Experiencing Digital

Last night I went to the new Digital Revolution exhibition at the Barbican, and a few weeks before that I went to the Digital City event at the Museum of London. Both events ‘digital’ as a theme, and had a variety of different exhibits to see or take part in.

At Digital City there was an art installation using receipt printers to print out machine-transcribed recordings, an LED screen which displayed waveforms of audio recordings of tweets collected during the Olympic Games, a life drawing session which invited people to either sketch a human model or a video project of the same model, and a silent disco.

At Digital Revolution there’s a room of early computers and early computer games/software (many of which you can play), a section looking at the CGI in the films Inception and Gravity, several new art installations using projection, sensors and computer graphics, a 3D printer, an installation/song by will.i.am, a section where you can play some contemporary computer games by indie producers, and, downstairs in The Pit, an impressive installation using lasers and smoke machines to create lightforms you can interact with.

In short: both were a collection of disparate exhibits, some more engaging that others. Both times though, the overall experience was less the sum of its parts.

I think this is because digital, on its own, simply isn’t coherent or meaningful as an exhibition concept. I can see why both organisations might feel the need to ‘do digital’, but in the absence of anything else, it makes about as much sense today as doing an event about ‘canvas’.

The Barbican event describes itself as a “the most comprehensive presentation of digital creativity ever to be staged in the UK” - a noble ambition, but one that it’s bound to fall short on (there's only so much space, after all). It would have been more interesting, I think, to focus on a particular form (video games perhaps, or digital film, or art apps) or, to maintain a multidiscipline focus, a particular subject (conflict, or privacy, or time travel).

The vague notion of digital is particularly highlighted by exhibits where the digital-ness isn’t really the point. A silent disco might use digital codecs to encode and transmit the audio, but it could equally have used an analogue FM-style signal. Similarly, the lasers-and-smoke installation at the Barbican may use computer software to interpret the sensors and drive the laser projection, but this is invisible to the audience, and it’s at least conceivable that the effect could have been achieved with non-digital technology.

There’s plenty to be excited about within the realm of digital technology, but I’d like to see arts organisations treat ‘digital’ less as a novelty, and more as a regular part of their programming.

Culture Hack Data

I’ve been working with Culture Hack recently, on a project exploring open data for arts, culture and heritage organisations.

That’s a topic quite familiar to me, as it’s something I discussed quite a bit whilst working at the Science Museum, many moons ago (I don’t think we used quite that term, but the idea was the same). So it’s been interesting to see how things have changed since.

Culture Hack is a programme run by Caper (and Sync in Scotland) which brings hackers together with arts organisations to build prototypes and hacks, usually over the course of an event. I attended the ‘North’ event in Leeds a couple of years back.

One issue that developers have faced at the events is knowing what data and content is available. This has sometimes been addressed this by distributing USB sticks with links, spreadsheets and data dumps on them. That’s okay in the short term, but isn’t ideal.

Thanks to some funding from the TSB, Culture Hack commissioned me and Kim Plowright to create a new web resource listing and describing some of the best cultural open data out there.

The site launched last week, and is visible at data.culturehack.org.uk

Culture Hack Data website - showing a search box, filters, and some example results
The Culture Hack Data site

When planning the project, we didn’t want it to be a complex database. Instead, we’ve kept things simple. Our aim is to get people to the actual data as quickly as possible, and to describe the sources well.

The data sources are curated into eight broad categories: art, literature, music, performance, fashion, design, media and history, so if you’ve got a particular interest in one area, it’s easy to see what’s available.

A second key factor we identified is the size of the dataset. This is crucial if you’re in a hurry (at a hack event, say), as dealing with huge datasets requires a different set of tools (and often, more time) than smaller datasets, which can often simply be manipulated within spreadsheets. So we classify datasets into Small (less than 10 thousand records), Medium (10 thousand to 1 million records) and Huge (more than a million records).

We’ve also labelled datasets with the formats they’re in (e.g. XML or JSON), and the rights they’re released under, such as the various Creative Commons licences.

Where possible, we’ve included a sample of the data you can download too. This is especially useful for datasets you have to register to access.

We’ve included all the relevant sources that we know of, but the list will build over time. Thinking about ways for people to contribute was one of the trickiest aspects of the project, and I was keen to avoid building lots of authoring, editing and moderation features without knowing how the site would be used.

Instead, we’ve opted for an approach of accepting quick suggestions via e-mail (or Twitter), and for more involved collaboration, pointing people at the Github repository where all the code and content is hosted.

Using Git for managing content is a bit of trend – it’s a way of getting full version control and change tracking, without needing complex CMS interfaces. There’s also a growing ecosystem of apps, GUIs and tools around it (and GitHub). In particular, we’ve experimented with using prose.io – a lovely stripped-back editing interface for GitHub files.

Of course, Git is pretty developer-centric at the moment. Whilst that’s the main audience for the Culture Hack site, we also wanted to encourage participation from the institutions themselves. To this end, there’s some instructions on using GitHub, which hopefully take people through the process step-by-step.

One final quirky note about the project: we’ve given each dataset on the website its own numerical ID, which you might notice in the URL. Rather than simply start from 1 though, we’ve using ‘Artisanal Integers’. This is a fancy name for a simple idea: a collection of web services which generate unique numbers on request. This is useful because it avoids us accidentally assigning the same number to two datasets (which might happen if two people are adding pages at the same time).

Finally, in the spirit of open data, all of the metadata on the site, as well as our descriptions, are all freely available without copyright restrictions.

Building a mobile guide to Ironbridge at Museomix 2013

I attended Museomix this weekend. It’s a sort of hack weekend, but in a museum, and where the output might be an exhibit, as well as perhaps an app or a website. The name and structure originated in France, and this was the first UK version.

The event was held at the Enguinuity museum near Telford in Shropshire, a hands-on science museum. It’s part of a wider group of museums dotted around Ironbridge Gorge, which is promoted as the “birthplace of industry”, largely because it was here that the technique of mass-producing iron using coke was invented. Iron was smelted in huge blast furnaces, one of which is preserved at the museum as the 'Old Furnace'. Also along the gorge are museums about china, tiles, tobacco pipe making and a recreated Victorian town. And there’s the Iron Bridge itself, built in 1779 and Grade I listed, which gives the area its name.

I arrived on a frighteningly early train on the Friday morning, and the first activity was a short tour of the immediate site. Then it was straight in to pitching ideas and forming teams. This was a bit of an abrupt beginning, as we’d not long arrived, but I had come with a rough idea to work on. Knowing how much the area itself contributed to the experience of visiting the museums, I figured it’d be a great opportunity to explore building something for mobile.

I’ve been talking to museums for years about the opportunities of mobile, but with a few exceptions, most museums have given more thought to the use of mobile devices within the museum than out in the wider world. This seems a bit wrong-footed to me, as once you’re within the museum walls there are already so many exhibits and panels and screens to give your attention to. Outside of the museum is a different story. There’s also a bigger audience outside the museum than in it, and the possibility of having a longer relationship than a one-off visit. This is especially true of museums whose subject is an area, as those stories relate to the landscape as much as to collected objects and artefacts.

My proposal at Museomix was to build a mobile guide to Ironbridge, using simple, proven web technologies, and to focus on including content that visitors really wanted to know. Despite this being the least sexy idea presented, I was relieved that my enthusiasm and spiel was enough to collect together a team of interested parties.

Once set up, we dived straight into an initial research phase of looking at maps at the area and identifying possible forms that the content could take, from audio commentaries and video interviews to simple text descriptions and historic photos. And then I insisted we all go for a walk.

We had a curator on our team, so our walk consisted of noticing interesting things and grilling the curator for information. Crucially, we asked some passing visitors some questions: what were they confused about, and which things had aroused their curiosity.

This walk taught us two crucial lessons which would shape our project. First, there was a LOT of interesting things to look at. The museum yard was littered with bits of iron and mechanical contraptions, and every building in the area had a story to tell. Second, nearly all of these things were entirely mysterious without a knowledgeable guide. Even an eight-foot high boiler outside the museum had no information on what it was or why it was there.

A big rusty orange boiler alongside other bits of old machinery
The big orange boiler, and other unexplained artefacts

Back at base, we set to work on the app. I set up a kanban-style board of cards and introduced everyone to Agile. We created GitHub accounts and triaged ideas. Our team had a strong content focus, which was great for developing something with content at its core. I was the only web developer on the team.

The next two days were a bit of whirlwind. I spent most of it writing code, and testing javascript on numerous mobile devices. My team colleagues selected content, filmed curators, sourced interesting information, wrote descriptions, recorded interviews, selected photography and more.

Somewhere along the line we broached the question of ‘how will people know this guide exists?’ We had a few ideas. First, the obvious: posters and leaflets. Then there’s simply telling people, perhaps from existing information desks. More ingeniously, we hoped to put an advert on the splash screen that guests see when connecting to the wi-fi (which covers an impressively large area).

We were lucky to have Matt on the team, who impressively works in manufacturing for a high-tech factory on the Isle of Wight. He suggested making some actual markers to put on things. This was easier than it might have been, as the museum had installed a FabLab for the Museomix event, which was full of 3D printers, a vinyl cutter, a huge laser cutter, and whatever a ShopBot is.

We wanted the markers to give some nod to the industrial origins of the area, as well a bit of a hint as to what they were for, so we created a design based on a magnet (representing iron) and wifi bars (representing mobile). It was also important that the markers didn’t detract from their surroundings too much, and so after laser cutting them from plywood and glue-gunning them together, Matt sprayed them with a can of sparkly 'iron-filings effect' paint hastily bought from B&Q, before painting the details in red and white.

The result was astonishingly good looking, and leant a physical dimension to a project that was otherwise entirely digital. It really showed the value of having a bunch of different skills on the team.

A hexagonal painted marker on a wall by some historic gates
One of the installed markers

The development process wasn’t without its interruptions. The Museomix organisers wanted to make sure that our projects were communicated back out to the wider online community, and so we wrote blog posts, filled in questionnaires and made a short video. This latter task was fun, but took a good while, especially as I had to try and remember how to use iMovie in a hurry.

The programme for the weekend included a couple of hours towards the end on Sunday afternoon for demo-ing the projects to actual members of the public. This was a brave but noble endeavour, as most of the hack days I’ve participated in culminated in a presentation rather than letting people actually try things out.

We had our working prototype early, so we subverted the schedule by putting out our poster and starting testing from first thing in the morning.

The app is fairly straightforward, code-wise. Each location has its own text file containing content in the Markdown format and metadata, including co-ordinates, in YAML format at the top. I selected these because they’re easy-to-read, and are supported natively by the GitHub web interface. This in turn meant that other people on the team (and potentially even others online) could easily contribute.

The text files are parsed by a simple Sinatra app, and then there’s a load of fairly hacky javascript I wrote to display them in a mobile and tablet friendly interface. One question we got asked a lot was whether the guide would still work when wandering through the areas where there’s no mobile signal. So from the off, I designed the app to store all the basic content in memory on initial load. (In practice, this wasn't so necessary, as the wi-fi proved so reliable in our test area – but it was a good thing to do.)

The only bit of ‘magic’ in the app is that it calculates how far away each of the locations are, and to tell you when you’re “at” one of them. Aside from some moderately complex maths, which I copied from someone else, this isn’t particularly difficult to do. The javascript API to ‘watch’ someone’s location (with permission) has been around a while, but I’ve not seen many web apps that make use of it. Having the screen alert you with a relevant message just as you approach a fountain feels quite remarkable – even though we’re well used to maps with a blue dot on them.

By the end of the Sunday our app had been used on 153 unique devices (I installed analytics, naturally), and we had received some great feedback from visitors. The museum’s board members all successfully tried it on their phones, and could see the possibilities for it.

Watching and talking to people using the app was really instructive. There were a few unexpected stumbling blocks. One person I spoke to hadn’t used wi-fi on their phone before. Another couple had location services turned off (I had to quickly learn how to turn enable this on Windows and Android devices). The most amazing was watching someone press DENY without a second thought when the app requested his location. When I asked, he barely recalled doing it. This was doubly problematic as un-doing this meant diving deep into the settings. Improving the messaging before asking for location permission ought to help. Thankfully, I designed the interface such that geolocation isn't required to access the content.

It was also interesting to note that a sizeable quantity of the people we tested with didn’t realise that geolocation uses satellites rather than cellular data, so they were pretty amazed that their phones knew where they were despite being in a mobile phone blackspot.

The nicest bit about watching people use the app was seeing people engage with the content. Our premise when producing the content was to answer people’s questions and tell interesting stories, and to do so in the most contextually relevant way that encouraged more and not less engagement with the actual environment. We didn’t get this perfect, as there was still a fair amount of people staring at their screens, but it was good to see people comparing old photos on their phones to how things look today, and listening to audio whilst wandering around.

Black and white photo of industrial workers standing proudly outside factory gates
Historic photograph of workers stood by the gates where one of our markers was installed

We also added a last-minute feature so that anyone at a location who wasn't satisfied with the information we’d given them could ask additional questions, via a simple e-mail link. We received about 7 of these, and made the effort to quickly find an answer from a curator and then to both e-mail them back and to update the app so other users could see their question and answer. This simple feedback loop demonstrates how responsive museums could be, delighting their visitors and improving their content. Though obviously it would need a lot of thought to get that to scale.

I got a bit of time before the end to look at the prototypes from the other teams. My favourite was a lovely projection onto the old furnace that showed how molten iron would’ve flowed from it into troughs, which really aided your understanding of how it would’ve worked. Another team turned an iron pot into a giant speaker which then told you, via poetry, of its story as a whaling pot. I’ve always liked the idea of museum objects talking in first person (something we explored in My Life As An Object), and so this was taking it a step further by literally having the object speak. In the same museum, another team took advantage of the fact that you were, unusually, allowed to touch the objects, by designing a game for children and adults using Pictionary/charades/Blind Man's Bluff style mechanics.

After that there was a brief wrap-up, then it was time to go home.

I hope the museum got a lot out of the event. Part of the Museomix concept is that it’s only about 25% museum professionals who take part, so that there’s plenty of input from people not involved in the sector to shake things up. As well as the prototypes themselves potentially being of interest, the process shows that experimenting and doing things fast can yield results.

The web app we made, Iron Insight: A curator in your pocket, is still online for people to use. We’ve even made a few updates to it since.

Playful 2013 sketchnotes

I went to Playful 2013 on Friday. It’s a conference about design, games and playfulness. This year’s theme was loosely playing with form.

On arrival I picked up a pack of blank playing cards and a Sharpie pen that Smithery and Mudlark had designed for the event. I think you were supposed to make a game with these, but instead I used them to sketch out some notes from the talk.

I kept it up all day, so I thought I’d share them.

Anne Holloday showed what some engineers had taught her about the process of making, with some clips from her The Makes of Things documentary series.

Ben Reade discussed the research and development he does at the Nordic Food Lab, and how he made some mould taste like foie gras.

Dan Catt showed everyone the best ever Snakes and Ladders board, and how he used computers to make it.

Dani Lurie talked about mischief-making and the experiments she did for Oh Comely magazine.

Duncan Fitzsimmons talked about some of the innovative projects he’s worked on at Vitamins Design, including folding-a-wheel.

George Buckenham discussed form and ‘play feel’ in video game design.

John V Willshire (Smithery) pushed a 'boxes' metaphor to its limits and said we should make things of the internet, not an internet of things.

Maria Lisogorskaya talked about vernacular architecture and play spaces, part of her work at the Assemble collective.

Marie Foulston told the story of her home-building within the Animal Crossing game.

Pippin Barr talked about some of the extroadinary video games he’s made.

Rob Lowe talked about art, optical illusions, and Moiré patterns.

Stefanie Posavec talked about her ‘vacation’ at Facebook, where she was an artist in residence.

Experiments with newsprint

I’ve been working with Newspaper Club for the past couple of months. It’s a company I’ve admired for years. We used it at both Rattle and Folksy to produce newspapers.

The main focus of my work there has been to improve the website so that it’s easier to understand the products and quicker to get started.

We’ve also launched some new printing options, making it now possible to order broadsheet and mini sized newspapers in low print runs (down to single copies for broadsheets).

I used this as an excuse to experiment with an idea I’d been toying with for a while: printing a newspaper of a year’s worth of Instagram photos.

So I printed a broadsheet newspaper with all of my Instagram photos from 2012.

I’m really pleased with how it turned out.

Initially I included the original Instagram captions, but they felt oddly out-of-context on the page, especially the hashtags and user references. Removing them gave it a cleaner layout, and also had an unexpected side-effect: when looking through the paper, I have to remember why I took each photo, which itself is an enjoyable experience.

The paper is also inherently social. Showing it to people prompts their questions and a discussion – often with more engagement than in the original comment thread on Instagram.

Producing the paper also taught me something about how I use Instagram. It doesn’t tell the story of what I did in 2012, but rather the story of what I saw. Or perhaps more accurately, what I noticed.

I’ll be producing another 2013 edition of this paper in January. And I’m also investigating the best way of doing this for other people too. So if you’re interested in seeing your Instagram photos in newsprint, get in touch.

The Pedway: Elevating London

Went to see a film at the Barbican last night called The Pedway: Elevating London.

It’s a 40 minute documentary by Chris Bevan Lee about ‘Pedway’ elevated pedestrian walkways around the City of London area. This scheme was started in the post-war period, but only partially implemented, often in such a way that some walkways lead precisely nowhere.

The film told the story nicely, with plenty of archive footage, some contemporary slow-tracking shots of the decaying infrastructure, and a voiceover commentary by four experts.

Interestingly, the film has a made-for-Vimeo feel to it. The director was present for a Q&A after the film, and said that he deliberately avoided talking heads, as those are usually the moments when he finds himself second-screening.

The basic narrative of the film is chronological, following the conception of the walkways by architects at the London County Council, the building and use of them, then the decay and failings of the walkways, and finally a look at other schemes around the World.

The main conclusion of the experts in the film, which I’d agree with, is that elevated pedways are a flawed idea, as they require pedestrians to deviate from their natural desire-lines at street level. They also stem from a desire to separate people from motor traffic, which was as much about speeding up cars as it was about preventing accidents. The more modern ideal of slowing down and reducing vehicles in cities negates much of the need to segregate pedestrians.

Something I thought was missing from the film was a bit more of an in-depth technical look at the Pedway. It would have been interesting to learn more about things like the height and width of the walkways (which wasn’t particularly consistent), the various wayfinding systems, and specific design principles. A really good map of the system as-built would be nice too. I suppose that’s what books are for though.

One last thing to note is that I actually used a bit of the Pedway to get to the film screening. It seemed only right.

Policy Positions

Like many in the web/tech sector, I’ve been following the progress of GOV.UK closely. The work they’re doing to present information clearly is fantastic.

The gov.uk team have also committed to making the information machine-readable, via JSON views and APIs.

I’ve been interested in what this might enable.

In particular, I thought I’d look at the policies section of the website. This is where the Government’s current objectives are specified. Apparently, before gov.uk, these hadn't ever been clearly written down before.

Policies represent a choice by the Government. A response to a particular problem, or a decision to take the country in one way or another.

Having good, well thought-out policies is arguably one of the most important things a Government needs to do (along with executing them). Therefore they deserve scrutiny and debate.

So I’ve built a thing to encourage people to read the policies, to form an opinion on them, and to state that position publicly.

It’s called Policy Positions. Take a look.

I’m not sure what this will lead to. Already, it’s prompted me to learn some things I otherwise would’t have.

The things I’ve learnt in the short period that the site has been in testing are firstly that it can sometimes be hard to understand a policy enough to be confident on whether you think it’s a good idea or not. With some of them, such as Developing a new high speed rail network, the policy title tells you enough. With others, such as Improving opportunities for older people, the title is so vague that it‘s impossible to understand what the policy would actually entail. So I’ve tried to encourage people to read the policy details on gov.uk itself.

The other thing I’ve learnt is that some people feel uncomfortable expressing any kind of political opinion publicly, for various reasons. I’m not sure that this is something I can particularly solve.

I’d be interested in any feedback you have on the project. It’s an experiment, so it could evolve in a number of directions.

The final thing to note is that the site stores every change that people make to the positions they take on policies. So if a major policy changes (and gov.uk helpfully maintains a changelog), it will be interesting to see if this also shifts public opinion.

Lasso Slippers

I recently received my first product that’s the result of something I backed on Kickstarter. I’ve supported half a dozen or so projects, but most of them are either still yet to deliver, or else are digital projects.

So receiving my Lasso slippers was a true delight.

This is a great project with a lovely product: a pair of slippers made from a single piece of felt each, which you self-assemble by threading together with a colourful shoelace.

My lovely red slippers

Their Kickstarter page told the story in a simple, compelling way. Gaspard Tiné-Berès was studying at the RCA in London, and had to survive a freezing winter in a draughty Victorian flat with a cold stone floor. The slippers were a response to the need for warm feet.

Back in Paris, the designer found a local factory to make the slippers. A factory that’s a social enterprise, and employs disabled workers.

The Kickstarter campaign was successful, production started, and here I am with my slippers. The process of sewing them together is a lovely touch. It’s fun, quick, and feels like a bit of magic – turning something 2D into something wearable.

They haven’t opened up for general orders yet (fulfilling the Kickstarter rewards has taken a while), but if you’d like to be notified when they do, you can subscribe to their newsletter.

Slow Stories: publications for Little Printer

I’ve had my Little Printer for a few weeks now, and I’ve been enjoying the daily print-out of interesting things.

Yesterday, I released my own publication, called The Moon Race, which you can now subscribe to.

The inspiration for this was the On This Day publication, which each day tells you about three different historical event that happened on the same day of the year.

I liked this, but found the randomness a bit jarring, and sometimes wanted to know what happened next, as a consequence of the events.

What I realised was that I wanted to follow a single historical story, but told in the day-by-day rhythm of the Little Printer.

So I created an app to do just that.

The publication I’ve released tells the story of the Space Race to the Moon. It starts with President Kennedy’s speech to Congress on 25th May, 1961, in which he commits America to landing a man on the Moon, and returning, by the end of the decade. The story ends, and I hope this isn’t a spoiler, some eight years later in 1969 with the Apollo 11 mission.

The key decision I made, though, was to tell this story in ‘real-time’. So the Kennedy announcement happens for you on the first day you’re subscribed to the publication.

The consequence to this that, most days, you won’t get any update. In fact you might go months without an update. Other times there will be a flurry of daily activity in the build up to, and during, key space missions.

I have no idea what this will feel like to subscribe to. Hopefully, at the very least, you’ll get a sense of the pacing of this historical period.

One last thing: I built the app in such a way that it could be easily re-used, without any modification to the actual codebase, to tell other stories in real-time via Little Printer. I think World War 2 would be interesting to experience in this way (someone’s pointed me towards @RealTimeWII on Twitter, which is incredibly powerful).

I don't have the energy to write up any other stories though – researching the Moon Race is time-consuming enough – so if you fancy having a go, let me know.

The Web as a material

I had an enjoyable evening listening to two talks at #LDNIA last night.

First up was Tom Armitage. He was talking about “The Material World”, and how design is in part having an understanding of those materials, even when those materials are intangible (or ‘immaterials’) – things like the Web, or wi-fi, or a particular data set.

This was followed neatly by Paul Robert Lloyd, whose talk “This is for Everyone” discussed the universality of the Web as being its key design principle. This, in short, means embracing the fact that the web can be experienced on a whole range of devices, with widely ranging capabilities. To put this in the language of Tom’s talk, this is to say that the material of the Web is not screens, but HTML, URLs and HTTP.

I found myself nodding along to both talks. They both articulated well the practices that I and other web-tinkerers seem to follow instinctively. The first stage of many projects I’ve done is to just “muck about” with the core technology or data set, discovering how it works and what it means. This is the process of material exploration that Tom talks of. Wanting to follow the ‘grain’ of the Web and to design the HTML structure and semantics first also feels natural for anyone who’s spent a long time making web pages – particularly if, like me, you’ve watched HTML slowly evolve and have spent a long time reading the specs.

Social media platforms and services are materials too. And they each have their own conventions, affordances and cadences. These subtleties are why I always feel uncomfortable when people cross-post, posting the same content to Facebook and Twitter, or pulling tweets onto their webpage (for a start, hashtags outside of Twitter feel really ugly). It’s also why I think there’s a value to Medium which is different from blogs – Medium has an undefined but discernible house style which makes it a unique form of content.

One final thing about the event was that it prompted me to think about how the Web’s universal nature could be made a bit more apparent, in an age where browser rendering has become mostly consistent and user browsing preferences have been minimised. I have some ideas for this, but it’ll take a bit of work and playing around to make them happen.