For the rest of this course we are going to discuss operating systems as that thing which provides services to the user. What the user wants to do is going to be the prime organising question.
First, we need to limit ourselves somewhat. We are going to concentrate on computing environments where people are dealing, more or less directly with the computers, and they know they are doing that.
Thus we will not be looking at process control systems, where the computers main job is directing machinery, and keeping track of chemical and mechanical operations. Systems like this control factories or portions of factories, power stations etc.
We will also not be looking at the computer inside your television, or motor vehicle. When people interact with these computers they don't usually realise it.
Now that we have decided to ignore most of the world's computers what are we left with? Well the sorts of computers that are used in business, science, personal productivity, education, recreation and rehabilition, to name a few areas.
There is a large range of computing tasks which people in these different areas want computers to perform. But all tasks can be summarised as
To produce results as instructed.
Now we come to a bit of a problem. We have to decide what is doing the result production and what is receiving the instructions.
The desired results are almost always produced by user level programs (these days commonly referred to as application programs). The role of the operating system includes:
Many application programs handle instructions from the user. However we have already noted that the operating system is ultimately responsible for all the i/o needs of the program. In many situations information has to be handed to the program when the program starts. Once again this is going to be handled by the operating system.
So at one level we can say:
The task of the operating system is to accept and understand instructions and then execute the programs necessary to obey the instructions.
With this definition we must include a study of the user interface in our study of operating systems. The Lane and Mooney book as well as a classic operating systems text "Fundamentals of Operating Systems" by Lister and Eager, agree with this. Many other books on operating systems disagree. The books which do not include a study of the user interface usually say that, the interface can be separated out from the operating system and be provided by user level processes (of course this is exactly what UNIX does with its different shells).
However this is becoming less and less appropriate. With the development of microkernel operating systems, more and more of the services which were run at the kernel or supervisor level have migrated to user level processes. We don't want to limit our discussion of system service providers to the contents of microkernels.
So for the next three lectures we will be looking at user interfaces. We have to ask questions such as what facilities should the user interface provide and what are the best ways of providing these?
We want to be able to run programs, manage our files, get information. One thing that wasn't thought about for a long time was getting some sort of consistent approach to providing the services. The user should have a "feel" for the system. Anyone who has used different computer systems knows that they feel different. Sometimes we find ourselves confronted with something which just doesn't feel right on this particular system. A recent example of this is the conversion of some Windows software to run on the Macintosh. Many Macintosh reviewers have remarked how the programs just don't seem Macintoshy. Later on we will call this "feel" the system genie.
First of all we will concentrate on users giving direct instructions to the system. As a simple example I will list a variety of different ways in which a user can command the system to continue editing a letter. I will also list the advantages and disadvantages of each method, in particular concentrating on how easy or difficult the method is if the user has some form of disability. It is interesting to think about the tie-in between input and output in the different methods.
Advantages: Brevity. Can be performed by anyone, even if a user can't type directly, as long as they have some controllable action input can always be converted into simple text in a straightforward way.
Another advantage is flexibility, if you read the "vi" man page you will see that all sorts of options for the editor can be set via the command line.
Disadvantages: How are you supposed to know that "vi" is the name of the editor? This normal method of program invocation forces us to tell the system the name of the program we want to use to edit the file. We then can optionally include the name of the file we want our letter saved in. There are more potential problems here. What if a file of that name already exists? What if we mistype the file name when we want to use an existing file?
This is an example of telling the computer the action first and then following the action by the item that the action is going to be performed on. Verb followed by noun.
This is a reasonable approach, we commonly ask people to do things this way. "Complete that form and put it in my mailbox". However what the user is really doing in this case is issuing the name of the program to run, this is not natural.
There is no need for connection between the input and any visible output with this method. All that happens usually is that the characters typed are echoed to the screen. For a blind person the characters may be echoed with a voice synthesizer.
Advantages: The user doesn't have to remember how to write a letter. Selection is easy, regardless of the method of input.
Disadvantages: Not flexible. The user is constrained to only being able to select from the list of items in the menu.
One of the first attempts (and still around today) to make computers easy to use was with menus. Menus had been around for quite sometime in transaction systems such as airline booking terminals. In these cases they were superb. Only very limited types of transaction were required. Even though I have a friend who works for a major airline and they recently changed their transaction system. The new method was supposedly far more flexible, however all the old hands could do exactly what they wanted with the old system, trying to use the new improved flexible system for anything other than simple queries was much harder than the old system.
By the way some entire operating systems have been menu controlled. The UCSD system for microcomputers was, and apparently its menu structure was influential in the Finder menus on the Macintosh (File, Edit etc) and from there into Windows. I quite liked that system, however it did drive many users crazy. The great thing about the UCSD menu system was that when you were proficient you could quickly move around the system executing commands by typing bizarre sequences of menu codes e.g. FR filename Q would take you from the command level to the Filer, Remove the file filename and Quit back to the command level. Almost as efficient as rm filename without having to memorise the command when you were first using the system.
The command level menu looked like this:
COMMAND: E(DIT, R(UN, F(ILE, C(OMP, L(INK, X(ECUTE, A(SSEM, D(EBUG, ?
The ? command was an interesting one because it meant that there were more menus than could fit across the screen, typing "?" gave:
COMMAND: U(SER RESTART, I(NITIALIZE, H(ALT
My manual said interesting things about the debug command:
The D(ebug prompt does not correspond to a currently implemented command. The Compiler is called, but no debugging routines are available. Do not use this command.
When our system uses a menu we don't have to have a large connection between the input and the output. Obviously the way the user selects an item has something to do with what is on the screen, usually typing a number or letter corresponding to the required choice. We can make the connection greater by enabling the user to highlight a selection by moving a pointer or using the arrow keys.
Menu systems initially followed the verb then noun system as above, however this was about to change.
Advantages: The picture of the letter conveys the users meaning. The user does not have to know about programs, even which program edits letters. This appears to be a step in the right direction, why should users have to know about programs, they just want to get their work done.
Disadvantages: What does a letter look like? This is not as silly as it sounds. The design of useful icons is not very common. We will look at icons a little later on. How easy is this method for a disabled person? It is a great step backwards if you are blind. Controlling a pointer in a two-dimensional space is more difficult than making menu selections or entering text for users with physical disabilities.
This is tied in with the absolutely tight connection between what is presented on the screen and the input from the user. All input is placed at specific points on the screen via some pointing device, usually a mouse.
Because of this cooperation between the user and the computer system it is only feasible when you and the computer are close together in some sense. Communication speeds tend to drop off the further you are separated from your computer. However clever client/system methods such as X-windows and even the WWW allow such cooperation even when the user and the receiving computer system are very far apart. There is still a penalty to be paid compared to local systems.
In this case the command is a simple noun. Normally we don't ask people to do things or help us by issuing nouns. The system has to assume that if the person selects a particular type of object, they want to perform a particular action. In a system such as the Macintosh, each file has an associated application program which is run automatically when the object is double clicked, where is this information stored? How is the same thing done under Windows?
This goes part of the way. What happens if you don't have the right application? These days it is possible to tell the system to open the object with a similar application, still not greatly satisfactory. In the first GUIs developed by Xerox, there was only one application to deal with each type of file and so the decision was made for you. Of course this type of environment only works if the developers of the system software have a lot of control over the development of the application programs as well. It is worthwhile noting here that the biggest seller of application programs for Windows is MicroSoft and the biggest seller of application programs for the Macintosh is Claris (at least with regard to integrated office suites), a subsidiary of Apple.
This is just a variation on the previous method: after selecting the icon the user then chooses the action to be performed on the object, edit, print, delete etc. Noun followed by verb.
Several of the so-called GUI interfaces have a default action when you select an object. In which case how does the user do something which is unexpected on the object? Say for example that the letter contains a table of numbers and the user wants to perform calculations on these. In situations such as this it sometimes is an advantage to be working in a simple text environment such as UNIX. Because there are so many tools to work with ASCII based files in UNIX, it makes a lot of sense to save all information in such files. It is always nice to be able to inspect the contents of a file, without having to have the particular program (or even type of program) which created it.
I only know of one operating system which does this, the Oberon system designed by Niklaus Wirth (who we can also blame for Pascal, Modula and the Oberon programming languages). The user selects the name of a file to edit by clicking on it with a mouse button. If the name isn't already somewhere on the screen the user can type it somewhere. It doesn't really matter where because all text is live.
One of the design principles behind this part of the Oberon system was that some studies showed that up to 80% of command input was already showing somewhere on the screen.
Advantages: The users can create their own menus. Type a list of commands and it is automatically a menu. Some system tools are just files which contain lists of commands which the user can then click on. Can have the advantages and disadvantages of menu and direct typing interfaces.
Disadvantages: It really feels strange until you get used to it. It hasn't been too popular, later versions keep this behaviour but add ordinary menus, dialog boxes and icons.
It is very difficult to use if you are physically disabled, a 3-button pointing device is essential.
Just as with a GUI interface there is a very strong connection between the users input and what is on the screen.
Advantages: Just like telling a secretary what to do. No special commands required. Uses the natural language of the user.
Disadvantages: Difficult if you can't speak, wonderful if you can speak but have other physical disabilities.
Once again there is no direct connection between output displayed on the terminal and the input command.