More on Selection (Links & Underlay)

When looking over the state of any feature in Revit it can often lead to a trip down the proverbial "Rabbit Hole".   So far on the topic of selection I have covered Press & Drag, and touched on Chain select.  In this post I want to get some feedback on Underlay and Links with respect to selection.

Underlay

Underlay has always been slightly out of alignment with user mental models.  In 2D processes underlay had one drawing placed under the other yet in Revit we are looking deeper into the model at parallel levels - not placing one view under the other.  Further there is the additional behavior that underlays are open for selection which is also often unexpected.

This can come in handy when using Linework to reference items above yet can also cause accidental changes do to inadvertant selection.  You may note that the system currently prevents box selection from working on anything visible via the underlay and this was implemented after receiving user feedback.

My question to everyone is when is selection of an underlay useful?  MEP workflows or reading property values? What if underlays were never selectable?  Is the work around OK?

Another potential mitigation strategy would be to allow underlays to be selectable in specific tools, such as the Component or Linework tool, yet disallow selection for the Modify (Arrow) tool.

I'm very curious to hear your thoughts.

Links

Much like underlay when is the selectability of a Link a problem and when is it advantageous?  Specific examples can help us acheive the best default behavior and/or allow flexibity if required.

_Erik

Comments

[Steve]

Links should be secondary in the selection sonar, Revit should "see" native file elements first. It is particularly frustrating RME workflow relying on links more so than other trades to some degree.

Microstation uses separate tools for dealing with external references. I thought it was silly coming from AutoCAD experience but then seeing Microstation users struggle with accidentally moving Xref's made me realize that if "that's the way it is" we adjust. The separate tools conditioned them to expect the same in AutoCAD. I'm not suggesting that I'd like separate copy/move etc for links.

I think making it necessary to use the Tab key to select a link would be better than we have no. If it were possible to toggle on/off an option to make links select-able or not, like the Design Options check box...that might be better still.

[Steve Bennett]

I really like Steve's idea about a toggle/check box to turn on/off selection of links, but how would that differ from setting a link to be pinned? Pinned affects everyone, but would the toggle only affect one user? Could it perhaps be a project setting to lock/unlock links from selection/movement/editing?

I personally think that it would be safer (especially for new users of Revit) to have elements shown via underlay to not be selectable for edit/move by default, yet have the ability to do so via a toggle. Yes, you can always go to another view to align something as needed, however for those already accustomed to this behavior might be undesirable.

[Luke]

"Underlay has always been slightly out of alignment with user mental models."

I think this should be changed - underlays should in fact reference some particular view - this would give a lot more visibility control, and it would be more intuitive.

[David]

Great comments. I would suggest the checkbox options for underlay selectivity and link selectivity be in a dialog box, however. I don't want the user interface too overly cluttered with option boxes.

[Yves GRAVELIN]

Une utilisation très courante est la projection d'élements situés en plan de plafond ou les bords de toit en utilisant l'objet trait.

A very common use is the projection of elements located in ceiling plan view or roof edges using linework tool.

[Anthony Hauck]

Yves, Il est possible de conserver ce comportement (avec Linework) tout en évitant un effacement accidentel avec de loutil Modifier
Je te remercie - Erik

[It’s possible to keep this behavior (with linework) and still prevent accidental
deletion in the Modify tool]

[Tim Waldock]

I am delighted that you are looking at all this selection stuff, as it catches out so many users (new and experienced). We regularly put our grids, links, topography and structure into design options specifically so they cannot be selected (topography just because it saves time not accidentally selecting it). It works well, but we just wish we didn't have to (ab)use functionality that has other purposes. So we'd be happy with a non-selection mode that behaves in the same way - don't mind if it is done on an element or category or workset basis (or all). Yes we'd need to be able to override this when we actually need to select something - could be a checkbox like design options, or if by category/workset then they could be made selectable again projectwide.

I would like to see this taken one step further, so that not only are some things not easily selectable, but they are really locked in place even if you do manage to select them (links being one) - pinning is hopelessly ineffective, so we need a more powerful lock.

I would like underlay objects to only be accessible for linework, override, hide in view (view based modification); definitely not for move, delete or any other kind of model based modification. This could be a locked in behaviour (no need for options to override these rules).

[Michael Ruehr]

Underlays should be part of the visibility system and behave like Linked Views but should be able to be selected and questioned. “Predefined Selection Filters “ just like the Visibility System could control the selection behaviour of categories, links and underlays. You could choose to select and or alternatively lock or both. You could turn on and off Links, Underlay selection or any other category. Selection Lock Templates can quickly define the Selection behaviour you want for a certain Workflow. Down the line you may expand this to dimensioning so only Categories that are ticked can be dimensioned too. I’m Dreaming am I ?

[Chris Hubbard]

I like the check box option. We often select elements from the underlay, and occaisionly mis-select elements. We are well trained.

But one more parameter below the Underlay and Underlay orientations does not see onerous to me. I would welcome that.

[C M]

Linked file selection can be a problem - you only have to be a pixel off and you can select a linked arch file for example and have to wait a while them while Revit updates references etc. Some way of having to consciously select a linked file or element in a linked file would be good.

[Tim Waldock]

Another related subject is the selection process in Area plans. Standard usage of area plans is to effectively have the building plan as an underlay (albeit in normal display mode of black lines etc), with area lines, colour fill and tags on top. When you work in an area plan it is most likely that you would not want to be able to modify the underlying model - ie you may want it to be not selectable except when you are picking walls to define area boundaries or else using the align tool (pick wall line then pick area boundary line.

We do not use automatic generation of area lines, or rule based placement of lines, as it mostly gets it wrong. So we place the area lines manually, and we do not lock them to walls because we don't want the model to be too heavy with non-critical associations. Whenever we want an area update we have to do a quick realign process. It drives me nuts when I am trying to align area boundary lines to walls and Revit wrongly picks other elements and shifts them. I need to be able to tell Revit that in an area plan it is only allowed to move area objects, therefore the second pick of any align command must always be an area boundary line only.

[Julian Jameson]

A check box for link selection would be ideal, set as unticked by default (non-selectable). It is really annoying when you have rooms shown in a linked model and when you are selecting MEP objects using a crossing window, the link is included too.