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.