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

Version with Skins

Expand Messages
  • Phlip
    Agile-Usability: Sometimes two or more different user interfaces must cover the same Logic Layer. One common industry reason is versioning. Version 5, for
    Message 1 of 38 , Jul 14, 2004
    • 0 Attachment
      Agile-Usability:

      Sometimes two or more different user interfaces must
      cover the same Logic Layer. One common industry reason
      is versioning. Version 5, for example, will have many
      new features, and these deserve a re-designed user
      interface. Version 4, however, is still available for
      release, and V4 shares the older features in V5's
      Logic Layer. Customers suffering with V4 bugs should
      not be told, "Wait for V5. It will fix your bug, and
      it also has a new and improved user interface that
      looks completely different!"

      The least brave, and least wise, solution to this
      problem is to fork the entire code base, then mirror
      every bug fix between V4 and V5. Forking a code-base
      is duplication, like any other, and should be fixed
      while it's simple, before it drags down a team's
      productivity.

      As soon as the V4.1 user interface no longer "looks
      like" V4, duplicate only the GUI elements that are
      different. The program's "skin" will be a
      configuration setting. Methodologies that prevent GUI
      code from turning into spaghetti will support this
      "user view fork" very easily. Configure the test rig
      to exercise both versions simultaneously. Look up
      "Abstract Tests".

      Similarly, many projects release more than one
      application built out of a single core. The
      differences between each "flavor" of application could
      be as simple as tiered price/feature points-Personal,
      Standard, Premium, Enterprise Editions - or as complex
      as different user interfaces tuned to match different
      hardware assemblies. The Software Engineering
      Institute calls this topic "Software Product Lines";
      the GUI must also address it with skins. Tests must
      cover all skins and flavors when any of them change.

      While we know that we must always find ways to improve
      external appearances and responses, we must also
      appease our stakeholders that our applications, in all
      their aspects, have appearances and responses that
      closely match requirements and expectations. If your
      integration tests capture screen shots of all your
      windows with all their skins, you can upload these to
      a Web site for easy cross-reference.



      =====
      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
    • katharina9267
      Larry, This is without a doubt an issue that I came across in my experience as a usability manager. Do you suggest that this work should be done in iteration 0
      Message 38 of 38 , May 30 6:07 AM
      • 0 Attachment
        Larry,

        This is without a doubt an issue that I came across in my experience
        as a usability manager.

        Do you suggest that this work should be done in iteration 0 using the
        agile methodology? This seems to be increasingly a recommendation in
        a number of white papers and publications such as Scott Ambler.
        However, when you say 'minimal effort' how does this translate into
        time scales - is there an average that you work with in your
        experience let's say 1-2 weeks?

        I also appreciate, if you could forward the pdfs on the collaborative
        UI review method that you mentioned in a previous message.
        Many thanks,
        Katharina

        --- In agile-usability@yahoogroups.com, "Larry Constantine"
        <lconstantine@...> wrote:
        >
        > Jeff,
        >
        > An effective way around this problem is to draft a navigation
        architecture
        > (screen flow) in advance based on provisional understanding of user
        roles
        > and tasks in the application. This architecture gives a reasonably
        well
        > thought out framework on which to hang the features and functions
        as they
        > arise "organically." The navigation architecture is itself reviewed
        and
        > refactored as needed as the details of the application emerge. This
        approach
        > is what I describe as "architecture-first development" in the new
        Cutter
        > Report on agility and usability. It's proven to be a good
        compromise that
        > yields maximal payoff in maintaining a sound UI organization with
        bare
        > minimal upfront investment.
        >
        > --Larry Constantine
        > Chief Scientist | Constantine & Lockwood, Ltd.
        >
        >
        > -----Original Message-----
        > From: Jeff Grigg [mailto:jeffgrigg@...]
        > Sent: Tuesday, 13 July 2004 7:48 PM
        > To: agile-usability@yahoogroups.com
        > Subject: [agile-usability] incremental design -vs- overall user
        experience
        >
        > I can't claim to be an expert on user interface design or agile
        > methods, but here's a thought that's been bothering me for a while:
        >
        > It's been my experience that systems that "grow organically" over
        > time often have bad user interfaces. New features are often buried
        > deep within the existing user interface structure, making it hard
        to
        > find. New reports, for example, are added as buttons or menu
        > options deep in the work flow, where they're first needed, but
        *not*
        > made available from higher level menus.
        >
        > I've found that drawing screen flow diagrams of the overall system
        > illustrates these problems and guides redesign of the GUI to make
        > the system more usable.
        >
        > But...
        > How can one avoid this problem in "organically growing" systems?
        >
        > Does the "overall user experience" need to be planned up-front,
        even
        > when functionality is implemented incrementally?
        >
        > As project direction changes during implementation, what triggers
        > you to recognize that the user interface flow needs to be
        redesigned
        > to most effectively support the new business requirements you've
        > discovered?
        >
        >
        >
        >
        >
        >
        > Yahoo! Groups Links
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.