I had the pleasure of working on a very excellent project this week. A little over a year ago, I was introduced to Taarifa, a Tanzanian project which aims to make potable water available to all.
I met Taarifa at the Hackathon for Disaster Response 2.0 in Birmingham, UK. When last we left Taarifa, it was moving from a service called Ushahidi to a custom built API. To this task, I suggested a distributed method of hosting and data sharing with custom APIs built in Python+Flask called Data Anywhere. It appears that Taarifa has gone that route, and created their own API in Python+Flask! See the code on GitHub.
Over the three day hackathon, I created a mock-up for the Taarifa system’s potential front-end. This was based off of the field reports gathered by the awesome Willow (@willowbl00) and discussions from other folks who worked on this project for over the past few years. So now, let’s talk a bit about what Taarifa is and what its use cases are.
Check out this video to get a better understanding of the situation in Tanzania:
In the most general sense, Taarifa stores and updates data about water points in and around Tanzania. It serves the Tanzanian Water Ministry by allowing people to submit reports of broken water points and give the Ministry a birds-eye view of the situation on the ground (when cell and data service are minimal). There are water points (wells or large tanks on stilts) spread across the country. Water Ministry Officers manage all the water points by sending Engineers out to install or maintain them. The Water Minister oversees all of this while normal people use the points to gather their water. Informal maintainers make money by filling up the tanks with either fresh water or, in some cases, salt water.
I’m told that people who can afford it will purchase fresh water for drinking, and use salt water for cleaning (gray water). While those who can’t afford fresh water will drink the salt water. I am truly privileged to live in a society that has such an abundance of cheap, fresh water that we can shit in it.
White board sketch of user roles
I drew this whiteboard sketch to outline the different user roles that would use the Taarifa system, either through a web application, a mobile app, submitting text messages to the app, or by simply telling someone else who can.
The Water Engineer
They want to submit reports that water points are broken (or fixed) and they want to know which water points need attention.
The Water Officer
Officers want to be able to update water point data, see up-to-date info on what is broken and where. They also need tools to make “punch lists” (to-do lists) for the engineers.
The Water Minister
They have goals to meet and people to answer to.
The Informal Participants
The people who use the water and those who fill the water are considered informal actors. They might have data enabled smart phones or, more likely, SMS enabled “dumb” phones. However, with data rates, they probably won’t be too inclined to use those systems to submit reports. Like most things, they will use word of mouth, sometimes marching into water ministry buildings to report broken points.
Someone shared with me their observation of the political will of the people. They said that the history of Tanzania is such that people’s attitude basically breaks down to “that’s the governments responsibility, but they don’t get anything done.” I wonder how true this is, as I have witnessed the same attitude in the US (“congress should solve ________, but they can’t get anything done.”)
This informs a desire (of a few of us) to use the Taarifa system to bootstrap a more autonomous means of solving the water problem. If anyone could report a problem with a water point, then potentially anyone could solve that problem. With public data it becomes possible for non-state actors to make a positive impact. This, however, brings up the political issues of open data.
If we open up the data, it might show that some people are doing a piss poor job. It might also eliminate other people’s usefulness. It’s easy for someone like me to rally for open data when I have no stake in the data remaining closed. The pressure to keep data closed doesn’t always come from those in the most powerful position, it also comes from those lower down the totem pole, but this is a tangent for another blog post.
Taarifa user interface mock up
I determined three main views that the API interface should have. The Dashboard, which shows an overview of data points, the Waterpoint (or item view) showing a single entry into a data point and a List view (or search view) which shows a list of data. I also had the idea of a Feed view which would show recent changes to the dataset, but didn’t get around to mocking that up.
Look and feel
I based my initial design on a mock-up another member of the Taarifa team had made, which featured a dark color scheme and small boxes of bold graphic information.
I kept the dark color scheme with neutral gray. The nav bar is the darkest gray, while the in-between space is a lighter gray. Lighter gray elements then pop out against the dark backdrops.
I wanted the design to feel like an application. It is full width and has simple bold elements. A persistent header acts as a way finder.
This header, I feel, is currently not well thought out and could use a lot more work.
Alas, one can only do so much in 2 days.
The “query card” is a small card that presents a single point of data in a bold manner. It could be a pie chart, a graph, or simply a number. I would like to see these as widgets that users create by adding simple query strings together.
This view allows a user to see a broad overview of the data set. On the right, is a map with a key and messages that display on click or hover. Ideally, data could be filtered by way of drawing polygons on the map or adding specific filters using a stackable filter UI.
The filter accepts strings, has drop down for common attributes (in this case district and status) as well as the ability to “stack” additional filters. I based this off the OS X finder search design:
The ability to save searches can allow for detailed searches to be shared to other users.
The Search View
Using the same search filter as above a user should be able to view large lists of data:
The map on the right can be toggled on/off and will zoom to fit the extent of the search data. Search data will be presented in list form, a bulk edit option should be available. The ability to drag and drop rows into custom data sets, like a work list for engineers, would be a great addition.
The Item View
The last two pages I was able to mock up, represent single items from the database. The Water Point and Report items are often linked but stand on their own.
The Water Point above has some basic information as well as a few “Query Cards.” We were hacking on a few items that could provide real time data about flow and water levels in the Water Points, so I imagined what that might look like.
The next data item I mocked up is a report. This is what an engineer or person would send in to the Water Ministry. I added a “confirm” button primary, so the Water Officers don’t get frightened that their job is at risk. Below are other related reports (perhaps reports that share the same Water Point or reporter.)
I’ve already touched on the “Query Card“, here is my idea for building one. I imagine that the Query Card will take the current view’s data set and visualize a date range, data type, and particular column of data. Each Query Card is then saved and can be inserted into particular views. Perhaps users can customize their views with Query Cards that are best suited for them.
This is a very rough mock up with more emphasis on visual design than a real hard look at usability. I’m sure it can be much improved and I would be happy to hear about your ideas.
A key feature of Taarifa is that it is flexible. While it is being designed for Water Point management in Tanzania it could very well be used for Water Point management in India or canvasing data in Brooklyn. So the really important next steps for this part of the design process is to abstract the above designs into a one-size-fits-all mock up.
In my dream world you would deploy the Taarifa API on a server (or servers), deploy this front-end, and customize it to fit your needs before plugging it into the data source.
It should work just as well for any potential use case.
- You can download the Adobe CS6 Illustrator file here.
- A PDF with all the mock up and elements is available for download as well.
- This Hackpad covers user stories (you might need permission to view it)
- Here’s a playlist of Taarifa related YouTube videos
Here’s a day 2 check in with an overview of most of the folks who participated: