It is worse on a browser

1
It is worse on a browser
Niall Murphy
2
This lectures 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 application.
• Computer science students in the name of
  education (or 2 academic points).

3
Preview

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

4
Moving to computer applications

• Stepping backwards before moving forward.
• E.g. replacing the paper diary by a computer
  application.
• 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.

5
Advancing web programs

• The next step is advancing web based programming.
• 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 mentioned?

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

7
The dictionary evolution summary

• The traditional dictionary was good until
  computers arrived.
• 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 compensation?
• Answer - probably not. Most of the time we dont
  need associative links and updates are not
  relevant for dictionaries (the language is not
  changing).

8
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
  designers life easier (no need for input
  checking) therefore we can see them everywhere.
• The user cant 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 doesnt 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.

9
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 experience
• 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.

10
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 cant force actions to
  happen in a certain order.

11
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 amount.
• How much money did you deposit ?
• Conclusion If your application receives
  control commands from the user the result is
  unpredictable in some situations.

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

13
Moving to Java Applets
14
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.

15
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

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

17
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 configuration.
• 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 releases.

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

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

20
(cont.) Java appletAladin The

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

21
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
This table shows that the JVMs distribution is
very slow.

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

22
Using native codes

• A native code is a program which is compiled for
  a specific machine and OS, therefore
  incompatibilities cant occur in this process.
• Native code is written in any common programming
  language.
• Dedicated and mature widgets can be used in a
  native code.

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

24
Outlook express vs. Hotmail

• There are two popular ways to use the e-mail
  service.
• 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 ?

25
Hotmail snapshot
26
Outlook express snapshot
27
Outlook vs. Hotmail - conclusions

• Some usability issues
• Hotmails advantages
• Hotmails 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
  hotmails bad usability (The next two pages). The
  problem is derived from web design constraints
  (the lack of mature widgets).

28
(No Transcript)
29
(No Transcript)
30
The X-windows alternative

• Browser based programming is not the only way to
  maintain a remote graphical interface over the
  TCP/IP.
• 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.

31
(No Transcript)
32
X-windows drawbacks

• Apparently X-windows has some disadvantages
• The need for an interpreter on the displaying
  machine.
• 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 before).
• The major drawback is that it is not familiar
  with most users.

33
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 dont transfer much
  information across the wires.
• E.g. a VCR what we need to know is the current
  timing information. Lets say 20 bytes of
  information.
• The most basic web page contains 1Kb of
  information.
• Is this true ?

34
Embedded devices (cont.)
Size 997 Bytes

• A very basic controlling HTML page
• Html Example.htm

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

36
Embedded devices (cont.)

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

37
Where is the compiler?

• Although its 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.

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

39
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
  interface.
• The best human device interfaces were built
  without the web technology.

40
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 RD Books.
• Murphy's training and consulting business is
• based in Galway, Ireland.
• He welcomes feedback and can be reached at
  
• nmurphy_at_panelsoft.com.

41
The articles 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.

42

• Bibliography

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 www.embedded.com
www.itouchinc.com http//www.adass.org/adass/pr
oceedings/adass99/O7-04/O7-04.html The Aladin
Java Applet Experience. http//www-h.eng.cam.ac
.uk/help/tpl/graphics/X/X11R5/node3.html Overview
of X Windows. http//www-106.ibm.com/developerw
orks/usability/library/us-widget1/
http//www-106.ibm.com/developerworks/usability/li
brary/us-widget2/ Using web widgets wisely.
Interface Hall of Shame The Use of Color.