Inside the Factory

Revisiting the UI

The design team has been working on ways to improve your experience with products based on the Revit® platform. We have been conducting focused research as a part of our design process.  This research gives us the opportunity to test ideas, observe interaction, and receive feedback.  This has tremendous upside but can be limiting too; we can only include a relatively small number of users, during a relatively short period of time, and, invariably, we always want to ask one more question.

Now for a bit of an experiment...

This blog lets us reach a larger audience over a longer period of time.  You’ll find some design concepts below.  We are sharing these with a hope that we will receive thoughtful and constructive feedback from our readers that influences our design process.

To be clear, these are ideas and sketches we use to frame our research.  We are not making any promises that they will make it into a future version of Revit-based products.

We need both qualitative and quantitative feedback.  To help us quantify your feedback*, please take this survey <closed 9/9/09> after reading the entire post.  Further, we welcome any further suggestions* in response to our ideas, which can be submitted using the Comments feature provided on this blog.

On to the design ideas...

Idea 1 – Use of available space

In this first set of tab mockups (Figure 1), notice the subtle differences from the Revit 2010 UI.  This design takes advantage of the wider screen real estate (these mockups are done at a width of 1440).  This idea uses the horizontal space provided by wider monitors by making the icons larger and spreading them out more, providing larger targets and greater legibility.

 
Click image to enlarge

Idea 2 – Modify tab revisited

In this mockup (Figure 2), the Modify tab is moved to the last tab position.  The tab contains the most frequently used modification commands and several commands common to many workflows.  Please provide feedback regarding the contents of this tab.

 
Click image to enlarge

In this design, the contextual panels are merged with the Modify tab, so that your general modify tools, as well as your specific tools for an object exist on the same tab. These items are separated from the consistent items using color. Figure B shows the tab converted to the Modify & Place Wall contextual tab, figure C shows it converted to Modify Walls when a wall is selected and figure D shows Modify Text Notes.
An important aspect of this design is keeping the first 8 panels, up to and including the Match panel, of these tabs consistent and tools stay in the same position.  Each time a tool is presented, it is in the same location.

Idea 3 – No labels on common tools

To help increase the number of tools presented on the static section of the contextual tabs (see Figure 2), we are investigating no labels for many of the items on this tab.  The tooltips would still be available.
Do these ideas work for you and your workflows?  How would you change them?

Please go to the survey <closed 9/8/09>) and give us your feedback.

Thank you for your help.

*By posting, uploading, inputting, providing or submitting feedback or suggestions on this website ("Submission") you are granting Autodesk, its affiliated companies and necessary licensees and permission to use your Submission in connection with the operation of their businesses including, without limitation, the rights to: copy, distribute, transmit, publicly display, publicly perform, reproduce, edit, translate and reformat your Submission; and to publish your name in connection with your Submission, and the right to sublicense such rights to any third parties. By posting, uploading, inputting, providing or submitting your Submission you warrant and represent that you own or otherwise control all of the rights to your Submission as described in this section including, without limitation, all the rights necessary for you to provide, post, upload, input or submit the Submissions. No compensation will be paid with respect to the use of your Submission, as provided herein. Autodesk is under no obligation to use any Submission you may provide.

Occasionally, Autodesk makes statements regarding planned or future development efforts for our existing or new products and services. These statements are not intended to be a promise or guarantee of future delivery of products, services, or features but merely reflect our current plans, which may change. The Company assumes no obligation to update these forward-looking statements to reflect any change in circumstances, after the statements are made.

Autodesk and Revit are registered trademarks or trademarks of Autodesk, Inc., and/or its subsidiaries and/or affiliates, in the USA and/or other countries. All other brand names, product names, or trademarks belong to their respective holders. Autodesk reserves the right to alter product offerings and specifications at any time without notice, and is not responsible for typographical or graphical errors that may appear in this document.
©2009 Autodesk, Inc. All rights reserved.

Revitness Recap

This is a summary I gathered or inferred from the previous feedback on the Revitness post.

What we like (valued when present are missed when not):

• Inability to cheat.  To get the right output it must be modeled properly.
• The versatility of sketch mode and some UI workflows.  Skills once learned can be re-used.
• Bi- directional associatively - change in many places, when you want
• Real world objects and discipline specific terminology
• Strong underlying data model
  • Coordination of data (color schemes/schedules)
  • Editing same objects via graphical views or data views
• "Level of Detail" and other like features that allow a rich model yet convey it properly in different contexts.

Should be included

• Rapid and frequent releases of functionality
• Provide all the tools to make the model.
• Access to more data.  Tag and schedule more.
  • Expand internal data, keynoting, assembly codes, schedules, specs ect.
• Reduce the need for workarounds and work flow barriers.
• Improve consistency.
• More versatile or generic tools.

_erik

 

3D print courtesy Zach at buildz

The Drawing List Neighborhood

Often when looking at a feature or enhancement there is opportunity to make some changes "while in the neighborhood".  Imagine a feature as a comet.  When it's close to earth it gets a lot of attention - cameras, probes, discussion ect. - but then it is back to obscurity until it returns again.  The previous Fix, Fit, Finish post recaps how we identify features that need more polish.  When this process ensures a feature is again near there is a strong temptation to look at all aspects, revisit past decisions to take advantage of the moment.  Some early features were implementation driven.

On the other side, and continuing the celestial metaphors, on Venus mountains can be shaped by crushing atmospheric pressure known as "Venusian Creep".  The software version "Scope Creep" replaces atmospheric pressure with extra functionality that, while justifiable on some level, was not in the original requirements. This expansion unchecked could burden delivery of the entire feature.

Opinions often vary on when an enhancement suffers from creep.  In the factory we try to establish clear functional, design, and usability goals.  Revisiting these can often help make decisions on scope or portions that need re-work.....back down to earth to review some aspects of Drawing Lists.

Schedules of Sheets

Revit has a feature "Drawing List" which is essentially a schedule of sheets.  This can then be placed on a cover sheet and faithfully show all sheets that have the property "Appears in Drawing Lists" checked.

There have been requests to allow this feature to be more flexible in allowing for the inclusion of consultant sheets without having to make stand in dummy sheets.  These requirements are pretty clear.

• Are there other means beyond paper by which you receive a list of sheets from a consultant?  Text file? Spreadsheet? DWG file?  All of the above?
• If a sheet is on the schedule but not used in the project (consultant sheet)  what could this be called.  Rooms like this are labeled as "Un-placed".  Sheets are not really "placed" though.  "Un-used"?  "Listed only"?
• What about the term "Drawing List"?  "Sheet List" seems more accurate and "Sheet Schedule" would be even more symmetrical and Revity.  Then again If there are no training or learning issues it may be better left alone.

_erik

Modeless (continued)

A few posts back I shared the "Small Project Myth" the main topic being Revit's highly related object based system ensures even the smallest pieces of functionality can create many questions that need to be explored making them less small.  Modeless properties wouldn't be considered small from the start yet if small features aren't small are medium/large features proportionally larger still?

I'd like to share/explore some additional aspects of this hypothetical feature.  Follow the white rabbit....

"Dummy" Elements and "Rubber Banding"

A "Dummy Element" is an internal term for the element you are about to create.  To summarize: When you enter a command you can often continue to access properties.  Edits made at this time will affect the element you are about to create - the system presents a "Dummy" until a real instance exists.  Not all elements have had dummies since the beginning and some elements still lack them (e.g. Grids).  We are always trying to make progress on this and if properties were more visible the gaps will also be more visible.

Continuing...

If we have modeless properties then properties of the element to be created display whenever the tool is active.  Now when you draw a wall with chain enabled and the second wall is rubber banding the previous wall is technically selected.  With a wall about to be created and one selected which wall do the properties apply to?  My first thought is consistency should rule.  The properties should apply to the wall to be created just as it was when you started the tool.  The the rules would be:

• When an editor is active properties control the item to be created
• When Modify is active the properties apply to the selected element

"Sketch Mode"

Another place to look for additional special conditions are modes.
As mentioned in the previous post when the Modify tool is active and there is no selection we could display properties of the active view.  This received some positive comments in the last post. Is this as valuable in sketch mode?  An alternative design could display the properties of the sketch instance.  For example when editing a floor sketch if you select a sketch line the properties of this line are displayed. When nothing is selected the properties of the Floor are displayed.  These may be more desired than the view properties.  Would this be viewed as inconsistent or would the different behavior be accepted and even appreciated when in this different mode.

If anything is unclear I'll follow up in the comments.  Lets keep the previous discussion going a bit more.

_erik

Modeless

 
For a long time there has been a call to make properties more accessible.

The option bar has duplicated some that are also in the properties dialog but typically only the most common.  In user tests these option bar fields are often skipped over in favor of the full properties dialog.  I've observed engineers do this the most.  They favor the property dialog 99% of the time (like moths to a flame.)   One way to interpret this is the option bar lacked visual distinction in the UI.  Another is the full dialog is the lowest common denominator for properties.  You know the property is there even if it might be somewhere else. 
Another method for better access is more direct access in the canvas yet this is also unlikely to cover all properties - at least in the short term.
This leads us to the popular request to make the property dialog modeless.

The ability to take the dialog (specifically a more compact version of it) and keep it available could reduce the number of clicks by eliminating all the call and dismiss clicks - perhaps hundreds per session.

I still have a vivid memory of a discussion with a customer who was lamenting the property dialog.  He said something like "I feel like I'm always moving in and out of a data grid. I'm living there all the time".  He slowly transitioned his gaze down to the carpet as he said it - the tone very resigned.  I was moved.

Modeless property access is available in AutoCAD and its verticals via the palettes.  Other programs also have floating properties that update dependent on the context (Microstation, Photoshop ect..)

Below I want to explore some Revit specific  implications and possible designs with you.  Lets start with the most simple design:

Instant Update
Changes made in a modeless property dialog cause an instant update to selected elements in the canvas.  This is common with many other apps and provides instant feedback.

In Revit there are some issues lurking:
• Many changes cause the model to regenerate which would impose a variable delay after each change.  Some changes might be several seconds.
• Some edits can create an invalid situation (e.g. wall base constraint above a wall top constraint).  If everything updates instantly you would have to make the changes in a specific order.

Lets explore these issues in alternative designs:

User /Focus update
Instead of updating on each change the system will hold all application of the changes until you mouse out of the dialog or press an "Apply" button.  At this point all changes would be committed together.
You are free to edit parameters in any order even if they are temporarily invalid.
• There would be no feedback in canvas until you leave the dialog or press "Apply".
• There is a chance that if you created an invalid condition it will be more tricky to correlate the specific change that caused the error.

For the last item it may be possible to display warnings/errors in the properties dialog for better feedback but this could still add some delays.

Instant Update - Keep UI available
In this design the changes would be applied on each field change but would not prevent changing other fields.  Each time you change a field it restarts the calculation unless it managed to finish while you were thinking about it.  In this design the system time may be greater than either of the two previous solutions but since it favors keeping the UI available it should not interrupt the workflow - unless you decided to wait for it to complete.  You could make valid changes freely and observe the system update in between when possible or after you finish for more changes that cause greater change in the model.
This would require some new threading and other expense but is worth evaluating with the previous ideas.

Potential supplemental requirements
• Support quick access to the properties dialog for those that may not want to dock it continually.  Separate buttons for instance and Type.
• Take care that type changes cannot be made too casually / ensure these are distinguished in the UI
• Remember state between sessions
• Potentially integrate type selector (could replace ribbon access)
• When nothing is selected display active view properties

As we can see simply making something modeless has implications that need to be thought through to truly realize an improvement.  I welcome your evaluations of these issues, new requirements, and anything else related to property access.  if necessary I'll post a followup.

_erik

Last Command

In current research I have come across the desire for quick access to the Last used command.

The need is fairly well understood and there are several precedents.  Anyhow, I have come across a simple question I wanted to get some quick feedback on.

Scenario:

You are picking up some marks on a plan.  You place several dimension strings and then zoom the view to another area. You select a wall with the modify tool and change its type.  At this point you wish to place some additional dimensions.

You right-click and choose "Repeat %last command%" or hit the "Enter" key.

Question:

What is the %last command%?  Zoom or Dimension?  Should view navigation be included or excluded?

AutoCAD includes all commands.  I could also see a desire to separate navigation from modeling and editing.  Revit has some precedent for treating these separately such as the "Previous Pan/Zoom" command availability in addition to "Undo".

I'd appreciate any thoughts, opinions, or examples.

_erik

Call for Usability Study Participants

The Autodesk Collaboration User Experience team is setting up local site visits in the San Francisco Bay Area. They are interested in talking to customers in person to understand the challenges they face collaborating on design projects across distributed teams. 

From the team:
"We are conducting 1.5 hour usability sessions the week of July 13th in order to gather user feedback. We are looking for any BIM Design application (Revit or other model-based design application such as Graphisoft, Bentley) or VCD application users who share files with other disciplines outside their firewall.
This is an opportunity to make a great impact on the user experience Autodesk products and we welcome your company’s participation."

Complete this quick survey to sign up.

_erik

Revit(ness)

While we are on break I am taking this opportunity to schedule a post I have been formulating for some time.  Its not related to any specific feature but gets to the heart of "What is Revit" and therefore an exchange I have been eager to have with our customers.

evitness

In the beginning years of Revit there was a light hearted internal document that lived alongside the source code and other process documents called the “Revitictionary”.   Contained within were definitions of manufactured Revit terms.   Examples were “Revity”, “Reviteers”, “Revitorium”…you get the gist.   Sadly the document seems lost yet despite this loss I can recall one of the terms was “Revitness”.   If had to reconstruct the definition it would be something like this:

revitness

    -adjective
    The traits and behaviors of a feature that distinguish it as a Revit solution.

To me revitness is that behavior that caused you to grin when you used it for the first time - the venustas of the three vitruvian principles.

I am on a quest to gather some examples and work on this definition. Why? In the process of designing  a feature there are always precedents to consider.   Each new feature should consider the ones that came before to leverage concepts.   This streamlines learning and ensures consistent and predictable behavior.  These are the patterns.   I’ll cover how we identify and deploy these "patterns "in further detail  in an upcoming post. 

We are always looking for examples that should conform to a pattern yet don't.  In addition to improving consistency when there are certain behaviors that are known to be particularly enjoyable there might be elements of them that can be replicated.

This is my aim.  Its often easier to discuss what isn't working yet by calling out items which do work really well we can determine just what is about them and strive to replicate it in new features or enhancements.

Note: some may think Revitness is BIMness.  While this is certainly related I can think of examples in features that are not specifically related to BIM yet Revit users are glad for them - Annotation scale management for example.  Perhaps we can also explore BIMness in a future post.

What is Revitness to you? Do you have your own definition? What is your favorite feature? Why is it your favorite?

_erik

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

Keyboard Shortcuts continued

Thank you all for your feedback on the previous post.  I spoke to a few others offline and appreciate the responses.  A few cases were identified asking for access to specific UI items:

• Project Browser Show/Hide
• View Range

The first of these has an underlying command ID (ID_VIEW_PROJECTEXPLORER).  The second is a dialog control and lacks a top level command ID.  Its ID is: Dialog_Essentials_PlanViewRange.  In general dialog controls are accessed via tab, arrow keys and other dialog navigation methods.  In this case the control accesses an important dialog so a solution is needed.

Here are a few other dialogs accessed from dialogs:

Model Graphics:                                 Dialog_Revit_ModelGraphicsStyle
View Clipping:                                     Dialog_Revit_DepthClippingDialog

In some cases the dialog is accessible from two places, one of which is a command, and therefore keyboard accessible.

Home>Room Area>Color Schemes:     ID_SETTINGS_COLORFILLSCHEMES
View Properties:                                 Dialog_RoomAreaPlan_ColorFill

View Frame>Shadows>GD Options:    ID_GRAPHIC_DISPLAY_OPTIONS
View Properties>GD Options:              Dialog_Revit_ModelGraphicsStyle

These command IDs and control IDs can be read from in the journal files.  This is the reason why the Options Bar has never been accessible.  The implementation is an assembled strip of small dialogs thus all commands in the option bar are dialog controls.  A potential solution is to create command IDs for the ones that lack them so they can be assigned shortcuts.  This of course would be behind the scenes but I am explaining it here for the curious.

One additional question?  Is it still a requirement to have multiple shortcuts assigned to the same command?  Its possible now yet adds complexity to any design.

_erik

Keyboard Shortcuts

The one and two key shortcuts have been in Revit for some time and are something new users look for having found them useful in other programs.  In class I always get questions about keyboard access as soon as we start covering the interface.

How It works now

Any single or double character can be assigned to a command in the keyboard shortcuts file.

Once established the user can enter an alphanumeric sequence (e.g. “W”) and the associated command will execute unless:

• If a single sequence partially or fully matches other combinations (e.g. “WS”, “WF”) then these will display in the status bar one at a time in ascending order (“WF: Wall by Face”, then “WS: Structural Wall”).
• The user must complete the sequence or use the arrow keys to select the desired command.

Spacebar will execute the command

Shortcuts are only available for top level commands

Potential Enhancements

Increase the scope. - There should be the ability to access contextual commands and other areas of the interface that currently lack access such as the View Cube or Status bar.

Allow Modifiers (Control,Alt, and Shift) - Even with one and two character shortcuts possible the potential combinations run out fast.  Shortcuts are also less useful if the two keys are separated by too great a distance.  "VG" is great for Visibility Graphics not just because of the mnemonic but also because the close proximity of V and G on the keyboard.

Better UI - Some interface enhancements could help make assignment easier.

• A way to Filter commands by a UI area such as Ribbon tab, App menu, Status bar, Contextual commands ect..
• A way to search for a command by partial name
• Ability to Import and Export command assignments
• Ability to identify and resolve duplicates
• De-couple commands from the UI path.  It should not be necessary to define more than the command name and sequence.  This eliminates the need for multiple definitions.

Are there other requirements or comments related to shortcuts?

_erik

UI Sketch

Structure - Metal Deck

As many know Revit Structure implemented some features that the Architects have highly desired in Revit Architecture.  These features are Curved Beams, Slanted Columns, Beam system Tags, Beam Coping, Metal deck, and Truss. Feedback has been consistent. (If you want to reiterate past comments please send them here)  I've been investigating specific architecture requirements (if any) for these features and would like to quickly review and solicit feedback on a particular feature in this post: Metal deck representation in floors.

Behavior in Revit Structure

First I'll review the feature in Structure for those unfamiliar.

Floors have a layer function "Structural Deck" where a 2D profile family can be specified to represent metal deck in section views that are set to a "medium" or "fine" level of detail.

There is also "Span Direction" symbol that documents the direction and allows the user to manipulate it.  The symbol is placed automatically and if one is not present you are prompted to load one.  There is also an "Align Perpendicular"  contextual command that allows the user to align the deck to a slab edge when a Span direction symbol is selected.

Section View Behavior

Floor with Metal deck as shown in a section (0 - <45  degrees across span):

A perpendicular section shows the side detail (45 < 89 degrees across span):

At exactly 45 degrees both sections (horizontal and vertical) show the side detail.  Rotating the span direction or placing a rotated section achieve the same results.

Floor sketch lines also have a "Concrete Cantilever" and "Steel Cantilever" properties.   These control the slab edge condition.

Validation

I am looking for feedback on the following two items:

1. Assumption: Architects are interested in the 2D deck representation in sections but not necessarily the span direction symbol that Revit Structure requires to control the span direction in plan views.  Is there any need for the default span direction symbol if another method is available to control the direction?
2. There are some examples where architects show metal deck a single way (corrugated orientation) regardless of the true direction.  Is this just an old convention or is there a true need to document the deck this way?  I ask as it violates the idea of the drawing being an accurate representation of the model.

In addition to dialog on the above two items other comments related to the feature description are welcome.

_erik

Autodesk Sustainable Design Survey

The Autodesk Simulation User Experience Team is looking for feedback on the relative importance of different types of energy analysis data during the early conceptual design phase of a project. The survey should take less than ten minutes to complete.

Who Should Participate? Architects, Designers, Energy Analysts, Mechanical Engineers focusing on HVAC, and those who are doing design work with a focus on sustainability. Please forward this survey to any colleagues in these roles who may be interested.

The survey can be found here.

The survey will be active: June 1 – 8, 2009.

Please also feel free to let us know your thoughts on this survey and your experience with energy analysis in the blog comments. Thanks!

Looking forward

The lack of posts in the past week does not mean its been all Dos Equis and Guitar Hero here at the Factory (although that would be nice!) On the contrary, we have been very busy - not only re-examining the new user interface, but the larger User Experience (UX) team has been in "research mode" for the past few months. Since starting this blog in March, we have been focusing mostly on the present (the current Revit release) and the past (R&D that lead up to the release.) The comments to date have been extremely helpful and insightful (not to mention humbling in many cases.)  However, we never intended this to be the "ribbon blog," so we now want to spend some looking forward and examine some other ongoing research projects here at the Factory. We hope this will give you an idea of not only potential future areas of Revit development, but also the methods with which we conduct research.

A note about methods. Based on some of the comments in the past months, I am afraid people may have the wrong idea of how we conduct user research here. Although useful, sifting through usage logs only gets us so far. Much of what we do is pounding the pavement and getting out, talking and observing users and putting "meat" on the bones of our quantitative findings. This can take the form of observing users in their workplace, phone interviews, screen-sharing teleconference sessions, surveys,  focus group discussions, group brainstorming and usability studies of existing products, among many others. We are also constantly working to improve what we do, tweaking, mashing up methods and abandoning those that do not work. More to come...

_tom