First thank you all for the relatively large amount comments on the previous selection post (Press & Drag) that can still be found here. Again the best comments explain why you use it one way or another since that helps us understand how to best support your tasks and uncover patterns of usage.
In this post I want to briefly talk about Chain Select This is the behavior that allows you to select a contiguous set of connected lines. Revit does not have a polyline element so this is one way to speed multi-segment selection.
In the Massing environment the preference is to always select the chain or loop. Tab will select individual sub elements of the chain. This is 180 degrees opposite from the project environment where individual elements are given preference and you must tab to select the chain.
Each behavior has its benefits yet having two opposing behaviors can lead to frustration and slow learning. Is this the case in the field? Do you prefer one behavior over the other? Why? Do we need a setting to control this? can one behavior serve both environments?
Posted on behalf of David Conant - Principal User Experience Designer:
A product like Revit that is moving from adolescence to early maturity needs to revisit its roots periodically to make sure that it is not coasting on early glory. To illustrate, let me turn on the time machine.
The scene: An architect’s office late 1999.
The action: I am demonstrating a Beta build of Revit 1.0. On screen we see a floor plan, an elevation, and a window schedule. In the floor plan, I add a window. It appears immediately in the elevation and a new line appears on the schedule listing an instance of Window Type 2. I delete another window from the elevation and it disappears from the schedule and plan.
The reaction: “That’s amazing, I love it. Checking window schedules is so tedious. Now how do I put the window type symbol in the schedule? No? I’m going to hate that. What about adding comments or shading every other line? That can’t be hard. I’m sure you’ll fix it soon.”
Now: It’s 2012. Revit schedules can do much more than they did in 1999. You can add new properties, perform some calculations, and group header cells together. Unfortunately they don’t provide full control over cell format, won’t schedule a generic model component, or display a window tag. “You’re killing me” I hear.
Schedules and related elements such as Legends, Takeoffs, Lists, or Reports are powerful and highly useful features of Revit. They do, however, have a number of limitations both in the data that can be presented and how it is presented. Some are the result of constraints imposed by current interface tools, others reflect deeper issues in the Revit data structure and regeneration engines. To build a better picture of how the tools should be working, the AEC User Experience team is studying schedules and related non-graphical data display tools.
As one part of this research effort, I am gathering information on how you use or want to use schedule and schedule like methods in your work. If you are interested in helping us in this, I have provided a link to a short survey focused on your usage and a request for you to share image samples of what you are doing. Samples of real work are an important part of our research. They will be used as test cases and help us illustrate themes as we explore methods to increase flexibility and capability. They need not be confined to what you can currently produce in Revit. Examples of what does not work well or appear correctly in Revit are more useful than what worked well.
This control defines what happens when you click on an element and drag while holding the button down. It defaults to being enabled.
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.
I'm in the midst of conducting some research related to the Project Browser and wish to crowd source some of this with our readers.
For this specific effort I desire to better understand current usage and context. To this end I'm on the search for screen shots of the following:
Browser Organization "Folder" and "Filter" tabs for Sheets and Views. (4 images)
Project Browser Screen shots showing all the nodes expanded. I realize this may be many as long lists are a known issue in the current design.
MEP Users feel free to send an image of your System Browser
Anything sent will be for internal use only. If you use a third party product please mention it as I'm looking at products offered by our partners as well.
From this information I hope to get a better picture of how data is organized (by discipline, project parameters ect..) and also what constitutes a realistic data set (size and diversity) for use in testing new concepts and ideas.
If you can help please send images in any format via email.
I'll follow-up in the weeks ahead with more related topics to help validate known issues, common tasks and requirements.