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

Comments

[Eric]

Example: Floor by face is on both the Home tab>Build Panel and on the Massing & Site tab> Conceptual Mass panel.

Same for Roof by face, and Wall by face

[Tom Vollaro]

Yes this is a good example. There will be future post on the sketch tools re-organization but essentially the massing panel provides a more explicit access promoting the 'by face' method as a top level command. This was the same in R2009.

[Chad]

TCBOO. Autodesk must not have been thinking about the number of mouse clicks?

The old UI had a nice medium of 'objects' on the left, and 'modifiers' at the top. Modifiers stayed on permanently so they are ready for use at any time.

Now in the new Ribbon you have to select the Modify tab which moves the user away from the modeling tools. So there is now a constant back and forth interaction. Home Tab - Wall > Modify Tab - Align > Home Tab - Wall > Modify Tab - Align > Home Tab - etc ... You can see the problem.
The change to a linear UI with the TCBOO rule has resulted in more work.

The Measure tool is on the Modify tab, but it's not on the Annotate tab, since it's a temporary form of annotation.
There is Area Plan on Home with the Room/Area modeling tools (which is fine), but it's not on the View tab where you would think to go to create a new view. These are just a few examples.

While the TCBOO rule is a nice thought, hasn't it now created other forms of confusion by a user not finding tools where they would expect to find them, or where a tool provides additional help with other tools?

So, how does Autodesk plan to address the increased number of mouse clicks which are now required to traverse the Ribbon?
And the relationships that individual tools have with many other tools that are now spread across other Tabs?

[Anthony Hauck]

We realized early on that tab switching would be an issue, particularly for the Modify -> Edit panel. That is why the Revit team fought hard to have the ribbon component updated from the AutoCAD 2009 implementation in two ways to address this: 1) Panels that float now "stick" when you change tabs. You can now float Edit panel and it persists, even if you go to another tab. 2) Allow the quick access toolbar (QAT) to reside below the ribbon and closer to the modeling space.

[Chad]

So when Autodesk realised that there were actually workflow deficiencies in a Ribbon type UI, rather than addressing the issues directly, the Revit team fought to introduce new methods that decreases the amount of workspace available.

In the posting after this one "Screen Real Estate", Autodesk are describing the space savings the new UI is offering, yet this is now negated when tearing panels off and/or moving the QAT in order to gain the most out of the new UI to reduce tab switching.

[Gareth Marshall]

If I recall correctly, the TCBOO rule is part of Microsoft's requirements for all fluent user interfaces. That said, they don't follow that rule in Outlook, so they can't be too serious about it - at least that's what we've decided in putting the fluent ui into our product.

[Tim Waldock]

Colour scheme of new UI.
I posted a question on the forum about the logic behind the colour scheme of the new ribbon UI - no response yet. I find the ribbon to be rather inconsistent in colours and often very difficult to distinguish between icons. please let us know the rationale . . .

http://myfeedback.autodesk.com/cs/forums/thread/306561.aspx

[Anthony Hauck]

Tim, Thanks for the feedback on the color scheme. We have a more detailed post on the icons and visual treatment in the works. In the meantime, to answer the two core questions:
1. The overall light gray color scheme was selected to allow you to focus on the most important part of the product: your model. That said, we also had to balance contrast to ensure the icons were distinguishable from one another.
2. The use of color in the icons follows a system we devised. Blue indicates a transformation from one state to another. Green indicates selection.

[Robert]

The basics tab may have been a happy accident due to marketing folks, and I understand the your arguments in favor of "TCBOO". However that said, a good trainer with good curriculum could easily leverage the Basics tab to make training go smoothly, while introducing users to the UI and Revit. I used to teach that Basics was just that, "the Basics", and it was helpful. However, all the tools that were there were also available in other "tool boxes". Basics, was more like the drawer in your kitchen where you keep a small hammer, scewdriver, measuring tape and a pair of pliers. You still have them in the garage, but sometimes it is nice to grab something from the kitchen....

You could literally build a very simple, but complete Revit building model from the basics tab, which was really handy. It is unfortunate that the new UI, while maybe a "good" UI in terms of UI design, does not do a good job of actually supporting our day to day processes of being architects, engineers and contractors. Technology should not support technology for technology's sake, it should support the core processes for which the technology was designed.

[Chad]

"The overall light gray color scheme was selected to allow you to focus on the most important part of the product: your model."

This is rather ironic.
The colours are 'soft' to focus more on the model.
Yet, with so much condensed into the Ribbon, which is ever changing with Contextual Tabs and the user constantly switching between fixed Tabs, that you can't not be constantly distracted by the Ribbon.
Since the user is having to refer to the Ribbon with practically every command, you might as well make it easier to identify buttons/icons.

[RobiNZ]

Tom, One aspect of the "Mk 2010" AutoCAD Ribbon not seen in Revit is the ability to have contextual tabs merge OR replace the current tab. I think this would address many of the tab switch concerns.

[Anthony Hauck]

Robin, actually, the Revit ribbon does "merge" with the primary ribbon tabs in certain cases. Specific examples include all sketch modes and group edit mode.

[Chris]

Manage Links appears twice - once on Manage tab-Manage Project panel, and once on Insert tab-Link panel. I get the rationale, but I prefer some duplicity - so long as it's not extreme. AutoCAD's Properties dialog/palette holds the record, surely. I think I once counted 7 different ways to open it.

[Chad]

Under Autodesk's own There Can Be Only One (TCBOO) rule, why does Orient to View show up under both the ViewCube and the Steering Wheel? Apparently having such a redundancy is a problem.

And in the interest of UI consistency, why is the menu structure for Orient to View on the Steering Wheel only one level deep, while the menu structure for Orient to View on the ViewCube two?

[Chad]

"...has resulted in menus like Modeling menu at right. Not only is this way too many items to scan efficiently..."

This is just a little more than hypocritical isn't it?
Let's do some comparisons of the number of top level *visible* commands on various UI areas from 2009 and 2010;

Modelling (Design Bar 2009) - 22 commands
Modelling (Menu 2009) - 24 commands
Home Tab (i.e. Modelling, Ribbon 2010) - 29 commands

View (Design Bar 2009) - 14 commands
View (Menu 2009) - 25 commands
View Tab (Ribbon 2010) - 27 commands

There are other areas where the number of visible commands are less, but as shown above, Autodesk has actually increased the visible command count, even your example of the Modelling menu doesn't live up to your reasoning with 5 more commands shown than in 2009.

I find it hard to beleive that this had anything to with the design of the Ribbon.