# Chapter 6 -

`Look and Feel' Part 1 - Toolkits for Application Programs

#### Introduction

Up to now we have been describing the mechanisms that X provides to the system builder, but not how these mechanisms are put together to build graplucal user interfaces. In this chapter we look at how a consistent user interface is provided in X; unlike other window systems, this part of the system is handled entirely within the client, usually using toolkits. We also look at some standard interfaces that have evolved.

## 6.1 `Look and feel' means how the user sees the system

The visual appearance of an application, and how the user interface behaves and how the user has to interact with it, comprise the application's look and feel. Different user interface systems provide different look and feels.

The `look' of a program is its visual appearance - how the various controls are laid out, what the components such as menus, scrollbars, buttons and so on look like, and the overall style.

The `feel' of a program is how it behaves - how the scrollbars operate (can you drag them with the mouse, what happens when you click in certain areas with the left mouse button, with the right?), whether you can `press' pushbuttons by hitting the keyboard's space-bar or return key instead of clicking with the mouse, etc.

It is the combination of the look and the feel that makes up the overall user interface. It is not only windowed computer programs that have a look and feel: other programs, especially DOS PC applications such as spreadsheets or word-processing packages, have their own recognizable and distinctive look and feel. [Footnote: The distinctiveness of a system's look and feel is the basis for the recent vogue of lawsuits alleging infringement of copyright or other intellectual property rights.] Computer keyboards have a look and feel. Keys are labelled `QWERTY. . . ' along the top row, `ASDFGH. . . ' along the middle row, etc., and that is the look; when you press the key marked F, say, you get the character `f' printed, and that is the feel.

Even the controls of a motor car have a look and feel: the look for a car with manual transmission is shown schematically in Figure A. This is quite a good example of why you want look and feel to remain consistent even in products from different manufacturers, and how nasty it can be if they don't. For instance, you expect that a car's accelerator (gas) pedal is on the right, and the brake pedal is to its left. What would happen if Volkswagen used that convention, but Ford decided to use the opposite? How easy would it be to drive a car of the other type - a car which has the same look (two pedals) but a different feel (the pedals have opposite `meanings')?

So, while look and feel is a general term, it is increasingly used to mean consistent appearance and style of operation. In the next module we list what we require of look and feel for applications.

###### Figure A. The `look' of motor car controls.

### 6.1.1 Look and feel requirements

Users are now demanding standard, consistent interfaces, to make applications easier to use and easier to learn.

What we want from the look and feel of an application is

- Consistency of appearance, for example, scrollbars should look the same in all the programs you use. It ought to be obvious that some component is a scrollbar just by looking at it, even if you have never used this particular application before. Similarly, the function of other user interface components ought to be obvious from their appearance.
- Consistency of behaviour. All the scrollbars in all your various applications should work in the same way. Scrolling up ought to be controlled just the same in your mail program as in your spreadsheet. In other words, it ought to be obvious how to use each user interface component.
- By combining consistency of look and feel we can leverage or multiply people's knowledge. Just by looking at a new X application you ought to get quite a good idea of what it does and how to use it. Figure A shows a Motif program with some standard components. Once you have used a few Motif applications, you know you can pull down menus from the menu-bar, you know that the option to Open a file will be in the File menu, that the box to the right of the figure is a `file selection box' and that you can use it to select a file as well as displaying those files which are available for selection.

There are many other features that we want from a windowed application, that people often attribute to look and feel, but whieh are really due either to just having a graphical user interface, or more often to having a consistent look and feel:

- Ease of use. Graphical applications are (when well designed) easier to learn and easier to use. In Module 2.1 we gave an example of this, comparing an X calculator program, xCaIC, with its UNIX equivalent, dC.
- Simplicity, especially for the non-expert. One example is desktop managers (Module 9.6) which let non-computer-experts manage their files and run programs without having to know about the underlying operating system. Another example is menu systems, icons and so on, which can give users access to all the facilities they requine without having to know which programs are being run and, in the case of X, which remote CPU they are on, or even that a network is involved at all.
- Standardization and compatibility. The user interface of the program ought to be compatible with other programs the user already knows. For example, OPEN LOOK has been marketed as a de facto standard, and Motif was designed to be very similar to Presentation Manager and the interface provided on Microsoft Windows for DOS.

In fact most of these are user demands. Vendors have not automatically provided these features, but they are now being forced to listen to what their customers want, to remain competitive.

In the next modules we'll see that X lets developers build many, very different, look and feels. We'll look at what they are like, and how they are implemented.

###### Figure A. Standard Motif user interface components.

## 6.2 X allows many different look and feels

The base X system deliberately does not provide a standard user interface, so individual application developers have produced their own interfaces. The designers of X did not include a standard look and feel in the system for many reasons. This gives great flexibility - for developing new interfaces, or emulating the interfaces of other systems to obtain compatibility. Unfortunately it may also mean you have to deal with many different interfaces.

As we described in Module 1.2, the look and feel of an X program is not part of the base system - it is not determined by the server, but is part of the individual application. So, it is possible that each application can have its own distinct look and feel! In the old days, this is more or less what happened: each applications programmer or group of programmers wrote their own. This was bad for users, first, because the user ended up with many different and inconsistent look and feels, and second, because programmers are not necessarily good user interface developers, and some of the look and feels produced were very bad indeed.

However, not building a standard interface into the system does have its advantages. New developments and advances are possible; as the user interface is part of the applications program, researchers have complete freedom to alter it and experiment with new ways of working. This is not possible with most other systems. The source code of X is freely available, which also makes X the obvious choice for experimentation, in the same way that UNIX has often formed the basis for operating system R & D.

Not specifying a look and feel also means that X systems can provide a user interface that is compatible with some other system. For example, Motif is very similar to Presentation Manager and the interface available on Microsoft Windows. It would also be possible to duplicate the interface of the Macintosh (but you would need good lawyers to defend you in case of a law suit from Apple).

This freedom of development leads to an organic evolution of the system. Many new interfaces or look and feels are produced, the best of which form the springboard for future work, leading eventually to the adoption of the best technologies as de facto standards. Ideally this occurs only after the technology has matured enough for a really good system to be available.

Unfortunately, there are disadvantages too. Several viable look and feels have emerged, and each vendor is trying to make their own one the single universal `standard', resulting in the `GUI wars'. In practice, we end up with multiple standards, which means confusion for users, and extra work for developers who have to work with all the different systems. (For example, Figure A shows some of the variants of scrollbar offered by different user interfaces.) This diversity is paradoxically a result of the need for the large commercial software marketplace to have a standard; the demand is so great that some common look and feel needs to be defined now, even though it may be premature, and that there just has not been enough time or work done to give the richness of choice necessary before some single interface is chosen and cast in stone. But the user community is demanding standards, so standards are being provided.

In the next module we look at some of these emerging standards.

###### Figure A. Different look and feels use different scrollbars

## 6.3 Motif and OPEN LOOK - the standard look and feels

Standard look and feels are emerging. Motif and OPEN LOOK are the two most widely used. They are very similar in function, but differ considerably in detail.

MIT provide a sample implementation of a look and feel, with their Athena toolkit. This is a relatively simple and unsophisticated system, but it does provide a model for other developers. It is used only in sample applications provided by MIT and in very few other cases. An example of an application using this look and feel is shown in Figure A.

#### Motif

The Motif look and feel (Figure B) was developed by the Open Software Foundation (OSF) and is based on Digital's DECwindows system and work done by HewlettPackard. In appearance and function it is very like IBM's Presentation Manager and Microsoft Windows for DOS. This is very important for users who wish to integrate their new X applications with existing IBM or DOS software.

#### OPEN LOOK

The OPEN LOOK look and feel (Figure C) was developed by AT&T and Sun. It is derived from the user interface developed by Xerox in the early 1980s.

Both Motif and OPEN LOOK have a 3-D appearance, and they offer more or less similar functionality. However, they differ in visual detail, as you can see from the Figures. They also differ in the way the user interacts with them, particularly as to the extent to which you can control an application using the keyboard instead of the mouse. Also, OPEN LOOK provides drag and drop facilities, and a push pin to force pop-up menus to stay popped up (Module 8.3); also, a full implementation comes with a file manager application, which provides many of the facilities required from a desktop manager (as described in Module 9.6).

In the next module we discuss how X can have so many different user interfaces, and not insist on a single standard.

#### Which `standard' do I choose?

There is no easy answer to the question of which look and feel you should use. Your decision is likely to be based less on technical factors (because there is little to differentiate between the two standards) and more on marketing and pragmatic considerations. For instance, which look and feel has more applications available in your application area? If you are a software vendor, what's important is which look and feel do your customers want, not which you prefer yourself.

For now, many people hedge their bets and use both standards, perhaps helped by a toolkit which allows you to develop applications capable of providing either look and feel (see Module 7.5).

###### Figure A. An application with the MIT Athena look and feel.

###### Figure B. Example of the Motif look and feel.

###### Figure C. Example of the OPEN LOOK look and feel.

## 6.4 How look and feel is implemented: toolkits

The look and feel is implemented within the application itself, not in the base X system. The components of the look and feel - the elements of the user interface and how they are controlled - are usually provided by a toolkit which gives consistency and isolates the application developer from the details of user interface programming.

A user interface toolkit (or just a toolkit) in X usually provides a set of user interface components from which the applications programmer can assemble the user interface, that is, a set of ready-made building blocks. Figure A shows that the user interface code is actually contained in the application, and also that the toolkit provides a higher-level programming interface.

It was always intended by the designers of X that applications would be written with a toolkit. Writing an application using a toolkit rather than basic Xlib functions is analogous to using a high-level language instead of assembler, or writing a C program using the Stdio I/O library instead of raw operating system calls. Initially programs were written using only Xlib; toolkits are a later development, and represent a maturing of the technology, overcoming many of the earlier problems and simplifying the programming task.

The toolkit provides the applications programmer with a set of ready-made user interface components, which are used in different ways to build up the complete user interface, in much the same way that a house is built from pre-manufactured components such as bricks, doors, electrical sockets, etc. The toolkit also contains the functions necessary for creating, assembling and managing these software components.

By using the standard components we get a consistency within all applications built with that particular toolkit, whether they are written in-house or are bought in from an independent vendor, and irrespective of which platform the application has been written for. So, Motif applications running on a DEC VAX are look and feel consistent with Motif applications running on a Sun; you can't tell them apart. (However, the fact that two applications have the same look and feel does not mean that they were built with the same toolkit. Remember, look and feel defines how the application appears to the user. The same external behaviour in a program could be provided in several different ways internally. For example, you could have three functionally similar programs, written respectively in C, Lisp, and Ada, with each using a toolkit written in its own language.)

Toolkits usually also provide special functions for tasks related to the user interface. For example, to use an application principally via the keyboard and minimize the need for the mouse, we need special keyboard handling to replace normal mouse functions. We want to be able to define mnemonics - special key sequences - so that we can pull down menus and select one of the menu options using only the keyboard. We would also like accelerators or short-cut keys to let us invoke frequently-used menu options directly without having to call down the menu, move to the option, and select it explicitly. (For example, in a word processing system you want to be able to save the document easily. Often ctl-s is used as an accelerator for this, that is, as a quick way to invoke the Save function.) Additionally, for form-based applications we need a mechanism to let us navigate from one field to another. Toolkits often provide these mechanisms.

There are many toolkits available. Some are standard (for instance, the MIT X toolkit, Xt, described in the next chapter) with provision for enhancements or for building your own user interface components using the existing pieces or even starting from scratch just using the framework the toolkit provides. Others are specialist toolkits for particular purposes: for example, a basic graphics toolkit for students starting with graphics programming, or advanced toolkits purpose-designed for CAD and CAE systems. There are language-specific toolkits: for example, to allow X programming in Lisp or Ada. (And you can even write your own toolkit if you have a particular need: for example, to address the problem domain that your organization specializes in, but this is a little extneme!) Module 7.6 deals with other toolkits.

Many toolkits also provide high-level functions to simplify programming; these are covered in the next module.

###### Figure A. A toolkit provides a higher level interface to the programmer.

### 6.4.1 What else a toolkit provides

Toolkits often provide many high-level functions to simplify programming, so that the applications programmer can concentrate on the application-specific aspects of the program, and avoid the low-level details of X programming (which are best addressed by a systems programmer or other specialist).

Using a toolkit also provides high-level functions that are not addressed by the basic Xlib library. For example, X is a pixel-oriented system: all dimensions are expressed in numbers of pixels on the screen, so the physical length of a line will depend on the resolution of your screen. Some toolkits let you express dimensions in inches or centimetres, and convert to pixels internally, so you can write resolution-independent programs. (If you don't use some system like this, or go to a lot of trouble to provide similar functionality yourself, when you produce an application which looks fine on a low-resolution PC screen, then as soon as you run it on a very high-resolution screen it will be about the size of a postage stamp - see Figure A.) Resolution-independence can be particularly important in DTP applications; the text displayed on the screen must accurately represent what will be output on the printer, even though the resolutions of screen and printer are likely to be very different. To give the necessary control over appearance, some toolkits process individually each character to be drawn, computing its size and optimal screen position, rather than relying on the standard X text drawing mechanisms.

Usually a toolkit will handle many routine but essential tasks in an X program. Most components of the user interface, such as pushbuttons, labels, scrollbars, menus, etc. will have been created using the toolkit, and therefore the toolkit can redraw them whenever they have been obscured and re-exposed. In other words, the toolkit can automatically handle expose events for most of its components, saving a lot of tedium for the programmer. Similarly, input event handling can be greatly simplified; for example, pushbuttons can be `pne-programmed' so that they automatically handle mouse events (that is, the pushbutton is activated when you click on it), and text components can have keyboard event handling built in so that when you type in them, that is, generate keyboard events in them, the corresponding text is shown. Typically a toolkit provides general mechanisms for event handling like this, and then the specific components in turn use these basic toolkit mechanisms.

Other functions provided by toolkits include:

- Reading-in and processing option settings on the command-line. . Reading-in default values and user-specified preferences for various components in the program, for example, which server to connect to, what size the application window should be, colours and fonts to use, etc.
- Automatically opening and closing the connection to the chosen server.
- Finding and loading fonts.
- Handling colours and colormaps, and graphics contexts, so the applications programmer rarely has to deal with them explicitly.
- Handling any necessary communication or interfacing to the window manager (Module 8.4.1).
- Supporting communication such as cut-and-paste between client applications (Chapter 9).

In the next chapter we look at the standard X way for providing a toolkit, and Module 7.3.1 outlines the extra functionality it includes.

###### Figure A. Different screen resolutions affect the size of an image on screen.

## Summary

In this chapter we have see that the look and feel of X applications - the interface they present to the user - is implemented within the application itself and is not determined by the X server. As a consequence, X can support different look and feels or graphical user interfaces. We considered what people want from a GUI, to make applications easier to use but also to give consistency of usage across all the user's applications. Then we looked at the de facto standard GUIs, Motif and OPEN LOOK. Finally we saw that the user interface in general and GUIs in particular are almost always implemented by means of toolkits. In the next chapter we examine this in depth, concentrating especially on the mechanisms X includes for supporting toolkits.