cs349 - s10 - Lecture 20
CS349 - Implementing User Interfaces - Spring 2010
Public Service Annoucements
- 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
Add components one by one, using the container's
- 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
Components that get events get them through
- Implement the interface.
- Use the appropriate
addListener method to activate the
- Which components get which events
- Listener needed.
- Area test for user events.
- Events percolate up the add tree until they find an appropriate
Components can communicate in two ways
- Some components create events, which can be listened for in other
- 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.
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
show calls the
show methods of all added
Occasionally you want to change the appearance of a component in response
to an event
- Change the
- 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
Trend is to abstract components, which encapsulate affordances
independently of presentation.
From Java AWT
- 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
- What does the presence or absence of window manager controls
- 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?
- list - multiple selection possible
- menu - only single selection possible
- What is the essential difference? (Hint. It has to do with the
- two state selectors
- button - command
- checkbox - state
- What is the essential difference?
- 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,
- Aspects of the component that implement the parts of a dialogue,
- Aspects of the component that implement Olsen's presentation
Your program puts components into the interface. What can it specify?
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
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
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
- Why is it sometimes a bad thing to give an interface a unique
(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.
- Who does the customization?
- What is the context of customization?
- What is the mechanism of customization?
Who does the customization?
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
- 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?
- 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?
- 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.
- preferences manage resource files
- often mysterious to the user
- The same interface presentations and affordances appear,
- but their scope is different
- 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
- hard-coded - product identity
- strong marketing issues
- counter-intuitively, incompetence can outsell competence
- e.g., non-standard MIME encodings
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?
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.
- Understandable to the user.
- Understandable to the programmer.
Two options for implementing this in practice
- initialization files, at the mercy of a set of rules for finding
- resource forks, at the mercy of update operations.
There is, at present, no acknowledged solution for this problem. There are
two practical approaches
- Open systems (Apple -> Sun)
- Internationalization is a real problem. Innovate to solve it.
- My way or the highway (Stone age IBM -> Microsoft)
Solution by fiat, IBM: `Let them learn EBCDIC', Microsoft: `Let them
learn English.' E.g.,
What is the mechanism of customization?
- Environment variables
- .rc files
- Resource forks
- 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
Green in western society is associated with Nature - this world in its
Even lack of colour means different things in different cultures.
- The aesthetic revolution produced by Pater and Ruskin in the early
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.
- Doesn't make sense.
- The colour terms are `black' and `white'.
- The colour terms are `black', `white', and `red'.
- The colour term `grue' is added.
- Either `yellow' or `blue' is added.
- 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.
Having read this, what do you know about using colour in an
Specific meanings associated with colour need to be changed from culture
to culture. Possibly overall graphic design as well.