Long Reply- RE: Character based notations
I'm honored to have your feedback, and I'd also like to say I enjoyed your
paper on Model Based Design Patterns.
Speaking for myself, I should have been more precise. My regrets.
Here are my answers to the very good points you bring up:
1. By "development experience", yes, I do mean coding experience.
While I don't have an exact statistic, my gut feeling is that almost all
user interface designers, cognitive psych's, usability experts, etc., have
had some coding experience at some time in their lives. As for what
pseudocode has to do with coding experience, almost anyone who has ever
taken a programming course has seen and used such structured constructs
before (but majority humans do not.) This makes it more approachable to
(And I do feel it's important that interface designers have coding
experience. My observation is that if the interface designers do not have at
least some software development awareness, they will not gain sufficient
respect and acceptance for their designs by the software engineering group
whose job it is to create the reality of the product. It is quite possible
their reasoning, conclusions, and work will be rejected by the programmers.
While this may sound bizarre, sadly this is often corporate fact. If it
wasn't, Alan Cooper's book, "The Inmates are Running the Asylum" would not
have been necessary or so popular.)
2. Notations exist both as a shorthand and a means of conceptually and
abstractly manipulating broad, diverse, or rich expression which would
otherwise be too complex to manipulate in detail. However, the UML is itself
growing towards that complexity breaking point.
So you may still have the UML, but I don't. I've opted out. And with just
two exceptions, all the companies I know who've looked at it or tried it
have ultimately rejected it. If the UML was such a great thing, why is there
such a backlash now? Why is UML such a burden that companies need dedicated
UML experts in addition to their programmers? It's rapidly becoming way too
cumbersome to use for someone who needs to crank out code for a living, and
for companies who need to release products under market pressure.
Please don't get me wrong. There are graphical notations I really like- as
an ex- realtime systems programmer, I'm a user and great fan of both Harel
Statecharts and message-sequence diagrams- and they're a part of the UML!
But they are more easily USABLE than other notations within the UML, when
one considers usability in terms of learnability, efficiency, memorability,
errors, and satisfaction.
So there, I've said it. I personally find the complexity of the UML to be
high and the usability of the UML to be poor (not to mention the support
(Ever tried to use an UML Use Case Diagram on a real world project?)
Again, personally, as a first-time "out-of-the-box" experience, I found
Tony's type of textual notation more understandable. I believe I could hand
over an abstract textual model like Tony described to a programmer and say,
"build this, please" and they'd get it pretty close to right the first time.
I'm not sure I could do that with most graphical UI notations.
As for your question about using the graphical notation for editing, my
experience with using the UML was that I spent very little time drawing,
linking, and rearranging pictures (the graphical portion) and lots of time
typing in class information, method names and signatures, making
How many people still use a text editor for creating HTML instead of a
graphical WYSIWYG editor? Why does the IEC standard for PLC programming
(IEC-1131) have both graphical as well as textual notations for expression
of PLC programs? Why does the country of Japan vote almost annually to adopt
English as their national language?
Just because it's graphical does not mean it's always easier, better, or
more concise than text. I could make the same argument as you, and say that
it's even harder to generate good code from graphical notation- and code
generation is one of the primary purchase reasons for UML tools!
Regarding 3, I would disagree with your statement that people usually
utilise size and layout for focus and grouping. (Maybe it depends on what
you mean by focus.) In the real world, UML practitioners use decomposition
and hierarchy for focus and grouping of concepts. Real world projects don't
play nice because of their size and complexity. Humans use decomposition to
break up big problems into little managable ones and hierarchy to express
order and priority. Size and layout is used for emphasis within a context.
Remember, I don't have to generate a great diagram, just one that's good
enough. The support tool should let me tweak or massage the diagram until
I'm happy with it, then save my tweaks as textual annotations. There are, in
fact, commercial diagram generators (products like AllClear) which do a
pretty good job at creating diagrams from structured text. But for me, I'd
rather have a good translation to a lo-fi prototype, hi-fi prototype, or
even code before I care about generating a good graphical notation diagram.
Forgive me if I sound too concrete, but my background is in commerce, not
academia, and I mean no disrespect. I need notations I can quickly
understand and use to my benefit, robust tools that I can easily understand
and use, and practical patterns that apply to a majority of the situations
(or fragments of situations) that I encounter, all so that I can better
design, document, communicate, build, and deliver more usable products.
I hope this clears up my comments as well as the insanity behind my
From: Hallvard Tratteberg [mailto:hal@...]
Sent: Saturday, April 28, 2001 4:52 PM
Subject: RE: [usage-centered] Character based notations (was Patterns
cum UCD vs. XP)
Tony and David,
> I really like Tony's suggestion for using character-based UI notations forI would argue against all these. First, what has pseudocode with development
> 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.
experience. Do you mean coding experience? If 2 is correct, why do we have
UML? In addition, most modelling language distinguish between abstract
syntax and surface syntax, and usually support a textual notation for file
exchange, while using a graphical one for editing. Why? For 3 I would say
that it is very difficult to generate good graphical diagrams from text,
since they usually utilise size and layout for focus and grouping of
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
- 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