Inside the Factory

Putting Editing in Perspective

In Revit Sundial's What's New, you may have noticed this entry...

• Perspective views: Certain modeling capabilities are now available in perspective views: (See Work in a Perspective View.)
  • Editing tools: Move, Align, Pin, Unpin.
  • Reset Target tool: Restores the position of the camera target to the center of the field of view.
  • Toggle between the perspective and parallel representations of the 3D view.

Editing in perspective views has long been a customer request, so when I asked about it among the old-time Reviteers, most reactions were something like...

"Well, no one ever really tested it. We could try turning it on and see what breaks."

So, it turned out a number of things broke, which is maybe why we haven't just tossed it off sooner than this. A number of issues that turned up are fixable, but not immediately.

What Sundial has is what didn't break or was easily fixable. It could be possible to do more on this in the future. Interesting? Vital? Boring because you use 3DS Max for important visualization anyway?

Try it out and let us know!

Anthony

 

 

What's New in Sundial?

Hi everyone.

Judging from the heat coming off the servers in the last 24 hours, a lot of you have given Revit Sundial a try in the hosted environment. If you'd like to read about what's different in Sundial, click here for What's New.

In What's New, you'll see mention of Dynamo as a feature -- sometimes documentation visits us from one possible future, and we can only marvel at the modern wonders of time travel.

More information later today!

Anthony

REVITalizing Inside the Factory

We’re back!

Two years ago Inside the Factory went… well, inside the factory for a while. Recently we took a walk around the old place, blew off the dust, and did some remodeling, because we wanted to offer some news about what we’ve been working on.

The Building Authoring product team at Autodesk, (which includes Autodesk^® Revit^® and its nifty trademark symbols that Autodesk Legal^TM loves so much) will be using this blog to provide updates on Autodesk’s Building Information Modeling (BIM) product lines. A number of folks on the Revit team will offer insight from the Factory floor into what we're working on and introduce you to some of the people behind the products.

To get things started, we’re providing everyone within reach of this blog the opportunity to test drive a hosted release preview of Revit called Sundial.

Autodesk Revit Sundial provides enhancements to Revit that are not currently included in the commercial release. We will be highlighting the many improvements in blog posts over the next days and weeks.

For those of you who try the release preview, please drop in here at Inside the Factory and let us know what you think. The hosting technology we’re using for the preview is itself experimental, so if you run into issues accessing the test, we’d like to know about those as well.

The quantity of available simultaneous sessions is limited, so you may run into delays if there are many people trying to access the preview at once. We'll keep the preview available for a few weeks, so please try again if you can't initially gain access.

Because this is an early in-progress release, there are no guarantees all the features you might see or read about will appear in a future release of Revit. Please keep this in mind when making any future purchasing decisions.

Try Autodesk Revit Sundial

Anthony A. Hauck

Senior Product Line Manager

Bucky Bim

I sit next to Zach Kron here at the Factory. One thing Zach and I talk quite a bit about is the “hands on” approach to parametric modeling in Revit/Vasari vs. the more abstract approach of applications like Grasshopper and Generative Components. Zach calls this the “geometers” approach. That is, using good ol’ fashioned drawing techniques to define the base geometry and relationships. This keeps one very close to the actual geometry, versus the abstraction of spaghetti diagrams and the inaccessibility of code for those of us without comp-sci degrees.

For a while now I have been somewhat obsessed with the notion of building a parametric geodesic dome in Revit. I was originally inspired by David Light’s winning DesignByMany submission for Bucky’s Dymaxion House (which, by its geometry, can take advantage of standard divided surfaces. I quickly found that geodesic domes cannot be built using stock divided surfaces.) Also, I just love geodesic domes. I visited Bucky’s own Biosphere in Montreal this summer and committed myself to figuring out a way to build one in Vasari without writing any code.

The following video shows my technique, including an aspect of 3D snapping to surfaces that was pleasant surprise to me (and Zach as well!)

Coda: After building this model, I came across George Mokhtar and Iwan Peverett at BimAcadamy  who took a very similar approach. Interestingly, they generated their icosahedron as a pseudo solid using formulae. This seems a bit more efficient than my technique of stitching the intermediate components across the golden rectangles.

Another Coda: And just last week the BIM Troublemaker made some trouble with a stellated dodecahedron in Revit (sweet!) Yet another (probably more efficient) way to explore building this dome.

_tom    

 

Revit Schedules: A Love Hate relationship

Posted on behalf of David Conant - Principal User Experience Designer:

A product like Revit that is moving from adolescence to early maturity needs to revisit its roots periodically to make sure that it is not coasting on early glory. To illustrate, let me turn on the time machine.

The scene: An architect’s office late 1999.

The action: I am demonstrating a Beta build of Revit 1.0. On screen we see a floor plan, an elevation, and a window schedule. In the floor plan, I add a window. It appears immediately in the elevation and a new line appears on the schedule listing an instance of Window Type 2. I delete another window from the elevation and it disappears from the schedule and plan.

The reaction: “That’s amazing, I love it. Checking window schedules is so tedious. Now how do I put the window type symbol in the schedule? No? I’m going to hate that. What about adding comments or shading every other line? That can’t be hard. I’m sure you’ll fix it soon.”

Now: It’s 2012. Revit schedules can do much more than they did in 1999. You can add new properties, perform some calculations, and group header cells together. Unfortunately they don’t provide full control over cell format, won’t schedule a generic model component, or display a window tag. “You’re killing me” I hear.

Schedules and related elements such as Legends, Takeoffs, Lists, or Reports are powerful and highly useful features of Revit. They do, however, have a number of limitations both in the data that can be presented and how it is presented. Some are the result of constraints imposed by current interface tools, others reflect deeper issues in the Revit data structure and regeneration engines. To build a better picture of how the tools should be working, the AEC User Experience team is studying schedules and related non-graphical data display tools.

As one part of this research effort, I am gathering information on how you use or want to use schedule and schedule like methods in your work. If you are interested in helping us in this, I have provided a link to a short survey focused on your usage and a request for you to share image samples of what you are doing.  Samples of real work are an important part of our research. They will be used as test cases and help us illustrate themes as we explore methods to increase flexibility and capability. They need not be confined to what you can currently produce in Revit. Examples of what does not work well or appear correctly in Revit are more useful than what worked well.

https://www.surveymonkey.com/s/66BVMW3

_David Conant

 

 

Revit Spaghetti

Back in September, a little Revit add-in named Dynamo made the rounds through the blog/twitter-sphere. Dynamo is an early exploration into programming for Revit. It was created by Ian Keough, Solution Architect at Vela systems. Ian developed some serious Revit chops while working as an engineer at Buro Happold. He created Dynamo in his spare time and released it as an open source project under the Apache license on gitHub. Dynamo allows you to place and control family instances hosted on points using a familiar node wiring diagram interface – instead of having to write code. The installation is a bit wonky, so here are the steps:

1. Go to the Dynamo repository on github.
2. Click on DynamoInstall or DynamoInstall_32bit (depending on your Revit install)
3. Click on Release
4. Click on both the msi file and setup.exe. For each, click “View Raw” and that will allow you to download the file
5. Run setup.exe and restart Revit. I will post instructions soon on getting it going in Vasari.

Ian clearly admits: It’s incredibly buggy, feature incomplete, and completely undocumented. Regardless, this little science project is really cool and has generated a lot of interest internally as well as at Autodesk University last month. If you were were not lucky enough to attend Matt Jezyk and Zach Kron’s “Energizing Supermodels” course at AU, stay tuned. We will soon share some more cool stuff you can do with Dynamo. In the meantime, I put together a short video to introduce the add-in and show how to get started.

_tom

Exposing Design Detail via task Analysis

A lot of good design is overlooked.  When you are able to get a task done smoothly, without having to understand how to interact with a fancy widget or discover the way forward, you are often less likely to notice.  You may notice if the interaction pre-existed and was recently improved.  This happened to me the other day when Gmail introduced a button to delete trash contents in a single click instead of multiple.  I’m sure they realized that most people go to empty the trash completely and so provided a link for this.  Thanks Google. Things should just work and on occasion delight.

Having said this let’s explore a specific example I recently came across:

The requirement calls for a widget to create and store paths with logical names to external files.  Here is the initial design and workflow:

The user clicks “+” and a new row is created.  A default name assigned.

The user must next click in the “Path” field, then a dialog launcher will display.

Clicking on the “…” dialog launcher presents a standard “Browse for file” dialog.  Once a file is chosen and OK pressed the path is defined.

DONE

So looks good…or does it?  Let’s review the task flow in detail:

1. Create a new entry
2. Activate the path field
3. Click the dialog launcher button
4. Select a file (double-click or click OK)
5. Activate the “Name” field
6. Select the text
7. Type in a new name

Several steps fall into a category of things the user might not think to do or things that unnecessarily interrupt the desired flow.  Is the default name meaningful?  Should it be created before the file is specified?  Why make the user activate fields? (the dialog launcher does require field activation but this is due to a toolkit that has rooted itself everywhere in the UI – another post perhaps)

What would an idealized workflow look like?  Its pretty clear what this particular sequential task demands.

1. Create a new entry
2. Activate the path field
3. Click the dialog launcher button
4. Select a file (double-click or click OK)
5. Activate the “Name” field
6. Select the text
7. Type in a new name (optional)

Let’s see how close we can come.

The user clicks “+” and the “Browse for file” dialog is launched where the user chooses a file.

The path field is populated, the “Name” field matches the name of the chosen file (better default) and the field is activated and text pre-selected.  The user can now immediately type to specify a new name if they prefer something else or move on.

DONE

So we can see by performing this task analysis of what is performed by user vs. machine a more streamlined and pleasant experience can be had.  No fancy widgets.  Sometimes this analysis is easier to perform on working code - making changes in a second iteration but it could also be simulated via prototypes.

There are other places in the UI that could benefit from this analysis, renaming items in the Project Browser comes to mind.  Please share others, especially if they are frequent.

_erik

 

Friday Fun: Tweaking Parameters with Sliders

As many of you may have already noticed, Vasari 2.1 just dropped yesterday. Even though we have been launching a new version of Vasari about four times a year since November, we still wanted a way to get some new cool stuff in front of users even faster. So, as part of this release, we also launched a Works in Progress page on our wiki. The first (of hopefully many) WIP is a small add-in created for Vasari 2.1 by our summer intern that launches a modeless window with sliders that represent all numeric (number, length, angle, etc.) parameters in your model. It works in both the project (by selecting instances) or in the massing family editor. There are a few bugs, including one that will crash the entire application when switching between two open files - but that is what puts the "P" in WIP! So we recommend not using this on any production files. Which BTW, goes for Vasari as a whole anyway, since it is a tech preview.  Have fun! 

 

_tom

Student Showreel 2011 TU Graz

Today I'll share an uplifting video that came across my desk this morning.  Its a reel of student work at TU Graz.

 

I'm inspired.  I recall in school having to hide the tools I used because the use of technology was oft equated with the relinquishment of intent.  Since then it has been rewarding to work on Revit and teach it to local students. Things have changed. There are so many examples of real and imagined projects using these new tools.  Strong work all.

_erik

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

 

2012 Little Things: Type Selector

Now that 2012 is out of the bag I can take time to cover some of the smaller interface and design changes that made it into the product and might otherwise be overlooked. Today I'll review the type selector.

TS in Ribbon

When the type selector moved to the modeless properties palette some expressed a desire to get it back in the ribbon.  More choices for you.

 

TS Graphics

A small change in type names now align under the family name in the type selector drop down.  Previously type names were justified under the center of the image which created issues when trying to quickly scan the list.  This is very subtle but was easy so we knocked it off in the spirit of any positive change is good no matter how small and we should take opportunities when they present themselves.

TS in Sketch Mode

Saving best for last the type selector is now enabled inside sketch mode.  This was a very old behavior fixed.  I'll spare anyone the technical reasons why the button in the property dialog was disabled in 2011 but it was the same in pre 2011 releases though we did have a special property button that would bring up the type dialog then.  Now in 2012 the normal type button is enabled.  Kudos to the UI team for coming back to remove this inconsistent behavior that I know was source of annoyance. -erik

3D on the Web: Look Ma, no plugins!

I have been interested (obsessed, actually) with the idea of navigating and interacting with 3D worlds on the Web since the early days of VRML. Navigating and interacting with 3D on the internet has a long, torturous history. The solutions have fallen basically into two camps, both with their strong points and downsides. First, desktop gaming (such as Half Life, World of Warcraft, etc.) and virtual worlds (such as Secondlife) have been hugely successful at connecting users into a massive consensual hallucination. The downside of course, is that the entry points are still closed systems such as Windows, Mac and/or game consoles. The second, and less successful camp, is browser-based 3D. Almost as soon as the Web came into being, 3D was touted as the "next big thing." VRML, Java, and eventually Flash have all been used in a multitude of combinations to deliver interactive 3D to users on the web. Although these worlds were in-browser, they were (for the most part) solitary experiences and also required an additional plug-in.

I am happy to say that with the launch of Firefox 4 last month all of that is posed to change. Firefox 4, as well as the betas of Chromium and Webkit (Safari) based browsers now support WebGL. WebGL is an extension of the HTML5 Canvas object that uses the JavaScript programming language to display interactive 3D graphics within any compatible web browser - without the need for plugins. This means an explosion of hardware-accelerated 3D all over the web. What does this mean for BIM? Imagine being able to view, annotate, and edit your BIM from any device using the same browser-based user interface. There have been some demos that show WebGL running on Android devices and It is expected that the next generation of Safari on the iPad will support WebGL as well. This will give users a predictable, consistent and accessible interface for 3D tools on any device from PCs to tablets to phones and beyond. This will also allow software vendors to create true web-based 3D applications that are by their nature cross-platform (without having to re-write code.) I know it has been said before, but I predict that this is a tipping point in the history of 3D on the web.

If you are running one of the newer browsers, check out some of these sample works particularly relevant to BIM. Note: You will need to enable WebGL in your browser.

 

Fractal Lab, C'mon, its fractals that you can explore in 3D. Pretty damn cool.

PhiloGL allows you to explore parametric geometry equations.

Tessellations!  Exporting to an OBJ file is a nice touch.

Thingiverse.com is an online community where makers share their 3D creations. Any entry that has an STL file will have a little gray cube icon. Click and you get a 3D preview - with no plugins!

 

3DTin is a Lego style modeler. You build 3D models by placing colored blocks. It is quite primitive (literally), but demonstrates a good start towards interactive 3D modeling on the web.

 

_tom

 

Equality

As many know in Revit you can turn a string of  dimension segments into an equality constraint by clicking an EQ control. I'll summarize some of the capability:

  

Clicking the control creates a constraint.  If you delete an equality dimension you will see the warning:

"A Dimension with Lock and/or EQ Constraints is being deleted, but the elements will still be constrained. Push "Unconstrain" to remove the Constraints or "OK" to leave elements constrained."

Essentially the message allows you to remove the dimension annotation and the constraint or just the dimension annotation.  If the constraint is kept the elements will still try to maintain an equal spacing.

When a dimension is turned into an equality you can choose what text to display or if values are displayed instead.

The type property "Equality Text" controls the text value:

An the instance property "Equality Display" controls if the text is used in lieu of the actual value:

Now onto the requests:

Some of you have asked for a third option where the equality string can be customized.  In this case an entire equality string would display a single value derived from a formula such as 3 @ 4' - 6" or 3 X 4' - 6" = 13' - 6".

The elements that could be used in a formula would be:

• Number of Extension Lines
• Repeat Segment Length
• Number of repeating Segments
• Total Length

There are also different graphic styles for the interior segments:

I'd like to get more feedback from people that this matches your requests or if there is another aspect to equality dimensions you can't create easily with the current version of Revit such as display properties derived from the elements being dimensioned.

_erik

 

More Factory Kitchen Interactions

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

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

Let's bend down a little closer:

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

So the issue here is different things should look different.

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

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

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

_erik

Project Vasari Tech Preview 1.1 is now available

We are happy to announce that, just after three months since the initial release, we have an update to Project Vasari on Autodesk Labs. We have been working hard to deliver on some features that we were unable to get to back in November, fixing bugs, and more importantly: delivering some new experimental analysis features. So text annotations, metric templates, and STL export are now available. We have also further isolated Vasari from potential Worksharing badness by automatically detaching a work-shared RVT file upon open.

Now on to the fun stuff.  We have had the distinct pleasure of working with Dr. Andrew Marsh of Ecotect fame for this release. He has developed two prototype analysis features based on Ecotect technology. The Wind Rose tool allows you to visualize wind speed and direction data in your models for different seasons and times of day. The Planar Solar Radiation tool lets you perform solar radiation analysis in the external spaces within and around your site. Both of these tools continue the trend of visualizing analysis data directly inside a BIM. We also had the pleasure of working with an excellent team in our Shanghai office that has been porting over the Maya "Nucleus" physics engine to work with native Revit masses. In what I believe is an Autodesk Labs first, we have a coordinated launch of two Labs tech previews with one integrated in another. So now inside Project Vasari you can play around with applying real phsyical forces such as gravity and wind to mass surfaces!

Have you been using Project Vasari since the initial launch? Did you pass it along to some of your colleagues not yet initiated into Club Revit? One of our goals with Vasari is to introduce the concept of BIM and parametric modelling to a new audience that may be intimitated by Revit. I am curious to hear your about your experiences with this. Did this spur a larger conversation about BIM and analysis in your office?

_tom

Making Project Vasari

 

Yesterday was the day. We officially launched Project Vasari on Autodesk Labs. I thought I would give everyone a behind the scenes look at how this all came about.

Genesis

As we said in the teaser, it started as a simple question: What if we reduced Revit to its essentials? Followed quickly by: What would it look like? What would we keep? Who would it be for? This evolved into the following goals:

• Create a simplified "on-ramp" to introduce building information modeling concepts to students and young designers
• Focus on the conceptual modeling and cloud-based analysis work flows
• Create a "sandbox" where we can experiment on new features and concepts
• Deliver this as a technology preview on the web

Design Tenets

The following design tenets were our guiding principles as we began conceiving of what to make

• Let users get their hands dirty faster
• Reduce modality
• Focus on teachable moments
• Progressively disclose complexity
• Build a community

Personas and Storyboards

A persona is a one-page narrative that describes a fictional user based on user data we have gathered. After interviewing and surveying many students, we distilled that data into Gabriel .This helps us keep the team user-centered. As we face various decisions, we must ask "what would Gabriel   think of this?"  We also wrote a series of scenarios - stories with Gabriel as the main character. These act as the basis for some early sketching and storyboards (note, not all of these ideas made the final cut.) 

Being Agile

In addition to the previously mentioned goals - we also wanted to see what a small team could do in a short amount of time. By "small", I mean one product manager, five software developers, two designers and one quality assurance analyst/blogger/mad scientist. By "short time" I mean six months from inception to delivery. To do this we adopted a more agile team process called Scrum. I won't go into much detail, but to put it simply Scrum is like IPD for software development: A cross disciplinary team co-locates to increase collaboration, breaks down roles to foster innovation (QA helps with design, designers do some coding, etc.) focuses work on a central information repository (in our case, the source code and a wiki) and shares equally in the risk and reward.

So, isn't this just Revit with a bunch of stuff removed?

Yes and no. Yes, it is Revit at its core. But no, we did make some progress in some areas - primarily related to our design tenets. Ultimately, Vasari has become a platform to experiment and take some risks - something that has become difficult when trying to get the larger Revit out the door each year. So what's different?

• A smaller, less imposing user interface.
• Access to massing tools is more streamlined. Were you asked to switch visibility mode when creating a mass? Were you asked to name your mass when you created it? Did you actually have to create the mass at first?
• You can double click to edit an in-place mass and double click to stop editing it. My personal favorite.
• When you are editing an in-place mass the background changes color and non-edited masses become transparent.  Notice I said reduced modality, not removed. We follow Jef Raskin's definition of modality, that is, an interface is not modal as long as the user is fully aware of its current state.
• Levels and reference planes are now visible in 3D in the project environment. This allowed us to keep the experience primarily in 3D, with little need for 2D views.
• The product is delivered in a nice, compact, single executable. No licensing. No big installer wizard.
• Realistic views have edges turned on by default.
• And our dirty secret? Much of the look and feel was achieved using a plain ol' Revit template.

What's Next?

I can't say. I know, I know - tight lipped as usual. Actually, it is because I really don't know. I do know that we have generated a lot of ideas (stories in our backlog, to use Scrum terminology.) Now that we have some time to breathe we will listen to the feedback that comes back from our target demographic, sift through the backlog and decide on what to tackle next.  Until then, come join us on Facebook and Twitter where we will continue the conversation. 

_tom

A video introducing Project Vasari's features:

 

Its the Little Things - Default 3D Views

Another subtle 2011 change.

Problem

In every release of Revit going back to the start we've had the concept of the "Default 3D view".  You click the little house icon and get a 3D axon view named "{3D}".  Renaming this view preserves it and allows another one to be created using the same method.

When worksharing came into the picture the {3D} view started to become a source of contention.  A project team member would manipulate the view and it would be signed out to them.  This then caused other team members to receive a permissions warning when they tried to manipulate the same view.

Workaround

The work around was to save off individual views for each user but the convenience of the Default 3D View tool continually caused the situation to reoccur.  Several customers had brought this issue to our attention.

Solution

Now in 2011 the Default 3D view is user specific and works the same as it would in a non workshared file. 

When the little house icon is clicked it looks for a view named {3D - username}. Username is defined in the application "Options" "General" tab available from the "R" application menu.

If this view exists it is opened, if not it is created.

The system always directs people to their own default view so the previous contention is eliminated.

 

_erik

 

 

Interactive Facades

Or "How to improve on a Gehry design."  Somewhat off-topic, but I have a thing for these animated facade projections that have been appearing over the past couple of years. This recent one is particularly cool:

The LightLine of Gotham from seeper on Vimeo.

File under "If and when I get some extra time:" Use a Revit model to design and simulate a facade projection using the new Analysis Visualization Framework. Then hook the visualization up to a hardware system using openFrameworks and arduino to drive the projection. Or, one could project real-time data visualization about the building's energy and/or solar performance right on the facade - a public display of green-ness (or lack thereof.)  One can dream.  

Here are some more fantastic examples:

Architect Simone Giostra talks about GreenPix - a media art LED wall that is powered by the sun. Extra cool: they have built a free tool for simulating your own videos. The user interface is kind of clunky, but it demonstrates how one could start to simulate these types of installations using a 3D model.

UrbanScreen does some amazing work 

555 KUBIK | facade projection from urbanscreen on Vimeo.

 

Also from a couple of years ago, this is a bit more fanciful (made with After Effects not actual projection) but I love the decidedly low-tech approach

 

Modules from endemic project on Vimeo.

_tom

 

Its the Little Things - View Titles

Note this small change in 2011 that came directly from customer feedback.  The title of tiled windows has always been: %Project Name%-%View Name%.  This was inverted in 2011 so that when many windows are tiled the view name (most unique item) is last to be truncated.  The specific use case involved reviewing a large number of views such as a set of standard details.  It can often be easier Tile "WT", Zoom All "ZA" and find your view.

_erik

Got Essential Skills?

Last week inside the factory we held our (mostly) weekly design pinup. These lunch time pinups give interaction and product designers the opportunity to pin up an unfinished design and have others throw darts. You know the drill. This particular pinup was not focused on a particular interface or feature design. Instead, we brainstormed on what constitutes the absolute essential skills for first-time Revit users to learn. Our colleagues in the Media & Entertainment division pioneered the concept of Essential Skills Movies back in 2002 when they released the Personal Learning Edition of Maya. This was a free version intended to introduce the product to new audiences. During usability testing, the user research team noticed common problem areas that made users stumble and sometimes even abandon learning the product. The team distilled these issues into seven 60 second movies that introduce the most essential skills needed to have a successful first learning experience. It is interesting to note, we have been talking a lot about in-canvas and more direct model interactions vs. "traditional" user interfaces such as toolbars, ribbons and menus. The problem is, our industry has not standardized most "direct" interactions, so they remain hidden to users. This technique is a nice way of lowering that initial steep learning curve and introducing features that may be, by there nature, hard to discover.

The Maya 2010 Essential Skills Movies starter screen. Notice the topics focus on basic concepts such as navigation and selection - more advanced topics are accessible from the red button.

We decided that this method was intriguing and deserved some thought on how it could be applied to Revit. Below is the list we came up with. Note: the ultimate goal is to get this down to no more that seven movies. And each should be no longer that 60 seconds. The Maya team has done a lot of research and found that this combination of quantity and length strikes the right balance. In your experience learning and/or teaching Revit, which items would you add? Remove? Modify?

• Families: Parametric, coordinated models, not just 3D forms.
• Views: Coordinated views of a single model, not just 2D projections
• Constraints and hosting
• Navigation:  Mouse wheel, viewcube,
• Datums: Grids, levels and workplanes and why they are the important building blocks of any model
• Selection: Pre-highlight, ESC key, Tab select, right-click, displaying properties
• Temporary dimensions

Its the Little Things - Ceilings

An update on a couple of small interface changes related to Ceilings.  In 2010 with the ribbon we received more than one question about "What happened to the automatic ceiling placement?".  The answer turned out to be nothing - just a trick of the eye.   The confusion was understandable on analysis.

In 2009 you would enter the Ceiling command and start clicking away (more on that below).  While in the command there was an unassuming contextual button in the option bar called "Sketch".  This would allow you to enter a sketch mode rather than get the automatic flood behavior.

In 2010 this button moved to the ribbon and got a lot more attention..so much that many more people pressed it rather than stay in the "automatic mode".

Those who have taught Revit will know people often overlook the option bar despite all reminders - perhaps because it blends in with the toolbars.  The fix was simple enough.  The next 2010 update, and subsequenty 2011, indicated the current state next to the Sketch option as a toggle.  There is actually no way to press "Automatic Ceiling" and the command is just the same "Ceiling" command yet it solved the issue by indicating the state.

oh yes....the other change is if you click more than once in the same place with the Ceiling tool in automatic mode you now get a  warning.  This was an issue going way back.  We did have warnings for components but not items that were sketch based.  No more piles of ceiling elements or floors for that matter.

_erik

BIM Analytics 2010 Conference

I was fortunate enough to attend the fourth annual BIM Analytics Conference on the USC main campus in LA earlier this week. It was a real pleasure to spend some time with top educators and practitioners who are really pushing the envelope of BIM. Preceding the conference, I also attended one day of the provocatively titled "Kill Bim" session in USC's ExecED series. I am not going to go into detail on each talk (hopefully the organizers will post the content online soon.) Instead, I pulled out a series of themes that kept coming up over the course of two days.This is just a quick summary and I plan to delve into these topics more in future posts. I am also curious to hear your impressions and in-the-field stories related to these topics.

BIM and Analysis - What questions can I ask of my model?

Based on the premise of the conference - and the breadth of speakers - BIM is starting to deliver tangible results as a platform for analysis. Obviously, analysis is a broad term, and the range of speakers reflected this. CO Architects presented a case study in how they were able to deliver a unique copper cladding scheme within budget by carefully tracking material costs within their BIM. Arup shared their technique for creating acoustic "fingerprints" to realistically recreate, simulate and analyze spoken voices within a virtual model of a court house. There were also a variety of examples of architects using tools such as Ecotect and EQuest to perform early and periodic analysis of day lighting and energy performance throughout the design process. The democratization of these tools (in terms of cost and usability) is clearly making an impact on the industry. However, the question of accuracy versus precision came up at various times. These tools present a danger in that they present compelling and precise results - but if the accuracy is off, a designer could be lead astray. It is interesting to observe the larger industry conversation switching from "how do we build BIMs" to "what kind of questions can I ask of a BIM once it is built?"

IPD and "Who owns the model?"

I apparently missed quite a lively discussion related to IPD on the first day of the Kill BIM session. But the topic kept coming up in other talks. It appears that many thorny legal issues are yet to be ironed out before a digital BIM can act as the contractual record of the design intent. The state of art still seems to be printed documents from a BIM acting as legal documentation. This is not my area of expertise and I would be curious to hear from others about their experience with IPD and/or using a BIM as a contract "document."

BIM and Facilities Management

A topic for a longer post. The question boils down to this: "Why has this not been solved yet?" Of course a handful of people will respond "Well, we ARE using BIM in FM" (but digging further you find their workflow is incredibly circuitous and painful)  It still appears that this is one of a few remaining BIM frontiers.

Interoperability

Also a topic for a follow-up post or ten. The discussions and debates this week tended to focus on the pain of file translation between the multitude of platforms and tools. It started to really dawn on me by the end of the two days: BIM is not being served by the whole files and folders paradigm - especially as project complexity balloons and teams disperse across the globe. Cloud-based access to data, real data - as in queries not a bunch of files on a server - is coming, but it is a sticky problem that has not been solved yet. Once again, a potential game changer. As product designers, we love sticky problems. Bring it on. More to come...

_tom

Feature Stories continued | Elevation Tags

Lurking Evil

I use this term to describe items I know are going to crop up and challenge what may otherwise look like a feasible design.  It lurks in the strangest places yet often stems from conflict with adjacent features, other new features developed in parallel or legacy Revit weirdness.

In the previous post custom elevation tags has a design and is moving forward.  For those who keep track of Revit trivia the feature was born on 20090930_1159 (yyyymmdd_hhmm).  After this date one could fire up a development build and test the feature out.  It’s always desirable to get live code early in a release since problems are easier to witness than imagine.  ….On to some of the issues:

Upgrade

Pre-2011 hard coded elevation tags were somewhat customizable as long as the built in properties could make a tag you liked.  Properties controlled the shape of the tag, how pointy the arrows were, label presence, and label location.  In the 2011 release we planned to ship new content that would match the old content yet this exposed some issues.  Take the ‘View Name Position” property.  Families do not have a property that controls text or label position.  It would be silly since you can just place a label where you want but the hard coded elevation tags required a positional property.  After some brainstorming it was decided that we could make a type for each possible combination of text and label location using visibility properties to turn them on and off.  On upgrade we would map to the type that matched the existing condition.  Sounds good yet the “Text Position”, “View Name Position”, “Reference Label Position” and the “Show View Name” properties demanded 4 x 3 x 3 x 2 types!  The fact that the pointyness of the arrows shifted the labels suggested infinite types were required!  In the end we decided that we could not ensure the tags looked exactly the same after upgrade but we would ensure the same labels were present keeping drawings readable and accurate.  It would be possible to correct the upgrade results manually if this were required.

Reloading Content

Given the capability of loading elevation tag content what happens when elevations exist in the project and the new symbol is different than the original?  How many ways can it be different? This scary issue was raised early so we got a leg up on many of the solutions before actual implementation.  Here are the main cases and solutions:

• If the user desires to make cosmetic changes to the family they must edit the family and reload it into the project.
• • The instance will update on reload without affecting views provided the direction and number of nested pointers is unchanged.
  • Adding new arrows are OK as they do not instantiate a new view until checked.
  • Line work and labels changes are remapped.

• If the new symbol arrows are in the same relative direction and quantity to the base family as the project elevation instance then the system will match the orientation of the new instance to that of the placed instance and remap the arrows in the old instance to the new instance in a clockwise fashion.
• If a new instance is the same as the original but has fewer arrows than any used arrows the new symbol will be considered incompatible.  The user must place a new symbol and delete the old views.
• If the base and pointer arrows do not correlate in number or direction then switching type is disallowed.  The new symbol will be considered incompatible.  The user must place a new symbol and delete the old views.
•  If the user deletes an elevation family and it is instantiated in the project a warning will be issued similar to the one shown below for a callout head family.

Tag Rotation

It turned out that when placing elevation tags the hunting behavior (where it identifies nearby walls) caused the system to rotate the tag.  This caused the now possible asymmetrical tags to be rotated large amounts and look stupid.  A new algorithm had to be created that would choose the arrow from the tag that caused the least rotation rather than always rotate to the top arrow. The existing behavior was impossible to know because all the original hard coded tags were symmetrical. Here is the issue before and after resolution:

 

Text Rotation

It turns out that the hard coded elevation tag text maintained an orientation. 

Labels in our custom families did not have capability this before 2011.  We decided to open up and expose this property.  Now there is a “Fixed Rotation” property for all family text and labels the family category Elevation Marks  A similar property is still needed for lines to get the section head behavior.

Those were the biggest issues.  As you can see nothing is ever a simple as it seems on the surface but I have to admit solving these is half the fun.  Design is a form of problem solving - there are always constraints.  The end result is more rewarding having overcome these obstacles.

_erik

Retourner and Feature Stories

Hello!  I’m back from a break and ready to re-take up blogging.  Thanks to Tom for his efforts to keep the information flowing.  As many fellow bloggers out there know ..its work.

I was fortunate to visit some great cities: Amsterdam, Cologne, Munich, Bern and Lucern.  The U.S. should look to its past and across the ponds to re-establish some decent rail service.  It was really a treat riding speeding ICE trains that arrived exactly on time and dropped me off right where I wanted to be. 

…anyways back to work.

I’ve gotten some first and second hand feedback that people enjoy posts that provide insight into factory feature production.  Given this I’ll make an effort to share some stories on some 2011 features and start with ....custom elevation tags.

The first thought of anyone who didn't learn Revit this year is probably what took so $%#&@#* long.  .........yeah....ummm.....sorry..about that.

The main complicating issue was the fact that elevation tags differ from all the other symbols in that they supported multiple views.  This required a different solution and complications kept inflating estimates requiring more people to be involved who were already booked ect....ect...  Believe me we wanted to solve this guy and it was a real let down each year when it remained an open issue.  2011 it was do or die.  This thing would not get the better of us.

Lets review some solutions that were explored over the years.

Allow one to choose a symbol to use for the arrows and one for the body.

This seemed fine yet the body and arrows are closely related making it difficult to imagine how one could make the content so it all lined up properly in the project.  When you edit a section head or tail they are always separated so they don’t affect each other.  Not so with elevation tags.  Imagine someone iterating for a long time trying to get it right. Additionally no joy for those who needed flexibility in the number or direction of the arrows.

Draw the arrows and body in the same family and use a parameter or subcategory to assign line work to a view direction or the body.

This was workable yet again didn’t allow for flexibility in view direction or the number of views.  We'd have to hard code the directions (up/down/left/right) and the number of views (4).  It would also be possible to assign a left arrow to a right view or forget to make an assignment which is stupid. It looked like a very manual and error prone process.

Copy Section code to the Elevation category

This would allow you to place something like a section but Revit would treat it as an elevation.  Let’s just call this a hack.  It would be a gesture but leave many requirements on the table - multiple interior views for instance.

Nesting!

This was the breakthrough.  One could make an arrow symbol and nest it into the body symbol.  This would allow the arrow to behave as a single thing rather than a bunch of lines and one could accurately position it relative to the body previewing the final assembly.  The view direction would be inferred by the system and the number of arrows could be 1 - n.  Happy Joy Joy!  There was a concern that family nesting was too advanced to be a required skill yet BIM managers typically make the content. We would also ship examples for modification.  All examples we had collected were now possible as well as some unconventional examples:

Work left to do?

Sections have an embedded behavior where the symbol line maintains a horizontal orientation.  Many would like to see this capability in elevation tags.  Currently this only works for the lines in the section content we ship so there would need to be some UI exposed to allow you to specify if a line can rotate or not.  Please share any additional items below.

Next

In an upcoming post I’ll continue this story as work hardly ended once we had the design.  Features often encounter something I like to call “Lurking Evil”.  In this project it came in many forms.

_erik

Bill Buxton on the parallels between architecture and software design

I just finished watching this video of Bill Buxton speaking at the MIX10 conference. Buxton is the Principle Researcher at Microsoft and worked extensively on design applications at SGI and Alias (in the pre-Autodesk days.) Recently he has gotten a lot of attention in the user experience design circles from his book Sketching User Experiences (well worth a read.) In this talk, he makes some parallels between architecture and software design. Having one foot in both software and architecture worlds, I think often about these parallels, so I was intrigued. A number of people have written and spoken on this topic, but mostly with a focus on the how Christopher Alexander's pattern language methodology has been subsequently adopted by the software world. Buxton takes a slightly different tack. He talks about changing the culture at Microsoft so all projects have business, technology and design having equally represented. "For every project you need the same depth and same level of creativity from each of these three professions. Each is essential. None is sufficient on their own. Their success depends on how they intertwine and work together." Sound familiar? If you replace business, technology and design with owner, builder and architect and you realize the kernel of what he is talking about is similar to Integrated Project Delivery. Of course, I do not think the Seattle Public Library was designed and built using IPD, but he illustrates that user experience design is behind the curve of even "traditional" the design/bid/build process because in most software shops, developers still call the shots primarily. This is mainly because user experience design as a  discipline is very young (measured in decades, not centuries.) Thankfully this is changing rapidly in the software design industry as design continues to take on a more central role in the development of new products, including at Autodesk. Buxton makes another important point: we don't want to turn the tables and have cranky designers calling all of the shots, either. We must form collaborative teams where all three disciplines have equal say, equal stake, and take equal risk so we can all fail or succeed equally. As many of you are with IPD, we user experience designers are entering into a new paradigm where collaborative teams are the norm and all three disciplines are expected to be able to be conversant at a minimal level about the other two. If people are co-locating, talking more, and sharing a central model (be it a BIM, software code, or other database), I think only good things can happen. The closest analog I can find to IPD in the software world is Agile development... but that is a topic for another post.

Bill Buxton, speaking at MIX10 - the first 15 min or so is his presentation and the rest is discussion with the audience.

_tom

Bill Mitchell, influential urban theorist, passes away

Bill Mitchell, the former dean of the MIT School of Architecture, author, and founder of the Smart Cities initiative died this past friday. Unlike some of the people at the Factory, I was not fortunate enough to know Bill or work with him at MIT. However, his passing does bring back memories of reading City of Bits when it was published during my last year of architecture school. That book, among others, played a part in my eventual move from architecture to software and interaction design. At the time, there was much breathless talk of the death of physicality and how we would all just "jack in." All architecture would be experienced purely through the visual cortex (etc. etc.) Mitchell took a slightly different tack in City of Bits. This book focused more on how physical architecture, from the building to urban scale, would be fundamentally altered by this new paradigm, not necessarily replaced by it. Much of what Mitchell wrote about in City of Bits was pretty spot on. Considering that it was written just as the Web as we know it was taking shape, much of the content, ranging from issues of personal privacy to the impact of technology on the nuclear family, does a pretty darn good job of describing our world today - for better or worse. 

I leave you with some memories of Bill Mitchell from Factory veteran David Conant:

The design community has lost a great thinker. One whose ideas provided foundations for the very work we are engaged in on a daily basis. Several of us on the Revit team were touched directly by Bill and his work as we started on the paths that lead us here. In the early day of Revit, we met with him several times to discuss the feasibility of our effort. He was most encouraging. As he moved on, he never lost that clarity that allowed him to be thinking 10 years ahead of the tools and paradigms used in practice. Bill’s passing will be a loss to all who are involved in the community of design.

_tom

on Type and Instance

The concept of type and instance is a core Revit concept.  Some elements need to vary while others need to remain coordinated.  In conversations with customers I often hear that Revit could support the design process better.  This usually means moving things around, testing ideas, and swapping out content in an unrestricted manner.  Types add restriction yet if everything is an instance a lot of power is lost.  Lets explore this topic and start by reviewing what Revit offers now.

Curtain Wall can define Grid and Mullion patterns quickly by type.  Once a type is established you can choose to "un-pin" a sub-element to change its type, location or very existence.

These elements have a "Type Association" property which can be "Dependent" or "Independent".  In this case one may end up with a mix or type driven elements and others that can vary from other type instances.

Grids and Mullions can also be added to a Curtain Wall which has a pattern in its type.

In both the above cases you end up with a Curtain Wall that is mixed as to whether its elements are defined by the type or instance.

What about Structure?  "Beam System" has a command "Remove Beam System" which essentially makes all the beams behave as if they were placed manually.

 

Curtain Wall has a similar feature.   If you swap a Curtain Wall Type with a pattern layout defined for one that is undefined you will be asked if you want to keep the sub-elements as instances or delete them.

This is a little different from removing a Beam System as the type still exists yet its just set to "None".  The obvious question then is why doesn't Beam System have a layout rule option "None"?  ...an unfortunate inconsistency.  Beam system also places these properties at the instance level so it wasn't a type to begin with.  It would probably be good for Beam System to match curtain wall and while we are at it for Curtain Wall to have a "Remove Type Layout" command.

The work-flow I see missing from this is there is no way to convert an instance into a type.  Groups are the only thing I can think of.  You select some items and Group them which wraps them in type goodness.  The family editor also allows you to convert a parameter between type and instance.  What if you could mess around with Grids and Mullions on a Curtain Wall, select some and define it as a type layout once you arrived at a nice pattern?

Is fluid conversion between type and instance a step on the path to better supporting design?

...or

should there be a way to isolate and edit a type instance graphically?

...or both!  Thoughts?

-erik

Its the little things...

A few years back I was renovating a bathroom and after the demolition and new framing I vacuumed all the stud bays and nooks before putting up the cement board.  The plumber noted I had done this an remarked on it.  "I saw you cleaned...not many would do that knowing it won't be visible later.", he said.  "Yeah I'm obsessive this way", I replied.  "Sure", he said, "I had an uncle who made me do that...I told him Why bother when it will be hidden?"  My uncle replied, 'God will see it' ".

I filed this little exchange in my memory.  Whatever your beliefs are its always nice to walk away from a job knowing everything is ship shape.  Electrical outlets are aligned, the switches are off in the down position, door knobs are at the right height, doors swing the correct directions ect...

2011 has lots of subtle tweaks to make your life better.  Some of these were requested and others were things we observed since we too use Revit and what bothers you bothers us.

Temp Dims: They have some new UI to control their display (App menu>Options>Graphics):

When you reposition them they stay next time you select the same element:

Family Types: When making parameters the default type is length (most parameters are length right?)  When you choose another type like "Material" Revit will set the group to "Materials and Finishes" for you.  Less work for those conscientious family craftsmen out there.

Properties: Aside from loosing their modality (not so subtle) which should save a few thousand click a year the properties are indented under their groups.  This helps with scanning.

I have a long list of new requests for properties such as better ordering of the properties and shading of the dialog. Each time we are "in the neighborhood" we try to make things a little tighter.

More are out there. If you caught any feel free to share with the other readers.

_erik

Calling all hold-outs

Many of you spend a lot of your time evangelizing Revit within your offices, and for that we are eternally grateful. But what about those stubborn hold-outs? You know, the young designer who says "just leave me along with my <fill in name of other design app>." THOSE are the people we are looking for. We are ramping up some design research and want to talk to architects, specifically young hot-shot designers who have not, or will not, learn to use Revit. If you have some names in mind, you can contact me directly at tom.vollaro at autodesk dot com.

"Conceptual" "Analysis"

A lot of terms get thrown around the Factory. Very broad terms with multiple definitions and meanings have a tendency to take on a single (or even new) meaning within the context of an industry or discipline. For example:

"Conceptual design." What is the first image that this phrase brings to mind? For me, recently, it has all been about form making and massing. While critically important to even the simplest of architectural project, defining massing (and conversely: space) is really only part of the story. When talking to customers and examining data in the past few months, programming keeps coming up as another critical, if less "sexy" part of conceptual design.

Second is "analysis." With the extreme buzz around sustainability, the term "analysis" tends to imply performance accreditation (ala LEED) and energy analysis. Once again, these are extremely important scenarios - but does it paint the entire picture? What are some of the other frequent analysis tasks for architects and engineers that have nothing to do with sustainability? (Obviously I know some, but I ask naively to get it in your words ;-)

Making Design Patterns Work in Practice

I just posted on our corporate design blog about  <shameless plug> Making Design Patterns Work in Practice. </shameless plug>  We don't normally like to re-post, but I thought it was relevant to demonstrate some of the thinking that goes into our design practices inside the Factory and how it dovetails somewhat with architectural design. This is also closely related to Erik's recent post on consistency. Please note, we realize that we have a ways to go before we follow our own interaction design patterns fully - but this illustrates the direction we are headed.

_tom

is Revit your Type?

In this post I want to raise a subject that might be popular.  Here are two facts:

We are visual people

I hear this a lot in interviews.  "I see it and want to manipulate it".  and "Don't make me reverse engineer the technical implementation"  or "I just want to grab X not work in a spreadsheet."  This is very logical.  Some changes are better made in dialogs or properties but a lot of the time, especially when designing you just want to interact with the model.

The Object Model is powerful

With a change of a type parameter you can make a few changes in quick fashion and know everything will propagate and be coordinated.  This is Revit. Happy Joy Joy.

Now onto the intersection of these two themes.

1. When teaching I, and other instructions, often preach to duplicate types when making a change to a type property.  It may be the layer structure of a wall or pattern spacing in curtain wall.  The reason is to avoid inadvertently redefining elements that are already instantiated in the model.  Its relatively simple to later swap out the type of a few instances in a view or all type instances using the selection tools (This was made better in the 3 subscription release)  Making a new type however is not the natural thing to do.  Most Revit users don't think "I want to change X so I better duplicate the type".  They feel they are acting on one object - not many.
2. Many type changes are difficult or impossible to preview.  This could be addressed in the type dialog but there may be context in the model that is important to the preview so its often more desirable to make the type change right in the model.

The above might explain why some ask for modeless properties for both type and instance while others want type changes to be treated uniquely to prevent accidental changes by new Revit users.

Can this workflow be improved to fit better with needs and mental models?

Potential Designs

1. Provide a lightweight mode where type changes can be made and previewed in the model on a local condition after which an explicit decision is made to forget the edits, save them as a new type or redefine the existing type.  The amount of elements that would be affected by each choice could be communicated by the system to help inform the choice.
2. Allow changes in context but save them to an <in-session> type that needs to be re-named and swapped out with an existing type to propagate a change.  Print settings work like this.
3. Allow direct edits but ask what should be done when another element is acted upon and the current element completed.   Editing a walkthrough path partially works like this and the dialog that prompts when deselecting the walkthrough can be a bit annoying.

Each of these has pros and cons.  This is just a thought experiment but I'm very interested in opinions, additional cases, or alternatives.  I see it come up again and again.

_erik

Consistency

Consistency is an interesting topic in design.  Its often spoke that improving it is a worthwhile pursuit in its own sake but in reality its much more subtle.  The cookie cutter suburbs that now comprise large swaths of the U.S. might have been justified on some levels but often fail their eventual inhabitants.  Lost was the pleasing diversity represented by vernacular building styles and common sense mixed zoning that create lively walkable communities.  Much of new urban planning is a re-discovery of proven ideas that were casually tossed aside in the later half of the last century.

A co-worker Chauncey Wilson wrote a good summary of this topic applied to interaction design on a sister blog titled "The Consistency Conundrum".  I recommend it.

In testing Revit and other products and also in my teaching I've seen many places where consistency improves learning by providing a scaffold via interaction patterns. A new feature can be understood by leveraging a known feature.  In some cases the interaction pattern may not even be that great but once learned tasks are completed without trouble.

In the 2009 release there was a quiet effort to make our open and save dialogs more consistent.  I placed some animated GIFs on a separate page (less annoying) showing the differences from 2008.  In some instances it was just a layout fix but in others extra dialog bits were moved to occur before or after the save dialogs to better fit the work-flow and not overload the person performing the task with too many decisions.

To close I want to solicit comments regarding:

• Areas where you feel Revit is consistent in a good way.  reinforce good behavior.
• Areas where is Revit inconsistent in a way that causes frustration.  (e.g. renaming is handled differently in types and views)

P.S. Please no stories of short inebriated mythical celtic creatures.  I'm sympathetic and heard them all by now. I promise that bugger is on a strict coffee regiment and a cab has been called.

_erik

Factory Lecture Series: Shape Grammars and Mass Customization

We continued our lecture series here at the factory last week with a visit from José Duarte, Associate Professor at the Technical University of Lisbon Faculty of Architecture. He is currently conducting research at MIT on applying design patterns and shape grammars to create computational systems for urban planning. The stated goal is to use rule-based computer-aided design and manufacturing processes to re-think the uniform housing and rigid plans. He presented work that he did 10 years ago with Alvaro Siza's Malagueira housing project outside of Lisbon.

In an attempt to recreate the variation inherent in organic urban plans and provide clients with a individualized result, Durate create what he calls a "discursive" shape grammar. This system encodes Siza's preferred proportions and design rationale into a language which can be applied in a seemingly endless number of ways (over 67 million possible combinations, actually.)  What was interesting about this system was it's seeming simplicity and practicality. It builds on the work presented to us last month from Kostas Terzidis - but applies a similar computational concept in a tangible way. The web-based prototype he built, albeit almost a decade ago, accepted input parameters, such as client preferences and local zoning rules, generated solutions based on the grammar and pumped out drawings, 3D models and cost lists for each variation. This talk predictably generated the same debate as with the last lecture: who is the author of the resulting design? The architect of the design language? The designer of the system that generates the alternatives? Or, the system itself?  This is not a new debate and predates the use of computers in architecture. However, based on the type of work we see being attempted by students and our customers alike, this is going to be the central debate concerning the use of computation and design in the coming years. It is an exciting time. Erik summed it up well: "I went to architecture school 15 years too early!"

_tom

Ending the quarter on an up-note

Much has been written about how Autodesk ate it's own dogfood (man, I hate that saying, but it works) with the use of BIM and IPD for our new AEC HQ here in Waltham. But I thought it was worth pointing out the recent article in  Metropolis, particularly the breakdown of upgrades that were made possible by savings realized by IPD (such as nicer finishes, custom lighting and exposed mechanicals - which are helpful when scratching our heads over certain MEP workflows!) Also, the BIM(x) blog just posted Tocci's take on the process, which includes a summary of LEED credits and the complete Platinum score card. See if you can spot a certain co-blogger in one of the photos...

And speaking of facilities, all of Autodesk is shutting down for the week of the Thanksgiving holiday here in the States. So, blogging may dip in our post-feast stupors. See you in December!  _tom

Photo: Jeff Goldberg/Esto

Factory Lecture Series: Algorithmic Architecture

Lira Nikolovska, a fellow Interaction Designer on BIM Platform Team, has been organizing a sort of informal lecture series here at the factory. Yesterday, we were pleased to host Kostas Terzidis, PhD, Associate Professor of Architecture at Harvard Graduate School of Design. Professor Terzidis has a background in computer science (he was one of the original developers of form-Z) and architecture. His focus is on how architecture can be generated and influenced by computation, which he distinguishes from computerization - using the computer to simply facilitate the study formal compositions. He is strongly critical of the decade-plus trend in computer-generated blobitecture (In the introduction to his book Expressive Form, he describes this trend using words like "arbitrary," "vague," and "caricature.") Terzidis instead proposes using rule-based algorithmic computation to generate and evaluate a multitude of options. The key to this approach is the use of rules - which can take the form of pragmatic building codes, geometric patterns, or formal design patterns - to present to the architect combinations they may not have arrived at themselves. These options are then culled and selected based on specific criteria. This generated debate amongst the architects in the room. What about the ideal of the architect as individual genius? Is this simply the computer replacing the architect? My personal take: it all depends on how far you want to take this concept. The key is in the selection criteria. Taken to a logical extreme, one could attempt to boil every single design decision in a building down to rules to be generated and analyzed solely by the machine. This idea is not entirely new. Nicholas Negroponte explored "architecture without architects" in the 1973 Soft Architecture Machines. I do not think this is plausible or preferable. Instead, I see these algorithms as simply another tool, the selection criteria is still dependent on the aesthetic sensibility of the architect. An algorithm may provide all n possible fenestration combinations for a facade - the architect still chooses.

How does this apply to Revit, or BIM in general? I am not sure yet. Revit's strength in the face of many generalized tools has been it's specificity. When you click Wall, you know what you will get. But when you break it down, its all geometry, parameters, and rules. So one could imagine using parameters to drive the creation of a multitude of design "branches" that can be deterministically pruned and combined as designs progress. It is surely a fascinating topic that really cuts to the core of most contemporary design disciplines.

(BTW, I just found the full text of Prof. Terzidis's latest two books on Scribd: Algorithmic Architecture and Algorithms for Visual Design.)

_tom

Inspection Methods - Heuristic Evaluation

In addition to the Claims Analysis posted earlier another popular method of inspecting a design is the Heuristic Evaluation.  The aim again is to uncover usability issues earlier in the design process.  This can prevent them from showing up later in a live usability test. These later tests can then delve deeper uncovering other issues that might have otherwise been hidden.  In the evaluation process a group reviews the design and judges it against a set of established criteria - the "heuristics".  The heuristics can vary depending on the specifics of the design but ten common ones are listed on the website of usability professional Jakob Nielsen.  

• Visibility of system status.  The system should always show state and provide adequate feedback.
• Match between system and the real world.  Speak the language of the customer's domain.
• User control and freedom.  Provide clear ways to get back or exit a feature when things go wrong.
• Consistency and standards. Follow platform conventions re-use appropriate workflows.
• Error prevention.  Try to design out conditions where the customer can easily get into trouble.
• Recognition rather than recall.  Do not overload the customer's memory. Make possible actions visible.
• Flexibility and efficiency of use.  Support both novice and expert users through alternative command access (accelerators)
• Aesthetic and minimalist design. Keep it simple. Remove any elements that serves no clear purpose.
• Help users recognize, diagnose, and recover from errors.  Use plain language and state the problem and potential solutions.
• Help and documentation.  Do not rely on help but ensure it is readily available, easy to search, and uses real tasks in examples.

Recent efforts have made progress on applying these principles during new design work. Tooltips and task dialogs were re-written to remove jargon and use natural language.  A consistent icon language was applied to commands and pointers.  Massing tools provide new in-view manipulation controls.

Future efforts involve applying these not just in new designs but revisiting existing features.

 

Figure 1. - Revit job security

_erik

Inspection Methods - Claims Analysis

In the next few posts I am going to review a few tools we employ in the design process to evaluate designs.  While focused inspections can't completely substitute for usability testing with live customers they can be used to predict many usability problems early in the development process when it is easier to make changes.

The three techniques I'll review in different posts are:

• Claims Analysis
• Heuristic Evaluation
• Cognitive Walkthrough

In a claims analysis several individuals, representing different points of view, identify positive and negative aspects of a design that may affect usability.  The participants can represent designers, subject matter experts, quality analysts, developers, and product management.
A "claim" is a hypothesis about the effect of a feature, or aspect of a feature, on the user and their goals.  Claims may be open or made against a set list of the functional requirements or design goals.

As an example there was a recent effort to develop a graphic standard for the in-canvas pointers (cursors)
Here were the guidelines developed for this effort:

• Avoid visual clutter. Too much detail can distract the users or make the image illegible.
• Re-use images for similar methods (do not use the same image for different functions)
• Use platform standards whenever possible. E.g. Ban symbol or hourglass.  Match Autodesk AEC standards where applicable.
• Keep sizes consistent
• Minimize obscuring of the canvas.
• The action portion (hotspot) of the pointer must be clear and predictable
• The pointer must be legible at all times (have sufficient contrast)
  • Colored backgrounds
  • Over model elements

In the claims analysis different designs were evaluated and the above list served as a basis for which claims could be made.  In one design an individual could make a positive claim that a pointer was more legible than another.  Another might make a negative claim that a design looked too much like pointer used for another function with a different purpose.

This  technique offers a simple framework for describing how a feature supports or frustrates customer activities and goals.  It also focus feedback in a structured way that can direct future design iteration.

This process could serve just about any discipline.  Has anyone used a similar technique during a design pin-up?  Next I'll discuss Heuristic Evaluation.

_erik

The Small Project Myth

In previous post I talked a bit about our process for small enhancements.  See (Fix, Fit, and Finish)

Often when looking over a list of projects one may think a solution should be trivial to implement.  In Revit this is rarely the case.  This may be because of the internal data structure or interactions with related features.  Even after working through several projects I find I continually need to adjust my expectations as to what is a "Small Project"   Here is a recent experience:

Enhancement:
Customers desire the ability to convert Detail lines to Model lines and vice versa.
To summarize "Model Lines" show in all views and "Detail Lines" are view specific.  Given this behavior when an inexperienced user places the wrong kind it is difficult to recover from.  This usually involves tracing and recreating the proper lines or some other work around.   Not fun.

Lines have a read only property "Detail Line (yes/No)".   If this command were made editable then the customer could change it and correct any issues.  Done!

Not so fast.

When converting a Model Line to a Detail Line we need to choose a view or assume the active view.  As it turn out properties have no notion of view (just the element they relate to) so we need to launch a specific "Convert" command that can run some code to find the active view.

What if the Model Lines are shown in a view that detail lines can't be drawn in?

OK- We disable the "Convert" command when the view does not support the creation of Detail Lines.

What if the model lines displayed in the view in a non parallel plane?

OK - Lines can be projected to the view plane.  Line would foreshorten and arcs would convert to ellipses to maintain visual fidelity.

What if they select Detail Lines and Model Lines?

Both line types belong to the category "Lines" so they can't be filtered!  Now we are stuck.  We could create new line categories or subcategories.  We could implement a better pre-selection filter that can distinguish properties.  Hmmm. We haven't discussed converting Detail Lines to Model Lines and the issues lurking there.
We can now see this small project is spawning sub projects and becoming...well "un-small".  It may have reached a dead end but there is usually another way to get to the cheese.  Sometimes after running down several of these paths you step back and ask "Is there a way to make the need for this enhancement to go away by  changing behavior elsewhere?"

Why share this?  I'm not looking for sympathy. Solving these issues can be very rewarding.  I more wanted to share this case study to be a little more transparent, dispel myths, and just tell a story of working in the factory.

If you have any experiences on wanting to convert lines please share.  This may spawn more ideas or requirements.  It would also be good to know if there are use cases aside from correcting a situation where the wrong line was drawn by accident.

_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

Scenarios & Tasks

Scenarios and tasks are tools we will use to test different designs via quantitative analysis or in live sessions with a prototype and real customers.

Scenarios:
The scenario  is essentially a story that provides additional context to a group of tasks that must be performed to achieved a goal.

Tasks:
These are more specific and describe actions a participant will need to perform using the system.  The tasks are required to achieve the goal of a scenario but may be common to many scenarios.  When defining tasks it is good to avoid words foreign to the domain and unique names of commands or features a test participant must find. This is done to avoid leading the participant down a path.

Here is an example of a scenario and tasks:

Scenario: Set up a cartoon Set

Sharon, the project manager, has just guided a project through schematic design development.  It is now time to get a handle on the documentation requirements and staffing assignments.  To begin this effort she identifies a standard set of plans and details as well as specific elements in the design requiring detailed documentation.  (enlarged plans, curtain wall sections, details ect..)  This will be the digital cartoon set that will become the starting point for the team.

Some related tasks:

• Create and name several series of sheets  A0, A2, A3, ect..
• Create a cover sheet with information on the project, team consultants and a list of drawings
• Establish a title block
• Create and name new views
• Compose the drawing sheets

This scenario and its tasks can be used to evaluate existing behavior to establish a benchmark. It can also evaluate potential enhancements to the existing functionality or completely new designs.

We are continually growing and enhancing our internal library.  If you are willing to share a particular scenario please do.
This may be a scenario you feel is:

• Unintuitive using existing features
• Encountered very frequently
• Infrequent yet critical to a job

I realize there is likely strong alignment with known requests and wish lists yet it is still valuable to understand the underlying goals stated explicitly in this form.

_erik

Fix Fit Finish

Step into the not so wayback machine, somewhere late in the 2007 development cycle (2006), a new process came into being in the Factory.  During the early years the fast pace of development was successful at rapidly expanding Revit's capabilities but there were some side effects.  Some features were reduced in scope at the end of the release to ensure quality and delivery.  This might leave out a less common use case or forgo a more comprehensive integration with other areas of the product.  Issues identified in Beta or post release would have to fight against new features for attention in the subsequent release.  Many lost this fight.  It bothered many.
    This was partially unavoidable.  New concepts were being introduced that were challenging to design and implement.  Resources were finite.  Allowing for more time or more detailed estimates would have slowed the pace and might not have fully mitigated the symptoms.  These are common issues in industry, not just start up companies.  In the building industry it gets the name "value engineering" yet that may reflect the point of view of the owner more than the architect.

A new process was needed to address these items and ensure they stopped accumulating.  This was first called "Small Enhancements" and more recently F^3 (Fix, Fit & Finish).

The process allows any factory worker to nominate a project.  Sources include customer support, blogs, forums and general customer contact.  From this uber list the project managers create smaller prioritized lists.  Employees can address an issue from these smaller lists opportunistically in ad hock teams.  The main restriction is a threshold of time for design and implementation.

The process is designed to be flexible and infill around the larger projects.

Here are some past examples:

• Counts in the Filter dialog
• Gaps in Grids
• Close Loop Snap
• Custom Scales
• Dimension to Intersections
• Currency Symbols
• Digit Formatting
• Recent file Start Page
• More granular view template application
• Spot Slope

Some from R2010:

• Default Workset open setting
• Save before and after Sync to Central
• Open as local
• Halftone/Underlay Settings
• Elevations, Sections and Callouts in view Filters

There are many others but I wanted to convey the range and diversity.  In some future posts I am considering using this blog to discuss research around potential projects.  This could confirm requirements or comment on potential designs.

How does this sound?  The only qualifications:

• Anything discussed is not a guarantee it will appear in the next release
• Anything discussed does not mean it is the sole focus of the Factory

I thinks that it.  Stay tuned and feel free to comment on any of the above projects.  Good/bad?  More please.  New suggestions.  Fire away.

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

Rotate: Before or After?

This is a short post to test using this blog as a method of soliciting specific customer feedback as the need arises.  Often during design an issue will arise without a clear solution.  There may be many paths forward but the best one remain elusive.  A survey or interview can be used to gain additional insight yet these have a high overhead and can’t be justified in all situations.  A simple question on a blog might be sufficient and is certainly better than proceeding without any customer feedback.  So here is the first such post:

Revit has a single point placement option called “Rotate after Placement”  This appears in a few places such as the "Component" tool and "Column".

The option allows you to specify, pre-placement, that you want to rotate the item.  Right after the placement click the "Rotate" command is activated and the next click defines the amount of rotation. Next you proceed to place another instance.  It is a bit unconventional but has been in the product for some time and was likely introduced to solve a specific need.  If I had to reverse engineer a use case it might be:

“I need to place several instances - each having a unique rotation.  I do not want to place and rotate each instance separately”

I can see  [find] several [pre existing] alternatives to this option including:

1.    After placement the ribbon will display a “Rotate” command that allows you to rotate the element and then quickly resume placing other instances.  Its discoverable and flows well.

2.    During placement you can press the spacebar to rotate the element into alignment with other elements the mouse is hovering over.  Fun to use as it flows well but not very discoverable.

 

3.    You can place a single item then click the “Rotate” command.  This is more clicks but if you have many to place you could just copy the instance you rotated.

So the question is does this placement option still have value?  Do you use it?  When?  The more details you can provide the better.  Thanks!

_erik

Revit Pointers or 'Crayon Requiem'

With the effort to update the look, feel and language of all the icons it soon became evident that dozens of Revit pointers and in-canvas bitmap controls would need to be updated to be consistent.  Before this effort was undertaken design guidelines were established to provide a framework for evaluating the current state and alternative designs.

Design Guidelines

1. Avoid visual clutter. Too much detail can distract the users or make the image illegible.
2. Re-use images for similar methods (do not use the same image for different functions)
3. Use platform standards whenever possible. E.g. Ban symbol or hourglass.  Match Autodesk AEC standards where applicable.
4. Keep sizes consistent
5. Minimize obscuring of the canvas.
6. The action portion (hotspot) of the pointer must be clear and predictable
7. The pointer must be legible at all times (have sufficient contrast)
   1. Colored backgrounds
   2. Over model elements
8. The main body and badges must properly convey their purpose or action

Evaluating against these guidelines led to focused reviews and some re-design.

First, all the pointers were given a subtle halo.  This addressed an issue in R2009 for the few who ran with an inverted background and found the pointer almost invisible.  In addition the new gradient background in 2010 created a further need for this.  A white halo with alpha transparency was added and each pointer was viewed over a range of backgrounds to ensure it was legible.  This should also improve pointer visibility over dense model geometry.

Many of the pointers with badges were re-organized to ensure the badge was placed in a consistent location.  R2009 used several different configurations and this was also true for hot spot locations.

Lastly the crayon is no more.  Internally this created some mixed feelings.  The crayon has been with us from the beginning and perhaps falls into the category of behaviors that make up Revit's unique break from legacy CAD.  An analysis of competitive drawing and modeling applications showed almost all used a cross hair. Was there a reason? Some applications did use a crayon but they were paint applications.  Here the input is defined to be imprecise and gestural. In the end we had clear guidelines and precedent to fall back on.  We made the change to a cross hair in time to have it place for many rounds of testing.  It never received a comment nor created any observable issue.  Again this is sometimes the best result in evaluation tests.  Had there been comments it would suggest the pointer was getting undo attention. A good pointer in a BIM application should provide a subtle yet clear means for precision input using a minimal representation. 

In 2010 the Arrow pointer still remains for selection and the draw editors still display badges for the non-linear sketch methods.  There was consideration to remove these badges and standardize on a selection cross hair like the one used for Modify>Cut.   Could we have simplified further?  Are there other pointers that need attention?

_erik

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

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

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

Software Designers

So you may be asking: what does design have to do with creating a piece of software? When I tell customers that our team designs the Revit user experience, the most common response is "so you are a software engineer, right?" This is a common misconception about software; that it is created solely by software engineers. While this has been largely true for the past few decades, the way software is designed is changing in a big way. In many forward thinking companies like Autodesk, the concept of a holistic user experience - the way the user perceives and uses the product, including everything from the first experience with download site to the user interface to the accompanying documentation - is designed by user experience specialists. Additionally, usability practitioners evaluate the learnability, effectiveness, and efficiency of our product designs with users.

To sharpen the point, I often provide the following analogy to our customers, particularly architects: Think of Revit as a building. You sit in front of the computer and "inhabit" the application for hours at a stretch. To that end, it is critical that this experience be designed to ensure that you can accomplish your tasks in an efficient, accurate, and enjoyable manner. Similarly, when you ensure that your buildings truly fit your clients' needs and delights the inhabitants, you strive to achieve good design. We strive for the same exact thing. Unfortunately, I cannot take credit for this apt analogy. Almost twenty years ago, Mitchell Kapor made a similar comparison in A Software Design Manifesto, his appeal for the establishment of a professional discipline of software design:

The Roman architecture critic Vitruvius advanced the notion that well-designed buildings were those which exhibited firmness, commodity, and delight. The same might be said of good software. Firmness: A program should not have any bugs that inhibit its function. Commodity: A program should be suitable for the purposes for which it was intended. Delight: The experience of using the program should be pleasurable one. Here we have the beginnings of a theory of design for software.

So remember, as you work tirelessly to bring delight to your clients through your designs, we endeavor towards the same goal!