Revit Standards Document

[krista.manna]

I was wondering if anyone had an opinion about revit standards documents (aka here's what to name your views, here's what the name the file & where, etc.). If your firm does have a similar document, what kind of information does it include. I'm curious as to what other firms out there are doing.

-K-

[cganiere]

Generally we name the views based on what they represent. Administration Plan. Section @ Multi-Purpose Room, East Elevation. Views that go on sheets are all named in CAPS. Working views are named in lowercase and given a suffix of the person that created them.
Our Revit Teams are small enough that we haven't published a "Standards" document. And since we aren't hiring right now...


I was wondering if anyone had an opinion about revit standards documents (aka here's what to name your views, here's what the name the file & where, etc.). If your firm does have a similar document, what kind of information does it include. I'm curious as to what other firms out there are doing.

-K-

[patricks]

There have been a few threads about this, including a link to one firm's (SOM maybe?) standards. Try searching for it.

[saeborne]

I would argue that your revit standards document should include guidelines for naming Component Families.

When you're looking through the type selector, wouldn't it be great all of the light fixtures were organized together?

As opposed to some under "D" for downlight, or "F" for fluorescent, or "I" for incandescent.

This is probably not exciting to set up, but it will save MANY headaches in the future.

Bryan

[krista.manna]

http://forums.augi.com/showthread.php?t=78692&highlight=Standards+Document

HOK but the link is no longer valid.

-K-

[patricks]

http://forums.augi.com/showthread.php?t=78692&highlight=Standards+Document

HOK but the link is no longer valid.

-K-

look at the last post in that thread. ;)

[krista.manna]

This is not the type of standard that I'm referring to. What I'm referring to is a standard document that lays out for example what to name views in model, what families should be called, etc. Basically, a company guideline for best practices to make using revit organized. When you have many different people naming things they're own convention things can get a bit out of control. What I'm looking for is what people have or would include in a document or documents that include standards for these.

And the link only goes to the NBIMS docment not an HOK document as far as I can tell. Unless the HOK document is the NBIMS document.

-K-

[twiceroadsfool]

AFAIK most firms are making their own.

We have naming conventions for Models, Families, Detail Components, Walls, Views, and Worksets, so far.

They take some getting used to, because the names are pretty long. They are based on conventions that start with general catagories and increase in specificity, all defined as such for a reason.

Views, so they sort accordingly making it easier to apply View templates across the board, and so you know what that view is tied to (is it a linked view in another model, is it in the doc set, is it a working view). Families so they sort intelligently in the component drop down, and so you know all the pertinent information (is it hosted, is it flexible, is it generic content or specific content), models so you have all pertinent information before you opened the model (Trade, revit version, and are worksets enabled).

The names are long, but once users get used to them they go stark raving mad when they get in a project from before these conventions. :)

[cporter.207875]

Here is a list of some of the things that we are doing.
Some items have already been listed above.

1. Step-by-step instructions on project set-up
2. Rules for worksharing
3. File maintenance procedures and intervals,
4. Guidelines for family creation and review
5. File sharing/coordination "rules of thumb"
6. File naming standards
7. Revit Family Library
8. View Naming standards
9. Trouble-shooting tips & tricks
10. Common terms and definitions (more information)
11. Project templates
12. View templates

I am still putting all these things together, but everything (except library) will eventually be hosted on the company intranet with multiple embedded links that take you to visual aids, related sections, and outside resources. Taking me a long time to build, but I think it will be worth it in the end.

Downside: I have to redo a lot of these things with 2010; probably true with each new release after that.

[dbaldacchino]

Your goal is not to write an encyclopaedia, but to help users with their FAQs. Keep an eye on what questions you find yourself answering day in and day out: those are the perfect topics. Procedures that pertain to your firm are the most important probably. Naming conventions are also important, especially family naming. Personally I don't think view naming is that crucial, although some guidelines would be valueable (I know, aaronrumple would strongly disagree! But that depends on if you use view names for sorting in the project browserr or for automation of some sort). Focus also on how to handle revisions, etc. And keep it short and sweet. Focus more on one-on-one mentoring instead writing long documents that will gather the proverbial dust. That's my personal opinion :)

[krista.manna]

I agree with this in that I don’t think we should dictate/restrict too much because then people will feel hindered by the standards instead of the standards helping make things easier. But at the same time I think we should set up rules of thumb for people to use to make it 1) easier for them to use and 2) easier for me to troubleshoot.

Thanks everyone for you comments. I wanted to get a feel for what everyone else is doing to decide what to do.

-K-

[twiceroadsfool]

Well, i disagree about "not restricting too much."

I think ANYTHING regarding naming just about anything and everything in the model needs to be done strictly with a standard, and with good reason.

Ever try to apply a view template to a particular scale or type of elevation, when the project is almost out the door? You have to do it in the view sorted portion of the browser, so youvegot to pick and choose through apphabetized elevation names.

Content naming- Door shouldnt be next to desk. If left to their own devices, you get all sorts of fun things: Users initials as suffixes, office initials as prefixes, job numbers as prefixes... Ever see a component list with all three? Since its alphabetical (read: stupid), a good regimented naming strategy is all that keeps people efficient here.

Naming models and worksets: Here are a few things im tired of hearing people waste time on: "Do i need a local copy?" "Oh, its worksetted? So i shouldnt be in the file?" "What do you mean the print looks wrong, which worksets was i supposed to load?" "Which workset is that Linked Model supposed to be on?" All time wasters, and they always have different answers, unless there is a good standard.

Walls. Oh my. This is what i hate seeing

Walls - Ext- 4-7/8" Metal Stud Partition
Walls - Exterior - 4-7/8" Metal Stud Partition
Walls - Exterior - 4-7/8" Metal Stud Partition2
Walls - 4.875- mtl std and gyp both sides

All of that for ONE type of wall. And i cant blame people, because who can definitively say from that list, whats REALLY going on. It could be a metal stud with two layers of gyp on one side, and three of the four names wouldnt tell you. Plus, if everyones not doing it the same way, the sorting (again) goes to hell.

Im not saying standard conventions are the end all be all, but as long as revits default methodology for sorting almost everything is going to be alphabetical...