One recent change in the design of user interfaces is that they are designed. A criticism of computers was that they were foreign. People who wanted to do work on computers had to learn about computers first, even though all they wanted to do was to get some work done.
So some of the people at Xerox PARC desided to do something about that. Let's make the computer not look like a computer. Let's make the computer look like something that people already know. Usually people want to work with documents, usually pieces of paper, with text and numbers on them. They usually work in an office, with desks, filing cabinets, telephones etc. Since we can approximate some of the computer programs or objects by these things lets pretend our computer is an office, or less appropriately a desktop.
Ever since then interface designers have tried to make the computer look like something else. The "desktop" metaphor has certainly been the most successful.
This emphasis on system metaphor has lead to some good ideas and some attrocious ones. Some of the good ideas have been the rooms metaphor, whereby different applications produce their output in separate rooms and the user can walk between rooms. The computer as theatre is a metaphor I particularly like, however this is intended to be a metaphor for user interface designers rather than the user interface itself. In a recent issue of SIGCHI, a kitchen metaphor was suggested, on the basis of the fact that more people work in kitchens than offices. Unfortunately the suggestion for representing files was slices of bread.
If we do want our system metaphor to actually mimic something outside the world of computers we need to apply two criteria.
There has to be a suitable relationship between the things in the model and those in the source of the metaphor. This is pretty obvious, otherwise we wouldn't find the metaphor, a metaphor. e.g. The desktop itself should be a place to leave documents, folders, calculators etc. What about printers. Not too many desks have printers on them (or filing cabinets). I think the kitchen metaphor really falls down on this one.
Things we do with the model must be reasonable things to do with the source. Moving a document from one folder to another is like moving a document from one folder to another - and it is not too far from moving a file from one directory to another (but is it like copying a file and then deleting the original?).
It has been suggested that there are five ways to measure the effectiveness of a metaphor.
Regardless of whether or not the user interface was designed, all computer users build up their own model of the system in their heads. After using a system for a while we know what it is capable of and have an idea of what is going on inside the system. This construct (which is entirely inside our own heads and may bear little relation to what is actually going on in the system) is known as the system genie.
So the system metaphor is what the designers intended the system to look like and the system genie is what we think the system is. When we need to do something we haven't done before we use our system genie to give us ideas of the methods we think should work. Obviously the closer the system genie is to the system metaphor the better our chance of making the right move.
Now we have covered several different aspects of the user interface: what it was designed to look like (the system metaphor); what it does look like (the system genie); the language we use to control the system - from the terminal, from within a command file or script, and from within programs. One important aspect hasn't been touched on yet.
To make a user interface truly easy to use we need to provide a good help system. For a while interface designers tried to avoid the problem of "help" by insisting that their interface was so intuitive that a help system was unnecessary.
We have different requirements which all come loosely under the title of help.
I like the way UNIX provides an answer to "who am I", even if it is without the question mark.
The most important job of a help system is to provide assistance when the user doesn't know what to do next or how to do something.
The original (and probably still best?) way of providing such assistance was with the system or program manuals. Books are not usually regarded as part of the operating systems however. It is possible to put the same information which goes in the book onto the computer. There are several things wrong with this approach.
(There is a disturbing trend by some companies to no longer supply reference manuals with software. The sort of manual you get is supposedly designed to help answer the sorts of questions you normally have. Computer capable people commonly just want a reference manual, they are quite happy with looking up the information and making the links themselves.)
Nevertheless, such online manuals provide the basis for what I will call "traditional" help systems. Users type the word "help" followed by the topic they want help on. If they don't know the topic, the help system usually provides a list of possible topics.
All help systems need to be selective in what help they provide. Usually users want help with what they are doing at the present, therefore help which looks at what the user is doing (usually at a rather coarse level) and provides information around that activity is what we want. This is known as context sensitive help. However sometimes users want to get information not immediately related to the job they are doing at the moment, this means that there must be some way of jumping outside the present context.
Once again context sensitive help is an area where application programs have been ahead of operating systems. However in the interests of consistency we are going to have to provide some system wide approach to providing help.
The Macintosh Balloon Help is not a bad attempt at providing context sensitive help. Of course all it attempts to do is to explain what different areas of the screen mean, but it is useful at complicated dialog boxes for example or at explaining what a menu command does. I think the greatest problem people have with Balloon Help is all those stupid speech balloons which pop up all over the place. A very nice way to avoid this would have been providing a help button on the mouse, which you clicked when you wanted the balloon help for the object the pointer was currently over. But Apple were convinced that a one button mouse was the best.
The Windows 95 help system allows you to click a "?" in the top right hand corner of many dialog boxes and then to click on areas of the dialog to get relevant explanations.
The other thing about both the Windows 95 help systems and Balloon Help is that developers are free to ignore it (or to include minimal explanations to get passed development restrictions) which immediately reduces its usefulness.
We still have a problem. Our user wants to be able to get instructions on how to do something. Asking the question is still the biggest problem. What we really need is a natural language help system. The Microsoft Office programs have the Answer Wizard which attempts to cope with a query expressed in natural language. This really seems to be a hit or miss affair. Sometimes you get very appropriate information and other times it looks as though the system has produced totally random suggestions because it couldn't make sense of what you were asking.
Once we have had our query understood by the system we then need to be given simple instructions (in terms which we understand) to perform the task. I have already commented on GUIs when it comes to this. The Apple Guide system and the Windows 95 help system, attempts to lead a user through the actions required to perform a task (in the case of Apple Guide by using the Apple Events system).
One thing which some application programs have provided for many years is tutorial information. This may be a sequence of graded operations designed to teach a new user how to use the application, or even a simulation of the program which shows the user how to use it. Some operating systems (the only ones I know of are for personal computers) come with similar "Introduction to …" programs. This is one way of guiding the user both in how to use the system and in building the user's system genie.
One area of the user interface that has received very little attention is presenting feedback from the system to the user. I must admit one of the most frustrating experiences I have is when I try to connect to a remote system (via telnet or something similar) and I have no idea on the state of the connection. There are ways of getting information but, they should be presented automatically, in straightforward language.
A major problem which needs correcting even in modern user interfaces is the way errors are reported to the user. As we pointed out several lectures ago, it would be nicest if we went out of our way to make sure that errors never occurred. However sometimes the program or the user is going to do something, that either isn't allowed or can't be done. Or even worse the system, hardware or software is going to fail.
First of all, we don't want the user unsure, whether a command has succeeded or not. If something has gone wrong the system must let them know.
The system must produce a message which is understandable to the user (ok this may be difficult in some situations but if it is impossible then the message should tell them how to get help on the problem). This means the message must be in language the user can understand. It should also give information on ways to avoid the problem.
One difficulty facing the operating system is that it is once again going to have to have the cooperation of the other programs in the system. What happens when a system call causes a problem, should the system put the error message up for the user, or should the error be handled at a higher level?
The only method we know which guarantees an error message is produced is that each calling procedure tells the routines it calls whether or not it can handle error messages. If not the called routine has to send the error message if something goes wrong. Java does something like this.
List some of your pet hates about a system you know well.
We have been looking at the interface between people and computer systems however there is one sort of user we have been ignoring, the system administrators. We also need to consider the information the system must have about people.
As soon as you have more than one person using a computer system you really need to organise control of the system. We will call this managing the system and it entails doing all of those things which allow ordinary users to get their work done but are not their responsibility.
They need to keep an overview of the system, making sure that it is running as smoothly as possible.
As people get added to the system someone has to set them up with an account. The type of information this requires we will look at shortly. The information must be accessible and changeable by the administrators.
Accounts must be maintained automatically (nothing else is fast enough) for all resource uses. Individuals, departments or entire companies may be the final payers.
In a university or research environment it is easy to forget about the cost of the computing resources we use. However, many real world systems worry a lot about accounting. Doing this properly is not a trivial task.
How does the system help when something goes wrong. Not the sort of thing which goes wrong when a process attempts to do something it can't, either because it is not allowed to or because its request is impossible. Instead, the sort of thing when something serious across the system goes wrong, typically the system crashes. We will look at this in more detail in the next section of lectures.
We have already mentioned the fact that a lot of this organisation is unnecessary if the system is designed for a single user. Of course with networks being so prevalent these days some of this information is required even in a "single-user" system.
Different types of information is necessary.
Some information about users needs to be held between sessions.
This includes the permissions the user has to files, programs, devices, mail etc.
Limits on resource usage. How many resources do I have left?
Where is the users home directory, and files? Where is my mailbox?
Where should this information be stored?
Since most of this data is rather disjointed but is associated with specific areas of the operating system - files, login etc - it will probably be found scattered around the system.