2010 Task Dialogs

A thank you to Steve Stafford, long time Revit user and blogger, for catching an instance of an effort to improve task dialogs. Part of adopting the 2010 shared interface components included new style task dialogs. Part of this update included a new consistent look and feel. An inventory found there were over 12 incarnations of a Revit task dialog with 400+ instances.  The prospect of presenting a consistent appearance was seen as a positive move.

Pre 2010 task dialogs

The other, more critical part, was the dialog content.  This part of the effort concentrated on improving the language and workflow.  Many task dialogs had confusing language or presented unclear choices. Some of these dialogs would cause an individual with experience to pause and left a new user running for their BIM manager. First some guidelines were laid down. One primary principle stated:

“Task dialogs should be informal, helpful and consultative in tone. They should politely provide information that is clear and informative to the user, and that can be acted upon accordingly with confidence. All other principles are subservient to the need to provide clear and helpful guidance.”

Some items used in evaluating a task dialog:

• Is the wording terse or condescending?
• Is the wording awkward or confusing in anyway?
• Does it provide all the information needed to take informed action?
• Is the information too technical or jargon-filled to be understood by the target user?

Each instance was reviewed per these guidelines and to also ensure it used clear sentence structure and grammar.  We were fortunate to have a designer with a technical writing background.  Some additional guidelines:

• Use present tense 99% of the time (do not say something “will” happen)
• Use active voice (not passive).
• Do not use the word “please” in a message.
• Do not use the word “may” or “may not” in a message, use might, can, or cannot instead.
• Do not use the word “wish” in a message, use “want” instead.
• Use only one space after a period if you have more than one sentence.
• Do not use an exclamation point (!) in a message.

Examples

Steve mentioned the “unresolved references” dialog here. Let’s take a closer look at a couple others that show a range of change.

Inconsistent Groups

Model edits can occasionally cause one instance of a Revit group to become inconsistent. This breaks the concept of a group and therefore requires attention.  These cases would first post a warning where the user could “cancel” or choose to “fix the group”.  When they choose the later they would see this:

 

First off four choices is a lot.  The first two options seem reasonable but the second two create more questions.

• What is an inconsistent member?  Is it a group member?
• If I remove/delete elements from the problem group will they be removed/deleted from all groups?
• Why does it mention family?

The solution involved optimizing the underlying code to remove the least frequent and most confusing choices then reword the remaining choices to include supporting details.
New dialog:

 

Not a drastic change but simpler and more informative. The language is consultative and the subtext provides additional information that can be read if needed but does not compete with the main command links.  Here is a better and contrasting example:

Save to central (2010 Synchronize with central)

A user opens a workshared file and makes changes to the project that causes elements to become editable to them.  They then close the project and see this:

Issues:

• While minor, the dialog lacks a clean layout
• The message orders the viewer to “Save to Central” but then states what will occur if they choose “Relinquish” which is not a button choice.  Choices are: “Relinquish & Save” or “Don’t Relinquish”
• Does “Relinquish & Save” save locally or to central?
• The title of the dialog suggests “Save to central…” but doesn’t communicate the issue.

BTW the most common task dialog title in R2009 was “Revit”…Not very descriptive at all. All 2010 titles are now unique and descriptive.

This work sharing task dialog would stop anyone in their tracks.  Careful analysis identified six distinctive tasks:

• Save all work to central (1)
• Save local file and:
  • maintain ownership of all checked out elements (2)
  • relinquish all unchanged elements (3)
• Close project (i.e., do not save the project) and:
  • lose all changes since last save and maintain ownership of all elements (4)
  • lose all changes since last save and relinquish all elements (5)
• Cancel back to project (6)

2010 re-design:

The dialog now asks a question which starts the viewer down a path.

 

• Three choices are presented and if the viewer has previously Synchronized with Central the first choice is hidden so only two are shown.
• The dialog title is changed to communicate the issue it is meant to resolve.
• The frequent and desired choice “Synchronize with central” is the default command link.
• The second two choices launch an additional task dialog.

Select “Save locally” and the “Save Changes to Local File” task dialog displays:

 

Select “Do not save the project” in the Changes Not Saved dialog and this task dialog displays:

 

In this example, unlike the first, more dialogs/choices are used.  This required mapping all the tasks and their sequence then displaying the choices progressively so that the viewer is not burdened upfront with multiple simultaneous decisions.

Summary

The task dialog project dealt with over 400 task dialogs on varying levels. Approximately 60 high impact/frequency instances were extensively reworked. An additional 28 were deemed superfluous and removed altogether!  The remaining were converted to the new format but left with their content unchanged.  We are always looking for additional cases, especially ones that are particularly confusing or encountered frequently.

_erik

Comments

[Steve Stafford]

If you'd like another "task oriented" message or GUI issue to fix take a look at this one:

http://revitoped.blogspot.com/2007/07/print-preview-printclose-closequit.html

The language on the print preview window is misleading.

[Tom Vollaro]

Agreed. This one trips people up all the time. Thanks for calling attention to it.

[Tim Waldock]

Generally speaking I like the changes you have made to dialog boxes as described, BUT The example above of simplifying the inconsistent groups message is ringing alarm bells - You state that "The first two options seem reasonable but the second two create more questions. . . . The solution involved optimizing the underlying code to remove the least frequent and most confusing choices then reword the remaining choices to include supporting details." Well it just so happens that I tell my users NEVER select the first option (Ungroup), use option 3 instead (remove inconsistent elements from group) because that is the one least likely to destroy the model. Yes it would be good to know whether it refers to all groups, but why not just tell us. The real problem with that dialog box was that it did not give enough information, nor the option to find out which instance of the group it was referring to (Name and ID Please)
I have not tested v2010 to see if this is how you have implemented it (not easy to force the message), but I am seriously worried by it.

Please do not make assumptions about how we want to use the software, particularly if it subsequently limits how we can use it.

[Tom Vollaro]

Tim, If you find any new cases definitely let me know but from known examples we had collected the code was improved to eliminate the occurrences. There is no intention to limit use by simply removing an option. This was why I chose these two examples as in the second case simplification was difficult so it was just presented in a refined manner and actually allowed for more flexibility.

[Tim Waldock]

Erik,
I'm not sure I follow you - the dialog changes in second example (synchronisation) all sounds good; but the first one (inconsistent groups) is one that we have been really struggling with recently on a project in v2009. From your description above it sounds like you have removed the option that we like to use "remove inconsistent members from groups". Are you saying that the code has been improved so that we won't get the inconsistent members of groups in the first place? or that it handles it better when it happens? I may need to test this in v2010, but should we discuss this by email, off the blog? Coincidentally the project has just been uploaded to support for a workset issue, so you might be able to look at it yourself.
Tim

[Tom Vollaro]

Tim,

Yes the code was improved. I will contact you to test the file you mention if possible.

[Rich Sales (Director Salesoft CAD Solutions - Revit developer)]

Keep up the good work of removing non comprehendable dialogs. New users realy do/did get confused as to just what to do.
The worry I have is the new dialog format/conventions. If you picked a radio button that was a clear thing to do, then you OK'd. Now a path for action or option is presented as an imformative 'message' sentence to read but the fact that you have to use the message as a pick 'button' is not entirely clear and the thin line green border indicating that it is the default is doubling as a traditional button indicator. Weird when first encounted and has to be explained to users that you pick the sentence to get action.