Loading ...
Sorry, an error occurred while loading the content.

Long Reply- RE: Character based notations

Expand Messages
  • David W. Schofield
    Hallvard, 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
    Message 1 of 44 , Apr 29, 2001

      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
      annotations, etc.
      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

      Regards, Dave

      -----Original Message-----
      From: Hallvard Tratteberg [mailto:hal@...]
      Sent: Saturday, April 28, 2001 4:52 PM
      To: usage-centered@yahoogroups.com
      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 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.

      I would argue against all these. First, what has pseudocode with development
      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/
    • Nuno J. Nunes
      on 30/04/01 08:40, Hallvard Trtteberg at hal@idi.ntnu.no wrote: Hallvard, ... I m familiar with Paternò s interactors. That approach is very close to the
      Message 44 of 44 , Apr 30, 2001
        on 30/04/01 08:40, Hallvard Trtteberg at hal@... wrote:


        > The abstraction is close to the "York/Piza" interactors, which in short
        > 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.

        I'm familiar with Paternò's interactors. That approach is very close to the
        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 runtime
        > system for this. I'm also working on a mapping to UML through stereotypes,
        > which I guess you're particularly interested in.

        Sounds interesting... Can you send more info on that UML adaptation? Is the
        runtime environment available?

        > I like to call the UID patters, i.e. both user interface and design. If we
        > omit "design" these may wrongly regarded as software patterns.

        I prefer a different distinction:
        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
        URL: http://math.uma.pt/njn/
        Address: Campus Universitário da Penteada
        9000 - Funchal - Portugal
      Your message has been successfully submitted and would be delivered to recipients shortly.