An essay by Sophie White
The Graphical User Interface (GUI) has become an indispensible part of the operating systems used on modern desktop computers. Coincidentally, the form of GUI chosen on all modern desktop computers is one which attempts to model the behaviour of a physical desktop on the computer screen, at least in some respects. Such designs derive from the first experiments into user interface design carried out at XEROX's Palo-Alto Research Centre (PARC.)
It is curious that the basic elements of the PARC design—windows, icons, mouse and pointer—have not changed greatly since they were first introduced. The elements of todays GUIs still exist on a plane which is divided into windows, although there are some systems which differ over the way windows can be arranged. Most commonly, windows exist in a stack, with the one in which the user is working on top (e.g. Apple Mac OS, [Apple97], and Microsoft Windows, [Microsoft95],) although some systems allow work to be carried out in any window, regardless of its position in the stack (e.g. Acorn RISC OS, [Acorn89] & [Acorn94],) and others tile windows on multiple planes with no overlap (e.g. Wirth's Oberon, [Wirth92] & [Oberon].)
In addition most current GUIs also use menus in some form. Mac OS and Windows have set the trend by using pull-down menus available from a menu bar, although context sensitive pop-up menus are used for some applications. Oberon has just a menu bar of commands, in line with its non-overlapping approach, while RISC OS adopts the opposite behavioural extreme, using context-sensitive pop-up menus everywhere.
From system to system, the mouse is universal. What is not universal is the number of buttons. Mac OS prefers the simplicity of one, which is perhaps a false simplicity. Windows wisely chooses to have at least one other, and more recently another control has been added to Windows mice which is more superfluous gadget, less useful tool. RISC OS and Oberon use the sensible maximum of three, and apply global conventions to prevent programmers from giving their own definition to the buttons which would compromise the user-friendliness of their GUIs and consistency between applications.
The keyboard has not been thrown away either, likely because much of computing still involves the input of symbolic and not graphical information. In Windows, the keyboard is forever integrated with the command set available within applications and the facilities of the environment itself, for Windows evolved from a text-based system, DOS. Surprisingly, in Windows, the mouse is optional. The reasons for this are largely due to the history of Windows, but recently it has proved to be a design feature, as accessibility to disabled people has increasingly become recognised as an important design feature. Mac OS and RISC OS have keyboard shortcuts, but these are much less dominant, and are not available everywhere.
We still strive to have spoken dialogue with computers, and one surely must have little doubt that this will eventuate in time. In the meantime, the GUI provides the dialogue box, which is essentially a window containing a form into which we input information to communicate our requirements and intentions to the computer. In Mac OS and Windows, dialogues can only exist one at a time, and typically present themselves in the middle of the screen when a command is selected from a menu. RISC OS prefers dialogue boxes to be directly attached to the menu trees which exist in that environment, so that the user may browse through the available dialogues before deciding which one to use. Dialogue boxes which can coexist and which are persistent are also a commonly observed feature of RISC OS, so to allow dialogue boxes themselves to cooperate.
Application management is treated in a variety of ways by a variety of GUIs. Indeed, Windows perhaps has yet to hit on its preferred approach. Early versions of Windows preferred to have a user-defined program manager where users placed applications, with switching being provided for by a task management dialogue box or through the shuffling of application windows. These have now been largely replaced with the concepts of a start button and an icon bar. RISC OS uses an icon bar for applications, and opts for complexity in providing a task manager which shows memory allocations. Mac OS has an application menu instead of an icon bar, and also achieves switching through window shuffling. Oberon decides to blur the distinction between applications.
In terms of cooperation, Oberon strives for seamlessness in its environment, with the commands available in applications being more important than the applications themselves. Object Linking and Embedding (OLE) developments in Windows, Mac OS and RISC OS provide for close-knit cooperation between applications. The global clipboard is preferred in Windows and Mac OS for inter-application communication, while RISC OS has always placed emphasis on drag-and-drop communication between applications. Drag-and-drop is now being used in Windows and Mac OS, but it is distinct from the file drag-and-drop prevalent in RISC OS.
Windows and Mac OS, despite both having hierarchical GUI interfaces for file management, still choose to use application specific dialogues in order to implement file saving and export operations. RISC OS has always chosen to implement such saving using the same drag-and-drop technique as is used between applications, which provides a consistent approach across the board for users, and reduces the burden of programming separate interfaces for inter-application communication and file management.
The unfortunate thing is, despite the design features of systems like RISC OS and Oberon, innovations like it in GUI design are being swamped by the sheer weight of numbers of those who are coerced into using the more popular designs like Mac OS and Windows. Oberon against Windows is like David and Goliath, and sadly without innovative projects like Juice [Franz], it is hard to see some of its wise design precepts being widely adopted. RISC OS has its own problems, but stale GUI, poor efficiency and cumbersome size are not amongst them.
On examination, it is quite clear that some of the most valuable elements of GUIs already exist in small innovative systems, and are slowly being incorporated into the mammoth legacy systems which are widely popular. There are still many more ingredients yet to be realised—the extension of the plane to a space for one, the integration of humans more seamlessly into the work environment for another. One must recognise, however, that these developments will occur on the fringe, in small innovative GUI-based environments. The continued existence and recognition of such systems will be the key component in a bright GUI future.
Both Oberon and RISC OS have the concept of a focus window (although Oberon calls its windows viewers,) and the nearest equivalent in Mac OS and Windows is the active window, which always resides on the top of the window stack.
The focus window is defined as the window containing the input caret (even if such a caret is invisible, as it might be in a RISC OS drawing program for example.) There is no requirement that this focus window be on the top of the window stack, or for it to be completely unobscured, even when it is being clicked in or accepting input of any other kind. The focus window is typically highlighted in some way.
Wirth prefers not to use overlapping windows at all in Oberon, but both Windows and MacOS use them as well. Wirth argues that the scheme of overlapping windows comes at a heavy implementation cost, which is true to a degree, as redraws of a single window may consist of multiple rectangular regions, each of which need to be determined and redrawn. He claims that this cost is not worth paying because he is not convinced that "documents being piled up on one's desk" is an appropriate metaphor. Perhaps Wirth has a particularly cluttered desk and cannot find anything.
The scheme used in Oberon in preference is that of tiling windows. It seems that by simplifying the task of the computer, Wirth has complicated the task of the user. Instead of basing Oberon on an existing real-world scheme, like the overlapping windows on a screen base themselves on documents on a desktop, Wirth takes time to implement a quite involved scheme, which while well justified at the level of implementation detail, is not adequately justified at the level of user-friendliness. While the desktop metaphor can have problems through obscured windows, the familiarity of the scheme makes it hard to beat.
With RISC OS allowing the focus window to be anywhere in the window stack, and providing mechanisms by which to move and resize windows without altering their position in the window stack, the difficulties of overlapping windows obscuring each other is lessened. RISC OS therefore more closely models a real desk—there is nothing stopping you from sliding a document out from under another to refer to it without moving it above another document which lies above it. While Windows or Mac OS users would claim they can achieve the same result by resizing their windows, it seems clear that the RISC OS approach of sliding windows into view is more natural than the distracting dance of windows vying for the top of the stack on their desktops.
Scrolling windows are one of those necessary evils required in a desktop environment because screens are quite finite, our windows are still more finite, and documents are virtually infinite. While there may yet be an argument for restoring pagination over scrolling with the advent of more appealing virtual book interfaces (perhaps when desktops become a little more three dimensional,) which is clearly more natural, scrolling can still be implemented better than it is by most systems today. The scroll bar seems to be a legacy technology of the days when windows couldn't be rapidly updated as they were moved or scrolled—in those days, the user blindly moved an outline representation of the scroll bar down the document in a step by step way, so feedback was slow.
Auto-debounced scrolling, where the user uses the pointer to fly over the document, is much more natural than using a scroll bar, and can be effectively used to browse over an area, but it is difficult to implement without being annoying. In a document window, this type of scrolling is commonly used when dragging out a selection, but not otherwise. The RISC OS icon bar uses auto-debounced scrolling and uses it well to provide rapid access to application icons even when there are many tens of icons available. Providing a debounced scrolling widget on a window might be a positive step—perhaps double-clicking on a scroll arrow could change the visible mouse pointer so that it could scroll the window at each edge.
Similar to auto-debounced scrolling is push scrolling, where you effectively use the pointer as a hand to push the document around. The sense of movement is reversed, because instead of moving the viewing area around the document, you are moving the document under the viewing area. Where the movement in auto-debounced scrolling occurs without movement of the mouse—once you move the pointer to the edge of a window, you initiate flying until you recede back to the centre—the movement in push scrolling corresponds to the mouse, although it may be accelerated over time. Again, as for auto-debounced scrolling, a push scrolling widget could be provided or a special utilization of existing scroll furniture employed.
Less acceptable than these two approaches, but perhaps more seamlessly achievable in current GUIs is the concept of two-dimensional scrolling. Here, by dragging a window's scroll bar in a special way, you can actually affect both the vertical and horizontal scroll bars of that window. The mouse pointer typically disappears, and the mouse movement is tracked by both scroll bars. Both push scrolling and auto-debounced scrolling are two-dimensional, but mouse movements do not equate to scroll bar movements in the same magnitude and direction.
Besides being more natural than scrolling horizontally and vertically individually, two-dimensional scrolling can be particularly convenient in graphical applications, including desktop publishers which display left and right pages side by side. RISC OS is the only operating system of those examined to provide two-dimensional scrolling, although there may be extensions available for Mac OS and Windows which allow it. It can be argued that this technology is too good to be left to such chance, however.
Wirth's doubts about overlap aside, provided that menus can be delivered to the user quickly (and this is the case with today's increasingly powerful software and hardware,) it can be argued that pop-up menus are all that are needed, and are therefore all that should be available in a desktop operating system. Freed from the burden of menu bars, such an approach means that more screen space is available for work area, and multiple applications or documents can exist on the same screen with greater economy. The cost comes through the user not readily being able to see the main menu options without actively seeking them.
Menu bars and pull-down menus are legacy elements of an age where, for one reason or another, fewer mouse buttons have been favoured over more. The main argument for fewer mouse buttons is that it provides for simplicity (in terms of what the user must know, and the design of the mouse and interface software and hardware,) at the obvious cost of flexibility. The most extreme case is Mac OS. With only one button, the only operations possible are select (single-click,) drag (held button) and activate (double-click.) Of course, one could use triple clicks and so on, but these are clearly ridiculous concepts that have very limited application—one exception is selecting hierarchical elements of a document in succession, but this is usually achieved by multiple-staged selection, and does not require fast clicking.
But with one extra button, context-sensitive menus can be called up using that button exclusively. Instead of menus being restricted to an active area of the screen which interprets mouse clicks and movements in a different way, menus are available anywhere. Windows, with its extra button, has this advantage but prefers to keep menu bars. Given this, and the large redundancy or technicality of operations available on context-sensitive menus in Windows applications, perhaps Windows would have been better advised to stick completely with menu bars and to use the other button for multiple selections (see below.)
Recent incarnations of Mac OS have incorporated context-sensitive menus—such has been the cross pollenation of software written for Windows and Mac OS. In order to provide the same interface and functionality to users of Mac OS, context sensitive menus become available through static drags. That is, you hold the button down over an item, avoid moving the mouse, and eventually you will be rewarded with a context sensitive menu. This is a poor substitute for an extra button, because it violates the earlier point about context-sensitive menus needing to be delivered to the user quickly. Also, this cannot work correctly for items which are draggable, since there will be ambiguity over whether a drag should be initiated or a context sensitive menu delivered.
Oberon is a mutant case, because menu bars are really just command palettes. Oberon itself does not support menus in any special way, although clearly an Oberon window may behave in a menu-like manner. Wirth sees menus as a hinderance to his compact design, which would be plausible if only he had not then gone on to provide for menu bars, which while easy to implement, are similarly unnecessary if one was to follow through on his strict design ideals.
RISC OS has the extra mouse button dedicated entirely to menus and does away with allocating fixed portions of the display area for menu bars. All menus are context sensitive, and called up by the user on request. In fact, RISC OS goes beyond providing no facility for menu bars, it is exclusively prohibited for a programmer to implement her own in the RISC OS Style Guide [Acorn93] as being contrary to the operating system's values of design consistency.
The difficulty with context sensitive menus overall is that they often obscure the context in which they are called upon. Pull-down menus suffer from the same problem to a degree, but the nature of context-sensitive menus means that the problem is more acute. Wirth's aversion to overlap is given some merit through the occurence of this problem. Unsurprisingly, the operating system which suffers from the problem more severely (due to its exclusive use of context-sensitive menus,) RISC OS, allows its menus to be dragged by their title bars to allow viewing of obscured areas. In fact, menus on RISC OS are treated exactly like windows, because they are in fact windows.
The overlap problem is recognised by most operating systems in terms of the persistence of menus. Menus do not persist in Windows, Mac OS or RISC OS when the user clicks away from the menu. Additionally, menus do not persist in Windows or Mac OS when a command is selected, although often a sequence of commands will be needed. While Windows and Mac OS benefit from the persistence of their menu bars in terms of visibility of main menu options, these options are never commands within themselves, and they always call up further menus. So multiple command selections can be laborious, involving the automatic closing and manual reopening of the same menu many times. The problem is short-circuited, at the expense of user-friendliness, by providing keyboard shortcuts (see below.)
RISC OS provides a solution through its third mouse button, while other operating systems have extensions available which involve modified mouse clicks (see below.) By clicking with this additional button, the user causes the menu to be left open for the same command to be repeated, another command on the same menu to be chosen, or indeed for another menu in the same tree to be located and used. This option is further exploited by dialogue boxes, which are typically hung off menus in a seamless fashion (see below.)
Still, there is some justification for allowing menus to be even more presistent than this—in cases where the user is interleaving menu and other commands. Tear-off menus, which are provided by some applications within their own frameworks, would be a valuable addition to all the operating systems being discussed (excluding Oberon, where it would violate Wirth's key design precepts.) A tear-off menu provides some control on it which allows it to become persistent on the screen so that it remains even when clicking in windows (or indeed further menus) outside it.
Due to the legacy of fewer mouse buttons being used rather than more by Windows and Mac OS, as GUIs have been required to support more complex operations, modified mouse clicks have been introduced. Such clicks involve the combined use of mouse and keyboard. Clearly such arrangements are awkward, and largely negate the arguments of simplicity in having only one or two mouse buttons.
From an ergonomic persepective, such operations require the user to use both hands, and also that the user memorize the shift key modifiers which are sometimes used for different technical purposes in different applications. The problem is exacerbated by the fact the user typically has to reach for the keyboard from a relaxed position and select the appropriate shift key. It is not uncommon for the combination of not knowing the correct shift key and not finding the intended shift key which can result in frustration.
Modified mouse clicks are perhaps the height of user-unfriendliness. While RISC OS gets it right by providing three buttons instead of two or one, it stupidly requires a number of modified mouse click combinations[1], and it perhaps has the worst record for different programmers using different shift key combinations from application to application. But Mac OS makes RISC OS look like utopia, because there is hardly an operation which can be performed without the user having to resort to using the keyboard.
Multiple selections reveal the problem most acutely. These involve the selection and deselection of multiple items in a window one at a time. The difficulty arises because there are two possible intentions the user may have when selecting an item. Either they require that item to be selected or deselected exclusively, or they require that the item be selected in addition to others which have already be selected (or conversely deselected amongst those already selected.) Two clearly distinct behaviour involves two clearly distinct types of selection commands—selection and selection adjustment.
RISC OS chooses to map these commands onto distinct buttons. This gives rise to global functions of the three button mouse of RISC OS: selection, selection adjustment and menu request. Oberon differs in that its menu button is for requesting commands and its third button is for marking rather than selection adjustment. More complex functions (including selection adjustment) are achieved by interclicking (the combination of more than one mouse button), a technique which arguably requires even more aptitude than using the keyboard in combination with the mouse.
The difficulty arises when you don't have a third (or second) button. You must then use a keyboard modifier to achieve the desired result from your mouse-click. Clearly, for the reasons already elucidated, this is not the most desirable way to implement a function, particularly one which is so commonly required throughout the GUI.
In a GUI, the mouse, or in the very least some pointing device, is king. But it is often more convenient to give a symbolic representation of a common command or action, particularly if that command or action is buried deep down in a menu. The common solution is to provide a symbolic representation for this command which can be delivered via the keyboard.
Arguably, keyboard shortcuts could be eliminated through the judicious use of user defined toolbars, although there are a number of ways in which such an approach turns out to be inferior, at least on current systems. For example, if the user had independent pointing devices, one for each hand being the natural scheme, it would be convenient for a user to activate tools with one pointer and apply them with the other. But even then, the toolbar takes up valuable screen space, and it may not always be easy to select the right tool if the toolbar is cluttered.
Windows has a keyboard shortcut system which is almost capable of making the mouse redundant. This is a legacy of DOS interfaces from which Windows derives, where it couldn't be assumed that the user had a mouse at her disposal. Typically, every element of the Windows GUI has a letter by which it can be referred, and this is usually underlined. The user can also move through the various input elements of a dialogue box using a key.
Seemingly only useful for the rare user who either doesn't have a mouse or has an aversion to using one, these shortcuts have proved practical for people who can't use pointing devices through some disability. Neither do these people need to be able to use a keyboard—the shortcuts are readily mapped onto specialized input devices.
Mac OS, RISC OS and Oberon allow programmers to define shortcuts, but it is not actively encouraged as is the case under Windows. This makes these systems less accessible to disabled people.
All GUIs seem to have check boxes, radio boxes, writable fields and command buttons. Many also have other gadgets like sliders, list and combo boxes. Windows is perhaps most rich in terms of the diversity of gadgets available, with Mac OS being next, followed by RISC OS and the much more restricted Oberon. But the key element of the Windows GUI elements are that they carry focus, so that they can be controlled via the keyboard when they have that focus. The Tab or arrow keys typically allow movement through the fields. These keyboard shortcuts (see above) make Windows a very accessible environment to those incapable of using pointing devices.
Dialogue boxes are called up typically by a toolbox icon or a menu option. This is what usually happens in Windows and Mac OS. In these cases, you don't know the form of the window until you see it. However, under RISC OS, dialogue boxes are typically attached as submenus in context-sensitive menu trees. These open and close as the pointer flies across the menu options, and provide a much more dynamic way for the user to decide how she wants to communicate with an application.
In RISC OS, dialogue boxes can also be persistent windows, and unlike such boxes in Windows or MacOS, which have to be closed in order to carry out other operations, RISC OS does not insist that they exist one-at-a-time. A typical example is a dialogue box which accepts input dragged from another source on the screen. Instead of placing data on a global clipboard, and pasting it in the dialogue box later, RISC OS allows the user to select the operation first, and then drag the information into the persistent dialogue box. Indeed, there is nothing stopping the other window from being a dialogue box itself. Such behaviour is more natural than the clipboard approach, and takes drag-and-drop nearer to its full potential.
The icon bar is becoming a well-defined feature of most GUIs (including Windows and RISC OS,) although its future may hand in doubt as application boundaries blur, and it is more difficult to distinguish applications, perhaps even unnecessary from a user perspective. Oberon has no need for an icon bar, because it is command oriented. Mac OS could benefit from an icon bar, but currently it uses an application menu to switch between tasks. As it is the purpose of the Windows and RISC OS icon bars are quite different—Windows' icon bar "switches-in" a particular application window, yet there is no "switching" of application windows in RISC OS, so its icon bar is merely a way of enumerating and addressing applications (opening menus, starting new documents, or dragging in existing ones.)
The difference between application management on Windows and Mac OS versus RISC OS is that Windows and Mac OS distinguish sets of application windows and keep them together on the window stack. This means that when one "switches" from one application's window to a different application's window, all the other application windows belonging to the newly selected application rise to the top of the window stack. This is a very unnatural behaviour, and counter intuitive because we often edit documents in different applications in the same sorts of ways, and rightly expect them to coexist in the same desktop plane, just like real documents would.
This artificial distinction between applications is unnecessary and a legacy, at least in Windows, of the use of application frames. If the utopia of seamless application integration is to be achieved, then it is clear that Mac OS and Windows must eliminate this "switching" behaviour. The approach in RISC OS is to make each window its own window, able to coexist with any other at any depth on the window stack. Selecting an application window for work not only doesn't bring it to the front, it doesn't affect any other windows belonging to that or any other application that may be in the window stack. There is no cumbersome menu bar (see above) to deal with, as all applications' main menus are drawn from the icon bar (non-document dependent commands) or from document windows (document dependent commands.)
RISC OS has one final curiousity with no equivalent in Windows or Mac OS. The task display displays the memory allocations of all current applications and system memory areas like caches and shared data and code repositories. This allows advanced users and programmers to determine the memory usage in their system. Arguably, this sort of information should be hidden, but knowledge of resource usage is relevant to users, and if it is possible to represent such things in a sufficiently abstract yet useful graphical fashion, then a task display of some form might be a useful addition to a GUI.
The traditional means of application communication available in Windows and MacOS is the global clipboard. Each application has its own cut and paste operations which transfer data via a single repository using a well defined data format. The clipboard is typically invisible, although there is often an operating system feature to view it, this is rarely used. This means that the clipboard is a particularly non-intuitive entity, and while providing a convenient middle-man for the implementation of inter-application communication, it is not the most elegant or most natural approach.
For this reason, the more natural method of drag-and-drop is being increasingly used as the medium of communication among applications. Indeed, RISC OS, without a global clipboard, is dependent on it. Selections of documents can be dragged from one application in order to incorporate the information in another. Apart from straight import and export, where the data is duplicated, modern systems also use OLE to ensure that data can be shared between applications. Indeed, not only is the data shared, but it is also possible for the applications to use each others facilities in order to display the data.
For example, a wordprocessor which has a document which contains a link to a spreadsheet may use the spreadsheet application to render the spreadsheet within the wordprocessor window. This is clearly a very flexible approach, and is a sign of the lessening distinctions we may see between applications in the future. Oberon's command based approach already makes applications start to look outmoded as a concept, and OLE in Windows, MacOS and RISC OS may soon also begin to break down the boundaries of what an application is and what part it plays in the environment. Increasingly, applications will be less visible to the user, leading to one seamlessly coherent environment.
An odd quirk of Windows and Mac OS is the replication of the filing system interface throughout all applications. Each application in Mac OS and Windows has its own save dialogue box which allows the user to navigate the filing systems available in order to decide where to save their document. In addition, Windows provides the Explorer for file management and Mac OS provides the Finder for a similar purpose. This duplication of responsibility for file management is cumbersome, and it is almost impossible to justify logically—it is just something which has evolved into these systems and become accepted.
The RISC OS approach is to make the Filer the only application which allows the user to navigate the filing system. The equivalent of Windows Explorer and Mac OS Finder, the RISC OS Filer supports drag-and-drop completely. It is the only interface through which new file objects can be loaded into and saved from applications. Besides the ordinary double-click, a file can be dragged to a specific application icon in order to be loaded, or it can be dragged into an existing document in order to be incorporated therein. To export or save an entire document or selection, one typically uses a Save dialogue box which contains an icon for the file which will be exported. If this is dragged into a Filer viewer, it is saved in that location. If it is dragged to another application (or indeed the same application,) that application can load or import it as required.
The difficulty with the RISC OS approach is that Save boxes are typically non-persistent, so that searching for an appropriate Filer viewer removes the Save dialogue box, which has to be called up again when the desired viewer is found. This is much less than satisfactory, but it is still clear that the overall approach to unifying file management in a single scheme is a more sound design than duplicating the interface in many places.
By barely touching on some of the broad features of GUIs as they stand on desktop computers today, this essay has shown that their is much room for the cross-pollenation of innovative ideas from platform to platform. Yet we can only dream of the sorts of GUIs that may be in use in a few tens of years time.
It is obvious that current GUI environments lack depth—literally—and much of their intuitivity through their sound basis on real-world behaviours would be greatly enhanced by a three-dimensional interface where the user could interact directly with virtual tools to build virtual objects in the most natural ways.
The distinction between applications is already blurring, and object-oriented approaches which are seamlessly integrated together from a variety of vendors are likely. In this world, combined with a three-dimensional GUI, a document would become an object, a window would become a tank, and toolbars would become toolboxes, and an icon could be anything from a holographic cube to a virtual person with which we discuss our needs. We might have virtual keyboards, virtual pens, virtual books, and explore the possibilities of gravity and virtually unlimited space. Computers can already generate such worlds—it is only a matter of time before they are convincingly realistic and we actually have ways of interacting with them and getting back visual, auditory and tactile feedback in real-time. From here, the future looks bright.
[Acorn89] Acorn, RISC OS Programmer's Reference Manual, Acorn Computers 1989
[Acorn93] Acorn, RISC OS Style Guide, Acorn Computers 1993
[Acorn94] Acorn, RISC OS 3 User Guide, 4th Ed, Acorn Computers 1994
[Apple97] Apple, Mac OS 8, Apple Computer 1997
[Franz] Franz M and Kistler T, Juice, http://www.ics.uci.edu/~juice
[Microsoft95] Microsoft, Introducing Microsoft Windows 95, Microsoft Corporation 1995
[Oberon] Department Of Information And Computer Science, University Of California At Irvine, Oberon Software Distribution, http://www.ics.uci.edu/~oberon
[Wirth92] Wirth N and Gutknecht J, Project Oberon: The Design Of An Operating System And Compiler, Addison-Wesley 1992
[1] Thankfully, most combinations are only required for technical operations such as revealing the contents of an application directory, or opening a directory without loading further icons from the applications within it. Unfortunately, the Shift key in combination with the selection mouse button is required to perform a filing system move operation, where a drag using the selection adjustment could have made RISC OS so much more user-friendly. As it is, drag using the selection adjustment is much less useful, because it closes the parent window and performs a copy operation just like the selection button would—rarely useful.
Last updated: Saturday 1st October 2022