Wednesday, August 18, 2010

The Office Library (part 2)


As i mentioned last week, much of what we did on the Wiki is now Superseded by a new content Navigator we got from a third party developer. What we purchased: the KiwiCodes Family Browser (clicky).
This product looks strikingly like the Design Palette from ACA and Civil3D, if youve used them: And thats a compliment. Now, i have LARGELY been a disponent of using third part Add-ons in my Revit Implementations, as you have many more directions you have to think about in terms of Support, Version upgrades, error checking, etc. But this appears to be a banner year, with so many high powered Add Ons coming in to play... The Family Browser, Site works from Eagle Point, and a few others we cant mention yet, that are in the works. My point is, if my goal is to provide the most efficient tools for Beck, the time is finally here (in my opinion, for those of you who thought the previously available add ons were worth it) to let the add ins in to the workflow.

The family browser itself also meant a restructuring of the Office Content Library, since the tool organizes Tabs by File Directory. The OOTB library largely ships that way- with subdirectories upon subdirectories... And i largely UNDID all of that for our office libraries. When you have to manually search for parts in a kit with that many folders, i dont find it is efficient. Plus, a stringent naming system keeps everything organized alphanumerically anyway, so ALL Furniture being in one folder made sense. All Equipment in one folder, and so on. But, i didnt mind subdirectory usage here, since the Family Browser largely means no one needs to browse the library anymore.


The tool also lended itself to Task Based Organizing: Something i was fond of while supporting an AutoCAD Architecture office at QPK Design, who also used Civil 3D. (Shout out to my buddy Lance King, who helped build all of our networked Palettes there). So i went the same route at the The Beck Group, with our new implementation of the Family Browser. The following are the different "Tab Groups:"


















...



















...

The beauty of the tools organization is several fold: 1. If you check the names of all the tabs, youll see redundancy again, much like the old Wiki. Well, i can think of several different times i may want to put in Cabinets, be it Interiors Work, general Modeling, etc. Since these are AUTOMATICALLY driven by their directories, its zero maintenance to have the tabs in multiple locations.

Plus, props on the Palettes being auto refreshing. I add content to the directory, the next time someone clicks on the tab (note: they dont have to relaunch revit), the tab is updated. ACA and C3D did it, but i had to manually add the content to a palette config. Here, i dont have to. Awesome.
Here is a short video cycling through all of the Beck Palettes:




Philip at Kiwi codes was also great about tailoring this for ease of use. A TON of features were added between v1 and v2, including Management functions to auto load custom sets of palettes, and a button that launches the URL from the Family Type properties, which we use to take you to an instructional page on the Beck Revit Wiki, for using the content.
A few things to look out for: It generates previews in jpg format, and saves them in a directory. Philip and i have noticed some strange-eties with this, but its not quirks in the FB itself, its quirks with Revit. Heres what weve found:
1. If the *initial* save-as that CREATED the family, occurred in the view {3D}, it wont get a preview. Itll get a gray box. This is also true: the preview wont ever work in Win7. It DOESNT MATTER if you "resave" the file in another view. Doing a Save As in a 3D view named something else (View 1) corrects the problem. No idea why. Maybe the Factory can chime in.
2. The previews it generates are 64x64 pix. I made some manually, since some families are difficult to get zoomed in properly. Make sure you respect the 64x64... The FB will grow with the previews, and get ugly. :)

All in all, its a great add on. Unfortunately, the day i showed it to the office, i had to leave town on a Family Emergency. So im heading back today, and it should be fully deployed by Tuesday!

Next thing i hope to write about, is Site works... It looks really exciting!

Sunday, August 8, 2010

Mobilizing an office, and Distributing Information...

I often wonder... How does everyone filling the role as BIM Manager for many people manage to distribute information about all of the changes made, to all of the users that use them? Template updates, Content creation, content modification, Standard detail updating, etc... Theres a lot to keep everyone informed about.

The running joke amongst me and one of my (now) coworkers, HAS been that over the last few years i would take a position, set up an entire office, and then leave.... Only to have to start over at the next office.(Here is hoping this time i dont end up having to go somewhere, im quite happy!). But whats always plagued me during the implementation trials... Is how to keep everyone informed? Of COURSE, i know how every family works. What every parameter does. Where the constraints are. How things flex. Whats in the template. Which things are ready, and which things arent. Its only natural... I built it all. But thats not fair to the entire rest of the office.

So finally, while setting up a Content and Training library for Beck, we saw the opportunity to do something ive always wanted to do... And we seized it: The Revit Explorer. At least, in my mind thats what it was called. The format of it lended itself more to: The Revit Wiki. But it was/is as follows:


The first and most significant (in my mind), was the Content Page. We have Registered Architects, designers, Interior Designers, Project Engineers, Project Managers, and Interns, all looking for content. Does everyone know what Folders the library is broken up in to? What Revit Categories to check? No. Should they have to? No.

So the content link goes to a very bland looking list. The reviteers will notice its awfully close to a Revit Category list, but its not. While it started out that way, the categories were then broken up further, in to groupings that made sense architecturally. Revit System Families were included (Architectural staff often dont need to know- or care- that they act differently than components).

One of the beautiful things about an HTML solution, is that redundant links can point to the same location. So some things are included under Equipment, that are also located under Plumbing, or Casework, and so on. They all point to the same pages, when it gets down to the content level, and thats a beautiful thing. If three people guess (interpret) that a piece of content is something different... If theyre marginally close (read: if i anticipated that interpretation), they find it anyway!

The pages shown below (Doors) point to families that are stored in the Office Library. The items that are system families, ALSO point to the office library, where systems of Model Groups are saved out. Just because its a "Revit System Family" that plays by different rules, why should it act differently for the staff needing to load it?

The other benefit to this solution is images. I stand by the long and complex naming strategy for Content that ive implored upon people in office and office again. Until the Factory gives us a Component button that functions by category, and sorts in a fashion other than alphabetically, this will continue to be necessary, as a means to circumnavigate chaos in a Revit Model. (Foreshadow: This whole page is still relevant, although someone built JUST THAT: A version of the ACA Design Palette, for Revit. Thats coming up in my next post, as were using it as the new front end for all users, and for this website).
Still, pictures are much easier to understand than a 5 field Family name, meant to declare what the usages are of the Revit Content. From here, the user knew they had the correct Door: Now it was just a matter of knowing how to use it. Considering how parametric a lot of families are, this is a trial in and of itself. So each family had three links: About me, Open for Load, and Find in Library.
The last one, did just that: It took you to the directory in the network that had the content in it.

Open for Load, would launch the family in Revit (in session, if Revit was opened, with their project, presumably), and then they could simply hit "Load in to Project" and be done with it... Never having to bother with finding the library.

About me, was a page (1 per family) meant to tell the users which parameters were meant for them to use, and what it affected. They look as such:

They may seem like overkill, but i cant help but think its a vital necessity: Highly flexible and parametric content- How much of it do you have? I mean, the harder and faster we push in to integrated delivery, and the more advanced and data/object rich modeling we do, the more theyre necessary.

The image at left is a door family. With the advent of reporting parameters in 2011, doors afforded us many new options: Report the thickness of the host, which we then translated in to (user defined) "ignore the thickness of the host," and for that matter "ignore the LOCATION of the host as well." Why?
We derive much better results (both on the architectural detailing side, and on the construction estimating and sequencing side) from having our Wall Finishes and our Wall Structures modeled as two separate walls. Ever see what that does to a Wrapping Door Frame graphically? Yuck. Now our teams have a way to have the frames auto-throat-determine and wrap at interior partitions, and ignore and manually define throat dimension and frame placement, in exterior conditions. Which ALSO means no more skirting to BS typical details for Frame Locations in Cavity walls. Its a thing of beauty. But, its a lot of parameters. So this web page serves to teach the users which parameters control what.
The Page called Office Standards is just that... Things that are Beck Specific. But another of the fantastic things ive enjoyed with this web page, is the Beck Training Page.
The way i look at it, there are two types of people looking for Revit Help documents, and those two groups of people will search in two different ways:
Those who just underwent training, will search by the class they took. (chronological)
Those who arent in training, are looking for the topic they need help with. (systemic)

I normally train with Powerpoint, and live hands on work, afterwards. But i saw the chance here to just do away with the PPT, and build the presentations in chronological order for the Training classes at Beck University. This worked out very well:
In the image above, you see both ways to search. The top four links are by "topic," while the bottom one takes you to the Beck U training schedule:

Much like the redundancy links on the content page, i like this setup because really... The links are all pointing to the same thing. If you go to "Beck University- Day 1- Modeling," somewhere in the slides you will find Levels and Datums. But if- instead of the Training U page- you go to Revit topics- Building a Model.... Youll find Levels and Datums.
The other major nicety of this system, is that the images are all linked from the office Server, instead of embedded in a Powerpoint. Now, im sure thats doable in Powerpoint as well, i must admit ive never tried.

But working with a program in such infancy as Revit, where the UI, menus, ribbons, options, add on's, and whatnot are changing year to year, this makes updating training material MUCH faster.

I dont have to remove an image, and reinsert an image. I just write over the image on the Server Directory, and its done.


Which leaves me to the last remaining item... The one that was toughest for me to grasp the severity and necessity of, as i was the creator of the material: How, and who to, must i alert to what ive changed, every time ive changed it?

For this, we actually had a conversation amongst the offices internal Revit Users Group: Should it be everyone? Just Revit Model Managers? Project Managers? All Revit users? And how often? Template changes? Content Additions? Standard Detail revisions?

In the end, we settled on this: There is no perfect system. If i email everyone at every change, they will all filter their inboxes to delete my email (LOL... Tell the jokes now, girls. "We already do!" hahahahaha). So, we set up a very simple system as follows:
They are four "Document sets" on the site, which is basically Sharepoint.
One for Content, One for Template changes, and one for Standard Details. They are just pages with lists of text and notes on them for what ive changed in each category, but theyre set up as different document sets, so each user in the office can set up an "Alert," if they would like to be notified via email when i make changes. Instantly, daily, or weekly. Their choice.
Its not a perfect system, but it is- by far- the best ive had the change to implement, for disseminating information.
If you read this far, the irony will be the next post: A third-party app provider has made it so: The Content "About Me" pages will live on, as will all of the Training and Office Standard pages... But the Content navigation pages became largely unnecessary with a new application derived from the API.
Imagine.... The Design Palette from AutoCAD Architecture. Replete with: Content IN Revit, thats NOT in the project, that automatically calls from the library (meaning the complete capability to rethink whats natively in the template, since its all available without a load function). That updates in real time. The loads and/or places content. That is office-wide configurable. And....
That connects to this Wiki's About Me pages. To be continued!