We camped out for a few lovely days at the inspiring Little Devices out of N51 at MIT. Hugs and hearts to Anna and Jose who brought their brains and their space to our hackdays. And didn’t find our requests for things like buckets, tubing, and CNC strange. We were constantly surrounded by go carts and craziness. So happy.

Maps

Mark used the OSM-Bright style and started to add Tanzanian Open Data to create a basemap for Taarifa (and generally anyone interested in Tanzania). Have started to refocus the cartography on public services as opposed to navigation – roads are the design focus of OSM Bright – Mark is changing this!

Requests have been made to import this data into OSM, however, as yet have been unsuccessful – I am following up on this! So, seeing as I can replicate OSM’s stack insofar providing a map tile service is concerned, I’ve started to create a Tanzanian base map.
Before: 

After: 

Next Steps

Currently continuing to work on it. Will need to understand how the loading of OSM Stylesheets into TileMill can be re-consumed by others, currently the work is installed on a local TileMill and isn’t packagable for wider consumption. Changing this is a priority.

Lives at

On Mark’s computer – needs to be on a github repo. As a (rather large) side note. The finished product will need to be hosted on a server with at least 100gb of space, if not more. Consequently understanding where and who has this infrastructure will be important.

User Interface / Dashboard

Drew did a bunch of work on this. Here’s a drawing from brainstorming:

And a link to the PDFs.

User Stories

It’s important to know who your users are, if you’re going to build any tool. By building out user stories based on experience and interaction, we can consider message format, connectivity, visual needs, and the like. Willow typed up a bunch of user stories based on her week in Tanzania.

Next Steps

There are some lingering questions that not enough experience was garnered in order to answer. Things like – if we want to show people that their reports are being acted on, but we can’t send them text messages back (if we’re protecting their identities), then having printouts at local municipal offices makes sense. What should those look like?

Code Base

Dirk and Florian led the charge on this.

• Created initial installation and usage docs for the API and Waterpoints flavour of Taarifa.
  • Drew helped to guineapig this
  • range of bug fixes & doc fixes
• Understand the sensor use case and how that relates to the Taarifa use case. Settle on the use of a separate, existing dedicated sensor api solution (potentially MITs chain-api).
• Trying to complete the TaarifaWaterpoints application but ran into technical issues. Lots of debugging with Florian which lead to more a fundamental discussion as to what the scope of Taarifa should be.
• Technical issues pretty much solved with a couple of things swept under the carpet for later. Scope discussion started on the mailinglist, community needs to comment (this is where a board could be useful)
• Lots of discussions with Spencer (chain api), Jude (Promise Tracker), Ben (MoMo), Dan (Riffle) in between

Next Steps

• Complete Waterpoint example so it’s usable
• Main priority: focus on UI / Dashboard, implementing Drews mockups.
• In parallel continue work (who?) on a more flexible, generic API depending on outcome of scope discussion on mailing list
• Don’t actively evangalize Taarifa codebase to outsiders and other applications without some caveats.

Videos

Introductions

Day 2 Updates

What Else?

There was also some killer work done on water sensors with Public Labs, and on telephony plugins with Tropo. Look for that followup here!

What’s Next?

Next, we’re taking this show on the road to University College London 5/24 and 25 (bit.ly/taarifalondon), and then to Dar es Salaam (bit.ly/taarifadar). We hope you’ll join us, in person or remotely, for one or both.

See the list of our tasks on this hackpad page.