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

RE: [usage-centered] browser based application UI

Expand Messages
  • Larry Constantine
    Jeff, ... 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
    Message 1 of 4 , Sep 9, 2000
    • 0 Attachment
      Jeff,

      > In such an application I find that some designers/developers work
      > very hard to make the application behave like it's *not* running
      > under a browser. Creating lots of intelligent JavaScript client
      > side, doing lots of work server side to preserve state, using lots of
      > complex browser specific layout client side to more tightly control
      > the look and feel, etc.. It's my opinion that all this effort
      > not only makes the application time consuming to develop, delicate
      > and tough to maintain, but confuses users. The resulting app ends up
      > being somewhere between client server and a website type browser
      > app. The application isn't able to leverage what users may
      > already know about running a browser or a client server application.
      > We end up teaching them this new form of application behavior.

      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.

      In our work, we have gone both ways at times, depending on the needs of
      users.

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

      --Larry Constantine
      Director of Research & Development | Constantine & Lockwood, Ltd.
      58 Kathleen Circle | Rowley, MA 01969
      t: +1 978 948 5012 | f: +1 978 948 5036 | www.foruse.com
    • 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 2 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 3 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.