In January we brought together coders, developers, designers, business developers, domain experts and scientists for the Future Food Hack 2015 at Wageningen University & Research Centre. The hackathon was a ‘32 hour get-away’ for interdisciplinary teams trying to create impact with open data in agriculture and nutrition.
So, how far did we get? Did we change the world, find solutions for intractable issues and develop easy-money-generating apps? Not quite (yet). We did however learn a lot about the issues at stake and what it takes to develop innovative software solutions. We hope that by sharing our experience and insights, we’ll collectively be able to build on top of them.
The second blogpost in our retrospective deals with the Road Safety – Ushahidi challenge. In this post, team member Bart Doorneweert reflects on his team’s effort to build a compelling use case. This is actually a key element of a successful application, which all too often gets neglected by time-pressed participants of a hackathon. However, if you want the results of a hackathon to survive the life span of the event itself, there are some elements that you definitely do want to grant some of your valuable time!
At the GODAN open data hackathon, our team had an idea to develop a solution to improve road safety in rural areas. Agricultural machinery in the Netherlands is getting bigger due to the growing size of farms. On the other hand, road infrastructure is not growing accordingly. Rural roads are thus often congested when machinery needs to be out on the road (like harvesting time). The number of traffic accidents related to agricultural machinery is also on the rise.
Our team set out firstly to develop a compelling use case, a story that would tell how communication and exchange between agricultural machinery drivers, and other road users could be set up to improve traffic coordination and avoid dangerous situations as much as possible.
We started off by relating tractor drivers and cyclist, as cyclists are vulnerable road users. Our assumption was that tractor drivers would appreciate being able to drive on roads, which were free from cyclists, and cyclists vice versa. Could we develop a solution where these parties could coordinate this together?
Taking this idea we started looking at the back-end, and considered the theme of the hackathon: open-data for solutions in agriculture. One of the possibilities we were offered was to work with an open source mapping application called Ushahidi. Essentially Ushahidi allows the user to share geolocation, and contextual information to that pin put on the map.
What made things really interesting is that Ushahidi uses open street map for the underlying mapping infrastructure, and most of the navigation apps used by cyclists do too. Various types of cyclists also use navigation apps quite extensively (like Garmin and mobile apps like Strava). That would create the opportunity to build something that could connect tractor drivers and cyclists on an open source platform. Much like car navigation warns drivers where congestion takes place, so could our app show cyclists where farmers were active on roads, and provide alternative routes.
Seems compelling, right? It does, but it’s still not a convincing use case. It was still missing validation of some crucial assumptions we made on the behaviors of our target groups. Do farmers consider cyclists enough of a nuisance to activate them to submit their route and current location? What handling would be permissible for them to submit? How do cyclists actually use navigation devices? Do they use turn-by-turn navigation to coordinate traffic decisions?
(Heat map van fiets ‘Big Data’ mbv de Strava App)
We were thinking of building a turn-by-turn planning feature for bikers to warn for tractors/heavy machinery, using Open Street Map, fed by GPS apps. We would request farmers to open their GPS signal and feed that into OSM. Although this idea is technically feasible, this does not yet mean that there is a good reason why it should be build.
We called different users to verify some of our assumptions. From a farmer we got the feedback that he does find competitive cyclists a nuisance and a danger in traffic, which was encouraging. But from the end of cyclists we got the feedback that they usually have routes in the back of their mind, or sometimes use a map to orient during breaks, but no real turn-by-turn support was used. Also they didn’t consider tractor drivers to be much of bother, even not being able to recite any meaningful incident with tractors from their own experience.
So, essentially, our use case fell through. Our cyclist user group does not show any signs of behavior that could motivate using our solution. So what we actually demonstrated was why not to start building this feature yet, even though it is a compelling idea and the underlying problem is quite urgent (for more information, check our pitch presentation)
Access to logged traffic streams of cyclists and tractors could have perhaps helped us in our exploration. But even all the access to massive amounts of granular open data in the world, does not make up for the need of behavioral insight into your intended users – how does your conceived problem exist inside the lives of the users you’re trying to reach? This is something that needs to be inside the narrative of each hackathon challenge that seriously wants to demonstrate what the possibility of open data is to change the world.
Bart Doorneweert (LEI Wageningen UR)
Jappe Franke (WUR)
Arjan de Jong (Alterra)
Inge La Rivière (Alterra)
Onno Hols (WUR)
Jesse van Vliet (student)
— Bart Doorneweert (@BartDoorneweert) January 20, 2015