CodeBook libraries have insighted much opinion and debate over the years, in this post I'll touch on some of the history, what is available now and what makes a good library in my opinion.
Back in my day...
When I first started using CodeBook in 2003, it came with a library database built on the ADB briefing system and an image library of microGDS or AutoCAD blocks. At the time we had 3 major projects running simultaneously in AutoCAD, with each of them using a different briefing system - ADB, Hiltron and Healthcare Environments (HCE). Once we started to develop our exemplar rooms, we soon realised that the 'out-of-the-box' CodeBook library didn't contain everything that we needed and we would need to create project specific content. Also some of the existing blocks, weren't drawn in the way we wanted and so also required some attention.
Naturally each of these projects had their own project database and library, their own set of exemplar room layouts and after drawing equipment and room layouts 3 separate times with only minor differences between them we thought - there has to be a better way! At first the questions were - why doesn't CodeBook provide a decent library? Why are the blocks drawn so badly? I'm sure that I asked Peter these questions quite directly and probably a bit rudely on several occasions.
To his credit and in his usual style Peter explained politely, calmly and succintly that each practice does things differently, each project has different requirements and that he could spend the rest of his life drawing content and still not make everyone happy. Shortly after this he created a new build for me, which added additional fields in the database for different briefing systems (cwfCode2, cwfCode3 and cwfCode4) and enabled us to have an ADB, Hiltron and HCE code neatly sat in parrallel with each other all linked to the same CAD graphic.
The issue of library content had still not gone away though and so myself and a colleague decided to tackle the issue head on and organised a meeting between ADB, Hiltron and HCE. Peter also attended along with a few other architects and service engineers. There was hot debate about industry standards, what wasn't being provided and the lack of content sharing between the various parties. Unfortunately, the differing commercial interests of each party meant that the idea never really gained traction, despite the good intentions.
So whilst being a little disheartened, we decided to consolidate the libraries from these 3 major projects into our very own practice library ready for whatever future project came up, regardless of the briefing system used. This was very powerful and we also picked out the best exemplar rooms from each project and made them into assemblies ready-to-go on the next project. We still felt there was something missing though, as we had lots of individual room data templates (design, finishes, m&e) and assemblies which, on a large project, were very difficult to coordinate and manage. Soon enough, we had another new CodeBook build to try out which introduced Room Types and combined all of these separate templates, plus more.
I learned some valuable lessons back then and working together with Peter, gave us great results. Fast forward to 2011, Revit and Australia and I find that I'm having similar conversations with people albeit several years later on the other side of the world.
So what is available now and what makes a good library?
The standard CodeBook libraries offer both UK and Australian room data sheet templates and provides an AutoCAD library that can be converted into Revit families or A.N.Other platform. There is also now quite a lot of free content available on-line in the form of sketchup models or Revit families. The more astute manufacturers are starting to understand the benefits of modelling their products in Revit and making them available to the industry. Manufacturers producing these aesthetically pleasing accurate families, with O&M manuals and other FM data are already standing themselves apart from their competitors.
There are also companies whose core business is building families and generally speaking these are available for a reasonable price, but you are licensing the right to use the family - not the IP or the exclusive use of it. Not a problem for many practices, but there is yet a further option for the more discerning Revit user - to outsource the creation of your very own custom built library to India or Asia, where you can specify your requirements and have your families built cheaper than you could do in your own studio.
But with all of the above, you need to understand what it is that you are loading into your models and using in your documentation. What is the right level of detail (LOD)? Are the families dimensionally correct? Do they comply with local regulation? The responsibility for this has to remain with the party producing the model or drawings in my opinion and not necessarily the person who produced the family.
Many people think that you can start a project with an "off the shelf library", that will not require any editing throughout the duration of the job. The reality is that you will always have project specific content and each client will want to see greater or lesser detail, descriptions, groupings or coding systems than you currently have. Personally speaking I think investing resources into creating a generic library and then resisting the temptation to make it bespoke for as long as possible is a sound strategy.
At my practice we have made this investment and are now starting to realise the benefits of this work, plus have avoided large volumes of work duplication. In addition, we are generating a series of generic rooms and room data sheets with the goal that each project uses this as a starting point and, through the design development stage, update these to suit specific project / client requirements.
The concept is really quite simple, start from a point of compliance and don't re-invent the wheel each time you start a new project - however - many practices struggle to understand the value of this 'non-project-specific' work, or comprehend sufficiently enough to fund it. This really makes it a strategic matter and if a practice is serious about BIM and Healthcare, they will need to invest money and resources which cost in the short term, but will provide efficiencies in the future.
In addition to creating families and room assemblies, we've also spent considerable time reviewing the data component, in that we have several coding systems sat in parallel, complete with group, class and numerous other properties. These equipment properties are mapped to a corresponding Revit Equipment Parameter, contained within a Shared Parameter file, so that we have continuity and achieve synergies across multiple projects and studios.
Content sharing has been a hot topic of debate and whilst I'm a supporter of the ideal, I'm still uncertain of how it would work in practice. For example, if we were to give our library to another practice, they could not utilize it in the same way that we do in a 'plug-and-play' fashion. Why? Because it is setup to work in our Revit environment and is based on the criteria that we selected. Most practices will have similar requirements, but the naming conventions we use, the coding, description, equipment parameters, revit schedules, views and other 'template' related items will differ and so other than providing a visual representation, using someone else's library has limited value.
To summarize, some of the main elements that make a good library are:
1. Compliance with local standards
2. The correct LOD - i.e. don't model the nuts & bolts, just the general form.
3. Flexibility
4. Equipment data, and last but by no means least
5. Guidance material
You can have the best library in the world, but if no-one knows what it contains or how to use it.....maybe that's why you're reading this blog now!
There are many other parts to this issue, parameter mapping, types & catalog files, reports, legends etc... which I'll cover in separate posts.
...aimed at educating, promoting good practice and demystifying the use of CodeBook within Architecture.
Good to find other people have mulled over the same issues and has come to similar conclusions. I have found too much detail and too specific an equipment databases is worse than not enough detail.
ReplyDeleteAlso think it is very time consuming to create (and certainly maintain) a good company standard library with the program currently.
Some things I have though about to ease the task of library creation management and standardisation:
1. Community led standard libraries, for the various sectors and countries. Not necessarily one company giving up their hard work, but a group actively perusing the same goal of a high quality but streamlined standard libraries to use and somewhat ease cross company working. However, how practical it is to set up such a group is debatable.
2. A change to codebook to allow you to set a standard equipment library and also a project equipment library. When looking up equipment Codebook would consult the project equipment library first for a matching definition. If found, it uses this equipment definition. If no definition is found, the standard library is consulted. This way if someone wants to change the description on your OUT010 for a specific project(shudder) it doesn't have the wide ranging consequences could have at the moment. Obviously this is no simple change but it would add flexibility and ease library management.
Some great food for thought here. I am in the process of trying to create an office standard library so it is useful to be able to learn from the experiences of others.
ReplyDeleteAlso Richard, I very much like the idea of having separate Standard and Project libraries!
Interesting point re the Standard and Project Libraries, but I'm wondering how this could be achieved in practice... the only way I think this could work is that you link to a standards library and each time you make a change you select whether you want to update the standards or project library. If it is just an update to the project library, then CodeBook copies the equipment block, family or GDL at that moment??
ReplyDeleteFirstly I think it would need to be an "optional" function of codebook and not the default behaviour so as to avoid confusing people who are not aware of the function or new to codebook.
ReplyDeleteOnce you have nominated to use a project library. I would think that changes would be made to the project library as default. To edit the standard library you would have to explicitly tell codebook that you want the object added/updated in the standard library via a check box, separate password prompt (or some similar means).
This could be complemented with a function to easily "promote" an equipment item from a project library to a standard library (although the library import utility allows this to be undertaken in a slightly unwieldy way) .
Our current work around to this situation is to keep a central library on the server and seed each project with a copy of the standard library. Any project specific equipment is reviewed at the end of a project (or relevant key stage) and imported back into the standard library if deemed of use on other projects. Its a very disk space and time heavy process. But it avoids equipment changing across multiple projects.
Richard, thanks for sharing you're ideas, clearly you have given this a lot of thought and have some good ideas for how this could work. I'll forward onto Peter although I know he's busy preparing for AU and finalizing v10. I've only had a brief play with the SQL server version and can't help thinking this may be the vehicle to enable this kind of change in library structure. It's high on my list to do list so will keep this in mind when testing
ReplyDelete