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

Comments

[Adam Sheather]

Erik

I like the first option best, but on the condition that it is optional in other words you can still use existing methodology to make changes or open this dialog system to test and make lightweight changes before accepting them.
The issue with it being constant is it would get frustrating having more clicks on easy and very understood changes that do not require the testing framework.
2.Sounds like alot of extra legwork to get things done to me, while it would be alright once going I fear it would add another level of management to be looked after without really having accompanying benefits to the user and speed.
3. Again 3 sounds like alot of extra clicks to me. While having modeless properties is a great thing, I don't want Revit asking me questions and having way too much info pop up on the screen, especially if it is selection sensitive as many times I want to review or manipulate and not edit and therefore all this other info popping up and adding clicks seems to take away the option for the existing workflow.

[Anthony Hauck]

Makes sense.

[Robert Mejia]

Depends on the complexity of the object. One can be creating a new type for something simple like an annotation (text and leader) or a complex window with a couple of parameters to change it. For simple things like annotations I would like to see more instance options in Revit. I'd like to be able to have 1 text type with instance dot, arrow, tick, etc. leader options, rather than having to create a new type for each, which might feel slightly "unnatural".

For component families I am constantly testing out the parameters every time a new constraint is added. Modeless properties would greatly simplify this if I could leave the properties window open while working simultaneously with the family to quickly test the parameters without having to halt the work, open the properties dialog, test the parameter, close the properties window, add a new constraint, repeat parameter test, etc.

Of the 3 potential design options, I like #1

[Anthony Hauck]

Thanks for those examples.  Another idea is to push instance changes into a type or create a type from an instance.  Some of these choices exist with view templates or the commands that allow one to propagate datum extents.  Im not sure how obvious those commands are to most people though.

[Theo Dore]

Erik,

I like what you said in your last post. Being able to edit interactively on instance parameters and later on being able to save them out as a type sounds like a nice workflow. In a way that could become an in-place type that the BIM manager could later on pick up and convert into a proper type in the library.

Thanks

[DoTheBIM]

We don't really have issues with inadvertant type changes other than pasting from one project to another where it produces a duplicate types by renaming automatically (wish it would prompt what the user wants to do). We simply don't allow (translated: VERY strongly suggested) users to not duplicate type unless prior approval is acquired... because this messes with our BOM software as everything is based on the naming of family and type.

I don't see any difference between option 2 and a user having to think... "I want to change X so I better duplicate the type"... since you still have to go back and change types to "real" types... so I'd say there's not really any gain there... and nix that option all together.

Option 3 would seem that it could get tedious with prompts, but could be resolved with a checkbox (or [yes to all], [no to all] buttons) to apply the same answer to subsequent similar prompts.

option 1 seems to be the most logical intuitive approach adding in not only number of elements affected but possibly types (or a list of family:types), but something seems like it could be don't much better in this area, but I can't quite put my finger on it right now. Could you present an example of a scenario and how it would play out in this option? Might help jog my mind (and others).

Bottom line from my experience is that the inadvertant type changes is a direct result of a user being new to the system/concept of Revit. Once the majority of the learning curve of the system tools is out of the way... the user seems to grasp readily the affect between instance and type changes. After that if there's still a problem it's not likely that the problem goes away. I have one user that still after 3 years does not fully understand the Revit way of workflow, but simply is remembering a series of steps that he must perform to get to an end result. I don't see this ever changing as he had the same mindset with 2D/3D work in Microstation.

[Dave B]

Since the "Duplicate" workflow is really at the source of user confusion for the most part, what about this?

a) An "Edit Type" button with an option to rename the type and no further prompts are issued; You cannot duplicate from here.

b) A "New Type" button which immediately prompts for a new name and copies over the parameter values from the currently selected type. To dismiss the dialog, you're prompted to choose from the following:

1) Save Type. No instances are changed;
2) Save and change type of current instance only;
3) Save and change type of all instances using the currently selected type.

[Robert Manna]

If this ends up being a double post I apologize!

When we teach internally we really stress what it means to be dealing with Types and Instances. This concept is at the core of Revit and we feel that to effectively "shield" people from this idea by suggesting something like "you should always duplicate types then select and changes instances" effectively circumvents the logic and point of Revit in the first place. With many users working together on models/projects we need them to fundamentally understand how Revit functions. Thus, they truly need to understand what it means to edit a Type, why it is important, and when, where and why you would want to make new types versus editing an existing type and the potential ramifications to the model by doing so. Therefore, I believe #1 is the best option for a variety of reasons; it helps to emphasize how Revit actually works, the ramifications of the decisions making process, makes it easier for users to avoid inadvertent mistakes that would otherwise compromise the model, it makes it much easier to understand what changes are propagated (particularly dimensionally) and does not add a great deal to the click count. One thing that "preview" does not resolve is when making "data" changes. Data changes are far harder to spot then in-correct geometry, and can have huge ramifications on the documents of a project. However, a blatant message (similar to when editing in schedule) with element count would hopefully. Error messages in plain English that are slightly more comprehensible would help too.

[Tim Waldock]

We have drummed in the process of duplicating types, and surprisingly we don't get many stuffed models due to this (unlike many other potentially disastrous workflows where it all goes wrong quite often). But it would be good to have better control, albeit without making it too complicated.
I think I prefer option 1 of Erik's 3 choices. It would be important to give users the maximum amount of info about which elements would be affected (not just the number) - I'd like an expand button that might tell me if any of the elements to be changed were in a group (if so, group names) or a design option; what levels (for model elements) or views (annotation); hosts (for things like profiles that are used to define other families); also if those hosts have actually been used in the model etc. Would a list of IDs be going too far?

This concept of giving such information needs to be extended to other areas of Revit, like "Select all instances", "Delete type" (from family list in project browser).

[Joel Osburn]

I'll echo Robert Manna's sentiments. IMHO, either you've learned it, or you haven't. If you haven't, you need to. Everyone else should have direct access to manipulate parameters, thus option number one is preferable to me.

Option two is unpalatable at first blush, but I could see a certain usefulness of having some versioning capability for families and types. Imagine if the last five versions were kept...you could easily back out changes with some simple renaming. To avoid the resulting proliferation of types in the project browser and type selector, they would be hidden by default, turned on only when needed. So this could be effectively combined with either option one or three. Ultimately probably not worth the model bloat, but interesting to think about, anyway...

Option three just adds to Revit's clicky-ness, which is the last thing Revit needs more of.

Giving visual cues to a user to help reinforce that type parameters are being changed rather than instance parameters would help, though. If a portion of the type parameters box listed how many instances of that type are currently in the model, then the user could easily see that they are affecting more than just one thing.

A preview changes button could be useful, but let me bypass that for all those cases where it's unnecessary.

I also like Dave B's suggestion for adding clarity to the Duplicate process; it is a little oblique as it currently stands.