What is the best practice for form and dialog placement on single and multi-monitor systems?

Question

I'm having a sort out of my (Delphi) applications and I been visiting the floating form size and location persistence which seems to be increasingly important with larger screen real-estate and multi-monitors. Clearly it is often desireable to have a user's form reopen in the same place as they closed it, but maybe not always, for example a modal dialog might justify opening bang in front of the users vision, i.e on the primary monitor center screen. There seems to be little out there on the 'net about this and commercial applications seem inconsistent especially regarding multiple monitors. So, a few (probably contravertial!) rules to get us started...

• Non-modal forms should always reopen at the size and location of closure.
• Modal forms (i.e with OK/cancel, Yes/No buttons) should reopen at the previous size (if sizeable), but inthe center of the monitor on which the application resides.
• An information message box should open in the center of the monitor on which the application resides.
• A warning or error dialog should open in the center of the primary monitor.

Thanks in advance, Brian

Answer 1

"Non-modal forms should always reopen at the size and location of closure."

They must have a default position and size when they first open. Do you have any rules about this?

I would add the qualifier: If the screen resolution/monitor count is different from the last time this form was opened, then it reverts to default position. So no inaccessible forms restored 400 pixels to the right and below the screen area.

"A warning or error dialog should open in the centre of the primary monitor."

I don't understand why you move the messagebox from 'monitor where the app resides' (henceforth MWTAR) to the primary monitor. You know the punter is looking at the MWTAR; after all he has just done something 'bad'. Why are you changing monitors now you have something important to say?

(After all, if it is an error dialog containing useful diagnostics, he won't read it anyway. I don't see the need to hide it from him.)

A further thought. One problem with error modal dialogs is that, wherever they pop up, the user may hit 'Enter' accidentally while typing something else and dismiss it. I know I do this quite often.

One trick I have seen to overcome this is to disable the Ok button when the dialog is first displayed. There is a 3 second timer in the dialog which counts down, displaying the time remaining in a small label attached to the button. So the punter knows he will be able to dismiss the thing soon.

Obviously this must be used very, very sparingly, and only on the rarest and most important of dialogs. But it struck me as quite clever. Perhaps all that needs doing is to make Ok the default button after three seconds.

Answer 2

Depending on the platform, when the application does not have focus when throwing up an alert it should avoid taking focus. Too easy for a user typing to dismiss the alert without any chance to read it.

E.g. on Windows make use of the ability to flash a task bar button.

Answer 3

A dialog should never open in the center of the monitor. Consider one of the 30" monitors with 2560 x 1600 pixels resolution - using an application maximized on one of these monitors makes sense only in very specific cases. If an application form resides in one of the corners of that huge screen area then the user would need to move the mouse cursor from its current location to the center of the screen, and back after dismissing the dialog. Also, with a normal viewing distance it's probably impossible to have all of that screen in view at the same time, so center of the active window will be more "in front of the users vision" than the screen center. Any dialog that doesn't remember its position should open centered on its parent window. Exceptions should be made for dialogs that are bigger than their parent window (where it makes sense to leave a bit of the parent visible, which makes it more obvious for the user what's going on), and property pages that should appear near the objects they apply to.

I would also think about saving screen positions in percent of the screen area, not in pixels. This way using a laptop with and without a large external screen will always make optimum use of the screen area - using absolute coordinates will either have portions of the screen unused, or windows moved outside of the visible area.