Inside the Factory

Select "all" instances?

One of the fundamental areas of ongoing Factory research is selection. There is a lot more about this to write, but I have a (seemingly) simple question I wanted to get some quick feedback on. Here is the scenario:You are working on a project in schematic design and you are in the Core Workset. You have checked Editable Only in the status bar so you are sure to only select elements in the core. You right-click on a Generic - 12" wall in the core and Select all Instances. All walls of that type in the model are selected (including the Generic - 12" walls in the Exterior workset, which is not currently editable.) Does this match your expectation? Or, would you expect Select all Instances to respect what is checked in the status bar? To phrase the question in more fundamental terms: Do you see Select all Instances as an extension of the Modify tool or as two independent tools?

_tom

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

Revit Terminology

In our early research to document tasks and processes that occur during a building project there was consistent feedback that Revit would occasionally use a novel name in lieu of an established one. In the process of re-mapping hundreds of commands we took the time to step back to ensure command names we used were appropriate. Some of the criteria were:

• Does it fit the building domain rather than the domain of software?
• Are we using a less common term over a common one?
• Does the command accurately reflect what the tool does?

We knew this would force relearning so we took care to focus on those that could clearly be better. Below are some specific cases for illustration:

Internal Consistency
In 2009 when selecting an extruded roof form a tool was displayed in the option bar called “Cut Plan Profile”. This command name was explicit yet...a little clinical perhaps? It also had behavior that was a dead ringer another command named “Vertical Opening”. This replication creates an additional cognitive load recalling two names for a single action. In 2010 the command “Cut Plan Profile” was standardized to “Vertical Opening”.

Reflect the underlying Behavior
Those on large projects will see “Save to Central” was renamed.  An early iteration used a term “Publish” which is often used for this behavior but didn’t capture anything new or seem a significantly better choice. After further iterations and internal debate this was later replaced with “Synchronize with Central”. This name more accurately reflects what occurs during the save process. On initiation data is first transferred into the local file from the Central file and then from the local to the Central. The two files are brought in “sync” with each other.

Use commonly known terms
Did you notice the rename of “Resize” to “Scale”?  Going way back “Resize” was originally chosen as the command didn’t really scale all aspects of an object. In the case of a wall it would scale the length but not the height or width. Despite this truth the common name for this operation in most other modeling programs is “Scale”. Disqualifying this name because it could not be applied literally on all aspects of an object seemed a technicality.  Customers could predict how “scale” would work on richer objects and not using a term they knew almost seemed almost condescending and certainly caused them to pause. To help new users leverage their existing knowledge and improve consistency with other products, including those by Autodesk, the name was changed. The default “RE” keyboard shortcut was maintained to avoid an inconvenience to existing users.

Remove Jargon

When laying out the top level modeling tools we came across the term “Host Sweep”.  In 2009 this top level menu contained the tools “Wall Sweep”, “Wall Reveal”, “Fascia”, “Gutter”, and “Slab Edge”. While experienced Revit users were used to the term it was clearly not one you would find in an architectural textbook. We first tried to brainstorm alternative names but given the ability of the tool to place many specific sweep-like elements a single name could not be found.  After some iteration the key was in the word “Host” – a generic, and again clinical, term for top level objects in the software (Wall, Floor, Roof etc.) Since each command had a “host” we could distribute these commands under these. “Wall Sweep” was placed under “Wall”, “Fascia” and “Gutter” under “Roof” etc. We tested this organization by assigning specific tasks to customers with a range of Revit experience. Care was taken to avoid using the exact command names in the task goal by providing an image that the customer had to recreate. These tests showed the new organization worked extremely well. A few experienced users paused to look for the original location but then reasoned it out and found the tools in the new location completing the task successfully. After the test we often asked, “When you paused what tool were you looking for?” Most could recall the tools used to be grouped together but could not remember the full menu name “Host Sweep."

Are there additional instances of terms that you think fail the previously mentioned criteria? Can you find more examples of jargon?

_erik

Usability Methods

A common question from last week’s video post is “who are these ‘dedicated users’ you mention at the end?” quickly followed up by “why was I not one of them?” To answer the first, over the course of one year beginning at Autodesk University 2007, we tested the ribbon user interface on over 100 Revit users. This does not include the scores of users the ribbon concept was tested on by the other Autodesk product teams. Their expertise ranged from beginner (three days of training) to expert (used since release 3) and all points between. We carefully screened participants depending on the goals of the particular study. For instance, some studies were geared towards ease of learning while others were geared towards the overall efficiency on expert tasks. Participants represented companies as small as one all the way up to some of the largest AEC companies in the world. The participants were predominantly North American, something we are working to change as we improve our remote testing capabilities (more on that in later posts.) As I said in the video, the fidelity of the prototypes increased throughout the process as we refined the design. We started with paper prototypes at AU 2007 and ended with pre-Alpha working code at AU 2008. Usability sessions ranged from 30 minutes to 5 hours, but averaged about 60 minutes. We typically employ the think-aloud protocol, where we ask participants to talk through their thought processes as they complete tasks to understand problems as well as features that work well.

As for the second question, we are continuing to build our database of potential usability participants. As I mentioned earlier, we are particularly interested in reaching out to more international users. To add yourself to the database, you can fill out this recruitment survey. We have been working hard for the past three years at building up our usability testing methodologies and infrastructure at Autodesk. It is an evolving process and we are constantly striving to make it more effective. We will touch on more details about these methodologies as we dive into specific parts of the UI in later posts.

_tom