Press & Drag?

Everyone familiar with this little guy?

This control defines what happens when you click on an element and drag while holding the button down. It defaults to being enabled.

Behavior

• When enabled the element under the mouse down action will be selected and then moved as you drag.
• When not enabled the mouse-down/drag/mouse up will select elements only and will not move any selected elements in the same action.

I'm interested in how many people use this setting.  I know one may disable it to try and pick elements that are located over another larger element such as an imported image or import.  The aim is to avoid picking and dragging the background element while making a window selection of a smaller group of elements.

Lets imagine this control is un-checked and removed from Revit.

• You can still select elements then drag them -  just not in the same action.
• Accidental drags are prevented which is good as this can often cause long regen times and slow tasks

What are the downsides?  Please share any you see.  Is drag/move even useful given the lack of accuracy?

FYI, I am looking into this as part of research into face selection.  It is a well known issue that having to pick elements by their edges and tabbing to do so is a usability and learning issue.  Allowing face selection, however,  will increase the potential to accidentally drag elements on selection.

BTW to preview face selection it currently works on the Part category.

_erik

 

Comments

[Ryan]

I choose not to enable it. The main reason is that I've made some modifications to elements without knowing I did or meaning to. Also, the way my brain is conditioned, via ACAD, I'm thinking in the way of a two step process. 'command' then 'select'.

[C M]

I would definitely be in favour of disabling the setting and removing it entirely. Most new users fall foul of this and make a mistake, as despite being told about it they have so much to learn it doesn't register on their radar.

[Alfredo Medina]

I have used Revit for about 5 years, and I have never used this seting, and I have never seen that it was necessary to change its value to achieve or prevent anything. Whatever the default value has been, I suppose that is OK, because I never change it. This is the most insignificant feature of all, in my opinion.

[Anthony Hauck]

So far my suspicions are confirmed but I like to get as much feedback as possible - even before an alpha or beta.  Im sure we created this setting to mitigate risk where there was less clarity.  This will often work but puts the product on a path to complexity.

[John Flannery]

I can't live without it. Don't know why, but when I don't have it checked or I uncheck it by mistake I get frustrated at why I can't click and drag. Please if you don't like it don't check it.

[Anthony Hauck]

Im curious what you are dragging or the specific use case.  Drag seems very inaccurate unless you use temp dims.

[Aaron Maller]

The Press and Drag functionality is a major liability.

The infamouse "Screen hop" problem (which has been misconstrued as having to do with any number of the following: Linked Files, secondary monitors, undocked properties palettes, etc) means that you will MOVE an object in your model when you select it, if P+D is turned on, since the Options bar grows to three or four lines deep, and the Revit UI seemingly builds itself from the top down.

In addition, Revit being a program (im not sure why) where you click in dead space to end certain commands, P+D becomes even more dangerous with Large Linked Files, and "References" from Component content sometimes spreading to the extents of their geometrical constraints.

I would TYPICALLY never vote to remove functionality, in favor of just having it a user configurable option. HOWEVER- the issue of Face selection versus edge selection is brutal:

Its different in the CME, its impossible to deal with on complex models with a lot of links and a lot of geometry, and it makes designers and new adopters more resistant to the program.

If you can enable face selection while keeping P+D, i would do that... Allthough i think people are nuts who leave it on. We disable it in the INI that gets deployed.

[Gordon]

I am in the "turn it off" camp. It is potentially VERY problematic for new users, and I have yet to see any use in the hands of experienced users that actually adds value (as apposed to just being familiar). As such, I actually have it off from Deployment on. If nothing else, it would be great if there was a flag in the install process to make it available or not, and let each office decide.

That said, it is a very important setting for successfully running lots of journals. Phil Read's benchmark journal requires it, as does the derivative RFO Benchmark. Many others do as well. So if it goes away in as a user facing feature, it needs to be either a journal directive, or simply on when journals run if having it on doesn't cause problems for those journals that don't specifically need it. And journal execution would need to toggle it back off if a journal file fails and drops into interactive mode. Having it still on, and no way to turn it off, for the rest of a session post journal failure would be a real bummer.

[Dave Plumb]

I'd vote for getting rid of it.
That's one of the first things I tell people to turn off, and our deployment is sent out with it off.
My thinking is that - with P&D off - it's just one more click to select an element and THEN drag it.
With P&D turned on, it is WAY too easy to start dragging something when you meant to create a selection Window. Once you accidentally drag something, you'll often have to clear a few Warning messages. Then (if you didn't notice fast enough to hit ESC) you'll need to Undo. So one click just a couple of pixels off can cost you several minutes to recover from. And that's if you happen to NOTICE that you accidentally moved something.
In my opinion, a dangerous command, for which the "workaround" is to simply click twice.

[Anthony Hauck]

Good points.  We are probably the heaviest journal user so your points there are well known though I would not use it as an excuse unless its also an issue for customers.

[Aaron Maller]

Guys- dont take this the wrong way: But if journal files and regression testing are even a CONSIDERATION in what direction the program goes in terms ofbetterment, we have all done a major disservice to the programs potential.

I once had a long phone conference about the extremely poor quality of the OOTB content, and how i knew firms who would DONATE better content to the cause, if it meant Revit shipped with better content. Regression testing and journal files all using the busted *** "Single Door.rfa" should not be a reason that Revit doesnt ship with OOTB Nested Door Panels.

Nor should it be a reason Press and Drag stays as it is. If research vets that it should stay, it should stay. But journals can be remade in a couple of hours, even by an idiot like me who cant do anything with code more than copy and paste, trial and error.

=)

[Anthony Hauck]

completely agree.  Internal workings should not hold up progress

[Gordon]

FWIW, I am not suggesting that journal needs should stop UIX changes, but in this one case I think the right answer might be to remove P&D from UIX while leaving it enabled during journal execution only, IF that can be done (relatively) easily. If this can't be done, an Autodesk provided script to convert journals to the new behavior would be the next best solution. Followed by forcing users to modify their journals. NOT changing UIX is the last option, and really should not be considered.

FWIW, I see P&D as very similar to the user name bug introduced in 2012. It is a bit of an edge case, there are educational ways to mitigate the problem, but mostly it is just a lousy problem that should just be fixed.

[Steve]

Please leave my Press and Drag alone. I'd be quite frustrated with the extra clicking to select then move things. There are many things (text, tags, dimensions, furniture etc.) that can be arbitrarily adjusted using it that losing it would tick me off.

Getting rid of it just because new users aren't used to it seems a bit extreme to me. Fix any real issues like selection priority of linked files over native elements instead of getting rid of it.

[Chad]

I'm with Steve on this one. I'd go nuts if I lost this functionality as there are many times where I drag elements.
I'll add to some of Steve's examples where I also use Press & Drag with areas such as Massing and Family editing.

I've seen many a user do just as badly with this option turned OFF and miss-selecting their elements before using Move.

It comes down to the user and their individual ability to take care. Not the software.

As a user who NEVER turns this off, I'd be devastated if I lost this feature as it provides an increase to my modelling and especially documenting speed.

[Michael Ruehr]

We have it off via the ini.
I agree that in larger working environment it is a liability.
I would prefer to have a switch to not install it.
If Steve and Chad can’t live without it we don’t want to make their live hell.
But as for the 100+ users working with me and asking me where their stuff magically disappeared...they won’t have a Choice. My sanity is more important.

[Tom]

I use press and drag all the time. It's not inaccurate, as Revit has fantastic auto-snap and alignment. For items that don't require perfect alignment, it's also very useful. Please don't get rid of it.

As for select by face, don't you even dare think about doing that. In a black and white hidden lines view, it's often impossible to know what object is presenting a face. Every bit of software that has select by face drives me up the wall in frustration.

We are all skilled and intelligent professionals and can manage to tab through selections. It's not a hard skill to teach. Learning the software takes a short amount of time compared to the *years* of use it gets afterwards. Do not sacrifice usability on the alter of new user friendliness.

[Aaron Maller]

What i find intriguing about this conversation, is it really gets to the crux of the matter: Maybe im wrong and it shouldnt go away at all (although i wish it defaulted to off, but thats another story).

Maybe Press and Drag, AND Face/Edge selection, should be configurable options by User?

That is really what were getting at here. Tom thinks Face Selection would be a disaster, and i emphatically disagree with him. Its not about training when there are hundreds of objects densely populated: Sometimes there ISNT an edge to grab.

Regardless, why should either of us have to decide? Right click customizations, selection behavior, P+D... Theyre like Keyboard shortcuts, and they ought to be user options, not software decisions.

Reiterating my point above, i would only be in favor of blowing it away if it was this OR fix the selection issue. (But yes, guys, i think youre nuts!!) ;-)

[Anthony Hauck]

Everyone is entitled to their opinions and if anything it sheds some light on the difficulty of making any change in this product.   I do agree any changes that affect selection should be considered together and when there are many different opinions and use cases options can help.  It would be a large research project to go through every category to find which might be dragged or not to remove the need for this configuration.
Other related topics are link selection and underlay.  I may post separately to discuss these.

[BecFra]

I always have my Press & Drag on and hardly ever think about it. If I enter drag (yes usually on a linked model) I escape the crap out of that command. However I have seen new users really not grasp the dragging concept. Not just press+ drag .. even select then drag! One must learn caution.

However, for "fun" I turned it off today. Didn't mind the click-click+drag process much, except for when it came to dimensions and text, and anything really where the second click activated the text field instead of dragging. Again one must learn caution... and break old habits when needed

Having it default to off seems best, as I’m not for taking away an option even if it’s so small.

[Anthony Hauck]

I'm not just interested in the way people have this set but more why one would change it from one setting to another.  It would be simple enough to enable drag on first pick for annotations, and mass forms and disable for model elements and inside faces of model elements as well as links if this satisfied the majority of use cases.

[Gordon]

1: Press & Drag behavior as an Object Styles setting. I imagine a setting for every category in Object Styles, with options of Locked Off, User Toggle Default Off, User Toggle Default On, Locked On. This would apply to both model and annotation items. On the annotation side I might lock Levels and Grids off, while the rest is User Toggle Default Off. Some other office might lock the same off, but set the others to user toggle default on.
Also, the same settings would translate to views. Items locked off or on would remain so, but the rest would be available in Visibility graphics for the view. So in my case, where all the extra model stuff would be set to user toggle Default Off, I could still create a Furniture Layout working view, where P&D is overridden to Locked On, while everything else remains User Toggle Default Off
2: Press & Drag behavior with linked items. This is probably the single largest problem area. If anything could benefit from simply disabling P&D, it is linked/inserted RVTs, DWGs, Images, and perhaps even groups. All of which are not available via OS/VGOverrides anyway.
3: toggle mechanism. I think part of the problem now is the persistent nature of the toggle. you generally want it off, then need it for a moment so you toggle it on, then forget to turn it back off and get burned. Perhaps a better approach is a non persistent toggle and a user default. So under Options I set my personal Default to Press & Drag off (INI stored, so it roams) then when working and I actually want P&D I just hold down the Option key as I press & drag. As soon as I let go of Option I am back to default behavior, which would reduce unintentional P&D issues. Also, Windows and most mouse drivers would allow you to map Option to a button, so toggling transient behavior could still be a single handed affair. Also, by moving the user setting to Options, rather than on screen, there is less chance of a newbie selecting it by "mistake". A user experienced enough to go digging in Options deserves to set their own value, the newbies get P&D Off as a safe default until they are ready to make informed decisions.
4: Address model "security". One of the major problems people have now is that things get moved that are catastrophic, usually by new users, and often not caught until much latter, due to lack of warning message or ignoring of warning message. P&D just makes this more likely to happen, but turning it off doesn't solve the problem. The items in question are usually things like Levels, Grids, Links, Site, etc. Currently Pinning doesn't really address the problem, because it only addresses movement, there isn't even a warning if you change the type or a value, or even delete (the ultimate "move" really). And pinning is a pain to undo when you really need to make a change, then re-pin. To address the issue some have gone so far as a workset checked out to a "dummy" user, but this is a huge pain as well, and non workshared projects can't use it. Abusing Design options also doesn't work as not all items can even be in a DO. But perhaps the Option select toggle idea could be expanded. A single project wide setting could require Shift Ctrl Select for certain object types to be selected at all. The Option P&D behavior would integrate easily. Perhaps both the keys and the object list could be customizable. This would effectively eliminate the "newbie mistake" of moving or deleting more than intended, and yet still allow editing quickly when needed. I think it would address 90% of the desire for a Lock Down capability rather gracefully. Over time one might even add to the list, with levels and grids there from the start of DD, but sections & elevations added to the list in CDs. This could really help tighten up model security as the project progresses, but without unwanted side effects.

Admittedly there is a fair amount of complexity here, but much less than all the visibility permutations, and people get used to that and eventually see it as a strength.

Gordon

[Tim Waldock]

I absolutely hate Press and Drag - it is so dangerous as it is. Yes we do turn it off in the INI file before rollout of each new version, but sometimes it gets forgotten or someone does a one-off install without getting the correct INI file; or sometimes an unwary user just turns it on to see what it is. As far as I am concerned, it just adds visual clutter to the UI.
The only time I ever used it was for moving views on sheets, but even now I'm out of the habit of that, and just go with the extra mouse click to select (then I don't have to worry about whether P&D is on or off).

Because of problems we have had with P&D, we have created an elaborate system of making some things non-selectable by putting them into design options to lock them (eg grids, linked files).

The one thing that we cannot lock down is section lines - especially the hidden part of the line in the middle. You can try to pin a section line so that users don't accidentally ******P&D move it, but then you can't change its 2d extents, so you have to unpin it each time you need to adjust that (and someone will forget to repin it). Oh what fun if someone drags a section sideways - the work it takes to undo that is a thousand times more than you could ever save in time with fewer mouse-clicks using P&D.

My vote would be to utterly destroy P&D forever.

[Steve Bennett]

I say keep it. It really does need some work though on prioritizing what it drags. It would also be nice to have a check box to turn it on/off by default when creating the installation image instead of having to hack the ini file. Or, make it a UI element that can be turned on/off like Properties or Project Browser. This way, you can hide it completely for the Revit neewbs and show the gurus where to bring it back...

[Clinton Maulder]

Get rid of it. It is a liability for those that are not aware of it. I instruct all our users to turn it off. Unfortunatly when we upgrade, it is on again. For the love of all that is good...ditch it.
Thanks.

[Michael Ruehr]

This discussion brings up an old Idea &Wish of mine. What about having a Predefined Selection Filter like in 3DMax where you can tick of categories you don’t want to select and let’s say filter it down to Walls and Dimensions and Text. Nothing else would be selected there you could have Options for different selection behaviour. This would be very helpful for instance when dimensioning to walls to make sure you select and dimension only to walls.
In my case I would turn off Links selection by default. Running wild this could be set up like the Visibility System with Predefined Sets etc.

[Chad]

Gordon: "I think part of the problem now is the persistent nature of the toggle. you generally want it off, then need it for a moment so you toggle it on, then forget to turn it back off and get burned."

So the experienced user who forgets to turn it back On gets just as easily burned as the careless new user who leaves the option On.

I'm certainly not picking on Gordon, but it's an interesting comment.
There is this general fear that On is ALWAYS worse than Off, and it goes back to my previous comment where I mentioned that I have seen just as many users who have this Off and still making dragging errors.
It's solely a user operator error, and one that I agree could be improved through improved software functionality, rather than just removing it altogether and disadvantaging the users who can use it On in a proper/safer manner.

Here's an opposing look at the above quote.

"I think part of the BENEFIT now is the persistent nature of the toggle. you generally want it ON, then don't need it for a moment so you toggle it OFF, then forget to turn it back ON and DON'T get burned."

It work's both ways.
The argument could be made that the Press+Drag when on by default and temporarily turned off is safer than in the hands of a user who works with it off and temporarily turns it on.

In the end, I don't care whether it's hidden in the Options and Off by default, as long as I can turn it On and it is remembered between sessions so I'm not having to turn it back On all the time. The .ini is not an option as the only way to do this. It has to be in the UI somewhere.

I do think Gordon brings up some interesting concepts and would be worth looking into by The Factory because there are some elements which I still want to move, but maybe just not by dragging.

Erik: "It would be simple enough to enable drag on first pick for annotations, and mass forms and disable for model elements and inside faces of model elements as well as links if this satisfied the majority of use cases."

That's a terrible idea to force a blanket exclusion on model elements. The place where Click+Drag is most beneficial is at the early design stage. This is the stage where elements are moving in a fluid manner and you would be hindering that fast flowing design iteration process. This comes from personal experience as my background is heavily in design concepts.

To add to this, it's also the stage of the design which has fewer elements in a view so the chance of mis-dragging incorrect elements is greatly reduced even further. The views are cleaner with more white space around elements.

I hope this helps to provide some points to the positive side of this discussion for keeping this functionality somehow. Thanks for listening.

[David Fink]

We have it disabled on all of our machines. I causes too many problems with objects being moved accidentally. It is much better to select and then drag.

[P. Lawton]

OMG, turn it off by default. Obviously, you can also leave the check box where it is for folks who may want to enable it. But for OOTB, OFF is best, by far.

Please count my vote 3,000 times (I do know someone from Chicago).

Thanks

[P. Lawton]

Upon further consideration, I am going to adjust my 3,000 votes:

Please leave the checkbox for folks to set as they wish, but add a bit of publicity such that folks understand it better.

A more useful solution to the problem of inadvertant selection could be perhaps enhancing the power of 'pinning' objects, such that anything pinned is also 'locked' and cannot be selected. Then we can pin equipment and linked entities, they won't move, and we can't accidentally select them.

Thanks

[Jason Halaby]

Please disable it by default and make it a setting accessed through the options dialog. I have outlawed it in our office because it causes too many problems with accidental dragging.

[Vincent Cadoret]

I'm with the others: it's a liability, please disable it by default or even remove it completely.

I tell all my students to disable it as soon as I start teaching them Revit.

[Tim Waldock]

It seems that there are a few people out there who support the use of P&D, but the majority hate it. So as an absolute minimum, the default OOTB setting should be OFF.

But what this really highlights is the terrible deficiencies that Revit suffers in terms of model security, as described by Gordon and others. We have had quite a number of elements accidentally dragged, but by far the most serious have been gridlines (because the entire building model can be affected) and section lines (because section drawings can be utterly destroyed by one accidental drag. We also like to lock down Linked files and any structural elements (in an architectural model). In fact we now put important stuff like structure into a separate linked file (even if not collaborating with structural engineers), because we can't afford the risk of someone accidentally moving.

This is one of the most important things that needs to be improved in Revit. Even more important than site tools and . . . .

[Lance Cayko]

Wow! Did anyone say they use this option?! Great discussion!

[Anthony Hauck]

Very Lively