Earthquakes

In 1923, Frank Lloyd Wright completed the Imperial Hotel, a building commissioned in Japan. In 1923, there was a 8.3 magnitude earthquake. The hotel survived.

Wright was a midwesterner like myself, and had no experience with Earthquakes. When he arrived in Japan, that lack of familiarity was his strength; he passionately researched earthquake damage, and designed his hotel with multiple safeguards.

1. The reflecting pool (visible in the picture above) provided a source of water for fire-fighting, saving the building from the post-earthquake firestorm;
2. Cantilevered floors and balconies provided extra support for the floors;
3. A copper roof, which cannot fall on people below the way a tile roof can;
4. Seismic separation joints, located about every 20 m along the building;
5. Tapered walls, thicker on lower floors, increasing their strength;
6. Suspended piping and wiring, instead of being encased in concrete, as well as smooth curves, making them more resistant to fracture.

Wright’s thoughtful consideration of both what happens to a building during and after an earthquake made me wonder about how well designers (including IA’s and IxD’s) consider their materials and toll that the environment has on their work. I know webdevs worry and fuss over the effect older browsers have, but overall how often does a designer consider what happens when things go wrong?

For example, I often see space-constrained interfaces with the label in the form field; for example here shown Netflix’s search.

I am a very fast typer (and thinker) and often have a slow connection (being a laptop user, roaming about). I have been known to call up netflix and type a query into the search box before the rest of the page has finished loading. This also means that the little bit of javascript that clears that label also hasn’t loaded. We get a result that includes the label into the query.

I’m not pointing a finger at Netflix; a lot of sites do the same. In fact, Netflix is a paragon of technological capability: if anyone could make this solution work consistently it would be them. So although some designers might argue this is a technology problem, and an engineer should fix the javascript. But I say it’s the architect (designer) that should consider what happens when things go wrong. because things always go wrong.

One solution would be to have the algorithm strip out the label when it’s used with a query. Another would be to not put the label in the form, where it is likely to fail anyhow (plus past AB testing has told me placing the label in the search field reduces the use of that feature. It damages the ability of the user to pattern-match to find search. Fun fact!)

As well as technological earthquakes, in social website design you have to consider social earthquakes. For example, at Linkedin there are a lot of recruiters on the site. And while they are a valuable part of the ecosystem, one has to be careful they don’t interrupt the ability for professionals who are gainfully employed to exchange ideas and questions. In the groups area, ordinary conversations would get buried by recruiters posting jobs. So they added a job board, and a “move to jobs” button, and allowed the users to get those posts out of the way of folks not seeking work, but saving valuable content for those who are.

This is not the be-all-end-all solution, but it’s a good step. There are those who abuse this tool and move valid (if annoying) conversations into the job board, making that less valuable. but as the groups team learns to predict those kinds of aftershocks, they adapt the tools to be flexible and robust.

So as we design we need to consider more than the perfect design; we have to consider how that design will both get build and how it will live in the world after. Technological earthquakes to consider include

1. Execution: can the person who’s building this build it the way I have designed it. Web developers are still enough in demand that your company may have hired someone a bit less experienced or skilled. Are you designing something that can’t be built by the person who’s building it?
2. Maintenance: Okay, you have a genius who writes codes that signs. And when he takes a better offer, can that code be understood and maintained as new browsers come out? What happens when parts are suddenly depreciated?
3. Scale: your design works great with 20 users, or 20 objects, but what about 200? 2000? 2 million? Did you remember the pagination? search?
4. Bandwidth: yes, users now have broadband, big screens with big resolutions and everything is great until… wait! Holy cow, everyone has a 14 inch netbook and they are all trying to use the starbucks network right now! doh!

Social earthquakes include

1. Innocents/Idiots: What do you do about the guy who asks for the 500th time it’s been discussed “Should links to outside websites open in a new window or not”? “Should links be blue, or can they be other colors?” or other sacred cows that the community has decided are tiresome?
2. Trolls: There are people who come to your site just to see if they can annoy other people. because they are mean/bored/sadistic/whathaveyou. Are you ready? They will come.
3. Spammers: The guys are good, and there are more of them than there are of you. They will destroy your community with ads for vitality drugs and pictures of naughty bits.
4. Criminals: Any place people can talk about the things they are passionate about, and exchange images and files can be a place where those passions may not be illegal, and those files under copyright. Do you have an approach that keeps you out of court?

I’d like to invite readers to add other considerations of the way things can go wrong in the comments. And be like Frank, after all those who do not learn from history are doomed to repeat it. Study the way things have broken in the past, and prepare.