The main issue to me is that I can jack up a working view with hidden categories, goofy colors, whatever, and I don't break the printed set. In a single user environment this is less of an issue (no one is going to print not realizing the set isn't ready), but even then remembering what I changed (maybe weeks ago) in a view and making sure to change it back is a pain. "Sheeted view is sacred" is a pattern I follow no matter what.
I also believe in coordination views, export views and management views that don't change, so perhaps borderline excessive. But as long as they aren't open, a metric crap ton of usable views don't really weigh down a project, and offer a lot of convenient consistency.

Gordon

Hi Dave,
We use the working view more on files that have multiple users involved. It helps to erase the problem of people turning on / off items when they are working in the view and forgetting to put it back the way it was and in this process effecting the final plot.
If each user has a working view, they can have it display as they need when working without effecting the plot sheets.
This can be used for single users as well.

Also important for projects with linked consultant models, once you setup how you want the consultant model to look for printing, you will often need to adjust the link display during co-ordination. With a separate set of working plans, you can make sure your print plans are not affected by temporary adjustments to the VG overrides for revit links, this becomes even more important when multiple users are involved

I have also heard them called modelling plans, it is just important for people to remember that they need to annotate in the print plans

Hi Dave,

I'm all by myself (when it comes to working that is), but I have always used working views for the following reasons:

-constraints. I can leave constrained dimensions sitting in view so I can always see where constraints are put. No need to worry on how it looks on sheet.
- categories on/off. I often deselect categories that need printing, simply because it's easier modelling. For instance furniture in a plan view. No need to check if everything is "on" when I print.
- Review items. I once posted a review family consisting of a simple block with shared text parameters in the Nurse Call Devise-Category. This is only on in my workviews, the category is off by default in all printing views (luckily I'm not in the healthcare-business!).
- I don't have those irritating tags/text/etc floating around my workview where I don't need/want to see them.
- I often use filters and colors to check the model if it complies to design criteria. For instance different kind of wall colors for different finish layers, etc. It's easier to check but I don't want them printed (unless off course when I need to consult the principal in which case I would create extra printviews)

Granted: a lot of this stuff only comes into play when you have to revise your work regularly. If your workflow really is Model-Annotate-Revise-Print-End of story, well then maybe you don't need this. But it's often Model-Add-Revise-Print-MORE REVISIONS-End of story. Work-/printviews are primarily useful in the second round of revisions (and all after that)

thanks all for the great input! I use a lot of linked Architectural models and have run into having to turn stuff on and off as I work in the views then have to go to printing the views. It seems much better workflow to have separate printing views in this case.

Next question would be: how is this handled in Project Browser organization?

Create a new Txt parameter (ie browser_org, folder etc.) in the Views Category, make a new Browser Organisation sorting on that Text parameter (and on Family&Type if that's what you prefer.)

Then whatever input you give in the Text parameter will create a new header in the PB.

I know how to set up custom Browser organization. My question probably should have been: what is your naming convention for working vs printing views and how do you sort them?

Hi Dave,
We normally just place the initials of the user behind the view name. Ie. Ground Floor Plan_ET
This way it keeps them grouped in thhe browser.

We simply use "Working" "Print" "Export" and "Info" Then use the above mentioned added project parameter to sort in the borwser.