The ALL CAPS Top 10 Articles of 2020

Who’s ready for a listicle!? It’s that time of year when everyone everywhere is reminiscing on the best whatevers of the year. Of course, I’m getting in on that action with a list of the top ten most-read articles of 2020, the year of ALL CAPS triumphant return. Here we go…

10. Rethinking Access to the Architecture Profession

My opinions on how the three pillars of prerequisite experiences to becoming a licensed architect need to change were a popular read — even if not everyone agreed with me!

9. The Smartsheet for Rollout Development Series

It’s no secret that I ❤️ Smartsheet and I was happy to see that you all liked this series on building the absolute best friggin’ system for managing rollout development! (seriously, all other systems suck and this one rules)

8. A Spoonful of Content Makes BIM Exchange Absurd

People love venting about the closed BIM world created by divergent objectives and proprietary file formats. I do too, so I did…in this article!

7. Information-Driven Design: Distributing Design Criteria Via Smartsheet – Part 2

More Smartsheet! This look at the direct pipeline of information exchange between Smartsheet and BIM is my favorite Smartsheet trick!

6. Revisiting Software Costs

I did my own take on a cheap tech stack to try and help Autodesk CEO Andrew Anagnost’s fuzzy math work better…and I did it! Just not using any Autodesk products. Sorry, Andy!

5. The Mike Brady Compensation Index

We all like to see how much others are making, and I was happy to lift the veil that had long been concealing TV architect Mike Brady’s earnings from us. Turns out Mike is a cash machine! 🤑

4. On Architects Being “Good at Math”

It’s the question for the ages: do you need to be good at math to be an architect? I hate this question. You love this article!

🥉 3. Grab a Drink! Let’s Peruse Architecture’s PPP Data

The Paycheck Protection Program was one of the few morsels of good news we had in 2020…until we saw who was taking all that dough. In my tabloid-esque look at who got what in architecture, we see that there’s some architects out there making Mike Brady look downright poor!

🥈 2. Searching the Soul of Your Software Developer

There’s no question that THE STORY of 2020 for the AEC software world was the angry architecture firms’ open letter to Autodesk. It was real tip-of-the-iceberg shit. One of my favorite things I wrote this year was this article, so I’m glad you guys liked it too.

…and now, the most-read story of 2020 at ALL CAPS…

🏆 1. The Software Obituaries of an Architect’s Practice

This was one of those article ideas I felt really satisfied with, and it was a lot of fun to think back on all these titles. I had to dust off a lot of old spreadsheets and notes to find all the failed software. Every architect knows the struggle of finding good digital tools to get the job done.

Thanks for reading! In my look back at the site’s statistics I found one article that doesn’t have a single view! I’m not saying which one because now I’m paranoid that it’s really bad! 😂

A Spoonful of Content Makes BIM Exchange Absurd

The absurdity for me began back about a decade ago — I can’t remember the exact year, but I’ll never forget the sequence of events. A client reached out to have me send a bunch of content from the drawings we had prepared for them over the years to a guy at Autodesk. After what I can only assume based on personal experiences was a full-court-press sales job, the client had decided to migrate their design criteria from AutoCAD to Revit and Autodesk was going to build them a template and a library of content on top of signing them up for rent-a-license annual fees.

In a rational world, this would be no big deal for me as my firm had already been producing this client’s projects using a BIM authoring tool for several years at that time. They would be catching up to me and maybe they actually start using the ever more powerful BIMs my team was producing. In turn, I could help them out with sophisticated content that was already up and running. Side note: since our contract obligated us to provide what some well-meaning, but ultimately poorly informed attorney wrote in as “AutoCad R.12 files” we simply exported our beautiful, smart BIM to dumb DWG files for the client’s records up to this point. The BIM was really just a more efficient design and production tool for us at that time.

But 21st century BIM practitioners do not operate in a rational world; we work in a world of daily absurdity. My offer of BIM content was rebuffed, most likely because Autodesk had mostly walled off any of Revit’s potential model geometry sharing capabilities ever since it acquired the software from its original developers. All they wanted was some DWGs, and to this day it still makes me laugh that my content went from Archicad to AutoCAD to gawd-knows-what to Revit. That. Is. Absurd.

I don’t mean to make this all about Autodesk walling off the rest of the industry either — even though that’s exactly what they do. The real point, the real absurdity, is the basic approach to BIM collaboration happening here.

My area of practice as an architect focuses on working with chain concepts on rollout development, especially with restaurants and retailers developing dozens or even hundreds of locations nationally here in the US every year, so that’s the perspective I’m writing from with this article. In conversations with other BIM practitioners, I’ve found that we chain architects share the same absurdity with those who work on larger one-off projects like campuses, stadiums, and high-rise buildings where the client has an extensive and very specific EIR.

Back to that BIM collaboration approach. Basically, every chain that’s migrated from CAD to BIM in the US takes the same approach, which is, “hey, we’re using Revit (insert specific version number here) to make a shit-ton of content for you, so you have to use Revit (insert same specific version number as client here) and use all of this content as-is — oh, and that’s super easy ’cause Autodesk said so. So get it done faster and cheaper too.”

This. Is. Absurd.

If I approached someone (maybe not you, as if you’re reading this you’re probably thoroughly tainted by the absurdity already) and said they would be spoon-fed a bunch of stuff for their job…

…and this stuff was often cumbersome or counterintuitive to their workflows, (imagine fixing the same errors with each new version of the content, or reformatting the same stuff over and over with each new design made from the content) but they couldn’t do anything about that because this stuff had to stay in the same format and version it came in even if the rest of their company was working in a different format and/or version since the content had no backwards or cross-platform compatibility…

…and receiving this stuff, and working for the client would tether them to really expensive and often flawed software — the only software that can use this restrictive format — and that software stops working if they stop paying in every year — even though other software does all the same stuff and more and better for less money, oh and it has perpetual licenses…

…and despite all that nonsense, everything they create for their client will be useless in a few years because this software will be unable to open the old files, so they’ll have to do the old work all over again in a newer version of the same shitty software if the project ever gets revisited by the client…

…they would probably stop to think and say, “well, how much am I making off this?”

FAIR QUESTION! The answer is certainly no more than you did already and there will be pressure to do it all for less since the client is investing so much effort in spoon-feeding you, even though their content is slowing you down. Also, what is your sanity and freedom to operate as you see fit worth to you?

…they would then agree to do the work anyway! Why? Remember: ThIs iS aBsUrD¡

Getting back to us, the tainted-by-absurdity BIM community now. A/E firms sign up for this — we line right up to participate in the absurdity. We need the work and we don’t want to let down our clients, even if they’re headed down an ill-advised path that will fuck over our G&A budget while giving our staff (especially BIM managers) migraines. There are also people amongst us who think this is a good idea because they don’t know better, so they’ll sign up for the work too. This is what we do as poor sap architects after all, this is our lot in life. Embrace the absurd!

When Did It Become Absurd?

The story of how it became absurd is a brief one. It’s not complicated. Autodesk acquisition-ed itself into the BIM paradigm and used that change to avoid the mistake it made with AutoCAD in not having a locked-down proprietary file format. Then Autodesk seasoned that shit stew with some restrictive versioning and a shift to renting instead of owning the software licenses. We poor sap architects made like Tennille and told our Captain, “do it to me one more time!”

But here’s the real kicker, in our (I’m using this possessive determiner to be nice, keep me otherwise out of this) rush to Revit, most made the same mistake that always happens at paradigm shifts in our profession and in this case, didn’t really change their CAD workflows for the BIM world they were living in now. A few users found their way to little bim and enjoyed new levels of production automation over CAD, but not much more than that. And here in the US there was virtually no Information in BIMs early on (and it’s not much better today).

This brings us back to chain concepts (and clients with large-scale one-off projects). Autodesk sells these corporate entities on flashy BIM doing fancy Information-driven shit, but they only get to little bim (the content I’ve seen made by Autodesk is, well…crap) and settle for getting automatic elevations and basic stuff like that. Keeping those old CAD workflows on top of all this, the corporate entities (our clients) push out templates and libraries to their consultants, but it’s not like it was with DWGs where people could use a variety of versions of AutoCAD or even other CAD tools (looking at you, Microstation and Vectorworks lovers, or any of the multitude of other software that can run with DWGs), you have to use the exact same version of Revit now as your client and absolutely nothing else. Side note: the acrobatics these companies and their consultants go through when the company decides it’s time to use a new version of Revit since it’s not backward compatible are truly something, and bring plenty of unintended consequences with them. Another thing the client doesn’t realize is that unlike DWGs or DXFs, eventually these RVT files will age out, and unless you have and old computer sitting around that can run that old version of Revit, you’ll be sitting on gigabytes of worthless files…unless (per Autodesk support) you also happened to save out an IFC file with that RVT back whenever (warm up that time machine). But no one reads that part. I know because no one involved in the decision making about using Revit at these corporations seems to know much about IFCs at all in the conversations I’ve had with them over the years.

We don’t stop to consider what you actually need for legacy BIMs, which is just the friggin’ BIM itself and not all the CD set content that proprietary formats include (at least not the editable original versions of it); and that these BIMs may not be needed for ten years or longer (ten years is a common lease term for the retail industry and that’s often when old designs get revisited). Who’s to say what we’ll be using to do our work in a decade? I certainly don’t want a bloated legacy file, as all that bloat guarantees a crash on open. Thus far Autodesk hasn’t done jack shit to make sure their customers can use those RVTs that many years later. It’s enough to make an openBIM advocate roll their eyes so hard they get stuck in the back of their head.

What Keeps Us Embracing the Absurd?

Fear, for one thing. We’ve been in the walled garden long enough to be worried that if we step outside we may not be able to get back in again. But on a more technical level, there’s the divergent objectives of openBIM that create confusion and frustration for people new to it that are just trying to be free to author BIMs using the tools and workflows and content that they control. This part is where some of the openBIM folks will get irritated with me, and that’s okay. We’re not letting perfect, standards-driven, Information-loaded deliverables get in the way at this point (though I do earnestly want us all to get there someday). Let’s just get ourselves decoupled from proprietary files and dumb CAD workflows for now.

If you dive into IFC, you’ll quickly get that it’s all about the ‘I’ in BIM — the Information. But in the beginning when you’re starting out with it, you really just want to be able to share model geometry with another party because that’s all anyone’s been doing to this point in time with all their RVTs and RTEs and RFAs and whatever else. This graphical side of the conversation is largely ignored in conversations about openBIM because those convos are conducted by the more advanced BIM practitioners who are simply focusing on their interests. Yes, these early exchanges will be messy and could be better with some Information coordination, but we’ll get there, just hang on. While we all need to be doing Information-driven BIM, we have to start by just making sure we can share the damn model geometry, even if it’s not perfect (it wasn’t perfect in the RVT either, so there’s that too). That’s step one for this particular project type and it’s the impure, ugly truth.

I’ve had the…uh…joy of being on both sides of the model geometry exchange: as the client’s architecture consultant and as the corporate entity, AKA the client. I’ve written extensively about the proper way to set up design criteria, which is not handing over a proprietary template and library based on your personal way of doing BIM, so I won’t go into that too much here. My client-side methodology is driven by the organizational structure I wrote about as well as rigorously documenting the Information in ways that allow for easy exchange and importation into the consultant’s BIM. The process I’ve described is definitely critical to open workflows, but it’s equally beneficial to any kind of chain rollout development efforts as it just works better for conveying design intent, and that leads to better outcomes.

This is an example of one of the client-side workflows I’ve used with great success

On the consultant side of things, I find that you need to keep things short and sweet with the client, as you’re lucky just to get a moment to talk about a different way of doing things. What I’ll do is discuss the IFC format and IFC viewers, then we’ll exchange some small, simple test IFC geometry that we can each look at the test geometry in the viewers and our BIM authoring tools. Now we understand how the geometry translates across platforms and make adjustments as needed. There’s often frustration for the client when they don’t see something exactly like the RVTs they’ve been looking at for years. I equate these feelings to the frustration one feels when initially learning a BIM authoring tool at that moment when they feel like it’s all too much work, too many settings to fiddle with, and it was just easier with CAD (but substitute RVT files for CAD in this case). I’ll explain to the client that it’s just different and that the BIM tools have settings to better control/automate imports and exports to make the software do the work for them. Like when initially learning BIM, just keep at out and you’ll grow to appreciate it for what it is: a better way of working because it lets all of us work the way we choose that’s best for us. There’s another conversation to be had with the client about the forward compatibility and reliability of the IFC format over time, and this convo goes pretty smooth as people don’t want to lose that work due to the passage of time.

I’ve found you need to give the teams doing IFC model geometry exchange time to get comfortable before you get into the Information part of those IFC-based BIMs, and some of those Information conversations will just start happening naturally when they realize the Information drives the model. After exchanging IFCs for a while, people start to make requests of each other with regard to model elements and maybe even some properties of the elements. From there, people see possibilities in working together to customize the BIM via IFCs neutral exchange and then you can start talking about including (or more accurately, cleaning up the mess of) Information embedded in that model geometry. People are shocked to find out that all the Information they’ve ever wanted from their BIM has already been asked for a zillion times in the past and that someone invented a system for reliably exchanging that Information (why hello, COBie!) and that there’s software to automate the movement of that Information between parties. It’s all baby steps to make sure we don’t lose anyone or anything along the way.

Will We Ever Not Be Absurd?

You can see how it’s easier when the client just does things openly from the start, as that trickles down to the consulting professionals and then everybody’s on board. It takes longer and requires more effort to push uphill with change from the consulting professional side of the content exchange.

The same mindset that resists adopting national CAD and BIM standards kind of applies here. For example, we all know our personal standards are best, so we don’t pause to think about a world in which we never have to spend time configuring and troubleshooting software for our own standards because the national ones are baked right into the default settings. It’s a similar kind of resistance that says it’s easier if I spoon-feed everything to those who work for me and we all do it my way in my software using my content — take all the thinking and choice out of it, you know…

Another obstacle to these efforts is the software and its limitations (mostly this is Autodesk, but not exclusively). A lot of Information exchange is hindered when developers don’t implement reliable import/export methods for standards-based information. I see Autodesk joined ODA, so maybe this will change, but I won’t hold my breath. Right now, Autodesk does a lot to muddy or just outright block the road for imported geometry to become a Family, which is a constant source of frustration and wasted time in my efforts to work openly amongst teams using a variety of BIM platforms. We find workarounds that allow us to support our openBIM efforts, but it’s clunky and inefficient. There’s no question that we need something slightly less shitty from Autodesk here.

Anyway, back to converting RFAs for use outside Revit just to be able to do some architecture. Have an absurd day!

Lessons from the Corporate World

I spent three years working as director of design in a corporation — a startup. It was a wild ride and I learned a ton. Going corporate is definitely something I recommend all architects try.

There’s a lot I can write about my time in the corporate world, but the most important takeaways from working with business professionals all center around lessons on agility and flexibility, whether to meet the changing needs of the marketplace or to adapt the corporate structure to a new business plan.

I’ve been triggered to write this by all of the recent reporting out there on how architecture firms think they’re locked in with Autodesk, who’s been ripping them off for decades. My corporate time taught me that anything can be changed if it pencils out economically (and basically everything except the most batshit crazy nonsense will pencil out). Not nearly enough architects or firms take a dispassionate look at big changes to their practices, nor do they have independent boards of directors pushing them to do so and asking tough questions along the way.

Great businesspeople are more creative than architects in an important way: they can dispassionately look at every part of their business and ask tough, honest questions with seemingly unattainable answers; then get super creative in pulling off plans to make the unattainable a reality. In architecture, we get so romantic about so many parts of our practice that we let any business judgement get clouded by these romantic notions of how we do what we do (see any discussion ever amongst architects about hand-drafting or sketching by hand). Businesspeople don’t get particular or sparkly-eyed about how it gets done, so long as it gets done on time, on budget, and it’s done correctly. Meanwhile, architects go on diatribes about shit that doesn’t matter in the production process.

As creative professionals, I can see granting us a little, tiny bit of space for our hangups preferences on how our production process works; but surely the first boundary around that space is economics. When something in your production process doesn’t pencil out because it costs too much money or time, I don’t care how hard you think it will be to change (and it’s never as difficult as you think it will be), it’s time to move on from a business standpoint.

It’s all one more reason why I laugh at these conversations in the wake of the angry open letter to Autodesk. In a corporation a conversation would’ve ended any attempt to even send an open letter in the first place:

Employee: “We want to issue this open letter complaining about license costs to our biggest software vendor. It’s cutting into profits and the software doesn’t even work that well.”

CEO: “Have you talked to this vendor before you considered an open letter?”

Employee: “Yes, they offered excuses and then ignored us on subsequent attempts to communicate. They also just raised prices…again.”

CEO: “Assholes. Let’s dump them. Someone else makes software that does the same thing or better for less, right?”

Employee: “Well…yes. But it would be too much work to switch, since everybody knows the other software.”

CEO: “How different can the two softwares be if they do the same thing? Pull together an ROI analysis and transition roadmap for Monday’s meeting before you go sending open letters out. Let’s figure this out.”

This is the spot where the employee would pull together numbers with their team and realize that the change pencils out rather reasonably.

Instead, I’m counting the days until the newsfeed brings us a story about a firm tacking on an Autodesk Surcharge to their fees to cover them getting gouged because, well, Revit is just such an integral part of their practice and it’s what people know. 🙄

PS
This isn’t about being anti-anything in terms of software, it’s about whiney architects being chickens. Design however the hell you want to, just don’t expect to get taken seriously when you choose to let a software vendor key to your design process walk all over you because you think change is impossible. I ain’t afraid to make a change when I realize the time has come to do so.

The Software Obituaries of an Architect’s Practice

All those lists that well-meaning architects make of their favorite software become outdated quickly. I thought this would be a more interesting way to talk about personal software preferences than the usual “what I use” software lists out there. These obits will be limited to software I actually used on real projects. Software that never made it out of my testing phase was dead to me before it ever really got going — plus any list I make of software I’ve merely tested would be long as hell!

Before you dig into these, be sure to open this song in another tab and leave it playing in the background as you read. Have a tissue handy, this is going to be emotional. Deep breath…here we go…

🖥 Desktop/Laptop

BIM

  • Revit 2009-2015
    • Man oh man were you a dysfunctional piece of shit when I met you. I stuck with you though, and you got better with each version. One thing that never improved though was the TurboGrafx16-like graphics of your 3D window…or your ridiculous cost of ownership…or your inability to work well with others…or how slow you were in handling larger BIMs…you know what!? You’re still a dysfunctional piece of shit.
    • Survived By: Archicad

CAD

  • AutoCAD 1993-2006
    • A mainstay of my architecture practice for many years. I invested time and energy mastering its programming language and managing its deployments. It rewarded that investment with limited functionality and inexplicable crashes and network license errors (it was really the only reason to ever reboot an NT server). You won’t be missed.🖕🏻
    • Survived By: AutoCAD’s web version and DraftSight (the only reason anything replaced it is so I can validate DWG and DXF exports from Archicad)
  • Architectural Desktop 1997-1998
    • You were a bloated version of AutoCAD that thought it could do something resembling BIM, but without the reliability or lowered effort. Good riddance.
    • Survived By: No next of kin…

Visualization

  • 3D Studio MAX 1998-2006
    • I won’t miss how slow this software was nor how unpredictable its output could be sometimes. It tied up endless hours of processing time with its renders that I look back on and laugh. Like its late cousin, AutoCAD, network reliability was horrible as well.
    • Survived By: Lightworks (Archicad)
  • SketchUp 2000-2006
    • It came on the scene like a breath of three-dimensional fresh air and swept us all off our feet with its beautiful, simple, intuitive interface…but then you had to edit/revise what you just modeled. The rest, I’m afraid, is ancient history.
    • Survived By: Archicad
  • Piranesi 1998-2001
    • Piranesi was a revelation. Its EPix technology was (and still kind of is) a very cool way to edit depth in 2D imagery. You were quick and easy for making renderings, but maybe a little too specialized for your own good.
    • Survived By: Lightworks
  • Illustrator & Photoshop 1998-2018
    • When architects need these two capable titles, they really need them. I relied on Illustrator and Photoshop for all sorts of tasks that helped make me and my work look good over the years. I want them to remember (up in heaven) that it was never about them, it was about their creator, Adobe, who’s a total asshole that I hate.
    • Survived By: Affinity’s Designer & Photo
  • Lightworks 2006-2014
    • I only liked you because you were built into Archicad. Everything else about you was clunky and unintuitive.
    • Survived By: CineRender
  • CineRender 2014-2019
    • Ditto what I said for Lightworks, but at least your were slightly faster.
    • Survived By: Twinmotion

General/Productivity

  • GoLive 1997-2007
    • I loved you and you were the best WYSIWYG web tool ever…and then Adobe bought Macromedia and was like, “Hey, everybody! Use this bloated piece of shit instead!” You are missed.
    • Survived By: WordPress
  • WordPerfect 1994-1999
    • I doubt any word processor will ever be able to handle templates as slick as you. Alas, the age of email made me adopt Office (and Word along with it). You will always be remembered and loved though.
    • Survived By: Word
  • Fusion 2013-2015
    • No one emulated a beige box PC as fast as you, and the best part was I could just shut you down and make that beige box disappear.
    • Survived By: No next of kin (I just avoid Wintel software nowadays)
  • Wind2 1999-2010
    • You were certainly reliable, if not attractive. Updating your database was an epic undertaking that consumed hours of my life.
    • Survived By: ArchiOffice
  • ArchiOffice 2009-2015
    • ArchiOffice was a breath of fresh air relative to the dinosaur that was Wind2. It was built upon FileMaker’s database technology…then its developer migrated to MySQL…and sadly ArchiOffice succumbed to its injuries.
    • Survived By: Toggl
  • Acrobat 2000-2016
    • I never liked you, but you knew that. I was all too happy to send you packing.
    • Survived By: Revu
  • Revu 2016-2020
    • I liked what you were capable of on a good day, but you became even slower than Acrobat, and that’s really saying something.
    • Survived By: TBD (still testing my options)

📱 Tablet/Smartphone

I definitely tested a lot more software on these portable devices than I ever did on the desktop. Very few apps ever make it out of testing and into my tablet/smartphone workflows though.

  • ZipCAD 1999-2009
    • Still the 🐐 CAD app for smartphones. I managed to keep this old beauty running on Visors and Treos well into the iPhone era. No one to this day could interface with a Leica DISTO like you, my beloved. Always remembered. Always loved. Let’s pour one out for ZipCAD.
    • Survived By: DISTO Sketch
  • DocumentsToGo 1998-2009
    • You were kind of helpful at a time when being able to open Office files on a mobile device was groundbreaking. Viewing was your specialty, editing was your downfall.
    • Survived By: Word, Excel, PowerPoint (iOS versions)
  • SketchBook 2012-2018
    • I thought you were really great, but then I realized I needed something much simpler. Goodbye.
    • Survived By: Linea Sketch

🔗 Web/SaaS

It’s funny how much in this realm is absolute garbage.

  • Lucernix 2009-2012
    • Your interface looked like web 0.1 technology and you were slow af.
    • Survived By: Accruent
  • Accruent 2012-2015
    • While far from perfect, I generally admired IBM’s efforts…until I met you, that is.
    • Survived By: Smartsheet
  • Buzzsaw 2009-2015
    • I always wondered how you were so much slower than all the other cloud services using Amazon S3, then I remembered Autodesk made you.
    • Survived By: Smartsheet

What have I learned from all of this software death over the decades? Don’t get seduced by software that promises to work miracles, as very, very few miracle-workers ever live up to their potential and several even end up making more work for you. Most software is simply okay, and as long as its reasonably priced and reliable, you should rely more on your own imagination and creativity with that software to make it work miracles for you. (also, this statement is not to be misconstrued by Luddites who think it’s okay to still use CAD, it’s not, get help)

A Quick How-To on Data Transfer Between Archicad and Smartsheet

In my twopart series on distributing design criteria via Smartsheet I explained how the heart of the process was a direct pipeline of information between Smartsheet and the architects’ and engineers’ BIM authoring tools. In my example of this I used Archicad and I wanted to share some more detail about how to make Archicad’s property import/export functionality work with Smartsheet.

Archicad has been able to import and export property data via Excel spreadsheets for several versions now and it’s a very slick way to use information to drive your BIM workflows with external vendors, subcontractors, and anyone else who communicates product and design specifications via spreadsheets. Since Smartsheet is spreadsheet-based and can import/export Excel files (among other file types), it too can be used to communicate property data with Archicad with just a couple extra steps to help all the data make the journey.

If you haven’t already used this feature of Archicad, read about it here in the Help Center before you dig into the Smartsheet workflow.

Now, here’s how property information transfer between Archicad and Smartsheet works:

  1. Just like you normally would, set up your properties and schedules in Archicad and then export them from each schedule you want to share with Smartsheet. This will give you XLSX files for each export.
  2. You can open the exported XLSX file and notice that row 1 in the spreadsheet is collapsed by Archicad. This row contains the GUIDs, which are the Midi-Chlorians of Archicad, who in this case are working behind the scenes to make things from outside of Archicad match up with things inside. You shouldn’t alter row 1 or do anything with it, so close the file without saving. It’s just important to know for later on that row 1 is there, and to note that row 2 is the headers from your Archicad schedule.
  3. Next launch Smartsheet and import the XLSX file. When you do that you’re prompted to select a row from the XLSX file to make the Column Headers in Smartsheet. You want to select row 2 here. In Smartsheet the header row doesn’t have a row number, which is different from Excel. This difference means the old Excel row 1 with all those GUIDs is row 1 in your newly imported sheet in Smartsheet.
  4. During the import process you’re also prompted by Smartsheet for which column to make the Primary Column in Smartsheet (Primary Columns have special functions that we don’t need here, but you’ll need to select one nonetheless). Select column 1 from the Excel spreadsheet, which is the column containing the GUIDs for each row in the schedule.
  5. Lock the Primary Column and row 1 in your new sheet in Smartsheet so no one messes with those while working on the rest of the schedule. Then go about filling out or changing cells as needed.
  6. When you’re ready to export the sheet from Smartsheet back into an XLSX file, do so like you normally would from Smartsheet’s File pull-down menu.
  7. Open the exported XLSX file in Excel. Here, we’ll need to move that GUID row that we made the Column Headers in Smartsheet from row 2 in the XLSX file back to row 1. Once we do that, the XLSX file is ready to be used by Archicad.

These are some images of the steps in the process noted above that may be helpful in understanding the workflow.

That’s it! A switcheroo of row 1 as it goes from the XLSX file into Smartsheet and then back into an XLSX file again is the key to this workflow. Hopefully we see a Smartsheet plug-in for Archicad someday that just does this for us automatically, but until then, this is how it’s done. Happy data-transferring!

Searching the Soul of Your Software Developer

The juiciest story in the BIM community at this moment is the open letter to Autodesk complaining about how shitty Revit is in terms of cost, licensing, feature set, interoperability, and day-to-day use. The letter came from a bunch of British architecture firms and was published in AEC Magazine. If you haven’t read it, you should. Autodesk is a (consistently) poorly-led company that uses acquisitions, restrictive proprietary technology, and marketing to return shareholder value instead of innovation and keeping customers happy. This is an important reminder that when looking for a new software solution, we should look at the companies behind the software first — why do they do what they do? Why do they exist? Who’s running the show? Then, we can look at the software itself, which is a lesson I learned very early in my career.

The BIM wars are tired because they focus on comparing features and functions of one BIM authoring tool against another — and rarely do they involve architects who have used both of the software titles being compared. In 2020 it’s safe to say that any BIM authoring tool out there is probably quite capable. They all have their strengths and weaknesses, they all have their blind spots that will shock and appall those who use different software. They all do stupid shit from time to time that will have architects ready to throw their BIMs out the window. No one of them is perfect, but they’re all capable. From there it’s more subjective in terms of UI and the intuitiveness of the experience, so whatever floats your boat.

It’s more interesting to look past the software itself and into the company that develops and sells that software. I’ve always thought this was an important thing to do when it comes to software that drives your practice (obviously it’s not as important for software that plays a bit part in your workflows). In school, I learned AutoCAD, which in the early 1990s ran on DOS or System 7. I liked it and it was exciting to be learning CAD. When I started working, I continued using AutoCAD on DOS. Version 12 was current at that time with version 13 coming out soon. My coworkers were excited about that new version, which made me excited as well. Then AutoCAD 13 came out. I still remember the firm’s IT consultant deploying its multi-diskette installation and changing out digitizer pad templates. AutoCAD 13’s UI looked noticeably different and ran on DOS or Windows only. Those were dark days for Apple and I wasn’t surprised that Autodesk dropped support for the Mac, but it still sucked: strike one. Anyone who’s used AutoCAD 13 remembers that it was a notoriously horrible version full of bugs, incomplete or missing features, and it was a frequent crasher at a time when recovery of lost work was overtime hours instead of restoring a recent past file. This was still in the first half of the ‘90s and it took the piss right out of everyone who was so excited about CAD technology in architecture. From then forward, getting excited about new releases of AutoCAD was strictly the realm of the CAD managers and tech nerds — the average production person at an architecture firm was just going to use whatever version of AutoCAD the firm had to get their job done and that was, more or less, it — no passion or excitement about CAD anymore.

AutoCAD 13 changed the way I looked at software in general and at Autodesk. I went from loving AutoCAD to hating it in rapid succession. I would read the CAD industry magazines and see Autodesk staff brush over the troubles they brought with AutoCAD 13 (though they did fix some things with AutoCAD 14, which took years to finish and release after the 13 debacle) and make promises about new versions. When it came out a while later, I tried AutoCAD Architectural Desktop and felt like blah-blah-whatever — it was too cumbersome for its own good. During this time, our Autodesk reseller hosted some training sessions to help expand people’s knowledge of AutoCAD’s feature set — they were mostly awful, and the last of these sessions was so bad we got a refund. By this time, the Autodesk promises were coming out hot and heavy, but with no substance and little in the way of delivered product. I began looking to get away from Autodesk. I was met with doubts and resistance, as people were scared that we wouldn’t be able to work with engineers, or be able to open DWGs from clients.

It was the late ‘90s when I heard about Graphisoft Archicad and its “virtual building” concept, which seemed really intriguing. But at the same time I was researching Graphisoft, I got a CD-R of a 3D drawing tool called SketchUp dropped on my desk. SketchUp was fast and easy; and even though it was dumb and disconnected from AutoCAD, just bringing 2D work to life in 3D so quickly without having to deal with AutoCAD’s clunky 3D bullshit was exhilarating for us AutoCAD users. I look back on those SketchUp years as a complete waste of time though. SketchUp was an enabler of Autodesk dependency in a weird way, as it was really just a shortcut to 3D from AutoCAD (for the record, I thought the people of @Last Software, who made SketchUp, were great and very, un-Autodesk-y).

It was 2006 when I got back on track and purchased licenses of Archicad for the firm to try out. This was after Graphisoft sent an actual architect to show us their software instead of some slimy Autodesk reseller. They offered training coupled with template and content development provided by an architect as well. The experience with the company behind the software was noticeably different from the Autodesk racket. Not to start pitching Graphisoft here either, as the point I’m trying to make is that your experience with the developer of your software is vitally important and it tells you something about their motivations. What I got from Graphisoft was a community of architects who were passionate about virtual building, which was quickly being rebranded as BIM…

…Long side-story short, I used Autodesk Revit at the same time that I was rolling out Archicad. I got to work with some talented Revit users and we learned and grew our BIM knowledge together. In retrospect it was nice to be able to use these two tools side-by-side. Revit made good progress during the early aughts and got more stable and useable. But for me at least, it was not nearly as nice to use as Archicad…and of course there was still Autodesk behind Revit being unbelievably shitty about support, licensing…everything…

…I was young and still learning the industry during Autodesk’s rise to a billion dollar company in the 1990s, but I could clearly see that their CEO at the time, Carol Bartz, was more interested in pushing new versions out the door and charging us for them even if they didn’t work well, than she was about making sure we were happy customers. Now, the shareholders on the other hand, were very happy during this time and made Autodesk a superstar on Wall Street. It took me a while and I got distracted along the way, but even in the early years of my architecture career, I eventually made the change away from Autodesk. This is why I’m always amazed that people still use Autodesk’s crapware and tolerate the abuse of this company’s licensing practices. Nothing — not one single thing — has changed since Carol Bartz set the tone back in the ‘90s. So, if you started a firm since that time and still got into bed with Autodesk when it came time to buy software, it’s hard for me not to laugh after reading the open letter in AEC Magazine. Those firms aren’t even contemplating leaving as they try to fix an unfixable relationship. There’s plenty of other great choices out there and no one will die if your firm no longer uses Autodesk software to get the job done, we “outsiders” all manage to grow beautiful designs in our own little plots of heaven-on-earth outside of Autodesk’s walled garden.

As for the software developers that didn’t just get written up by an angry mob of users? Remember what brought us to you in the first place: the fact that you weren’t Autodesk and didn’t act like Autodesk. Keep it that way or your next.

Information-Driven Design: Distributing Design Criteria via Smartsheet – Part 2

In Part 1 we looked at how Smartsheet can serve as a tool to help organize and disseminate design criteria for companies doing rollout development of their concept. We discussed how vitally important it is for the design criteria being referenced by external consultants like architects and engineers to be current and accurate.

In Part 2 we’ll cover how to build a pipeline of current and accurate design criteria between Smartsheet and the BIM authoring tool used by the architects and engineers. This pipeline of information is the automated magic that makes this workflow superior to everything that came before.

You’ll recall from Part 1 that we loaded up sheets with specifications in a schedule format where each row represented an individual fixture, furnishing, or piece of equipment. BIM content corresponding to each row was attached to that row. Smartsheet’s push notifications let external consultants and vendors know that changes have been made and are ready for download and export. With this functionality in mind, we’ll establish the information pipeline to the BIM. In the example of this workflow, we’ll use the architect as the external consultant and Archicad as the BIM authoring tool, but the workflow is essentially the same for other consultants and other BIM authoring tools.

The Workflow

Step 1: Notifications & Downloads

Once the organization makes changes (including additions and/or deletions) on a given schedule sheet, the architect receives an email notification highlighting the change from Smartsheet. The architect then opens the sheet and goes to the changes (if desired, the company can even have Smartsheet highlight the changed cells in the sheet itself for ease of identification) to download the new BIM content if applicable. If the change is to the specifications, the architect exports an XLS file of the schedule from Smartsheet as well.

In this example, we see a simple schedule entry with an Archicad Object attachment to download
Next, we can export the Smartsheet schedule to an XLS file, now we have model geometry and scheduling data for our Archicad PLN

Step 2: Updating the BIM with Changed BIM Content

The architect will add the BIM content to the library for their BIM, retiring old content if applicable. The updated library is reloaded and the new content gets verified in the BIM, including aligning the new content’s ID and classification with the corresponding schedule in the BIM. Next, the architect can then begin updating the scheduled specifications for this new BIM content.

Here, the architect brings the new Object into their PLN file and prepares it for receiving scheduling data automatically

Step 3: Updating the BIM with Changed Specifications

The architect imports the data from XLS file from Smartsheet into the BIM to update the properties of the BIM content with the changed scheduling information. Schedules in the BIM then automatically update with the changes, with no manual data entry required

This image shows the XLS file’s data being imported by Archicad to automatically update the corresponding Object and schedule in the BIM
Here’s the schedule in Archicad, all matched up with the original from Smartsheet and ready for CDs

This workflow is the same whether the architect is updating their template or a live project. The three step process can be completed in just a few minutes as well.

Another great feature of this workflow is that the company can allow the vendors who provide the stuff in the Smartsheet schedules to update those schedules and their attachments directly which effectively extends the information pipeline from the architect directly to the source of the information, further reducing opportunities for errors and omissions.

All Done!

Let’s be brutally honest here, no one likes doing prototypical updates — it’s boring af — so the more of it that we can leave to technology like we see in this workflow, the better off we all are. Having it be more accurate and timely is an added bonus. Distribution of a chain company’s design criteria is just one use of this workflow, so I’m hopeful that as more jump on board with it, we can begin leveraging Smartsheet APIs to have the workflow be even more automated than what’s shown here — like a plug-in for the BIM authoring tool that grabs all the content and data straight from Smartsheet. Bring it on!

Information-Driven Design: Distributing Design Criteria via Smartsheet – Part 1

For companies doing rollout development of their concepts, a big part of making sure buildings and spaces get designed right is making sure all of their external consultants are working off the latest and greatest design criteria. Having been on both sides of this important knowledge transfer, I’m here to tell you that it’s easier than ever to do this well thanks to technology.

I love this topic. It’s all about implementation. You can have the coolest design with the best content for your architects and engineers, but if you can’t organize all that information in a way that makes it easy for those outside of your organization to use, you lost.

To make sure we don’t take an L, we’re leveraging information-driven design workflows to take the design criteria for a concept from the organization’s design department out to their consulting architects and engineers. The heart of this workflow will be Smartsheet, a web-based database centered around powerful interactive spreadsheets.

Step 1: Organize the Content into Schedules

The first step is for the company doing the rollout development to organize their BIM content (Families, Objects, whatever you want to call them) into categories related to how that content would be scheduled in construction documents. Depending on the content, you’ll want to organize it by vendor, procurement or installation responsibilities, purpose, or something else. This exercise should allow you to identify common scheduling characteristics (manufacturer, model, finish, utility connection types, etc.) which will become the columns of the schedule chart. The rows of the schedule chart will be each individual piece of content. Now you’ll know how many schedules you need, what’s in each schedule, and how each schedule charts out its information.

Step 2: Build the Schedules

Next, we’ll begin building the schedules from Step 1 in Smartsheet. Each schedule will be its own sheet. The sheets can be organized within Smartsheet into folders which will come in handy for assigning access privileges later on. First, set up columns based on the scheduling characteristics determined in Step 1 then begin adding each piece of content in the rows.

Your vendors can help populate these schedules accurately with current information if you want to give them access to the sheets. This is key to making all of the information accurate, especially once everything is up and running as we’ll see later on.

The individual files for the BIM content as well as any product data get attached to the row in the schedule to which they belong. Smartsheet has version tracking so if the BIM content needs to be updated later on just upload a new file with the same filename to preserve history. This version tracking also applies to the contents of the cells in the schedule. Having a history to look back on is super helpful to both the organization and the external consultants once everything has been up and running for a while.

A completed schedule might look something like this…

This is what schedules look like in Smartsheet

Step 3: Grant Access

Once completed and populated with the initial content, each schedule will also leverage Smartsheet’s push notifications. You’ll set up the sheets to push notify everyone who needs to be made aware each time there’s a change made. Those people will get automated emails from Smartsheet highlighting the changes so they can take action and update their BIMs, and in turn the documentation created from those BIMs.

To make notifications work, you’ll first step up all of the users who need access to the sheets of schedules and BIM content. These are your external consultants and vendors. People can have read and/or write access to the sheets depending on who they are and what their needs may be. You can further organize users into groups based on their companies and/or level of access to make it easier to assign people and update them later on as people come and go from these external companies. As you set up users, Smartsheet pushes out email invitations to get set up in your company’s Smartsheet workspace.

Step 4: Set Up Sheets for Other Design Criteria

Smartsheet is useful for other types of design criteria that aren’t necessarily schedule-based. For example, prototypical details for construction documents can be disseminated through sheets with version-tracking and push notifications as well. Here’s an example of that…

You can organize prototypical detail content in Smartsheet too

Another type sheet you can make is instructional, where you explain to external consultants how to handle the design criteria. Here’s an example of an instructional sheet explaining distribution of deliverables created from the design criteria. Again, push notifications allow people to be made aware of changes in an automated fashion.

Using Smartsheet to explain distribution requirements for design deliverables

These non-schedule sheets won’t interact with the consultants’ BIM authoring tools in the ways we’ll cover in Part 2, but they are still a great way to leverage technology to distribute design criteria.

End Users Download & Create

With everything up and running in Smartsheet, your external consultants can visit the sheets to begin downloading BIM content, product data, and exporting sheets. In Part 2, we’ll look at how these downloads and exports from Smartsheet drive information in the BIM and eliminate the coordination headaches common to every other method of distributing design criteria.

Building Information Sketching: The BIM Era Guide to the Design Sketch Handoff

As certain generations embrace algorithmic design for pre-BIM ideation, for certain other generations the handoff of a quick floor plan sketch created by a senior-level staffer or principal to a production person for headlining is a long-standing architectural tradition. I’ve experimented with a modern take on this important sketch-based task to facilitate BIM workflows.

In an earlier article, I explained that I’m fine with either approach to early design work, but if you sketch, at least make sure you do it digitally — however, even sketching with pen and paper will still work with the guide I’m introducing in this article, it’s just…clunkier.

I came up with this workflow, which I refer to as Building Information Sketching, after seeing enthusiastic production staff get hung up on the Z-axis of the BIM while the designer was only working on the X-Y plane. None of that Z-axis was a concern in the CAD days, and it’s a good thing that it’s an issue today, because it makes us better designers. It all made me want to feed the production staff information for building the BIM that was relevant to the kind of data input the BIM authoring tool was looking for and still make that quick and easy for me to do. Of course there are workarounds for that production person aside from anything we cover here, but that often leads to a mess to clean up in the BIM at a less than ideal time during a later phase of project delivery. So why not embrace The BIM Curve when doing pre-BIM design? Let’s do this. Here’s how…

The Workflow

BIM authoring tools want you to tell them all sorts of details about walls when you are laying out a floor plan, so the designer can provide some guidance on walls via simple wall section sketches — not too much is needed here if you don’t want. For exterior walls, just give thickness, height, and if you’re designing elevations at this time, any information on relief in the exterior face of the wall is helpful. For interior walls, I’ll just provide a height to start with and leave it at that.

For multi-story buildings, you can provide a simple, diagrammatic wall section to explain the story heights or annotate them on each floor plan.

Doors, windows/storefront/curtain walls, fixtures, furnishings, and equipment are handled by letting the production person know which elements from the BIM template you want them to use. If there’s not a good fit in the library, then just let them know the basic parameters so they can place something, they’ll know what to use based on the parameters you specify. This requires the designer to know the content of the BIM template, which can be done by printing out the choices and their names for the paper-centric types or by giving them a PDF to reference if they’re a more digital designer. Having concise naming for BIM elements in the template is important to this workflow to make things fast for the designer.

If the designer is doing exterior elevation sketches, not much changes from what they’re probably used to providing the production staff as long as the designer is providing the wall section sketches noted above.

If you’re the designer about to do a sketch, and you’re in a time crunch and feeling the pressure, don’t be tempted to just sketch the floor plan. Resist temptation and get yourself into a habit of at least providing the diagrammatic wall section sketch(es) too. It really isn’t more than an additional couple minutes of time to get done, and it makes for a big time efficiency improvement on the BIM side of things.

Here’s what that BIM-aware sketch might look like…

This quick sketch captures enough to inform the production staff of design intent and BIM construction — it comes together quick!

You Just Made a Building Information Sketch!

That’s all there is to it! Nothing too difficult here, but it makes a big difference to the production staff in setting up their BIM for success as the project moves forward. Go forth and foster love between design and production staff.

The 21st Century Architectural Graphics Manifesto

In 1932 Charles Ramsey and Harold Sleeper published the first edition of the Architectural Graphics Standards. A look through its pages shows that a lot of things haven’t changed much since then about how we use graphics to document design intent. I don’t think that’s necessarily a bad thing, but I also think that since the technology we use to create the designs and document them is completely different now, we should be making changes to our architectural graphics to leverage that technology.

The idea for a new set of guidelines around architectural graphics has been rolling around in my head for a while. I began altering my thinking on this topic when I started transforming the way I do my job with new software about 15 years ago. That new software made me rethink workflows first, which was challenging and made me question the wisdom of changing software in the first place, but it ultimately paid off when I could see that my work had gotten better from all of these changes. Once I was at that point, I started owning up to the idea the the way we graphically represented things could change too. Colleagues had a big influence on my thinking, and not just peers, but younger people with less experience had refreshing ideas and challenges to the graphics status quo too. Here, I’ll organize my own guidelines into The 21st Century Architects Graphics Manifesto.

Annotation

Using BIM properly means changing a lot of dated ways of documenting buildings. For the documentation and the graphical annotations that go with it, the priority needs to be on using BIM’s smart linkages and ability to intelligently recognize model elements as opposed to manually annotating things as we did with CAD and manual drafting. Rethink schedules. Rethink markers. Rethink noted call-outs. Rethink it all. Ask yourself: if it ain’t automated, then what do you need to do to make it automated? Whatever the answer to that question is what 21st century annotation looks like. And what it looks like is often different from how it was done in the past, and that’s just fine. Making these kinds of changes surprised me when it came to the resiliency of contractors and vendors, who took documentation that looked a lot different and ran with it successfully.

Lineweight & Hatching

This is another place where BIM causes a rethinking of the old ways. Software developers have improved their offerings and added features to automate lineweights, but for those trying to force CAD-based thinking onto BIM, those features won’t be enough. And when those same people are in charge, it sends the production staff into a tailspin of budget-breaking hours and QA lapses trying to get an elevation or something like that too look “just so.” There are questions to ask yourself with this topic too: since BIM expands our capabilities with regard to hatching and customizing linework display based upon specific views, how can that improve the reading of the drawn elements? This is a good time to review the lineweights you use and simplify them. I was surprised how much better the drawings looked than the CAD days with these kinds of changes — things appeared simpler, cleaner and easier to understand. If you want, save your complex lineweighting for details, which haven’t changed much since the CAD days in terms of drafting, but the automated BIM elements need the new set of rules and thinking.

Color

Color is very much connected to the points I made on lineweights and hatching. I’ve been slowly introducing color into my deliverables. Color has pretty much always been a part of my design phase deliverables, but now I’m starting to include it in CD phase deliverables too. I think color in CDs has huge potential and it doesn’t have to be over the top either. Just using some subdued hues in restrained ways within the documentation really helps the information pop. Think not just of coloring materials, but of color coding spaces or elements using highlighter-type colors to help explain design intent. Color schedules to make them easier to read, color call-outs to make them stand out, color code things instead of using call-outs to reduce clutter. Remember, with BIM, color can be automated too.

3D Representation

In the early days of BIM adoption (and sometimes even today) you’d see a drawing in a sheet or even a whole sheet dedicated to an isometric view of the BIM. No annotation or anything else, just that 3D view. Then and now it’s still common to see a perspective view of the BIM on a cover sheet as well. These are nice, but 3D views of the BIM can be so much more. When assembling CDs in the BIM era I’m always thinking about what in the documentation is easier and more clear to show in 3D instead of the usual orthographic views — and not just as an isometric either because sometimes a perspective view is helpful for conveying design intent in the CDs. Combine all of this with color as mentioned earlier and now you’ve really got some powerful documentation. Use all three dimensions of your BIM regularly in your CD deliverables.

Sketching (if applicable)

I’ve tried many apps and Linea Sketch is the best!

The design phase has quickly bifurcated into the algorithmic design and sketch design camps. They’re both fine by me. The algorithmic camp has tools to connect their design work directly into the BIM authoring tools though, and sketching doesn’t. This doesn’t mean we need to avoid sketching, I just think that we need to use different sketching tools now. All sketching should be done digitally with a stylus on a tablet. These digital tools bring new ways to iterate, new effects to explain ideas, and some even let hand drawing get translated into vector-based linework for importation into the BIM. Just having a native digital copy of the sketch that imports nicely even without vectors is helpful in turning sketches into models. Added bonus: no graphite or ink all over the edge of your hand (left-handers know the pain).

Modernizing the CDs

All of these efforts made me realize that a lot of the graphic standards I’d used for years were looking kind of dated in the digital world. This part of the manifesto is strictly personal preference, but I found it made a refreshing difference in the visual quality of deliverables. Specifically, I left behind any fonts or hatches that were skeuomorphic representations of hand drafting. Probably super controversial in some circles, but there’s no good reason to do either the old timey look or the modern look, so I’m going modern, just like the technology I used to make it. Logic!

And Lastly, the Adoption of Standards

The US National CAD Standard applies to BIM too!

I’ve saved the best for last! Imagine a world where all architects use a single set of standards for their architectural graphics and sheet layout. I know that’s a real stretch because very few things seem to divide us more than how shit should look on paper, but just imagine it for a second. Next, imagine all the amazing things that software developers could do if they could focus less on customization tools for their their users to infinitely tweak the appearance of something like a section marker and instead pour that energy into making a single section marker that was super intelligent and feature-packed. Imagine that same kind of change for all the other stuff that we all do slightly differently from each other, but mostly the same. Next, imagine spending less time training new staff since everyone everywhere uses the same standards — also think about the quality of everyone’s work improving because the standards are a constant rather than a confusing moving target from firm to firm.

Does this imagination exercise help you become less clingy to your special and unique and clearly-the-best-in-your-opinion way of doing architectural graphics? No? Okay. Fine. You probably hate this whole article anyway. 😤 Neeeeext!