Guest Blog by Andrew Lewis: Reflections of a data hack judge
I was recently invited to be one of several judges at the Science Museum’s hackathon #SMHack. Good job it was.
As a maker, at home I’m always putting things together just for the crack. I’ve also managed digital assets at work for years, including making APIs available to artists and developers to work with collections data, and in product development at the front end. So I appreciated being in a room full of people bouncing ideas around and getting creative.
It was an honour to be judging all this lovely creativity and it also was a great opportunity to reflect on what is needed to turn data raw materials into user experiences. While mulling all this, some questions came to mind that might be worth considering for other organisers and attendees of data hack events.
What’s the point of asking people to hack your data?
It might seem a bit deep, but it is worth reflecting on why we would ask people along to a hackathon. Is it to get more value out of your data? To test the usability of the open data services on offer (in this case, the Science Museum’s admirable newish collection API)? For PR? To generate new service ideas?
I felt this hackathon did a good job achieving all of these, although of course, these are not the only aims you could have for a hack. The last hack I went to before this one was at The Oxford Research Centre in the Humanities (TORCH) in January 2017. In that case, the hack day was more aimed at developing data skills and techniques for social humanities researchers. They were not providing data, but providing an environment for the attendees to learn about data science concepts such as topic modelling and sentiment analysis, before some hands-on exercises in extracting evidence from public data.
What incentives do you need?
Of course, you can’t reasonably expect people to give up time for your benefit without offering them something for theirs. This is subtler than it might appear. First of all, lots of people come along to hack events for the chance to show off their skills so showcasing ideas is a given. There were some great ideas here and lots of people enjoying showing them off.
Many people enjoy the competitive element of a hackathon, but it is worth remembering that lots of people don’t necessarily enjoy competitiveness. (although most people can tolerate it if they happen to win prizes of course!).
Prizes are fair reward for effort in the hack, and I think everyone attending should get some sort of reward, whether it is a chance to mingle and learn stuff, or freebies or something to pop on a CV.
How many rules should you have?
This is an interesting one. For creativity it is tempting to assume having as few rules as possible is best, but I’m not sure this is true. Limitations to scope can encourage creativity too. It also depends upon what you are trying to achieve.
While wandering about speaking to teams at #SMHack , it was clear that all of them wanted some sort of framework to work within. If people are going to commit serious brain time into the hack, it is only fair that they know what is in scope and what is not. When any of us offer up a contribution, we like to think it is helping and out time was not being wasted.
What do you need to do to look after hackers?
Apart from a clear scope and rules, there are some simple things that help. The Science Museum is a pretty big building and the hack space was actually a long way away from an entrance, so it was logistically quite tricky to get people in and out. On the whole this worked, but it is easy to accidentally lose hackers in hacks due to things like access passes, lack of signage or clear comms channels to get hold of an organiser.
Another really important thing is to recognise that hackers may need your help understanding the data. If APIs have documentation, that’s good and making sure hackers have someone to ask about it is even better. Thus includes the data structure as well as any endpoint calls available.
Obviously one thing that is always going to help is food. There were some good lunches laid on and pizzas at the showcases and sweets on tables. This is best practise in my opinion :)
Finally, one important thing is having support for people on hand throughout the day. There’s always someone struggling somewhere at any given moment, so having people roaming about checking in on teams and offering ideas, making planning suggestions (like “you might need to get building…”) and to keep a check on the balance of personalities in teams to make sure both the introverts and extroverts were getting what they need to be happy and productive. It’s a bit like the Great British Bake Off. You need some roaming love as well as critique.
Showcase
Anyway, hats off to both the organisers and all the hackers. It was a pleasure to judge. Overall it all felt really positive, all the projects were interesting and I came away energised and full of new ideas. Anyone that makes available open data or gives up their time to explore its value is good with me.
Here are some highlights from the teams (in no particular order)…
The Waterfall of Human Endeavour
(winner of the “Creative Prize” for most artistic, beautiful, and thoughtful use of the Science Museum’s API )
This was great for being very simple, but irresistibly compelling through its use of ambient sound and a simple but lovely visual cascade of objects that exposed the collection enjoyably. This could be used for real almost in the state of development after just the time of the hack. (for example in queuing/waiting areas or as an alternative for a hoarding during temporary closue for exhibition refits etc)
Myseum
This was probably the most ambitious concept of the day.
A location-aware service offering a personalised “Museum in your pocket” based on crowdsourcing user content based on object data and sharing between visitors. If I’m honest, in a live service, this would be a huge thing to attempt, needing a large technical infrastructure and considerable staff resource for moderation to establish and then maintain the community needed. But, the point of a hack is to not worry about possible barriers necessarily. By imaging it existing, it got me thinking tangentially about how visitor location-data could be visualised to visitors and the potential uses.
Science Adventurers
This was a quiz-based treasure hunt.
It was attempting to connect visitors with interesting objects and had a clear purpose for an audience.
Lucky Jim
One of two interesting chatbots produced at the hack.
This one was a take on an AI tour guide with two modes. These shots are a bit poor as they were taken from a distance
Sci Mu 9000
(winner of the “Punk Prize” for most disruptive, revolutionary, quirky or just plain oddball application of the Science Museum’s API)
The other chatbot was actually a series of experiments to “play with voice recognition” Subsequently, it was not that developed as a final product, but it had some great potential and some nice attention to design (and a cardboard robot was involved, which always helps)
ORB-ject - Chaos Galleries
This one used AR (augmented reality)
I liked that it was intended to get visitors to go out into the galleries and engage with objects. It had interesting image triggering.
Team Henry
This web based offer was linking objects from the Wellcome Collection and the Science Museum.
Credit for getting it successfully working technically. I did suspect the user demand might need a bit of further exploration in any future iterations.
Hot or Not - Team Dippy
Disclaimer - this team was colleagues of mine from the Natural History Museum so I abstained on voting on this, but it was very appealing.
Its simple gameplay was to pit pairs of objects from four museums (Science Museum, Natural History Museum, V&A and British Museum) against each other, then use the results data to crowdsource suggestions.
I like the fact that the game was easy enough to not need explaining, with enough playfulness to be good fun
Team Undefined
This was also a game and also with a simple and engaging gameplay. Here is an early version. I always like a paper prototype.
It involved showing 3 images of objects with one description revealing the text bit by bit. The player simply had to guess which object it referred to as qyuckly as possible. Enough of a mental challenge to engage, with exposure of object information in a fun way.
Hack the board room
This one was more of a concept than and didn’t build on the collection data provided, instead exploring how the data on museum staff pages could be collected from web pages to analyse demographics for lobbying.
What came first?
Another game, this had a load of potential and was a neat take on timelines to make them more compelling with simple gameplay.
Traditional timelines, which rather assume people will actively study them, which is not likely to be true for many people. Its clever trick was to simply offer up objects and challenge players to say if they were invented earlier or later than the objects already in play.
Museum Egg — Super Team Happy Club
(winner “The Next Big Thing” prize for impactful, practical, scalable or useful application of the Science Museum’s API)
By far the most advanced end product (although to be fair to the others, this team were from an agency, so I suspect some of this work was already in existence before this hack).
Having said that, the concept was well thought out on several levels. It was a cute and attractive object that people would probably like (though managing hardware for public use is always a bit of a mare!), it didn’t burden users with a need to understand it or force them to do a specific task.
It was location aware and just needed to be worn. It then used location data to record a list of objects that visitors had visited and finally print a takeway handout of these as a keepsake.
This met a recurring user need for a visit to a museum or gallery - to get a souvenir. It also allowed users to just experience the museum, yet still gave them curated information based on their interests, not dictated by the museum — all very clever.
Should you make data available and invite people to hack it?
Duh - of course! Hats off to everyone involved for this one.
