Graphical user interface
If, from reading these notes, you conclude that I am off my rocker, you won’t be the first, and you may even be right.
No doubt there is a dozen and one reasons why none of this would ever work, but perhaps somewhere deep down there is a tiny fragment that could be used for something.
- Global consistency
- Internal consistency
- Avoidable sins
- Window state
- Window toolkit
Only one out-of-the-box graphical user interface will be offered. This will be chosen as a compromise to suit as many people as possible. This is required to help anyone in the world to support anyone else in the world, by ensuring that as many installations as possible look and behave in an expected manner. Where possible, changes to this interface over time will be as limited as possible.
Instead of a single shell, each component of the UI (window manager, task switcher, application launcher, window theme, folder browser etc) will be a separate program or library. A high-level message passing system will be used to drive the window system. Component processes will register for events and send their own commands to the graphical despatcher. This way, parts of the UI can be swapped out separately (e.g. replace the Windows-style taskbar with a RISC OS-style icon bar or Mac OS-style floating palette.
The various abstract components will include:
- Window manager
- A program that handles window presentation and behaviour. Separate window managers could offer behavioural models such as Windows (with maximise and minimise), RISC OS (with select/menu/adjust mouse control and send-to-back) and macOS. Since the position of the menu bar (integrated as with Windows, mouse-invoked as with RISC OS and global as with macOS) varies by window model, the menu bar will likely be provided by the window manager. A desire to mimic the style of another system without altering the system behaviour would be achieved by simply changing the theme.
- Window theme
- A set of definitions for drawing interface components such as window borders, window corners, widget bodies, widget corners, control surfaces etc. While largely vector, bitmapped surfaces would be permitted so that we can have RISC OS-style themes. Changing the theme would restyle the appearance of windows but not change the system behaviour.
- Task switcher
- A means for providing a way to change task. Possibly you would need several, such as for the taskbar (visible window), alt+tab and win+tab (on demand) and the classic Mac application menu. These could be libraries (for hooking into the window manager) or standalone applications. Separate processes for the taskbar and alt+tab/win+tab would add a bit of noise to the user’s process list, so libraries would add tidiness.
- Application launcher
- A means for starting applications. Again, this could be a library that taps into the task switcher (start button) or global menu bar (to mimic the old Apple menu) or a fully standalone program (such as how Windows 8 behaves).
- Folder browser
- A library that presents a graphical view of a file system, used by file managers and Open/Save dialogs. FTP and SFTP software would be expected to register a process-level loopback handler so that they can feed their simulated (remote) file system into the standard presentational model.
Additional bindings include those listed below. Each one by default is bound to a standard utility included with the system.
- System configuration utility, invoked with EVENT_OPEN_SYSTEM_CFG and an optional topic parameter.
- Print queue manager, invoked with EVENT_OPEN_PRINT_QUEUE_MGR and an optional printer parameter.
- Task manager, invoked with EVENT_OPEN_TASK_MGR.
Most computer users are “rote learners” rather than “understanders” when it comes to computers. The staggering lack of inconsistency within desktop software generates an excessive level of cognitive load on end users. This is a far worse problem in Windows than other desktop environments. A simple task such as copying text to the clipboard is not a rote learnable task, as every program makes this command available in a different place. Microsoft are incapable of picking a single ribbon design and sticking to it, software vendors almost universally make a pig’s ear out of their attempts to copy it, some applications put the menu bar under a single button, and the rest all still use the legacy menu bar design. Right-click is a trick that could be learnt once and employed everywhere, except for all the places where it doesn’t work.
Apple attempted to bring more order to the desktop with Mac OS X, and this is the correction direction to go in. The intention here however is to go a step further. Where possible, interface concepts such as menus and toolbars should be described in a flexible way that gives the user a choice as to what mode of user interface to be employed. Whether it’s possible to use a single data structure to define a command set that works both as a menu system or a ribbon is unclear and needs investigation. A simple toolbar system like macOS uses would use a command repertoire derived from the master command set from which the menu bar or ribbon is derived.
There is one important caveat here: classical menus have a huge advantage over any other kind of entirely graphical interaction: menus do not require every command to provide an icon. Macintosh software is quite surprising as to the professional quality of icons used, but too many developers will not have the skills or inclination to find or draw a suitable icon for every possible command.
As a note, just as with macOS, the user must be allowed to search for commands. There is no reason why they should not be allowed to execute graphical commands from a prompt, but the macOS approach of showing the user where the menu item is allows the user to achieve in a couple of clicks what would otherwise require not just typing but also an input change from mouse to keyboard and back.
The arrogance and stupidity of so many software developers and software houses leads to a lot of avoidable sins:
- Hung UI due to unexpected but perfectly predictable delays in I/O or computation. The UI must always live in its own thread so that it remains responsive at all times. Even if the program is unable to cancel its work or the pending I/O, the window will still be able to redraw and respond to window manager commands. Ideally the program should also be able to indicate what it’s pending on, although that is quite involved; for example, each call to DNS resolution needs to known as DNS look-up can be delayed. This is part of the general accountability principle.
- Non-standard dialog boxes that do not obey presentational or keyboard command conventions, e.g. not cancelling on Escape, message boxes that don’t obey the rule that Alt is not required for mnemonics in a window of only buttons, or message boxes that don’t even obey the Tab or Enter keys. Fully-custom dialog boxes are rife in Windows and are a complete nuisance, and Microsoft themselves have created a lot of UI flows in recent years that violate all their keyboard navigation rules.
- Totally fake window layout; all custom skins must be implemented as application-specific themes so that the window manager still has a proper window to manage and the user can disable the skin if they deem it unduly hideous.
- UI lag and lack of feedback. It’s very common on a Windows PC to choose a program from the start menu and have the start menu not close for a while, leaving the user confused as to whether their click was even noticed. Print jobs “disappear” with no indication of what became of them. Program and document launch attempts seem to fail when the program is taking a while to open. Every UI command must complete instantly or indicate to the user that it is in progress; UI commands that don’t seem to do anything are forbidden.
Modern computer systems display depressingly little synergy, and all too often very little feedback to the user as to what did happen or will happen. The graphical user interface design will resolve this as best as can be practically achieved. Some examples:
- Psion’s EIKON GUI—used with their EPOC32 handhelds—showed within the file manager which files were open by drawing the names of those files in bold. It was possible to close the file directly from the file manager; this would signal the owning process to exit.
- A drag and drop operation between two processes should be undoable as a single action.
- Drag and drop operations must correctly indicate whether the action will be a copy, a move or an assignment (e.g. choose file, open file etc). Windows applications get this wrong constantly.
- It must be illegal for a system action to cancel a user action. A window opening must not close a context menu that was opened while waiting for another window to open.
Where possible, the user should able to achieve an unbroken stream of input with whichever input device they are using. That is to say, text input notwithstanding, the user should be able to keep their hands on the keyboard or hand on the mouse without needing to keep switching between the two as they work. Each command should have both a mouse and keyboard means to invoke it.
See the RISC OS GUI page for notes on how much better the mouse can be handled.
State flags include:
- Indicates that unsaved changes exist; the window manager is responsible for presenting this information, as different graphical interfaces show this differently. An asterisk in the title bar is a fallback option (e.g. a Windows-like desktop) while a macOS-like desktop would place a dot into the window’s close button.
Additional state information that should be provided for the window manager to use:
- A handle to the file represented by the window: this can be used as a proxy icon in Mac-like desktops.
Window layout will be dynamic rather than pixel-positioned. The most straightforward GUI known is possibly Psion’s EIKON UI from EPOC32. In EIKON, all controls in a dialog box are arranged vertically, except for the buttons. Each new control is placed below the one above. For example, the following keyboard shortcut handler for Control+A shows the About dialog box in LBShips:
PROC cmdA%: dInit "About LBShips" dText "", "Lecture Battleships for the Revo " + KVersion$, 2 dText "", "Daniel Beardsmore, 2003", 2 dButtons "OK", 13 + 256 dialog ENDP
Although unachievable in OPL, dialog boxes with more content than will fit on the screen were divided up into tabs. (All OPL would have needed for this was a simple “dTab” command to start a new tab, but OPL had some serious omissions compared to the C++ API.)
Where possible, window layout is to be achieved using the minimum amount of presentational control, using automatic control placement.