Usability for Graphical User Interfaces

Document Sample
Usability for Graphical User Interfaces Powered By Docstoc
					   It is worse on a browser

Niall Murphy                  1
    This lecture’s target audience

 Software developers who are
  struggling whether to
  develop an easy browser
  based application or a
  custom application.
 Software developers who
  have already decided to
  program a browser based
 Computer science students in
  the name of education (or 2
  academic points).
   A web program is always less usable:
    –   The need for a stable internet connection.
    –   Losing the shortcut keys.
    –   Using the HTML inferior widgets.
    –   Losing control over the program.
    –   The possibility to change performed actions.
    –   Caching unpredictable attributes.
   Using Java applets wisely can improve web usability.
   Alternatives to web design:
    – Native programs.
    – X-windows.
   Embedded systems and the web.
Moving to computer applications

   Stepping backwards before moving forward.
   E.g.– replacing the paper diary by a computer
    – Losing the ability to turn down the corner of the page.
      This ability may be replaced by a bookmark but it will
      never be the same.
    – Losing the ability to carry it with you.
    – Time lost for booting the computer.
   In order to encourage people to use the
    computer application the developer must add
    new extra attractive features.
      Advancing web programs
The next step is advancing web based
   This step causes usability loss:
    – The need for a stable internet connection.
    – Using the HTML inferior widgets (this point will be
       proven later).
   In many applications the development process contains
    two phases – moving to a computer application and
    then moving to a browser application.
   It is essential to distinguish between the reasons for bad
    usability. Is it due to the first or the second phase
Example – the dictionary evolution
The traditional dictionary (Oxford):
  – can be transported – no need for computers.
  – Very slow and irritating search.
The native dictionary (Babylon) :
  – Can be updated from the net.
  – The fastest of all three.
  – Supporting shortcut keys.
  – Can support few libraries together.
The web dictionary (Morfix)
   – No need for updates.
   – Gives associative links.
   – Needs an internet connection.
The dictionary evolution – summary

  The traditional dictionary was good until computers
  Most of computer users use Babylon because it has the
   best usability. The Shift + right click has made our life
   much easier.
  The second evolution phase is less usable than Babylon.
  Did the developers give us enough extra features for
  Answer - probably not. Most of the time we don’t need
   associative links and updates are not relevant for
   dictionaries (the language is not changing).

              Tricks and widgets
   The set of widgets available on a browser are limited in
    comparison to native ones.
   Pull down menus:
    – This widget is a good example because it make the designer’s life
      easier (no need for input checking) therefore we can see them
    – The user can’t differentiate whether it is a choice selection menu or
      an action menu.
   Special controls for a browser – hard to implement due to
    compatibility problems with different machines, while in
    native programs this problem doesn’t exists.
   Shortcut Keys make our life much easier, but are not
    available on a browser.
   Right click menus are also not available on a browser.

        Tricks and widgets (cont.)
E.g.– JAVA web style documentation vs. MSDN.
   Java documentation - Java documentation.lnk
   MSDN -MSDN Library - July 2001.lnk

Both documentations look the same, but after little
   – It is tiresome trying to find a class in the JAVA
     documentation using the list box widget but MSDN provides
     a better searching tool – using the first letters.
   – MSDN has a better unique menus as opposed to JAVA
     which has the standard explorer menus.
   – The java documentation may be reached through the net
     without downloading it completely while MSDN needs full
     installation.                                        9
Losing control over the program.

   There exists a problem for the programmer to
    control a web application:
    – The possibility to write an exact URL - the user
      can go directly to his desire link.
    – Unlike dedicated applications it is unable to gray
      out undesired links (or options).
   Therefore the designer can’t force actions to
    happen in a certain order.
     Changing performed actions
   Most browsers leave the current page available after
    performing an action.
   Therefore data changes can be made during a
    transmission process. The consequence is unpredictable.
   What will happened if you will try to deposit money in
    your account, and during the process you will change the
   How much money did you deposit ?
   Conclusion : If your application receives “control
    commands” from the user the result is unpredictable in
    some situations.

Caching unpredictable attributes.

   The forward and back buttons create some usability
    problems while raising some questions:
    – When clicking the back button - What is the current data ?
    – Did the programmer tag the page as an immediate expired
      page ?
    – Does our browser support expired pages techniques ?
   The main problem is that caching assumptions become
    unavoidable on the web.

Moving to Java Applets

    The Java applet concepts
 A Java program is compiled only once on the
  development machine.
 The executable code, called Byte-code, is
  downloadable and runnable directly by most
  current browsers.
 To run the Byte-code the browsers integrate a Java
  virtual machine, called JVM, which is able to
  execute the Byte-code.
 Consequently, the Java applets don't require any
  installation and all platforms supporting a Java
  enabled browser run them immediately.
     The four applet problems
   The Network Downloading Delay:
    – Each time a user wants to run an applet, its Byte-
      Code has to be downloaded through the network.
    – Therefore it is strongly recommended to limit its
      size to a few hundreds of kilobytes. So making use
      of additional packages is not recommended.
   The JVM Performances:
    – A good JVM implementation is generally 2 to 5
      times slower than the C equivalent code.
    – Newer JVMs have worse performance due to the
      more sophisticated features they support
The four applet problems (cont.)
   The Security Restrictions:
    – By default, Java applets cannot access the user
      “machine resources”.
    – The main consequences are: no local disk access, no
      printer access.
    – This problem is solved in the newer versions of JVMs
      with the new concept of the “secure applet'' but it is not
      easy to implement (Netscape and IExplorer have
      different standards).

The four applet problems (cont.)
   The JVM Incompatibilities:
    – The first incompatibility problem is regarding
      configurations. Combinations of different Java releases,
      hardware, operating systems and browsers.
    – If a bug is harmless on one configuration, it might jam
      another configuration. The only solution is to test each
    – The second incompatibility problem is about the Java
      machine itself: there exists five major Java releases.
    – So if an applet uses one package object of the last Java
      version, it will be incompatible with the previous Java
“Java applets – the optimal solution”
   Do java applets provide the ideal solution for the
     ”client side” program?
   Answer: Probably not due to:
    We are still in a browser restricted environment with
     inferior widgets.
    Incompatibilities between browsers and JVMs.

The Aladin Java Applet Experience
 Aladin is an interactive software sky atlas that allows
  the user to visualize digitized images of any part of the
  sky, to superimpose entries from astronomical catalogs
  or personal user data files.
 Aladin was developed by Centre de Données
  astronomiques de Strasbourg.
 Aladin is a good example for a program which has
  been upgraded from x-windows to java applet.

    Java appletAladin The (cont.)
 Aladin was first developed with X11 technology.
 There were 2 major disadvantages with this approach:
    – The installation cost required user availability and
    – The portability cost required engineer time and efforts.
   A decision was made to implement the Aladin user
    interface as a Java applet.

    Java applet – summeryAladin The
        Aladin applet was carefully design for most users.
         JVMs usage table (For year 2000) – when JVM 1.2 was already available

                                            Release   Packages   usage
        * This table shows that the JVMs’
                                             1.02        8        8%
        distribution is very slow.
                                             1.1.x      20       87%
                                             1.2.x      50        0%

 Aladin is 170kB large and avoids any additional package.
 Aladin doesn't integrate Java classes that are too sophisticated in
  order to ensure good performance.
 Aladin is Java 1.02 compatible and uses only the 8 main packages.
 Developing Java applets that can be executed by every Web
  user implies difficult choices from the developer's point of
  view.                                                          21
        Using native codes
 A native code is a program which is
  compiled for a specific machine and OS,
  therefore incompatibilities can’t occur in
  this process.
 Native code is written in any common
  programming language.
 Dedicated and mature widgets can be used
  in a native code.

        Native Codes drawbacks
   Drawback 1: Losing the mobility
    – This is the main disadvantage of native codes - a local
      installation is needed.
   Drawback 2: The need to provide interfaces for
    each OS.
    – The solution is using Java.
   Drawback 3: Synchronization.
    – The solution is to force version update if a mismatch
      is detected.
    – E.g. Norton antivirus checks periodically the server for
      updates.                                          23
 Outlook express vs. Hotmail
 There are two popular ways to use the e-mail
   – The Browser approach – Using mail web
      services like hotmail or yahoo.
   – The Native Code approach – Using a mail
      desktop application like Outlook or Udora.
 It is well known that most of the people will
  choose the second approach – but why ?

Hotmail snapshot

Outlook express snapshot

Outlook vs. Hotmail - conclusions
Some usability issues :
   Hotmail’s advantages:
    – Hotmail’s advantage is mobility. You can reach your e-mail
        account from any remote computer without special installation.
   Outlook express advantages:
    – The visual performance is much better. You can see all your
        e-mail accounts, mailing lists etc…(can be improved by hotmail
        by bettering the programming).
    –    All the information is accessible after disconnecting from the
        Internet. This attribute is due to the lack of mobility.
    –   Better performance on slow Internet connections.
    –   Better Menu performance – for example sorting the e-mails by
        several different methods (can be improved by hotmail but
        requires an effort).
    –   Adding an attachment is a very good example for hotmail’s bad
        usability (The next two pages). The problem is derived from web
        design constraints (the lack of mature widgets).                27
    The X-windows alternative

 Browser based programming is not the only way to
  maintain a remote graphical interface over the
 “X-Windows” and “photon” made this possible by
  allowing remote functions like drawline(),
  createManu() etc. The rendering will be performed
  somewhere else on the network.
 The difference is that the information is done by
  transferring call by call as opposed to the web server,
  where the whole page is being transferred as one unit.
       X-windows drawbacks
Apparently X-windows has some disadvantages:
 The need for an interpreter on the displaying
 The lack of a hypertext linking ability.
  But these drawbacks are not vital ones, if we want
  to control an embedded device.
  What we need is good variety and mature widgets,
  and not web constrained ones (as mentioned
   The major drawback is that it is not
    familiar with most users.
Embedded devices & the web
The X-windows solution is elegant and flexible but
  how many users will install it on their computer?
 Most of the embedded devices don’t transfer much
  information across the wires.
 E.g. a VCR – what we need to know is the current
  timing information. Let’s say 20 bytes of
 The most basic web page contains 1Kb of
 Is this true ?

    Embedded devices (cont.)
A very basic controlling HTML page
                                     Size = 997
Html Example.htm                       Bytes

   Embedded devices (cont.)
A better solution must be found…
 The simpler solution is to allow access to the data.
 The data can be transmitted over a socket using a
  simple application protocol which allows point to
  point communication of ASCII text.
 For a complex data we can use more sophisticated
  protocols like CORBA or RPC.

   Embedded devices (cont.)
Why do we need these complex protocols?
 It looks scary but the flexibility benefits are
 It can let us interact with the receiving data
  (which is very awkward using an HTML
  page ).

              Where is the compiler?
Although it’s not a usability issue, we
  should not forget the programmer
  (probably us…).
 A web page is actually a program
  which needs to be compiled (for
  missing links, syntax errors etc.).
  But there is no “web compiler”, so
  the programmer should test the
  program manually.
 In the windows application the
  compiler will “scream” about
  errors. Therefore bugs can be
  discovered earlier and with less
  efforts.                                37
    What have we learned today?
 Web programs are less usable than native ones.
 This issue is intensified when dealing with a
  device that needs to be controlled (especially
  embedded devices).
 Java applets can improve the web design
  constraints but raise compatibility issues.
 Two alternatives are represented:
    – X-windows – good but requires a special installation.
    – Native codes – the most popular solution, but loses
         The author opinion
 Web interface is more efficient when the user
  interface is fairly simple.
 When we face the need for a more sophisticated
  interface we should provide a native program
 The best human device interfaces were built without
  the web technology.

                Niall Marphy
• Writing software for user interfaces
  and medical systems for ten years.
• The author of "Murphy's Law“, a regular
  column in ESP and is also the author of Front
  Panel: Designing Software for Embedded User
  Interfaces, published by R&D Books.
• Murphy's training and consulting business is
  based in Galway, Ireland.
• He welcomes feedback and can be reached at                          40
            The article’s criticism

   The good things:
    – The topics are very actual and relevant.
    – Most of the time the articles are very precise and accurate.
   The bad things:
    – In the second article many arguments seem to be constrained.
    – The English is irritating (especially when getting to the
      technical details).
    – There were very few examples - like embedded devices etc.
    – The articles are written in a very dry and informative way. It
      does not excite the reader.
* Usability for Graphical User Interfaces (2001) by Niall Murphy
  Embedded Systems Programming
* It's Worse on a Browser (2001) By Niall Murphy
  Embedded Systems Programming
       The Aladin Java Applet Experience.
      Overview of X Windows.
       Using web widgets wisely.
* Interface Hall of Shame: The Use of Color.                  42

Shared By: