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.ph...dards+Document

HOK but the link is no longer valid.

-K-

[patricks]

http://forums.augi.com/showthread.ph...dards+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