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

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

Expand Messages
  • Jeff Patton
    ... as essetial ... was ... this use ... really ... good ... The essential use-case is a handy variation of a conventional use case. The two column format
    Message 1 of 10 , Dec 14, 2004
    • 0 Attachment
      --- 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
    • 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 2 of 10 , Dec 14, 2004
      • 0 Attachment
        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 3 of 10 , Dec 15, 2004
        • 0 Attachment
          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 4 of 10 , Feb 24, 2005
          • 0 Attachment
            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 5 of 10 , Feb 24, 2005
            • 0 Attachment
              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.