Related Posts with Thumbnails

« Ribbon tab and panel logic | Main | Draw/Pick Gallery »

March 25, 2009


Feed You can follow this conversation by subscribing to the comment feed for this post.

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.


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.

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.

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.

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!

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.

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.

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.

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.

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.

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?


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.

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.


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.

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?

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.

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

"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.

A discussion about terminology that matters.....

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:

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

The comments to this entry are closed.


  • Subscribe