Haystack Blog

HCI research needs to get better at spreading the word, sooner, in the Web 2.0 era.  Typically, by the time that CHI rolls around, the research being presented is at least 7 months old.  When (or if) a group decides to post PDFs early, the papers are so distributed that interested readers can’t find them. What’s more, the research that is posted isn’t presented in a web-friendly way: how many web pages do you read in PDF form?  But, when HCI research is made available in an interesting and accessible form, it often gets great press.

What I’m thinking might remedy the situation is a CHI early results blog.  It would work like this: when a paper is accepted to CHI, the SIGCHI blog administrators e-mail the authors and invite them to write a short blog post describing the results that will be appearing at the conference. It should be written for a general web audience and other HCI researchers and practitioners. This would not just be the abstract and intro; the blog would highly encourage pictures, videos, and any other media. The drafts would be vetted for readability, and then posted as soon as they are ready (with some flow control to make sure we don’t post too many items at once). This means results could be posted as early as December.

If successful, this could be a great way to accelerate the dissemination of important research results, generate lots of positive buzz for the conference and the papers in it, keep research conversations going year-round, and increase the number of HCI posts on Slashdot. And I mean, Slashdot is our currency, really.

What do you think?  Would you post in a centralized SIGCHI blog when your papers get accepted?

Ever since returning from the 2009 International Semantic Web Conference last week I’ve been bursting to discuss a panel that took place there on the topic “Does the Semantic Web need Ontologies?”.    But the WWW2010 deadline was today and we had 3 papers to write.  With that deadline now 10 minutes past, I can finally post!  When it was first proposed, I was concerned because panels need controversy to be fun, and I didn’t think there’d be debate on this topic.  However, the organizer was confident that he’d be able to arrange different viewpoints on the panel.

When I attended the panel I was sorry to discover that the panelist did in fact all agree.  Far worse, they all said “yes” and wanted to debate what kind of ontologies were needed. Those who’ve followed my slow conversation with Stefano Mazzocchi won’t be surprised at my reaction—ajump to the audience microphone to voice a strong “no!”   I asserted that a bunch of data presented in spreadsheets was already a big step forward over our current unstructured web.  This led to some interesting discussion that helped me clarify some points in my mind that I’ll try to lay out here.

The panelists’ general reaction was amazement that I could be opposed to ontologies.  Without ontologies, how could any tool actually use the data?  What good would that data be without an explanation of what it meant?

Tim Berners Lee tried to mediate by suggesting that I did support ontologies.  After all, a spreadsheet has an ontology: the ontology specifies rows, columns, cells, and the relationship between them. But by this definition, any structured data necessarily has an (implicit) ontology, and saying “ontology” is just another way of saying “structured data”.   And I think this diverges from the standard meaning of “ontology” in the Semantic Web community, which I would read as “an explicitly recorded, machine readable description of the ontology of the given data.”   While I am a big proponent of structured data I’m going to bet that the panelists would not consider their implicit ontologies to be ontologies in the Semantic Web sense.   So we do in fact disagree.

Why then do I think we don’t need (explicit) ontologies?   Because I’m focused on the ways that human beings, rather than machine agents, will consume the data being shared.  And for humans, a machine-readable explanation of the data’s meaning is often unnecessary because the human who is consuming that data can figure it out in other ways.  For example, the meaning of the data elements might be explained in English, a “caption” of the data I am inspecting.     Even without captions, if I get a data table with column headings, I can use my comprehension of English to understand the meaning of those headings and from it infer the roles of the columns.  Even if there aren’t column headings, the “shape” of the data can tell me a lot—I’ll recognize standard person names, phone numbers, addresses, prices, book titles, and such from the textual patterns or from matches to my large wetware database of known entities.  And if I see enough examples I can draw conclusions about the values in the column (indeed, Google Squared suggests that you might not even need a human in the loop to make these inferences).

So humans can understand data without (explicit) ontologies, but is it any use?  Sure!  Just to plug some of my own group’s tools, they can use Exhibit to throw it into a rich visualization—a map, timeline, or list with faceted browsing and sorting.   Or they can combine it with another data set using Potluck, and throw the combined data into an Exhibit visualization.  I can make a post on ManyEyes or throw the data into DabbleDB for further processing.  These activities typically require me to match certain properties (columns) of the data set into roles in the UI (Exhibit, ManyEyes) or to properties in the other data set (Potluck, DabbleDB)—a straightforward task.  They don’t require the machine to understand the data, because I’m the one taking these actions.  They do require that the data be structured, since otherwise there’s no way for me to say “which column” to the tools I’m trying to use.

That’s the argument I wanted to make at the panel, but it’s a bit hard to squeeze into 20 seconds at the audience-feedback microphone.  So I’m afraid the panelists instead thought that I was arguing against ontologies, asserting that they should not be deployed at all.

On the  contrary, I like ontologies.  But I’m convinced that ontologies are a luxury, not a necessity. They’re certainly nice to have, and there are some things you can only do if you have them–for example, theycan help me understand column headings written in Russian or Spanish by connecting them to explanations in English.  But I remain captivated all the opportunities that arise just by making data easily accessible in raw form.   Too often, what people want to do with information is perfectly easy to explain, but impossible to do without serious programming, for silly reasons.

And it’s that enthusiasm for open data that keeps me energetically arguing that we don’t need ontologies.  If we need ontologies, then work on freeing data needs to stop until we get them.  I think that’s a very dangerous perspective.  It’s the one that says “there’s no point to building tools for scientists to publish their data, until we’ve figured out the right huge ontology that we’ll force them all to publish in.”

Instead, I think we should go right ahead with our research on ontologies and tools for them, but in the meantime, let the data fly!

P.S. When someone rose to support me, arguing that we should forget ontologies and concentrate on Linked Open Data, I mudied things further by asserting that we don’t really need the “Linked” part, and Open Data is useful in its own right.  While it comes from the same place as my perspective on ontologies above, that’s the substance of my discussion with Stefano, and I won’t repeat it here.

Right now the world’s premiere semantic web conference is happening in Washington, D.C. As a graduate student of the fellow who’s chairing the conference this year, and working down the hall from Sir Linked Data himself, I’ve had my fair share of semantic web experiences. But my background is not in Semantic Web technology, so joining a group so focused on the semantic web threw some of its core tenets into sharp relief for me.

So here, from the perspective of a human-computer interaction guy, is what I’d like to see changed about the semantic web:

Stop Calling Everything ‘Semantic’

At worst, the term ’semantic’ in a title can mean “we re-did existing research using {RDF, RDFa, N3, OWL, SPARQL, DBpedia, Semantic MediaWiki},” without a clear notion of why this would be a good thing. The strength of the semantic web is its ability to interoperate heterogeneous data, yet the inclination is to ignore this and work on the problem, any problem, in a semantic web framework. Semantic web research papers can feel like a bunch of hammers running around in search of a nail. And there are plenty of oft-hammered nails: semantic query visualizations, semantic desktops, semantic wikis, semantic ontology alignment, and semantic web service composition, to name a few. Why do these benefit from being semantic, any moreso than taking another approach?

At best, the term is still very unclear about what it implies. ‘Semantic’ should mean more than a language or a framework. It is an idea, and the idea should drive the research. Saying that something is semantic should imply something as clearly as saying that it is a proof by reduction, or a tangible user interface, or a static code analysis technique.

Who’s the User? (And Why Would They Ever Use This?)

That’s not a jab. It composes two specific critiques:

To solve important problems, you need to know who your users are. What are their problems? What biases and constraints do they bring to your system? This is true whether you’re composing web services or creating a Linux desktop. Semantic web technology’s greatest strength and greatest weakness is that it is very general. Too many projects focus on trying to help everybody; but too often, “everybody” is too vague to give you a good foothold, and it trends toward “semantic web-interested people”. This leads to many issues with the research, not the least of them is the Big Fat Graph solution to every semantic web problem and the requirement that I manually author RDF triples. When you’re defining the problem, define the set of users! “Everybody” is too vague; start with some personas or scenarios, or build systems that aim at some subset of the world. This will give you the insights necessary to generalize back out to “everybody”.

Second, there are some serious questions about user motivation. The semantic web suffers from a real cold start problem — how to get all that data into linked format.  Again, no single motivator will work for everybody, so the resulting motivators are so general, or so tied to implicit semantic web assumptions, that few get off the ground. Nobody wants to sit and re-encode their data into semantic web format.  But given a real problem, and the promise of a solution that just so happens to involve RDF, it will happen.

This is why I think Semantic Web UIs is something of a misnomer. It’s like “Java Swing UIs” or “UIs based on a relational database backend and a PHP frontend”. The critical irony of a good semantic web UI is that there should be no indication that it’s semantic. You could do this using a standard database and data model, but it’s easier because it uses semantic web technologies. Again, the interface should flow from the problems, not from the data model (flexible as it is).

I’d love to hear a semantic web researcher’s critique of human-computer interaction. Or your thoughts on my thoughts…

Many years ago I discovered NoteWorthy Composer, and I’ve been using it for music notation ever since.

Unfortunately, I find that NoteWorthy doesn’t scale very well in several important dimensions. In particular, it lacks the ability to:

• Let the user manipulate multiple staves at once (even just for copying/cutting and pasting a horizontal section of music from one place/time to another).
• View several staves as a single “condensed” score.
• Save vertical screen estate by hiding staffs containing only rests for a given interval (Stravinsky-style “cutout scores”) .
• Switch rapidly between transposed and untransposed views of the parts in the music, and handle copy/paste between transposed parts. For instance, (Bb) trumpet parts are “written” two semitones higher than they “sound”, so when you copy a melody from a piano part (untransposed) to the trumpet, it should appear as if it was transposed up by two semitones.
• Hide presentation details from the user. I spend much time adjusting the location of staff items (like an “mf” dynamic marking) so they don’t collide. Also, copy/paste works on a too low level (see above), so if you copy a melody from a treble clef part into a bass clef part, or from a location with one key signature to one with another, the result will be incorrect until fixed manually. Also, the current clefs and time/key signatures are not shown to the left of the screen like they ought to.
• Associate note velocities recorded with a MIDI keyboard with notes in the score for improved expressiveness in future playback. Actually, I want more than this: I also want the ability to record volume changes (e.g. from an external MIDI expression pedal), and the ability to record tempo variances (rubato, fermata, and all the little things that make human performances better than plain computer playback from a digital score) in the same way.

For these reasons, I every now and then decide to stray away and try the latest version of Finale or Sibelius, most recently the latter. I find these full-fledged music notation packages can do almost anything, except letting the user manipulate the score efficiently. Whereas in NoteWorthy, there is almost never any reason to reach for the mouse, Sibelius forces you to click all the time. In general, I find NoteWorthy’s editing model beats that of Sibelius by great margin when it comes to entering music on a single staff.

Granted, NoteWorthy’s model is very unconventional and quite weird. It regards every staff as a separate list of staff “items” (which includes notes, rests, bar lines, clefs, key signatures, and such), and editing is done word processor-style: there is a cursor which goes between staff items (unlike in Sibelius, where it seems the cursor can be either between or on an item), and the staff items behave like characters, meaning you can delete them with the backspace or delete keys, select them by moving the cursors left or right while holding down Shift, and so on. Measures work like to words, meaning you can move the cursor quickly between them via Ctrl+Left/Right. This all works extremely well for single staves, and when entering multi-staff music linearly from beginning to end. However, NoteWorthy’s editing model fails horribly if you make a mistake while editing the middle of a piece of music with multiple staves:

Notice how the error propagates to the entire rest of the piece, and how the user him/herself has to figure out where there’s a missing note and what that missing note’s duration might be. In fact, the situation above needs not even be an error: if you wanted to replace the contents of one measure in the middle of the piece, the staves would inevitably be misaligned (like above) during the editing operation. This forces the user to think very hard about editing—if you lose track of what you’re doing for just a second, it’s a pain to figure out how to realign the staves again.

Despite all of this, I find I can work so much faster in this environment than in say, Sibelius, that I’m sticking with NoteWorthy for now. But future blog posts shall reveal my glorious plans to fix all of this by writing my own music notation software (no, NoteWorthy is not open source, unfortunately)…

Which approach do you take to managing information overload on the web?  Do you unleash the firehose on yourself, subscribing to RSS feeds or relying on content aggregators to keep up with the news?  Or do you take small sips from the stream of content, regularly checking a small set of websites to look for updates?  It’s a common problem: firehosers dedicate much of their time to finding the golden nugget in the stream, whereas the sippers have given up on hearing everything—they will settle for a subset of the news. In both cases, highly personalized information often misses the recipient, or arrives late.

We’ve been looking at ways to empower another source highly personalized content: our friends, family, and coworkers. They already share web pages with us by e-mail, in person, and on social networks.  Social link sharing is often high-quality and personalized: quality is vetted by people you trust, and personalization is implicit when your social network uses its notion of your interests and tastes to forward you links.  Social link sharing is not perfect either—we all have that friend that’s filling up our mailbox with e-mails that contain the subject line “Fwd: Fwd: Fwd: puppies,” and our considerate friends sometimes avoid sending us content to avoid being perceived as that person.

Michael and I have been working on a multi-stage project to understand the social processes behind web content sharing and to support those processes by introducing a novel tool called FeedMe to facilitate such sharing.  We’ve published our findings in this technical report, and have summarized the results below.  Today we’ll be sharing part 1, where we will discuss our initial exploration to understand social link sharing; in the next post, you’ll be hearing about the tool we built based on these findings, and you’ll get a chance to sign up for a public release of FeedMe!

Link-Sharing Surveys
We conducted two surveys encompassing 140 users of Amazon Mechanical Turk, one focusing on what it’s like to receive posts, and the other focusing on what people think about when sharing.

In our receiver surveys, we learned several things:

• E-mail is the dominant link-sharing medium.  Receivers cited a lack of time as a reason for why they do not visit content aggregators to find the top web content.  Sharers share content through email over all other mechanisms, because it is ubiquitous on the internet, and is a consistent protocol for sending content with anyone.  Another interesting tidbit: in addition to being the dominant link-sharing mechanism, e-mail tied regularly visiting one’s favorite websites as the the dominant information-finding mechanism.  Few users utilized feed readers, social aggregators, or social networks for links.  It turns out that e-mail is not dying in favor of Facebook and Twitter, especially not for the average user.
• Topic Interest Drives Enjoyment.  The biggest reasons receivers cited for liking shared content was the relevance and entertainment value of the content.  Off-topic shares were off-putting for them.  Sharers were conscious of this; relevance and timeliness were their biggest concerns.
• Link Sharing is Burdensome when it is a Repetitive Firehose.  Receivers disliked it most when sharers could not rate-limit themselves.  One user complained about a sharer who blindly forwards 10-20 e-mails per day.
• Small Audiences are Best.  A small recipient list is a good predictor of whether recipients will appreciate the content.
• Friends are the Most Common Target.  Sharers share more content with friends than family or co-workers, and their set of receiving friends are a small group that they regularly communicate with.
• Receivers Want Even More.  If guaranteed high-quality content, receivers claimed they would like to have more links shared with them.

From active sharers, we learned:

• Sharing Correlates with Seeking.  Individuals that identify with spending a large amount of time seeking out web content are also those that identify with sharing a large amount of content, and having their contacts in mind as they read web content.
• Sharing does not Imply Sociality.  You might think that sharing activity is guided by how much of a social butterfly you are. Not so. We measured two types of social capital, and neither was able to explain sharing practice.

Next Up…
With this information in mind, we sought out to build a tool to help heavy information seekers share more content.  Next week we’ll be sharing FeedMe, the tool we built to address this issue.  Until then, feel free to look through our technical report for the detailed results.

I am in a state of transition: from Java to OCaml.

A Java Project in NetBeans

I like Java as a platform primarily for its matureness, static typing, and great IDE integration (Netbeans in particular). But lately I’ve been finding myself manipulating a lot of tree structures—ASTs, query plans, nested relations, automatically generated GUI layouts—and Java is just too verbose. Even using visitor patterns, the real application logic just gets too diluted among classes, methods, and variable declarations to help me gain any additional insights from the coding experience. I find this unacceptable, as one of the main reasons why I code is to solidify my understanding of otherwise theoretical ideas. It was time to move to OCaml.

Well, I only had experience with SML (a dialect of ML) from compiler and programming languages classes and a few smaller projects during undergrad, but I knew that sum types, pattern matching, and strong static inferred typing just might be what could fit 4000 lines of Java into 500 lines of functional goodness. OCaml turns out to be the more popular (and less obscure) dialect of ML, so it seemed like a good choice. I was concerned about tool integration, however.

I took it for granted that OCaml would force me to give up the many great IDE features I had been accustomed to with Java and Netbeans: code completion, editor/build system integration, live documentation browsing etc. Especially since I’m a Windows user (on the desktop, anyway), I had serious concerns about whether I would be able to set up a satisfactory work environment with OCaml. To the rescue came F# .NET, or so it seemed.

An F# Project in Visual Studio

F# is Microsoft Research’s new adoption of OCaml for the .NET environment. In essence, F# is to OCaml what C# was to Java, and one of its big selling points is integration with Visual Studio. Excited, I bought Expert F# (a very good reference book, which I will use even as I learn OCaml) and downloaded the F# May 2009 Community Technology Preview for Visual Studio 2008. I spent the next two weeks trying to learn and set up the environment to suit my needs, which included parser generation using fsyacc/fslex and heavy use of the F# interpreter to debug my code.

Unfortunately, F#’s Visual Studio integration is to this date rather rudimentary. I understand that the plugin is still in early development, and I’m sure it will improve a lot in the next year or two, but meanwhile, here’s a quick grief list:

• No syntax highlighting or code completion in fslex/fsyacc source files. (While parser generation might be seen as an obscure feature on any other platform, ML people do have a striking tendency to be compiler researchers or language designers…)
• The FsYacc/FsLex MSBuild tasks do not consistently generate new parser/lexer files after the definition files have been modified, and a “clean” operation does not delete the generated files.
• Console apps (e.g. “Hello, World!”) open in a new window which promptly disappears after the end of execution, instead of having their output routed to a console output window. Visual Studio might be a little weird in general here, but I couldn’t figure out how to fix it.
• There is no easy way to use the interactive console in the context of the code that is being built in the current project. For instance, if my project code defines a number of modules, namespaces, functions, and data types which are all compiled into a DLL, I would like to always be able to access the most recent build of those definitions from the interactive console, without too much fuss (see below). Automatic copy-and-paste of raw source code into the interactive console does not do the job when you have multiple files (some possibly generated as part of the build process) and when you don’t want old definitions hanging around.

Currently, a single iteration of interactive testing would involve the following steps:

1. Make a change to the source code.
2. Manually delete fsyacc/fslex-generated files to make sure they are remade on the next build (see above).
3. Reset the interactive console (step 5 below will lock up the output DLL, causing the build to fail if we don’t do this).
4. Do a build.
5. Issue a command like #r “Z:\\Unfinished\\EverythingCO\\trunk\\fswork\\qllib\\bin\Debug\\qllib.dll”;; to make the compiled definitions available from the interactive console.

Add this to the fact that the F# language itself is still bleeding edge, and the costs to productivity start outweighing the benefits. So for now, I decided to abandon F# in favor of OCaml, spending yet another two weeks trying to set up a great work environment.

An OCaml Project with the OCaIDE Eclipse Plugin

And there it was. With Eclipse plus the OcaIDE plug-in (and Cygwin to provide some underlying prerequisites like make), I found everything I wanted. It took a little while to figure out, but in the end I had:

• A Makefile-based build system which would not only work on my own Eclipse/Windows environment, but also for anyone else who might like to check out the code in the future, for instance on Linux. The plug-in has a centralized Preference page to set up all the necessary OCaml paths. Note that the build system I use is just the standard OCamlMakefile—other options are available.
• Code completion and object browsing.
• Syntax highlighting in ocamllex/ocamlyacc definition files (though no code completion in ocamlyacc semantic actions.)
• Automatic rebuild every time I save a file (standard Eclipse stuff).
• Compilation of custom OCaml toplevels, giving me the kind of interactive development I mentioned above (though you still have to manually kill the existing custom toplevel before rebuilding).
• Console app output shows up in a console (compare above).

This, together with the matureness of the OCaml language, has made me choose OCaml over F# for now.

Our online lives are increasingly spent staring at advertisements and commercials.  Understandably so, we’re bombarded in hopes that we’ll click something, and someone, somewhere is making money off of our time this way.  Traditional models of online advertising are pay-per-impression (per view on websites), pay-per-click (for clicking through), or pay-per-action (where users actually act on the ads they’ve seen).

Recently, a new trend in online advertising is appearing.  As many social sites incorporate ‘like’ features or other approval mechanisms, some have started adding this feature to advertisements.  Hulu.com, which streams network-approved videos of television shows and movies, has this feature for their advertisements; another example is popular social networking site Facebook.com.

I can’t purport to speak on the actual financial models behind these actions, but I’m assuming that your thumbs-up on an ad is something that can be monetized as well.  From the user’s perspective , it’s a conflicted action.  Do we like being advertised to?  Are we approving this particular ad?  Are we asking to see more of the same?  Does a click of approval mean we’re interested in this product or service?

The ‘like’ feature is a nebulous thing on its own.  If my friend posts that her car has gotten towed and I ‘like’ that post, does that mean I don’t condone her actions and am satisfied that her car was towed, or is it a symbol of support for her?  However, the real-world analogue of this action comes much more naturally in communication, both verbal and non-verbal.  The confusion here arises when we’ve made this feedback discrete and countable, as opposed to  appropriately complex, complicated, and communcative actions in the non-digital world.

I was doing some experiments with Adam in the lab on Friday, and we discovered some interesting variations in the way that Firefox and Safari implement the HTML 5 Cache Manifest specification. I think this is a particularly important feature to have implemented consistently across platforms because it is the make-or-break feature of HTML5 that will permit web applications to function offline.

First, what is the manifest?

For people who haven’t heard about this feature before, the manifest is essentially a special file that lists portions of a web site that should be cached locally for offline access. This is the feature of HTML 5 that will standardize the type of “airplane mode” access that GMail users have with Google’s custom Gears plugin.

The manifest is served as a regular old file, with MIME type text/cache-manifest, and is linked from the html tag itself, as follows:

<html manifest="site.manifest">

..

</html>

Once a web site is marked as being cached, then the browser will use the local cached copy of all the files specified in the manifest instead of attempting to load them from the internet. Say you’re on an airplane and type in the URL for http://my_cached_site.com. The browser will recognize it as a cached one, load it from its local storage instead, and then use a new JavaScript API to inform the web site that it is running in offline mode.

So now for the important part, how do these two browsers (Firefox and Safari) handle this file?

Firefox

Upon loading an HTML5 document with a manifest attached, Firefox firsts asks permission to cache the site offline before requesting the manifest file from the server. Here is how the toolbar looks on my browser:

And here is the server log (I’m using a Rails project to test this) to show that the manifest was not yet loaded:

If you choose to allow offline caching, the web browser then requests the cache file, as can be seen from this screen shot.

Now here’s the cool thing, I set the headers on the manifest file such that the manifest file itself should also be cached on the client side:

        headers["Expires"] = "Fri, 30 Oct 2010 14:19:41 GMT"
        headers["Cache-Control"] = "max-age=3600, must-revalidate"

And the result of this is that the subsequent load, no files at all are loaded from Firefox — it operates entirely offline. Notice the completely empty server log as I reload the site 2..n times.

Safari

Now let’s look at how Safari does it. Upon loading the web page, Safari also does not load the manifest file, as can be seen from this screen shot:

However, it also does not ask any questions about offline access. The next time I load the web page, something strange happens. Safari checks the manifest file twice and then doesn’t load the actual HTML page (because it doesn’t have to). The double-loading of the manifest file appears to be on the second page load, not split 1/1 between the page departure and subsequent reload. A little strange, if you ask me.

Furthermore, when I reload the page, despite the HTTP headers specifying that the manifest should be cached, Safari reloads the manifest file. Though, at least it only loads it once for every subsequent time:

Conclusion

I’m no spec-master, but it seems like Firefox’s implementation of this feature is what I would want to happen as a web architect, while Safari’s behavior seems a bit strange.

Firefox:

1. Only loads the web page once
2. Asks the user for permission to enter offline mode
3. Only downloads the manifest file once if given permission
4. Then obeys HTTP Cache Control headers to suppress reloading the manifest file on future loads

If Safari were to also behave like this, there are a few fixes that need to be implemented. Namely:

1. Ask the user if offline access should be allowed
2. Load the manifest when the user loads the page the first time (and approves offline mode), not the second time, when the user might be on an airplane
3. Stop loading the manifest file multiple times in a single page load
4. Start obeying the HTTP cache headers so that zero web connections are necessary if the cache says so

Safari’s Manifest handling quirks aside, both browser teams should be applauded for so aggressively implementing the HTML5 spec. It is a real treat as someone researching web platforms to get to test the in-progress spec on real browsers instead of just talking about what might eventually happen down the road.

Today, we rely increasingly on the Web for a multitude of everyday activities that run the gamut from simple queries to complex social interactions. As a result, our browsing patterns are starting to reflect the intricate and multi-faceted nature of our daily lives, but web browsers retain little of the nuanced richness of this information beyond simple “page histories” of previously visited sites. Analytics providers such as Google and Alexa regularly collect statistics of browsing activity, but such analytics are sitecentric and not clustered around individual end-users. Moreover, despite the social nature of web browsing, individuals have little awareness of what others are looking at and how often; while sites like del.icio.us facilitate social exploration, they focus on what people choose to share rather than on their actual habits.

When we created Eyebrowse, we sought to allow users to capture their web browsing activity to examine whether it could help them better understand how they and their friends use the web.  Specifically, Eyebrowse allowed people to examine long term patterns in their web browsing activity and facilitates sharing, comparison, and increased social awareness of browsing patterns among friends. and finally, to form a public, democratized corpus of web browsing data for the research community. So, how much are people willing to share, and how does sharing impact the web browsing experiences and habits of the individual?

After three weeks, we have over 200 users sharing selected portions of their web browsing activity. We surveyed some of them and found that public web browsing was most useful to them for seeing socially derived information in context of their own web browsing activity and for viewing other users profiles for the purposes of social awareness and information discovery. Almost all users reported social- or work-related privacy concerns and their comments indicated a fear of being misrepresented by their web browsing activity. To help cope with this we are considering implementing a ‘greylist’ that would hide specific page titles, but track overall activity and multiple whitelists, such as one for home, and one for work.

We plan to continue to grow Eyebrowse into a service that supports social browsing through collaborative filtering and other crowd-sourcing techniques, promotes self-awareness among users of both the patterns in their browsing activities, and provides researchers with useful web browsing data without violating the users’ privacy sensibilities.

Thanks to all our users and supporters! We were recently featured on infosthetics!

Last April we presented results at CHI 2009 about how people used List-It, our open source Firefox plugin when it was released in September 2008.  Since this initial study, we’ve had quite a few more users – we just hit our 13,000th registered account on September 1st, 2009!  More importantly, more than 600 people have given us permission to analyze their notes for science, which has made it possible to discover interesting trends. Here are some initial findings from purely looking at note statistics:

• Memory triggers (reminders) are important – from a randomly selected subset of the notes we examined, 58% were primarily memory triggers, a general term that refers to notes like to-dos and reminders that serve a primary purpose of calling your attention to something.
• Memory triggers are easy to identify but not to interpret – when people other than a note’s author are shown a memory trigger note, there’s strong agreement (consensus) identifying it as such (k=0.77, N=2500). However, they’re difficult to interpret than other note types because of their brevity and ambiguity. For example, the note “lincoln park” might be a memory trigger, but it is not clear its interpretation: does the author have to go to Lincoln Park, in Chicago? Is it a reference requiring context, such as a name of a book to read? Is it a reminder to listen to the band Linkin Park?
• Shorter notes are deleted more quickly than longer notes – This is likely because short notes often represent memory-triggers which are often discarded after use, whereas longer notes tend to be reference items and items kept for posterity.
• Bookmarking – Notes containing URLs contain little text modifying them – 36% contained only the URL; the median number of words per-note with URL was 2.
• Copy and paste from the web – A significant number of individuals regularly copy and paste entire fragments of web pages, e-mails, and even spreadsheets into their notes for safekeeping.  These kinds of notes account for the majority of notes which are over 200 words long and which are kept for more than a month.
• There seem to be are two types of people – keepers and deleters.  Although the statistics here aren’t extremely significant, the distribution of percentage of notes people delete has peaks at around 30% and above 90%.  This implies that most people delete a small fraction of their notes, while others delete most of their notes.  An initial inspection reveals that this latter category are people who use List-It primarily as a to-do manager (and delete notes when they’re done).
• Searches to personal note collections were very infrequent but repeated – The median number of searches people performed over a one month period of usage was 5, (min: 0: max: 122).  Among the searches, 60.2% constituted repeated searches (searches that had been done at least once before on a separate occasion).  Interestingly and not surprisingly, the most frequently searched term was “todo”.

Based on interviews and surveys with participants, we also arrived with the following conclusions:

• List-It was used to permanently keep track of a number of different kinds of information.  Instead of being merely a temporary resting place, interviewees mentioned that they kept most (if not all) of certain kinds of information permanently in List-It.  The kinds of information that participants most often cited keeping entirely in list-it were: 1) Ideas and brainstorming. 2) Text copied and pasted from the web. 3) Short-term to-do reminders. 4) Things to look up some day.
• Ease of creating and accessing notes in List-It were its most valued attributes. A majority of users rated  “Much easier” (1) to write information down in than other tools they used (on a 7-point scale), and “Somewhat easier” to look things up in than their other tools.

We are currently in the process of preparing a paper describing these results in detail; please stay tuned and we’ll announce when this is available.  But we think that these results immediately suggest ways that we think we can improve how well List-It works for people.  First, since speed and ease of use were important, we plan to work on making List-It more easily accessible directly from places outside the browser, and to let users directly add links to their List-Its by pressing a single hotkey/button.  Second, due to the importance of reminding, we plan to investigate ways to add reminding to List-It such that it will effectively show people notes at appropriate times. More on this later!