City Tickets – a possible ecology

City Tickets would most likely exist as part of a wider ecosystem, being only one element among several touchpoints of a service. I thought it might be interesting to sketch out some of those, and explore how they might work together.

When I was working on my thesis project at CIID, I focused both my thinking and the tangible design work on the specific service of city tickets, printed receipts available from parking ticket machines. Focusing so tightly on the single aspect of receipts from ticket machines was a strategic decision for the project, to make sure it was clean enough an idea to be communicated clearly, and to focus both efforts and attention on the parts that were new and interesting, and I’m very (!) glad that I did that. But it’s also fun to let my mind off the leash a bit, and see how that single element might fit into a bigger (and more complex, messier) ecosystem. The short version:

• City tickets from parking ticket machines, as I’ve proposed them in my project.
• City tickets from other sources that already give receipts: stores, supermarkets.
• Mobile applications (plural, varied)
• Phone (voice; human operated)
• SMS and MMS
• a website

Each of those has its own strengths and weaknesses, and they don’t all have the same capabilities or features. But working together, they fill in the gaps (of geography, demographics, technological opportunity) left by the others, and thus make a much tighter and more powerful system.

I’ve often been asked why I hadn’t simply designed an iphone app instead of using parking meters. In some ways, it’s a reasonable question, and an iphone app could functionally do almost all – and more – than can be achieved using printed receipts from parking machines. But I think there is great value in designing a service that is for all – not just those who have iphones or smartphones – and embedded in the physical urban fabric – here and now, where and when it’s needed.

Services like 311 already exist (notably in NY and SF), and initiatives such as Open311 take a great stab at proposing and creating an open and extensible backend, which has already spawned a bunch of exciting services and applications that, in essence, already do what people are asking for when they ask why I didn’t design a mobile application instead.

City tickets from parking meters can come pre-printed with hyperlocal maps, and don’t require any additional hardware (ie, you don’t have to own an expensive phone), and can be filled in using that great technology, a pen – with all the freedom to scribble diagrams or annotate maps that come with it.

But an iphone or other smartphone app can work where parking meters are less common, and can more accurately pinpoint your current location; although it puts the burden on the user (citizen), the fact that any text is typed removes the hurdle of messy handwriting. Photos of the location or issue can be included in the report, perhaps removing the need for a scouting trip by the local authority to determine what resources are required.

Existing 311 systems let you phone in and talk to a real person, which lets issues be immediately be routed to the right place, and you get immediate feedback that it’s being in some way dealt with. Other options are SMS (short, text only – send in your location and basic information on the issue), and maybe MMS (short text, and also including a photo of… something relevant), which open many possibilities to many people (who, again, may not have expensive smartphones), as well as very immediate feedback.

Receipt printers in every shop and store in every city are another example of a potentially magnificent infrastructure, basically just sitting around. City Tickets very similar to the ones I proposed from existing parking ticket machines could also be available from kiosks, corner shops, post offices, and supermarkets. In Copenhagen, each of these already has a custom-ish receipt printer that lets them sell mobile phone credit – the receipt you get also has instructions, and a code to put the credit on your phone, etc, in addition to being a receipt and telling you how much it cost. The same thing goes for the National Lottery receipts you get in the UK, which tell you which lucky numbers you selected. There’s no reason these can’t also print other things, if you ask for it; or maybe every receipt has a city ticket bit attached or on the back. It would be interesting to think about how they might be different to the ones I designed for the parking ticket machines – would the map be the same scale? Would there be different fields to fill in, depending which type of store you got it from? Would it be co-branded with the store? Would the same store also work as an additional ‘input’ location, which I’ve currently defined as post boxes. See also BERG’s lovely exploration of the possibilities of microprinting in their recent videos.

An obvious element (that I didn’t even talk about as part of my project, but in my mind was always kind of implied) that is also worth highlighting is some sort of web-based access to all of the data in the system – a way of marking a spot on a map and reporting issues, a way of looking up a specific issue (“what’s the status of problem #6912?”), and a way of looking up what’s known for a specific location (the equivialent of a city ticket todo list, ie “what’s known near machine location #3129?”) or, more human-friendly, what’s known near an arbitrary street address or postcode?

But the key point, I think, is that these approaches are not mutually exclusive. Indeed, I think city tickets as I’ve proposed them could (and should) happily co-exist with an iphone app, and a phone service, and a website, each with their own strengths and weaknesses, and each catering to different needs, times, and people. If the backend system – database, API, data formats – are designed to be sufficiently open, then practically infinite ways of accessing, contributing to, and building on the municipal information could emerge, though many different media/channels, including ticket machines, iphones, and more. (As an aside, I love Kevin Slavin’s description of the incompatible 311 systems in different American cities as having evolved ‘data dialects’ in his talk in Barcelona earlier this year.)

Some or all of this exists in various forms, but it becomes a different beast when all the different parts are interconnected: submit something from a ticket machine on the way home from work; check the status online a week later during an idle moment; maybe follow up with a phone call to complain at the slow response. But as with many things, an ecology of different channels, media, touchpoints, flows and connections can be much more powerful than any single one in isolation.