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

RE: [usage-centered] browser based application UI

Expand Messages
  • Hallvard Tratteberg
    ... While I agree that you should always start with a task model, this will only cover higher level interaction. Adaption to a particular interaction style and
    Message 1 of 4 , Sep 10, 2000
    • 0 Attachment
      -----Original Message-----
      >From: Larry Constantine [mailto:lConstantine@...]
      >The real issue is not whether it looks and works like a web-page in a
      >browser or like an application with the browser as thin client. The
      >important thing is whether it best supports the work that users need to
      >accomplish. There are web-based applications that demand departure from web
      >conventions for efficient task support.

      While I agree that you should always start with a task model, this will only
      cover higher level interaction. Adaption to a particular interaction style
      and platform, like web-interaction through a browser, requires getting many
      details right. Implementing direct manipulation is impossible in a
      web-browser, and while the browser/server model fits the forms based
      interaction style pretty well, it cannot always be made to look & feel like
      a standard database application. And if there is a mismatch between the
      users' expectations and the real rules of interaction, the interface will be
      a lot less usable, even though it is based on a sound task model.

      >Another issue is the target audience and usage context. An application used
      >by a captive intranet or extranet audience has greater latitude than a B2C
      >e-commerce site. However, even there, the rules keep changing, and visitors
      >are becoming accustomed to embedded Java applets, pop-up tools, etc.

      The browser is increasingly being used for "real" applications, by gradually
      mixing in new technology for making the browser more responsive (without
      going through the server) and slowly extending what is expected from
      interaction through browsers. Nevertheless, I believe one should be very
      careful not to overload a web-application with interaction from other
      styles, and perhaps use Java (which in this discussion is just another
      standard GUI implementation platform) for the whole application.

      >The best way in practice is always to design it right from a task-support
      >perspective, then adapt it to implementation context, compromising only
      >where necessary and acceptable.

      Again, as a general rule I agree with this, but at some point in detailing
      the user interface the interaction style mandated by the platform takes
      becomes more important than the task model in defining the interaction. At
      that point other rules apply, which are not covered by the task/usage-based
      approach.

      Hallvard Tratteberg, stipendiat ved IDI, NTNU
      http://www.idi.ntnu.no/~hal, mailto:hal@..., phone:+47 7359 3443
    • Larry Constantine
      Halvard, ... Indeed, the devil dwells in the details, which is why we model tasks with essential use cases. These give us a much finer-grained picture of user
      Message 2 of 4 , Sep 11, 2000
      • 0 Attachment
        Halvard,

        > While I agree that you should always start with a task model,
        > this will only
        > cover higher level interaction. Adaption to a particular interaction style
        > and platform, like web-interaction through a browser, requires
        > getting many
        > details right. Implementing direct manipulation is impossible in a
        > web-browser, and while the browser/server model fits the forms based
        > interaction style pretty well, it cannot always be made to look &
        > feel like
        > a standard database application. And if there is a mismatch between the
        > users' expectations and the real rules of interaction, the
        > interface will be
        > a lot less usable, even though it is based on a sound task model.

        Indeed, the devil dwells in the details, which is why we model tasks with
        essential use cases. These give us a much finer-grained picture of user
        intentions and expectations.

        I would argue that for all new systems there must always, by definition, be
        a certain tension between user expectations and the interaction
        design--otherwise we would still be replicating command-line and
        green-screen interfaces on the desktop and on the Web. The legacy of user
        expectations must be understood and respected but not be allowed to become a
        tyranny. Again and again, we have found that non-standard but genuinely
        superior (more usable and task-centered)designs are be accepted by users if
        the payoff outweighs the departure from norms. The payoff comes from a close
        fit with the real task structure. And, there are techniques--visual
        affordance, instructive interaction, and the like--that make the unexpected
        easily understood.

        > Again, as a general rule I agree with this, but at some point in detailing
        > the user interface the interaction style mandated by the platform takes
        > becomes more important than the task model in defining the interaction. At
        > that point other rules apply, which are not covered by the
        > task/usage-based
        > approach.

        But, as you stated earlier, things are changing, and that includes the
        interaction style mandated by the platform. The Web and the desktop have
        been on a collision course for years, and the differences will continue to
        diminish as more and more desktop idioms appear on the Web and as Web-like
        presentation perfuses other software.

        --Larry Constantine
        Director of Research & Development | Constantine & Lockwood, Ltd.
        58 Kathleen Circle | Rowley, MA 01969
        t: 978 948 5012 | f: 978 948 5036 | www.foruse.com
      Your message has been successfully submitted and would be delivered to recipients shortly.