XForms and Model-based User Interfaces

Steven Pemberton, CWI and W3C, Amsterdam


The name XForms is now somewhat of a misnomer.

XForms started off as a design for better forms on the web.

But because the design ended up so general, it is now widely used for applications in general, and not only forms-based applications

An XForms Application: A Google-maps like application

Maps in XForms

A clocks application

Clocks in XForms

The Essence of XForms

XForms has two essential, and separable, parts:

The Model: data, types, restrictions, invariants, declarative

The User-interface: abstract, accessible, device independent

The User Interface

The idea behind the controls is that they specify what you want to achieve and not how to achieve it.

For instance, a control selects one from a collection, or many from a collection, rather than specifying the use of radio buttons or a menu or whatever.

Example of abstract controls in use


The control used

The example just had three copies of the same control:

<select1 ref="colour">
<label>Colour </label>

Adapting controls

Since data can be typed, the system can adapt the controld to the type of the data. For instance, a date:


<input ref="when"><label>Date</label></input>

The advantage of abstract controls

The advantage of this is the possibility of late binding of concrete controls to the abstract controls.

This gives:

For instance, implementors have demonstrated the same XForm being run on a regular PC screen, a cell phone, via a voice browser, and even via an instant messenger buddy.

The Model

The XForms model allows you to specify

Model values can be exposed anywhere in the UI


The cost of producing applications

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.

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.

Google maps as Declarative Application

Although the example shown earlier 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.

Data point: Big machines

A certain company makes BIG machines (walk in): user interface is very demanding — needs 5 years, 30 people.

This became: 1 year, 10 people with XForms.

Do the sums. Assume one person costs 100k a year. Then this has gone from a 15M cost to a 1M cost. They have saved 14 million! (And 4 years)

Data point: applets

A company is producing many small applications using XForms, based on previous Javascript versions.

They report that the code is less than 25% of the original size (so a tenth of the work).

"[The designers] are really happy to not have to use javascript by the way: they like that if things don't work its not their fault :)"

The Approach

Declarative markup

Late binding of user interface (e.g. XBL)


The advantages of this approach are:

In other words: everything you need for the web!