Non-modal user interface

// Published 31 May 2006 // 6 Comment(s) //

The user interface of the new product that I am currently working on will be almost completely non-modal. This is of course only a minor feature, a goodie, rather than its unique value proposition. ;)

In fact, this has evolved by accident rather than by design. In the process of designing the software (an activity that is not separate from development in my case) quite a few instances already occurred, and continue to occur, where by conventional wisdom I would just pop up a message box, a confirmation dialog, or design a small dialog window for details of the current user task.

Message boxes and dialogs break the user flow and take away the system focus (annoying when you scroll through a list or type text), and so I (and many users) despise them.

Are you sure you want to...?

For confirmations where I really want the user to think twice (very rare, I usually tend to trust the user's decision if he already took the trouble to click a button...), drop-down menus very nicely replace yes/no confirmation message boxes:

Information bars

I implemented flashing information bars (as can be found in the current generation of Internet Explorer and Mozilla Firefox web browsers) which pop up at the bottom of the application window for a couple of other events that would typically produce a message box or dialog:

Wizards

More complex dialogs (such as Options) and wizards are completely integrated into the document window management of the application and are thus non-modal, too:

Standard dialogs

I have no plans to waste time replacing standard dialogs such as Open File, Save File, Print, Page Setup or Print Preview at this point. There would be a very real risk that usability might suffer unduly (people already know how to operate these dialogs) and my intention is not to be religious about non-modal user interfaces, but to avoid breaking the user flow or stealing the focus. The product is meant as a productivity booster for a certain type of task, it is targeting power users, so the main purpose of these experiments is for the software to get out of the way.

Archives Categories

03:12 / 29 Aug 2006:

... I recently came across this blog entry which talks about an entirely modeless application, with some very clever ways of getting around things which are typically modal: using menus for "are you sure" type questions and information bars for warnings are great ideas.

This kind of got my creative juices flowing. Surely there were places in Humanis which could benefit from being less intrusive and not require pop up dialog boxes! And, indeed, there are. I didn't go looking for them, really, and the one that I want to talk about today just sort of came out of a brainstorming session that I had with James...

16:10 / 12 Jun 2006:

Good work!

Philipp Schumann
07:03 / 12 Jun 2006:

No third party UI library; it's my own code.

I've also been asked who did the icons; well these are stock icons and the bulk of them is from --- fantastic work, I'm very impressed with these icons and if my product works out I'm planning on some heavy donations... ;)

20:19 / 11 Jun 2006:

Hi Philipp,

Really nice UI. Could you say which UI lib are you using for the tabbed Windows?

Thanks in advance.

Philipp Schumann
16:30 / 01 Jun 2006:

That's a good point. There won't be much data entry to my product but I noticed that issue as well. Right now what I do is taking care that none of the six menu accessors is overwritten by controls within the application' forms (panels). I also largely confine accessor keys in these forms/panels to group boxes so the keyboard user will have to tab within these group boxes but that wouldn't be the most usable solution for classical raw data entry forms.

Joe
16:21 / 01 Jun 2006:

One thing I do find modal dialogs useful for is data entry forms. Putting them in a dialog means you can have more access keys without conflicting with access keys on the main form.