Inside the Factory

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

 

More Factory Kitchen Interactions

Back in April last year I authored this post on some interactions in our office kitchen. The other day I found another I wanted to share as it touches on a good aspect of design.

Its morning, you fire up the workstation, and grab your coffee cup.  Upon filling your cup (unless you like it black) you turn to the sugar, creamer, or both.  This is what you see with your pre coffee blurry vision:

Let's bend down a little closer:

Still hard to tell, eh.  I've had to learn the hard way to double check before pouring anything into my coffee.  I don't care for milk or cream - and this goes double for powder creamer.

So the issue here is different things should look different.

I imagine "Highland Estates" benefits from such efficiency in packaging and font conservation yet this could be better.  Think of a restaurant where the sugar comes in a glass dispenser and the creamer in a pitcher.

In a less fancy place perhaps you encounter something like this:

Some free design advice for Highland Estates.  If you must continue with unified packaging please at least put a picture of a creamer pitcher on your creamer canister and a sugar dispenser on your sugar canister.  The pictures would serve as an icon and help my pre-caffeinated brain leverage its memory and prior learning.

_erik

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

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

Contextual tabs: the right tool at the right time?

A major aspect of the Revit 2010 ribbon UI, and one that has received much attention, is the concept of contextual tabs. It is clear from much of the feedback we have received that actual experience of using contextual tabs is not living up to our original design intent. I wanted to take some time and explain our original design goals and intent - so that we can move forward with trying to figure out how to address the issues that have been raised.

A Bit of History

The Microsoft ribbon introduced the concept of contextual tabs, a ribbon tab that appears only in specific contexts (an active tool or selected object) and contains tools and options related only to that context. Microsoft's tabs generally work as follows:

1. Start a tool (such as Insert Picture) and the Picture tab appears gets immediate focus
2. Click on an existing picture
• If Insert Picture was the immediate last command, the tab appears and gets immediate focus.
• If not, the tab appears but does not get focus - the user must click on the tab
3. Double-click on the existing picture and the tab gets immediate focus

^{_{The Word 2007 Picture Tools Contextual Tab, in focus}}

AutoCAD 2009 adopted this concept, except that a double-click or explicit edit command is required to give the contextual tab focus. In both Microsoft Office and AutoCAD, the use of contextual tabs is limited to a handful of contexts (picture, table, MText, etc.) For Revit, we were faced with the prospect of hundreds of potential contexts due to the existing contextual framework we were building on top of. As you all know, Revit has always been a contextual product. That is, it traditionally used the Options Bar to present options (such as whether a wall should be chained or not), the instance properties and  the type of the currently selected item, or item being created. While this system was extremely flexible, it presented a variety of usability issues:

1. The bar's width limited the amount of tools available at one time
2. The bar's height and color made it difficult for users (especially novices) to see that it was changing.
3. The dynamic nature of the bar mixed options and properties during creation tasks, making it difficult to tell them apart. Also, related controls had a tendency to be split apart (see image below.)

^{Revit Architecture 2009: Create Wall Option Bar. Properties in blue and tool options in green}

A Pattern-based Approach

During the early phases of design of the ribbon, we decided to expand on Revit's contextual nature and adopt the contextual tab concept as a way of solving the known usability issues with the Options Bar. Since there were over 800 contextual commands to organize and lay out - and MANY more permutations since Revit decides what to show depending on context - we adopted a design pattern approach that allowed us to develop a framework which would allow us to fit many different contexts across the three Revit products. Below are the three primary contextual ribbon patterns:

The primary goal was to give the user the right tool at the right time. For instance, the Modify tools (Move, Copy, Rotate, etc.) were on the old toolbar and disabled until you selected an element. We opted diverge from Microsoft's click pattern, and give the tab immediate focus upon creation and selection, because we felt these tools should not be hidden from the user. Also, the element specific panels are inserted programatically, depending on the current context. The Option Bar remains, mostly due to some technical constraints that we encountered - and it's contents are still mixed between properties and tool options. However, we elevated the most frequently used tool - draw and pick options - which was covered in a different post.

Known Issues

This concept tested well overall, including with our extended expert testing. People felt that they were being presented the right tools and options at the right time. However, during the Beta cycle and initial release, we have received quite a bit of negative feedback about the contextual tabs. To summarize the feedback (which I am still sifting through), the benefits of contextual tabs seem to be outweighed by the following issues:

• Panels (such as the commonly used Modify panel) change their location depending on the context and/or type of element selected.
• By always giving the contextual tab immediate focus, there are times when you may be taken away from the tool you need (i.e. the last tab you were on when you selected the object.)

Can you expand on what frustrates you, but also what you see as the beneficial about how contextual tabs have been implemented? How would you change them?

(BTW, the lesson learned here is that changes such as these must be validated through longitudinal testing - something we plan on doing much more of in the near future.)

The Ribbon Process in Four Minutes

Designing and implementing this overhaul of the user interface required a considerable amount of research, data analysis, interaction design, and visual design. I put together a four minute video that was presented to the senior Autodesk executive staff last month. It briefly describes some of the design methods that we used while integrating the ribbon into the three Revit products. This video highlights a few themes that will persist through our blogging on the topic:

• Using data to make design decisions
• Developing prototypes and iteratively testing them with customers
• Leveraging design patterns to create flexible and extensible designs