MultiDevices and Multiple User Interfaces: Usability and Engineering Trends and Challenges

1
Multi-Devices and Multiple User Interfaces
Usability and Engineering Trends and Challenges

• Ahmed Seffah
• Department of Computer Science
• Concordia University
• Seffah_at_cs.concordia.ca
• Workshop on Multiple User Interfaces over the
  Internet, HCI-IHM, Lille, France, September
  10-14, 2001
• http//www.cs.concordia.ca/faculty/seffah/ihm2001
  

2
Suppose your boss/customers asked you to

• Design a multi-device portal for
• Web UIs
• (e.g., HTML)
• Desktop UIs
• (e.g., Java, C, Visual Basic)
• Handheld UIs
• (e.g., WAP phones)
• Voice Uis
• Think about the coming multi-modal UIs
• (e.g., Voice GUI)

3
Suppose your boss/customers asked you to

• Must have
• Rich user experience
• Content from different Web servers and databases
• Support for international users
• You have one week!

4
Your headaches

• Training an armada of developers in
• 4 languages and development environments
• New versions and releases of 4 languages
• Maintaining 4 source code bases
• 4 different ways to describe UI
• 4 different ways to access data sources

5
Usability Issue Want to make UIs consistent for
each platform and across devices
6
Development issue Want to run N apps on M
devices without writing NM programs!
7
Development issue Want to run N apps on M
devices without writing NM programs!
8
Is there a substitute for all these languages?

• Use one high level language to create any UI for
  any device
• Write one UI description that magically adapts
  itself, at runtime, to any device
• Use an approriate design methodology and a
  multi-platform vocabulary to properly design a
  model of a multiple UIs, the model may be
  expressed in one notation.

9
The case of UIML Device-independent markup

• There are so many syntaxes for UIs!
• Java
• JButton jb new JButton(Go)
• HTML
• ltINPUT TYPE BUTTON NAMEjb VALUEGo!gt
• XForms
• ltbuttongtltcaptiongtGolt/captiongtlt/buttongt
• UIML uses one syntax for every UI language
• ltpart namejb classButton/gtltproperty
  namecontentgtGo!lt/propertygt

10
The case of UIML device-independent markup

• UIML ltpeersgt Maps Button to Java versus HTML
• ltd-class name"Button" maps-to"javax.swing.JBut
  ton"gt
• lt/d-classgt
• Versus
• ltd-class name"Button" maps-tohtmlinput"gt
• lt/d-classgt
• This stuff is written once, like a device driver
  for an OS.
• Events and calls to outside world handled
  similarly.

11
The case of Java Swing pluggable look and peel

• To be portable across look-and-feel standards, a
  Swing application does not hard-code its widgets
  for a particular look and feel
• PLF is the portion of a Swing component's deals
  with its appearance (or look), as distinguished
  from its event-handling mechanism (its feel).
• When you run a Swing program, it can set its own
  default look by simply calling a UIManager method
  named setLookAndFeel()
• UIManager.setLookAndFeel("com.sun.java.swing.plaf.
  motif.MotifLookAndFeel")

12
The case of Java Swing pluggable look and feel

• Look and feel already available
• Windows 2000/NT
• Java
• Macintosh
• Unix
• PalmOS
• Windows CE

13
A MUI is more than a multi-device user interface

• Web UIs
• (e.g., HTML)
• Desktop UIs
• (e.g., Java, C, Visual Basic)
• Handheld UIs
• (e.g., WAP phones)
• Voice Uis
• Multi-modal UIs
• (e.g., Voice GUI)

14
A MUI is more than a multi-device user interface

• Abstraction - All information should be the same
  across interfaces, even if not all information is
  shown for all views, computer and devices.
• E.g. a product listing may include only the
  best-selling items on a small narrowly device
  with the rest relegated to a secondary "more
  products" page.

15
A MUI is more than a multi-device user interface

• Cross-Platforms Consistency - All user preference
  must be preserved across the interfaces.
• E.g., if the end-user uses one access mechanism
  today and another tomorrow, then the changes I
  made in one user interface are reflected in what
  I see in the other.

16
A MUI is more than a multi-device user interface

• Uniformity - Same functionality and feedback even
  if certain special features or variations are
  eliminated in some versions
• E.g. an airline reservation system may make
  choosing a flight and buying the ticket in two
  separate steps. This separation should be
  preserved in all versions instead of having the
  simplified version unify choosing and buying into
  a single step.

17
A MUI is more than a multi-device user interface

• User Awareness of Trade-Off - It would be OK to
  have an advanced version including additional
  features (such as specifying a seating
  preference) that were not in the simplified
  version
• Missing these features is a trade-off that the
  user would make in return for the benefits of
  being able to use the system under various
  limited circumstances.

18
A MUI is more than a multi-device user interface

• Conformity to Defaults Standards - It is not
  necessary for all features to be found in all
  access mechanisms.
• E.g. a low-end version may eliminate photos or it
  may show them in black-and-white. Similarly, text
  may be abbreviated on a small display, though it
  should be possible to retrieve the full text
  through a standardized command.