|
What
followed was a 2 hour brainstorming session. As is typical with
such brainstorming, the conversation tended to thrash about across
different topics.
The
follow main constructs emerged:-
Input
Devices
Events and Notification
Actions
Decisions / Condition Evaluation
Exceptions
Transactions / Units of Work (implies ACID properties and persistent
storage)
States / Presentation of State
Navigation
Selection
Hide and Show
Scrolling
Content
Grouping
Idiomatic Tools (aka Widgets, Gadgets, Controls)
Containment
Views
Presentation / Layout / Positioning
Relative vs Absolute Positioning
Measurement of Navigability
Access Control by User Type / Class or Role
Some
of these constructs are elaborated as follows:-
Navigation
In
HTML an example would be a hyperlink. Navigation moves the user
between Views or Containers of Content.
Selection
In
HTML an example of selection would be a Jump Link. Equally the scroll
bar could be considered a selection device. Selection controls the
visible Content within a View of Container.
To
summarize this:-
Selection
selects Content
Navigation selects Views / Containers
It
was further observed that there a number of types of selection.
The use of appropriate selection devices is affected by the available
space, the size or quantity of content, whether the data is of a
fixed size, a bounded but unknown size or an unbounded size.
Transitions
It
was also noted that there are two key types of transition in a UI:
a change in view - implies a change of system state, which required
a "notification" from the system to the UI to refresh
the display; and between views. The first is driven from the system,
the second is driven by the user.
It
is essential that a profile for UI design can cope with both cases,
and a notation has some form for displaying actions or events which
occur from the system rather than the user.
This
would be essential if a UI profile were to cope adequately with
the requirements of any real-time system.
Input
Devices
Input
Devices are a highly abstract concept which can be divided into
different types such as Selection Devices and Data Input Devices.
Selection
Devices
In
turn Selection Devices can be predefined or must be dynamically
defined at run time, dependent on data size or quantity i.e. a selection
is unnecessary, if there is only one result from a search. A good
example of this might be Amazon.com. If your search has a single
match with a high degree of confidence then the page is displayed
immediately. If there are multiple matches or a low degree of confidence
then the user is presented with the results and asked to make a
choice.
Data
Input Devices
There
were several attributes of a data input device noted but the concept
was not explored any deeper. Some data requires validation, other
data does not. There is a possible sub-classification of data input
device based on this concept i.e. a Date Input Device by definition
must require validation of a date format.
It
is also possible to define an input as Mandatory, Optional or previously
In Error. There is perhaps a 4th category of Not Applicable. Therefore,
it may again be possible to assign classification to a Data Input
Device based on these attributes.
[The
discussion really started to get interesting when we looked at Presentation]
Presentation
The
elements of Presentation could be broken out as follows:-
Layout
Branding
Standards / Guidelines
Layout
/ Presentation
Layout
implies patterns, templates for positioning. This is what graphic
designers call a grid and program. Any kind of template implies
meta-model. A graphic design grid is a meta-model for a design.
Each design object ought to be an instance of the original grid.
Further, it should be possible to abstract the grid from examination
of instances of the design objects i.e. they all follow the same
layout.
Branding
There
are several elements to Branding including: graphics, identity marks
(logos) and word marks; color palette; font palette; style; and
attitude or atmosphere.
In
turn some of these can be examined more closely. Graphics, identity
marks and word marks coupled with color palette and style, can all
be associated with the art of iconography. Style, attitude and atmosphere,
can be affected by graphical style but also by interaction style
and content.
Standards
and Guidelines
It
is possible to draw up sets of standards and usage guidelines not
only for brand policing but quality control and usability in general.
Standards and Guidelines can cover almost any area of design, including
but not limited to, color palette, font palette, layout, interaction,
navigation. In summary, standards can apply to both Presentation
and Navigation.
Generically,
standards and guidelines can be considered as constraints. They
constrain the design and set out the boundaries for the designer.
Constraints
Constraints
can be used to validate a model. Therefore, a design can be represented
in a model. The standards and guidelines can be represented as a
set of constraints. Conflict between competing constraints can be
adjudicated based on rules. Those rules can be held in a Constraint
Resolution Table. It is common in most guideline documents to find
notes which identify the winning guideline in an instance where
one or more conflicting pieces of advice might apply.
Emerging
from this discussion, it was obvious that there were similarities
with existing modeling language. UML already has notation for modeling
designs and another one for modeling constraints - albeit for a
different purpose, computer programs.
Vocabulary
It
was noted that there is an urgent need to develop a full vocabulary
for UI Design - a lexicon or glossary. For example, what does thumbnail
mean? Clearly, it is some, summary, abbreviation or small image
but without precise definition it is open to misuse or misunderstanding.
Form
Vs Function
It
was observed that Presentation is essentially an element of the
Form of UI Design problem. Function goes more to behavior and functionality,
whilst Form is Presentation, Style, Layout and appearance.
Form
Vs Function with Conceptual Modeling
If
we consider an object model which is intended to represent the mental
model for the user i.e. the designers' model where the designer
is hopefully as close to a user's mental model as possible, then
we can look at Form and Function is a slightly different light.
Form
lends itself to attributes of any given object. The composition
of those attributes, the aggregation of content, and inheritance
of attributes or content. For example, this website contains a number
of objects which in the abstract are White Papers, Editorials, Book
Reviews and so forth. They have a physical implementation as HTML
pages. Each of them reuses a template, layout, grid devised from
a program of such grids for the website. The program attaches to
the collection - the website, whilst the grid attaches to individual
objects in the collection - the HTML pages.
Function
on the other hand, lends itself to the behavior of an element in
a design. For example, in a GUI environment, many different objects
can be dragged and dropped. The content of the object can vary but
the drag'n'drop behavior remains the same. The appearance can vary
too, again dependent on the content or classification of the object,
but the drag'n'drop behavior remains the same.
It
might be fair to say that user interface objects can compose a "draggable"
behavior. The Java OO language tells us that something which is
"draggable" is in fact exhibiting the "draggable"
interface. In OO modeling language, we can say that the object is
of type "draggable".
To
use another, perhaps easier to follow example, imagine a computer
game which features 3 characters: the hero (a person); his pet dog;
and a robot. Each of these characters plays different roles in the
game, they look different, and do different things, the underlying
data for each character is different. However, all 3 can be asked
to "walk" across the screen from one object to another.
Imagine
that you can "right click" each of the three characters
and an in-context menu of actions appears. This is classic OOUI.
You are selecting an object with the right click, then offered a
selection of actions from the pop-up menu. It is an object-action
system - the definition of an OOUI interface.
On
that pop-up for all three characters, you will see the option, "walk".
In other words, the hero, the dog and the robot all exhibit the
"walkable" interface. They each have polymorphic behavior
of walking. The are of type "walking character".
We
can further extrapolate to say that Function in a user interface
is determined by type or interface and exhibits the basic OO property
of polymorphism.
Therefore,
Form of a UI design is determined by its data inheritance and
encapsulation but its Function is determined by its polymorphic
behavior.
This
simple rule seems to be of profound value in analysis of UI and
as a guide to how tools, notation and process for UI design should
develop in the future.
The
afternoon Session
In
the second half of the workshop, the two "Interaction Spaces"
and discussed their findings. There was a considerable divergence
between the efforts of each group. There was a notable difference
in membership. The other group was mostly academics who had been
thinking about this space for purposes of doctoral and post doctoral
research, and my own group which was mostly people working in industry.
We
set out to define some essential elements of a UI Profile for UML.
The outcome produced the following suggested terms and definitions.
View
- a collection of elements which are visible
Viewport
- determines the visibility. It is a window of information and actions
which are available, to the user, but not necessarily visible.
Other
terms under consideration for Viewport were Perceptional Theatre,
Interaction Space or Virtual World. Viewport is looked down upon
because of its commercial usage in products such as the Amiga. Virtual
World was thought to be narrow, by implication applies to computer
games and simulations.
It
was observed that Computer Games and Simulation software makes for
the natural test environment for any UML Profile. Both are by nature
complex and real-time. If a suggested profile can accommodate the
requirements for these types of system then there is a good chance
that it is sufficient for general use.
Transition
- can be between views or between interaction spaces.
Using
these definitions, a collaborative modeling session produced the
following profile. This is shown as a UML Class diagram. However,
what is displayed here is intended to be seen as a Level 2 Meta-model
diagram i.e. any given system design ought to be an instance of
this diagram.
The
Abstract Layer
The
abstract interaction space (or Viewport) is intended to represent
the available information and actions. The "uses" arrow
is intended to show an action being carried out which changes the
Interaction Space. In turn Interaction Spaces can compose / aggregate
other Interaction Spaces.
The
Concrete Layer
The
Concrete layer is intended to represent the actual elements of a
user interface, as manifested in a design. A View is the collection
of elements(information and actions) which are visible. A View "maps
to" or "belongs to" an Interaction Space. The "uses"
arrow represents the performing on an action which changes the View
without necessarily changing the Interaction Space. Views can compose
or aggregate other Views.
The
Adapter Layer
The
purpose of this layer is to avoid polluting the business layer (or
problem domain layer) with user interface elements or the ability
to interact with user interface elements. This layer should be called
the "Domain Adapter layer". Each interaction space would
require a Domain Adapter. The Domain Adapter would act as a Facade
to many Domain Classes.
The
Domain Adapter is playing an important role as a "denormalizor".
The Abstract Interaction Space layer is intended to represent the
Designer's Model. This in turn is the designer's attempt to represent
the User Mental Model. The User's Mental Model is NOT the Domain
Model. A properly designed Domain Model would be fully normalized.
The data would be stored in 3rd Normal Form across the classes in
the object model. User's Mental Models need not be in 3rd Normal
Form. The Domain Adapter copes with this complexity on behalf of
the Business Layer.
I
was very comfortable with the inclusion of this layer because I
have seen it before in real system. The Domain Adapter Layer encapsulates
the "notification" mechanism for the UI. In other words,
the Domain Adapter is responsible for that other kind of transition,
the one generated by the system. The Domain Adapter will notify
the Abstract Interaction Space of changes in the underlying system
state. The Domain Adapter can, from this perspective, generate actions.
These are system actions rather than user actions.
System
Actions can change the state of the user interface. They can change
the current view, they may even change the current Interaction Space.
|
