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

browser based application UI

Expand Messages
  • Jeff Patton
    Although it looks like this group may have become inactive, I ll drop a post here anyway to see if someone is listening. I m looking for resources –
    Message 1 of 4 , Sep 8, 2000
      Although it looks like this group may have become inactive, I'll drop
      a post here anyway to see if someone is listening.

      I'm looking for resources – articles, papers, discussion
      groups etc.. that discuss browser based application UI. By browser
      based applications, I don't mean websites, rather I mean a piece
      of software you'd normally expect to be a client-server app. One
      that handles transaction processing, reporting, decision support
      sorts of things – but just happens to be deployed through a
      browser using html and JavaScript.

      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.

      Not sure if I'm being clear here, and can provide some specific
      behavior examples if necessary. But, my real hope is that someone
      knows what I'm talking about and has seen some published
      discussion on this – and or can offer some personal anecdotal
      information.

      Thanks in advance,

      -Jeff
    • 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 2 of 4 , Sep 9, 2000
        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 3 of 4 , Sep 10, 2000
          -----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 4 of 4 , Sep 11, 2000
            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.