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

Re: [usage-centered] browser based application UI

Expand Messages
  • Thomas Nunes
    There is an interesting 3-part paper at http://www.uidesign.net that discusses how to architect the MVC design on the server-side for web-based applications.
    Message 1 of 5 , Sep 8, 2000
    • 0 Attachment
      There is an interesting 3-part paper at http://www.uidesign.net that
      discusses how to architect the MVC design on the server-side for web-based
      applications. It uses statecharts to model the interaction or navigation
      between pages, which I find to be an interesting approach. The first part
      starts at http://www.uidesign.net/1999/papers/webmvc_part1.html . The third
      part talks about some of the issue involved with complex web-based
      applications, such as managing the user's session, managing transactions,
      and handling issues such as exception handling, and unexpected navigation
      using the back button and bookmarks. It won't answer all the concerns
      you've expressed, but it may provide a good architecture to build from. Web
      applications are naturally more complex to build than informational web
      sites. But with the proper effort toward a sound architecture and design,
      they need not be fragile and difficult to maintain.

      I hope you find this helpful.

      Regards,

      Tom Nunes

      -----Original Message-----
      From: Jeff Patton <jeff621@...>
      To: usage-centered@egroups.com <usage-centered@egroups.com>
      Date: Friday, September 08, 2000 7:17 PM
      Subject: [usage-centered] browser based application UI


      >
      >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
      >
      >
      >
      >
      >
    • Jeff Patton
      Thanks for the response. This sounds exactly like some of the thought I ve been looking for - and the site looks like a great collection of additional
      Message 2 of 5 , Sep 11, 2000
      • 0 Attachment
        Thanks for the response. This sounds exactly like
        some of the thought I've been looking for - and the
        site looks like a great collection of additional
        information to boot.

        Thanks again,

        -Jeff


        --- Thomas Nunes <tnunes@...> wrote:
        > There is an interesting 3-part paper at
        > http://www.uidesign.net that
        > discusses how to architect the MVC design on the
        > server-side for web-based
        > applications. It uses statecharts to model the
        > interaction or navigation
        > between pages, which I find to be an interesting
        > approach. The first part
        > starts at
        >
        http://www.uidesign.net/1999/papers/webmvc_part1.html
        > . The third
        > part talks about some of the issue involved with
        > complex web-based
        > applications, such as managing the user's session,
        > managing transactions,
        > and handling issues such as exception handling, and
        > unexpected navigation
        > using the back button and bookmarks. It won't
        > answer all the concerns
        > you've expressed, but it may provide a good
        > architecture to build from. Web
        > applications are naturally more complex to build
        > than informational web
        > sites. But with the proper effort toward a sound
        > architecture and design,
        > they need not be fragile and difficult to maintain.
        >
        > I hope you find this helpful.
        >
        > Regards,
        >
        > Tom Nunes
        >
        > -----Original Message-----
        > From: Jeff Patton <jeff621@...>
        > To: usage-centered@egroups.com
        > <usage-centered@egroups.com>
        > Date: Friday, September 08, 2000 7:17 PM
        > Subject: [usage-centered] browser based application
        > UI
        >
        >
        > >
        > >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
        > >
        > >
        > >
        > >
        > >
        >
        >


        __________________________________________________
        Do You Yahoo!?
        Yahoo! Mail - Free email you can access from anywhere!
        http://mail.yahoo.com/
      • Jeff Patton
        Larry s comments are indisputably correct. Certainly there s no need for a browser based application to look and feel like one simply for the sake of it.
        Message 3 of 5 , Sep 11, 2000
        • 0 Attachment
          Larry's comments are indisputably correct. Certainly
          there's no need for a browser based application to
          look and feel like one simply for the sake of it.
          However your comments Hallvard do get at the meat of
          what I'm saying.

          By now there's a certain body of knowledge we can
          anticipate that users come to the computer with.
          Certainly that's gated by who the users are and the
          nature of the software, but in general with software
          built for frequent users we can expect understanding
          of some basic UI behavior - and even count on it. In
          a windows based application, I expect ctrl-c & ctrl-v
          to copy and paste. I expect file-save to be in the
          upper left hand corner of the UI.

          When I type a url into a browser I expect a certain
          bag of behavior as well. I certainly don't want to
          get reprimanded by the application for hitting the
          browser's "back" or "refresh" buttons as many
          applications pre-occupied with managing a stateful
          session tend to do. Nor do I have trouble
          understanding that if I don't "submit" the form I'm
          working on, I can't expect the data I've keyed in to
          have been transmitted back to the server. It's also
          been my experience that not excepting fundamental
          truths about browsers - like back buttons - can result
          in lots of delicate server-side code and/or client
          side code with hundreds of lines of embedded
          JavaScript to feign client-like behavior.

          I believe in _Software for Use_ there's some verbage
          on delivering software to users using their own
          language. The browser is fast becoming a tool used on
          a daily basis by millions of people for wildly
          different reasons. There's value in leveraging what
          users know about browser usage. Understanding browser
          usage is fast becoming part of the language of many
          disparate user communities.

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

          Focusing in on that comment, has anyone seen anything
          written regarding applications that suffer as a result
          of breaking users expectations - or alternatively
          applications which have succeed in spite of breaking
          accepted conventions within their deployment
          environment?

          Thanks both Larry and Hallvard for your valuable
          comments.

          -Jeff

          --- Hallvard Tratteberg <hal@...> wrote:
          >
          > -----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
          >
          >


          __________________________________________________
          Do You Yahoo!?
          Yahoo! Mail - Free email you can access from anywhere!
          http://mail.yahoo.com/
        • Larry Constantine
          Jeff, ... Yes, indeed, and we all must remember that we are the oddballs. The majority of users surfing with IE have no idea that you can ctrl-c & ctrl-v. For
          Message 4 of 5 , Sep 11, 2000
          • 0 Attachment
            Jeff,

            > Certainly that's gated by who the users are and the
            > nature of the software, but in general with software
            > built for frequent users we can expect understanding
            > of some basic UI behavior - and even count on it. In
            > a windows based application, I expect ctrl-c & ctrl-v
            > to copy and paste. I expect file-save to be in the
            > upper left hand corner of the UI.

            Yes, indeed, and we all must remember that we are the oddballs. The majority
            of users surfing with IE have no idea that you can ctrl-c & ctrl-v. For
            example, in a survey of customers of one B2C site, less than half knew that
            you could right-click with the mouse and nearly a third of those who knew
            "almost never" used the right mouse button.

            > I believe in _Software for Use_ there's some verbage
            > on delivering software to users using their own
            > language. The browser is fast becoming a tool used on
            > a daily basis by millions of people for wildly
            > different reasons. There's value in leveraging what
            > users know about browser usage. Understanding browser
            > usage is fast becoming part of the language of many
            > disparate user communities.

            The operant word is "leverage." You build upon past experience rather than
            become buried in it. Those millions learned to surf the Web; they were not
            born knowing how to use the back button. The trick is to make any added
            learning painless--both subtle and subliminal.

            --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
          • Nuno J. Nunes
            on 09/09/00 02:44, Thomas Nunes at tnunes@snet.net wrote: Thomas and Jeff ... We re organizing a workshop on that subject at the forthcoming UML 2000
            Message 5 of 5 , Sep 11, 2000
            • 0 Attachment
              on 09/09/00 02:44, Thomas Nunes at tnunes@... wrote:


              Thomas and Jeff

              > There is an interesting 3-part paper at http://www.uidesign.net that
              > discusses how to architect the MVC design on the server-side for web-based
              > applications. It uses statecharts to model the interaction or navigation
              > between pages, which I find to be an interesting approach. The first part
              > starts at http://www.uidesign.net/1999/papers/webmvc_part1.html . The third

              We're organizing a workshop on that subject at the forthcoming UML'2000
              conference. We hope to discuss a lot of related work regarding the use of
              the UML (and the different underlying diagrams) for interaction design.

              Take a look at some of the position papers that discuss that and other
              interesting subjects. URL at http://math.uma.pt/tupis00

              Nuno

              --
              Nuno Jardim Nunes
              University of Madeira - Teaching Assistant
              Mathematics Dep. - Computer Science Unit
              phone: +351 91 705160 (direct) 705150 (secretary)
              fax: +351 91 705199
              URL: http://math.uma.pt/njn/
              Address: Campus Universitário da Penteada
              9000 - Funchal - Portugal
            Your message has been successfully submitted and would be delivered to recipients shortly.