Sunday, October 14, 2007

architectural API

I found this blog entry a few days ago buried in the city of sound links. It's a well-written rumination from a "random" GSD student suggesting that architecture might learn from the rapid development of web programming, which is summarized as
"1. rough html -> 2. static sites by designers -> 3. flash and information architecture (parallel streams) approaches -> 4. template driven design hooked to massive databases (even for personal sites)/web 2.0 cross-site interactivity.
I see architecture at being at best in stage 3 (if not in stage 2) of this. If we can precipitate a stage 4, then I think things will be interesting."

It then goes on to try to define exactly what the analog of web 2.0 would be for architecture. What comes out is interesting if a bit hazy-- something like shelter+decoration+organization+processing. In my mind the answer is something a bit more literal-- if we had an accepted standard for BIM files, and a national code system that superceded most state and local building codes (especially MEP), then we might have something close to a plug-and play, open-source standard for building components. Large producers of things like window walls, prefabricated structural frames, PEX radiant heating and greywater systems could then provide libraries of digital components you can plug into your design and mash up with custom work of your very own. No checking to see if it'll work with the local inspector. No making sure that the j-box is in the right place. And no calling to get the cost and lead time- this is built into the component in the first place for parametric tastiness. If architecture is going to be anything like flikr or google maps, this is the way it's gotta be.

No comments: