MicroThoughts
Richard Bailey, Kim Spreen, G Stepanov
bask@okcoder.com
Abstract
MicroThoughts is a system for storing, organizing, and visualizing notes
taken throughout the day using geospatial and temporal markers. This paper
discusses our project’s goals, how we measured up to them, and what challenges
we faced along the way.
1
Introduction
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. 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.
2
Project Objectives
MicroThoughts’ goal was to build an end–to–end solution for personal note creation,
search, and sharing. We wanted to provide multiple methods to access this information and explore the growing area of mobile usability and webservice creation.
3
Look, We’re Solving Problems!
With the rapid advancements in the power and versatility of mobile devices and the
recent release of the Apple iPhone, the land of mobile usability research is an exciting
place to be. MicroThoughts lies at the center of this activity, combining the minutiae
of ground-up construction of a converged mobile application and an interesting set
of usability questions posed by our application. The scope of the server work here is
not terribly novel and most of the true research questions lie in the usability realm:
• How much data should be exposed to the user on a mobile device? What of
this is the most useful?
1
Figure 1: MicroThoughts Server and Client Architecture
• What are the most important actions from each of our interaction screens? Do
we expose too few actions or too many?
• What functionality should be sacrificed from the mobile device so that the
experience is better polished.
• How do we manage user privacy given the locational nature of our project? Will
this even concern the end user?
3.1
System Decomposition
Our system archiceture is designed with extensibility in mind as the scope of this
project as a whole is far beyond what is possible during the time frame of this course.
Our basic division of the project is between the the web service and the client code.
The mobile device implementation varies significantly depending on the features available on the device in question but the decomposition for a basic device can been seen
in Figure 1. The MicroThoughts server is divided into four primary segments: a
2
persistence layer, a layer designed to post process data submitted to MicroThoughts,
a segment that performs business logic on input from external sources, and a conversion layer for external servers that enables interactions with third parties (or us)
that may want to provide value added services on top of MicroThoughts.
Of these three layers the post processing and exposed APIs are the most interesting. Currently the only post processing we’re plannig to implement is speech–to–text
allowing automated thought indexing based on the (audio)content and audio tags that
may be submitted. The layer that exposes an API to our service is very interesting in
that it allows us and other groups to easily extend the functionality of MicroThoughts
by using our service in a combinatorial or derivative application. The types of applications that could be produced are vast and limited only by the imagination of our
users.
3.2
Evaluation Metrics
Because of our choice of platform–Andoid–we were unable to run user studies with
a real handset and feel that the difference between the Android emulator and a
protoypte running on a physical handset would minimize the use of any usability
tests we ran. For that reason we set our success metrics to be primarilly technical in
nature (in order of difficulty):
• Browsing via mobile device
• Manual tagging of notes
• Coherent, extensible, and maintainable design
• Speech to text analysis to auto-tag notes
• Advanced visualization tool(s)
• Web driven interface for thought navigation
• Multi-party ThoughtCast aggregation
• Prototype running on an physical handset / generalization beyond Android
Of these, we achieved all save speech–to–text(STT) analysis, a web-driven interface,
and full ThoughtCast support. STT was dropped because the library we wanted to
use proved less viable than originally expected. Our original interest in a web-interface
was delayed because our decision to compete in the Android competition made the
client functionality much more important. The only feature we missed completely
was full ThoughtCast support and this was simply resulting from a lack of time as
thought sharing, a similar feature, is fulling implemented.
3
4
Lessons Learned
All of the teammembers worked incredibly hard in this project and given the scope
there was not a significant amount of overlap. As a result of this schism we each took
a different set of experiences and lessons from this project.
Kim worked primarily on the Map Visualization and related interaction techniques. From this she gained (rather surprisingly) experience in extending the Android UI toolkit to support draggable objects. She also worked with Richard on
the server and manages the production server we’re running for the google Android
competition.
Server work and the invisible framework that makes the Android client function
was cobbled together my Richard who, until this semester, had no experience working
with mobile devices. He was able to apply some basic systems concepts (cache management) and build a WebService adapter which put him in the unenviable place of
having his teammates rely on his code for the actual application to work all of which
he said was “new and exciting”.
To actually use the application you will use the section that G created. G has a
background in HCI and felt at howe working with the interace, his problems came
when we began trying to optimize the interactions for devices with limited screen real
estate. As the other teammates, G had no mobile or small form factor experience so
this provided him a first hand to learn the issues related. G also was responsible for
the client–internal database and provided an mini-ORM over it, which he had never
healt with before.
4.1
Coursework that proved relevant
Though many classes have relevant material to this project, the server and server interaction segments are the areas in which this class had the higest relevance. Because
we were aiming at building a scalabe, failure tolerant webservice, while optimizing the
client latency, we found inspiration and ideas in many of the Application/server and
Caching papers. Due to time constraits the server side for much of these optimizations was not implemented, but there was heavy use of client side caching (both of
content to reduce bandwitdth and jobs to ammoritize the cost of connection to the
internet). There was also notable contributions to our plans for providing location
privacy guarantees to our users and proximity based searches from this course.
5
Contributions
In addition to the practical usefulness of MicroThoughts we feel that in three significant ways it will provide benefit to the communities which we became part of during
the implementation of this project.
• Our concept of combining thought tracking based on spatial and temporal dimensions is unique to our project.
4
• The drag-and-drop work we did on Android may very well be the first implementation in the world on that platform.
• MicroThoughts promises to provide an avenue of research into many areas such
as the usefulness of memory aids, the effect of location as an index to seach for
memories, and low interrpution interaction techniques with handheld devices.
6
Future Work
The amount of future work we wish to pursue as a result of this project is vast. At the
minimum level we expect to implement a port of the software to the iPhone. From
there at least Richard will be attempting to continue with this academically with a
usability evaluation of the interface that will hopefully inform any further changes.
The team is hopeful about their Android competition entry will continue Android
development for Round 2 if choosen as winners on May 5th.
5