Revit Best Practices (RBP) - View Naming

[aaronrumple]

...we just started issuing full sheets only. We had issues in AutoCAD as well and it was simpler just to always send out any changes as a revised full sheet.

[dbaldacchino]

Agree with that 100%, especially after talking to contractors and they ALSO say we're nuts for issuing itsty-bitsy 8 1/2 x 11 sheets. Yet, there's a huge cultural barrier....."Oh, how am I gonna explain that to the client? They'll think we screwed up big time if I'm issuing full size sheets!". That was an excerpt from a real conversation with a PM (or 2 or 3...). Oh, another one...."The sub only has a fax machine if at all, so we have to cater for the lowest common denominator".

[stuntmonkee]

Everyone is really getting into this even if we are quibbling over sheets as being views! I believe they are but that is just my opinion. That is why I thought this topic might take more than a week.

As Aaon's browser shows, most all view categories can be easily organized since you can have multiple types for each, but plans and reflected ceiling plans don't allow that. That would sure be nice for those plan sheets also.

Could we say there are basically two ways to organize views? One way is using no extra parameters and the other is using them? We also seem to be able to agree that everyone but those in my first post use the "View Name" and the "Title on Sheet" built-in parameters and not just the "View Name".

If we can agree on those could we take those two paths and come up with some standards for how to approach each? Aaron's approach seems good for the first one and we have some for the second but it would be nice if the best practice was consistent for all view types. Are there any other naming conventions using Aaron's approach that work well?

What are people's thoughts? Can we agree on those few things above?

Kevin

I would agree with that.

But if I may still jump in, I have a few thoughts.

My first approach is to keep things as simple as needed. It really works 2 full. 1, you don't have people trying to get it to work like CAD, and 2, when people come in and learn Revit for the first time there is less to throw at them.

Now I understand that there are things you can do with Revit that are very helpful, and I implement that to the best knowledge that I have. Anything that I can have run behind the scenes that may or may not be complicated and in-depth for me, I will do. But this is a real issue of "Front User Working Knowledge". So whatever I can do to keep that as simple for then as possible, that's my approach. My next step in that approach is teaching project sense. Revit as a whole has made it much more difficult for the "slower" drafter to be involved. So I really push cleanliness and forethought. Most of my guys own their projects, so they know that if they don't make their bed, its still theirs to sleep in.

As far as view naming is concerned :

Most of our projects are medium to small. So really the need for a complex naming system is just wasted effort. We name our views with standard info that you may or may not find in a set of drawings. Floor Plan Level 1, Floor Plan Level 2 and so on. With details, we use real names, and if its a TYP details, we add that in the front of the name. Sections and wall sections is where things get a little squirrely, and while the view name is "Section 1, Section 2", we will sometimes add in the grid line location, and either keep that the name, or we will change the sheet name.

Again, since we are single users more often than not, if a project leader finds that a naming convention or even just a view name needs to be adjusted to improve their workflow, then that's fine. We don't allow personal names. . "Jeffs Fancy Light" or something like that. But in each job you may need to create diff naming conventions to better suit that particular job. That not only helps the drafter/manager work better, it can help with the out put at the end as well. But the best feature off allowing thoughts like these, are that it gets that individual involved and improves their thinking process. When it comes to crunch time, they will find out if they screwed up or not, and they will have a sense of ownership over it.

Now don't get me wrong. . .its not a free for all. But the beauty of Revit is that I can control all the things that are important definites. Line weights, fonts, borders, sheet numbers, schedule appearance and tag appearance. . . .families used, fill patterns. All that old stuff we hated having to fix as CAD Managers.

I applaud some of the ways you are using parameters to control view names, and using diff naming conventions to not have to use parameters. In large projects, I can see it as a must. 100's of views would be cumbersome even in the best system. But for some of us I would add a third idea to the 2 you have listed. And that is to teach the users to understand how view naming can work for them and against them, so that they can better adjust things on the fly to work better for their projects. Simply showing them the ability to hide all views placed on a sheet is huge when you need to make sure you aren't missing a view you have created, or a sheet you forgot to set up. But I would bet that a good percentage of new to medium users don't even know its there.

Thinking. . .its the toughest skill to learn sometimes, and one of the most frustrating to get people to rely on.


BTW, kick a s s idea for these threads.

[Kevin Janik]

Anything that I can have run behind the scenes that may or may not be complicated and in-depth for me, I will do. But this is a real issue of "Front User Working Knowledge". So whatever I can do to keep that as simple for then as possible, that's my approach. My next step in that approach is teaching project sense. Revit as a whole has made it much more difficult for the "slower" drafter to be involved. So I really push cleanliness and forethought. Most of my guys own their projects, so they know that if they don't make their bed, its still theirs to sleep in.

I applaud some of the ways you are using parameters to control view names, and using diff naming conventions to not have to use parameters. In large projects, I can see it as a must. 100's of views would be cumbersome even in the best system. But for some of us I would add a third idea to the 2 you have listed. And that is to teach the users to understand how view naming can work for them and against them, so that they can better adjust things on the fly to work better for their projects. Simply showing them the ability to hide all views placed on a sheet is huge when you need to make sure you aren't missing a view you have created, or a sheet you forgot to set up. But I would bet that a good percentage of new to medium users don't even know its there.

Thinking. . .its the toughest skill to learn sometimes, and one of the most frustrating to get people to rely on.

BTW, kick a s s idea for these threads.

It sure is not too late to give input. Your comments on thinking as well as just knowing what is capable already in Revit are spot on!

Most of our jobs are going to be two to three person teams or larger. I am starting to agree more with the non added parameter crowd but using Revit with all its capabilities to make things sing is my desire yet user ability to use and work with it really is a problem especially with newer people. (I am also in that boat by the way.) I am a tinkerer and one who likes to figure things out like a programmer, but most people are not that way.

Could you and others post an image of your browser expanded? Seeing it helps people understand what can be done and the overall organization people are using. If I see it and like it, then I can always figure out how to do it since I know it can be done. The end product of this thread would benefit from graphic examples of what people work with more than a bunch of text trying to explain it over many pages. We can even cut and paste pieces together to create hybrid models of what to do.

What do other people think?

Thanks also for your nice comment at the end. Please continue with giving input. That is how this will be valuable for everyone.

Kevin

[dbaldacchino]

Kevin, in your template you can add a view sorting parameter and then users can decide to either use it or not since they can change the browser organization. If the team decides to use a certain naming convention and do away with parameters, then you use a browser organization that doesn't sort & group with that parameter. It only takes a few clicks to set that up.

[ecoley]

we use view names to organize our project browser, along with built in functionality of the software. we organize our browser like this:
family and type
associated level
sort by view name

I have this built into the template.

this removes the necessity to include the building level in view names. i tend to encourage descriptive view names. to me it is more important that someone at my office can open up the project a year later during CA and find information, than having a compact project browser.

we prefix our view names with an indicator for what the view will be used for:
P - is a "presentation" or "printed" view meant to go on a sheet.
working - is a view for modeling purposes only
Callout - a callout view
PD - plan detail

We have Working Elevation and Working Section view types.

I find that sections and elevations are organized easily just using the view family and type. Building Elevations, Interior Elevations, and Working Elevations break themselves out in the browser automatically.

Drafting Views can become more of a mess... I haven't decided on the best way to organize those yet. I use descriptive names in full english for these right now.

Some of the solutions here with multiple levels of abbreviation would fail at my firm I would personally have no problem using them, though.

[Kevin Janik]

Could you post a browser image so we can see how it looks and works. It people see it, it might help in seeing the ease of its use.

Thanks!

Kevin

[ecoley]

I attached a view of a project browser for one of my projects.

You'll notice a lot of views named "ACC -" in this one. Those were views that we had to update over and over... and over (not bitter, at all... really) for an Architectural Control Committee.

Sometimes I will append the level name on a view. The stair Callouts are an example. I will have a view named Callout - EAST STAIR at multiple levels. Since we can't have unique names, adding the level is logical.

My main goal with this system was to create an organization that is usable, but as bare-bones as possible. The people I work with just wouldn't use anything more elaborate, even though you could argue for a more efficient system. Using Revit's built-in parameters to filter gives me some easy control to implement.

Here is something you could add to your RBP for view names: NEVER put a drawing sheet/number in a view name. That is a great way to destroy some of the best functionality of a program like Revit! A lot of people try to do that, especially with drafting views. Give me the view a name that tells me what is in it.

[Kevin Janik]

One our last project we probably had 150 details thus 150 callout and or drafting views. We had a real hard time figuring out which was which without added some of the detail numbers. We notice we could make more than one callout type for details to segregate them in folders but how would you suggest doing that to make it easy to find. I am thinking at least put them together by sheet number they will be located on? They can end up being in two places as shown below. Is that an idea? See Below

Kevin

[Kevin Janik]

Is this the end of people's input? Just checking.

Kevin