Greater Brooklyn Zine Illustration

I’ve been involved with this group of people who are writing a zine called Greater Brooklyn ( I was back in February 2014 that we got started on the project, here is the first call for submissions poster I made.

BK_ZINE_call_for_submissions_web_bw BK_ZINE_call_for_submissions_web

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.

Some detail shots:


greatbk-issue4-cover-web-detail-posters greatbk-issue4-cover-web-detail-bbq

And here’s the full thing:


Here’s an idea of how it will look when folded:


Rocky Mountain Bridges Website

I’ve been pushing out a bunch of great websites recently! Here’s another I just finished up for Park Works in Canada.

It’s a simple display site for Play Work’s line of drop in place bridges. They needed a presence online to show off their work, describe some of the features, and display how easy installation is.

They had a good body of photographs so it was a breeze to put together the site. I decided to go with WordPress so that Park Works could do as much editing in house as possible.

I chose Theme Foundry’s Make to act as the theme for the site. There wasn’t enough custom work needed to warrant a child theme, though I normally would install the child theme just in case.

I used Simple Custom CSS and Simple Lightbox Plugins to add just a bit of custom style and, duh, a light box to the site.

On the showcase page I used the built in Gallery function to create a grid of pictures that would pop up into the lightbox.


The Make theme has wonderful mobile support and the site works quite well on any device (not that I was able to test on that many, something I need to work into my process!).

rmb_mobile rmb_footer

Maximum Rose, a two day development sprint

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:


Desktop (full resolution)
nomadpals-maxrose-home-v1 max-rose-home-v1-crop

Mobile (full resolution)max-rose-phone-v1-crop:

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 to host the site soon and simply maintain it via git.

You can view the code for the site on

See the site live:

Check out max’s work too, he’s so damn good:



Hacking Tanzanian Water Systems with Taarifia

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.

(Read more about why this is a good idea on my post about Data Anywhere, or check out the Data Anywhere Website.)

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

whiteboard_user_engineerA 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

whiteboard_user_officerWater 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

whiteboard_user_ministerThe 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

whiteboard_users_informalThe 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.

taarifa_web_mock_querycardThe “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.

The Dashboard


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.

taarifa_web_mock_filterThe 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:

screen grab of the Mac OS X search function
Click to learn more about Mac OS X search.

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:

taarifa_web_mock_searchThe 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.

taarifa_web_mock_waterpointThe 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.

taarifa_web_mock_reportThe 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.)

Query Cards

taarifa_web_mock_querycard_editI’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.

Next Steps

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.


Here’s a day 2 check in with an overview of most of the folks who participated: