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

RE: [agile-usability] Re: principles for UI architectures

Expand Messages
  • Jon Kern
    i tend to do the following: break up roles/personas think about context of usage bridge the two together consider percentage usage of a given persona/role for
    Message 1 of 12 , Aug 1, 2004
      i tend to do the following:
       
      break up roles/personas
       
      think about context of usage
       
      bridge the two together
       
      consider percentage usage of a given persona/role for given context/function.
       
      helps to see where emphasis needs to be placed.
       
      That is, you probably want to pay attention to those aspects of the application that are used 95% of the time by 85% of the users. Versus, for example, the obscure, infrequently needed admin screens for maintaining the list of states/provinces for each country.
       

      -- jon

      -----Original Message-----
      From: Larry Constantine [mailto:lconstantine@...]
      Sent: Saturday, July 31, 2004 5:49 PM
      To: agile-usability@yahoogroups.com
      Subject: RE: [agile-usability] Re: principles for UI architectures

      Jeff and Josh,

      I hate to jump on two such good friends and colleagues in one positing, but
      I think you both might have misunderstood something. First, an interaction
      context is not a metaphorical place, its an abstraction of a part of the
      user interface. That is, an interaction context is an abstract piece of the
      real user interface--such as a window, page, screen, or tab panel--with the
      particular realization left unspecified. There is nothing metaphorical about
      it.

      I agree with Josh that goal-directed design might be improved by a more
      explicit incorporation of interaction contexts, but personas, which model
      users rather than interfaces or parts of interfaces, are certainly not used
      in this manner by most people I know doing what they think is goal-directed
      design. Personas in GDD stand in for user roles in usage-centered design.
      User roles are just a different slicing-and-dicing of what we need to know
      about users.

      All that said, from an architectural standpoint, there is sometimes a fairly
      simple connection between personas and the target user interface
      architecture in that, if you are designing to multiple personas, you do want
      all the needs of each persona to be supported by a closely coupled
      collection of interaction contexts.

      Cheers friends,

      --Larry Constantine [mailto:lconstantine@...]
        Chief Scientist
        Constantine & Lockwood, Ltd.
        58 Kathleen Circle | Rowley, MA 01969
        tel: +1 978 948 5012 | fax: +1 978 948 5036 | www.foruse.com


      > -----Original Message-----
      > From: Joshua Seiden [mailto:joshseiden@...]
      > Sent: Saturday, 31 July 2004 7:18 AM
      > To: agile-usability@yahoogroups.com
      > Subject: RE: [agile-usability] Re: principles for UI architectures
      >
      >
      > > > I'm wondering if there
      > > > are some principles for UI architectures, similar
      > to
      > > > modularity in design, that facilitate the
      > evolutionary
      > > > development of the HLD parts, rather than requiring
      > a
      > > > "full scope" pass up front?
      > > > --->
      > > > This is an interesting notion that I haven't seen
      > mentioned before.
      > > > Anyone have any leads on this?
      > > >
      > > Here's what makes high level design more resilient
      > for me:
      > >
      > > I'm using C&L's Usage-Centered Design.  They describe
      > an interaction
      > > context.  An interaction context is a metaphoric
      > place you go to do
      > > similar tasks.
      >
      > Cooper's goal directed design system uses personas in
      > this manner. Interaction contexts, as you describe them
      > Jeff, don't exist as a named entity in this system, but
      > instead are implied by the notion of a primary persona.
      > GDD would be improved, I suspect, by stealing this
      > notion of interaction contexts.
      >
      > JS
      >
      >
      >
      >
      >
      >
      >
      > Yahoo! Groups Links
      >
      >
      >
      >




    • Phlip
      ... The term all roads lead to Rome doesn t just mean than roman civil engineers started from home. It anyone carting their goods from their little farm or
      Message 2 of 12 , Aug 1, 2004
        Paul Hodgetts wrote:

        > So, I'm wondering what would happen if we just did
        > the
        > interface work as required by the feature we're
        > working
        > on. Why can't we approach UI design like we do
        > evolutionary code design?

        The term "all roads lead to Rome" doesn't just mean
        than roman civil engineers started from home. It
        anyone carting their goods from their little farm or
        crafts shop, chosing the direction away from the
        barbarians, would eventually encounter a Roman tax
        collector.

        Agile processes sort features in order of business
        priority.

        A project must finish its primary set of features
        before working on a secondary set. For the first few
        iterations, only the primary ones get any design
        attention, coding attention, or tool support.
        Reviewing an iteration�s results assists adding new
        User Stories to the stack, and assists resorting the
        stack before the next iteration.

        Some Agile literature admits a diagnosis of nebulous
        or rapidly changing requirements indicates an Extreme
        Programming prescription. This sophistry appeases
        those with positive experiences converting relatively
        motionless requirements into planned designs before
        implementing them. But we don�t care if all the
        requirements are carved in granite.

        Source code supporting the primary features, written
        first, experiences the most test runs over its
        remaining lifetime.

        Finished primary usability designs assist specifying
        new secondary usability designs, so their details
        reinforce the primary features. All versions lead
        users to the features of highest business value.

        All roads lead to Rome.

        Refactors invest secondary features into the primary
        features� code, amplifying the testing pressure that
        constrains the primary features.

        Implementing features by business priority is a design
        technique.

        > Every once in a while, I found we got into a local
        > maxima
        > that needed a little extra work to break out of into
        > a
        > better larger-scale design, but because everything
        > was
        > clean and minimal already, even though there was a
        > little
        > flurry of extra work to adjust for the new
        > structure, it
        > went smoothly with little risk and impact to the
        > project.

        When tests drive development and make changes safe,
        the search for the set of features that maximizes
        users� productivity becomes a simple hill-climbing
        algorithm. The Customer always fearlessly picks the
        steepest slope from the current location. This
        simplifies requirements gathering. While nobody can
        agree on the details for low-priority features, the
        high-priority ones compel attention. Implementing
        those features teaches how to specify the lower value
        features, so they support the higher ones.

        To avoid rework, XP teams boost user productivity
        early and often. The Planning Game sorts User Stories
        in order by business value. This is a hill-climbing
        algorithm�a search for the maximum productivity boost
        from the current position. On hills without secondary
        peaks, the shortest path up is always the steepest
        path from each point. In the space of programming, a
        hill-climbing algorithm encounters no secondary peaks
        if all application features can deform continuously.
        Simple Design, Merciless Refactoring, and Test-Driven
        Development create designs that change smoothly and
        safely.


        =====
        Phlip
        http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



        __________________________________
        Do you Yahoo!?
        Yahoo! Mail - 50x more storage than other providers!
        http://promotions.yahoo.com/new_mail
      • Lynn Miller
        ... I ll just respond to a small part of your post. It likely depends on the type of product that you have, but with applications that people use as part of
        Message 3 of 12 , Aug 4, 2004
          >
          >
          >So, I'm wondering what would happen if we just did the
          >interface work as required by the feature we're working
          >on. Why can't we approach UI design like we do
          >evolutionary code design?
          >
          >What forces resist evolutionary interface design?
          >
          >
          >
          I'll just respond to a small part of your post.

          It likely depends on the type of product that you have, but with
          applications that people use as part of their core job (i.e. spending
          the majority of their workday using the app), changing the user
          interface significantly decreases productivity as users try to forget
          the old layout and learn the new. The outcry is usually terrific.

          We try to design for what is coming in the future so that we don't have
          to modify the interface drastically and make our current customers mad.

          If we designed for only this release then refactored the interface on
          the next release, we wouldn't have any customers left. I think that is
          the force that resists evolutionary design. :-)

          Lynn Miller
          Alias
        Your message has been successfully submitted and would be delivered to recipients shortly.