Hello, My name is Erik and I'll be joining Tom on this blog in making posts and participating in discussion. Over the years its been a pleasure watching the amazing work you all do with Revit and I look forward to continued contact with you in person and on-line. On to the post...
Rather than more talk of real world foreclosures and falling home values, this post will start a discussion on screen real-estate. A positive effect of reducing complexity and adopting the new user interface (UI) has been to increase the amount of screen real estate available to the working view. In the 2010 default state there has been a net increase of 6% (based on a 1280 pixel wide screen at 96 DPI). Most of this was achieved through the removal of the Design Bar.
2010 overlaid on the 2009 UI footprint (orange)
The option bar was another pre-existing UI element that received a lot of attention and design iteration. Prototypes were tested exploring possible replacements with the goal of addressing known issues such as discoverability for new users, mitigating horizontal space limitations. Although we retained the option bar in release 2010, it was slimmed a few pixels in height. We will be discussing the option bar more in future posts.
Shift in option bar height
Another enhancement concerned the project browser. We observed many customers running with the browser undocked on a second monitor, despite having to re-set it every session. Revit 2010 now remembers the project browser state and location between sessions.
During design we selected a minimum target resolution of 1280 x 1024 after analyzing customer data which showed this as the most common resolution. Now, I realize that many new monitors are 16:9 rather than 4:3 and many others are using dual monitors. To address this, the ribbon component allows for the ribbon to be docked vertically and/or minimized. We decided not to implement vertical docking in 2010 because of some design issues we felt reduced its effectiveness and needed further investigation. As for minimizing, the two minimization states allow the ribbon to be reduced to 57% and 44% of the fully maximized state. I'll discuss the vertical ribbon and minimizing in more detail in the two next posts.
Concerning dual monitors, I can say that multi-monitor support is one of our most highly requested UI features. We are actively researching this topic and we would like to hear more about your frustrations, experiences and suggestions concerning multiple monitors.
_erik
"Revit 2010 now remembers the project browser state and location between sessions."
This feature alone makes the upgrade worth while.
Posted by: archshrk | March 16, 2009 at 01:41 PM
Regarding your questions about dual monitors, ideally we'd be able to pull view windows off to the external monitor without having to stretch the application window across. I know this isn't a common or easy thing in windows but check out GIMP (Gnu Image Manipulation Program) as an example. Each piece of their UI is a separate window, except for the actual file that is being worked on. Keeping those window states with the view would even be better.
Currently I'll stretch the application window across two screens, open up a 3d view and a plan or section and then tile them. Most of the time the auto-generated sizing will be off and I'll have to adjust. Then if I open another view it stretches across both screens at about 1/3 height. Not useful at all.
I know you'd hate to hear it but it would be nice if it behaved more like AutoCAD. Where any of the information or tool palettes can be placed anywhere and their placement is remembered. Granted, most of Revit doesn't have those types of tools but I think something like a properties window would be a great addition. Ideally it would be just like Element Properties but always up. When you select an item, it is filled with the appropriate information. To me, allowing the same style of toolbars as AutoCAD to be placed at will would be great for multiple monitors.
Posted by: Tom | March 16, 2009 at 04:46 PM
Thanks Tom,
An application that remembers window placement is a good thing. Your window setup I have seen before with customers who have two 4:3 ratio monitors side by side. In your setup can you share more detail what window layout you would prefer with 3 or 4 windows open?
Thanks for the feedback.
-
Erik
Posted by: Tom Vollaro | March 16, 2009 at 09:31 PM
As mentioned by Tom, the ability to detach the view windows from the main application window would be GREAT for us dual monitor users. Also a decent way to organize the views would be nice as well. Window tile is nice and all but having to do it 3-4 times just to get the windows organized how I want them is a PAIN. For example, I make alot of families. When making a family I like to have my three orthographic views (Top, Front, Right) and a 3D view tiled out on my screen.
Top 3D
Front Right
To achieve this I typically have to go through a few WT's (Window Tiles). If I accidently WT in the 3D view well then all my views get moved and I have to spend a few seconds clicking through different views and WT'ing to get them to organize correctly. In ACAD you could use the viewports command (named views option) and it would organize the views just as you specified. It would be nice to have this functionality in Revit as well.
Ty
Posted by: Ty | March 17, 2009 at 11:26 AM
I use ArchiCAD on Mac with two monitors and Revit with a single 24” monitor. The features from the ArchiCAD set-up I miss the most are:
•Floating view windows, as mentioned by others.
•Savable palette layouts. I have one for the two monitors, another for laptop screen alone.
•The Mac OS Exposé feature for quickly switching between open windows. This feature alone justified an office wide OS upgrade. I’m not suggesting you copy this directly, but we need a quick way of visually switching when views are maximized.
And while it’s more a real estate hog than saver, I second the notion of a non-modal, contextual properties inspector.
-GB
Posted by: Geoff Briggs | March 17, 2009 at 09:00 PM
Options Toolbar:
I note your comments about reducing the height of the options toolbar - not a bad thing. However, that might explain why it does not work with "Large fonts" set in screen display. All other menus/icons do - I suggest that either the fonts on the options toolbar do not scale up, or else only scale up a little bit (as the options bar presumably does).
Posted by: Tim Waldock | March 18, 2009 at 06:03 AM
Dual Monitors:
It has been a while, but Microstation had a really good dual monitor implementation - it supported persistent, floating dialogs/palletes in each monitor; more importantly you could split the application window into two separate windows, which could be maximised (or user controlled) on each monitor; you could then drag individual view windows to chosen monitors. This would allow you to run one monitor with a full screen view, and the other with tiled views (or any other combination).
In Revit we often open two sessions so that we can keep the views from two projects separated (or project / family) - and not have to sort through lots of similar named views from each project in one list (we've made mistakes, working on the wrong project because of this). The downside is not being able to copy/paste or load between sessions. So the ideal in one session would be to nominate which views or projects go on each screen; and to be able to arrange views differently on each monitor, so one can be maximised, one tiled etc. When a new view is opened it should go to the appropriate monitor in that format (maximised, tiled etc)
Posted by: Tim Waldock | March 18, 2009 at 06:18 AM
Thank you all,
Your usage descriptions help us discern requirements and overall goals the window arrangements support. Some items I can pick out are:
-Desire to save a layout on one or more monitors and restore this between sessions
-Ability to switch between open views graphically as well as by name
-Better grouping of open views by project
-More efficient tools to layout and organize open views and assign them to monitors.
-Family editor and project usage differ
Thanks again.
Posted by: Tom Vollaro | March 18, 2009 at 09:39 AM
Thanks for the blog, it is very interesting.
Did you not consider making the Element Instance/Type Properties non-modal, dockable palettes as in AutoCAD whilst making the user interface changes?
For me, this is the biggest thing that affects screen real estate, and you cant see the results of what you are doing until you exit these dialogs in most cases.
Posted by: Andrew Dobson | March 19, 2009 at 05:48 AM
Hi Erik
I realy like the new UI. I only wounder why the Designbar has'nt been completly incorporrated with the Ribbon. Som of the options from the optionsbar is in the Ribbon but not all... Why?
Regards Peter
Posted by: Peter Tranberg | March 19, 2009 at 05:57 AM
Great blog guys, here are some suggestions.
The ability to have child windows independent of the main window. It's invaluable for working in one view and seeing results from many views.
Please simplify the Project Browser. Breaking the top level tree nodes onto their own tabs would be nice. Also, the top level nodes have icons depicting their type, but the child nodes don't.
Allow us to duplicate nodes and all of their children.
Modal dialogs. The modal properties dialog is especially tiresome.
I miss the palettes, from AutoCAD and its verticals, tool palettes, properties palette, xref palette, etc.
With all of that being said, you have worked hard on the 2010 UI and it shows.
Posted by: Bobby C. Jones | March 19, 2009 at 10:32 AM
Erik,
As others have said the multiple views of a project is typically how I use it. When I have the time to set it up I'll stretch the application window to nearly fill up both screens with a little real estate left for dialogs. I haven't been un-docking the project browser, only because I'm going to the left edge constantly for tools.
As for the views I'll have up, typically it will be a 3d view and a plan view, maybe with a section also. It depends on what I'm doing. With my last project I needed all three to place the roof framing properly. A section view to set the correct elevation and to match the architect, a 3d view to ensure I wasn't putting beams randomly into space and the plan to tag, document and place. When I'm having to repeat some bit of information across multiple views I'll have all the levels open and then cycle through in an assembly line fashion.
As others have said it would be great to tear off palettes of tools and have then float for quick access. The same goes for the Element Properties. I've been using the product for a year now and am the office's tutor when new folks start working in Revit. The drafters moving from AutoCAD have a real hard time remembering that the EP exists and is needed on a regular basis, cause there really isn't a perfect analogy in AutoCAD.
Hope that is all clear. And thanks for allow us to provide input to the process.
Tom
Posted by: Tom | March 19, 2009 at 02:54 PM
I will try to answer a couple of questions asked above:
'Did you not consider making the Element Instance/Type Properties non-modal'
This is a popular request. We know you spend a lot of time here and this one was reason it was made re-sizable and the controls were simplified. There are many cases when parameters reference each other or enable/disable other parameters so it becomes much more easy to get caught in circular references. All I can say further is we know there are a lot of opportunities here.
'Why the Design bar hasn't been completely incorporated with the Ribbon. Some of the options from the options bar is in the Ribbon but not all... Why?'
One of our design goals was to embrace the new UI rather than try to keep legacy elements around. It was an early decision to forgo a classic UI and its implication and instead concentrate on the new. In addition to improving consistency among the company product lines we want to realize future benefits and efficiency of sharing these elements. This said it was a huge undertaking. The Design bar was incorporated yet the option bar is still with us in 2010. Future posts will talk more about the design exploration we did specific to this UI element.
Posted by: Tom Vollaro | March 20, 2009 at 10:00 AM
I too would like to echo comments about the non-modal Properties dialogue, and I would personally like to see it as a dockable palete that has a roll-out behaviour.
I guess you really only need a single dialogue box/palete, which has a button at the top that toggles between Instance and Type. This way the palete will remain in the previously selected state, Instance or Type, to help reduce clicks for repetitive work.
Posted by: Chad | March 22, 2009 at 09:24 PM
"One of our design goals was to embrace the new UI rather than try to keep legacy elements around."
So why was the Options Bar kept and not completely absorbed into the Ribbon, thus providing some more precious workspace?
Other Autodesk applications such as Design Review do a good job of putting Options into the Ribbon.
The current implementation feels like a half done job of moving some of the options into the Ribbon, but you didn't quite get all the way there with the remaining ones. It's become a bit harder to decide where to look if your an existing user.
Posted by: Chad | March 22, 2009 at 09:29 PM
The 2009 option bar is more complicated than it seems. There are editor options, element properties, and contextual commands some of which are shared and all of which are called programmatically. Any one instance can be made of several underlying components. Design Review lacks this complexity yet it is good you find their approach effective. Revit 2010 accomplished movement towards our goal by moving commands to the ribbon CT tabs where in many evaluations customers discovered some they missed before. More to come later.
Posted by: Tom Vollaro | March 23, 2009 at 10:15 AM
I think I understand by what you mean by shared components, i.e. the 'Copy' toggle is used by say Mirror, Move and Rotate.
But how are these any different from some contextual Commands like the Arrange commands (Bring Forward, Send to Back) for Filled/Masking Regions and Images which were on the Options Bar, but are now on the Ribbon?
It stands to reason that if customers were missing commands which have been relocated to the Ribbon, then they were also missing the Options? How can you miss some and not others when they are right there side-by-side?
So why were the Commands considered more important to get onto the Ribbon, but not the Options?
With so few Options now left on the Options Bar, it seems like a waste of valuable project workspace leaving it there.
Are there plans to eventually phase the Options Bar out, but it was just a matter of not enough time to do so with this release.?If so, that would be a totally acceptable answer.
Posted by: Chad | March 24, 2009 at 12:58 AM
I apologize for seeming evasive in answering this question. It comes down to rules that we cannot talk about future features or direction. It involves lawyers and strict procedure around the fact we are a public company. Analysts might take a statement as direction or promise and this would be an issue later if something does not occur for any number of reasons. The FAQ was posted to try to make these restrictions clear. Perhaps we can work together in the future under an NDA. : )
Posted by: Tom Vollaro | March 24, 2009 at 09:26 AM
Is there any possibility to consider eliminating the option bar, and adding those options as a hovering window beside the selected object, much in the same way Office 2007 does. The option bar is smaller, but it still takes up a lot of horizontal real estate for very few options.
Posted by: Robert Mejia | April 20, 2009 at 01:52 PM
I think the claims of increased drawing are with 2010 are exagerated and need to come with quite a few disclaimers. Just looking at my screen, I didn't think that the drawing areas were all that different in size. So I pulled up both 2010 and 2009. Did a couple of screen captures and did a little overlay in Photoshop. (Actually I use CorelPaint because it reports the X, Y size of an object allowing for acurate calculations. I saved the file in photoshop so others could verify this.)
First Autodesk does their calculations at 1280 x 1024, because that's what we're all using yes? My screen happens to be 1680x1050 - a pretty basic LCD these days. Even a Dell 17" XPS laptop runs at 1440px. 1440px is also the lowest resolution you can even buy for a desktop LCD at Dell and they are all 16:9 ratio. So I would question Autodesk's starting asumptions.
I set the project browser to both the same width so there would be pretty much an apples to apples for that. The browser on 2009 comes up much thiner than in 2010 for me - so I'm tossing the advantage to 2010 here. I also didn't deduct the controls in the screen area of 2010. Again - advantage 2010. Finally I expanded the desgn bar so that any text on any design tool would be visible. This is not the default width - so again - the advantage goes to 2010
The white space size in 2010 is 1451x777. Or 1127427 sq.px. The white space size in 2009 is 1310x873 or 1096470 sq. px. That's a difference of only 30957 or 2.8% increase - half the advertised increase of 6% Autodesk is touting.
Lets do another test - OTB configurations. This is what Autodesk should be using for the test, right? 2010 numbers above were OTB. For 2009 the numbers are 1399x833 or 1165367 sq. px. That is 37940sq. px LARGER than the 2010 using OTB configurations. 3.3% more white area for 2009 than for 2010! And remember - I'm not deducting anything for the window controls which have moved to the drawing area in 2010.
So while Autodesk may be right for a 1280 configuration - I haven't checked as I don't know where to get a 1280x1024 to check - for a more normal 16:9 desktop system - The results are quite contrary.
Posted by: Aaron Rumple | April 23, 2009 at 12:18 PM