Efficient Navigation with Kiwi Codes
In my role as BIM manager The Beck Group, I am responsible for firm-wide Revit implementation. We have deployed the Kiwi Codes Family Browser (Kiwi Codes Solutions, Ltd.) as our standard content navigator and browser. The Family Browser, an add-in for the Autodesk® Revit® Platform, allows for a tabbed browsing experience of our office’s content library. It runs in a modeless window, so it can remain on a second screen even when you are not using it. In addition, it features auto-hide capability. It has a look and feel very similar to the Autodesk® Design Palettes, for those familiar with, or migrating from, AutoCAD® or AutoCAD® Architecture.
How It Works
Content navigation has emerged as a critical issue for successful BIM implementation, and that has led to a number of tools and solutions coming around in the marketplace. A large part of our decision to go with the Kiwi Codes Family Browser was due to the simplistic nature of the setup and user experience, compared with some of the more complex add-ons available. The Family Browser (“the FB” as we call it) provides you with tabbed “Palettes,” each of which correspond to a folder in your content directory. The tabs in the FB are controlled through a series of .txt files, which list out the folders to populate each “Tab Group” of the FB with.
This makes navigation immensely more efficient, since each “Tab Group” can have different combinations of tabs. This leaves actual organization up to the BIM Manager or user. At The Beck Group, we keep groups set up by building location: Shell, Interiors, Furniture, Healthcare EQ, Plumbing, Lighting, Furniture, Structure, and, of course, Detailing, for our Detail Component Library. As an example, opening up the Structure Group shows three tabs: Columns, Framing, and Foundations.
The FB references both the text files and the directories live, allowing us to populate changes throughout the office immediately: The moment I add a new piece of content to a directory, it appears on everyone’s FB the moment they refresh the tab (switching tabs refreshes them). This makes disseminating knowledge of new content in the library effortless: It shows up right next to content they are familiar with, on the browser.
In addition, FB lets you create custom icons (at custom sizes) for each piece of content. We do this in the project environment, eliminating the issues of “sideways previews” that came about with face-based and hosted content. You can also show them in context in the preview.
FB has support for Type Cataloged Families as well: Flyouts will show the types from the TC, allowing you to load a single type in to a project at a time, bypassing the Type Catalog Prompt that comes up from the standard Load Family dialogue.
The user interface is a single (simple) window, set to auto-hide or remain persistent. Clicking on the tabs moves to a new series of families instantly. Search functionality exists right on the UI, and typing in the search box searches all tabs, looking for the search string in the Families File Names. Admittedly, some people desire searching by more metadata than the file name, but I haven’t had the need.
Currently we employ a family naming strategy that includes: Category Abbreviation, Item Classification (subcategory, if you will), Manufacturer, Model Number (Or Beck Type Mark Classification), and hosting type. The naming convention stemmed from pre-FB days, when the component button (the only option) was purely alphabetical. Searching for metadata may be more critical for MEP firms, but I have not had enough desire for it to even ask for its inclusion.
How It Helps
The Beck Group has several hundred Revit users, spread out amongst five main offices, several smaller offices, and many job sites with users running mobile workstations. Content distribution, education, and navigation was a big challenge, as was finding a way to keep all of the users as current as possible. The Family Browser, combined with some simple windows functionality, allowed us achieve this in short order.
The Main Offices
For the offices using a Distributed File solution across a WAN, things may be simpler. For now, we don’t have one employed, so all our users are “based” out of one of five main offices. Our entire content directory is synchronized from our home office, to the other locations, nightly. In addition, text files for all five main offices exist in the content directory. Making updates to them is a simple “find and replace” for each office’s directory name, making changes to the FB happen in all five offices in scant minutes. (We create yearly Revit libraries for each release. Writing all of the text files for all five office’s 2013 libraries was less than fifteen minutes of work.)
The Workstations
The majority of our users are on the go, constantly. This presents a challenge, not just with the content directories themselves, but with the content navigator as well. There is zero opportunity to update every machine simultaneously. If your firm uses SCCM software to push updates to everyone, then that is a potential solution. If not, though, there is a much simpler approach: Editing the .addin file of the Family Browser, you can re-path the location of the .DLL, and move them to a networked location. Note that in Revit 2013, due to .NET4.0 requirements you need to update a configuration file for Revit for this to work (currently it doesn’t work). It is, however, fully functional in 2011 and 2012. Ours are in a similar location to the Content Directories themselves. Then, Windows Sync Center (Offline Files) is used to sync the entire content library and FB DLL Directory (permissions intact). When they are disconnected from the office, they still see and have access to the content library. While it doesn’t guarantee real-time updating, it guarantees that as soon as the user touches a “home base,” not only will he or she get updates to content and libraries, but to the FB add-in as well (which has seen four major releases and about a dozen minor releases in two years).
The User Experience
For me, the seamlessness of the interaction for my design teams was paramount in picking a solution for content navigation: I don’t believe they should have to stop working to hunt for content. I don’t want them to have to search, and I don’t want a model experience that forces them to enter > step > find > load > exit, and resume work. For the user interaction to remain consistent and effortless, it needed to be small (or resizable). Some of the solutions in the marketplace—which admittedly offer a lot of functionality—are just plain huge. That equates to a user needing to get rid of it and, subsequently, it not getting used. The FB is small enough to auto-hide, or shrink at the users’ discretion. And since you don’t need to search or type in keywords to find content, you can shrink it down and use it in a minimal amount of real estate.
To be sure, the FB isn’t teaching the users how new content works (although it has right-click functionality to engage the URL of the family type, which we have explored tying to our internal SharePoint Guide for content). Plus, the content shows up automatically, which lets the users know something new is there (and they see it), instead of having to ask to be directed to it. For an office that is constantly expanding its content library, it also means not having to send dozens of emails a day with family locations. A simple “Switch back to the tab in a second,” tells a user the family is there and ready for use.
My transition out of CAD and into BIM took place a number of years (and several BIM platforms) ago. While being a proponent of innovative solutions, I also advocate that we remember to look back—not to work the way we used to “because that’s how we did it,” but to see what we used to do that really worked well. The Design Palettes were among those things: They were a chore to set up, but they were great at getting content to the masses in quick and simplistic user experience. With Family Browser, Kiwi Codes gave us just that, in BIM form. It is one of the few add-ins I consider a “must have” for a successful Revit Implementation.
Aaron Maller is currently the BIM Manager at The Beck Group (www.BeckGroup.com), specializing in Revit Implementation. His current role includes streamlining use of the program, exploiting its efficiencies amongst the Architectural Design, and Construction groups at Beck, as well as Revit Infrastructure Management and Training for all users. His work experience includes implementing and supporting Revit in a variety of offices, and using Revit for all phases of Architecture (from Design to Construction including fabrication), on projects of varying scopes and genres. Passionate about Revit and Architecture, he's an avid contributor on AUGI (twiceroadsfool) RevitForum.org (twiceroadsfool) and is active in the Revit Community. You can read more at his blog, the Malleristic Revitation. www.malleristicrevitation.blogspot.com.
