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

Re: [usage-centered] UCD vs. XP

Expand Messages
  • Tony Mann
    I am intrigued about using UCD as a way of selecting stories for an iteration. I never thought of that before, and I am not sure how that will fit in with
    Message 1 of 44 , Apr 26 5:58 AM
    • 0 Attachment
      I am intrigued about using UCD as a way of selecting stories for an
      iteration. I never thought of that before, and I am not sure how that will
      fit in with established XP practices. I did copy your post to the XP list,
      so I will see how they respond.

      As for my own opinion, I need to mull this over some more, and perhaps play
      around with some sample stories I have to see how this might work.


      ----- Original Message -----
      From: "Larry Constantine" <lConstantine@...>
      To: <usage-centered@yahoogroups.com>
      Sent: Tuesday, April 24, 2001 11:05 AM
      Subject: RE: [usage-centered] UCD vs. XP

      > Tony Mann wrote:
      > > Reading through your message, I started to see a possible solution. In
      > > you generally try to create as many stories as you can at the start of
      > > project. Then you take a subset and create a release plan for the next
      > > iteration. Now, if the UI designer looked at *all* available stories,
      > > would start to get a good idea of where the product was going, and could
      > > thus form a decent model for building a UI on. Once they had this model
      > > place, they could then focus in on the story subset for the current
      > > interation, and create a UI that provided the required functionality.
      > > Because they would be using a model that spanned iterations, the hope is
      > > that any UI changes needed as iterations proceeded would be minor
      > > enough to
      > > be acceptable to the customers.
      > >
      > > I actually think this could work! But I need to try it out first.
      > > Luckily I
      > > have a project coming up that will use XP and UCD, so I will get to
      > > test this theory shortly. Naturally I will let you all know how it goes.
      > This is a good idea. Looking at "all" the user stories is analogous to
      > building a complete inventory of task cases (essential use cases), which
      > our experience is the absolute bare minimum task model for agile
      > usage-centered design. It does give you a shot at understanding the
      > needs--at least you know all the varied things a user might do or need to
      > do--but is still lacking in one area. A simple inventory does not
      > the structure of tasks, that is how they fit or might fit together
      > (Extension, inclusion, conditional inclusion, sequence, semantic affinity,
      > etc.). A collection of user stories suffers from the added problem that
      > scenarios constitute implied groupings of tasks without conscious
      > exploration by the designer of alternative "stories" that might make as
      > or more sense.
      > Here's what I would recommend: (1) collect all the user stories; (2) split
      > long or complex stories into constituent parts (chapters?); (3) group
      > stories and chapters (on cards) into affinity clusters based on apparent
      > degree of closeness or interdependence (these are best guesses at dialogs
      > other interaction contexts); (4) based on affinity clusters and
      > prioritization, identify the stories for the first release (and
      > succeeeding iterations); (5) "essentialize" the user stories in each
      > affinity cluster (make the narratives abstract, general, and
      > technology-free) before beginning the paper prototype design. The
      > form is for the designer to guide the UI design; the programmer gets a
      > revised story edited to conform to this design along with the UI paper
      > prototype.
      > > Again, I would like to invite all of those folks who are interested in
      > > over to the extremeprogramming@yahoogroups.com mailing list. There is a
      > > growing awareness that XP does not adequately address the needs of UI
      > > design, and the open-minded folks there are looking for solutions. To my
      > > mind, UCD is just the ticket.
      > I encourage copying all relevant positings to the XP group (and v.v.); you
      > can certainly copy mine. Not sure I can keep up with the scroll rate in
      > groups! :-)
      > --Larry Constantine
      > Director of Research & Development | Constantine & Lockwood, Ltd.
      > 58 Kathleen Circle | Rowley, MA 01969
      > t: +1 978 948 5012 | f: +1 978 948 5036 | www.foruse.com
      > 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 4:29 AM
      • 0 Attachment
        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.