CS349 - Implementing User Interfaces - Spring 2010

Public Service Annoucements

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

Lecture 20 - Constructing an Interface from Components

Making an Interface out of Components (in Java)

Start with a container widget

• frame, window

Add components 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.
• 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 Components

Trend is to abstract components, which encapsulate affordances independently of presentation.

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 component, try identifying

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

Look-and-feel: layout

Your program puts components into the interface. What can it specify?

• location
• size

These create geometric patterns, with which users have strong associations. How do you get this right?

• graphic design
  • deals with higher level concepts, like alignment, negative space, colour relationships, etc.
• tools like layout managers

The twenty-first century has provided surprises

• fifteen years ago everything seemed to be converging on a high-definition television display with keyboard and mouse.
• Suddenly there is a new display size and resolution and resolution every month
  Suddenly there is a new input configuration/device every month

Layout was supposed to be the solution

Look-and-feel: customizing components

Customization of component sets is common, especially on major UI projects.

• The usual rule of thumb,
  • `enough', but not `too much', (Albert Einstein famously said, `Make it as simple as possible, but not simpler.' This always appears in quotations; I have never encountered the original. Thus, I am not sure what `it' originally referred to.)

  is not very useful for making practical decisions. On the other hand, it does seem to work pretty well for deciding whether somebody else's work is good or bad.

• Practical questions that need to be asked
  1. What presentation should be a component have?
     • the component's appearance
  2. What affordances should a component have?
     • the component's behaviour

When you are going through this process you are designing a new - or modified - look-and-feel for your interface.

• Why is it sometimes a good thing to give an interface a unique look-and-feel?
• Why is it sometimes a bad thing to give an interface a unique look-and-feel?

(Hints. 1. `Unique' is put in here as a deliberately bad descriptor. 2. The answer should prominentaly include the word `gratuitous'.)

Three questions must be answered.

1. Who does the customization?
2. What is the context of customization?
3. What is the mechanism of customization?

Who does the customization?

User

Interface programmer

Platform on which the interface runs

What is the context of customization?

These questions get answered in a variety of contexts. Each context may provide some customization, and there may be conflicts between the needs of different contexts

1. component-specific
   • What role does this instance of this component perform in the interface? Is the role
     • the same as other instances of the same component type?
     • different from other instances of the component type?

     For example,

     • e.g. Should the trigger be button press or button release?
   • What is the component's environment?
     • e.g. What foreground/background colour is needed to make the component conspicuous, but not too conspicuous?
2. container-wide
   • What should components occupying the same container have in common? How should they differ?
   • It's important to make components cohere visually.
     • But a strong container will hold together components that would otherwise fall apart.
     • What makes a container strong?
   • e.g. A dialogue box that pops up needs to tell the user which application it belongs to.
3. document-wide
   • Document-wide customization is usually accomplished by indirection
     • Components can be named. e.g. `First level Heading'

       All comonents with the same name receive the same customization. e.g. 16 point Bold.

   • It is common to make these customizations available to the user
     • or only to an uber-user

     in the form of style sheets or document preferences

     • e.g., Graphics context often appears pretty baldly in form dialogues that manipulate style sheets.
   • Customization mechanism may be deliberately hard for the user to find
     • Why?
     • Hint. Defaults are more important than most users think.
4. application-wide
   • preferences manage resource files
   • often mysterious to the user
     • The same interface presentations and affordances appear,
     • but their scope is different
5. system-wide
   • preferences manage resource files
   • pre-set contexts programmed using
     • environment variables
     • resource files

     or a combination

   • By the time we get to this level, users rely comprehensively on defaults
6. manufacturer-wide
   • hard-coded - product identity
   • strong marketing issues
   • counter-intuitively, incompetence can outsell competence
     • e.g., non-standard MIME encodings
7. country-wide
   • reflect language and culture
   • preferences
     • often expressed at time of purchase

     set environment variables

     • set at boot time
     • automatic use of geography has not been very successful

     which select resource files

The country-wide context experienced a very large amount of research and attempted innovation during the 1990s. The issue was `internationalization': how do you make an interface that works for groups of peole who come to it from different languages, cultures and political systems. It is now called `localization' and appears screwed up almost everywhere.

Sometimes there are contradictions and inconsistencies

• How do they get sorted out?

If the contexts form a hierarchy?

• scope
• Note. Users must learn and understand the scope concept.

  Many already do because `scope' is a very widely used concept in organizing competing sets of rules.

If the contexts don't form a hierarchy?

• then what?
• Presumably, something like multiple inheritance (dread phrase), with rules that users must comprehend.

There are two conditions that any successful solution must obey.

1. Understandable to the user.
2. Understandable to the programmer.

Two options for implementing this in practice

1. initialization files, at the mercy of a set of rules for finding them,
2. resource forks, at the mercy of update operations.

There is, at present, no acknowledged solution for this problem. There are two practical approaches

1. Open systems (Apple -> Sun)
   • Internationalization is a real problem. Innovate to solve it.
2. My way or the highway (Stone age IBM -> Microsoft)

   Solution by fiat, IBM: `Let them learn EBCDIC', Microsoft: `Let them learn English.' E.g.,

   • Declare date standards.
   • Publish dictionaries

What is the mechanism of customization?

Resources

History

1. Environment variables
2. .rc files
3. Resource forks
4. Resource files: special names, special places

How do they work in practice

• Programming system establishes a hierarchy of special file names
• Run-time system and component implementations look through the hierarchy and choose the first specification they come to.

An Example of Customization - Colour

Cultural meanings of colour

Different cultures assign different meanings to the same colour.

• Red in Chinese culture versus red in Western culture.
• Green in Islam is assoiated with Paradise - the other world in its perfected form;
  Green in western society is associated with Nature - this world in its perfected form.

Even lack of colour means different things in different cultures.

• The aesthetic revolution produced by Pater and Ruskin in the early nineteenth century.

Basic science of colour - Berlin and Kay

• an anthropological investigation done in the 1960s.

  Curiously, this research has provoked enduring controversy in anthropology, but is pretty well universally accepted - at least in its mian thesis - in colour psychophysics. (The arguments of the anthrologists often look to the psychophysicist like `two bald man fighting over a comb', a phrase coined by Borges to describe the war between Argentina and the United Kingdom over the Malvinas.)

• For Berlin and Kay the argument is one from language to culture, which is probably why the result is so controversial. You ask the question: how many colour terms exist in the language used by a particular culture, and you get the following result.
  1. Doesn't make sense.
  2. The colour terms are `black' and `white'.
  3. The colour terms are `black', `white', and `red'.
  4. The colour term `grue' is added.
  5. Either `yellow' or `blue' is added.
  6. The colour terms are `black', `white', `red', `green', `yellow' and `blue'. This collection of terms is very significant to the colour psychophysicist because they emerge very naturally from the opponent colours model of colour perception, a model that is - almost - universally believed in the colour psychophysics community.

  Berlin and Kay went on to mention a collection of other colour names, which they also found to be relatively culture independent: `grey', `orange', `purple', `brown', and `pink'.

• Psychophysical research has turned up this same set of colour names in a variety of cross-cultural contexts.
• Language learning experiments has turned up this same sequence of colour names in early childhood language learning.

Summary

Having read this, what do you know about using colour in an internationalized interface?

Specific meanings associated with colour need to be changed from culture to culture. Possibly overall graphic design as well.

Return to:

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