The IDL: An Inside Look Sep10


Related Posts

Share This

The IDL: An Inside Look

If you’re an avid reader of the [BE]log, you know that the 3+ MArch students were placed as interns at several  top firms around Seattle. A few fellow classmates have already posted their experiences to the [BE]log, and I encourage you to take a look.  My experience, however, has been a bit different from theirs.  Instead of working with an architecture firm, I was placed with UW’s Integrated Design Lab.

The IDL is a research lab.  The work here isn’t focused on developing buildings for clients, but rather, determining ways to make new and existing buildings even better.  The IDL started as UW’s lighting lab, with student researchers building elaborate scale models to test lighting conditions.  Most UW architecture students should be familiar with the IDL’s tilting earth heliodon and mirrored overcast sky simulator – unquestionable necessary here in Seattle.  These are still used on occasion, but the much of the work has moved into the digital realm.  The IDL is evolving, taking advantage of HDR photography to study light levels and working with all sorts of sophisticated modeling software. Most recently, they’ve expanded their focus to include whole building energy reduction.

When I started, the lab was finishing up research on “Target 100!” This project aims to take the second most energy intensive buildings in the US – hospitals — and drop the EUI to around 100 kBtu/ft2. This corresponds to a 60% decrease in energy use, which is impressive to say the least.  Now that the research has been compiled, we’re working on a “tool” to publish “Target 100!” Jumping in at this point has been intense.  In true architect fashion, I’ve been asked to become knowledgeable across a whole range of topics in a short amount of time.  Two days to learn the research before we meet with consultants.  A day to explore the current tool mockup and understand exactly how the IDL imagines it should be structured.  A few more days to research possible dissemination paths – should the tool be a mobile app?  No, it needs a broader distribution than just iPads/tablets. Should the tool be a website?  Yes, but should it be a statically coded website, or a dynamic page built off php and mySQL?  And then there’s the front end design.  “Target 100!” contains a wealth of complex information, but the tool needs to reach across all sorts of users, from designers, to hospital owners, to engineers, and to other researchers who can provide peer review.  Much of the work has revolved around ways of taking all this data and presenting it in a simple, graphic manner.  No detail is too small.  We’ve had heated debates over how many clicks the user must take before reaching the content they seek.

The work may seem removed from the architectural realm, but this, at its core, is design.  How will each user experience our site?  How can we direct their path?  What clues do we give to subtly guide them to the information that they want to see?  All of these are applicable to both the design of a website and the design of a building.  The constant charettes ensure that we’re always searching out new ideas and force us to keep learning about new systems/programs to speed up our work.  Our best estimate is that our site will be massive, with more than 200 individual pages all linked through a literal web of navigation.  Although the scale of this project is daunting, we have an excellent team working on it.  If all goes according to plan, I’ll be able to report our success here on the [BE]log in the next month or so.

Written by Justin Schwartzhoff, MArch Candidate 2014.




pixelstats trackingpixel