Inside the Factory

Quick Access Toolbar

In this post I want to solicit and verify feedback related to this element.  The Quick Access Toolbar (QAT) is now one of several places where persistent access is provided.  Some others are:

• View Frame
• Status bar
• Ribbon panels dragged off the ribbon
• Project Browser
• Navigation Bar (Zoom and SteeringWheel)

Any control on a static ribbon tab can be added to the QAT.  This includes drop downs.  Below work sharing tools have been added to appear in a similar configuration as was possible in 2009.

2009

2010

The QAT may also be displayed below the ribbon via its right-click context menu.  While this takes up additional vertical space it allows for more items and places them closer to the workspace.

Known Issues

• The ability to customize in Revit is appreciated yet 2010 is over dependent on this place for common tool access
• The visual design is too low contrast/dark
• The icons are too small
• There should be some ability to re-arrange tools once they have been added
• “Synchronize with Central” and “Save” should be adjacent
• The type selector should show the type/family name much like work sharing and design options.
• There is not a clear way to “reset to default”

In understanding what tools require persistent access we have frequency data that shows which of the hundreds of tools get the most use.  Despite this the data must be qualified given the following possibilities:

• A tool might be infrequently used yet be critical to a specific task
• Tools might be highly used by accident or other confusion (Arch column vs. Structure column)
• Some tools have a high affinity and should be co-located even if their individual frequencies differ

To supplement internal data and research I am soliciting screen shots of your customized QAT layouts.  Steve Stafford, Revit blogger, provides an example here:  Please share yours by sending a screen shot as an attachment using the following link:

Share your QAT Screenshot

Thank you

_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.)

Split Buttons and Drop Down Buttons

Thank you all for the feedback on the "rotate after placement" option.  We appreciate some of the descriptive comments.   A few others asked why we aren’t concentrating on feedback related to the ribbon.  We have collected a lot of feedback to date and this continues.  To gain additional understanding we can start discussing specific topics here. One of these is the Split and Drop down buttons.

The Split Button component supports the following behaviors:

• The top of the button allows direct access to one of the underlying commands (default)
• The bottom drops down the complete list like a traditional drop down list
• When a command under the split is used the default top level command can update or not.
  • Separately the title of the button can update or not (Update may cause the button width to change so we have avoided this)

In 2010 “Measure” updates and “Wall” does not.

Related to the split button is the "Drop down button". "Model Group" is an example:

Design Intent

The settings as they stand were based on the types and the usage frequency of commands in the list.  In the case of the “Wall” split button the organization helps bring these related commands together yet the split allows you direct access to “Wall” which is a known top command.  If you access a lower frequency tool under the wall command it doesn’t take over the top level.

The Measure split button was not like this. The commands are very similar and had a similar frequency so it was implemented to update.

Commands that had low yet similar frequency were given a drop down button.

Known Feedback

• Many have expressed that the different drop down/split button usage creates unpredictability.  It has been suggested we should standardize on one behavior.
• There have been comments that the tool tips should communicate what is under the split when you hover there.
• There has been feedback that the "Column" tool in Revit Architecture should update.  These two commands were known to be confused prior to 2010 so they were co-located to force a choice and improve discrimination but the default is always “Architectural Column”.

To address the last item one proposed design changes the button on "Home" so it updates the default on selection.  It also duplicates the “Structural column” command on a “Structure” tab.  Those that place Architectural Columns will still have to make a choice yet selecting the desired command will cause it to stick.  Those that are placing structure elements have access to the tools they want and do not have to deal with the Architectural Columns.

 

What do you think of this specific case?

Additional questions for discussion:

• Would standardizing all split button behavior truly be preferable or is it just a handful of specific commands where this would be better?
• What commands work when grouped under a split button and which ones might be better spread out?

Please share other examples.

Different topics will follow next week.

_erik

Reflections on re-writing tutorials

The following was written by Marcel Dubois, Lead Technical Writer for Autodesk Revit Structure on the AEC User Experience Technical Publications team.

When we began planning for the 2010 release, one feature in particular was always at the top of our priority list; the new ribbon UI. We knew early on that this task would require a total rewrite of over 600 pages of the existing tutorials, and that the work would be delayed until after the UI design was stable. This presented us with additional challenges including a shorter window in which to update the documentation. We were faced with some tough decisions that revolved around the unknown variables of the ribbon design and trying to estimate its impact on our overall schedule. Based on the added time to learn the new UI, I estimated that it would take me at least two days to adapt each tutorial. After starting, I soon realized that my estimates were too high. Once I figured out the logic of the ribbon layout, I was able to convert each tutorial in less than three hours (instead of the original two day estimate.) This included validating each step and capturing new images in the drawing area and dialogs. The new tutorials were completed ahead of schedule and are based on a more realistic user workflows.

For those of you re-writing your own documentation to fit the new 2010 UI, does this match your experience? If not, what in particular about the new UI is making it difficult to update your documentation?

_tom

Icon Design System

To follow up on Erik's last post about draw and pick gallery icons, I thought I would introduce some of the thinking behind the new icons in the 2010 Revit products. The design system developed by our colleagues on the Platform team was flexible enough for us to redesign over 1000 icons to fit our products while staying within the visual "family" established for all Autodesk products. The goals of the system are:

1. Be easy on the eyes
2. Do not overpower the canvas
3. Be as simple as possible
4. Have a distinctive style

 The following are the basic elements of the system:

Main Body
The foundation of our icons is the main body. Accents and badges enhance their meaning in a systematic way.

Accents
Accents are spot colors or overlay applied to the main body to enhance the meaning and communicate change.

Blue is used to show modification. For Cut Geometry, the blue object is the one being cut. The red is used to indicate stop or removal. For Join Geometry, we used the same base shapes, but use the blue color to show that both shapes will change.

Green is used to indicate selection. For Place Beam on Grids, we re-used the base Grid icon and added blue to indicate a beam will be created and the grid is what should be selected.

Badges
Badges are separate elements laid on top of the main body to indicate a common action such as edit, new, or delete. For Edit Profile, you see the combination of blue accent to indicate the profile will change and the common "pencil" badge to indicate editing. Another common badge is the "star" to indicate something new will be created. There were certain times where we had to deviate from the system. For instance, the Home tab would have been full of "star" badges, so we opted to leave them off since it would have been overly redundant.

This is just a taste of what went into creating these icons. There are many more guidelines dictating the exact color values and gradient levels to ensure consistency. Also, each icon required collaboration between subject matter experts and icon designers to ensure the symbolism was accurate and expressive enough. We had many lively discussions and sketch pinups discussing the ins and outs of whether "toy blocks" was too child-like for the Component tool or whether the "puzzle piece" made sense for Worksets.

 

_tom

Draw/Pick Gallery - Part III

Draw Icons

This is a very short post on icons related to this UI element.

When the polygon methods were promoted to a top level method the iconography was re-designed to improve discrimination over 2009.

• A pentagon was used rather than a square for better differentiation against the rectangle method
• The base shape is shown with a consistent size and orientation to focus attention on what is truly different
• The snap points and rubber band offer a better preview of the in-use tool behavior  (snap to face vs. vertice).

   
R2009               R2010

New/redesigned icons were a large part of the 2010 release so more on this topic will follow in the future.

_erik

Draw/Pick Gallery - Part II

Tools vs. Methods

In the previous release sketch lines could be created via a sketch or a pick action (lines, walls, or roof edges) yet this access was spread around the UI.  As an example “Pick walls” existed in the design bar but “Pick Lines” required the user first choose a tool from the Design Bar then “Pick Lines” from the Option Bar. The UI reflected an internal organization rather than create an upfront choice between sketch freehand and sketch by pick.   Some of these tools were known and others were being missed.

In 2010 all the pick methods were consolidated at the end of the gallery. This includes Pick Lines, Pick Supports, Pick Walls, Pick Roof Edges, and Pick Faces.

Co location

In sketch modes where more than one type of linear element can be sketched, a toggle was added before the gallery to communicate what is active and allow easy switching.  Example: “Boundary Line” and “Slope Arrow” for “Floor” and “Boundary, Run, and Tread” for “Stairs”.  Here the “Draw” panel ensures these sketch tools and the sketch method gallery are grouped together as they should be.

Below is a visual comparison between the two releases:

 

In tests users adjusted quickly to the new design or it was accepted without comment.  It is sometimes the best result when the task can be completed without specific comment on the UI - positive as well as negative.

_erik

Draw/Pick Gallery

During the implementation design period some 2009 features were identified for a closer look due to the frequency in which they are encountered and others by their importance.  Sketching tools scored high in both these categories.
Revit has an early strength in its re-use of concepts.  When not forced this aids learning and supports efficiency.  One could learn to sketch a floor and then leverage this knowledge to complete other tasks such as create a filled region, edit a wall profile or cut a hole in a roof.  Data analysis pointed to “line” as one of the most used commands and this was determined to be due to its use in sketch. Next we looked for opportunities to improve the comprehension and efficiency of sketching.   Video of user sessions was analyzed, the existing workflow mapped, and both evaluated on several levels.
Some observations:

• Hidden UI. Of the draw all the methods available (line, rectangle, circle, ect..) many were hidden behind a drop down. This created an extra step to view and access them (This design existed to conserve limited horizontal space due to the option bar’s single row).
• Tools and methods of tools were slightly blurred and given inconsistent UI treatment.  Sketch lines could be created via a sketch or a pick action (lines, walls, or roof edges). Sometimes 'Pick' was a tool and inother cases a method.
• Common sketch workflows required excessive mouse movement between the design bar and option bar and more importantly highly related items were not co-located.

I'll next relay the design solution and how it strove to address these areas.

Hidden UI

An early mockup provided an upfront dropdown of methods followed by a gallery on a contextual tab.

 

This version was not more efficient click-wise and the upfront portion was subsequently dropped in favor of the current design which was more like 2009 in providing methods contextually.  A ribbon gallery widget was employed to display all the available sketch methods equally.  Internally this is called the “Draw/Pick” gallery. This widget provided a convenient and recognizable container for a variable amount of content.

The following is a comparison between the two releases:

R2009

1. Click “Model Line”
2. Click method dropdown in the option bar
3. Choose polygon
4. Choose the circumscribed method
5. Set the number of sides to six

R2010

1. Click “Model Line”
2. Choose circumscribed polygon
3. Set the number of sides to six

Next post I will talk about rationalizing sketch tools and methods and co-location.

_erik

Ribbon tab and panel logic

The ribbon's tab and panel order, labeling and organization of tools follows a pattern that was designed to be flexible enough to accommodate multiple products while still allowing us to address Revit users' core work-flows. Before designing anything, our teams performed a series of day-long task analysis exercises with users and internal subject-matter experts to gain a clearer understanding of our five major disciplines (architecture, structural, mechanical, plumbing and electrical.) This research, in combination with interview, observation, and usage data collected over time led to the creation of work-flow diagrams that guided us throughout the rest of the design process. (Unfortunately, I cannot post these diagrams here, since they represent proprietary intellectual property.)

We then set out to design a tab and panel organizational system that could be applied consistently across multiple products and accommodate the varied user work-flows. This pattern went through many iterations. It basically boils down to these guidelines:

• Ribbon tabs represent a distinct work-flow (e.g. Annotation, Collaborate) or set of related tasks (e.g. View, Manage) The intent is to reduce the need for users to switch between multiple tabs to perform a series of tasks in a work-flow.
• Each tab is labeled with a single word (two at the most) that reflects the work-flow and clearly distinguishes it from the rest.
• Tabs are organized left to right based on a loose chronological order: You build model components, insert items, annotate the model, and so on.
• There should be no more than nine primary ribbon tabs.
• Panels represent groupings of tools used to accomplish a specific task(s) within the tab's work-flow. (e.g. Dimension, Detail.) Panels are ordered generally left to right based on frequency of use. However, based on usability data, we made exceptions and placed the most commonly used panel directly under the tab name to reduce mouse travel:

It is important to remember the ribbon was not designed to be configurable to fit specific work-flows (we explored this possibility, but had to shelve it) but to accommodate the major Revit disciplines. So the ribbon layouts had to be generalized to work across many different AEC work-flows. That said, we tested the layouts on many different types of users and tasks to ensure that it worked generally. The common tab labeling and order for all AEC products using the ribbon is as follows (bold items are in all AEC products - if  a non-bold item is in a product, it appears consistently in that left-to-right spot.) The ribbon is essentially split into two parts:

Content Creation

1. Home: Creating the building model
2. Insert: Adding content into the model
3. Annotate: Adding text, 2D elements  and detailing
4. Modify: Action-object tools - those that modify existing model elements by selecting
5. Render: AutoCAD products only (legacy tab)
6. Analyze: Running analysis on the existing model
7. Massing & Site: Creating massing and site objects

Managing the project

8. Collaborate: Collaborating with team members and coordinating model changes
9. View: Creating and modifying views
10. Output: AutoCAD only (legacy tab)
11. Manage: Management of the project settings
12. Add-Ins: Third-party add-ins (only appears when add-ins are installed)

This tab order was the result of many iterations. Throughout many usability tests one constant emerged: The tab label and panel organization are more important than tab location for discoverability. Regardless of the left-to-right order, as long as the label was clear users learned within minutes where all of the tools were.

To accommodate cases where a specific work-flow requires the a lot of switching between multiple tabs, we added two customization features that allow you to choose which tools to make persistent: floating panels and the Quick Access Toolbar. These will be explained in more detail in a future post.

Inventor 2010 Vertical Ribbon

The comments on the last two posts on screen real estate have been great. This is exactly the type of discourse we have been shooting for. I want to expand a bit on the vertical ribbon discussion and explore the topic of consistency. In his excellent paper on the topic, Jonathan Grudin, argues that pursuing consistency for it's own sake is misguided and that a user's tasks should override blanket consistency. To that end, the ribbon was designed as a system to be internally consistent to promote the transfer of learning but flexible enough to accommodate each product. For this release, each product team designed customizations based on specific users' needs and tasks and then prioritized the work based on the release schedule and resource availability. For instance, the Inventor team optimized their ribbon for expert use by developing a "compact mode" that turns all icons small and removes all labels (see below.) Our team, on the other hand, focused on customizing the contextual tab feature to accommodate the enormous number of possible combinations the Revit model allows.

The use of shared components across the Autodesk products is a relatively new practice. The customizations developed by each team during one release are evaluated for possible future implementation by the rest of the corporate products. With that said, what are your thoughts on the Inventor 2010 compact ribbon? Based on what you see below, is this something the Revit team should consider incorporating into a future release?

_tom

^{Inventor 2010 "compact" view of the vertical ribbon}