Designing Edenbee

designing

What do we do?

I checked with everyone in the office before I came up here: we’re definitely a user-experience design consultancy. So that’s cleared that up.

So before I talk about edenbee, let me give you a bit of context.

So, my name is James.

So this is Clearleft HQ.

In the sunny seaside town of Brighton

Well actually this is Clearleft HQ.

All the other pictures were boring so I picked one with a horse in it.

And this is a horse going in to our next door office.

This happens on a regular basis and we’re still not sure what is happening

Or whether we should report it to the RSPCA

http://www.flickr.com/photos/clagnut/2295246599/

LEGEND

And this is the legend that is Rolf Harris (outside the office).

This makes my wife cry.

http://www.flickr.com/photos/freefoto/639294974/


We spent the majority of our time designing and creating web sites

We do some consultancy kung-fu

We also run an annual grassroots web conference called dConstruct.

Shameless plug: Friday 5th September this year

And we make (or are making) some guerilla usability testing software called Silverback.

This is Steve the gorilla here on the right.

But I’m definitely not here to talk about that. Although I do have badges. Come and see me afterwards.

Whistlestop tour of edenbee.

designing

So back to the matters in hand

designing

anInformationArchitect

stakeon

Or more appropriately, an IA’s take on designing edenbee.

First off, a little bit of background.


Here’s a picture of sheep.

I picked this to represent the kind of thing we want to shy away from when working on projects.

But it was one of the primary reasons I wanted to work at Clearleft. To avoid any kind of herd mentality when starting and running projects.

I’m exaggerating by saying we don’t have a formal process. But rather than a pre-defined collection of steps, instead we’ll adapt to the specific needs of the project.

Kinda makes this presentation hard -- I can't give you recipes to go back and use in your job from the Clearleft process. It changes to suit the needs of the particular job. That’s not to say we don't make it up as we go along either -- but we certainly adopt an adaptive approach as opposed to a prescribed set of steps.



DavePete

Here’s Dave & Pete outside edenbee HQ. Conveniently above a pub.

edenbee is the product of three teams....edenbee + clearleft + new bamboo. crucially both small.

Within Clearleft Rich and I adopt the IA mantle, but in truth all of our skillsets overlap heavily -- we are a multi-disciplined team. We all sit in the same room. We learn collaboratively. Or by osmosis as I prefer to call it.

This is an absolutely CRUCIAL element to the way we work.

Seriously, someone should try and work out how to quantify the gains that this approach brings.

http://www.flickr.com/photos/basil_gilbert/396270430/

Hopefully I’m not talking my way out of any future job for Clearleft but as well as no process, we don’t really do deliverables either.

This is something common to the vocabulary of an Information Architect. The site map, the personas, the user journeys, the wireframes. These commonly shape the project plan.

We use all these things too but NOT to shape a Gant chart.

For me, the very term 'deliverable' has all the wrong connotations. The goal is not to to ‘deliver’.

The process and act of creating “deliverables” is far more important than the documents themselves.

The emphasis for us is a formative one.



http://www.flickr.com/photos/jason_coleman/294790591/

But we are left with a problem....the very nature of our company, as an agency -- the fact that we are a third party -- is that there is an endpoint.

Of course we try to avoid the throw it 'over the wall’ mentality, but at some point we stop getting paid.

As we discovered, it's particularly relevant when designing for community. And this is something I’ll deal with later in the talk.



GUILTY!!!

So the project began back in July of last year.

Ironically my colleague Richard Rutter and I flew over to Dublin so we already had some guilt points to work off.

Just to make things worse, it became one of the only times we were upgraded.

Needless to say this became one of my first entries in my carbon logbook on edenbee.

We tend to call this part of the project -- the discovery phase.

Sounds posh, but basically this meant a bunch of us sitting around a table for two days.

There were a lot of macs -- that was a good start.

It was a great couple of days. It was immediately clear that we were working for a client who were inviting design.

These are crap pictures, but you get the idea...we were here to discover.

We were using disposable lo-fi tools like whiteboards, post-its, cake, Red Bull.

Disposal, non-permanent stuff.

Sketching ideas.

We all recognised the inherent problems at the heart of tackling climate related issues.

One aspect we kept returning to the notion of carbon calculators.

These tended to have a top down mentality. With a few exceptions they tended to be unremarkable.

But there was good stuff as well...they were personal, provocative, they digested and spat out data!

Bad: They felt somehow isolated/siloed, companion-less, unsociable. People visited once and then left.

We became fascinated by the notion of making carbon calculators sociable.

http://www.flickr.com/photos/star_ph-uk/16461704/

They are undeniably intermingled with our everyday lifestyle choices.

The carbon footprint represents the results of these choices -- our stag or hen do Amsterdam. Our modded Citroen Saxo. Or may be our choice to cycle or carshare to work as opposed to drive.

These are fundamental choices within our lives today. They are our a facet of our identity.

Our challenge became to make a carbon calculator -- a sociable one - embedded within our lifestyle

One that not only collects, but also reports, converses, empowers, compares, informs, even advises.



This appealed to our design sensibilities. And by design I don't mean photoshop.

What do I mean by this? Well on several levels really, on a very rudimentary level: what flickr is to photos, what upcming is to events, what delicious is to bookmarks. We wanted edenbee to lay claim to your ecological facet of everyone’s network profile.

As far as we could tell this part of the ecosystem hadn't been claimed.

This represented opportunity, not only for a compelling service.

But also as a means for returning some of this value back in to the ecosystem.

Become a component of the ecosytem.

http://www.amee.cc/

As it turns out being a component of the ecosystem became very important to us.

A vital component of the carbon calculator is delivered not by anything developed by Clearleft or New Bamboo but from these guys: AMEE.

In their own words: "AMEE is a technology platform, designed to be built upon". An API. A small piece to be loosely joined.

For edenbee this represented a means for extracting out CO2 from our everyday actions. Huge simplification, but essentially we give AMEE a reading and it gives us back the corresponding CO2 emissions. This then powers the carbon footprint calculation for every edenbee, as well as the collective community.

But what's so cool about it is...this is an open framework. All the data edenbee contributes goes back in to enrich the aggregate whole

Can't talk more highly about these guys and about they represent how I see the future of the web. Small pieces loosely joined.

As Tom Coates put it, it's about 'doing more than we could do apart'. "An aggregate web of connected data sources". AMEE exemplifies this ethos.

“The fallacy is to think that social networks are just made up of people. They're not; social networks consist of people who are connected by a shared object.”

Jyri Engeströmhttp://www.zengestrom.com/blog/2005/04/why_some_social.html

This is a quote from an article by Jyri Engeström from Jaiku called “Why some social network services work and others don't — Or: the case for object-centered sociality “. Unbelievably it’s from 2005 which makes me realise how smart this guy must be.

It’s something I constantly return to when designing social software like edenbee

We were really excited at the end of the ‘Discovery phase’ as we felt we identified our shared object for edenbee: the ecological profile. The sociality of edenbee would extend from this object.

Our ecological profile: not just our footprint, but also our goals for change. Refer to Juri's post. This sense of object-centered sociality was crucial. Ironically we wanted to avoid over-focusing on social value...strip away the sociality and we still have personal value for our edenbees.

http://www.flickr.com/photos/booddin/116104385/

So I’m going to skip forward a bit and start talking about how we actually realised some of this stuff now that we had a vision an object to build around.

The first thing to mention is that functional specs don't live around here.

At the heart of our design we developed a high-fidelity prototype.

By high-fidelity, I mean interactive, clickable.

There’s lots of ways of doing this, Flash, bespoke tools like Axure.

As a web standards focused company it makes sense for us to use the tools we feel most comfortable and productive using. This means HTML, CSS and JS (heavily jQuery flavoured)

What's our goal here?

And why high-fidelity? Why not just Visio or even paper prototypes?

Well on hte most basic level, this is a means for us to acknowledgethat we're designing experience so let's try and get as close to possible to creating this, even participating in this ourselves.

Well allow me to generalise (a bit more) here but the traditional approaches to IA often follow the patterns of science -- this is one of reductionism.

“Reductionism was the driving force behind much of the twentieth century’s scientific research. To comprehend nature, it tell us, we first must decipher its components. The assumption is that once we understand the parts, it will be easy to grasp the whole.”

Albert-László BarabásiLinked

By looking at the problem in its smaller constituent parts we can then (re)build it correctly.

So to make a huge simplification, for an IA this might be something as simple as ‘we get to know our users, we establish a user's goal, then build him or her or her a path to reach that goal, maybe with a few sign posts to help them along the way.

Typical wireframes deal with this by capturing one representative user path through the system.

But this is unrealistic when it comes to the demands of modern web development.

A web page can take many different forms depending on whether the user is say....logged in, or whether they need some extra feedback after interacting with a widget.

Let's think about this from a micro level.

A traditional wireframe -- say something from Visio -- is less concerned with the behavioural level of the interface. More about structure.

But this isn’t practical in a day when micro-interactions are so fundamental to our experience of a website.

Behaviour is so important -- we wear it on a t-shirt!

Ajax is clearly responsible for a lot if this....as soon as you start updating web pages without page refreshes, you lose the native feedback mechanisms of the technology.

And this means you need to design these yourself.

Remember we’re no longer just talking about a mouse click, we’re talking about ALL the various events on a page, mouse over /blur / focus / drag & drop etc... Traditional tools such as Visio just don’t have the capacity for capturing this stuff effectively.

This is a big reason for us using high fidelity prototypes

Equally on a macro level: we can't afford to build a site purely from an examination of it's component parts.

We need to understand the interaction that happens between them.

This is even more true of social software.

Building one representative user path through a website is no longer good enough.

There is no longer an idealised version.

Our UIs need to be be adaptive...to accommodate the behaviour that emerges through their use.

This image is from the Facebook dev wiki where they’ve been demoing some of the changes for their next big release. There’s huge amounts of customisation going on. Users now get the chance to customise the tabs that make up their site. Basically giving the user the opportunity to play with the information architecture of their site.

This level of customisation is more akin to a game than a website.

But capturing this level of diversity in the form of paper wireframes is kind of hard work.

Apart from anything else, the number of wireframes (and the effort that would need to go in to that) makes them redundant as a tool for communicating design decisions.

A high fidelity prototype allows everyone to participate (devs, IAs, clients), It has universal appeal.

And most crucially USERS.

One of the greatest benefits we’ve found to high fidelity interactive prototypes is the potential for early-stage usability testing.

We’ve had phenomenal results with this, even to the point that we’ve been able to iterate through versions of the site during testing itself.

If there was one reason for doing this stuff, that would be mine!

Get yourself some cheap usability testing software...anyone know any?

Butwait!

There's a big BUT here. This isn't perfect.

I want to highlight some of the tensions here that are really important when designing social software.

Let’s face it, it would be arrogant to think we could design a community. Orwellian.

Especially one which is founded upon a bottom-up mentality.

Communities design themselves.

“Riding reductionism, we run into the hard wall of complexity. We have learned that nature is not a well-designed puzzle with only one way to put it together...Yet nature assembles its pieces with grace and precision...It does so by exploiting the all-encompassing laws of self-organisation, whose roots are largely a mystery to us.”

Albert-László BarabásiLinked

Let’s return to Barabasi.

This is the continuation of the reductionism piece I read earlier.

Barabsi is talking about the laws of nature, but the pattern applies to networks as well. In fact, the book that this quote is taken from is all about networks and network theory.

The crucial word or words here is self-organisation

And this is what we need to be mindful of when we’re designing FOR a community.

IAs tend to argue incessantly about their job titles. It annoys the shit out of me. Personally I think I’d prefer to be a web designer.

Interestingly this is where my role or at least my job title has a direct comparison with traditional architecture.

We create the spaces and objects within which people interact, but the actual interactions themselves are reserved for the inhabitants of this space.

It is from here that community emerges.

If I can use an analogy here. I'll need to borrow a lovely term from Will Wright: the possibility space.

I've always been a massive fan of Will Wright’s games and what characterises them for me is that feeling of open-endedness, that you can do ANYTHING, there are no boundaries.

It's the place that Wright refers to as the possibility space.

The algorithms that sit below the game’s surface are designed to encourage exploration of the possibility space.

Rules that foster emergent behaviour.

http://www.flickr.com/photos/yersinia/230046745/http://www.flickr.com/photos/philgyford/20553280/

I love these pictures of desire paths.

Defined in Nick Crane’s book 'Two degrees west' as the imprints of 'foot anarchists', individuals who had trodden their own routes into the landscape, regardless of the intentions of best-laid plans. There’s Flickr groups set of for this kind of stuff.



http://www.flickr.com/photos/yersinia/230046745/

I like this one but it begs the question why would anyone would want to take a shortcut to Lidl?

Must be the people coming out rather than going in.



http://www.flickr.com/photos/yersinia/230046745/http://www.flickr.com/photos/kake_pugh/1307255998/

But I show them here as representations of emergence.

An this is where I want to return briefly to the point I made earlier about the problems that agencies have when they reach an endpoint.

To design FOR a community we need to design WITH the community.

Allow the community to emerge like these desire lines do. But this is a challenge for us when at some point we throw our work over the wall.

I don’t really have answer for this yet. At the moment we mitigate this by working long after the launch with our clients, helping them build a team to manage these things themselves.



Image credit: From Sinai Hotels, by Sabine Haubitz and Stefanie Zoche of Haubitz+Zoche.

I was recently involved in the beta test of a new piece of social software that had EVERYTHING. Features everywhere. Groups, forums, walls, internal messaging, poking, nudging.

The aggregate effect was poor though...all it did was dilute the community rather than enable it.

As well as dilute any sense of object-centered sociality. It was to such an extent that I didn’t really know what the site was about.

It would be unfair for me to show the site in question so I thought I’d show you some pictures which reminded me of it.

Or at least it’s future.


These are pictures of abandoned hotels on Egypt's Sinai Peninsula.

Rather perversely, I find the pictures kinda mesmerising


The pictures were captured by Sabine Haubitz and Stefanie Zoche and then subsequently documented by Geoff Manaugh from BLDGBLOG


Manaugh describes these as “monuments to failed investment”.

“The hotels now look more like "architectonic sculptures" in the desert...or derelict abstractions, as if some ageing and half-crazed billionaire had constructed an eccentric sculpture park for himself amongst the dunes.”


It reminded me of the dangers of not focusing on your central object.

that edenbee needs to do one thing REALLY well and if the demand for social tools to facilitate this emerges, than look to satisfy those needs.

Design FOR your community.

Future?

Edenbee is not yet embedded in our lifestyle. Entering carbon data isn't much fun. Perhaps we need to make this more playful? Needs to aim towards ubicomp type values. In the course of ordinary activities, and may not necessarily even be aware that they are doing so. Watson. Toyota Prius. iPod jogging? "technology dissolved in the city" (Chris Heathcote's blog)....It doesn't do this yet

There is no API. Well not officially...

WE could benefit from more 'play'

Thankyoufor

listening



WE could benefit from more 'play'

Comeandseemeat:

http://edenbee.com/

Fantastic potential

We’re hoping to work with edenbee again.



Technology

Designing Edenbee