Jump to page content

GUI: experience

Caveats

Most if not all pages are just rough notes, and these pages as a whole are far from complete. More notes will be added in time, eventually, maybe.

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 are 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.

Contents

Overview

The graphical user interface will be a user-first experience.

Caveats

There are many approaches to a GUI, e.g. overlapping windows vs tiling windows and application-based (standard GUIs) or document-based (THE/Archy). The topics covered on this page do not indicate which if any approach is to be taken. Some of the guidance may become irrelevant if it relates to UI approaches that fall out of favour.

Command response

There are too many circumstances in which the user issues a command and nothing seems to happen. Printing is a common one: nothing comes out of the printer, so the user tries printing again, and again. The UI offers little to no suggestion that that the command was successfully received and that the print job is queued pending resolution of a problem.

Launching an application may result in a delay before anything appears on the screen, leaving the user wondering whether their request was properly recognised. This can lead to multiple attempts to start a program, each one increasing the delay on starting the first process.

With (for example) the Zorin distribution of Linux, you see the same problem as in Windows: after issuing a command to launch a program, there can be a long delay where nothing appears to happen. Mac OS X resolved this very deftly but with a caveat. When launching a program on Mac OS X, its Dock icon would bounce until the program was ready to start accepting input. If the program were not “pinned” to the Dock, its icon would be immediately added in order to show the animation. The Mac’s single-process-multiple-document approach was a key factor in the adoption of this approach: Dock icons represent applications and not windows. (The animation was later replaced with a pulsating symbol.)

There have been Linux desktops that add a taskbar button immediately to show that the command was received and that loading has commenced, but this has not become universal or sustained practice.

Application manifests—which will be mandatory—will allow the OS to understand what kind of program is being run, what environment it needs (e.g. console window), and ensure that the UI can immediately indicate that the program is being loaded.

The Windows Start menu has a different but equally frustrating problem. When clicking a tile to launch a program, nothing happens. The Start menu doesn’t close (to indicate command acceptance) and there is no animation or other indication that the mouse click was accepted. Menu items under Windows can be set to remain visible after the menu closes, fading out to show that they were chosen, which you also don’t see with the Start menu.

macOS added another useful hint to the user: when double-clicking a file, there is a brief animation to illustrate that the file is being opened, so that the user can see that the command was accepted.

Where at all possible, the user should always receive positive acknowledgement of any command invocation and be able to see the status of the command up until completion or failure. The UI should accommodate page swapping delays, I/O delays (e.g. opening a large program from an HDD, or network file share access speed) etc.

Window control

Observe the following screenshot from Samsung Magician:

While the program is busy, it blurs all window contents except for the status message, blocking all access to the window controls. The window cannot be either moved or minimised. This is not tolerable. Programs will not be permitted to remove the title bars from windows and draw fake ones in their place. Where the user is willing, applications will be able to use custom themes (applied solely to a single application) but control of the window cannot be removed. If the user needs consistency, applications will be denied the ability to use custom themes.

As noted elsewhere, when the user minimises, maximises, resizes or moves a window, this will always take place immediately. If the application chooses not to respond, so be it, but this will not stop the change from taking place, and such events cannot be vetoed. The software development framework(s) should maximise the ability and ease by which programmers can keep any I/O out of the UI thread, to minimise the likelihood of UI freezes.

Programs that need to set specific bounds on the window (minimum or maximum size for example) will do so via the API and the window manager will handle these bounds during UI manipulation.

Command availability

At any given time, each of the potential commands available to the user—for example controls and menu items—may be available or unavailable: they may be permissible or not permissible, and applicable or not applicable. How unavailable commands are to be handled raises difficult questions.

Commands can be disabled to show that they are unavailable. This has the advantage of the user knowing that they are looking in the correct place, but the disadvantage of clutter, especially with menus. Context menus that show every possible option that may be available at some point in time are not very contextual.

Commands can be hidden from view. This is tidier, but now the user might spend an age trying to find where a command has got to, not realising that it is inapplicable and therefore hidden from view.

The reason for a command being disabled is often far from apparent. The user needs a way to identify why a command is not available, which is completely impossible directly from the UI when the command is hidden. Psion’s approach was to leave menu items visible but disabled and show a brief message in the corner of the screen (using EIKON’s very simple notification system) to indicate why the command failed, although this was not necessarily a very useful message:

A not very useful message shown when clicking the disabled “Edit” button

This message should have read something like “There are no internet services to edit.”

Leaving commands available when the associated action is unavailable can lead to the user being able to choose a command, only to have it rudely rejected:

Fairly sure this mistake didn’t die out with XP …

The only “error” here is the user being offered a choice that turns out not to be available.

There can be a considerable complexity overhead in calculating in advance which commands should be available, which could make the above situation a necessary evil in some situations.

Dialog hold

Customer Manager has an interesting innovation that, when committing an action via a dialog box, the dialog box remains open until the action is confirmed by the server. This means that, if an error occurs, there is no need to re-enter everything into the dialog box again.

As a counterexample, consider the process of exporting a new version of a document to a PDF from Inkscape, when the previous version of the PDF is still open in another application:

  1. File → Save a Copy
  2. Choose PDF as the file type and specify the same location and name as before.
  3. A new dialog box appears showing the PDF options; confirm the choices.
  4. Overwrite fails as the PDF file is still open from last time; upon acknowledging this error, the whole process aborts.

After closing the PDF and returning to Inkscape, the whole process needs to be started over.

In the worst case, the dialog box from step 3 should remain open until the PDF has been saved. If an error message dialog box is needed, it will be a child of the existing dialog box. This “dialog hold” will allow the user to close the PDF and try exporting it again. There should be no need to start the process over.

With sequential dialog boxes, however, this still offers no recourse if the user is unable to clear the error, and wishes to save the same file elsewhere with all the settings they entered.

One option would be to integrate the choice of type, name and locations into the same window as the one with the save options, for example as a simple wizard. Such a window could be a standard OS feature, thus ensuring that the Save part of the window is always consistent with all other applications, with the caveat that it will no longer be possible to fully customise the system UI to match other systems where this feature does not exist. Another approach would be to simply integrate the disk browser into an otherwise custom window, but this would introduce its own inconsistencies.

If modal windows are to be accepted—see the dialogue page for more details—they will not be allowed to block the UI. Parent windows will remain movable. Commands such as Minimise or Send to Back will apply to the parent window and all associated modal windows.

Taskbar handling

Having a visible window with no taskbar button, puppet-controlled by a taskbar button associated instead with an invisible window, is absolutely forbidden. People not familiar with Windows may think that this concept is a joke, but it is a genuine technique used by various applications. It can for example lead to the window and its taskbar button being on different monitors, as the invisible window that owns the taskbar button doesn’t follow the visible window between monitors. The amount of brain-dead practices under Windows is staggering.

Equally stupid and equally forbidden is windows that unduly exempt themselves from the taskbar. All top-level windows must be selectable from the desktop environment’s window list (e.g. taskbar).