The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

UI design: alternatives to a modal dialog box?

I'm developing a Windows desktop application, which lets the user type in 'stuff', and 'tag' their stuff with user-defined 'properties' or 'attributes'.

I'm OK with the UI to list the user-defined attribute types (I'm thinking either a table/grid, or something like a definition list), and, with the UI to assign a new instance of an attribute type to something (e.g. using a context menu, or drag-and-drop), but I'm wondering about the UI to let the user create new types of attribute.

A new type of attribute (i.e. an attribute type definition) consists of three data:

1) Name (a string, e.g. "Estimated Cost")
2) Type (an enum value, e.g. "Number" or "Duration" or "Date" or etc.)
3) Description (another string, e.g. "This is the estimated cost").

An obvious UI to enter this data is a modal dialog box:

  Name: [edit box]
  Type: [combo box]
  Description: [edit box]
    [Ok]  [Cancel]

Modal dialog boxes are a well-known UI ... but they seem a little old-school.

Are there any alternatives to a dialog-box for this application (i.e. for creating a new attribute type)? I'm thinking:

* Toolbar (probably not: toolbars are an alternative to a *modeless* dialog box like "Search"; but I don't see how to use one an alternative to a *modal* dialog box)

* PropertyGrid (probably not: a PropertyGrid is good for showing/editing the *existing* properties of an existing object; it's not obvious how to use one to create *new* properties of a new object)

* Wizard (probably not: a wizard is just a multi-pane or multi-stage modal dialog, and is overkill when there are only three simple data to be entered)

* New row in a table (as e.g. you can enter a new row in an SQL table, using the grid of table contents which you can display in the MS SQL Manager application).

* A full-screen form (for example, the 3rd screenshot instead of the 2nd at http://www.37signals.com/svn/posts/1149-modal-overlays-beyond-the-dialog-box )

Are there any other possibilities? The latest edition (2007) of _About Face_ still talks about modal dialog boxes, as if they're still the Done Thing.
Christopher Wells Send private email
Monday, August 11, 2008
 
 
Sometimes, all you need is a good wheel.

In other words, what's wrong with a modal dialog box?  Be "creative" when it helps the situation.  When you've got a good tried-and-true solution that works, why get "creative" with it?

There's LOTS of "clunky" situations to exercise your creativity on.  This situation may not be that "clunky".
AllanL5
Monday, August 11, 2008
 
 
Having said that, I assume you'll 'attach' attributes with something like a right-click drop-down box.  Couldn't you have a "new attribute" selection there?

And yes, probably that would bring up a dialog box.  I'd prefer that to a wizard, though.
AllanL5
Monday, August 11, 2008
 
 
Thanks for replying.

> In other words, what's wrong with a modal dialog box?

Not a lot, apparently, if there's no alternative!

A dialog box is non-trivial to layout so that it looks good; but that's minor ... this is a "greenfield" project and I'm not a UI expert: dialog boxes are more than 15 years old, I thought I should question any presumption that they're still the state of the art.
Christopher Wells Send private email
Monday, August 11, 2008
 
 
How about a dialog box that isn't model?  I've been burned by some software that's in a modal dialog box but I need to look at something else in the software to complete what I'm doing.  I have no problem with the dialog itself (it's perfectly reasonable to ask for small amounts of information that way) but I don't like things to be modal for no good reason.
Almost H. Anonymous Send private email
Monday, August 11, 2008
 
 
The way to use a PropertyGrid in this context:  give the user the ability to create a new object with all of its properties set to default values, and then use the PropertyGrid to change them.  This is the way Visual Studio works, to pick one obvious example:  you drag a new control into place, and then you modify it.

An advantage to this (apart from not necessitating a modal dialog) is that it removes the distinction between entering properties of a new object and modifying them on an existing object.  In short, you're always modifying properties of an existing object, so you only need one UI.
Bob Rossney Send private email
Monday, August 11, 2008
 
 
I say, rethink the business logic before rethinking the GUI.

You say you require three pieces of information: a name, a type and a description, and think the obvious choice is a modal dialog box.

Why are those three bits of data required? Why must the value be typed rather than letting it be free-form text? Create a ui that allows the user to just give a name. Put an entry box right on the main screen where they can type a name and press "new attribute" or whatever, and it creates the new attribute right there on the spot.

You can even add some smarts to guess the type if you really want typed values (eg: "Starting date" would obviously be a date, attributes with "amount" in the name would be ints, etc. 

If the user is entering data and thinks "Gee, I need a new attribute", do you really want to make them stop in their tracks and invent a description and choose a type? Just let them create the attribute with a minimum of fuss.

If it is important to the user to have a description or a type, give an additional control for specifying the other metadata. That can be a modal dialog or traditional property sheet Or, let them type it all in at once.

For example, support a mini syntax that lets them type "name:Foo type:Integer description: this is the field named foo". This lets the simplest case stay simple "I want a new attribute named Foo" while at the same time rewarding the power user who knows they need something more expressive.

In summary, don't think 'what control will I give the user to force them to enter this data'. Instead, think 'what task is the user trying to accomplish and what is the least amount of interface necessary to accomplish that task?"
Monday morning UI quarterback
Monday, August 11, 2008
 
 
+1 to the quarterback

Think of the most sensible default and just insert it into the table of attributes. Make the table support in-place edit, so that, if the default isn't enough, they can still change it.
Dotimus Send private email
Tuesday, August 12, 2008
 
 
Paper prototype it - do it right now. Then try it out with 5 or 6 users and you'll know in a few hours if it works or not.
MT Heart
Tuesday, August 12, 2008
 
 
It depends whether the data the user needs to enter is mandatory and your software can't generate defaults. Would "Name1", "Type1", etc. be acceptable to continue running the software? If so you can allow the user to enter/change it at a later date.

Tuesday, August 12, 2008
 
 
As the wise guru on the mountaintop says, it depends.

Option 1. If you’re expecting the user to define a new tag as an aside to general object management that happens to include some tagging (i.e., the existing tags are not displayed in the window but accessed by something like a context menu), then a perfectly good design is a modal dialog accessed through a New Tag menu item. Modal dialog boxes are best for simple atomic commands that take a small number of parameters. Use them when your user wants to whip something off quickly and get back to the main task at hand. They have not been improved upon.

There’s a school of thought that says you should always make dialogs modeless because modes are bad. There’s merit to that argument, but it can also result in unnecessarily complicated dialogs (e.g., you need both an OK and an Apply button). Modeless dialogs are best for when the command is done repeatedly for objects in the primary window, such as for a series of objects or when the user will evaluate and adjust the results shown in the primary window. I don’t see your app benefiting from a modeless dialog enough to offset the complication.

If the user needs to reference multiple objects in the primary window to enter parameters in a dialog, chances are you don’t want a dialog at all, modal or modeless. You want something more like Option 2.

Option 2. If you expect the user to be tagging objects or managing tags as major task itself (i.e., you’re displaying all existing tags as a table in the window), then use a new row in the table with in-place edit, maybe always leaving at least one blank row at the bottom for the user to complete whenever it’s wanted --no menu item necessary and no OK button that has to be clicked. If you’re anticipating a large number of tags such that the user would have to scroll to the bottom of the table to get the blank rows, then consider a menu item to insert a blank row. Give the menu item an accelerator; I vote for the much-maligned Insert key.

To summarize: Option 1 takes the least primary window real estate but is slower (takes more clicks). Option 2 is faster but takes more real estate (need to display table of attributes). That’s why the preferred design depends on whether working tags is incidental to other tasks (Option 1) or constitutes the main task (Option 2).

Your user needs to complete at most (up to) three parameters (assuming defaults are provided). That pretty much rules out a tool bar, wizard, or full-screen form. Can’t see setting three parameters in a tool bar. Wizards are best for complicated branching many-parameter tasks that are rarely done by the user; otherwise they add too much work. A full screen form only makes sense when you have a full screen of parameters. Certainly eliminate parameters the user really doesn’t need, but a mini-syntax solution doesn’t sound right here. When defaults are good, it saves one click over a modal dialog, but when defaults need to be changed, it’s slower, more error prone, and imposes a greater mental burden. Unlikely to be a good tradeoff.

The idea that just because something is old, it must be obsolete is a crock. Do not make something new just to be new. This doesn’t help your users. Wizards are newer than modal dialogs, but that doesn’t make them better. They were invented to cover a (relatively uncommon) need that older design elements missed. Modal overlays and “lightboxes” are new but are also junk, having no advantage over traditional modal dialogs, and serious disadvantages.
Michael Zuschlag Send private email
Tuesday, August 12, 2008
 
 
The software wouldn't care if the name is called "Name1", but that would be a stupid name from the user's POV.

The type must be one of a predefined selection (eg. "Number", etc.), because the software has different processing for different types. I could guess a type, i.e., pick a default, but I don't know which.

Good things about a dialog include:

* It's obvious that *something* needs to be entered (i.e. there's a modal dialog box, not just a modeless property grid docked away somewhere near the end of the window)

* It's obvious *what* needs to be entered (i.e., all fields on the dialog)

* I can oblige the user to enter the data (by not enabling the [Save] button until it's entered)

Another way to choose the type might be by using an extra level of menu item, e.g.:

  New Tag Type...
      Number
      Date
      String

I suppose I'll go with the dialog. Thanks for your suggestions.
Christopher Wells Send private email
Tuesday, August 12, 2008
 
 
> As the wise guru on the mountaintop says, it depends. Option 1. ...

That's a good summary, Michael; thank you.

> Option 2.

That a usual solution for tables or grids. I suppose that, then, validation of any newly-entered data happens as described in http://discuss.joelonsoftware.com/default.asp?joel.3.665570.4

I also wanted to consider displaying the data like headings with a definition list, instead of as a table ... because it might be easier to read.

<h2>Cost (estimated)</h2>
<dl>
<dt>Type</dt><dd>Number</dd>
<dt>Description</dt><dd>This is the estimated cost.</dd>
</dl>
<h2>... etc ...

(In the above, the text within the <h2> and <dd> would be editable-in-place, but the structure of the tags and the text inside in the <dt> would be read-only).

> When defaults are good, it saves one click over a modal dialog, but when defaults need to be changed, it’s slower, more error prone, and imposes a greater mental burden.

So, you're against the software's (or rather, the application designer's) arbitrarily choosing a default value ... except when the guess as to what value the user wants is a *good* guess, that's likely to be right and not need changing.
Christopher Wells Send private email
Tuesday, August 12, 2008
 
 
Re extra menu level: As you probably figured out, given that users need a dialog anyway to specify a Name that makes sense to them, making Tag Type a cascade menu doesn’t save the user any work, especially if the dialog uses option buttons for the Tag Type (not a combo box). Meanwhile, the cascade menu reduces flexibility (it fixes the order of parameter input) and self-documentation (no label saying what number-date-string applies to).

Re definition list: It’s hard for me to imagine a definition list being more readable than a table, unless the display area is narrow or the description tends towards paragraph size.

Re defaults: Actually I’m generally in favor of defaults in dialogs even if there’s a low chance of them being right. Assuming the effort to change a default is no more than to change a blank value (usually the case), then even being right only 10% of the time saves the user 10% of the work. Also, defaults can be used to help the user see what _kind_ of input is expected. “Name: ____” means what? Should the user enter his/her own name? “Name: New Tag” provides a smidgeon of self-documentation (maybe not enough to be worth it in this particular case). I was just pointing out that for this app the gains in efficiency that mini-syntax provides when the defaults are right probably doesn’t justify the efficiency, clarity, and tolerance losses when defaults are wrong.
Michael Zuschlag Send private email
Tuesday, August 12, 2008
 
 
> Re definition list: It’s hard for me to imagine a definition list being more readable than a table ...

The table's columns contain user-entered text (Name and Description), which is of varying (perhaps unlimited) length. If the user enters one string that's a fair bit lnger than another (for example a short description for one item and a much longer description for another), then ...

a) The table's column width must be extremely wide (wide enough for the longest string); having wide columns makes it difficult to read the table *horizontally* (it's well-known that lines of text shouldn't be too long; the table's having horizontal rules will help, but imperfectly)

b) Or, text must be truncated (to fit in the narrow column)

c) Or, long text should line-wrap in a column; short text in other rows wouldn't line-wrap, so therefore some rows would be deeper (more vertical lines of text) than others, which makes it harder to read the table *vertically*

I think that the format I suggested might make it easier to:

* Instantly recognise the structure of the text (i.e., it's a sequence of headings, each with associated details)

* Scan the page vertically to find the heading of interest

* Accomodate long descriptions (which can occupy nearly the whole page/column width)

I suspect that people have read more paragraphs and sections and so on in their lives than they've read tables; you won't need to read table column headings and then remember which column is which.

I think that tables work best for items which have some constant or finite length, like country names, or numbers.

Anyway, I hope to try both.

> ... especially if the dialog uses option buttons for the Tag Type (not a combo box).

> Actually I’m generally in favor of defaults in dialogs ...

> “Name: New Tag” provides a smidgeon of self-documentation ...

Yes. Thanks again, for those suggestions. You seem to me to be fairly fluent/expert with UI design choices/details.
Christopher Wells Send private email
Tuesday, August 12, 2008
 
 
Ok.  Quick.  Open MS Access.  Create a new table.  Go to design view.  Type in the first field name.  Change the field type if the default is incorrect.  Then add a description if you feel like it.  Then repeat.

Sound familiar?  That's your interface.

BTW, the field type default is user definable.

Just a thought.
Gecko Send private email
Tuesday, August 12, 2008
 
 
To extend the MS Access example a little bit...

You could add 'Intellisense' to the Name field.
Gecko Send private email
Tuesday, August 12, 2008
 
 
You could have a tab for adding the new data.
This would contain 3 input boxes for each of
the fields. And a submit button. You can edit
the fields how you like; when submit is pressed
it inserts Filed1=Name1, F2=N2, F3=N3 into
the list or MsgBox's an error. Would that be
any good?
Object Hater
Wednesday, August 13, 2008
 
 
just for the sake of argument for "Are there any alternatives to a dialog-box" question...

Imagine the required user input is already collected with a "different technology": command-line utility, HTML page, AJAX-heavy web site, import from excel, e-mail, phone conversation with operator etc.

Would it be possible in desktop application to mimic user experience identically or very close to that one?

What can be done better in different technology?

Is it possible to mix-and-match the best elements of user experience?
DK
Thursday, August 14, 2008
 
 
Yes, we must use dialogs.

Users never want to go back and review other data before adding new data, so we can "oblige" them to fill in the dialog before permitting them to review existing data, or we can oblige them to write stuff on paper so they remember what goes in all the dialog boxes if they insist on cancelling the dialog box.

Thursday, August 14, 2008
 
 
>“The format I suggested might make it easier to… accommodate long descriptions”

Yes, I see. If you’re expecting long descriptions, then your definition format is probably better than a table. It looks like you plan to use large or bold font for the Name field, which addresses concerns about scanability. The use of font attributes to provide a visual hierarchy is a common web practice that desktop apps should emulate.

Do you expect users to compare or select multiple tag fields? Will descriptions usually be very long (paragraph or more)? If so, one other design option you might want to consider is to use a table for Name and Type and to put the Description field in a separate overflow detail pane beside the table. The detail pane shows only the Description for the table row that currently has focus (for more see http://www.zuschlogin.com/?p=31, scroll down to “Return of the Master-Detail” to cut to the chase). This allows for a large number of tags to be in view for comparison and selection, while the description can be very long. However, the description field pretty much loses all scanability. Just a thought.

If you _do_ use a table, of course make the column headings vertically fixed while the rows scroll underneath in a separate division. Headings that scroll out of view is a common web practice that desktop apps _shouldn’t_ emulate.
Michael Zuschlag Send private email
Friday, August 15, 2008
 
 
Modal dialogues in general are pretty bad.

Read this, it's kind of related:

http://humanized.com/weblog/2007/07/18/never_use_a_warning_when_you_mean_undo/

Then read this, which will change your view of interfaces forever:

http://humanized.com/weblog/
Ken Sharpe Send private email
Friday, August 15, 2008
 
 
> It looks like you plan to use large or bold font for the Name field, which addresses concerns about scanability.

Yes, that's what I meant when I put the 'name' value within <h2>...</h2> tags: the name (e.g. "Cost" in the example below) has a heading-style appearance.

  <h2>Cost (estimated)</h2>
  <dl>
  <dt>Type</dt><dd>Number</dd>
  <dt>Description</dt><dd>This is the estimated cost.</dd>
  </dl>
  <h2>... etc ...

> The use of font attributes to provide a visual hierarchy is a common web practice that desktop apps should emulate.

Until recently (i.e. "WPF") it hasn't been easy do that in a dynamic Windows desktop UI.

I might one day want a web/browser client UI, and web UIs tend to be easy to learn. For these reasons I'm designing the desktop UI with the thought, "what would this be like if it were an idealised web UI?"

> ... Just a thought.

Yes. Some day I'd like to read all your blog (I've spent the last day or two reading _Questionable Content_, which I found via your site, which I'm happy about; I like the way it shows that emotions are contagious, e.g. if one person gets anxious then so do the people they're with, ditto 'sassy' and other emotions).

> Headings that scroll out of view is a common web practice that desktop apps _shouldn’t_ emulate.

A 'user agent' (i.e. a browser) could make that its default behaviour when rendering and scrolling tables ... desktop browsers typically don't afaik, but maybe some for small-form-factor devices (which expect to need to scroll more) might.
Christopher Wells Send private email
Friday, August 15, 2008
 
 
> never_use_a_warning_when_you_mean_undo

Yes, that one of the presciptions in _About Face_. Two others are:

1) Don't use a modal dialog when it should be modeless

2) Consider alternatives to modeless dialogs, e.g. toolbar controls

> Then read this, which will change your view of interfaces forever

All of it? Or are there some particular posts which especially impressed you?
Christopher Wells Send private email
Friday, August 15, 2008
 
 
"... dialog boxes are more than 15 years old, I thought I should question any presumption that they're still the state of the art."

Don't stop there: invent something new to replace that clunky old keyboard. Heck, that's *hundreds* of years old! Much better to replace it with something that requires lots of hand waving and finger-pinching movements. Yeah.
Vaughan Send private email
Tuesday, August 19, 2008
 
 
You dont say if the 'stuff typed in' is one to one with the attributes (1 thing typed in, one attrib) or one to many (1 thing typed in many attributes).

I would assume the latter and use a datagridview.  This allows switching of data sources (your data set).

If you dont want to use a pre-bult control, then just work with the dataset directly and a multicolumn list.
andyw Send private email
Tuesday, August 19, 2008
 
 
> Don't stop there: invent something new to replace that clunky old keyboard.

Look, the last time I did a UI was Win2K; it's not that unreasonable I think to wonder whether a new windows style has been discovered since then.

Actually I've just found http://msdn.microsoft.com/en-us/library/aa511258.aspx (the "Wndows Vista User Experience Guidelines" in general), and http://msdn.microsoft.com/en-us/library/aa511268.aspx (related to dialog boxes in particular).

> Much better to replace it with something that requires lots of hand waving and finger-pinching movements.

You're thinking of Johmy Mnemonic, I guess; but a few years ago I did see someone's tablet PC.
Christopher Wells Send private email
Tuesday, August 19, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz