I’ve been involved with this group of people who are writing a zine called Greater Brooklyn (greaterbk.net). I was back in February 2014 that we got started on the project, here is the first call for submissions poster I made.
Now just over a year later I’m wrapping up the cover for issue 4. I am really excited to see this project grow so I put a lot of effort into this dover design. I’m also passing the illustration over to my buddy Max Rose to breath some life into the setting I illustrated.
I recently have begun a partnership with a dear friend Katie @fffalcon. She is a brilliant admin and designer, among other things. We picked up a little gig from my buddy Max Rose. He needed a portfolio site and fast! So Katie and I used it as a first mission to test out our potential partnership.
She turned me on to only selling myself in minimum of half day increments. No more billing one or two hours here and there, no if you want any of our time it will be at least a half day. Anyone who does freelance web work knows that even 15 minutes of work has upwards of an hour of prep time, between e-mail, server credentials, and just getting settled down to work you’ll burn countless minutes and hours that don’t get factored into your cost.
So we both gave Max a half day. Here’s the designs that Katie pumped out:
I then took that, plus some CSS she provided and converted it into the full site. I opted to use Jekyll to produce the flat site which is simply uploaded to the server via FTP. I plan to use GitHub.com to host the site soon and simply maintain it via git.
A friend of mine is running for the Portland, ME school board seat. She posted up a design for yard signs and asked for some feedback. The community did an awesome job with the feedback so I thought I would come in and just give it the “professional” touch.
The professional touch is fairly simple:
Large print ready format (in this case PDF, 700 mm x 400 mm)
Proper colors, e.g. CMYK
Choosing a proper font (In this case Becky went with a nice one to begin with)
Cleaning up kerning and leading
Here’s Becky’s original design, it’s a yard sign:
I then took that, figured out the font using MyFonts.com/WhatTheFont (I had to isolate and make the main text black on white for it to work)
Dropped that into Illustrator and came out with this:
You can see the outcome of my work in these two PDFs:
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
A water engineer drives around installing and repairing water points. They tend to have GPS units and smart phones.
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
Water Officers manage the engineers from their desks in the Water Ministry. Currently these officers update a CSV file which they download and then re-upload. (I know, it’s terrifying).
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
The Water Minister is the person at the top. They want the birds eye view of everything that is going on.
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.