I'm not sure how this affects the scenarios Ashkan has outline below,
but we would like to have the ability to show users the data we log
before they 'send' it to us. Eventually, we would also like the
ability for users to specify how much information they would like to
share (like setting access privileges if you will).
(+) Share everything
( ) Share selected attributes
[ ] Addressing fields
[ ] Titles
[ ] Location
[ ] Date/time information
[ ] Notes field text
[ ] Collection names
I think this will address some people's privacy concerns.
Logging and sharing usage pattern data might also become a great way
for users to actively participate in the design process. When they
describe a feature they would like or a problem they are having with
the app, they can supplement their written descriptions with a log of
how they interacted with the app.
Mimi
On Jun 26, 2006, at 3:59 PM, Ashkan Soltani wrote:
Hey all
I'm Ashkan, one of the interns working with the PPD team this
summer. My project it to instrument a usage tracking compoment
within Chandler in an attemt to better understand how dogfooders
are using the app. The idea is if we can gather logging data, we
can make better assumptions of what people actually do on a regular
basis and focus energies in improving those activities.
With a lot of JohnA's help, I've managed to put together a small
compement that logs blockEvent and some of context to a file or
stderr. (I should preface this by saying that I don't have any
previous exp w/ Python .... most of my development was in Perl and C)
Now that I'm able to log the events, I need to find a way to
consolidate this logging information and get it back to us for
review/analysis (both automated statistics crunching as well as
individual workflow analysis)
The 'logging' workflow is:
- dogfooders enable 'logging' via a pulldown in the Chandler test
menu pulldown
- they enter are prompted for a 'username' (basically an arbitrary
identifier), displayed some privacy disclaimer, and then a unique
userid is generated for them (or possibly pulled from a system
variable if it exists?)
- the system logs user data, either on the local filesystem or
some remote logserver
- if the logging is local, then on some interval, chandler would
'send' this information to us somehow
- users can disable/re-enable logging at any time
Questions:
What would be the best way to 'collect' this data, given that users
may or may not have network access, or could possibly be
firewalled, etc. (*caveat: i'm looking for a quick low-hanging
fruit such that more time can be spent on the analysis side of the
project)
Possible idea's I've considered is using HTTP in real time (or via
implementing a buffering system) to log the data to a central
server. There's some direct support for this in the python logging
module under HTTPHandler: http://docs.python.org/lib/module-
logging.html
Alternatives would be to use a 'sync' procedure, either via rsync/
ftp or perhaps even the background sync module to upload the
logdata to our servers. The implementation for this stuff would be
a bit more involved, specially since I'm not storing the logdata in
the repository and would need to figure out how to encapsulate it,
but it might be more compatible with the rest of the chandler
methodology.
The last/simplest approach would be to use simple SMTP to post the
information since we know that more often than not, users will have
'at least' SMTP access from within Chandler since it is a mail app
after all.
I've looked into all three approaches quite a bit and just wanted
to get some feedback as to what people think would be the best way
to do this.
-a
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
