MicroThoughts

Richard Bailey, Kimberly Spreen, Gennadiy Stepanov

Problem Statement
The environment we work (and relax) in today provides a constant supply of
information for us to process and the volume of this has been growing at an alarming
rate over the past several years[4]. Unfortunately, as of yet, very little has
materialized in the consumer market that can provide a low impact, high return
method to manage this information overload. Further, all signs indicate that the
problem will only continue to worsen for the foreseeable future. The goal of
MicroThoughts is to fill this gap and provide a minimally intrusive manner to take the
memos, ideas, and notes that you have during the day and make them persist past
your next interruption.

System Summary
MicroThoughts (MT) is a system for storing, organizing, and visualizing audio notes
taken throughout the day, using geospatial and temporal markers. Notes are taken
using a cell phone, PDA, or other handheld device, which is also responsible for
marking the time and lat/long location of the user. This information is then sent to a
central server for storage and indexing. The notes are retrieved using a web
application that the user logs into and are also available to browse over the phone.
Photos or text memos taken with the phone can also be bound to the note. As an
advanced feature, a note can be shared with users who are nearby when it is recorded.
For example, if the user is in a project meeting, he may wish to add his teammates as
recipients. This could be done using Bluetooth to detect nearby phones or with a web
service to find users who are co-located based on their current location. The web
application provides a rich visualization of the information, combining maps and a
timeline to find notes bound to certain locations at certain times. In addition to
searching based on time and location, MT will employ a remote Speech-To-Text
(STT) engine that will attempt to create an indexable transcription of the note to
enable text search.

After much research and contemplation, our team has decided to prototype MT using
the Google Android[5] platform, with the hope of taking part in the development
competition this spring. Choosing to use Android has shifted our focus somewhat, in
that we are now more interested in the mobile application than the desktop web
application. The web app, however, remains an important part of the MT concept as
a whole and we plan to pursue development of it after the Android prototype is
completed, time permitting.

As an extension to the basic MT premise, we have considered an interesting social

Feature Classifications
MT as we have described is a large and complicated system that would take a team of
3 engineers a significant amount of time to thoroughly design, implement, and debug.
Considering the competition for our time it is unlikely that we will be able to fully
implement MT as it has been described. For this reason we divide MT features into
three distinct groups: Minimum, Expected, and Reach Goals.
Minimum Goal
These goals must be reached in order to not consider this project a failure. Should
these goals not be reached we should have a good explanation of the technical
limitations that caused this.
 Mobile prototype working on an emulated handset device
 Pre-recorded audio to act as input
 Browsing via mobile device
 Manual tagging of notes
Expected Goal
Barring any blocking technical issues this level of functionality is expected to be
reached. We would consider the project highly successful if we reach these goals;
 Coherent, extensible, and maintainable design
 Live audio as input
 GPS simulation for multiple users
 Speech to text analysis to auto-tag notes
 Advanced visualization tool(s)
Reach Goal
Any pursuit of these goals should come only after all expected goals have been met.
Should any of these goals be reached we would consider MT as approaching
suitability for a public beta.
 Web driven interface for thought navigation
 Multi-party ThoughtCast aggregation
 Prototype running on an physical handset / generalization beyond Android
 Location tracking via WhereAmI / GPS
 Desktop web application with rich visualizations

Expected Issues
As with any significant project we don’t expect anything to go exactly as planned but
we have identified and elaborated a few of the high risk areas for this project.
Legal
In related work[2] there was some concern about the legality of recording audio for
future use. It is our opinion that while these concerns were valid in the case of PAL it
was so because of the intent of the user to record not only their comments but those of
 their companions as well. Based on our reading of ECPA[1] it is the intent of the
recorder that is key and that an unintentional recording of another’s words would not
make them legally liable. Additionally, the usage of MT is designed in such a way
that recording is initiated after the occurrence we wish to record has passed which
even further reduces the likelihood that a user of MT would be able to maliciously
obtain a recording of those surrounding them. This is our interpretation as laymen
and further, more formal, investigation will need to be pursued in the event we take
the MT implementation beyond the scope of this class.
Technical
While originally our goal was to have an implementation of MT working on the
Nokia N80 handset, our decision to take part in the Google Android competition has
made this infeasible. Unless a simple solution to putting Android on an actual
handset presents itself over the next couple months, our final prototype will most
likely be limited to the Android emulator. While this will undoubtedly make it more
difficult to test our system in a real world setting, we feel that it is a worthy tradeoff
for the chance to explore this new technology and participate in this high-profile
competition.
One technical hurdle we face is getting sound recording and playback to work
seamlessly alongside the emulator, which at the time does not have native support for
audio recording. We have considered streaming the audio from a separate recording
application to the device emulator, but still need to investigate this issue further as it
is necessary for the success of our prototype.
Besides this specific issue, there is the fact that no one on our team has any previous
experience using Android, which means we all face a learning curve here at the
beginning. This learning curve may be made steeper by the fact that Android is a
new platform that most likely has bugs, and that currently lacks a rich knowledge
base and online community.
References
1. US Code, Title 18, Part 1, Chapter 19, §2511; “Interception and disclosure of
wire, oral, or electronic communications prohibited”;
http://www.law.cornell.edu/uscode/18/usc_sec_18_00002511----000-.html
2. Hayes, G.R., et al; The Personal Audio Loop: Designing a Ubiquitous Audio-
Based Memory Aid; 6th International Conference of HCI with Mobile Devices and
Services, 2004
3. Miller, G.; The Magical Number Seven, Plus or Minus Two: Some Limits on our
Capacity for Processing Information; http://psychclassics.yorku.ca/Miller/
4. Lyman, Peter and Varian, Hal; How Much Information 2003;
http://www2.sims.berkeley.edu/research/projects/how-much-info-2003/
5. Google Android; An Open Handset Alliance Project;
http://code.google.com/android