Views: Moving the User Interface from the Application to the System
Steven Pemberton, CWI, Amsterdam
The Analysis
Classical user interface design analyses the user's requirements and tasks
before going on to design an application for that task.
A fundamental problem with this approach is that users seldom work for long
periods using one application, but swap rapidly and often from one application
to the other.
There can be various reasons for this swapping, for instance:
- because of the need for information -- you're working on a document, and
you need some data from another document produced by another
application;
- because of interruptions -- someonce comes in asking for some
information;
- because of demands of the application -- you need to draw a diagram to
put in your document;
- because of the computer -- you read news while waiting for a compilation
to finish.
This rapid swapping between applications brings many problems with it.
- Consistency: This is probably the best known of the problems, but even
so, the situation is worse than many realise. Example.
- Integration: Information can only be transferred between applications in
very fixed, usually low-level ways. Example.
- Interoperability: It is extremely difficult to get information from one
application to another, to link applications up to form a more powerful
application. Example.
- Difficulty in learning and using: Since each application is written in
relative isolation from all the others, the user has extra work learning
how to use the different applications, and remembering when they are using
any particular one, what the specialties of this one are.
Not only this, but programs for modern windowing systems are extremely hard to
write. Example.
The Problem
The main underlying problem is the isolation between applications. Each program
apart from true functionality has also to implement the user interface, and
code to access backing store.
This of course guarantees that there are differences in the user interface,
and means that applications can only read the data formats of applications it
knows about.
Although this is slowly changing, with publish and subscribe techniques, it
is still at a cost to the programmer, who has to do even more work than
ever.
Views
Views is an application environment with a system supplied user interface
layer, and a system supplied persistent data layer, where new applications,
which just represent the true functionality of the application can be plugged
in on the fly.
This gives: a greater degree of consistency in the user interface, since it
is centralised in one place, much less programming, and a high degree of
interoperability, since the applications don't know themselves exactly how
their data is stored, and the system can mediate for them.
To come: Choice of one user interface: TAXATA (active documents)
Advantages: ease of learning, ease of use, consistency, interoperability,
high integration, openness, ease of programming, system supplied undo,...
Examples of taxata interfaces
Objects, presentations, invariants.
Some Publications
These are all in PDF.