The Future of Web Applications

Steven Pemberton

CWI and W3C
Kruislaan 413
1098 SJ Amsterdam
The Netherlands


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.

But this approach comes at a cost. Google Maps is of the order of 200K of Javascript code. Such applications are only writable by programming experts, and producing an application is not possible by the sort of people who often produce web pages for their own use.

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.

About me

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.

Having told you about me... 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.)

And there's more

This applies to other things too, memory and screens

And network bandwidth is increasing even faster (doubling every year).

So how are we using all that extra power?


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?


Views application environmentLate 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 you would call it a browser (it didn't use TCP/IP though).

It ran on an Atari ST (amongst others).

The Web

A success.

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.

By the way: what is the most important property of a website?

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.

Four properties:

Four properties:

Four properties:

Four properties:


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.

Enter CSS.

Separation of content and presentation

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:

Separating Content and Presentation: Author Advantages

Separating Content and Presentation: Webmaster Advantages

Separating Content and Presentation: Reader Advantages

Separating Content and Presentation: Implementor Advantages

CSS Zen Garden 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.

One single HTML file

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.








CSS still has shortcomings

Although CSS has solved the immediate problem, there are still some long-term problems, such as:

But CSS does address device independence

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.

Diversity of Devices

Japanese moble phone useThe 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.

Rant: 'Resolution'

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...

The mobile web

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.

Diversity of Users

Not only do we have diversity of devices, but diversity of users too!

We are all visually impaired at some time or another:

Diversity of Users

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).

Applications over the web

So these are the conditions we are working under.

Ease of use (for the programmer as well as the end user)

Device independence


But what is usability for programmers?

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.

Applications over the Web

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).

Applications are currently delivered in such forms as Java, Javascript, Flash etc., all device dependent to a greater or lesser degree, all inaccessible to a greater or lesser degree.

Applications over the Web

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.

Google maps

Constructing Applications

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.

Declarative programming

Traditional programming:

for i from 1 to 20 do



A bigger example

The shortest code I could find of an analogue clock was something over 1000 lines of C (the longest was over 4000 lines):

1000 lines of C code


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

Separation of content, presentation and functionality?

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


This separates


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.

Important properties of XForms

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.

One last piece

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, who produce FormsPlayer (this one is 5kbytes of XForms):

A world clock written using XForms

Google maps in XForms

Google maps in XForms

Google maps in XForms

Although the example shown above is not quite complete, it does more than Google maps does and yet it is only 25Kbytes of code (instead of the 200+K of Javascript).

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.

More information

These slides: