RE: [usage-centered] Character based notations (was Patterns cum UCD vs. XP)
- I really like Tony's suggestion for using character-based UI notations for
both applications and fragments and enhancing them with pattern mappings.
Three reasons stand out to me:
1. Most UI designers will have some development experience, and the
pseuodocode-type expression will leverage off that prior experience.
2. The textual notation is clearer than current graphical ones, unless the
ideographs and spacial arrangement were much clearer than most used today.
3. The textual notation is easily machine translatable into graphical
notations or lo- or hi-fidelity prototypes, or even generate code for
language/platform specific development environments.
It's appealing enough that it's hard to resist on-the-fly proposing
extensions with simple optional navigation/formatting/locating directives.
Navigation is particularly important because it presents the work/task flow.
As we know, three elements, in the right location-order, may produce a
highly usable UI, whereas the same three elements in a different sequence or
arrangement could be confusing or unusable.
navigation: button, "Next>","Touch toes"
picture: bending-down1.jpg, leftcenter
location: 25,25,75,75 // size and location of application relative to
// in this case X1=25%, Y1=25%, X2=75%, Y2=75%
// (full screen [and default size] is 0,0,100,100)
picture: bending-down1.jpg, 0,0,33,100 // picture occupies left one-third
of the interaction space, and is full height.
// Of course, the "wizard" pattern knows this already.
As well, I could see this mapping easily to UsageCD's Canonical prototypes,
which could be used as the graphical notation.
Of course, this must be kept simple to remain agile... require only the most
basic elements (lots of optionals), intelligent use of defaults, etc., and
keep it in plain language so that it could be explained to the layman with
(Images of needing a YANN interpreter- Yet Another Notation Notation)
Now that we're on this track, two things:
1. Can anybody tell us how much of this, if any, is present in the UML
2. May I make a proposal? As a proof-of-concept, would anyone else (besides
me and potentially Larry) be interested creating a text-based UI notation
for UsageCD's canonical prototype notation-model? I feel it's small enough
in scope that we could accomplish this in a relatively short time frame.
This would accomplish useful work, as well as provide a vehicle for further
evaluating the concept. How about it? (I'm running out of those darned
- Dave "Huck Finn" Schofield
From: Tony Mann [mailto:tonymann@...]
Sent: Friday, April 27, 2001 12:08 PM
Subject: Re: [usage-centered] Patterns (was UCD vs. XP)
First of all, I really like these patterns. They are useful, quickly
applicable, and easy to understand. I will look forward to seeing more of
As I read this post and your last post, I started to think about what Larry
said about OO notation being so much more advanced than UI notation. And
then I thought that maybe a character-based UI notation could be a handy
thing to have. But it would be much more effective with UI patterns behind
For example, here is a possibility for a wizard:
style: simple, pictures
title: "Toe touch"
title: "Bend down"
body: "Arch your back and let your hands dangle."
title: "Touch toes"
body: "Let your outstretched hands touch your toes."
This wizard could be instantiated in HTML, Java, etc.
This list selector could be instantiated according to your bookmark model,
or to another suitable model. (We can assume that the instantiated model has
a way to save and retrieve the bookmarks).
Perhaps with this type of notation, and a portfolio of models to back it up,
UI development can leverage some of the techniques that have served OO so
well. Has any work been done in this area already?
- on 30/04/01 08:40, Hallvard Trtteberg at hal@... wrote:
> The abstraction is close to the "York/Piza" interactors, which in shortI'm familiar with Paternò's interactors. That approach is very close to the
> introduces a basic UI building block called "interactor" which mediates
> information in two directions, user to system and system to user, through
> four "gates". In my notation, the interactor is a rectangular box with
> title, triangular gates and a resource interface. I've introduced functions
> and merged these with gates, to provide domain specific computations.
> Interactors are put together a bit like lego-bricks, by connecting the gates
> and can be nested into a hierarchical graph, similar to a process network. I
> formalise part of this using Statecharts, while the process algebra LOTOS
> has been used by others. If anyone is particularly interested, I can send
> him/her parts of my thesis, where this is discussed in relation to concrete
> interface elements.
model-based tradition, which was popular years ago but failed to gain
widespread support mainly because model-based environments (including
back-to-back automatic generation) never proved to be effective in practice.
I'm not saying this approach is wrong or flawed, it surely is sound from a
theoretical perspective. The main problem is that "pure" model-based
approaches (in the sense that they attempt to fully automate the UID
process) have not proved to be flexible enough for modern UIs. There are
other successful examples of automatic generation techniques, mainly the web
- where UIs described in markup are rendered in different platforms.
However, those successful examples are very limited in terms of the extent
to which they support the UID process.
Times are changing though. Today we're moving away from the stable desktop
paradigm and there is an increasing number of target platforms that differ
substantially in terms of the devices we use to interact, and the related
interaction styles and techniques.
My point is that model-based techniques will inevitably come into play
again. It will be very difficult to deploy software systems over a series of
different platforms (just think of desktop, web, palm, cellular phone, and
interactive TV) without effective model-based techniques. It's not a matter
of whether we like them or not... We just can't cope with the increasing
complexity without model-based approaches.
> I want this to be a practical tool and have experimented with a runtimeSounds interesting... Can you send more info on that UML adaptation? Is the
> system for this. I'm also working on a mapping to UML through stereotypes,
> which I guess you're particularly interested in.
runtime environment available?
> I like to call the UID patters, i.e. both user interface and design. If weI prefer a different distinction:
> omit "design" these may wrongly regarded as software patterns.
Software patterns - all patterns that have to do with software
Design patterns - patterns that have to do with OO design
Analysis patterns - same for OO analysis
UI patterns - patterns that have to do with UIs - interaction patterns,
UID patterns, etc. are different classes of UI patterns.
Nuno Jardim Nunes
University of Madeira - Teaching Assistant
Mathematics Dep. - Computer Science Unit
phone: +351 291 705160 (direct) 705150 (secretary)
fax: +351 291 705199
Address: Campus Universitário da Penteada
9000 - Funchal - Portugal