I'm not a big fan of dialog windows and other windows popping up both in reaction to user actions and, especially, unasked for. Dialogs that do not properly use all the space available although they would benefit from it (such as configuration dialogs of complex programs), and instead may open further dialogs, are particularly annoying. So are tiny dialogs with a very direct connection to the main window (such as a ‘find’ operation), as well as non-critical message popups. In many cases these windows could be replaced by something much less obtrusive, less out-of-place, something better integrated into the application or document window. This essay discusses those possibilities.

1. One good alternative to dialogs is the “minibuffer” or “query line” featured in many text editors and the Ion window manager as well (although in Ion it feels a bit like a dialog, as there's no window to be part of). Minibuffer-queries can not comfortably replace all dialogs, but are particularly well suited to tasks where the dialog has to interact with the main document window.

An excellent example of the superiority of minibuffers over dialogs is the ‘find’ operation, for finding text within a document. For this operation, a separate dialog window is very cumbersome, demanding meticulous placement to not hide important areas of the document; there often being focus problems especially with the sloppy focus model; and, of course, the dialog simply feeling “wrong”, it having the focus instead of the main window where most of the action is. Contrast this with space being allocated e.g. at the bottom of the window – possibly shrinking the document viewing area – to display the very few necessary controls and information needed for this operation, as is done in many good old *nix text editors, and infact Firefox as well these days. (This is one of the few good things that can be said about Firefox. Unfortunately, keyboard access to all the features of the ‘find’ query is severely lacking and buggy.) Opera can also use a small ‘tooltip’ type window for its inline search, but this is not as complete as Firefox's (although less buggy).

While not strictly dialogs, an approach similar to the above is also preferrable to free-floating windows for toolboxes and the like (in pointing device-oriented applications, such as painting programs, as opposed to keyboard-oriented programs that do not benefit from toolboxes). A possibly even better approach would be to not constantly display those toolboxes, but open them near the pointer when a modifier key is held down. The result would be a bit like a conventional popup menu, but taking full advantage of the keyboard and the other free hand. (Some of the better interfaces for pointing device-oriented applications, such as Blender and FPS games, do almost depend on two-handed keyboard-mouse co-operation.)

2. A small status line within the main document window should likewise work well for some non-urgent or unimportant warning and error messages and notifications. The feasibility of approach is demonstrated – quite aptly indeed – by the “popup blocked” notifiers of Firefox displayed at the top of a page. Urgent and important messages, however, demand something more obtrusive. In cases such as a Web browser, there's a simple and occasionally used solution for some errors: displaying a new page with the error message. Perhaps this approach could work with some other classes of programs and errors as well, but with some improvements, the conventional popup dialog is also an option.

First of all, a message specific to some window or document, is seldom important until that object is accessed again, and thus the message should not clutter the overall operating environment by popping up a new top-level window. The approach taken in Ion alleviates this problem: by opening a dialog marked as a “transient window” within its indicated main window, the dialog does not obstruct other work until one tries to switch to the main window in question. That such a (hidden) window has been opened, is also indicated by the tab of the window changing colour and, when the window is on another workspace, a small unobtrusive hint at a corner of the screen.
Presently in Ion, the dialog window is, however, opened at the bottom of the main window by default, a behaviour that is useful for providing an approximation of query lines for dialogs that would be better implemented that way. Warning and error messages would, on the other hand, benefit from a more prominent placement, and this can only be done automatically if the window manager knows the “role” of the window. While the FDO EWMH specification infact does provide a window type property, the standard types – as almost everything in FDO specifications – are mostly related to fine-tuning the WIMP desktop mess, and do not provide enough abstract, semantic information.

Infact, when the main window is big enough to display the whole message, it would be possible to simply take the window manager out of the equation, and have the program display the message itself within the main window; to have the window manager only manage main document windows that programs would consider to amount to the full screen reserved to themselves. However, unless we make assumptions on the environment (this usually being a mistake), small main windows would in any case need to let the window manager handle their messages in a manner best suited to the environment. Of course, such gory details can be hidden by raising the abstraction level, as in the Vis proposal.

There also needs to be a way of delivering non-urgent messages without an associated main window to the user. This could be done with an unobtrusive translucent window in a corner of the screen, listing recent messages (possibly including those with an associated main window, as Ion already does indicate opened transient windows), supposing there was a decent messaging system that programs could use (possibly integrated with syslog). The same message area could be used for urgent messages as well by making those stand out, thus eliminating annoying popups. Some key combination could then be used to select messages to inspect in more detail in an appropriate window – possibly launching a program opening a new window.

3. Configuration dialogs could often be replaced by “configuration documents” – I shall explain the concept along the way. Aside from doing away with yet another out-of-place window (and further sub-dialogs) in applications that already display documents (possibly in a tabbed manner), configuration documents can also offer various other benefits over the cumbersome disarrays of widgets that the configuration dialogs of WIMP programs are. I do not know many programs that presently take the configuration document approach to any degree and none of the implementations is quite at what I'm after, yet. In any case, at least the customisation buffers of Emacs and the somewhat hidden opera:config page of of Opera could be said to be configuration documents, and the configuration interface of Azureus is an intermediate step between configuration documents and dialogs.

Azureus simply displays a conventional widget-based configuration dialog as a tabbed document within its main window, so it does not offer many other benefits over a separate dialog window, other than the nicer, more integrated feel of it (and non-modality). The explanations of some of the configuration options are also a bit lengthier than in normal smaller configuration dialogs, however, and this is one of the advantages of configuration documents: self-documentation.

Emacs' customisation buffers take a much more document-like approach, but unfortunately the result is very clunky and unpolished as everything in Emacs, with it additionally being cumbersome to navigate from one customisation page to another akin to most GNU ‘info’ browsers. The explanations of some some options are also severely lacking, but in principle there could be very extensive documentation of every option contained in configuration documents of the Emacs kind. These customisation buffers of Emacs are also searchable, of course, which is a big advantage over entirely widget-based dialogs. In essence, a good configuration document is a well-commented configuration file, with the editor only supporting editing the values of different settings, and highlighting these parts of the file, by different colouring or by using text input widgets for these parts. There may, of course, also be support for ‘folds’ and such used to show and expand only some parts of the document, and links to other configuration documents.

Infact, a good configuration document is not that far from a well laid out Web form combined with a browser with good search and navigation capabilities (history-oriented as in Web browsers and unlike in ‘info’ browsers). Opera's approach in the location opera:config is closest to this – it is a Web browser, after all – but it also still demands some polish in keyboard support and integration of documentation. (Firefox's about:config variable listing I do not consider a configuration document.) And since many Web applications obviously use HTML pages for configuration, perhaps it would also be possible to extend our so far short list by a few rare specimens among these that do not resort to Javascript/dynamic HTML/Web 2.0 anti-usability techniques. Such excess dynamism is not suited to documents, and usually seems to be aimed at doing the exact opposite of our objective here: to recreate the widget-based configuration dialog within a HTML document.

4. The above cases of small document-related dialogs, warning dialogs and (application-related) configuration dialogs cover a lot of ground, but there's still an important class of dialogs left: the bigger document-related dialogs, such as those for opening and saving files, and printing the document. Often a simple “minibuffer” would be enough for saving and opening files, and indeed many *nix text editors use this approach. But at other times, there's so much information to be viewed in the directory tree, that the dialog might be considered a full document. So how to balance these aspects and remove the annoying popup?

Although the particulars of many present file dialogs have a lot wrong in them, I do not have to present an approach all that different from the widespread one in a general sense. Minor improvements are nevertheless possible, and certainly the ones already discussed with regard to placement of dialogs in Ion within the main window are an improvement over the more common approach of placing these windows in the general mess among all the other windows. When the application itself has a tabbed document interface, further improvements would be gained by placing the window within the related tab (so that a dialog for the document in one tab does not obstruct the contents of the rest). When opening a new document, the file opening dialog (possibly a file manager of the user's choosing, including a special type of shell) could likewise be opened already in a new tab.

In a sense, the dialog would become a sub-document of the document it is related to. This often seems semantically slightly incorrect (as in the file and print dialog examples), and infact the exact opposite would seem more correct: in a sense “zooming out” from the main document to display (a part of) the bigger picture; or perhaps switching to another view of the document (from “edit” view to “save” view, and so on). But in practise the difference to the sub-document picture is mostly semantical, although the picture of different views of the document allows for quite a different kind of implementation and graphical outlook, and is perhaps more closely related to the minibuffer alternative for small dialogs.