Category: Four pillars

I’m sure there are better ways to decompose social networks, but in my simple mind, there are only a small number of fundamental components:

• directories and address books (you need to find the person or group you’re looking for)
• profiles and CVs and suchlike (there has to be some way of describing the person or group)
• communications infrastructure (you need ways to talk and listen and exchange messages)
• scheduling infrastructure (you need ways to agree times and places to meet)
• event notifiers (you need ways to spread news and gossip)

All these then get wrapped into a larger infrastructure, which covers four other things:

1. an ability to identify oneself
2. an ability to personalise the experience
3. an ability to have Four Pillars support (search, syndication, fulfilment; we already have conversation)
4. an ability for developers to add applications

In a way that’s what Office and Exchange and Outlook was about. In a way that’s what Bloomberg was about. And in a way that’s what Facebook and even Twitter are about.

This is an emergent and evolving space, but only in a narrow respect: communities have been around a very very long time; communications processes have also been around for a very long time. What has changed is the following:

• communications tools are becoming ubiquitous, especially with the web and mobile devices
• communications themselves now persisted digitally (allowing efficient archival, retrieval, search and syndication)
• the tools and the modes of communication have become more affordable

As a result, there’s a lot of learning to be had. Some people are concentrating on the interactions within the communities, the social graph as it were. Some are concentrating on movements: take a look at this article, published in the latest issue of Nature, and building on a theme established by a number of essays written by Barabasi and Gonzalez et al over the last couple of years); some continue to focus on the ownership, privacy and portability of the information. Yes, there’s a lot of learning to be had.

From an enterprise context, the learning takes on one further dimension. Enterprises have always been about walls and perimeters; now, as the walls become more and more porous, as the enterprises extend beyond their traditional boundaries to their customers and supply chains, communities become alliances, they become ecosystems, they become groupings of what Venkat calls “network-based competition”.

Yes, there’s a lot of learning to be hard.

Me, I’m utterly fascinated by one small piece of this overall puzzle. Alerts, event notifications, status messages, whatever you want to call them. Maybe it’s the old journalist in me. That’s why I loved the mini feed in Facebook. That’s why I loved Twitter.

And now, as I see more and more tools that help scrape information to do with events, I find myself going off at a tangent. Realising that we’re going to get overloaded by such messages (remember what happened when people started connecting Twitter to their Facebook status messages?); realising that current tools are already being stretched; and realising that the historical response (aggregation and summarising) is inappropriate.

I think we’re going to see an explosion of activity in the status message related tool space, with two different sets of tools. One to do with personal “manual” input, one to do with automated input. In both cases, I think we’re going to see this explosion connect with a similar set of explosions in the visualisation space, so that we see more colour, more heatmaps, more timelines, more fractal representations, more radar diagrams, more tag-cloud-like diagrams …… but all to do with status messages.

Status messages with a difference. Not aggregated, not summarised, but built around a capillary-action publish-subscribe model. Truly personalised.

That’s provisional enough. Now I wait for the comments so that I can learn more about this.

“Whatever you do, don’t tell me the result, I don’t want to know”.

Thus goes the refrain.

The refrain of people with a new problem, a problem that was nascent for maybe thirty years, but one that’s been maturing for nearly a decade, and is full-blown now.

A problem caused by time-shifting.

More and more people record things for viewing later; many of the things recorded are contests based around elimination: knockout tournaments, Cup finals, boxing matches, Come Dancing, X Factor, Who’s Going to be <Pick One from : Maria, Joseph, Oliver, Nancy,> the list goes on.

And once they’ve done the time-shifting, they’re trapped. They don’t want to know what happened. Not until they get the time to watch what they recorded.

They don’t want to know what happened.

Now there’s a real challenge for news personalisation. Letting me pick the things I specifically don’t want to know about. So when I get my paper online, I should be able to pick the things I want to hear about (my preferences), the things that my community’s doing (my news feed, as it were), the things my community recommends for me (actively and onymously as well as through profiling and collaborative filtering).

Filtered, of course. By my choice of filter. Shaken, not stirred.

And explicitly not containing things I didn’t want to read about.

Possible? Likely? It’s happening now.

So what next? I can just see it. In ten years time they’re going to be saying: Don’t tell me who won the election. Don’t tell me who won the war. I might want to go back and watch it.

I’ve just got to Shanghai for the first time, and despite working through what passed for night in China and in the UK, I found myself bright-eyed, bushy-tailed and full of beans. Having been ensconced in design strategy papers for a good few days, I think I’m looking at everything through “design” eyes, and trying to make sure I’m not jaundiced in any way.

The first thing that made me feel good was the socket (or what I used to call a “plug-point” in India). At the hotel here, they have sockets that look like this:

Wikipedia (which is where I got that illustration, by the way) tells me that this is a Type G (British 3 Pin) plug and socket, conforming to BS 1363. Which means I didn’t need an adaptor for once, a nice feeling. Strange, that I have to come all the way to China to get that feeling. Incidentally, just take a look at this map, available from Wikimedia Commons:

What the map does is set out the plug type in use in a given region, and it’s interesting to see some sort of colonial history laid out in the process. We’d probably get something similar if we looked at rail gauges, I guess, and I can’t help worrying that there’s an internet variant just waiting for us, a 21st century map of standards and protocols that reflect colonies of lock-in.

Enough worrying. There are so many things in this hotel room that make me feel good, that make me realise that someone’s applied thought to the design of the room, that someone’s actually considered what the customer may want.

There’s the ethernet point just where you would look for one, built subtly into the desk and covered with a little removable leather pad; there’s the cups and saucers and tea bags loudly signalling the existence of a kettle somewhere, and the kettle turns out to be where you would look for it, and the socket turns out to be where you would look for it. And the tea bags included a selection of green tea and jasmine. Something I guess you would expect in China, like the torch thoughtfully placed in the wardrobe almost at eye level.

Lots of little things that show that someone thought about what people want. My favourite is the wardrobe itself. It’s in the usual place, to my right as I enter the room, along the passageway to the area where the bed and desk are. What makes it special is what they’ve done to the back of the wardrobe. Sliding doors, accessible from the bathroom. Now that is useful. And simple.

Putting things where people would intuitively look for things. Looking at, and catering for,  all possible uses when designing something. Using open standards wherever possible. Building things with the customer in mind, actually thinking about how the customer would use something. Precisely how. Thinking about where a customer’s eye would fall, what his reach would be.

When we design systems, there is much we can learn from people who take customer service seriously. Like the hotel in Shanghai I happen to be staying in.

Ever since Joel Spolsky and Jeff Atwood announced StackOverflow, almost counterintuitively, I’ve spent more time reading their individual blogs.

I really enjoyed Jeff’s latest, Crash Responsibly. [Even though it is not the headline I want to see just before boarding a transatlantic flight.]

I love the four “rules” Jeff puts forward, particularly the first one: “It is not the user’s job to tell you about errors in your software”. Even in perennial beta environments, what we have to provide is software that works, even if the functionality is very limited. Providing additional functionality incrementally is fine and dandy, everyone understands that. But the software has to work in the first place.