Sandy and how the technology we build could serve us more effectively

Last week was a rough one here in New York City. People lost their homes, some a lot worse. We were lucky. I live downtown and all that my family and I had to deal with was no electricity for most of the week, no cell access and a lot of water in our kitchen, no one got hurt and the damage is all fixable. But the lack of basic technology services got me thinking about what could have worked differently. With all the technology that has been placed in the hands of users since the first personal computer I found it remarkable how little was useable. Let me start with a personal overview of our situation and then lay out some ideas about what could be done differently.

When Sandy hit my family and I found ourselves with:
– no power
– no cell phone access (ATT, our provider was down)
– Lack of reliable connectivity

For four days our only access to the internet at home was via one Verizon enabled iPad. Luck would have it, that this turned out to be the one Apple device you want. The iPad has the best battery of any the options available (iPhone, android phone, laptop), and the Verizon network proved to be far superior to ATT.

Yet many of the web sites we needed barely functioned. Con Edison was the worst. After 45 mins of dropped connections the ConEd website told us that they weren’t aware of an outage in our area . Power in all of lower manhattan was out and somehow the site couldn’t tell us that.  The map they had of outages had a few flags on it — those were the brave souls who persisted and reported an outage with pitch black all around them.  And from what I gather ConEd was way better than Connecticut Light and Power — their home page was still saying “Prepare for Sandy” days after the storm hit. News sites were too general, what I wanted was hyper local news. Twitter wasn’t useful. Twiter is hard to filter and the content stream moved too quickly to use effectively given intermittent connectivity. Facebook wasn’t useful, I wasn’t interested in pushing information out, I wanted to get information.

So what could have have been done differently? Here are five ideas:

1. Data and accessibility:

The data is there it just needs to be made accessible. ConEd and other utility service providers could design their websites for constrained circles of accessibility. Think of an inner most circle with no web access, just SMS. One ring outwards represents low bandwidth or intermittent access, mostly email, some web — and then the furthermost ring represents high bandwidth access. Ideally, utility websites should be adaptive across all these rings, at a minimum they should offer users the ability to navigate it at different levels, depending on the situation. So when an emergency hits users shouldn’t be faced with a site that is optimized for high bandwidth access with videos expelling things. What I wanted from the ConEd site was a simple status update of power restoration in our neighborhood. All the rest of the media and information on the website was of no use, in fact, it detracted from what should have been a simple experience.

Going one step further if ConEd and utility service providers made their basic service data accessible via API’s then it could easily be reformatted and delivered to people using the channel best suited to the situation. In the case of Sandy that would have been a simple web site, optimized for low bandwidth and intermittent connectivity, with neighborhood navigation. Someone would have made that site if ConEd and other utility providers made block level service status data available.

[update: there are a few end points that people found to ConEd data, that generated some data, for a good example see this thanks to @cmenscher who sent this to me and @ckundo who created the visualization]

And if service providers had basic API’s they could share them with each other. As @Auerbach reminded me ConEd may not actually know if power is down in your building but Time Warner Cable knows it. And the street lights have connectivity back to a central station. A little bit of data sharing could go a long way here.

2. Usability:

Utility web sites seem to have been designed primarily as marketing tools. This is backwards. The sites shouldn’t be managed by the marketing department, particularly in the case of a utility where customer churn is basically nonexistent. Take a look at the coned twitter feed: The number of messages with media, essentially promotional,is high. But ConEd and CLP are were at least active on Twitter this past weekend. In contrast AT&T’s marketing department seem to have gone home for the weekend.

Socialmedia is opening up channels for people to talk to companies and companies to talk to customers. The departmental lines between marketing and customer service are a fabrication of an era that is past. Customer service is becoming marketing and it should have primacy in situations like this. Companies and brands are starting to think they need to produce media in order to talk with customers. This makes sense in a marketing context but in a situation like Sandy it doesn’t. I’m not interested a Utilities video channel. What I want is usable information.

3. Simplify, Simplify, think /status

As technology advances systems become complex. During emergency situations that complexity needs to be unwound so that basic services remain available and accessible – the first and most basic is an awareness in an organization that systems, critical systems need to scale up and down this curve of complexity. If that awareness can become part of how we design technology then as new, more, complex functionality is added to a product will make the roll back actually possible.

Another approach to simplifying or unwinding a complex systems is for there to be basic standards that system providers agree to. Consider really simple things — i.e.: what if service providers adopted a standard so that users knew that if they went to or or they would get a network status update. In emergencies simplicity of navigation goes a long, long way. There are simple solutions and while this disaster is fresh in our minds is a good time to consider a few.

4. City, local, government data hubs:

Government and city government’s first job is to keep citizens safe to that end government could play an important role as a hyper local data aggregator. If the service providers made service/status data accessible via API’s then cities could easily aggregate that down to a neighborhood level. What I really needed was a single page with aggregate information for power, cell access, flood levels for our neighborhood or even block.  This is a prototypical public good that local governments could offer citizens. Match that page with a simple notification system to alert me of changes and we would have a very simple, usable, local status page.  Note the data I’m talking about is not account level data, its simple service level availability data. This isn’t a radical shift in the role of government, or governments access to data — at some level data becomes a public good and government are the most natural and benign aggregator of that data.

5. Towards a Machine readable city:

By the end of this year there will be approximately 2.3bn people connected to the network. Thats a big number, but we are on the cusp of an explosion in that number. Sensors that communicate with purpose built devices are going to be everywhere (think fuel bands and Nests for consumers and for the enterprise think about all the industrial hardware that will be wired up with sensors to monitor use and state of wear).  Additionally, I believe, cities will become machine readable. Imagine if a city simply added to its street signs simple QR codes. Not only would this give added information to citizens but information could be programmatically updated in the case of an emergency like Sandy. Over the coming decade billions of sensors get wired into the network, many of them in our cities. Most of these sensors primary purpose will be commercial yet there will be some level of aggregate data that the city government should have access to aggregate.  Weatherunderground had some useful maps of the tide levels on monday night as Sandy approached but the detail needed on a local level to make informed decisions was missing.

What happened here in NYC was nothing compared to the earthquake in Japan and the nuclear fallout that followed. Yet alot of our technology failed us. Technology needs to be designed as flexible, adaptable to the context that it exists in. Over the coming decade we will see contextual computing upend many of the services that today we take for granted. Building and designing technology with events like Sandy as a consideration are a first step down the path of making computing and the machines we depend on, function regardless and in regard of the context they exist in.