CS349 - Implementing User Interfaces - Spring 2010

Public Service Annoucements

1. Mid-term: 17 June, 2010, MC4059.

Lecture 19 - Sets of Components

Look-and-Feel

Look

Important aspects of look

• Overall composition
  • Gestalt principles
    1. Contiguity
    2. Completion
    3. Containment
    4. Common fate
    5. Colour
• Text styles and fonts
• Use of negative space
• Alignment

Feel

What do we want in the feel of something?

• predictability, so we can learn muscle activitation sequences
  • timed to 1 millisecond precision
  • predictability is essential for transferring stuff to lower levels of control
• low level feedback (mostly muscle stretch receptor feedback)
  • probably the most important level of monitoring and control
• fit with user abilities and capabilities
  • It's obvious, but easy to overlook, that users have windows in their sensory and motor capabilities, and they need the demands and information content of a task to be within these windows of capability.

Note. Most look is programmable/customizable, but the same code is not guaranteed to have the same look on different platforms. Even more so the programmable portion of feel is not guaranteed to be the same on different platforms. (The Macintosh interface, which cares more about this than any other, handles this problem by running only on one particular set of - often over-priced - hardware. The obvious generalization for this practice would be standards for hardware. Research topic. Develop ways of having reproducible feel in instances of a user interface running on different hardware configurations.)

Creating a uniform look-and-feel

1. UI architect
   • trusted by implementers
   • has absolute power
   • Apple did this by making its UI people into industry super-stars
     • (Part of the result was generally execrable implementation.)
2. User interface toolkit
   • appeal to lower nature of implementers
3. Widely understood metaphor
   • appeal to higher nature of implementers

Note. It is possible to appeal simultaneously to the higher and lower nature of implementers.

User Interface Toolkits - A history

What we're usually talking about when discussing `look-and-feel'.

Here's the problem.

• You are (Apple) introducing a new computer/OS.
• People will buy it only if they have applications they can use easily.
• Having decided from a business point of view that there's no money in applications, you want lots of `other people' to create lots of applications.
• You want all the applications to `go with' your new OS concept.

How do you arrange for this?

1. Model for inter-application cut-and-paste. (Clipboard, scrapbook).
2. Common look-and-feel, which means using a common set of rules and operations.
   • Model applications
   • User interface guidelines
   • User interface university
   • Movie star interface designers
     • which, of course, created a whole generation of wanna-be interface designers
   • User interface toolkit

In Apple's case the toolkit, at first, was just added ad hoc to the graphics model.

• but with very large amounts of user testing

Note. In Apple's case most of the real benefits came from a restricted `palette'.

X, on the other hand, was done by a bunch of professors and grad students.

• funded by Digital Equipment Corporation - subsequently taken over by Compaq.

A new thesis topic, or more likely, grant application -

• encapsulate bundles of Xlib atoms into molecules of higher level functionality
  • buttons
  • menus
  • dialogue boxes
  • text fields
• use callbacks to produce a new programming style
• the atoms of functionality were called `widgets'.

Basic motive not commercial, so little attention to look-and-feel, which are for suits (marketers).

• every look in creation - almost all abominable.
• feel didn't yet exist.

NeWS went for a Spartan look,

• the look that is most likely to be platform-independent

and much better feel,

• and lost the battle for `mind-share'.
• Hmmm.

Widget Sets

Essential properties of widget sets.

• Complete. An application designer should never need anything that isn't in the set.
• Consistent. They should share both look and feel.
• Customizable. Enough but not too much.

Making an Interface out of widgets (in Java)

Start with a container widget

• frame, window

Add comopnents one by one, using the container's add method.

• Where do they go? The order in which they are added determines where. Layout also plays a role.
• What size should they be? Layout managers generally pay attention to preferred size, and ignore your attempts to give them a specific size.
  • The null layout manager gives you the most control, and it's usually the way that programmers start using Swing. But the control that programmers want is too much control.
  • Think about what is done wrong on almost every corporate web site. The first thing that the html masters tell you is to use html that is as basic as possible. Code your meaning in elements of the design that are platform-independent.
  • Forward links.
    1. Layout is an extremely important topic, to which we will return.
    2. Platform-dependent look-and-feel is something that Java takes seriously - see next lecture - which is good, but without really providing a concrete solution, which is unfortunate. (`Unfortunate', not `bad', because it's a really hard problem without a good solution, as of 2010. It's been around for more than two decades in one form or another.).
• If you have customized a component you may need to provide it with a paint method.

Components that get events get them through Listener interfaces

• Implement the interface.
• Use the appropriate addListener method to activate the listener.
• Which components get which events
  • Listener needed.
  • Area test for user events.
  • Events percolate up the add tree until they find an appropriate Listener.

Components can communicate in two ways

1. Some components create events, which can be listened for in other widgets.
2. Components can call each other's methods.

The important structure of a Java interface is the structure that determines the flow of information from the user to the presentation. Inter-component communication controls the flow of information.

Call the show method of the highest level container to complete the initialization

• events begin to roll in, but only after the user has been prompted for them.
• show calls the show methods of all added components automatically.

Occasionally you want to change the appearance of a component in response to an event

1. Change the paint method.
2. Call paint, repaint or update.
   • The latter two call paint methods of all widgets in the container on which they are called.
   • Neglected painting is a mortal sin; excessive painting is a venal sin.

Typical widgets

From Java AWT

• canvas
  • implements the methods of the graphics model
  • components: label (text only), active: canvas (safer to draw on a canvas, than to draw directly on a container. Why? Layout manager knows about it.)
  • containers: window(no window manager controls), frame(window manager controls)
    • What does the presence or absence of window manager controls signify?
• dialogue - more specific meaning than `dialogue', as used above
  • obtains textual information from the user
  • modal: file dialogue
  • non-modal: form to be filled in
  • What is the essential difference?
• selectors
  • list - multiple selection possible
  • menu - only single selection possible
  • What is the essential difference? (Hint. It has to do with the trigger.)
• two state selectors
  • button - command
  • checkbox - state
  • What is the essential difference?
• scrollbar
  • thumb, arrows, background areas
• text input
  • text field
  • text area
  • Each one includes `complete' editor functionality. Editors actually occur all over a user interface. There's a big benefit to the user if they all are all instances of one editor. (Exercise for the reader. Compare and contrast, different methods of customization of editors - across widgets, across applications, across widget sets - as done by the operating system, by the interface programmer, by the user.)

As a self-test, to see if you are getting the essence of each widget, try identifying

1. Aspects of the widget that implement the parts of a dialogue,
2. Aspects of the widget that implement Olsen's presentation components.

Return to:

• CS349 - Spring 2010 - Lecture schedule
• CS349 - Spring 2010
• CS349 page
• Bill Cowan's home page.