ArchiCAD Layer Theory, Part 1: LEGO and Layers
Right before Thanksgiving a fellow ArchiCAD user sent me a thank you e-mail. He’d downloaded my template and was “still trying to get his head around not needing a gazillon layers…” I wrote back, told him a little about my Layer theory, and promised to write a blog post in more detail. It turns out I’m going to need a bunch of blog posts. Let’s start with some basic theory about how and why we put Elements into various Layers by using the wonderful analogy of LEGO bricks.
From Layers to LEGO
During my time off from work over the holidays, I also spent a lot of time surrounded by LEGO bricks. My daughters, at almost six and four, are entering that wonderful age where LEGO is all they play with. They still aren’t old enough to build everything by themselves, especially all the old LEGO sets they inherited from their mom. My wife thus spent countless hours over the past few weeks building. My job was to find pieces, which took longer than the building because all the LEGO bricks were in a huge mixed up pile. Each day of building we’d slowly separate out the pieces, then dump them all back together when it was time to clean up. Finally after a few days of doing this, I hunkered down and fully color sorted all the pieces. Once that was done, finding everything became so much easier. Except of course many pieces were missing because we’d already used them on other sets. Since it was so hard to find the right piece in the right color before the big sort, we built a number of sets with the incorrect colors. This meant as we later built sets in a more organized environment, we were forced to continue with imperfection, or swap pieces out from finished sets—essentially redoing our previous work.
Sorting all the LEGO bricks for my daughters was an interesting experience because it differed markedly from the color sorted LEGO of my youth. When I was a kid my brothers and I had a lot of LEGO. And I mean a lot. Think how much you had. My brothers and I had more. Imagine how much more. You’re still off. Double that. Now you’re getting close.
When you have a few dozen wheels, they don’t need their own bin. When you have hundreds, they do. When you have a couple quarts of a color, mixing in special pieces is fine. It’s not hard to dig through and find that piece with a sticker or the hinge. But when you have ten or twenty gallons of a color, then you need more differentiation. Furthermore when I was growing up in the 1980s and 1990s, LEGO had a much simpler color palette. There was red, blue, yellow, gray, black, white, some green, and even less brown (we can talk in the comments about dark gray, and a few other things). We also had a variety of transparent colors (which my brothers and I just referred to as ‘clear pieces‘). Now not only are there pink and purple and orange and other distinct colors, there are so many shades of each color that it’s now possible to own more shades of pink and purple than there were total colors when I was a kid (this link has a list of all LEGO colors and the years of production, do not click it if you love LEGO and have deadlines today).When I was a kid we had one bin for one color. It was simple. Now when I was color sorting my daughters’ LEGO bricks, I had to make the decision to sort by color group—pinks and purples in one bin, all shades of blue in another, browns and tans together, etc. Each tub of LEGO instead of being monolithic became a little spectrum of similar colors. I also had to make judgement calls like did the few orange pieces belong in the red bin or the yellow bin (answer: yellow bin). These color groupings actually work really well because a light blue piece sticks out in a sea of dark blue (orange in yellow is better than orange in red, I tested). Had I kept the strict rule of one color per bin, I would have had three to four times as many bins. The merging of colors even had me thinking that to conserve space I could probably mix contrasting colors too. When looking for a white piece in a sea of white and black, it’s probably pretty easy to ignore the black pieces. But that gets a bit complex.
In addition to separating out pieces by color, growing up we also had bins of special pieces. We had so many LEGO bricks that searching for certain pieces (ones with stickers, windows and doors, or other uniques) was impractical. But also since we had so many pieces, that special bin of hinges or sticker pieces wasn’t just two dozen pieces. It was hundreds. When sorting my kids LEGO, I realized that the specialization of my childhood wasn’t necessary. There just weren’t enough bricks to make a sticker bucket worth it—both because the resulting grouping wouldn’t be substantial and because searching for that special piece in a small bin of like colors isn’t so herculean.
Sorting the smaller amount of LEGO bricks did still require a few special groupings that were unique to my daughters’ collection. Minifigures (and minidolls) of course got their own bin because people transcend color. You don’t want to look for a pair of blue pants in the blue bin. You want to look for the pair of pants in the people bin. Growing up we had so many minifigures that we had a bin of town people, a bin of space people, and a bin of castle people (I can’t remember where the pirates lived). My daughters of course have a people bin (there’s no need to separate them out by historical era), but they also have an animal bin—because there are more animals today than when I was growing up and because my daughters are obsessed with anything small and cute. I also added all the food to the animal bin because my daughters also love having the people and animals use the food. Giving the food their own bin would be impractical because it would be so tiny (both because of the limited number of items and the size of those pieces) and leaving the food in the proper colored bin didn’t feel right: when you are looking for food pieces, you aren’t thinking about color.
From LEGO to Layers
I think we unconsciously treat ArchiCAD Layers like bins of different colored LEGO. Instead of separating things out by color, we do it by some other criteria (exterior walls, baseboard, roof finish, millwork, text, dimensions, etc). However we are often too heavy handed and go too far. We make the mistake of giving each shade of blue a different bin or tracking wheels separately even though we don’t have enough to make it worthwhile (how many wall Layers, annotation Layers, or mechanical Layers do you really need?). Not only do we do the ArchiCAD equivalent of a food bin, we go further and make a bin for bananas, for bread, for apples, for carrots, for turkeys… In short, we often think of Layers as the primary Attribute that separates everything from each other. But that’s overkill. If the buckets (Layers) are right sized, searching through ten is better than searching through a hundred little ones (can you manage with one wall Layer, one annotation Layer, and one mechanical Layer, for instance?).
Layers are great. Layers are critical metadata attached to (almost) all elements. But then again, they are just one of many tags associated with elements. They don’t have to be the most important. And they don’t have to be hyper specific. In fact, fewer Layers is better than more Layers. More Layers just complicate life. More Layers mean more chances to have elements on the wrong Layer. Ken Huggins writes pretty convincingly about how you only need one layer. That’s probably too far on the bell curve of layer number vs utility, but perhaps not as far off as your gut reaction says.
How do we decide what deserves to be a Layer and what should be handled with some other feature of ArchiCAD? In the next post, which I hope to share in the next few days, we’ll move from theory and concepts to nuts and bolts. Hopefully in the meantime this exploration into LEGO bricks as an analogy for ArchiCAD elements gives you something to ruminate on. Are you treating your Layers as dumb bins of single monolithic colors or is there more care taken? Are your projects burdened with elements not being put on the right Layers (and thus a devaluation of the whole system)? Are you basing your Layer decisions on the intricacies of your specific work or are you relying on external sources like archaic CAD standards, off the shelf templates, historical firm precedent, or some other source that might not be current enough. Do you feel like your files could use a few more Layers or a few less?
Let’s wrap this post up with one more LEGO anecdote. When I first encountered my wife’s LEGO collection, they were partially sorted—albeit in a manner that was nonsensical to the typical LEGO builder. To the best of my understanding, my mother-in-law when packing up all the LEGO bricks her children were too old to play with, decided to organize them to her liking. Instead of grouping in bins by color, she put everything in zip lock baggies, sorted by shape. Instead of a giant pile of unsorted pieces, or a manageable number of color-sorted bins, there where dozens and dozens of tiny groupings. It was impossible to find anything. I had to destroy her carefully created system just so that we could play. Let’s avoid that. Let’s not have ArchiCAD files with an unnecessary plethora of Layers, based on inappropriate criteria.
Are you following Graphisoft North America on Twitter? Click Here to keep track of all the latest ArchiCAD News in North America (and beyond).