The option bar has duplicated some that are also in the properties dialog but typically only the most common. In user tests these option bar fields are often skipped over in favor of the full properties dialog. I've observed engineers do this the most. They favor the property dialog 99% of the time (like moths to a flame.) One way to interpret this is the option bar lacked visual distinction in the UI. Another is the full dialog is the lowest common denominator for properties. You know the property is there even if it might be somewhere else.
Another method for better access is more direct access in the canvas yet this is also unlikely to cover all properties - at least in the short term.
This leads us to the popular request to make the property dialog modeless.
The ability to take the dialog (specifically a more compact version of it) and keep it available could reduce the number of clicks by eliminating all the call and dismiss clicks - perhaps hundreds per session.
I still have a vivid memory of a discussion with a customer who was lamenting the property dialog. He said something like "I feel like I'm always moving in and out of a data grid. I'm living there all the time". He slowly transitioned his gaze down to the carpet as he said it - the tone very resigned. I was moved.
Modeless property access is available in AutoCAD and its verticals via the palettes. Other programs also have floating properties that update dependent on the context (Microstation, Photoshop ect..)
Below I want to explore some Revit specific implications and possible designs with you. Lets start with the most simple design:
Changes made in a modeless property dialog cause an instant update to selected elements in the canvas. This is common with many other apps and provides instant feedback.
In Revit there are some issues lurking:
• Many changes cause the model to regenerate which would impose a variable delay after each change. Some changes might be several seconds.
• Some edits can create an invalid situation (e.g. wall base constraint above a wall top constraint). If everything updates instantly you would have to make the changes in a specific order.
Lets explore these issues in alternative designs:
User /Focus update
Instead of updating on each change the system will hold all application of the changes until you mouse out of the dialog or press an "Apply" button. At this point all changes would be committed together.
You are free to edit parameters in any order even if they are temporarily invalid.
• There would be no feedback in canvas until you leave the dialog or press "Apply".
• There is a chance that if you created an invalid condition it will be more tricky to correlate the specific change that caused the error.
For the last item it may be possible to display warnings/errors in the properties dialog for better feedback but this could still add some delays.
Instant Update - Keep UI available
In this design the changes would be applied on each field change but would not prevent changing other fields. Each time you change a field it restarts the calculation unless it managed to finish while you were thinking about it. In this design the system time may be greater than either of the two previous solutions but since it favors keeping the UI available it should not interrupt the workflow - unless you decided to wait for it to complete. You could make valid changes freely and observe the system update in between when possible or after you finish for more changes that cause greater change in the model.
This would require some new threading and other expense but is worth evaluating with the previous ideas.
Potential supplemental requirements
• Support quick access to the properties dialog for those that may not want to dock it continually. Separate buttons for instance and Type.
• Take care that type changes cannot be made too casually / ensure these are distinguished in the UI
• Remember state between sessions
• Potentially integrate type selector (could replace ribbon access)
• When nothing is selected display active view properties
As we can see simply making something modeless has implications that need to be thought through to truly realize an improvement. I welcome your evaluations of these issues, new requirements, and anything else related to property access. if necessary I'll post a followup.