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