Tuesday, October 30, 2012

Not on Sheets

Let's imagine you've been working on your project for awhile now and your project browser seems a bit out of control. It's pretty likely it doesn't take all that much imagination.

How can you tell which views are properly assigned to sheets and which aren't? I read a post today that offers one solution using a View List, a schedule of views.

You can also use the Project Browser sorting features. All the stock Revit templates include a browser configuration called "not on sheets". It's got a filter looking for views that don't have a sheet name parameter assigned.

If that's true the view remains in the views portion of the project browser. Those that are assigned to sheets are hidden from view. If you are thinking you could do the reverse to see those views ON sheets, really no need. You can just review those by expanding the Sheets portion of the project browser instead.

In fact this segregation lends itself to the notion of using working and production views that I wrote about the other day.

If my role is documentation I can focus on the sheets part of the browser. If I put on my modeler hat then I can move up to the views part of the browser instead. The "not on sheets" browser configuration will strip out all those documentation views for me.

There is also nothing wrong with some naming conventions to help declare their purpose. I like to see user names in working views so we can chase down the person who needed it to see if we can safely remove it. I've met some who manage such things with a scheduled Monday purge of so called working views. Ever run across a project with 200 sections views, all un-referenced? Nah, I didn't think so, your project teams are far too organized and careful.

Many people also use more formal naming for production/sheet views compared with working views. Something like PLAN - OVERALL - FLOOR SIX sure looks more formal than Level 06. If you use the Title on Sheet parameter then it gets a bit harder perhaps. For those just the presence of Uppercase versus lower case can be a subtle clue to their intended use for the team.

A hat tip to a little browser organization!


Unknown said...

Love it! Thats actually one of the other methods I was eluding to! I'll link back here so folks can see a good alternative :) Thanks for expanding on the topic!

antman said...

Now, if we could let each user specify their own browser organization...

Revit.King said...

Steve, as always, great points!

Some caution should be used with the "Not On Sheets" configuration with regard to views that were "Duplicated as dependents". If I'm not mistaken, those views still show in the Browser and deleting them could be heartbreaking to a project (or project manager!)

Just a word of caution. Correct me if I am wrong. Thanks!

Steve said...

The reverse is true in my experience. If a view that has dependent views is assigned to a sheet, not only does that view not show up in the browser, when using the not on sheets configuration, but the dependent views also disappear from the browser. That makes it less fun to assign them to sheets. That is where the Add View to Sheet feature comes in handy.

DaveP said...

Came here to make the same comment antman did.
That's one complaint I have had about the Project Browser. One person changes it, and EVERYONE gets that configuration the next time they make a new Local.
I really wish Browser Organization was a per-user. Just like Worksets Open/Closed can be.

Bol said...

Well said. We have a simple rule: "Unreferenced views will be shot, ahem deleted" unless you put your name on it.

Dave Baldacchino said...

Technically Browser Organization is per user...or better, per Local File. I don't think the developers ever intended originally to have new local files created every day, which is what we do as part of best practices nowadays. But each local file can have a different setting and does not affect other users. This is why, when I was knee deep in production work, I mostly opened the same local file and religiously audited and compressed regularly (almost to the point of OCD). This way I could maintain my browser organization AND the active workset and not worry about those settings changing on me.

Mikey Stix said...

Dave Baldacchino, So you are saying that you open the same local copy of the central, everyday? I have 12 different users in my central file everyday. I instruct them to open a new local copy from central anytime they open the project, PERIOD. This is because the local copies will become so far out of sync with just one day of modeling from the other 11 users.