Dialog boxes are used in
Modal Dialogs
A modal dialog box breaks the editing process of the document and forces the user work in the context of a dialog box. While the modal dialog is open, the user is expected to change settings of either document elements or the of the state of the application.
Contents
Modal dialog boxes contain a variety of interface components.
Two buttons are always needed. Cancel should close the dialog box with zero effect on the document or the application, returning the the previous state. OK should accept all changes and close the modal dialog box. Typically, OK should be the default button.
The typical dialog layout follows an information flow from the top left to the bottom right.
The OK button should be at the bottom right, and the Cancel button next to it on its left side.
Overlapping dialog boxes vs. Tab Pages in a single dialog box
In many cases, a modal dialog lets users open an additional modal dialog box from within.
In general, this is not recommended. It leads to a cluttered screen. However, you may do so to hide special settings of secondary importance and there are many cases in Archicad for this behaviour.
Make sure that the any subdialogs are opened in a default position so that the subdialog is neither fully within the mother dialog box nor fully outside of it. This makes the logical relation of the two very apparent. Plus, the subdialog must overlap the OK and Cancel buttons of the mother dialog. Otherwise, the user would see two OK and Cancel buttons at a time on the screen, which is a very ambiguous situation.
We recommend that you consider using tabbed dialog boxes instead of opening subdialogs. Tab pages with appropriate tab titles and proper structuring will work fine in most situations which otherwise would require subdialogs.
Resizing of dialog boxes
If a dialog box has items which display a changing number of user defined elements, like a scrolling list of layers, the dialog must be resizable. The growth of the dialog box should be applied to these items.
Selection indicator
Dialog boxes which apply changes on selected elements should have an indicator that informs users about the number of all selected elements and the number of elements within the selection which can actually be changed through this dialog box.
Modeless Dialogs
Modeless dialogs let users interact with the documents while being open. API-based Add-Ons CANNOT handle modeless dialog boxes. Use Palettes instead.
This service of the Dialog Manager is only accessible for separate applications developed with it.
Palette Dialogs
Palettes are modeless types of dialogs which can be open for an extended period of time. They do not break user interaction with the documents.
They can do good service when similar changes are made to or information is displayed about various groups of selected elements.
Accepting changes
Palettes can work in two ways. First, any setting you change within the palette can be immediately effective. An example of this is the Info Box in Archicad. Select a wall, change the fill, and the new fill is immediately visible in the document window. (In case of text fields, like a wall elevation value, Archicad waits until you continue working in the document window or press the Enter key, but this is perceived by users as “instant” change.)
Second, a palette can provide an Apply button to execute any changes you have made. An example of this is the Camera Settings palette of Archicad. In this case, changes you made in the dialog box are lost if you proceed without clicking Apply. This is a safer method against accidental changes, though the need for this extra step can be annoying for very conscious users who have a low error rate anyway.
Palette size
Keep in mind that as palettes give the user access to the document windows, they should not be as large as to hide lots of useful document content.
If a palette is to stay always on-screen, like a specialized toolbox, make it narrow or flat, so that it fits the standard Archicad palettes well and can be positioned alongside the document windows.
Palettes which are user for a task then closed, are not so sensitive to shape. The Spell Checker palette of Archicad, for example, is not narrow or flat, but leaves enough space for viewing the document while being open.
Tab Pages
Alert Boxes
Alerts are a special case of modal dialog boxes which are used whenever an application needs the user’s attention and response.
Alerts are a bad necessity, as they break the normal flow of user actions, and most likely, their flow of ideas. Users tend to spend a minimal amount of time reading alerts, so straightforward and consistent wording is essential.
Make sure that alerts do not ask indirect or ambiguous questions.
Even though alert may be annoying sometimes, it is always better to inform the user about problematic situations than not. With good phrasing, they educate users how to avoid the problem the next time.
When no alert is needed
Keep in mind that alerts are not welcome by users. In case of very “light” problems use a simple beep, especially if the user has other clues of the reason of the problem.
For example, a command that modifies selected elements can find elements which are locked (either by layer or individually). These elements are marked by gray selection dots anyway, indicating that they are ineditable. So, let the command change just the editable ones with no sign of error.
In the above example, if all selected elements are locked, it is fine just to use the error sound without opening an alert.
Types of alert boxes
Note/Information
This is the lowest level of alerts. It displays non-threatening information. Typically has a single OK button to acknowledge the information.
Caution/Warning
This alert requires a user decision. This can be either to cancel an action or continue, or choose from various ways of going on. It typically has two or three buttons.
A Cancel button is required to close the alert with no change or loss of data.
Stop/Error
Use this alert to tell the user that an action could not be completed.
Use wording that makes clear what went wrong, why, and what to do next to avoid this happening again.
Do It-Cancel or Yes-No?
Though a question with Yes and No buttons may seem to be a good universal solution, it is actually not. It requires very careful reading, which users tend to skip, and gives no clue which button does what.
We recommend that the button used to actually complete the action is phrased as a verb. Use the same verb as you used in the question. So, just reading the text of a single button will give the user a clue what would happen if clicked.
Content
Texts
An alert has up to two text fields to inform the user about the situation, and up to three buttons to choose from various resolutions.
Use the Large Text field for a short statement or simple question. This text alone should give sufficient info for the experienced user to be fully aware of the problem.
Use the Small Text field to provide further explanation of the context or to give advice for using the different buttons.
Buttons
Button 1 is on the right. This is the default button that is operated by pressing Enter on the keyboard.
If it has no text, it will be not displayed and Button 2 will take its place. In this case, the alert will have no default button.
This might be useful in very dangerous situations when you want to avoid even the chance to close the alert with an accidental hit of the Enter key.
Use Button 2 as the Cancel button to close the alert and return to the previous state of the document.
Use Button 3 to give an optional third way to close the alert.
Undoability
As users have a tendency to close alerts without too much thinking, avoid making changes which are not undoable. Then, even if choosing the wrong way, users can have a remedy.
If an alert leads to changes which are not undoable, use very explicit phrasing like “This action is not undoable.”
Special cases of alert messages
The alert box types work fine in most cases. If used, all layouting etc. will be done by the API automatically. If for any reason an Add-On needs a complex error message with more than three buttons or additional dialog items like a pop-up menu, create a modal dialog instead.
Remember that for the user, it will still be an alert by function, so the above guidelines should be applied. In this case the Add-On developer is responsible for making the dialog box look and feel similar to the standard alert boxes.