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

Re: Task model => User Interface ... Through task (esential use) cases?

Expand Messages
  • Jeff Patton
    Object oriented designers describe a process where they might read a narrative describing a business process circling nouns and underlining verbs. Nouns
    Message 1 of 10 , Dec 14, 2004
      Object oriented designers describe a process where they might read a
      narrative describing a business process circling nouns and
      underlining verbs. Nouns become objects, verbs services the object
      offers. The process described below "feels" similar to that for me.

      In practice when I look at the essential use case I'm looking for
      things on the screen: containers that hold information and actions
      that need to be buttons, links, or gestures. And, in practice I
      really do write essntial use case large on whiteboards or poster
      paper. This makes it easy to stick post-its on the EUC marking
      containers and actions. I can then easily transfer those post-its to
      another sheet of paper and arrange them in a way that best supports
      the workflow expressed in the essential use case. I do this
      stuff "in the large" collaborating with others. Never design alone
      if you can help it. It's kinda like pair programming - without the
      programming.

      Of course the devil is in the details. An interaction context often
      supports multiple tasks - so you'd need to do this process a few
      times and merge results into one visual context. Just as circling
      nouns and underlining verbs trivializes the skills of a good OO
      designer, this technique suggests UI design is a simple task of
      mapping. There's more to it than that. But this technique is a good
      starting point. Try it, you'll get useful results.

      -Jeff

      --- In agile-usability@yahoogroups.com, "aacockburn" <acockburn@a...>
      wrote:
      >
      > Jeff Patton contributed a section on essential interaction design
      to
      > the book "Crystal Clear: A Human-Powered Methodology for Small
      > Teams." In that there are few paragraphs on this subject:
      >
      > ----- begin extract -----
      > Deriving the UI
      >
      > When it comes time to develop the UI prototype, consider a
      technique
      > described by Constantine, Windl, Noble, and Lockwood
      > [http://www.foruse.com/articles/canonical.htm%5d, which I [Jeff] also
      > practice and have slightly modified to suit my personal style.
      >
      > Do the following for each user task, on poster sheets:
      >
      > * Write in two columns a synopsis of the dialog between the user
      and
      > the system. Put the User Intentions in the left column and the
      > corresponding System Responsibilities in the right. This is what
      > Constantine calls an 'essential use-case.'
      >
      > * Place sticky notes next to the user intentions and system
      > responsibilities that will be UI elements. Put those for input
      areas
      > and user actions on the left side and those for information
      > containers on the right side.
      > For example, a user intention such as 'user identifies self'
      suggests
      > two input areas and one action (name, password, some sort of "GO"
      > button). Write "username" and "password" on two sticky notes.
      > Write "action" on a third, or just use one with a different size or
      > color to indicate its presence. Stick all three next to the
      > phrase "user identifies self."
      > For a phrase such as 'system displays open orders,' you want a
      > component showing a list of orders. Write "list of orders" on a
      > sticky note and put it next to the phrase 'system displays open
      > orders.'
      >
      > When you're done, the use case should be spotted with sticky
      > notes.
      >
      > * Transfer the sticky notes to another flip chart, representing
      > screens the user will see, placing them in areas that seem
      > appropriate for the user interface of the system. When you're
      > comfortable with the placement, replace each sticky note with a
      > simple line drawing of the component drawn approximately the size
      > you'd expect the component to appear on the user interface. Do
      > this with each component. You now have what is called a "wire-
      frame"
      > drawing of the user interface.
      >
      > Test the wire-frame user interface by referring back to the use
      case.
      > One participant plays a user role performing the task, the other
      > plays the role of the system. Make sure the user interface you've
      > designed supports easy performance of the task.
      > ----- end extract -----
    • Agustín Villena
      jeff: Alistair wrote in a past message that you have documented some real examples about this process Any link? Thanks Agustin Jeff Patton
      Message 2 of 10 , Dec 15, 2004
        jeff:

        Alistair wrote in a past message that you have documented some real examples
        about this process
        Any link?

        Thanks
        Agustin

        "Jeff Patton" <jpatton@...> escribi� en el mensaje
        news:cpoiji+m6q9@......


        --- In agile-usability@yahoogroups.com, "Agust�n
        Villena"
        <agustin.villena@g...> wrote:
        > Hi!
        > Conantine & Loockwood proposes that tasks must be described
        as "essetial
        > use cases". Well... when I try to apply this format of use cases, I
        was
        > quickly involved in an endless loop of refining the redaction of
        this use
        > cases... Thinking about it, I realized that he problem is that I
        really
        > don't have a good understanding about when an esential use case is
        good
        > enough to begin the user interface design based on it

        The essential use-case is a handy variation of a conventional use
        case. The two column format limits the use case to a discussion
        between a single user and the system - ideal for considering the
        user's interaction with the system. The column headings "user
        intention" and "system responsibility" suggest thinking about what
        the user intends to do with the software rather than specific UI
        solutions to the problem. But, moving from the abstract nature of an
        essential use case to UI design is an act of design. The essential
        use case indicates what the user intends to do - it's up to you to
        determine what user interface might best help the user accomplish
        their goals - and the system accomplish its responsibilities.

        The EUC is only a small part of the picture though. The EUC
        describes, abstractly, the interactions. The use case is executed by
        a user role with a specific goal and operating from a specific
        context of use. Information about that role helps.

        The EUC describes interactions for a user task. I've found
        clustering tasks by affinity [in a task model] helpful for finding
        interaction contexts. Task performed by like people at similar
        points in time cluster close together. This usually suggests a place
        in the UI where several tasks might be performed. Knowing the
        interaction contexts lets you think about navigation from context to
        context.

        Constantine & other's approach using canonical components
        [http://foruse.com/articles/abstract.htm%5d helps to bridge the gap
        between a the EUC and a paper prototype. Paper protyping [I like
        Carolyn Synder's book on the subject] is critical for validating a
        proposed user interface. Try using the essential use case as a
        script for validating the UI.

        If I had a point in all this rambling it would be that the essential
        use case doesn't stand alone. You need all the models from usage
        centered design to help, along with lots of other techniques worth
        borrowing from other UCD approaches. The Cooper people talk
        about "jumping the spark gap." Basically crossing from the essential
        use case and all the other models you prepare to an appropriate user
        interface is a jump - like a spark crossing a spark gap in a spark
        plug. You need a concise useful set of models expressing your
        understanding of the user, their goals, context of use and tasks to
        help close that gap - make the jumping easier.

        Have you combined the essential use case with some of these other
        techniques? If you're interested in working through a specific
        situation, consider posting an essential use case here. I and the
        group might likely be able to ask you questions to fill in the
        context needed to suggest appropriate user interface.

        Thanks for your post,

        -Jeff

        > Well, is the "esential use cases" the only way to map tasks to
        UI
        >
        > Any advice?
        >
        > Agustin







        Yahoo! Groups Links
      • Agust�n Villena
        Hi Larry! The problem that I faced when trying to apply U-CD (in the Larry way) is that Is really dificult to know when the esential use case is ready .
        Message 3 of 10 , Feb 24, 2005
          Hi Larry!

          The problem that I faced when trying to apply U-CD (in the Larry way) is
          that Is really dificult to know when the esential use case is "ready".
          Thnking "a la" Test Driven Development: what tests the essential use case
          should pass to be considered "ok"?

          Agustin
        • Larry Constantine
          Agustin, Of course, there is no simple algorithmic test, but here is how I view it. An essential use case is ready when four things are true. (1) It is
          Message 4 of 10 , Feb 24, 2005
            Agustin,

            Of course, there is no simple algorithmic test, but here is how I view it.
            An essential use case is "ready" when four things are true.

            (1) It is expressed at an approprate level of abstraction. It is abstract
            and generalized but still specific to the particular task case and the
            application being designed. In other words, it is not "unsuitably vague."
            ("Expressing needs" as a user intention is unsuitably vague; "specifying
            kinds of entertainment is of interest" is not.)

            (2) It is technology- and implementation-independent. It has been purged of
            all technological or implementation terms and of all references, explicit or
            implicit, to specific solutions. This includes hidden assumptions in such
            technology-oriented words as "list" (implies a list of items). Seemingly
            innocent common words like "search" often carry implied baggage. (A user may
            intend to "find" or "get" or "identify" something, but "search" is a
            specific technology solution, not a user intention. The moment you use the
            word, it becomes all but impossible not to visualize a search box with a
            "go" button.)

            (3) It is expressed in terms of ordinary user language and the defined
            vocabulary of the subject matter or application domain. Elements of the
            subject matter or application domain are correctly and consistently
            referenced.

            (4) It is complete, enabling the user to perform the overall intention it
            represents. We verify completeness by walking through the task case, asking
            whether the user could complete the task assuming a user interface that
            supplied the necessary features and a system that carried out its
            responsibilities.

            With regards to the last criterion, completeness may refer only to the
            "happy case" or also to exceptions and alternatives, depending on resources
            and level of formality of the process. If it is a small application being
            designed under agile conditions, extensions may be allowed to emerge as
            needed rather than being elaborated and validated explicitly at the outset.


            --Larry Constantine, IDSA [mailto:lconstantine@...]
              Chief Scientist | Constantine & Lockwood, Ltd. | www.foruse.com

            > -----Original Message-----
            > From: news [mailto:news@...] On Behalf Of Agustín Villena
            > Sent: Thursday, 24 February 2005 1:58 PM
            > To: agile-usability@yahoogroups.com
            > Subject: [agile-usability] Re: Re: Task model => User Interface ...
            Through task (esential use)
            > cases?
            >
            >
            > Hi Larry!
            >
            > The problem that I faced when trying to apply U-CD (in the Larry way) is
            > that Is really dificult to know when the esential use case is "ready".
            > Thnking "a la" Test Driven Development: what tests the essential use case
            > should pass to be considered "ok"?
            >
            > Agustin
          Your message has been successfully submitted and would be delivered to recipients shortly.