The Internet of Food
Author Nick Taylor Buck, 23rd March 2018
After I explained the project and he held his head in his hands for a while, we came up with a set of steps to help us develop the digital infrastructure.
Developing the digital infrastructure
First, we need to start building the wider community outside of our Action Research Teams. We could do this through a Facebook group – perhaps initially a private invite only one, with a more public facing page.
Meanwhile, we need to create ‘personas' for around half a dozen types of user – these are brief sketches or caricatures that help us to outline their motivations.
Then we need to create a short story (or single sentence) for each type of user e.g. ‘As a farmer I want to do X so that I can do X’, or ‘As a food bank organiser I want to do X so that I can X’.
The next step is to develop an ‘information taxonomy’ – essentially an initial stab at the categories we want to organise our information into to help users engage with it, using our personas and user stories as a guide. For example, the home page could have links to ‘Growing Food’; ‘Preparing Food’, ‘Eating Good Food’, ‘Eating Together’, ‘Selling Food’, ‘Transporting Food’, ‘Waste Food’, etc. etc.
We can then start to engage users in the design, gaining their feedback and use iterative testing. There are a number of useful tools that can help us to do this:
- TreeJack would help us to test our structure and the way we organise information, by getting feedback from our team
- We could set up an initial wiki system for free on Trello or possibly Discourse to get the basics right and make sure things work roughly as expected. Discourse is designed around having ‘long and meaningful discussions’, and also allows voting when clear community consensus on an issue is required.
- We could then use Typeform (like a fancy survey monkey) to gather more feedback as we go.
The final stage of development would be to engage programmers and coders to help us to migrate our system from Trello or Discourse over to an open source platform that we can modify to our requirements. This could possibly be an open source version of stackexchange - a kind of Q&A community that facilitates knowledge sharing. One example of this is PaizaQA, and there are others here.
An approach similar to this was utilised by Andy to create the Asylum Journey application.
Engaging with the digital community
This brings me on to how we can engage with the digital community so that they can help us on this journey. We came up with 4 possible options (although there may well be many more):
1. Organise a hackathon to attract members of the community who want to do social good but also get new skills on their CV. This is how Andy got Asylum Journey off the ground.
- This could be done in, say, three events over a 6 month period
- People could meet on Friday night to chat, and then reconvene on Saturday to do the work
- We would provide refreshments and lots of encouragement
2. Contact people and organisations through existing community networks.
- Andy’s tweet on my behalf after the legup.social event immediately led to contact with Simon Cookson of @HiveIT_uk and Craig of @HydraCreative
- A couple of weeks ago I also met with Chris Dymond @chrisdymond of Sheffield Digital at their weekly GeekBrekky coffee morning. This resulted in Iain Broome writing about the project for the @SHFDigital blog
3. We could approach Code4000 - an organisation that gets prisoners working on coding to improve their chances of employability on release.
4. Finally our own University is always approaching businesses to ask for interesting student projects, and I will find out if this is a potential route.
Keeping our options open (source)
Andy warned me that we need to accept that whatever technology / platform / app we choose, it is likely to be dusty and outdated after around 2 years, which doesn’t sound good in terms of a sustainable digital resource for the city. However, we can mitigate the dangers of this by keeping everything open source and making sure that whatever technology / platform / app we use has an API (Application Programme Interface). The API will allow programmes to talk to each other, meaning that we can migrate all the existing data and information over to a new system in the future if need be…
So now we know what to do. Sort of. Watch this space for progress updates.