Revit Terminology

In our early research to document tasks and processes that occur during a building project there was consistent feedback that Revit would occasionally use a novel name in lieu of an established one. In the process of re-mapping hundreds of commands we took the time to step back to ensure command names we used were appropriate. Some of the criteria were:

• Does it fit the building domain rather than the domain of software?
• Are we using a less common term over a common one?
• Does the command accurately reflect what the tool does?

We knew this would force relearning so we took care to focus on those that could clearly be better. Below are some specific cases for illustration:

Internal Consistency
In 2009 when selecting an extruded roof form a tool was displayed in the option bar called “Cut Plan Profile”. This command name was explicit yet...a little clinical perhaps? It also had behavior that was a dead ringer another command named “Vertical Opening”. This replication creates an additional cognitive load recalling two names for a single action. In 2010 the command “Cut Plan Profile” was standardized to “Vertical Opening”.

Reflect the underlying Behavior
Those on large projects will see “Save to Central” was renamed.  An early iteration used a term “Publish” which is often used for this behavior but didn’t capture anything new or seem a significantly better choice. After further iterations and internal debate this was later replaced with “Synchronize with Central”. This name more accurately reflects what occurs during the save process. On initiation data is first transferred into the local file from the Central file and then from the local to the Central. The two files are brought in “sync” with each other.

Use commonly known terms
Did you notice the rename of “Resize” to “Scale”?  Going way back “Resize” was originally chosen as the command didn’t really scale all aspects of an object. In the case of a wall it would scale the length but not the height or width. Despite this truth the common name for this operation in most other modeling programs is “Scale”. Disqualifying this name because it could not be applied literally on all aspects of an object seemed a technicality.  Customers could predict how “scale” would work on richer objects and not using a term they knew almost seemed almost condescending and certainly caused them to pause. To help new users leverage their existing knowledge and improve consistency with other products, including those by Autodesk, the name was changed. The default “RE” keyboard shortcut was maintained to avoid an inconvenience to existing users.

Remove Jargon

When laying out the top level modeling tools we came across the term “Host Sweep”.  In 2009 this top level menu contained the tools “Wall Sweep”, “Wall Reveal”, “Fascia”, “Gutter”, and “Slab Edge”. While experienced Revit users were used to the term it was clearly not one you would find in an architectural textbook. We first tried to brainstorm alternative names but given the ability of the tool to place many specific sweep-like elements a single name could not be found.  After some iteration the key was in the word “Host” – a generic, and again clinical, term for top level objects in the software (Wall, Floor, Roof etc.) Since each command had a “host” we could distribute these commands under these. “Wall Sweep” was placed under “Wall”, “Fascia” and “Gutter” under “Roof” etc. We tested this organization by assigning specific tasks to customers with a range of Revit experience. Care was taken to avoid using the exact command names in the task goal by providing an image that the customer had to recreate. These tests showed the new organization worked extremely well. A few experienced users paused to look for the original location but then reasoned it out and found the tools in the new location completing the task successfully. After the test we often asked, “When you paused what tool were you looking for?” Most could recall the tools used to be grouped together but could not remember the full menu name “Host Sweep."

Are there additional instances of terms that you think fail the previously mentioned criteria? Can you find more examples of jargon?

_erik

Comments

[Joel Osburn]

We have long struggled with Revit's terminology, so I'm glad that Autodesk has taken this on. Since you asked (and unfortunately too late to matter for at least a year...):

Even experienced users struggle when presented with the choices given when closing an unsaved, workshared model:
* Save to Central...
* Relinquish & Save
* Don't Relinquish
* Cancel

Relinquish doesn't mesh with Check Out; those terms may work well with source code version control, but to architects and engineers, check-out invokes a library metaphor. Thus Return Borrowed would be more intuitive.

Further, sometimes someone may want to save, but not relinquish/return elements checked out/borrowed. Their brow furrows, and they can't figure out what to do. Will clicking Don't Relinquish still save the file? The other options use the word the Save, but not this one.

Tagging versus Keynoting seems to stump even Autodesk...the documentation regarding when to use each is clear as mud. Eventually one can grok that tagging seems meant for graphical symbology to tie to legends or schedules, and keynotes are merely repeating notes that sometimes have a symbolic placeholder. Or so it seems. No matter how you slice it, though, it's confusing that tagging a material pulls one parameter, and keynoting it pulls another. Not intuitive.

Trim/Extend works like fillet by default. This is only a minor confusion, but especially disappointing when users realize how crippled the trim/extend portion of that command is compared to Autocad.

Component captures way too many element types, including elemnts placed by other commands (columns, for example).

Architectural versus structural columns. They're ALL structural; there should just be a generic column type, similar to generic wall types. This applies to beams as well.

Linework overrides: invisible lines. Users make use of this when they want to hide a *part* of an element in a given view. Since their reasoning is about hiding something, they expect it to be made visible when they do a Reveal Hidden Elements. I realize that this is subtle, and not easily addressed, but it comes up.

That's it off the top of my head.

[Tom Vollaro]

Joel,

That is quite a list. Work sharing is a great example. In the past I know there was a correction where that same dialog contained a kind of double negative. I think it was 'keep editable' vs. 'don't relinquish'. 'Return borrowed' is good term especially if the library metaphor is used consistently. Some of the others are good examples of easing transition from other products. Fillet is handled in a very odd way as part of the sketch tools. Its the inversion of a bad term - the name is OK but the functionality does not meet expectations.
Thanks!

[David Fannon]

Renaming Resize? Ridiculous!
Resize is an accurate term (you acknowledge it is technically "truth") and switching to "scale" inaccurately describes the process (as you note with the example of walls). To me that is reason enough not to rename this command. I fail to see how choosing a name that is common in other applications (and which may accurately describe what they do) is advantageous in this one; I am not working in other applications, I'm working in Revit.

AutoCAD (to site one example) does have a tool called "scale," and it really does scale. But we know that Revit and AutoCAD are different, so why would they have the same interface? In fact, that would be MORE confusing to new users, who could (logically) expect a command with the same name to do the same thing. A command with a different name, however, is a "teachable moment" about the differences between applications.

You suggest that "resize" might be condescending, but in fact, the converse is true: it is "scale" that is condescending. I would much rather be given the benefit of the doubt that I am smart enough to understand the subtleties of a correct, precise description (resize) than be patronized with a similar term just because it is familiar (scale).

Lastly, a philosophical difference, you note that the term resize "certainly caused [users] to pause." as if this were a problem. However, I see that as a great strength: new users SHOULD pause, and consider "why is this different from what I am used to?" If we establish that Revit (and BIM generally) is a different way of working (as you do by acknowledging that the resize tool is NOT equivalent to scale); then why would we ever want people to approach using Revit the same way they approach other tools?

It concerns me that streamlining the interface with the software (make it similar to other software) is being mistaken for streamlining the BIM process; and may, in fact, be detrimental to it.

[Tom Vollaro]

Opinions vary. You accidentally quoted me as stating users paused on this specific change (that was host sweep). In fact no one ever paused on the change - even experienced users. More confusion was not created. I agree with your point about a teachable moment - unique BIM concepts should be different yet there was no confusion around the subtlety of how 'scale' works in a BIM app while people rarely found 'resize' when looking for 'scale' especially with a 2D element such as a raster image. Revit still has many 2D elements.
Thanks for the alternate view though. It is a good point that Revit is BIM and can have unique terms because of this.

[Mark Schmieding]

Having worked with and Revit for over a decade, I am familiar with BOTH sides of the previously mentioned issue of terminology. But I must say, whenever I had to teach Revit to someone new, I ALWAYS had to say " 'Resize' is like 'Scale' " - and that was enough to get the point across... Even though I knew why it was 'Resize', having been 'inside the factory' at one time, no one else REALLY seemed to care except me, so I stopped explaining it :)

The terminology thing that I always had to clarify was the difference between 'Model-based' and 'Drafting-based' elements. This was because Model Lines were just called 'Lines' and Drafting Lines were called 'Detail Lines' - but because architects use drafted lines for much more than just details, I'm used to telling people - think whether or not an object is a Model-thing or a Drafting-thing, because Revit has several different terms for 'drafting' (e.g. Detail, Symbolic, Drafting View...)

And I second the confusion that Joel mentioned over the "closing an unsaved, workshared model" - I hope that is cleared up in this release - that would be another relief!

[Chad]

I take issue with the rename of the Resize tool to Scale as well.

Scale suggests that you are proportionally changing the shape from one size to another. When in fact there are instances where you can run this tool and end up with a result that doesn't represent a proportionally larger or smaller version of the original.
In these situations you are resizing in a particular axis, rather than overall scaling. Resize is a much more appropriate name in this instance.

Changing to suit other non-related applications isn't always the best move.

[David Baldacchino]

I guess the point is that "lengthen" or "shorten" is not the same as "grow/stretch" or "shrink". "Scale" implies locked proportions. So "Resize" could mean scaling, stretching, shrinking, etc. I'd say the use of the word Scale is probably not the most appropriate in most applications, as in many cases one can change the aspect ratio of the scaling. We're dealing with a legacy issue though here. Scale has been engrained and thus, we seem to be forced to fall for it, even if it's semantically not the most appropriate description.

Back to a comment made in the post about "Vertical Opening". Am I the only one that thinks the name is actually totally misleading? A vertical opening is an opening that is vertical. A window and a door are inserted in a vertical opening, meaning an opening on a vertical plane. A Shaft is a vertically extruded void so to speak. So really, a shaft opening is a NON-Vertical opening. The extents are not sketched on the vertical, but the horizontal.

[David Fannon]

Erik, thanks for the reply. To be clear, I was quoting you as saying users paused at resize before change (or "BC" if you will):

"Customers could predict how “scale” would work on richer objects and not using a term they knew almost seemed almost condescending and certainly caused them to pause."

This was mostly so I could point out that I'm glad they paused, not all pauses are evil. I agree with Mark that I often reference "scale" when describing "resize" (learning technique=association) but always in the context of explaining how it is different.

David, I like your point about "legacy issue" although I arrive at a different conclusion: scale may be legacy in other applications, but it Revit it is Resize that has a long and glorious history.

[Tim Waldock]

I agree that "Resize" is a better term than Scale, but I laughed out loud when I saw the tooltip which says "Scale . . . . Resizes the selected item". I guess that we'll get used to explaining to users that Scale does not always scale elements.

Great that you changed the "Relinquish " dialog box - so much better, especially if you don't save then get a second dialog asking if you want to relinquish. Only comment is that it does not explain what happens if you don't relinquish (ie keep ownership), having already closed the file without changing.

One more great thing you've done is fix the terminology of "Import/Link" for CAD files - in fact you have gone one better and separated the two commands so there is no chance that users will forget to tick/check that vital "Link" box. you have no idea how much grief that will save me.

[Tim Waldock]

Erik,
Alarm bells are ringing about the "Synchronise" command. I am happy with the new terminology, but I'll miss the shouts across the office to "Save to central". Will we have to put on robot voices when we shout "Synchronise"?

But seriously, You say thet "On initiation data is first transferred into the local file from the Central file and then from the local to the Central." I'll swear that it used to be the other way around - ie. Save to central then reload latest. The order is crucial whenever someone edits any settings, because they can be overwritten if users reload/save in the wrong order. Ideally that problem should be fixed, but in the meantime can you clarify ASAP, Erik. If you really have changed the order, I will start a thread on the forum because it is seriously important to discuss it out there.

[Tim Waldock]

Tom & Erik,
This is a great blog page as it lets us all focus on specific topics. I'd really like to hear the rationale behind the redesign of some of the icons one day soon - like I just noticed the new Paint/soccer ball icon. Why?

[Tom Vollaro]

Tim,

Lots of questions I will try to answer. First the Synchronize (formerly known as STC) is not changed in any major way as per order. Sorry if I recalled it incorrectly. There were some enhancements though:
-An option to save local before and after Sync
-Open a central as a local avoiding a Saveas.
-Ability to set the default open workset behavior by project in the save options. (Working on a large file and you want to encourage users to 'Specify' worksets on open this can be made the default in lieu of 'last used')

Yes, Import and link got some attention. It was a rather simple change but I am glad it is well received. In our studies we ran across a lot of these seemingly minor issues but they do add up so we tried to address them.

The Soccer ball..must be the materials icon. This is an icon shared with all the ADSK apps. We never had an icon for this and hundreds of others but some that are common are shared and we took them when we didn't have an existing alternative. Others we designed in-house to the guidelines. My Favorite set are the Modify>Openings. These didn't have any before and the new ones are really quite informative. There have been comments on the lower contrast in the icons. I'll try to share some of the guidelines the company visual design team used in the near future.

Thanks for all this feedback. It really helps reinforce certain efforts to fix legacy issues.

[Tim Waldock]

Erik,
Thanks for the prompt reply. I'm relieved that nothing changed with the order of STC/Synchronise. However there is a long-standing problem with saving the settings to central that needs to be addressed.
I really like the "Create a new local" option - big time-saver, and avoid people accidentally working on central. I think that "Save before and after synchronise" is a good thing too.

As regards the Paint icon, I won't wait for your icons blog, because i now see that it is a terminology issue. You have used the material icon, but actually paint is just applying a surface finish, it is NOT changing the underlying material. This is something that always confuses users, so I discourage people from using paint. I think the change of icon makes it more confusing.

[Tom Vollaro]

Tim,

I agree there is something here that needs to be sorted. While paint is applying a surface finish it IS doing it via application of a material and this will affect material takeoffs. Graphic overrides are better for changing an appearance but are not as easy to sue as Paint. I appreciate your feedback here as we are continually interested in feedback relating to graphic appearance vs. materials and their relationships.

[Aaron Rumple]

Resize? Scale? Sync? Save to Central? It is all just lots of mental masturbation. Write some code that does somthing. Maybe site tools? Or a real text editor?

[Tom Vollaro]

I'd call it considered but opinions differ. As noted in the FAQ designers don't write the code nor make decisions about features to include. I can make suggestions and try to influence others and so will pass on your sentiments.

[Wes Macaulay]

I just like the image of Erik and the other designers rubbing their heads having clarified all these tool names =-P

I agree with the changes in terminology and I'll see what my students tell me in the fall when I start teaching 2010...

[Aaron Rumple]

"As noted in the FAQ designers don't write the code nor make decisions about features to include."

Which is THE major flaw at Autodesk - design by committee filled with marketing and lawyer types. The designer should make decisions about what the program does. I'm friends with talented ex-adsk employees which left the company because of this "process". And they could write code.

The only thing keeping adsk going is that they have a monopoly in the AEC industry. (I do blame architects for that in part.)

Full disclosure- I am a stock holder and not at all pleased with the companies direction in the last few years. Revit is a mess right now.

[Aaron Rumple]

A discussion about terminology that matters.....

http://forums.augi.com/showthread.php?p=965803#post965803

[Balazs Trojak]

I find the Object Styles / Overrides and Materials dialog boxes confuse "patterns" with "surfaces". A pattern is simply a partial definition of surface or a line. Herein lies the problem as there is a fundametal difference between the two and are thus defined in to separate places (Materials for surfaces and Object Styles for derived lines). My original post offers some alternatives and raises some other interesting terminology issues: http://forums.augi.com/showthread.php?t=88959

To take it further I think the surface definition should contain a third setting for base colour(1) upon which the pattern(2) is drawn in a specific pattern colour(3).