I am at the same spot right now. My opinion is there should be almost no families in the template so you don't have to reload them every time you make a change. The way I am doing this is by using Kiwi's Family Browser

Depends somewhat on your particular situation. Are you supporting many users/projects with the template, or just yourself?
I would say that if your templates are used on more than 2 or 3 projects, it would save more time to have the content in the template rather than having to reload everything over and over again in each project. The performance hit for having larger templates is negligable compared to the time spent loading the families on each project. Using the something like the family browser can help, but all in all, I still think beefier templates are the way to go in a larger production environment.

Personally, I've preloaded our template with a "core set" of families so people can get started ASAP.

But I guess it depends on what families we're talking about.

Annotation families, (elevation/level/callout-heads, view types, etc) are a clean "default" inclusion - as they really should only be updated on drawing standard overhauls (or company content/appearance rebranding) - and these can be saved from accidental "Purge" if you place an instance of each type in a legend view.

Beyond that, it really is a case of how much content do people really need to hand. I'd be surprised if it's as many as 150.

What you've got to remember is that loading multiple families at once isn't that difficult - and tools like the Kiwi Browser have certainly made it even easier.

Then there's keeping your usual suspects in a company "catalogue" model for en-mass copy&paste acquisition by other models. We do that for system families at present, (one model for each, sometimes using Transfer Project Standards to grab the lot, some done one by one) - but the same method could easily be applied to loaded families like furniture, light fixtures etc.

That way then your template will stay fairly light - but I've certainly found starting the "TYPES" phase work in the template is the only way to get people to appreciate it's functionality, and that's where our first (default) set of windows, doors and such all live, save from purge, and ready to be expanded upon, from the very off.

I wouldn't preload them into your template. For several reasons:

1. You might use all FAMILIES from time to time in any given project. But what about TYPES?
2. The overall lag of having a heavy template due to families which exist in them is nowhere near worth the time you save from loading them.

Instead, I too, would recommend you implement a very user-friendly Family Browser, like Kiwi. You can create custom groups with that (correct me if I'm wrong here) and order your Most Wanted Families to be one click and drag away there.

Well the consensus is pretty much in favor on keeping a slim template. That actually surprises me, but I can see your points. I just get tired of loading the same old families and thought i could save a little time.

Thanks for all of the advice.

steve

for me no families preloaded and use Kiwicodes Family Browser exclusively. The template is as lite as I can get it. With the huge amount of Window types and styles and sizes ie- for timber clad walls, brick veneer walls (with sills) there is no such thing as just having a basic set preloaded, and using Family Browser for windows (and doors) which have Type Catalogues is a breeze and all right there at your cursor.

To be clear, our "starter" families are as basic (and light) as they come. As in a window is effectively just the rough width*rough height opening, and doors are pretty much the same, but with their swing family loaded for plan use.

Why? Because we like to work up our architecture from the ground up - and prefer to hold off being prescriptive (in the first) that a window "looks like, and is built like, this" and "that door will be panel/frame/ironmongery type X" until other (later) factors are ready to be considered.


(I appreciate though this is a somewhat peculier workflow, but it suits our core contract types well)

I use CW's for that purpose. More freedom in form and shape. But that's just me...

I tried that once, but found it a pig since you essentially you have to start over when you are ready to fix things down, even a little, whereas with basic (correct category) placeholders you can directly "upgrade" the elements with families of a higher LOD when necessary.