UpMyStreet Conversations

This is a transcript of a talk I gave at O’Reilly’s Emerging Technology Conference (ETech) in 2003, lightly edited for readability.

I’m Tom Coates, and I’m going to be talking about UpMyStreet Conversations.

Stefan Magdalinski was originally going to give this talk. He was my boss, UpMyStreet’s CTO and the person who first conceived Conversations. He would have said more about the high-level idea and his work with mapping.

Unfortunately, UpMyStreet had just gone into the UK equivalent of Chapter 11 and Stefan needed to be there. So I spoke instead, concentrating on designing Conversations as a working piece of social software and on the consequences of integrating geocoding with discussion boards. At the time, that was my job: I was UpMyStreet’s Communities Producer.

The question I’m going to attempt to answer is: What happens when you tie web social software to precise physical locations?

Before getting to that, we need some background on the purpose and intentions of UpMyStreet Conversations, and that means explaining a little about UpMyStreet itself.

Some background on UpMyStreet

With UpMyStreet, you type in your postcode and receive a page containing information pertinent to your local area. The data came from a wide variety of sources: government statistics about crime and street cleanliness, a directory of local businesses, classified adverts, house-price information, political representatives and much more.

All of this information was presented on one substantial page. It was an unorthodox approach, but it worked for people: they received a comprehensive, comprehensible and printable overview of their area immediately.

The data was organised in two ways. Sometimes the geography had clear boundaries. If you wanted to find your political representatives, we could check your postcode against a list of who looked after which areas and return the appropriate names.

For local resources such as schools, childcare or doctors, a “Find My Nearest” approach worked better. It returned the closest results regardless of administrative boundaries. The search therefore never came back empty. That was the approach we decided to take with Conversations.

How we geocoded it

UK postcodes gave us a logical and comprehensible way to aggregate location. We could not do that reliably with street names: there is more than one Oxford Street in the country, while a postcode refers to only one area.

There were roughly 1.7 million postcodes, and each covered an average of about fourteen houses. That made them granular without becoming unmanageable. Location-based software does not always need accuracy to the nearest metre.

Postcodes also have a meaningful nested structure which people understand: an area contains districts, sectors and individual delivery walks. Almost everybody knows their postcode. In low-density parts of the country the postcode areas become larger, which was useful when looking for similarity between places even if it was less useful for close conversation.

ZIP+4 codes might have offered a basis for a similar model in the United States, although they were not nearly as commonly used or understood. Intersections and city blocks might provide another route to comparable granularity.

This diagram gives a sense of the granularity and density of postcodes across Greater London.

Closer up, these are individual postcodes. The boundaries are small enough to describe a very immediate neighbourhood.

This is not the same as using ordinary US ZIP codes. At the time, there were only around 33,000 five-digit ZIP codes, each containing an average of roughly 8,600 people. The more precise ZIP codes were not widely known by the general public.

The UpMyStreet ethos

One of the things we were interested in at UpMyStreet was encouraging civic engagement and connecting the dots between different parts of people’s lives.

A dream scenario would be that somebody arrived to see how much their house was worth and discovered that, despite paying more tax, their street was dirtier than the national average. From there, they might seek out their elected representatives and try to get their voice heard.

That journey was possible because people had detailed local information about their area. Civic engagement starts locally.

A local site for local people?

People did not only receive information about their area. They could also learn something about the other people who lived there. Location provides a useful first approximation when you are trying to understand a group of people: you can begin by looking at the other residents of the same place.

The ACORN profile shown here assigned detailed demographic information collected by marketing agencies to individual postcodes. Reading it could be disconcerting and invasive, but the information was already available to marketers, so we did not see why it should be withheld from everybody else.

The profile also revealed that people generally had much more in common with their neighbours than with random strangers. Their children went to the same schools, they used the same roads and public services, and often visited the same cinemas, arts venues and shops.

We knew that people in a neighbourhood shared a great deal, and that good things could emerge when they communicated. Given UpMyStreet’s interest in local civic engagement, we found ourselves asking a simple question.

How could we help neighbours talk to one another?

The answer became UpMyStreet Conversations.

What was Conversations?

Conversations was a geocoded message board. Every threaded conversation had a specific geographical location, and the service was designed to help people “meet their neighbours and discuss local issues”.

It was a geographically organised community: show me the nearest conversations to a particular place, within a particular span of time. Conversation density followed population density, modified by the sphere of interest around each subject.

Locating yourself

The walkthrough began with a postcode. You located yourself by typing in the place where you lived or the place you wanted to examine.

Putting a flag in the ground

When you started a conversation in that postcode, it was like putting a flag in the ground.

We looked at many possible models: conversations that moved across the country, threads that grew in geographical scope, multi-subject areas and different conceptions of time. Gradually, we moved towards this direct and comprehensible model.

Seeing nearby conversations

People in neighbouring areas then saw the conversations nearest to them. The interface did not require everybody to share a single national view of the board; each person saw the service from their own location.

What people talked about

People used Conversations to organise real-world social events, gather information about other areas, debate local politics, and discuss national issues with their local communities.

The conversations ranged from moving house and crime in Maida Vale to Iraq, book clubs and small favours between neighbours. Some were intensely local; others used locality as the social context for a much wider subject. We were interested in how the service could encourage more of both.

Why then?

Online discussion of real-world activity was not new, and neither was location-aware or geocoded content. What was new was the ability to combine them practically.

Clay Shirky had discussed how the internet made it easy to form communities around interests. Geography offered another organising principle. But a geographically organised community only works when enough people in the area are online. It depends on critical mass, the ratio of readers to contributors, and sufficient user density. In short, it depends on ubiquity.

Having seen why and how Conversations was built, we can return to the original question. What actually happens when you tie web social software to precise physical location?

Three issues emerged from geocoding every conversation which would not have appeared in the same way on a traditional message board: privacy, time and moderation.

These were not abstract concerns. They were problems we encountered while building Conversations and had to resolve in the product itself. To a greater or lesser extent, they are likely to recur in any service built around geolocated user-generated content.

Privacy: people’s locations

The most obvious problem with asking people to discuss their local area on a geocoded board is that they may have to compromise their privacy. In effect, you can end up associating their opinions with their home postcode.

Imagine the consequences of a violent online argument if the participants knew where one another lived. UK postcodes are remarkably precise, intuitive and well understood, and they are often the basis for street-map services. Typing one into a map can show almost exactly where somebody lives.

There were several places where the software might inadvertently expose somebody’s location. Profile pages were the most obvious. We could not stop people intentionally posting their address, but we could ensure the product never forced them to do so.

Showing location had legitimate contextual value. It helped other participants understand somebody’s background, the issues in their area and whether they were qualified to comment. We could preserve that value by pulling the focus out from the full postcode and displaying a larger named district instead.

Privacy: proximity to conversations

Proximity was trickier. Our early work showed that knowing whether somebody posting in an area was local genuinely helped. People decided whom to believe and whom to listen to on that basis; local allegiances formed and irritating outsiders could be ignored.

But if a participant shared a postcode with a conversation, particularly one they had started at home, the two locations became inextricably connected. We again used obfuscation, this time by setting a lower limit. The closest distance the site would display was “less than 200 yards”.

That was imperfect. Two hundred yards can encompass many people in a dense city such as London, but far fewer in the countryside.

Privacy: the location of conversations

The third issue was the conversations themselves. We did not lose much functionality by obscuring user postcodes and very short distances, but the location of a conversation was more fundamental.

The person starting a conversation placed it in a specific area. That postcode was often their home postcode, and their first message might make that obvious. Yet communicating the precision of the location was one of the principal purposes of the service: the product needed to feel genuinely granular.

The best compromise we found was to communicate obfuscated precision, showing the beginning of the postcode while replacing its final two characters with Xs.

The details here were specific to Conversations, but the lesson was general. Protecting individual privacy is fundamental to any real-world geocoded user-generated content, whether the location is expressed as a postcode or as latitude and longitude.

If you are building for the general public, you have to think hard about protecting users from real-world abuse.

Time and space: then and now

Most social software quietly relied on time as its primary organising axis. A conventional message board ordered threads by when they were last updated. It did not matter when a thread began, only whether it remained active.

MetaFilter took a slightly different approach. Its emphasis was on discussing timely events in a timely fashion, so the most recently started threads remained at the top even if older discussions were still receiving replies.

Both plotted ongoing conversations on an axis with “then” at one end and “now” at the other.

Time and space: there and here

UpMyStreet Conversations was doing something different. Rather than equating relevance with timeliness, it equated relevance with proximity.

Its fundamental principle positioned conversations not on an axis from “then” to “now”, but from “there” to “here”: show me the nearest conversations to this location.

What happens when time is no longer primary

Losing time as the primary axis also meant losing several useful properties of a conventional board.

1. People were no longer naturally directed towards new threads and could not easily tell when discussions they cared about had been updated.
2. Unpopular threads did not fall away. A local area could become surrounded by a wall of boringness.
3. An active, interesting conversation could become difficult to find simply because people had started less useful threads nearby.

Compensating for the loss of time

We built several features to mitigate those effects.

1. Thread tracking. Subscribing to conversations created a useful list ordered by the most recent update, so threads were not lost and people could see when something changed.
2. Reply indicators. The number and timing of replies drew attention to newly active discussions.
3. Email alerts. By default, people received a daily digest when their conversations had been updated.

These restored some of time’s useful effects, but we still needed to reintroduce temporal organisation more directly.

Reintroducing time as a filter

The revised principle became: show me the nearest conversations to this location which have been updated within a chosen period.

Time returned not as the main sorting axis, but as a filter. People could move to a shorter period to focus on recently active conversations, extend the range to recover discussions that had disappeared, and choose their own definition of thread freshness.

The axis of here and now

This fused the familiar “then/now” model with the “there/here” axis at the heart of Conversations. At one extreme, you could see very recent activity spread across a large area. At the other, you could see highly local discussion over a longer period.

The result was a surprisingly powerful navigational aid operating on an axis between “here” and “now”. At the time, we were still trying to find the clearest way to explain the power of those simple time controls to users.

If you remove time as the primary axis by which an online community is structured, you have to find other ways to compensate. Those compensations may themselves have side effects.

Moderation: local problems

The moderation argument was simple: when the community became local, moderation became a local issue too.

Moderators did not share a single default view with every user, which made problems difficult to prioritise across the board. The service was potentially vast: a high national volume of posts could exist without overwhelming any one local community.

Different standards of appropriate behaviour could emerge in different places, since an interest-centred community was more likely to attract people with similar attitudes. And one loud troublemaker in a small area could completely pollute local people’s perception of the whole service.

Moderation: local solutions

To find problems, we had to rely partly on local people telling us about them. Every thread included an invitation: “Help keep this site useful, informative and fun. If this thread is inappropriate, let us know.”

To help communities establish their own standards of behaviour and governance, we also developed a distributed moderation system. At its core was a process called “Find My Nearest Moderator”.

Local problems needed local solutions.

The moderation problems created by a locally organised community could only really be solved by devolving moderation to the local level as well.

What came next

The same model could support many other communities: parents and babies, political activists, networks of fans, newspaper readers, political parties, charities and fundraising groups.

Some examples we discussed at the time ranged from highly local services to communities such as Westlife fans, Gaydar or Punternet, where geography and a shared interest could intersect in different ways.

Extending the model

The model could extend beyond message boards. We imagined collaboratively edited local calendars tailored to a particular area, tools that helped bridge online and offline groups, and spaces where forums organised at different geographical scales could collide with communities organised around interests.

Enmeshed with the real world

“The future of projects on the internet — and geocoded projects are the first good example — is to be enmeshed with the real world, not parallel to it.”

Models already existed for online discussion about the real world. We had experience and working models for geocoding. The final missing ingredient was ubiquity: enough people online to make combining those things practical.

And that was the conclusion: go and build things.