Tracking of donations and requests by aid drivers

Code (not even vaguely functional yet) available at: https://github.com/TokyoHackerspace/tokyohackerspace/tree/master/aidtracking

Update (2011-6-18) As there are other sites that do this tracking, the code has effectively been abandoned.

Background
2011-4-13: Tuesday weekly meeting presentation by David Kell

(David has been doing personally-funded and crowd-funded drives of supplies to Iwate and Miyagi prefectures since the quake, and joined THS to explain his experiences and give feedback on how we might be able to help).

David mentioned a recurring problem faced by aid drivers is the lack of up-to-date intel on the specific needs for each shelter before leaving. If a week elapsed between the time a driver was told "we need water" by a shelter and the time the same driver made it back there with water, there was a strong chance the need had already been filled.

(Similar in nature to the problems faced by taxi drivers with reporting passengers needing a taxi: dispatch needs very high assurance a person will still need transport when a taxi arrives before investing in sending a car there.)

It was suggested that THS could
 * implement such a "needs sharing" forum for drivers and
 * use our network of contacts with aid organisations to help it reach the critical mass of user base required for it to be useful

Participants
Rick

Actors

 * Driver
 * Aid co-ordinator

Story 1: driver on site

 * Driver makes a delivery
 * After completion records the details of what's needed by the shelter (from interviewing locals) and what was delivered, tagged with location of the shelter

Story 2: before delivery, supplies already procured

 * Co-ordinator or private driver has supplies, wants to know where to deliver them
 * Searches by supplies, looking for area with that specific need as recorded in story 1

Story 3: before delivery, want to help a specific area

 * Co-ordinator browses by area, looking for the needs of a specific area in order to determine procurement strategy.

Hard requirements

 * Data entry: drivers will record places they visit (preferably with GPS) and record what they delivered and any pressing needs of the local community that other drivers should know about
 * Search: the needs should be organised in a way that makes it possible to search by location or item requested / delivered so potential deliveries can be targeted to the most needy areas.
 * Offline support: the environments drivers go to will be in areas of poor 3G and network service. Any system needs to be capable of functioning offline in some limited capacity and then later syncing back to the common repository when network service is resumed.
 * Technically simple: the people using this would be non-technical and likely never have contact with a developer. Usability without training time is likely to make or break the project.
 * Maintainability: the solution chosen would be deployed on many devices outside developer control, so some platform that allows a degree of remote control over any installed software would be necessary.
 * Open-access: the nature of the information is such that it should be viewable by all, editable by authenticated parties only. Authentication of an editor shouldn't be any more complex than say wikipedia.
 * Doesn't impose organizational structure: important that any system is not defined by a particular set of roles, but rather by goals of person using it. We have very limited intel or ability to teach structure for people when using this, so it makes sense to focus on meeting usage goals we know exist without forming any kind of user hierarchy etc.

Nice to haves

 * Degree: there would ideally be some way of flagging the urgency of a given need, so that "we have no water" and "we need kids toys" are easily distinguished
 * Language: support for sharing of the same information by users in different languages is a nice-to-have. Either opportunities for manual translation with fallbacks to original language or auto-translation (last resort) would be nice.
 * Free text search: the data entered will likely be poorly organised. It would be nice to have some ability to search google style when categorization isn't possible
 * Audit-trail: the open nature of this system means we'll likely have editors whose goals don't match the group's goals from time to time (read "spammers or vandals"). The wikipedia model for user auth and edit-history preservation is a good place to start.
 * Announcement of intention: (please discuss) It might be nice to allow known editors to announce scheduled deliveries to avoid duplication ? Unsure on this point.

First technology thoughts
The "offline", "simple" and "maintainable" requirements suggest an HTML 5 offline style application. If we were able to impose a restricted browser support list (i.e. pc with chrome/safari/firefox 4 or iphone/android/blackberry phone) this would be a workable solution. It would also inherit the location sensing capabilities built into the browsers.

See here for an intro to HTML 5 techniques with phones.