My Kingdom for a Dimension...or Two...Three

A Friday thought...

I've spent the last couple years doing a lot more modelling work than I expected to do. If you asked me in years before I'd have told you 80-90% percent of my time was dedicated to training and implementation activities.

Much of the modelling I do these days is from the contractor's point of view, for them. I quite enjoy it. I learn a lot and it keeps me on my toes.

This work is requested often because the documents they are using are not created from models to begin with. Sometimes they are but they (the contractor) have to build based on drawings so they find it informative to attempt to build things in the computer before doing it in the field. Where have I heard that notion before?

Chief among the things that trouble me doing so is the lack of dimensions. If there are lots of dimensions then the issue is their message or rather the lack of clear intent.

All too often I find a slab edge plan is lacking that one dimension, between adjacent slabs for example, that I could really use. In other instances the decision to start plotting the dimensions is based on a datum that involves a fussy site related angle (like based on a property line); when other orthogonal options are available.

I've also seen far more effort and devotion applied to dimensions for parking stripes in a parking garage than for the structural elements that make it possible to paint those stripes eventually. Then you have the dimension value bust. Such as, setting out the building grids reveals a subtle mathematical inconsistency or outright typographical error or override.

Then there are the dimensions that describe how to place something relative to other elements that get installed later during construction. How do we place a concrete column by referencing interior partitions...when those dimensions don't relate back to grids or structural elements? That issue is both missing dimensions and logical progression.

Often I have to endure the game of look over there, as if a hockey puck is getting smacked back and forth, when one says look at those guy's drawing for more information and then the other says the reverse. Slab edges that are required to overlap (per nearly matching details) are a real chore to sort out when you have to flip back and forth constantly and double check against the reflected ceiling plans...oops they're inconsistent with the plans...note to generate an email...

Then there are arcs. Thanks for all the radius and diameter information. Could I get dimensions for their endpoint locations and chord height/width? Better still, could I get something that tells me where their origins are supposed to be? Yes I do realize that one or two might be located somewhere on the outskirts of town. Then again if doing so exposes that issue up front when they are sketched, maybe we could get some other localized notion of how to place them on site too?

Though I've rarely encountered it in real life, I've really learned to appreciate the my documents stand on their own philosophy. In other words, a structural set of documents could be used in isolation to build all the the structural elements required, correctly, even if the rest of the work never got funded. It IS harder to do because it requires concerted effort to coordinate the disciplines well.

Yes I know, it's complicated, building stuff is messy. Now that I mention it, have you noticed, like me, that those ugly fractions people don't like seeing on drawings still crop up everywhere in real life.

Ah well, enough complaining. I've got some slab edges to reconcile. Back to grumbling to myself again. May we all enjoy a dimensionally accurate weekend!

Worksharing - Loading Content

I read Jason's post this morning and he describes a classic worksharing gotcha. Unfortunately he hasn't identified the true culprit. I'm referring to this part of his post specifically.

One of our most notorious examples is the infamous Break Line. Each drafting view we imported had a copy of the break line family. By the time anyone noticed, the project model had “Break Line (1)” through “Break Line (22)”.

What he describes is the result of worksharing and multiple users loading the same family in their own local files. Revit sees multiple versions of the same file being loaded from different local files (users) and seeks to protect them by renaming the other versions it encounters. We see this sort of message when it happens.

This error and situation is easy to replicate.

• Two users open local files for the same project
• Each user loads a new family and the same type
• Each uses Synchronize with Central (SwC)

The first person to sync will be successful without an issue but the second person will receive a warning about the family being renamed. If this is repeated enough, and by enough users at the same time, we could end up with family22 like he described.

For example, if eight people all introduce the same new family to the project then by the time the last person uses SwC there will be eight versions of this family listed in the Project Browser. This is what the Project Browser looks like after just two users think they both need to load a new double door and type.

Jason's post is focused on cleaning up after oneself and it IS important but it is also important to manage the loading of content and harvested details. It is equally important that people understand why these extra versions show up in the first place. Each time someone uses Load Family or Insert from File they must reconcile the warnings that appear before anyone has a chance to begin using the wrong version of the families that are duplicated.

I think it is worth restating that the subtlety of this issue is that this only happens when more than one user is introducing the same new family to the project (via their Local Files).

Once the family is part of the project (defined in the Central File) Revit doesn't get confused anymore. Here's what happens when I introduce the Break Line family he mentioned to the project via two users. Keep in mind that there is no Break Line family defined in the Central File at the moment. Each user loads the family, into their Local File, unaware the other user is doing it too. The first person to use SwC is fine but the second user sees this message (I expanded the warning to see the family description).

When the first user uses Reload Latest or SwC they'll both be able to see this in the Project Browser, listed beneath Detail Items.

Subtlety compounded with yet another subtlety...if the family is already defined in the project (Central File) but a new TYPE is loaded by more than one user then we end up with this situation in the Project Browser.

How do we avoid this situation?

As soon as we think we need to load a new family or type...STOP.

Who (on our team) is responsible for ensuring the content we need is available to us? There ISN'T any ONE person assigned to this? There should be. All new content should be requested, requests sent to or asked of this person. That person can delegate the task.

The goal is to avoid the situation where more than one user is loading the same new content.

Only ONE person needs to load the family(ies)/type(s) and then use SwC to make it available to everyone else on the team (they use Reload Latest). We are working on the same project after all.

To close and return to what inspired my post, Jason went on to write that they've abandoned using Detail Components in their details because of this issue. Tragic. They (the detail families) aren't the problem; Revit's worksharing behavior and user habits are. I hope he'll revisit that decision.

Preserving the Active Workset

The Active Workset is a user setting. We can each work using a different Active Workset.

However there is a circumstance where I can affect what the Active Workset is for others.

When I Synchronize with Central (SwC) my Active Workset will be the one any user that OPENS the project afterward will see. That is true until another user uses SwC. Then anyone who creates their local file after them will inherit their Active Workset...and around the bush we go.

It's important to remember to check the Active Workset as soon as your Local File opens.

Keep in mind that other users that are already working in the file will not see a change, their own preference will remain the same. It affects anyone who creates their local file later.

We can agree as a team to always use SwC with a specific Active Workset in play. I can't really expect that to happen every time if I have difficulty remembering to set the Active Workset correctly for my own purposes. I just try hard to remember to check the Active Workset setting before creating any new elements AND especially as soon as I get my Local File open.

We can also remember to take advantage of the Gray Inactive Worksets feature (see image above) to help make it more obvious that we aren't using the correct Active Workset.

Family Thumbnail View

One little thing you can do to improve the user experience when choosing and loading a family is to prepare the thumbnail view nicely. Revit will use the view that is open (has focus) when you save and close the file to generate the preview we see in the Open Family dialog or in Window's Explorer. Here's an example of a preview for a family in the stock pipe fittings folder.

I really can't tell what it is at all. The connector graphics are making it impossible for me to tell what sort of fitting I'll get when it is loaded. Here's how it looks after I tweak it a bit. Now it is a lot easier to tell what it is.

Most of the stock Revit content already has a 3D view called View 1. If I make a family from scratch I create one too. I make sure I open this view and close others before Saving and Closing the file when I'm done working on it. I caution users to be wary of content that does not have a clean preview, at least if they are using anything I've made. Messy means not done or not ready. Ideally content that isn't ready shouldn't be in a live folder at all but sometimes we get distracted and our own rules or habits aren't followed.

To clean up a family's preview:

• Use Temporary Hide/Isolate to control what is visible in the view.
• Use Thin Lines. (I hide host walls and faces for example)
• Use Detail Level setting to show off the family.
• Use Zoom Region to maximize the important geometry we see in the preview.

It's all meant to make it easier to understand what the family is and decide if it is the one they really want.

If you examine the stock door folder you'll see that most of the families have been oriented so that View 1 is a Front or Back elevation so you can see the panel design head on. I usually prefer a 3D axon orientation because it can give me a better sense of the frame and other proportions. Try to pick an orientation that best describes the family from the user's perspective, whatever will help them decide that this family is the correct family to load.

A cool feature of KiwiCodes Family Browser is that you can use your own custom Thumbnail images. This means you can set your custom library up in a project setting and take advantage of Graphic Styles like shadows and ambient shadows. This image is a sample of Aaron Maller's handiwork for Beck Group. His thumbnails include context and it really helps to understand what the family is, what features it has. He's put more effort into this than anyone I know of so far and I really like it.

It's the little things in life, every little bit helps the end user experience.