Completeness versus permanence

I realised something interesting tonight. For the first time, for a huge number of people, all of their personal correspondence will be neatly catalogued and saved. This is thanks to the pervasiveness of email — both people and businesses.

And unlike old boxes of letters, this correspondence is easily disseminated. Gmail has made me pretty fastiduous about keeping my inbox clear — however, with great search, most people don’t even need to organise their email. What this means is that all aspects of my life — travel bookings, concert tickets, bills, short notes, long catch ups, letters back home from holidays, photos sent, job applications, arguments with my brother, and so on — are being neatly stored and catalogued for the future. No lost filing cabinets, nothing thrown away, no mould or water damage.

It’s a stunning thought really — with Gmail specifically, people are now far more likely to have a permanent email account with enough storage to keep using indefinitely without deleting anything. Imagine how useful this information will be in hundreds of years for researching history.

But there’s the rub. I won’t cover this too much, as data ownership and safety is a much-discussed issue, but what happens when/if Google is acquired or goes out of business? What if they decide to close the account, or they have a catastrophic server failure? I have Gmail offline and Thunderbird to back up my mail (which most Gmail users won’t do), but even in this case, who knows what web browsers and mail readers will be like in the future — even if I own a local copy, will I be able to read it?

Essentially we’ve traded simplicity of archiving for the difficulty of maintaining the archive into the future. Previously you could just take a letter and throw it in an archive box and put it in an attic. You never had to touch it again and it would maintain its state. Now you need to find different ways to keep your data available and safe. In fact it wouldn’t surprise me if we actually end up with fewer sources of archived data, but they will be more complete. It’s certainly interesting wondering how this is all going to shake out…

The difficulty of simple design – part 1

The hardest part of being a designer is choosing what goes into the product.

Deciding what should and shouldn’t go in is actually a very difficult choice.  You don’t want it to be overcomplicated, but you want to have a competitive edge.  Sure, it seems easy — just throw out whatever people don’t need and put everything else in.  Unfortunately every user is different.  I read an article which claimed that people only used 20% of Microsoft Office features, and so 80% should be removed.  Unfortunately, each person uses a different 20% of the features.

So how do you decide what goes in without overloading your product?  The easiest features to be sure about are the ‘standard’ ones.  What are the must-have aspects of your product to make it work?  What does everyone love about your competitors?  Put these in!

The rest?  While usability testing will give you some idea of what people would want or like, a user saying they’ll use something in a usability session does not mean they will actually use it.  To decide what might be used, you will need to use some of your best judgement, some user feedback, but most of all, pick features which are ambiguous.  People will always do surprising things with your product.  How people customize and appropriate a system for their own use is called “articulation work” in design academia, and the more ambiguous you make your design, the more people can appropriate it in innovative and surprising ways.

I think Twitter is a great example of articulation work.  Ostensibly it’s just a status update system.  However, people use it for all sorts of things — microblogging, link sharing, ad-hoc meetings, connecting with corporations, getting the news, etc.  What facilitated this was a simple system with a few key features – such as the “@” and “#” operators, and a real time search.  From these basics, the community began using it in new and unexpected ways.

So when you’re trying to keep things simple and to decide “should I put this feature in?”, wonder “how might this be used in other ways?”  It’s much better to put in one feature which can be used in a multitude of ways, rather than overload on catering to everybody.

However, the question remains — how do you decide which treatment for a particular feature makes it in?  For example, say you allow a user to select something via a drop down or with radio buttons, and both test equally well.  How do you decide which to use without providing alternative methods of interaction?  I’ll cover that in part 2.