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

principles for UI architectures

Expand Messages
  • acockburn@aol.com
    In a message dated 7/30/2004 11:03:20 AM Mountain Daylight Time, agile-usability@yahoogroups.com writes: I m wondering if there are some principles for UI
    Message 1 of 12 , Jul 30, 2004
      In a message dated 7/30/2004 11:03:20 AM Mountain Daylight Time, agile-usability@yahoogroups.com writes:
      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?
       
      ==============================================
      Alistair Cockburn
       
    • Mike Kuniavsky
      ... Are you asking whether there are best practices for toplevel UI (and, presumably Information Architecture) development? If so, that s a holy grail that
      Message 2 of 12 , Jul 30, 2004
        On Fri, 30 Jul 2004 acockburn@... wrote:

        > In a message dated 7/30/2004 11:03:20 AM Mountain Daylight Time,
        > agile-usability@yahoogroups.com writes:
        > 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?

        Are you asking whether there are "best practices" for toplevel UI (and,
        presumably Information Architecture) development? If so, that's a holy
        grail that apart from some very low-level recommendations and some very
        high level recommendations I haven't seen too much compelling work on.
        The middle ground tends to be goal-specific and audience-specific, which
        makes it pretty resistant to generalization. Some people have tried
        making patterns, but--like the original Pattern Language for architecture
        and design--in my opinion they're more guidelines for how such a set of
        patterns could look like for a specific set of goals, rather than
        genuinely practical guides for anything I've worked on.

        --
        Mike Kuniavsky
        mikek@...
      • Ann Dillon
        I agree with Mike s holy grail comment, and would be very interested in anyones thoughts on the matter. ... (and, presumably Information Architecture)
        Message 3 of 12 , Jul 30, 2004
          I agree with Mike's 'holy grail' comment, and would be very
          interested in anyones' thoughts on the matter.


          > Are you asking whether there are "best practices" for toplevel UI
          (and, presumably Information Architecture) development? If so,
          that's a holy grail that apart from some very low-level
          recommendations and some very high level recommendations I haven't
          seen too much compelling work on.
          > --
          > Mike Kuniavsky
          > mikek@o...
        • Jeff Patton
          ... 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
          Message 4 of 12 , Jul 30, 2004
            --- In agile-usability@yahoogroups.com, acockburn@a... wrote:
            > In a message dated 7/30/2004 11:03:20 AM Mountain Daylight Time,
            > agile-usability@yahoogroups.com writes:
            > 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. Like your kitchen is a place you go to cook, store
            food, and wash babies in the sink. Software is arranged into
            interaction contexts. I can add support for tasks into an interaction
            context like adding furniture to a room. The contexts, the users
            they serve and the "kind" of tasks they support stays fairly
            consistent. Navigation from context to context stays consistent. Is
            that the sort of thing you're looking for?

            If you're reading this post from the YahooGroups site, you're looking
            at an interaction context. This post is in the center, and the tools
            are arranged around the outside of it - like furniture in a room.
            There's a buncha tools on the left side to do stuff with or about
            this list. There's some tools on the top of the message to do stuff
            with this message. The wireframe design of this interaction context
            is pretty resilient. If I need to do something else with a message -
            and need to add a feature to the software to support it, I can drop a
            tool in where the message manipulating tools go. I just noticed a
            tool there called "unwrap lines" - what does that mean? I know it's
            been added, since I started using Yahoo Groups - since it hadn't been
            there before. Since I'm a list moderator, different user role than
            you, I have more tools, like "delete message", and "ban author".

            An interaction context is pretty modular. Areas in that context are
            pretty modular as well. Cutting software up this way - and mirroring
            it in my code design helps. In Java, my top level panels exend a
            class called AbstractInteractionContext. Developers in my team know
            and understand this language, and arrange their code this way. It
            helps us.

            Hopefully I've understood the original post and Alistair's question...

            thanks,

            -Jeff
          • Phlip
            ... At the one end are people not realizing that common activities, such as jumping to the next field, should have common short cuts. At the other end are
            Message 5 of 12 , Jul 31, 2004
              --- Ann Dillon <Ann.Dillon@...> wrote:

              > I agree with Mike's 'holy grail' comment, and would
              > be very
              > interested in anyones' thoughts on the matter.

              At the one end are people not realizing that common
              activities, such as jumping to the next field, should
              have common short cuts.

              At the other end are people who can follow a Web page
              as a room, with furniture by the walls and an open
              area to work in the middle.

              And they are the same people. "Holy Grail" indeed...


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




              __________________________________
              Do you Yahoo!?
              New and Improved Yahoo! Mail - 100MB free storage!
              http://promotions.yahoo.com/new_mail
            • Joshua Seiden
              ... to ... evolutionary ... a ... mentioned before. ... an interaction ... place you go to do ... Cooper s goal directed design system uses personas in this
              Message 6 of 12 , Jul 31, 2004
                > > 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
              • Paul Hodgetts
                ... To ask this in a different way (sorry, this turned out longer than I thought it would when I started it)... I was originally very skeptical of evolving
                Message 7 of 12 , Jul 31, 2004
                  I originally pondered:

                  > 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?

                  To ask this in a different way (sorry, this turned out
                  longer than I thought it would when I started it)...

                  I was originally very skeptical of evolving architecture
                  via more local design decisions and refactoring. But I
                  found if I really, really paid attention to keeping the
                  smaller-scale design super clean and modular, kept a real
                  good eye out for when the design was moving towards
                  larger-scale patterns and mechanisms, and I was really
                  disciplined about cleaning things up right away, that it
                  just wasn't all that painful.

                  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.

                  I also found there were a few things that just seemed to
                  make sense to discuss early on. We needed to choose the
                  technologies we'd use, like Java, and that choice would
                  tend to suggest that certain larger-scale architectures
                  might be a good choice. So we'd discuss the overall
                  architecture in terms of things like the big system
                  layers, and the significant services (persistence, etc.)
                  and make some choices there. We tried to make it as
                  easy as we could to change these choices, but we often
                  didn't need to and some, like the language, would have
                  been very painful to change later on.

                  I worked with a team at a large county government for
                  about two years recently. This was an IT culture where
                  database development was very much a specialized realm,
                  and lots of database development was done up front. At
                  first I bought into the notion that if we didn't do a
                  good part of the data design up front across the "full
                  scope," we'd run into problems with performance and data
                  integrity and all the other bogey men that DBAs say are
                  lurking if we don't do the up front work.

                  But then the team chose to try a more small-scale,
                  evolutionary approach to database development. We began
                  only designing tables and relationships and constraints
                  and what have you as we needed them. We found we also
                  had to pay a lot of attention to some fundamentals of
                  good data design, like keys and basic normalization and
                  foreign key constraints and such. We had to learn how
                  to refactor the schema. But if we kept the data clean
                  and continually made sure on a small scale that we paid
                  attention to integrity and performance and the other
                  things, that we were able to grow the schema along with
                  the system.

                  Similarly, every once in a while we found that we had a
                  little flurry of work to break out of a local design in
                  order to improve the overall data design. For example,
                  we needed to do some higher-level normalization to clean
                  up relationships, or we needed to create a view or add
                  some joins or add an index to improve performance. But
                  because the data was clean at the small scale, these were
                  not painful and went smoothly. We even developed ways to
                  build migration scripts and procedures to pull off the
                  larger schema changes on production data.

                  So now I look at the user interface issue, and it seems
                  like there is a fear that if we don't do some up front
                  work across the "full scope" on things like the
                  interaction flow or whatever, that bad things will happen.
                  Maybe that's true. I don't know.

                  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?

                  From my experience, it seems that it's hard to refactor an
                  interface, especially when we're talking moving elements
                  from one page/screen to another, or changing the larger
                  navigation flow. Are there tools that facilitate this?
                  Most teams I've worked with don't seem to exploit UI IDEs
                  (maybe Dreamweaver?) the way they exploit coding IDEs
                  (like IDEA or Eclipse).

                  It seems like an interface has some elements, particularly
                  graphical elements, that require a lot of rework to change.
                  so If we change, say a major navigation bar on a web page,
                  it might take a bunch of work to generate the new one. I
                  have had some luck in delaying the addition of refinements
                  as long as possible, but at some point the UI needs to get
                  polished up for release to end users, and after that it
                  seems more rigid.

                  And then it seems like the overall usability depends on
                  the larger interface flows. Even if we make sure an
                  individual page/screen is usable, developing them one at a
                  time doesn't mean they will glue together well. But similar
                  to architecture, when we get the second page can we make
                  sure it glues together well with the first, and the third
                  flows well with the second, and make sure we always maintain
                  a good overall interaction flow as each new page is added?
                  This means the interface designers are more continuously
                  engaged in the project, rather than the practices I see a
                  lot of now where they swoop from project to project for
                  shorter periods of time doing the UI up front.

                  What kinds of things would we need to do to make sure the
                  smaller scale interface design (individual pages, screens,
                  dialogs, basic navigation) remained such that changing the
                  larger-scale interaction flows was not so painful?

                  One thing I think is to apply the same concepts about
                  removing duplication by using includes and controls and
                  things that are modular and can be moved around easily. I
                  see a lot of copy/paste interfaces, but I've also seen
                  really good interface developers that exploit technologies
                  in this area, like custom controls and tags.

                  Another is to use more easily changeable UI elements. It
                  seems a catch-22 when a lot of stakeholders demand fancier
                  interfaces with graphics and Flash and whatever, that tend
                  to be costly to rework.

                  I guess I'm rambling a bit here, but those are some of
                  the thoughts behind my original question. Any and all
                  thoughts and comments appreciated.

                  Paul
                  -----
                  Paul Hodgetts -- CEO, Principal Consultant
                  Agile Logic -- www.agilelogic.com
                  Consulting, Coaching, Training -- On-Site & Out-Sourced Development
                  Agile Processes/Lean/XP/Scrum -- Java/J2EE, C++, OOA/D, UI/IA, XML

                  Upcoming Presentations:

                  Agile Planning, Tracking, and Project Management Boot Camp
                  XP/Agile Universe Conference, Calgary, Alberta - August 15-18, 2004
                  http://www.xpuniverse.com/schedule/T12
                • Larry Constantine
                  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
                  Message 8 of 12 , Jul 31, 2004
                    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
                    >
                    >
                    >
                    >
                  • Jeff Patton
                    ... interaction ... of the ... piece of the ... with the ... metaphorical about ... I think we re in agreement - but my use of english may be a bit imprecise.
                    Message 9 of 12 , Aug 1, 2004
                      --- In agile-usability@yahoogroups.com, "Larry Constantine"
                      <lconstantine@f...> wrote:
                      > 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 think we're in agreement - but my use of english may be a bit
                      imprecise. When explaining it to others, I like them to think of the
                      house metaphor or a workbench metaphor - a physical place with
                      furniture or tools lined up to complete tasks. I like them to think
                      of navigation as the act of walking from room to room - and long
                      navigation paths as long hallways. In my original post, I use people
                      washing a baby in the kitchen sink to metaphorically hint that people
                      use software in ways unanticipated by its original designer. So,
                      while the interaction context may be an abstraction for part of the
                      user interface, I find using metaphor to describe it helpful. Then I
                      start getting lost in my own metaphor and mix up my terminology... ;-)

                      > 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.

                      There's where the physical place metaphor starts to work. If a
                      particular persona "walks into" a particular interaction context,
                      what information and tools would they see there? Personas share
                      contexts as people share rooms. In my kitchen are fridge, sink,
                      oven, and playskool little people zoo. The people using the kitchen
                      are me, my wife, and my 2 year old. We try to make it a friendly
                      place for all of them. I find that thinking of the user interace of
                      software the same way helps me design - and understanding the
                      difference between people and places - people being external to the
                      software places being the software itself - understanding that helps
                      me design software that stands up to change a little better.

                      The interaction context as the notion of a place wher tasks are
                      executed is a pretty helpful thing. I've seen lots of software
                      that's very task-centric - different context for each task. I've
                      seen lots of software that's unaware of the different kinds of people
                      interacting with it. I've seen lots of software that makes
                      navigation from one context to another more difficult than it should
                      be given the usage - akin to placing the master bath down the hall
                      from the master bedroom.

                      I digress - I mostly wanted to admit I'd use metaphoric wrong in my
                      original post - but defend and encourage the use of the term in
                      regards to the interaction context.

                      thanks for posting Larry!

                      -Jeff
                    • 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 10 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 11 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 12 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.