XForms and Model-based User Interfaces

Steven Pemberton, CWI and W3C, Amsterdam

XForms

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

A clocks application

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

Example

The control used

The example just had three copies of the same control:

<select1 ref="colour">
<label>Colour </label>
<item>
  <label>Red</label><value>#ff0000<value>
</item>
<item>
  <label>Blue</label><value>#00ff00</value>
</item>        
<item>
  <label>Green</label><value>#0000ff</value>
</item>
</select1>

Adapting controls

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

Example

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

• device independence
• accessibility
• multi-modality

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

• data sources and destinations, and initial values
• data types
• restrictions on values
• invariants between values

Model values can be exposed anywhere in the UI

Example

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: L^1.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)

Conclusion

The advantages of this approach are:

• Accessible applications: Because of the model-view-controller approach, it is just as easy to bind an accessible interface to the data as a purely visual one.
• Device independent applications: Likewise, because of the late binding to the data, you can bind device-dependent interfaces just as easily. (This is comparable with the advantages of using content+stylesheets in conventional XML and XHTML)
• Re-use: If someone develops a widget, like an analogue clock, it is available to all applications, and isn't hard-wired into an app (again, like stylesheets)
• Much less coding: Declarative programming is well known for requiring much less coding, mainly because you don't have to worry about all the fiddly administration involved in traditional procedural programming.

In other words: everything you need for the web!