From: unisql!kk@cs.utexas.edu (Kerry Kimbrough)
Newsgroups: fj.mail-lists.x-window
Subject: Design for independent UI development
Date: 5 Nov 92 18:10:29 GMT
Distribution: fj
Organization: Workstation Div., Supermicro Systems Group, Sony Corporation

Date: Thu, 5 Nov 92 10:35:14 CST
Message-Id: <9211051635.AA02325@hyundai.unisql>



   |>   It is my experience that the user interface tends to be very tightly
   |>   bound to the system that is being designed, and that the user
   |>   interface code tends to be mixed in directly with application code,
   |>   making it very hard to split up their development.

To those interested in sw UI's, this issue occupies somewhat the same
position as the question of a unified field theory does for physicists. 

Since the 60's (! remember the Reaction Handler?), the fundamental premise
of work in UIMSs and most UI toolkits is that it's possible to modularize a
sw system so that its UI is independent of its functional core. We want
this to be true, we *need* this to be true. (In fact, if it isn't true,
then we're likely to go broke.)  It seems very plausible and possible. But
is it actually true? As for a unified field, the evidence is tantalizing
but incomplete.

It seems to be a matter of degree. Some UI independence is certainly
possible, but how much? A lot? Or negligible? For example, it's pretty
clear that the functional core need not depend on most UI details at the
lowest lexical (presentation) level. But experience shows that it's much
harder for the intermediate dialog levels of the UI to remain extricable
from core semantics.

Also, it seems to depend on what kind of UI you're talking about. For
command language UIs and forms-based UIs, we've seen a lot of successful
tools for independent UI development. But for the direct manipulation GUIs
that occupy our main interest today, the situation is still pretty rough.
The efficacy of the tools seems inversely proportional to their
applicability to new domains, with new kinds of objects at the functional
core.

Personally, I feel that hope for DM GUIs may lie in the notion of a shared
database of objects that form the communication between UI and core. This
is the approach taken by the UIMSs like Serpent and Apogee and others.
These shared objects must reflect both UI and core domain needs.  These are
objects *of* the core domain that encapsulate domain facts and behaviors.
But, within the domain, they function as UI ambassadors. That is, these are
the objects that represent exactly how the system appears to the world
outside its domain (which may very different from how the system actually
works). These ambassadors may constitute the true line of UI independence,
with both UI and core free to vary on their respective sides of the line.

That's why, regardless of what tools you use, the first step in designing a
GUI is to itemize in complete detail all the components of the user's
conceptual model of the system --- facts, relationships, and behaviors.
This model is then a picture of your ambassador objects. That also explains
why designing the UI first increases chances of system success --- without
the conceptual model, system engineers don't know what ambassadors to
construct.