1. Microfinance: As part
of his UW PhD work Tapan Parikh created a tool called
CAM for helping microfinance self-help groups digitize their paper logs. CAM ran on a Nokia Series 60 phone and
used the camera to read 2D barcodes printed on the receipt and ledger
forms. After reading the barcode,
CAM would prompt the user (using audio) to enter the data elements on the form
using the phone keypad. It would
also speak out a value if it had already been entered. This project would recreate CAM on an
Android platform (that already includes a barcode scanner) and consider
completing some of CAM’s future work as well as using a more standard
form description language (e.g., XForms). See Tapan S.
Parikh, Designing
an Architecture for Delivering Mobile Information Services to the Rural
Developing World, Ph.D. Dissertation, University of Washington, 2007.
2. Paper to
Digital: Port an open source
optical character recognition (OCR) system such as Tesseract
to Android and use it to scan basic numerical forms (as those used above for
microfinance). See http://code.google.com/p/tesseract-ocr/ for source code and
documentation. Ideally, the system
would include a way to describe the likely position of numbers on a form and
map the form to a spreadsheet (.csv or .xls).
3. Location Tracks: Smartphones
include location systems that use GPS and WiFi
sensors. It would be useful to be
able to have a power-conscious tracking system that would allow one to turn on
tracking and capture the path from that past point to the current location. The user should be able to easily set
rate of location sampling (by time or distance from last point) and have the
system make the optimal choices regarding power consumption (keeping the GPS
and/or WiFi system active continuously can burn a lot
of battery power, but shutting them on and off can make getting a location fix
slower). The system would ideally
generate a KML formatted track.
Think of it as a set of breadcrumbs to help you retrace your steps or
communicate the path you took to others.
4. Bluetooth Remote
Sensing: FoneAstra
is a small plug-in board for low-tier cell phones that allows them to connect
to external sensors and send data from the sensors using SMS. It would be useful to have a very
low-power version that had Bluetooth capability (not requiring a phone to be
present at all time) and transfer data when a smartphone
is nearby. The phone should engage
in a wireless dialog over Bluetooth with the sensor board and not only gather
data but also set operating parameters and get battery levels. One could start by modifying the current
FoneAstra board or finding a more appropriate
low-power starting board from sparkfun or similar
sites. This project would find
immediate application in a Ethiopia-based study on how
much time households spend fetching water.
See R. Chaudhri, G. Borriello, R.
Anderson, S. McGuire, E. O’Rourke, FoneAstra:
Enabling Remote
Monitoring of Vaccine Cold-Chains Using Commodity Mobile Phones [pdf], ACM
First Annual Symposium on Computing for Development,
London, December 2010.
5.
FoneAstra Programming Environment: Combine
FoneAstra hardware with the Uju
SMS system from NYU. See W-C. Lu,
M. Tierney, J. Chen, F. Kazi. A. Hubard,
J. C. Pasquel, L. Subramanian, B. Rao,
Uju: SMS-based Mobile Applications Made Easy, [pdf],
ACM First Annual Symposium on Computing for Development, London, December
2010. This would provide an easily
configurable way for FoneAstra to report its sensor
readings without requiring low-level programming of the board.
6. Bluetooth Sensors:
Work with PASCO Instruments’ sensors to develop a set of Bluetooth and/or
USB sensors for smartphones focusing on sensors that
are likely to be useful for medical applications such as stethoscopes and
EKGs. See http://www.pasco.com/.
7. MXit in the USA: MXit is a messaging systems that
provides SMS-like functionality over GPRS which is usually orders of magnitude
cheaper with pay-as-you-go dataplans popular in most
other countries. This project would
re-implement MXit to work in the US, possibly taking
advantage of cloud-based servers such as Google’s AppEngine. See http://en.wikipedia.org/wiki/MXit.
8. Phone Remote: Create
a remote control device for home devices that the phone can talk to through the
cloud. It should enable a user
whether away or at home to control a variety of devices in the home. One could start with television
recording and also consider lighting and backyard watering. It may be interesting to consider a home
WiFi to IR gateway to take the place of typical
remote control devices. An
important issue here will be security.
9. Open Data Kit
Enhancements: Open Data Kit (http://opendatakit.org) has been a
successful project in enabling form-based surveys and flowcharts on Android
phones. As ODK matures, it requires
many other presentation types. For
example, a long list of yes/no questions should be represented as a matrix with
columns for question text, yes, no, and maybe (and don’t know) checkboxes
so that it is much more compact than having a single screen for each
question. Another example is selecting
an option based on a graphic rather than text. Yet another is selection based on typing
a few letters that are used to search a database of options on the phone. One could also consider caching previous
answers.
10. ODK on Tablets: ODK
can run more richly on a tablet with its increased screen space. One interesting option is to have the
rendering of the form show the answers to the previous couple of questions at
the top and upcoming questions at the bottom to provide context.
11. ODK Tables: Work on
aspects of an ongoing project to organize snippets of data sent via SMS or
email into tables on a phone so that it is easy for a user to see aggregated
data and reply to individual messages.
A database on the phone holds the data. Filters are needed to extract the data
from the messages and generated new ones that are human readable. Think of it as Google Calendar’s
easy addition of entries by typing in “lunch at 12:30 with
Joe”.
12. ODK Tasks: Open Data Kit is a mobile data
collection tool. See http://opendatakit.org. It is based on the user filling out
forms that ask for a specific set of data.
We need a tool to organize the tasks that need to get done, that is, a
deadline, customer, and form that needs to be filled
out so that the user can plan what tasks they need to accomplish when. Ideally, this would include building a
calendar schedule from the pending tasks.
13. Database-Centric
ODK: Reimplement
ODK’s form parser (now based on JavaRosa
– http://www.openrosa.org) with a parser that
places forms in a database with the appropriate schema. This could be quite a complex project as
JavaRosa includes the capability of having computed
fields and conditional question flow.
14. ODK in HTML5: Reimplement
some of the functionality of ODK in HTML5 using the Android web browser. The idea here would be to see how well
HTML5 could do the same tasks and also how well it supports disconnected
operation.
15. ODK Manage: An
organization using many phones running ODK needs to be able to contact all
users and push updates of applications, forms, and databases. A version already exists but could use
freshening up and updating to our new authorization scheme.
16. ODK Visualize: Data collected with ODK is stored on the
phone for later transmission to a server.
It would be nice to be able to create visualization forms that allow
someone to view all the completed forms on their own phone along with a summary
of the data that can be configured in a template. Ideally, this would also include the capability
to map (or at least cluster) location fixes.
17. NatureMapping: Create a quick application for doing
sound and image/video capture so that when out hiking one can record encounters
with animals quickly. Consider a
continuous mode where the last 30 seconds in kept in a buffer in case something
happens that needs to be recorded.
See http://depts.washington.edu/natmap/.
18. OneBusAway Trip Planning: Add a trip planning interface to OneBusAway with particular attention to how to choose
transfers for multi-bus trips. Also
consider approximate source and destination so that one can consider walking to
a slightly more distant bus stop to get close to the destination sooner. See http://onebusaway.org.
19. Library
Inventory: make it easy to scan the
barcode on the back of physical books and create a spreadsheet of titles,
authors, dates, links, and notes.
Make it easy to do searches of physical libraries by linking to virtual
version of books. Another option is
to consider Google Goggles rather than barcodes but that may be too slow for
practical use but may be a last resort option.
20. GeoSMS: Adapt InSTEDD Geochat to work on a smartphone
and allow the sending of SMSs that include a location fix with addresses based
on location, e.g., send to friends within a mile.
21. Location Updates:
Determine waypoints from accelerometer/compass data and assign policies for
when to report a user’s current location on social network, twitter, or
just direct SMS. Make it easy to
select how to report location (precise coordinate, approximate – e.g.,
work, home, or even by selecting from previously used options). Also set up times to report, or report
only for certain types of activities.
More elaborate schemes could include incremental learning from
examples. Connect to GeoSMS above.
22. Route Mapper: Map out
walks and bike rides based on preferences, past history, and approximate
start/stop locations. Include local
historical, art, political information and play it along the route. Essentially create a custom tour of
cities and neighborhoods.