Inside the Factory

Putting Editing in Perspective

In Revit Sundial's What's New, you may have noticed this entry...

• Perspective views: Certain modeling capabilities are now available in perspective views: (See Work in a Perspective View.)
  • Editing tools: Move, Align, Pin, Unpin.
  • Reset Target tool: Restores the position of the camera target to the center of the field of view.
  • Toggle between the perspective and parallel representations of the 3D view.

Editing in perspective views has long been a customer request, so when I asked about it among the old-time Reviteers, most reactions were something like...

"Well, no one ever really tested it. We could try turning it on and see what breaks."

So, it turned out a number of things broke, which is maybe why we haven't just tossed it off sooner than this. A number of issues that turned up are fixable, but not immediately.

What Sundial has is what didn't break or was easily fixable. It could be possible to do more on this in the future. Interesting? Vital? Boring because you use 3DS Max for important visualization anyway?

Try it out and let us know!

Anthony

 

 

Chain Select

First thank you all for the relatively large amount comments on the previous selection post (Press & Drag) that can still be found here.  Again the best comments explain why you use it one way or another since that helps us understand how to best support your tasks and uncover patterns of usage.

In this post I want to briefly talk about Chain Select  This is the behavior that allows you to select a contiguous set of connected lines.  Revit does not have a polyline element so this is one way to speed multi-segment selection.

In the Massing environment the preference is to always select the chain or loop.  Tab will select individual sub elements of the chain.  This is 180 degrees opposite from the project environment where individual elements are given preference and you must tab to select the chain.

Each behavior has its benefits yet having two opposing behaviors can lead to frustration and slow learning.  Is this the case in the field?  Do you prefer one behavior over the other? Why?  Do we need a setting to control this?  can one behavior serve both environments?

I look forward to the discussion.

_Erik

Exposing Design Detail via task Analysis

A lot of good design is overlooked.  When you are able to get a task done smoothly, without having to understand how to interact with a fancy widget or discover the way forward, you are often less likely to notice.  You may notice if the interaction pre-existed and was recently improved.  This happened to me the other day when Gmail introduced a button to delete trash contents in a single click instead of multiple.  I’m sure they realized that most people go to empty the trash completely and so provided a link for this.  Thanks Google. Things should just work and on occasion delight.

Having said this let’s explore a specific example I recently came across:

The requirement calls for a widget to create and store paths with logical names to external files.  Here is the initial design and workflow:

The user clicks “+” and a new row is created.  A default name assigned.

The user must next click in the “Path” field, then a dialog launcher will display.

Clicking on the “…” dialog launcher presents a standard “Browse for file” dialog.  Once a file is chosen and OK pressed the path is defined.

DONE

So looks good…or does it?  Let’s review the task flow in detail:

1. Create a new entry
2. Activate the path field
3. Click the dialog launcher button
4. Select a file (double-click or click OK)
5. Activate the “Name” field
6. Select the text
7. Type in a new name

Several steps fall into a category of things the user might not think to do or things that unnecessarily interrupt the desired flow.  Is the default name meaningful?  Should it be created before the file is specified?  Why make the user activate fields? (the dialog launcher does require field activation but this is due to a toolkit that has rooted itself everywhere in the UI – another post perhaps)

What would an idealized workflow look like?  Its pretty clear what this particular sequential task demands.

1. Create a new entry
2. Activate the path field
3. Click the dialog launcher button
4. Select a file (double-click or click OK)
5. Activate the “Name” field
6. Select the text
7. Type in a new name (optional)

Let’s see how close we can come.

The user clicks “+” and the “Browse for file” dialog is launched where the user chooses a file.

The path field is populated, the “Name” field matches the name of the chosen file (better default) and the field is activated and text pre-selected.  The user can now immediately type to specify a new name if they prefer something else or move on.

DONE

So we can see by performing this task analysis of what is performed by user vs. machine a more streamlined and pleasant experience can be had.  No fancy widgets.  Sometimes this analysis is easier to perform on working code - making changes in a second iteration but it could also be simulated via prototypes.

There are other places in the UI that could benefit from this analysis, renaming items in the Project Browser comes to mind.  Please share others, especially if they are frequent.

_erik

 

Some Friday fun: 123D Sculpt

It is a good thing I have a vacation coming up, because this thing is keeping me from getting work done!

Powerpoint for Prototyping

I recently wrote a series of posts on one of our sister blogs about how we use Powerpoint as a user interface prototyping tool.

Powerpoint for Prototyping - Part 1: Outlines the various levels of fidelity we work with, ranging from sketch to fairly high fidelity interactive.

Powerpoint for Prototyping - Part 2: Provides some detailed examples including Powerpoint tips and tricks.

I am re-posting here because it gives a bit of a window into how we do design within our group. I am also curious to hear if and how this type of interactive and mixed-media presentation style is applicable in your work. What kind of innovative techniques are you using to collaborate with your colleagues and clients?

_tom

 

Rotate 2012

Months back I posted on Revit rotate behavior (Twist and shout).  In the post we explored options for addressing some wishes, mainly better control over the specification of the center of rotation.

The feedback from this post helped inform the addition of some new behaviors to 2012 and the design approach.  In the approach we tried to maintain existing workflows for those who found the default behavior workable yet add enhancements allowing experts to quickly take full control.

So what is new in 2012?

New control behavior

The little blue rotate control that you could previously drag to re-position now allows repositioning with a two click operation.  "Click" "Click" instead of "Press" "Hold" "Release". The drag behavior will still work for those with strong muscle memory since both behaviors are compatible.

Option bar commands

The option bar now displays two choices for the center of rotation "Place" and "Default"

The former will place the center on the pointer and allow you to define the center manually - especially handy when rotating large elements that might have a center off-screen.

The later is the legacy behavior where the center is placed at the centroid of the element.

The tooltips and status bar were updated to provide further clues to the added behavior.

Spacebar

The above UI improves discoverability of the new behaviors for new users but could easily be viewed as more work by experts so more was done.  The spacebar has long been used to rotate components in selection or during placement and can now be used to quickly switch between the two rotation behaviors.  Type "RO" for rotate, tap the spacebar and you are in 3-click rotate.

Keyboard Shortcut

A shortcut for 3-point rotate was defined "R3".  Select an element and type R3 and you are in 3-click rotate.

Has anyone been using the enhanced rotate in 2012?  Are new Revit users able to perform a 3 point rotate?  Are experts also happy?  I'm curious to gain feedback on the approach and final design solution.

_erik

 

2012 Little Things: Dialog Launchers

A very subtle change yet one more crossed off a list of places we know of that can benefit from this type of UI:

In the type properties of views you can specify tags.  In previous releases you would see a list of tag types but if you wanted to make a new type you would have to exit the type dialog and go to the Manage tab to create a new tag type there.  Not convenient.  in 2012 you can jump to the Tag Type dialog directly from the View Type dialog.

 

View Type dialog and new launcher control

 

Destination: Tag Type dialog

 

Previous Single Access to Tag Type Dialog

_erik

2012 Little Things: Type Selector

Now that 2012 is out of the bag I can take time to cover some of the smaller interface and design changes that made it into the product and might otherwise be overlooked. Today I'll review the type selector.

TS in Ribbon

When the type selector moved to the modeless properties palette some expressed a desire to get it back in the ribbon.  More choices for you.

 

TS Graphics

A small change in type names now align under the family name in the type selector drop down.  Previously type names were justified under the center of the image which created issues when trying to quickly scan the list.  This is very subtle but was easy so we knocked it off in the spirit of any positive change is good no matter how small and we should take opportunities when they present themselves.

TS in Sketch Mode

Saving best for last the type selector is now enabled inside sketch mode.  This was a very old behavior fixed.  I'll spare anyone the technical reasons why the button in the property dialog was disabled in 2011 but it was the same in pre 2011 releases though we did have a special property button that would bring up the type dialog then.  Now in 2012 the normal type button is enabled.  Kudos to the UI team for coming back to remove this inconsistent behavior that I know was source of annoyance. -erik

Its the Little Things - Default 3D Views

Another subtle 2011 change.

Problem

In every release of Revit going back to the start we've had the concept of the "Default 3D view".  You click the little house icon and get a 3D axon view named "{3D}".  Renaming this view preserves it and allows another one to be created using the same method.

When worksharing came into the picture the {3D} view started to become a source of contention.  A project team member would manipulate the view and it would be signed out to them.  This then caused other team members to receive a permissions warning when they tried to manipulate the same view.

Workaround

The work around was to save off individual views for each user but the convenience of the Default 3D View tool continually caused the situation to reoccur.  Several customers had brought this issue to our attention.

Solution

Now in 2011 the Default 3D view is user specific and works the same as it would in a non workshared file. 

When the little house icon is clicked it looks for a view named {3D - username}. Username is defined in the application "Options" "General" tab available from the "R" application menu.

If this view exists it is opened, if not it is created.

The system always directs people to their own default view so the previous contention is eliminated.

 

_erik

 

 

Twist and Shout - (Rotate Behavior)

There has been some perennial buzz on the Revit rotate tool.  Each new person that learns the program has to learn this tool and its peculiarities so the topic persists.  In this post I want to review the current behavior, the access points, and review some popular revamp proposals.

Rotate lives in the modify ribbon.

When activated there are three options:

• Disjoin - prevents joins from interacting with the element during rotation
• Copy - creates a new element when complete
• Angle - allows you to enter in a precise angle

The first click is the start point of the rotation and the second click the end point.  Note: After clicking the first point of the rotation the temp dims listen so you can enter a distance via the keyboard in lieu of the second click.

This brings us to the main issue folks have with the tool: the center of rotation.  The center is shown as a blue control that can be repositioned by dragging it to a new location. The problems are:

• The behavior is undiscoverable. The status prompt or tooltip is insufficient and many go for a long time not knowing the center can be moved. (a % of this blogs readers may have just learned something)
• The center as determined is rarely optimal.  The center is the centroid of the item(s), with a few exceptions such as hosted elements.
• The center is difficult to reposition.  Its difficult to select and drag the control. After dragging its not remembered for future rotations.

 
Figure - Default rotation centers (hosted door, component, group)

There are really two main proposals that have been discussed over the eons.

1. Make the tool a three click operation. (Center, Start, End).
2. Retain (or enhance) the existing behavior yet provide a shortcut to snap the center to the cursor when desired. (the default could prefer one method over the other - preferably the most popular)

I'll share my opinion.

(1.) Simple and while it may mean an extra-click in some cases clicks are just part of performance.  It's proven that a person can make dozens of clicks in the same time it takes another to cognitively process a situation and then respond.  It follows industry patterns including other Revit patterns such as the nearby "Scale" tool.  Some snapping would need to be implemented such as center of Group unless it's not needed.

(2.) Provides a convenient way to place the center but is still as discoverable as the current control drag method.  New users would be unlikely to discover it.  Placing the point instead of dragging it should be better.

Another variation is to employ approach (1) but offer a snap to get the current behavior where Revit calculates the center.  We could also make some better choices such as choosing the family origin, remembering a repositioned center for the active session ect.  My concern would be implementing a dozen tweaks to the current behavior will not address the most pressing issue and cost more than just implementing a three-click behavior.

Note: the option rotate after placement would follow the same behavior as the rotate tool and the shortcut to rotate using the spacebar would be unaffected.

Bring on the comments..  Additional ideas or feedback on the proposals listed here are welcome.

_erik

 

 

Calling all Boston area students

Are you (or do you know) a student of architecture in the Greater Boston area? If so, we are planning a usability study for early October to examine some new and unreleased software. The study is taking place on October 5th and 6th in downtown Boston. If you are interested in signing up for one of our time slots, please visit or forward our recruitment survey page.  Sorry, no professionals (internships, etc. are ok). We will have other opportunities for you later!

Got Essential Skills?

Last week inside the factory we held our (mostly) weekly design pinup. These lunch time pinups give interaction and product designers the opportunity to pin up an unfinished design and have others throw darts. You know the drill. This particular pinup was not focused on a particular interface or feature design. Instead, we brainstormed on what constitutes the absolute essential skills for first-time Revit users to learn. Our colleagues in the Media & Entertainment division pioneered the concept of Essential Skills Movies back in 2002 when they released the Personal Learning Edition of Maya. This was a free version intended to introduce the product to new audiences. During usability testing, the user research team noticed common problem areas that made users stumble and sometimes even abandon learning the product. The team distilled these issues into seven 60 second movies that introduce the most essential skills needed to have a successful first learning experience. It is interesting to note, we have been talking a lot about in-canvas and more direct model interactions vs. "traditional" user interfaces such as toolbars, ribbons and menus. The problem is, our industry has not standardized most "direct" interactions, so they remain hidden to users. This technique is a nice way of lowering that initial steep learning curve and introducing features that may be, by there nature, hard to discover.

The Maya 2010 Essential Skills Movies starter screen. Notice the topics focus on basic concepts such as navigation and selection - more advanced topics are accessible from the red button.

We decided that this method was intriguing and deserved some thought on how it could be applied to Revit. Below is the list we came up with. Note: the ultimate goal is to get this down to no more that seven movies. And each should be no longer that 60 seconds. The Maya team has done a lot of research and found that this combination of quantity and length strikes the right balance. In your experience learning and/or teaching Revit, which items would you add? Remove? Modify?

• Families: Parametric, coordinated models, not just 3D forms.
• Views: Coordinated views of a single model, not just 2D projections
• Constraints and hosting
• Navigation:  Mouse wheel, viewcube,
• Datums: Grids, levels and workplanes and why they are the important building blocks of any model
• Selection: Pre-highlight, ESC key, Tab select, right-click, displaying properties
• Temporary dimensions

Patterns and Traffic Usability

It's no secret that the Factory re-located a while back across the street into our new LEED certified building.  It was a shining example of 100% integrated project delivery (IPD) and written up in many places such as here and here.

The new site has turned up an interesting usability issue.  It's not related to the building but its site access.  On arriving to the office one may see a vehicle slowly creeping across the parking lot toward the ramp to our garage. Living in Boston I've developed a predictive instinct as to what drivers are going to do, such as cut me off or hold up my lane making an illegal U-turn, so when I see these vehicles they clearly convey confusion on the part of the driver.  They exhibit none of the single-mindedness I am used too.

The issue is our entrance is about thirty feet from the I-95 South on-ramp.  The location and direction of our driveway implies it will reach the highway even though it won't.  Some cars have made it all the way into our garage and one of our own workers sadly watched as a semi-truck slowly backed into their car trying to correct the mistake.  I imagine the driver starting to wonder...Why are cars parked on the sides of the ramp?  Why are people walking on the highway?  Did they add another new toll or tunnel?

How to fix this?  A traffic island in the middle of the drive with our address/company name on it might help.  You would have to slow to navigate around it and exit ramps don't have these.  Perhaps some traffic experts can comment.

It's amusing on the surface yet bad signage did lead to deaths in Atlanta.

It's hardly the first confusing traffic situation in the Boston Area.

Traveling in Multiple Directions at Once

In summary patterns can work for or against you.  Things that look the same are expected to work the same and vice versa.

_erik

Got Mode?

We spend a lot of time and energy talking about and dealing with modes. Although modes get a bad rap, and we have worked hard to remove modality when it was problematic, they do have their place. The advantages of creation/edit modes in the Revit environment are two fold: 

• They focus the user's attention by graying out the surrounding context.
• They suspend regeneration to improve performance.

While modes themselves are not inherently bad, they are problematic when the user is not aware they are in a mode and do not know how to get out of the mode. The late Jef Raskin, one of the creators of the original Mac and the author of the Human Interface suggested "quasi-modes"; modes that require a constant physical action such as holding the shift key. While this is not feasible in all cases, we instead rely on a secondary user action - clicking Finish or Cancel. I have a few questions I have now that people have had some time with the 2011 release:

• We responded to feedback that people preferred the pre-ribbon Group Edit mode floating dialog. In 2011 we added this back as a floating ribbon panel. Comparing this to say, editing a floor or roof where the Finish/Cancel remain in the ribbon, is this floating panel preferable? It is more visually apparent, but it also occludes part of your view temporarily.
• Since you can undo back into any mode to undo changes, is Cancel really necessary?

Parallel topic: Factory Kitchen Interactions

 
Usability is everywhere.  Our factory conference rooms and offices have cool glass doors to let the daylight in. They have vertical pulls that are attractive yet offer little affordance as to whether you push or pull.  My architect brain tells me I push because its a left or right hand door into a room but the shiny vertical handle works on the lizard part of my brain that says "Its a bar not a plate.. pull it". Its minor yet its not uncommon to see peers tugging on door handles that won't yield.

 

Problems are often easy to identify but stepping back and noticing a successful design is worthwhile too.  The factory kitchen is full of examples of both.  Hours of coding and feature design requires caffeine which can be obtained via an automatic coffee machine and soda dispenser.

The coffee machine will make various styles with a few push buttons and grinds whole beans. It won't detect glass mugs but there are ways to trick it.  The buttons you can press light up and there are written instructions.  Occasionally it will display a cryptic message about water temperature but it usually snaps out of this state - altogether pretty good. The soda machine also has a thought out work-flow:

1. Insert money
2. Choose flavor: Coke 1, Coke 2, Diet Coke 1, Diet Coke 2, ect..
3. Retrieve beverage
4. Retrieve change (in the same place!)

Other than having to bend down to get my beverage (leveraging gravity is forgivable) its very smooth.

The snack machine is more of a jarring up and down, left and right process. The software equivalent to this is highlighting text when renaming objects to facilitate typing over or laying out a dialog in a logical order.

Out Kitchen Microwave...yikes. 

Its clearly a commercial model due to the fact its rated at 10 million watts and can convert a cup of water to vapor in 10 seconds.  The going theory is a commercial kitchen would label each number in the space provided and set it to a specified time for common things they need to nuke.  I know from experience that 4 = 00:45 seconds and 5 = 01:00.  We used to have a cheat sheet on the nearby whiteboard.  Clearly this is a case where the persona is someone other than a typical office worker.

_erik

Making Design Patterns Work in Practice

I just posted on our corporate design blog about  <shameless plug> Making Design Patterns Work in Practice. </shameless plug>  We don't normally like to re-post, but I thought it was relevant to demonstrate some of the thinking that goes into our design practices inside the Factory and how it dovetails somewhat with architectural design. This is also closely related to Erik's recent post on consistency. Please note, we realize that we have a ways to go before we follow our own interaction design patterns fully - but this illustrates the direction we are headed.

_tom

Consistency

Consistency is an interesting topic in design.  Its often spoke that improving it is a worthwhile pursuit in its own sake but in reality its much more subtle.  The cookie cutter suburbs that now comprise large swaths of the U.S. might have been justified on some levels but often fail their eventual inhabitants.  Lost was the pleasing diversity represented by vernacular building styles and common sense mixed zoning that create lively walkable communities.  Much of new urban planning is a re-discovery of proven ideas that were casually tossed aside in the later half of the last century.

A co-worker Chauncey Wilson wrote a good summary of this topic applied to interaction design on a sister blog titled "The Consistency Conundrum".  I recommend it.

In testing Revit and other products and also in my teaching I've seen many places where consistency improves learning by providing a scaffold via interaction patterns. A new feature can be understood by leveraging a known feature.  In some cases the interaction pattern may not even be that great but once learned tasks are completed without trouble.

In the 2009 release there was a quiet effort to make our open and save dialogs more consistent.  I placed some animated GIFs on a separate page (less annoying) showing the differences from 2008.  In some instances it was just a layout fix but in others extra dialog bits were moved to occur before or after the save dialogs to better fit the work-flow and not overload the person performing the task with too many decisions.

To close I want to solicit comments regarding:

• Areas where you feel Revit is consistent in a good way.  reinforce good behavior.
• Areas where is Revit inconsistent in a way that causes frustration.  (e.g. renaming is handled differently in types and views)

P.S. Please no stories of short inebriated mythical celtic creatures.  I'm sympathetic and heard them all by now. I promise that bugger is on a strict coffee regiment and a cab has been called.

_erik

What's in your Add-ins?

What is in your Revit 2010 Add-ins tab? Can you post a screen shot to show us? We are trying to put together a picture of what a "typical" Add-ins tab looks like. We are aware that there a issues with the Add-ins tab: specifically related to scalability and context, and we want to improve it. If you do not mind sharing on a public site, you can email your screen shot directly to my Flickr page: [email protected]  Feel free to comment here about your experience accessing tools from the Add-ins tab.

Addendum: as an experiment, I am embedding linking to the Flickr slideshow to create a bit of a feedback loop.

_tom

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