The Web took the world by storm, and as a result developed rapidly in many directions. However it still exhibits many aspects of its early development, such as its visual and computer-screen orientation. But the Web is still developing rapidly: there are now more browsers on mobile telephones than on desktops, and there is a vast diversity in types of devices, types and orientations of screens, and sizes (in number of pixels), and resolutions (in dpi) of screens.
Dealing with this diversity is impossible to address just by keeping a list of all the possible devices, or even a list of the most-used ones, and producing different sites for them, since the complexity would be unmanageable, and because once sites started turning away browsers and devices they didn't know, the browser makers responded by disguising themselves to such sites as other browsers.
On top of this diversity there is also the diversity required for accessibility. Although providing access for the visually impaired is an important reason for accessibility, we are all more or less visually impaired at one time or another. When displaying an application on a projector screen at a conference or meeting, the whole audience will typically be visually impaired in comparison to someone sitting behind a computer screen. The existence of separate so-called "Ten-foot Interfaces" (for people controlling their computers by remote control from an armchair ten feet away) demonstrates that the original applications are not designed for accessibility. Furthermore, Google (and all other search engines) is blind, and sees only what a blind user sees of a page; as the webmaster of a large bank has remarked, "we have noticed that improving accessibility increases our Google rating".
The success of the Web has turned the browser into a central application area for the user, and you can spend most of your day working with applications in the browser, reading mail, shopping, searching your own diskdrive. The advent of applications such as Google Maps and GMail has focussed minds on delivering applications via the web, not least because it eliminates the problems involved with versioning: everyone always has the most recent version of your application. Since Web-based applications have benefits for both user and provider, we can only expect to see more of them in the future.
The Web Interfaces landscape is in turmoil at the moment. Microsoft has announced a new markup language and vector graphics language for the next version of Windows; probably as a response Adobe has acquired Macromedia and therefore Flash; W3C have standards for applications in the form of XForms, XHTML and SVG and are working on 'compound documents'; and other browser manufacturers are calling for their own version of HTML.
What are we to make of these different approaches? Are they conflicting? Have any addressed authorability, device-independence, usability or accessibility? Is it even possible to make accessible applications? HTML made creating hypertext documents just about as easy as it could be; do any of the new approaches address this need for simplicity, or has power been irretrievably returned to the programmers?
This talk discusses the requirements for Web Applications, and the underpinnings necessary to make Web Applications follow in the same spirit that engendered the Web in the first place.
Researcher at the Dutch national research centre CWI
Organised 2 workshops at the first Web conference in 1994
Co-author of CSS, HTML4, XHTML, XML Events, XForms, etc
Chair of HTML and Forms working groups
Until recently, editor-in-Chief of ACM/interactions.
...now let me tell you something about computers.
We live in an exponential world.
To demonstrate Moore's Law
Take a piece of paper, divide it in two, and write this year's date in one half:
Now divide the other half in two vertically, and write the date 18 months ago in one half:
Now divide the remaining space in half, and write the date 18 months earlier (or in other words 3 years ago) in one half:
Repeat until your pen is thicker than the space you have to divide in two:
This demonstrates that your current computer is more powerful than all other computers you have had put together (and the original Macintosh (1984) had tiny amounts of computing power available.)
This applies to other things too, memory and screens
And network bandwidth is increasing even faster (doubling every year).
Mostly for pixel pushing.
Most computers spend most of their active life idle.
Why aren't we using the extra power to make people's (our!) lives better?
Late 80's after designing a programming language designed on usability principles (ABC - Python is based on it), we designed an 'application environment' that investigated usability at the system level (not just the application level).
This system had an extensible markup language, vector graphics, style sheets, a DOM, client-side scripting...today you would call it a browser (it didn't use TCP/IP though).
It ran on an Atari ST (amongst others).
The genius of the web was that it invented little that was new; it mainly integrated existing things in a good way.
It fulfilled a need.
It leveraged existing content (compare with the failure of WAP).
It was easy to use.
Forrester did a study (8500+ subjects!) on what properties of a website made a person choose one website over another that offered the same service.
As the web took off there was the threat that it would disintegrate, or at least split into non-interoperable sub-webs.
The reason you don't want that to happen is because of Metcalf's law: the value of a network is proportional to the square of the number of its nodes, so a network is worth twice the same network split into two (think telephones, or instant messengers).
So W3C was formed to "lead the web to its true potential".
One of the first tasks was to undo the mess of presentational elements added to HTML by the browser manufacturers who didn't understand the theoretical underpinnings.
The central aim of CSS is the separation of content and presentation.
There are so many advantages to this separation, that it is best to split them into four categories:
Csszengarden.com is a demonstration that CSS has come of age. It is a website with essentially one HTML page...and hundreds of beautiful, breathtaking CSS stylesheets applied to that one page.
Is uses very simple HTML: div, h1, h2, h3, span, p, ul/li, a, acronym.
As you look at each presented page, you have to keep repeating to yourself: this is the same HTML page.
Although CSS has solved the immediate problem, there are still some long-term problems, such as:
One of the advantages of CSS is that you can supply different stylesheets for different (classes of) devices.
This means that you can write your page once and have it work on different devices.
The world isn't just PC's
There are now more browsers on phones than on personal computers.
There are browsers on many new devices: phones, PDAs, printers, even refrigerators; there are increasing numbers of form factors, sizes, resolutions.
Everything to do with resolution is a mess!
'Resolution' of a printer: dpi
'Resolution' of a screen: number of pixels
Pixel density of a screen is given as the inverse of the dpi, as 'dot pitch', in millimeters.
Most computer systems don't know the dpi of the screen they are attached to (why can't the screen tell the OS???), so it is anyone's guess what size font you will get when you ask for 10 point text.
No one knows how to tell the OS what dpi they have...
There is a threat that the web will split into two webs, a desktop one, and a mobile one.
The reason we don't want that to happen is because of Metcalf's law: the value of a network is proportional to the square of the number of its nodes, so a network is worth twice the same network split into two (think telephones, or instant messengers).
The W3C is now starting the mobile web initiative, MWI, to try and combat this tendency, and ensure a homogenous web that is device independent.
Not only do we have diversity of devices, but diversity of users too!
We are all visually impaired at some time or another:
Not only do we have diversity of devices, but diversity of users too!
We are all visually impaired at some time or another:
Most applications do not support accessibility in any meaningful way.
Even if you can zoom the text, the menus and dialogue boxes stay just as small.
The need for so called ten-foot interfaces is an admission of lack of accessibility.
By the way: Google is a blind user, and sees only what a blind person sees (which is why text in images, or flash, are a bad idea, and why spending money on accessibility is a good idea).
So these are the conditions we are working under.
Ease of use (for the programmer as well as the end user)
I don't need to tell you what usability is about: speed, correctness, pleasure.
According to the DoD, 90% of the cost of software is debugging.
According to Fred Brookes, in his classic book The Mythical Man Month, the number of bugs increases quadratically according to code size: L1.5.
In other words, a program that is 10 times longer is 32 times harder to write.
Or put another way: a program that is 10 times smaller needs only 3% of the effort.
Speed: shorter programs
Correctness: less bugs, which is also a function of program length
Pleasure: well, speaking personally, that is also a function of less bugs.
What is an application?
Right from the beginning the web used image maps and forms.
An application is anything that takes input and returns a different result for different input.
Doesn't have to be the browser though, as long as it is 'web-based' (i.e. it uses the HTTP protocol).
Recent interest generated by Google Maps and GMail. One of the big advantages is that everyone has always got the most recent version. Hard to write though: Google maps is more than 200k of code.
The problem is, no one writes applications except programmers.
Interesting exception: spreadsheets
Mostly because they use a declarative programming model.
The nice part about declarative programming is that the computer takes care of all the boring fiddly detail.
sum=0 for i from 1 to 20 do sum:=sum+a[i] done
The shortest code I could find of an analogue clock was something over 1000 lines of C (the longest was over 4000 lines):
Here is the essence of the code used for the clock example used at the beginning of this talk. Twenty lines of code instead of 1000.
type clock = (h, m, s) displayed as circled(combined(hhand; mhand; shand; decor)) shand = line(slength) rotated (s × 60) mhand = line(mlength) rotated (m × 60) hhand = line(hlength) rotated (h × 30 + m ÷ 2) decor = ... slength = ... ... clock c c.s = system:seconds mod 60 c.m = (system:seconds div 60) mod 60 c.h = (system:seconds div 3600) mod 24
So if the separation of content and presentation is such a good idea, is it possible to separate the functionality as well?
This idea has actually been around for years in programming circles (Xerox Parc, 1979): it is called MVC
Which brings us to the last piece of the puzzle, XForms.
XForms is a new W3C technology designed to replace HTML Forms.
HTML Forms have done a great job this last decade, and have kick-started the e-commerce revolutions, but to be honest, we now know what's wrong with them.
XForms is an important web technology for the HCI field, because it has been designed primarily to improve the user experience, out of the box.
Improves the user experience, largely by doing work on the client side (using some of those spare cycles).
It is accessible out of the box (one of the co-designers, TV Raman, is blind himself).
It is device independent out of the box: the controls rather than being visually-oriented (like radio buttons) are intent-oriented (this control selects one value from a list), making it much easier to map to different modalities.
It has a declarative spreadsheet-like computational engine.
It separates the model from the controls, and has no view layer of its own (leaving that to the style-language).
Even though it was ostensibly designed as a Forms replacement, it has all the elements for building applications.
OK, I lied, XForms is not quite the last piece.
The last piece is SVG (structured vector graphics) as stylesheet language using XBL.
Some of the best work in this area is being done by a company called xport.net, who produce FormsPlayer (this one is 5kbytes of XForms):
Remember, empirically, a program that is an order of magnitude smaller needs only 3% of the effort to build.
The web application framework of the future will
However, just like with the original development of the web, I am sure that the world will take the wrong path initially and we will have some years of work and education to get the world back on the right path.