Inside the Factory

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

 

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?

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

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}

Designing the User Experience at Autodesk

I want to quickly mention another Autodesk blog that launched at almost the same exact time as ours: Designing the User Experience at Autodesk. The contributors and topics will span the entire portfolio of Autodesk products and solutions. A few recent posts include a definition of what makes a great user experience by Chauncey Wilson (my manager here at Autodesk) and an introduction to Windows Presentation Foundation, the framework used to implement the ribbon in Revit as well as AutoCAD, Inventor and 3ds Max.

_tom

Screen Real Estate - The Vertical Ribbon

The ribbon component that Revit inherited from AutoCAD includes features that were optional for each product. Once such feature is the capability of being docked at the sides of the screen, known as the "vertical ribbon." The image at right shows the vertical orientation in AutoCAD Architecture 2010. During design we evaluated each individual feature separately to ensure it met our previously stated design goals and did not introduce major issues specific to our Revit implementation. In our evaluation of the vertical feature we found reduced vertical space created a tighter constraint on the ribbon contents and in many cases caused portions of the UI to be hidden and accessible only through additional scrolling. Throughout the design of the content organization we were careful to ensure the contents would fit within the target 1280x1024 resolution. This was to ensure a consistent and predictable location for the common top level tools.  The horizontal ribbon has a fixed height but the vertical ribbon does not have a fixed width so the need for scrolling could be exacerbated further if the width is reduced manually. Commands also re-shuffled in a different manner than with the horizontal ribbon.

Maintaining Consistency

Ensuring that content always fits in the viewable space was challenging given the nature of Revit's contextual UI. This UI is made up of hundreds (322 to be exact) individual pieces that are dynamically placed when creation or selection tools are active. As an example, the options displayed for a curved attached wall differ from a straight unattached wall. The different permutations are larger still. Our approach was to maintain this system but ensure, as best as we could, that options would appear in a consistent order and always be visible when they were active. In the case of modal commands such as Roof and Floor, the vertical ribbon would have often placed the critical Finish and Cancel buttons past the fold making them difficult to locate without scrolling. In the end we opted to forgo this feature, investigate it further, and concentrate on fine-tuning the horizontal ribbon layout in the time we had for the 2010 release.  If anyone has any used the vertical ribbon in AutoCAD we would like to hear about your thoughts and experiences.

-erik

Screen Real Estate

Hello,  My name is Erik and I'll be joining Tom on this blog in making posts and participating in discussion.  Over the years its been a pleasure watching the amazing work you all do with Revit and I look forward to continued contact with you in person and on-line.  On to the post...

Rather than more talk of real world foreclosures and falling home values, this post will start a discussion on screen real-estate. A positive effect of reducing complexity and adopting the new user interface (UI) has been to increase the amount of screen real estate available to the working view. In the 2010 default state there has been a net increase of 6% (based on a 1280 pixel wide screen at 96 DPI).  Most of this was achieved through the removal of the Design Bar.

2010 overlaid on the 2009 UI footprint (orange)

The option bar was another pre-existing UI element that received a lot of attention and design iteration. Prototypes were tested exploring possible replacements with the goal of addressing known issues such as discoverability for new users, mitigating horizontal space limitations. Although we retained the option bar in release 2010, it was slimmed a few pixels in height. We will be discussing the option bar more in future posts.

Shift in option bar height

Another enhancement concerned the project browser. We observed many customers running with the browser undocked on a second monitor, despite having to re-set it every session. Revit 2010 now remembers the project browser state and location between sessions.

During design we selected a minimum target resolution of 1280 x 1024 after analyzing customer data which showed this as the most common resolution. Now, I realize that many new monitors are 16:9 rather than 4:3 and many others are using dual monitors. To address this, the ribbon component allows for the ribbon to be docked vertically and/or minimized. We decided not to implement vertical docking in 2010 because of some design issues we felt reduced its effectiveness and needed further investigation.  As for minimizing, the two minimization states allow the ribbon to be reduced to 57% and 44% of the fully maximized state. I'll discuss the vertical ribbon and minimizing in more detail in the two next posts.

Concerning dual monitors,  I can say that multi-monitor support is one of our most highly requested UI features. We are actively researching this topic and we would like to hear more about your frustrations, experiences and suggestions concerning multiple monitors.

_erik

More than a pretty face

Although it is pretty, the new Revit user interface goes much deeper than just the surface visuals. When we embarked on the redesign back in the summer of '07, the AEC Product Design teams (consisting of representatives from the three Revit products, AutoCAD Architecture, AutoCAD MEP, and Civil3D) got together with the larger Autodesk Platform team and established design goals for this project:

1. Make the products easier to learn
2. Make it easier to switch between Autodesk products
3. Maintain the productivity of existing users
4. Update the Autodesk identity

Learnability

To accomplish the fist two goals, we needed to reduce the complexity of the UI. That is not to say we reduced the complexity of the product itself. Let's face it, our products are powerful and with power comes complexity, which is not an inherently bad thing. The problem is that the common impetus has been to give the user as many options up front as possible. This design approach, combined with an legacy Windows UI system (menus and toolbars), has resulted in menus like Modeling menu at right. Not only is this way too many items to scan efficiently but most of these commands were replicated on the design bar.

To address this redundancy, the AEC design teams established a rule: There Can Be Only One, or TCBOO (I think someone on our team must be a big Highlander fan.) This means a single location for a tool. Whereas the old user interface had two, sometimes more, locations for a single command. Our ribbon design is a task-focused, hierarchical organizational system. In such systems, it is best to avoid too much cross-referencing, or it becomes increasingly difficult for the user to find what they need. (See Rosenfeld and Morville's book Information Architecture for more on this. A relevant excerpt can be found here.)

Lets take as an example the old Basics tab. Some users we tested indicated they liked Basics. But when pressed, they usually conveyed a story about not being able to find something as they grew with the product. A little known fact: Basics was originally designed to make the product easier to demonstrate; the marketing guy would not have to flip around too much during the demo. In reality, Basics becomes a crutch. After using it for a while, user find themselves asking, "Hmm, Floor is on Basics, but Floor by Face is not. Is it on the Massing tab or the Modeling Menu or somewhere else? " This results in a lot of wasted searching - even after learning where the tool is located.

TCBOO lead to a lot of hard decisions. For instance, we debated a lot about whether "Component" is a modeling tool or something you insert. We ultimately placed it on Home because analysis showed that Component is usually accessed with other modeling tools, not while inserting. Of course, rules were made to be broken, right? We found some minimal cross-referencing to be beneficial depending on specific workflows. Can you find any examples where we duplicated a tool on the main ribbon (not counting contextual tabs)?

A big part of obtaining both the learnability and updated identity goals was related to the design of the new icons, which we will discuss in a future post.

_tom

Video Tour

For those of you not on the Beta, and have not yet gotten a chance to use the new release of Revit, here is an official video preview. I know I promised to stay away from marketing material, but this video does a great job of highlighting all of the new user interface functionality.

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
  
  

Introducing the new Revit user interface

One of the motivations for starting this blog was the introduction of the new user interface (UI) in the forthcoming 2010 release of the Revit products. This is the most significant change to the Revit UI since the introduction of the product in 1999. The most striking change out of the box is, of course, the use of the ribbon as the primary access point for commands. For many of you, especially those who have been using AutoCAD^® since last year's release, this will probably not come as much of a surprise. This is part of a corporate effort to unify the way our flagship products (that is, AutoCAD and it's verticals, along with Inventor^®, Revit^® products and 3ds Max^®) look and behave. This corporate-wide initiative started with the introduction of the ViewCube^®, SteeringWheels^® and the ribbon in AutoCAD 2009. For more on the Autodesk ribbon, see the June 2008 Cadalyst article in which Matt Stein gives some insight into the inception of the ribbon. Although the foundation for a new UI was set by AutoCAD, integrating this new UI into the three Revit products was a daunting task that required not only redesigning parts of the ribbon component itself, but also a complete re-thinking about how we design and implement the Revit user experience. I realize I am not the first person to post this, but for those that have not seen it yet, below is a screen shot of Autodesk Revit Architecture 2010. In the coming weeks we will be diving deeply into the design process that lead up to this transformation.