Dialogue
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. These pages may simply position me as an acolyte to the late Gene Ray.
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
Dialog boxes are not met with universal acceptance. They have a habit of appearing without being noticed, and they are abused greatly. They are not without merit, but the implementations leave a lot to be desired.
System modal windows are a scourge. Apple finally banished them starting with Mac OS X (by Mac OS 9 they were largely an unwelcome holdover from the pre-multitasking era of the Mac), but Microsoft saw fit to introduce them and they remain a part of Windows. Application modal windows are also frustrating. They are used for messages that were more sensibly represented as modeless notifications. Depending on the UI model, they block the parent window from being moved or minimised; in Windows, the Show Desktop command forces them to vanish, and the first window activated causes them to return. This seems to relate to the extremely poor taskbar and window management where top-level windows aren’t required to have a taskbar button and dialog boxes can have the wrong parent set or have no parent set at all.
The late Jef Raskin’s school of thought holds that modality itself is a scourge. All interaction with the system is to be conducted virtually modelessly. His idea was to have a key that you hold to enter a command, with a single global command namespace. This notion is dubious, not least because it is tricky to type with one finger holding a key down. Having a global command namespace seems implausible. The whole idea of distinct applications was something he sought to avoid, which does stand to reason because many users have no concept of what an application is, or which application they are using to achieve their objective. Their web browser is “the internet”, not Firefox or Edge (even the idea of a browser is a mystery), and accounting is done in a program like “Sage” (which is a company, not a product). Lots of people want and need “Adobe”, by which they mean whatever Adobe is calling their PDF viewer or editor this year (whichever one the user is using or expects to see).
Apple’s sheets UI offers a compromise, albeit a confusing one as they set a rule of their own, that sheets must never spawn child sheets. This is perfectly possible and it works fine, but Apple decided that it was wrong, so the first sub-dialog again blocks the parent window from being moved, undermining one of the advantages of having sheets in the first place.
The price of attention
Modal prompts have a well-known weakness wherein users click OK without reading the prompt or even recognising that they did so. From this, there are certain considerations to take into account.
Attention is a difficult thing to pay, and the design of the user interface must take this into account.
Unnecessary modal windows are to be avoided, to limit the extent that users are conditioned to dismiss them without paying attention to them. This does mean that the equivalent modeless notifications need to be clear and be able to show or call up more detailed information that is too large to fit within the notification.
Further, a means is needed to ensure that no serious situations are reported only by modal windows or transient notifications. Important alerts must be accompanied by log entries, and where the user was asked to make a decision, this too should be logged, so that there is recorded evidence of what decision was taken. Application and system health reporting—as seen in NAS pseudo-desktop environments—would allow alerts to remain alive even after the user has dismissed the prompt, regardless of which option was chosen.
Macintosh practice requires prompt dialog boxes to fail safe: the default button should be the safest choice. Should the user click the default button without thinking, the amount of harm possible is minimised. This also helps mitigate the problem of modal windows that appear while the user is typing get automatically accepted by the next space or enter keystroke, which is a consistent failing in Windows.
Firefox used a timed delay on the dialog box offering to run a program that was just downloaded, to ensure that the user at least sees the message before continuing. Having a timed delay on the proceed or unsafe choice on unexpected prompts is one way to ensure that the message is at least seen. This will also mitigate against the problem of modal windows appearing during typing.
Timed delay on buttons will be a nuisance in any workflow where working through lots of dialog boxes is common, as well as clearing large floods of errors from a deranged program. Repeating duplicate messages could be mitigated in other ways. Timed delay is possibly best reserved to prompts that are unexpected, that are likely to be shown during typing, and where the outcome is hazardous. For example, if the user accidentally hits Ctrl+F (Find) while typing and then the subsequent keystrokes accidentally enter some characters and search for that string, this is a nuisance but no harm will be done. Timed delay will slow down for example being able to press Ctrl+F (Find), Ctrl+V (Paste) and Enter in rapid succession to search for some text on the clipboard, as opposed to a search where the term is entered by hand where a delay in being able to accept the window will go unnoticed.
Getting out of trouble
One of the strangest decisions with Mac OS X was to abolish OK and Cancel buttons. Traditionally, changes made within a dialog box were not applied until the user clicked Apply (in Windows) or OK. (The Apply button led far too many people to believe that Apply must be clicked before OK otherwise nothing changes.) Apple decided that it made more sense for all changes to take place immediately, but no formal method seems to have been defined to get out of trouble if you made a mistake. Traditional dialog boxes always had Cancel as a fallback if you did something irreversible such as remove a record. Now, with Cancel gone, such changes would have to be repaired by figuring out how to restore the settings back to how they were. For example (and this is a real example), accidentally removing a launch item by clicking + instead of − means trying to figure out what you just removed and how to put back something that you never added in the first place.
If there is some merit to having changes within dialog boxes take place immediately (which is troublesome in itself as some changes can only be made as a set of steps that have invalid or harmful configurations as intermediate steps), there must be some way to revert the changes.
Chrome-based browsers have an interesting dialogue implementation: when filling out a form on a website, undo applies to the form as a whole instead of just the active text field. As such, you can undo each change made across a whole form. This is confusing owing to being application-level innovation, but the concept itself would apply well to dialogue interaction where changes take immediate effect.