Modeless

 
For a long time there has been a call to make properties more accessible.

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:

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

_erik

Comments

[Danny]

I think I may be fond of the User/Focus methodology. I don't want Revit to have to "think" and "redraw" the views I have open at the time, for every single change.

For me, just having the Properties (and View Properties and Visibility Graphics) in modeless boxes will be a huge help. I hate opening and closing, opening and closing, opening and closing...its so tedious.

I can live with changing a few settings and then hitting Apply. Oh yeah, keep that Apply button at the bottom of the modeless dialog all the time too; just gray it out when I haven't changed any settings.

[Joel Osburn]

I would love such a modeless dialog box, preferably in an instant update incarnation.

By far the biggest advantage to such a UI element is the way it can better connect the user with their data. The fluidity in selecting an object, directly changing a parameter, and immediately getting feedback is a huge benefit to workflow, productivity, and ultimately creativity. If an error is thrown, then they know right away; delays would be especially harmful here. Since Autocad introduced such a beast, I have never seen a user not have that palette accessible.

Were Revit to divorce changes in an always active UI element from the realization of those changes (by requiring an Apply button to be pressed), this then adds a click back in, and in turn, a wall between action and result. The barriers placed between the user's actions and the expected results are impediments to user productivity.

Rather than let a performance liability drive the UI, the performance itself could be improved. Could view regeneration not be multi-threaded? One thread per view? Is there any room for improving when a full regen is needed, versus localized updates? And one concession might be to only fully update the currently active window, until come other event (my aforementioned, dreaded Apply button? Clicking out of the properties box?).

As you can see, I strongly favor the instant update path; if Autodesk wants UI continuity among apps, propagating the properties palette would be a well-received step.

Also, I think it is useful to distinguish between Element Properties, which is what I am mostly referring to, and Type Properties. My preference would be to have TP be it's own palette, and to optionally always be visible itself. Given it's wider implications in changes to the model as a whole, I think user's could accept a slower, and/or more deliberate method of propagating changes. Likewise, View Properties should have the option of being always visible, as well as Visibility/Graphics.

I know that seems like the user could then bury themselves in floating palettes, and some might. But for those times when you need constant action to one of these properties boxes, being able to have it would be incredibly useful.

A last thing to keep in mind (and I apologize for always being so verbose, but it's only because I care), is that a fair amount of the time a user spends looking at moving between the fields in the properties dialog box (element or type, view or vg), is just that: looking. If they are trying to make multiple changes, there ought to usually be ample opportunity for background updates to view(s) to occur.

[Anthony Hauck]

No worries on verbosity. Its interesting the first two comments favor different approaches. In concept I agree that performance should not be an issue but making everything an acceptable speed like <=200ms is a tall order. The property changes can affect many different functional areas all which would need to be threaded. Its a good direction but could take many cycles. The third approach may be more feasible. It seems if you are focused in the dialog it may be acceptable if changes in the canvas follow behind as the system can process the data.

[Joel Osburn]

Erik, my big concern about changes following behind is that if the user makes a change, and expects to see it manifested and doesn't, they then change it again or try something else immediately. This makes it more difficult to discern which change created which effect.

Thus my favoring the immediate cause-and-effect type of behavior. I'll note that the previous poster said, "I can live with changing a few settings and then hitting Apply", which is different from favoring. My reading is that performance was the driver for his leaning, but I'm sure Danny will correct me if I'm wrong.

Multi-threading needs to be accomplished at some point, anyway. Everyone is crying for performance improvements, and this is one obvious, albeit difficult, way to do that. As is my other favorite path: a real database server.

[ixxx69]

Modeless is definitely needed for almost every dialog, the only question is which incarnation. It's easy to see that there are some complications mostly because Revit's (or the computer) is not fast enough to keep up. I'm thinking of times where I change a door family with lots of nested components. If there was a pause of multiple seconds for regeneration after each change in the dialog, it would be unusable (and when I say that, I mean where the program appears to hang for a moment and the cursor turns into an hourglass). So, I'd take an "apply" button over instantaneous if it meant avoiding that scenario. Looking at Erik's post, I think this means "Instant Update - Keep UI available" - if I'm understanding this correctly, this is what I'd want if it was feasible.

If you can't make the regeneration transaprent, the way a program like Photoshop deals with this is that they have a "preview" checkbox in many of their filters (where it may take a long time to process a filter). I wonder if it would make sense to have something similar, where there's an "Apply Changes Instantly" checkbox at the top of the dialog.

Also, if there isn't an "Apply" button, then I assume there isn't a "Cancel" button. So "Undo" should be robust enough to clearly revert any changes.

Erik, it wasn't really clear to me what the first part of your post was about - I can't think of too many element properties that are visible on the Option Bar when an element is selected. I just went around a drawing selecting stuff, and I'm not seeing any instance/type properties showing up on the Option Bar. Actually, I think a common complaint is that there isn't enough element properties in the Option Bar - e.g. why isn't wall "Location Line" displayed in the option bar when a wall is selected?

The wall Location Line is displayed when creating a wall, but that's not how most designers think when designing in Revit. In my experience, most designers like to just get something on the screen and then copy stuff around and shape it from there. I only "draw" about half the walls using the wall tool - the rest I just copy walls around. This goes for most elements. I draw one floor and then copy it around and edit. It's not a matter of changing the floor tool, because there's only so much you can change the designers thought/design process and workflow before you end up with a disaster (e.g. see Ribbon). Most of design is the process of editing, changing, re-arranging. This is an important reason for why we want modeless dialogs in the first place.

This could be made into a separate topic altogether, but I think it's worth revisiting how the separation of "Instance" and "Type" dialogs is currently implemented. This is probably in the top five "stumbling blocks" of learning and understanding Revit, not to mention a huge time waster. I certainly like the idea of quick access buttons for both Instance and Type as Erik suggested, but that's just a start. While the concept of their separation is both necessary and powerful, I question the importance of having them *visibly* separated in separate dialogs. For instance, imagine a single dialog that displayed either Instance, Type or both at the same time (kind of like if you glued the two dialogs together side by side), and at the click of a button in the dialog (e.g. "List, Grid, Coverflow" view buttons in iTunes), you could switch between "Instance", "Type" or "Combined". This would cut down on the confusion of the "endless dialog loop" that confounds new and occassional users, and would be a huge productivity boost for experienced users.

[Robert]

I like keeping apply because of the deliberate act it requires. Presumably after a change to a property pressing the Enter key would result in "application" of the property change, and not a move to the field below. The "killer" as your story relates is the constant transitioning into the dialog, and time for regeneration of the screen, etc. I beleive I would also like to keep Type properties in a separate non-modeless dialog by default. If Types were allowed to be modeless, then changes in that state should result in the same message displayed when modifying type properties via Schedules or Tags. I greatly fear users changing types, without fully understanding the ramifications, particularly if the modeless dialog is just "sitting there". Easier access to "View Depth" (perhaps with the other view toolbar options) would be appreciated, but I'm not sure that full modeless access to all View Properties is really necessary. I can see where it would occasionally be helpful, but I'm not sold. I like the change in 2010 to allowing direct access to Instance or Type, however I do miss seeing the Type Properties while looking at Instance info, a roll-up on Type properties could be useful in either instance (mode or modeless).

[John]

There is a need to avoid regeneration of the model. Properties should change after "Apply".

But seriously an easy change is to have two separate icons for instance and type properties(not a pull down menu.)

Also having direct access to the view range would be an improvement in productivity.

The message I'm trying to relay is start with the simple (and in my mind the obvious) productivity improvements before adding new features to the UI.

In any case I applaud the openness of this blog. Keep up the good work.

[Chad]

My preference would be User/Focus, with clicking out of the dialogue. I'd like to know that if I changed a parameter which was at the top of the list, that I wouldn't have to traverse to the bottom of the list to press the Apply button, before traversing across to the Project Workspace.

Just on the Instance/Type parameters accessibility, I would like to reiterate my concerns which I mentioned here; http://insidethefactory.typepad.com/my_weblog/2009/05/split-buttons-and-drop-down-buttons.html?cid=6a011278d71c9628a4011570806418970b#comment-6a011278d71c9628a4011570806418970b

I would prefer to see a Type button on the Instance dialogue, and not put the Type parameters on a modeless dialogue, or even worse, together side-by-side with the Instance parameters. Type parameters are accessed far less frequently so keeping them modal isn't such an issue to me and helps keep them 'safer'.

[PaulB]

I certainly support the idea of a modeless dialogue box which could be docked or not by user choice. I also support the Instant Update mainly due to the fact that I am a firm believer of; you should know what you are asking the software to do and so when it's finished I don't want to have to click “Apply” or "Are you sure you want to do this". For goodness sake, of course I want to do this otherwise I wouldn't have started the command....... As long as an undo works. With most of the changes that have an effect on the regen time, once you are aware of this, you would do these at a more suitable time.

I would also add that most of my projects are not large multi-storey or overly complex buildings and so therefore the regen times tend to be fairly quick.

Once again though it is all about user choices. Is it possible in the options settings that the method could be chosen as to how you want it to behave or would this mean that the overhead (in terms of software maintenance) would to too great?

[Anthony Hauck]

A few points from the comments so far.
-I would maintain access to Types from the Instance dialog
-A properties palette could be docked or used as it is now. Buttons for both Instance and Type would still be available in the ribbon yet at the same level - not in a split.
-"Apply" could be activated with the "Enter" key. I also proposed we could apply on the next click or when the mouse leaves the dialog. The option bar does this now.
-There could also be a setting to enable an Instant update. The Photoshop filter preview example is a good one. Smaller models may have less issues or you may be involved in a low overhead task like detailing.

[GeoffB]

I would prefer instant update and hope that hardware/software will soon be optimized to deliver that. In the meantime how about a combination of the proposed behaviors. Instant update, but only in the active window, then propagate all the changes when focus is returned to the workspace. If that is not practical then I fall in line with Chad. Either way simply clicking in the workspace provides a simple, easy logic that avoids the Apply button.

[Joel Osburn]

I am fundamentally against nesting the dialogs boxes: this is what leads to the overly clicky nature of Revit, and having to back out of four layers to see results, and initiate the next task.

I understand the fear regarding how much damage a newer user can unwittingly wreak on a model, but this is a problem that users move past. Undermining experts and future experts for the (limited) benefit of the neophyte is undesireable for the simple reason that we expect to use this platform for a long time. We will learn it. We will teach it. It will become old hat. We need it to suit the bulk of our use, which will be as experts seeking efficiency and transparency to our design efforts.

A potentially mediating solution might be to more clearly delineate which dialog box is which; at a minimum, I'd like to see a count of objects that will be affected in a prominent location, next to the Family/Type buttons. This way a user could tell that they are affecting one item or thirty-four. Another tack might be in how changes are applied; instant for Element Properties, but only on Apply for Type Properties. Color coding could work, but if it's an idea that is expanded upon in the future, would probably end up looking terrible.

I suppose that if an Element Properties palette were always visible, and presented a button to get to Type Properties, then at least there would be one-click access to it, but I would prefer to be able to see the parameters of the type immediately, in it's own docked palette. I think most data entry views that affect the BIM should work this way; only Revit settings should have modal dialog boxes.

[eivendur]

how about a tabbed property-window? like in acad? instance properties always available, the type parameter in the same window, but on adifferent tab - and i would love the option to let the user decide if he wants instant update or only after hitting apply.
and - could the properties window and all the other windows were i constantly have to scroll down to get to where i need to be, just detect that the mouse is in place and save me the anoying extra click? (as impelemented in firefox bookmarks-sidebar, directory opus and many other programs)

[Aaron Maller (twiceroadsfool)]

Some sort of transitional *go* button is a must, and ill tell you why: Nested Families.

I know its been mentioned, but some families with complex geometry and Mathematical formulas have a regeneration time close to 25-30 seconds or more. Waiting for that, when you KNOW you have 6 parameters to edit... stinks.

But i LOVE LOVE LOVE the idea that simply "clicking out of the dialogue box" is the activator. No apply button needed.

The dockable rollout palletes in ACA are great, in terms of how you can arrange them. Actually, while were on that subject: THE PROJECT BROWSER. I love it, its great that we have it, etc. Auto HIDE for it would be a godsend, to me anyway. Im not a recent ACA convert, ive been in revit the last 4 years... But im also reconfiguring ACA for the ACA portion of our office, and i have to say, its GREAT that we can set up standard palettes and dialogues and have them HIDE. The BROWSER is great when i need it, but you have two choices currently: Keep it slim and only see the full view names when you hover, or keep it wide and have it eat up real estate. AUTOHIDE!! :)

I also LOVE LOVE LOVE the idea that it defaults to View properties unless something is selected.

Think of it like this: When i need the "properties" of SOMETHING, its either: an element, or the view. I have a 100% chance of needing to select it, if NOTHING is displayed in properties. If its an element, i need to select it ANYWAY. If it displays View properties by default, and i keep my Modeless properties dialogue visibile (user choice), now for the percentage of times i need the VP and not the EP, its two clicks i no longer have to make (right click, VP click).

Suddenly VG/VV is one click away, underlays are one click away, view rangle, Phase filters, etc.

As for your concerns about entering invalid items like the wall constraints, etc... Its irrelevant. We already are faced with that. I select a bunch of walls, i change a height to something that doesnt make sense... It churns for a second and gives me a somewhat indiscernable message that im fooked. As far as that goes, heres something to consider:

In Digital Project, when you give something a value that cant be done... It doesnt force you to undo. It TURNS THE VALUE RED. Sometimes when im typing in a formula for a parameter, i need to get out of it to change something else... But i dont have the syntax right. Tough noogie, revit tells me. I have to waste it, or finish it... Sometimes not possible. For this reason, many of us write our formulas elsewhere, and copy them in. Thats silly. Bad syntax? Okay. When you click "okay" turn it red, with a pop up warning. Of course it wont WORK, and itll stay red... But i can move on for now.

Same for things i break in my project. I changed a wall height. What, you cant make the wall? Okay. Dont DELETE the wall, leave it at its previous value and TURN THE WALL RED. EVERYWHERE. And keep the incorrect value i put in, and ALSO turn it red in the MODELESS PROPERTIES box. :) Then i click my red wall, see my "related warnings" button, and my red parameter, and i fix it... Instead of deleting a wall and every hosted element attached to it...

As for Instance vs. Type... Id make them seperate Modeless dialogues all together. At different phases in a project i may want instances up all the time. Types, not so much. Other times, i may want types, not instances. (Of course if i had my way and these were ACA-esque hideable dockable palletes, id keep them next to each other docked-left. when i want one consistant, i un-autohide it...)

Overhead running Modeless dialogues, i would WILLINGL take. What i WOULDNT want? Overhead to run fruity tranitions. Even when i want auto-hide stuff, i dont care if i SEE it slither off screen. I dont care if it fades. I dont care if its elegant. (Same with the rest of the UI...)

I care that it goes balls-out fast, plain and simple. I run Vista and WinXP in old-ass "look like Win 98" mode, with no glitz on whatsoever.

While were talking interface, if the ribbon stays can we get a "no transition and no glitz mode?" Ill take the headache i get from it, but when i click MODIFY, i want to see it already. :)

Thanks for listening!

[Balazs]

Well done Autodesk, finally we are talking usability! I'd prefer an "apply" button with a click away from the dialog also acting as an implicit "apply". It would also be great to be able to place this dialogbox anywhere in the desktop, ie. away from the main Revit window like the project broswer.

[mruehr]

I'd prefer an "apply" button with a click away from the dialog
Or Enter with fast Right Click (enter parameter 1/ slow right click/ enter parameter 2/fast Right Click (Enter) Values are applied.
We have some deep nested Families that take a lot (a lot) of time to update
It would not be helpful to wait 3 Minutes per parameter to update.
TURN THE VALUE RED as described by Aaron would be very very sleek.
•Quick access to the properties dialog for those that may not want to dock it continually.
•Separate Taps for Instance and Type, or separate modeless dialogues
•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

[Tim Waldock]

There are some great ideas here - but lots of them conflicting, and speculation. I think it is really important that we get a chance to test the options in some form way way before beta stage, so we can give more precise feedback. If a wrong decision is made on this we'll all have to live with it on all the dialogs for years. Maybe we should just start with the instance properties dialog before it is applied to any other dialogs?

I love the idea of properties going red when they are the cause of a problem - then you would not be able to leave the dialog until you fix it. View properties dialog by default unless element properties is relevant is also great. View range should just be another section of the View properties dialog (not a separate dialog).

Type properties dialog should be kept separate and hidden unless it is summoned. It definitely needs to keep the apply/cancel buttons - I like being able to cancel if I realise that apply has done more than I expected (effectively undo). Maybe we need apply/cancel on element properties too, but also the ability to apply by just clicking outside the dialog.

Modeless dialogs need to work for small single screens (laptops) and for dual or widescreen monitors - so we need options. On Microstation with a single small monitor you get buried in modeless dialogs in minutes, but it works really well on dual monitors. So, for any Revit modeless dialog the user must be able to set it back to modal, or else have some kind of auto-hide.

[JGA]

I feel the idea of no apply button doesn't appeal, for the reasons already stated, but a tabbed interface which can be left open does appeal.
Also, can all the boxes be adjustable by dragging the edges/corner, as per the windows conventions.
On another tack;-
Where a numerical entry is required in the Options Bar, can the current entry be kept between uses, & already selected if I want to type over the previous value. If the option bar only has the one option to alter, can it not be already highlighted to overtype without having to move the mouse to the box, clicking & dragging the current entry & then typing in the new entry.
There, I've got that off my chest!

Great blog, good to hear the programmers point of view & practical difficulties of improving a software package.
Keep up the good work.

[Eric Anastas]

I don't think adding a modeless properties window, necessarily, has to affect the workflow in Revit. To me it's not an issue of what you do and when you do it, but rather just the number of click and the mouse movements it takes to get to the properties window.

What I'd like to see is a dock-able properties window like there is in AutoCAD. So ultimately, if I'm working in Revit and I'm ever at a point where there is a "Properties" button on the tool bar that I can click (active selection, beginning of command, editing a floor sketch etc) I'd rather just turn my head and look at an already open and docked property window then to have to click a button on the ribbon.

If Revit is in a state where a properties window does not make sense (nothing selected, not at the beginning of a new command etc) then the properties window can just be blank/disabled. For example, if you have nothing selected in AutoCad the properties dialog is just shows "no selection" and the current layer and color settings.

[DoTheBIM]

Lots of great suggestions... a bit off the topic of information requested but great none the less.

On the subject of number of clicks. I'm particularly fond of word 2007 appearing/disappearing common toolbar for selected text. While I acknoledge that this could be a challenge to implement in a 3D design environment... it gets to the core of number of clicks and user focus. place the tools a user needs most common right on the screen where the user is looking/focused.

To respond to the blog request. I'm not particularly fond of the 10 sec delay every time I check a check box in my door family. So instant update as it works right now is useless to me as I can't see those updates till I hit apply or OK anyway and I gotta wait 10 sec. to boot.

I think "Instant Update - Keep UI available" is most appealing to me IF There was some visible means to tell me the Revit was not yet done calculating something and it gave me the option to tell Revit speed up the process by locking me out of making changes until the process was finished. If Revit could make use of multi core It would go a long way to reducing conflicts on edits while calculating in background. This does seem like the most difficult to implement but it does seem like the most productivity geared approach which is what all this software is about anyway.

[Anthony Hauck]

Digression into sub topics are OK. There are a lot of suggestions but reading through all the comments there are many common threads. In-house we have brainstorming meetings with subject matter experts, developers, and UI designers. During a meeting its always fun to see how some designs meet technical issues and some technical issues can be overcome by a clever design. One person's idea will inspire another to something even better. This blog is adding another voice to the mix and I hope will produce even better results.