Posts from AUGI- Creating a Standard: Doors

I am delinquent in getting this post... posted, but it has been an insanely busy time! A discussion was started on AUGI about custom content, and after a somewhat heated debate was had over the successes and/or failures of Revit Content sites like Seek, RevitCity, etc... A few of us were of the opinion that the failure isnt really on that of the content sites, but that of the content standardizers: They arent end users, and theyre not using the software to get the work out the door. How CAN they know what needs to be in the standards?

Autodesk has taken some initiative posting the Revit Model Content Style Guide, but many of us disagree on if it is helpful or not. It often recommends things that arent a value to the PROJECT, in the spirit of helping REVIT.

I would cut and paste my thoughts on the subject, but its quite lengthy. You can read them in this post, specifically addressing the Content Style Guide.

So what IS a successful standard? Well, in my VERY humble opinion: It needs to account for the most complex situations. Otherwise, when those situations DO come up, its a free for all. The beautiful thing about a complex standard that covers all bases, is it STILL works for a more conservative project. So... Whats critical in that standard? Well, here is my hope:

Im going to go category by category, and post what we are using at Beck, as "our standard." Then im hoping others will do the same. By Vegas time or a bit after, im hoping to have something we can share with the 'Desk. If- at any point in this discussion- it becomes useful, ill post our content as samples, along with the Shared Parameters files.

For the first Category, im going to start with Doors... As theyre often the most complex.

Admittedly, at Beck we like our Revit models a bit more Complex than- perhaps- they need to be. This is a diagram of one of our doors, and the Parameters they have.

This includes a series of Offset parameters and if/then statements, allowing the Door to stay "hosted" to the wall, but push itself off of the wall. This is primarily because we model our walls as multiple walls, so the "Revit Wall" cannot drive the size of the door frame in ALL cases.

Discounting that as something that is not necessary in a standard (as its just our desire), lets look at the rest:

Width: Some doors have one panel, some have two. Theyre not always equal. This NEEDS to be planned on. We have two independant Panel Widths. We have other functionality, to automatically make them EQ, but thats all fluff. i think we cal all agree we need to Panel Widths, STANDARD.

Panel TYPES: This starts the debate about Nesting. Though it may be arrogant to assume everyone works like us, ill go on the limb and say this NEEDS to be standard. Anyone whos done a job with the OOTB doors, knows how exponential the number of doors to edit becomes, with Panels arent nested.

FRAME Types: Always a gray area, since some people make the "Frame" families the Door family itself. But, having worked with them as seperate Nested Families, i have to say i think its great. Ill put up a vote for them being Nested. What are your thoughts? This also starts to delve in to Frame Dimensions, and WHERE should they be controlled?

But, if i WERE to desire Manufacturer Built Content, my personal thoughts are it should be like this:

Door parameters(parent family):

Panel 1 Width (Length)

Panel 1 Type (Family Type: Door)

Panel 1 Finish (Material)

Panel 2 Width (Length)

Panel 2 Type (Family Type: Door)

Panel 2 Finish (Material)

Overall Opening Width (Length- formula driven)

Panel Height (Length)

Panel Thickness (Length)

Panel Floor Clearance (Length)

Frame Type (Family Type: Door)

Frame Profile Jamb Width (Length) [for cutting the opening out wider]

Frame Profile Head Height (Length) [for cutting the opening out taller]

Door Panels (shared):

Panel Width (Length) [tied to the Panel widths in the door]

Panel Height (Length) [tied to the Panel height in the door]

Panel Finish (Length) [tied to the Panel Finishes]

Door Frames

Opening Width (Length) [tied to the Overall Opening Width]

Opening Height (Length) [Tied to Panel Height]

Okay, so ours have a bit more than that. These are also just thye basics. Of course the Frames will have more, as will the panels, for variations IN the panel. But these are (i8mvho) what need to SCHEDULE, and be made from a STANDARD shared Parameters File. But im out of time at the current moment. What are your thoughts on the above?

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!

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!

Revit and Multi-Language Documents

Its been much too long since ive written. Its been an eventful year since i wrote last! I went through all of the implementation and content standards at a new job in NYS, right after which point.... I moved to Texas, to take the job as a BIM Manager at The Beck Group in Dallas. Its been a busy but amazing time down here, and im enjoying every minute of it.

On the Revit side, theres a lot of current stuff to write about. But this one struck my fancy. We're doing some Design Work in Korea, and as such our deliverables have to show both languages: English and Korean. We experimented with a few different options for this, and we also found some interesting things (some by accident). Heres how it went down:

There were two items that needed to have both languages: Room Names, and Notes. Room names was a pretty easy one. As most languages arent one for one literal translations, we simply needed another Parameter to put in the Room tag. No brainer there. Where it got interesting was the following:

In doing some experimenting, The room name in Korean had to be typed in a Text file, saved in UNICODE Encoding, instead of the standard ANSI (Notepad) or Western European/Windows (Word, saved as Plain Text). Without the Unicode Encoding, the characters would actually translate in to gibberish, and nothing would work. Ironically, we figured this meant we would also need a Font that had the Korean characters in it.

Initial testing proved this not to be the case, as this screen shot is Korean Text, in Arial. Interesting! However, i went over to a collegues station and his looked a bit different than mine:

The Korean Arial isnt displaying in Revit on his system. Whats the difference? Im on Windows7-64, and he is on Windows Vista-64.

For whatever reason, the Unicode TXT document doesnt respond the same on both systems.

This also made me nervous because of the Revit "Tug of war" that happens with some settings such as "By Linked view." (If youre not sure what i mean, with two users in a workshared project (Parent) with Links (Link), test the following:

Have both users get local copies of the workshared model, and local copies of the Linked Model.

1. User1: In "Link" Create a new view, "View-Link"

2. User1: SWC in "Link."

3. User1: In "Parent," reload "Link."

4. User1: In "Parent," set a view to "By Linked View: View-Link"

5. User1: Synchronize with Central

6. User2: (Who has been working this whole time): Sychronize with Central.

7. Either user- Go check the Linked View VG settings for Link in that view.

The trouble is, the instance of "Link" for User2 doesnt HAVE that "View-Link" yet, so it cannot acknowledge that it is "BLV:View-Link." Where this gets troublesome, is for some reason the local file of User2 acquires editability of those view settings, and UNDOES the Linked View.)

Back on topic, im HAPPY to report that isnt the issue with the Encoding of the Text in the parameters. So, if the Vista user sees it displayed as squares, it will still plot and display correctly, in Korean...... If plotted from a machine using Windows 7. (I dont think its a Revit issue, so much as a windows issue, but i dont know enough about it. Thats only amusing because Revit 2010 (what this project is in) isnt officially supported in Win7. FWIW: We would love to upgrade, but the Foreign Language versions of 2011 werent released in time for our consultants, hence remaining in 2010. But i digress: The inconsistancy in Windows versions and text occurs in 2011 as well.

This brought us to our next challenge: Notes, in both Korean and English. With language being something that we cant just "toogle" because of the indirect translation, we wanted some way to at least assure that the English and Korean versions stayed tied and up to date, instead of "Text note in english" and "text note in Korean."

What we decided on, was Revits Keynotes. Typically meant to show either a Numeric Tag, or the text of a note, we elected to have it show both.... The number, and the tag of the note. Except, we also elected to not have it show a number, but show the English version of the note AS the number, and the Korean version of the note as the Text. So, just as normal in Revit, we made our Keynote file. (Note: We had to save it as Unicode Encoding again, or it didnt work...).

Once the keynote file was created, it was business as usual in Revit. We made three types of Keynote tags. For each language, and both language. Depending on what we want to print.

The only difficult part is having the Project Team know which note was which, since they cant get sorted alphanumerically, given that weve "replaced" the Keynote Number with an actual text field. Along this front, i think it would be great if we could add additional fields to Keynotes and Keynote schedules. We already do something similar when we add parameters and Shared Parameters to Type Catalogs.

The keynote file is nothing more than a Tab Delimited file, so i wonder why it can ONLY be "key number Keyed Note". The more we get in go complex models, and now (in the last few versions) with the advent of multi parameter labels, it seems like were begging for "Key NumberKey Note EnglishKey Note ForeignInstance Based Text Field," where Instance Based Text field is a note that applies TO the Keynote, but in this one location only. BIM-esque or not, its one of the small features Keynotes need that is a hang up for mainstream adoption.

Anyway, its not a perfect solution, and its not without effort. But this is how were crossing the multi-language bridge. How are you?

EDIT: I should add- Because of the users on Windows Vista, we DIDNT end up keeping it all Arial. We switched to Gulim, which is a native Windows font that supports korean Text. That way- even though the enoding was right- all of the project team could see it on the screens correctly. Unfortunately, when youre actually "IN" a Revit room schedule (not looking on sheet, but in it), they still display incorrectly, unless youre actively in the field. At which point, they display correctly. Strange!