A MTurk Exploration of Activity Stream Usage
These are some slides from a presentation I gave on some Mechanical Turk data I collected about how people are using Activity Streams (also called News Feeds). Specifically, I was interested in what tools people were using, what they were using them for, how these tools might be improved, and how people had been using these tools to collaborate/coordinate. Here’s what I found:
The data collected and the major points were fairly straightforward:
Participant Demographics:
- Age: Mean = 25.6, SD = 8.0
- Education: Almost all were mid-college or post-college (and about 1/6 post-graduate study).
- Usage: Most (56/78) reported specifically personal usage, and only 2 subjects reported specifically professional usage (14 indicated both, however).
Tools Used:
- Vast majority listed Facebook (61/78) - this was unsurprising (also, Facebook Stream listed as first example of an “activity stream” in survey instructions.)
- Wide Twitter usage (41/78) was surprising, however. Past experiencing with polling for Twitter-related topics on MTurk had resulted in low yield. Perhaps this is due to the crazy upswing in Twitter sign-ups over the past few months?
- Other than MySpace (16/78), tools such as LinkedIn, Yammer, FriendFeed, and others were barely listed, indicating either that these tools are not widely used or that people do not consider some of these to be activity streams.
Functions Served:
- Note: These responses were loosely categorized by me - this was not intended to be a rigorous academic study, but rather a glimpse into usage of these tools.
- Status(33/78), Communication(32/78), and Information(19/78) were listed as the most common functions served.
- Responses also demonstrated a wide variety of usage, however, including some less anticipated uses such as Journaling. Perhaps this speaks somewhat to the flexibility of these tools and the ability that users have to adapt them to their own needs.
Feature Requests / Improvements:
- These are exact quotes from participants (again, loosely grouped into categories by me - no cross-coding was done).
As you can see, the “Summary” was really just a reminder about what people said regarding potential improvements, but I thought this was really the most interesting part. It’s interesting that most of the things that people asked for were things that are either available or which could be easily made available by new activity stream client applications, so there may be a lot of low-hanging fruit out there for application developers.
I’d be curious to see if any of you has done (or seen) similar research regarding Twitter, Facebook, or other activity streams (whether on MTurk or otherwise) and if you found similar or different trends. If you are interested in clarification, more details, or discussion about any of the points brought up here, the comments section awaits.
June 15, 2009
Tags: activity streams, facebook, friendfeed, mechanical turk, mturk, news feeds, presentation, research, twitter Posted in: /Matter 
Comments
Retweets and Microsyntax
First, for reference, here is some background information on ‘Microsyntax’:
A week or so ago, Stowe Boyd (@stoweboyd) posted a message on his blog entitled “Microsyntax: A Messifesto“, in which he outlines his plans for a structured survey of ‘microsyntax’ for Twitter, which he defines as “various ways to embed structured information right into the text of Twitter messages.” Some obvious examples of these are ‘@’ for replying to people, or ‘#’ for inserting keywords, which, while invented by Twitter users (see Chris Messina’s (@chrismessina) original/updated post on using hashtags from back in August, ‘07), have become so commonplace that they are now an indispensable part of the Twitter grammar. A newer example includes Stowe Boyd’s own suggested “geoslash“, or the use of “/” to indicate location information in posts.
Stowe has formalized this endeavor by forming the non-profit group Microsyntax.org, and Chris has actually joined him as a member of his advisory board (which he mentions in his blog post outlining the project). Together, they have started a wiki to aggregate proposals, suggestions, theory, and examples from the wild, and I think that this is a great forum for observing and driving new conventions to help make Twitter even more useful.
Now, some of my own thoughts:
Back in December of 2008, I had a discussion with Mike Krieger (@mikeyk) where I started thinking about possible ways to revise the way that we retweet. The rest of this post is the result of some more recent thinking on the subject inspired by Chris and Stowe’s efforts:
Basically, the problem with the current ‘RT’ syntax is this: the only information currently carried by “RT @username” is that the person “username” was somehow involved in helping some information making its way to you. First, because things may be RT’d multiple times, you end up having to either string together multiple “RT”s (and likely run out of space) or start dropping some. If you start dropping names (not in the social climber sense), do you drop the name of the person who sent it to you and deny credit to a close social connection or instead do you drop the name of the writer and deny credit to the original producer? Neither option right now is very palatable. The second major issue is that since the RT doesn’t carry any information about the message itself, you are forced to quote the entire message, which just seems impractical in a 140-character medium. Removing parts of the quote, then, to save space is actually somewhat misleading, since the quoted information is supposed to represent an original thought from another person.
In summary, RT currently = “no information about the message and limited information about the messenger.” This is unsatisfying.
To me, given the fact that tweets are logged somewhere for eternity, there should be no reason why we can’t simply find a compact way to link to these original tweets. Below is my original proposal for doing this, which simply entails appending “R#” to the unique update number of the original tweet:
Thanks to Chris for pointing out that I could use Twistory to retrieve this!
I am not a developer, so the specifics were best left to someone other than me, but I imagined that the trick behind making it easy for people to write these would be providing simple ways for Twitter clients to grab these status numbers and insert them into the tweet automatically, perhaps in a similar fashion to how the Twitter Web client now auto-trims links or how the client Tweetdeck auto-Twitpic’s uploaded photos. Mike actually wrote (extremely quickly and skillfully, I might add) a Greasemonkey script that plugged a similar functionality in the Twitter homepage, adding a “Retweet This” button which inserted a tag of the form “#twitter:status=tweet_id” into the status update box (the syntax refined by a suggestion from Chris). While this syntax may be clunky and perhaps not as human-readable as Stowe or Chris might be imagining for Microsyntax elements, it’s not really that much more clunky than staring at a twitpic URL, for instance, which Twitter clients now handle expertly. Ideally, if this syntax took off, it could be integrated directly into clients such as Tweetie or Tweedeck, perhaps in a way that is similar to the way that Tweetdeck handles Twitpics, such that humans never have to worry about interpreting it.
No time to make a mock-up of status screens embedded directly in Tweetdeck, so this twitpic of this sad baby will have to suffice.
In terms of solving the problem mentioned above (that of giving credit to all nodes along the path of a RT), this would provide a unique chain of updates which could somehow be logged in the future:
Original Writer: “Check out this amazing lolcat - http://…”
Retweeter 1: “R#1201420384 Hah, that’s amazing.” (now a program can trace back to the writer)
Retweeter 2: “R#1204235345 Wow, this is going to spread like wildfire!” (the R# links to the re-tweeted message, and through that, we can trace all the way back to the writer)
However, the actual implementation happens, such a reformation of RT would be a boon for a few reasons. First of all, it would ensure that everyone in a conversation was credited, from the original writer to the most recent node who provided you the information. I use the word ‘conversation’ now instead of ‘retweet’, since this syntax could extend beyond retweets to any sort of interaction on Twitter. Twitter is a conversational medium, and this could be used for any sort of interaction where one wants to refer to a specific tweet. If I post a question to my followers, for instance, they could use this syntax to reply, thus helping people (or a Twitter client) easily trace back to the original question.
Second, as a researcher, this would be incredible. Using these traces, we could trace an entire network of interaction and information spread on Twitter in a way that is currently not possible. Researchers who currently look at retweets (such as Dan Zarella) can currently only do very shallow analyses such as searches on “RT” since there is no infrastructure to support this behavior. A structured syntax for RT’s could provide a rich glimpse into the dynamics of information spread on Twitter.
Anyways, this is really just a first attempt at outlining the problem, and I hope that this post can generate some discussion which may lead to a solution. Comments, suggestions, and refinements are obviously all welcomed and appreciated.
P.S. If any of you are kind enough to retweet this post, please take the opportunity to think about how limiting the current syntax is while doing so!
June 5, 2009
Tags: activity streams, Chris Messina, Dan Zarella, microblogging, microsyntax, Mike Krieger, retweet, Stowe Boyd, Tweetdeck, twitter Posted in: /Matter Comments
A New Paradigm for Artificial Intelligence
This was the rather bold title of a PARC Forum talk that I attended yesterday.
The talk was given by Dr. Paul A. Rhodes, the CEO of a company called Evolved Machines, which is focused on studying neural circuitry and finding ways to synthesize it artificially. This, in essence, is the “new paradigm” mentioned in the title of the talk: the old paradigm being the basis of artificial intelligence on symbolic logic.
Artificial Intelligence, at least in the way that it is defined on Wikipedia, is “founded on the claim that a central property of human beings, intelligence—the sapience of Homo Sapiens—can be so precisely described that it can be simulated by a machine.” The point of the talk was that the current method of modeling AI systems on symbolic logic does not really simulate the mechanisms that underlie our intelligence - our neural circuitry doesn’t carry out operations in discrete, logical steps, but rather in a probabilistic, chaotic manner.
For this reason, AI researchers have been able to solve certain types of problems extremely well: where the states and set of states are clearly defined (such as playing chess). However, other types of problems, such as visual recognition of objects in different contexts, remain very difficult. I would tend to think of the second problem, something that almost human does automatically and without thought, to be much more at the heart of being human than playing chess.
And this is exactly what Dr. Rhodes and Evolved Machines are hoping to accomplish - he showed some great visualizations (which I wish I could have captured for you) of models they have built using simulated neuronal interactions, including one that showed how the neurons which receive signals from retinal nerves might re-wire themselves in response to visual input in order to better, and more quickly, recognize objects.
This is an example of the new paradigm as he described it - artificial neural circuits built of simulated neural components and characteristics, such as:
- Electrically active trees which homeostatically self-regulate
- Dynamic (probabilistic) synapses
- Self-organization of wiring in response to sensory input
To me, it is amazing that computing power has grown to the point where we can start programming computers to model systems that don’t work like computers. As neuroscience, computer science, and other disciplines continue to collaborate in ways such as these, I am encouraged by the prospect that we will soon see true aspects of human intelligence being synthesized.
April 24, 2009
Tags: AI, artificial intelligence, Evolved Machines Posted in: /Meaning, /Mind Comments
Chronological and Kairological Time
So, I’m in the middle of reading John Thackara’s In the Bubble: Designing in a Complex World, and just finished a pretty interesting section on how our perception of the passage of time changed with the invention of the clock. Specifically
Mechanical timepieces have always been used not only to mark the passage of time, but also to dictate the scheduling of activities; they regulate the speed of action and therefore the pace of society. “Contemporary ideas about promptness would have been incomprehensible to the vast majority of our predecssors,” concludes Robert Levine in his book A Geography of Time.
The Greeks, Levine explains, had two words for time: chronos and kairos. Chronos means absolute time: linear, chronological, and quantifiable. Kairos, however, means qualitative time - the time of opportunity, chance and mischance. If you go to bed because the clock says 10:30, you are adhering to a chronological time system. If you go to sleep because you’re tired, you are following kairological or event time. Before they shifted to a more clock-based way of doing things, people listened to their bodies to tell them when to do things. Babies, so much in touch with their internal needs, are perfect examples of humans turned to kairological time. The clash between personal time flow (getting food, going home) and the public time flow (standing in a queue) is experienced as disturbing.
Our concept of time as dictated by the clock is so ingrained in us that it seems almost impossible to imagine what life would have been like before rush hour, minute rice, and never having a second to think. In fact, in some ways, our concept of time is shaped by our conflict with it (how often do you think about the time when you are enjoying yourself or have nothing to do?). Furthermore, it is almost frightening to think that the pace of life will only continue to accelerate.
Anyways, to lighten things up, here’s another astute set of observations about our changing perceptions of time from the comedian Louis C.K.’s appearance on Conan:
April 21, 2009
Tags: time Posted in: /Meaning Comments
Social Search Researchers on Twitter
A few days ago, I started passing around a sign-up form to help people interested in topics relating to Social Search find each other on Twitter. The great thing about having millions of people on Twitter now is that you are virtually guaranteed to have other people tweeting about the things that interest you, and this was such a great and easy way to find new interesting followers and build a community around a common interest.
I purposely kept the subject “Social Search” vague, because I hoped to cast a wider net and then decide who to follow more specifically later. It’s turned out that I’ve already learned a ton of interesting stuff from the people here, so if you are interested in Social Search topics at all, I’d recommend that you join the list and give everyone else a follow!
I had trouble embedding the spreadsheet in the post, so click these links for the sign-up form and results list. Enjoy!
P.S. The list is obviously public as it was passed around on Twitter, but if anybody has any questions or concerns about my posting the list here, please let me know!
February 13, 2009
Tags: social search, twitter Posted in: /Matter Comments
Smartsheet Automating Data Collection Through Mechanical Turk
Smartsheet has just launched their “Smartsourcing” product which allows you to automatically build data-collection tasks in a “Smartsheet” (a spreadsheet) and outsource them as HIT’s on Mechanical Turk. I just watched the demo video over at Smartsheet, and I have to say that the integration looks pretty slick.
The ability to outsource data collection and have it populate a formatted spreadsheet in near real-time is fairly impressive (speed will probably differ on attractiveness of the task). Often, the steps required to set up a MTurk task can take as long as the data collection itself, and afterwards you are left exporting to an unformatted Excel sheet. Making sure to name data-labels correctly, populating data fields to randomize among workers, and other tasks can further complicate things; judging from the demo video, Smartsheet seems to handle these parts of the process fairly easily.
Unfortunately, good service doesn’t come free, and using the Smartsourcing feature requires signing up for a paid-account as well as the Smartsourcing fee on top of that, so I didn’t get the chance to try it out, but I would be extremely curious to hear about anyone’s experience with the service if they do try it.
February 12, 2009
Tags: data collection, mechanical turk, mturk, smartsheet, smartsourcing Posted in: /Matter Comments
I Know Where You Were Last Summer
As I eagerly wait for Google’s Latitude to drop on to the iPhone app store, I’ve had the opportunity to try out the web interface in the form of the Latitude iGoogle gadget. Immediately, I was struck by how similar the web interface was to that of the current mobile location network darling, Loopt.
Loopt:
Loopt: Friend Map
Latitude:
Google Latitude: Friend Map
Of course, it is difficult to completely ignore the extra features that Loopt offers or Latitude’s clean look, and many other blog posts discussing these aspects have gone into a lot of detail comparing the two. However, I think that these types of comparisons ignore the fact that these two services are fundamentally the same and suffer from the same fundamental flaw, what I think of as the Catch-22 of Map-Centric Social Networks:
- Nobody is going to visit the service regularly unless they are getting useful, reliable information.
- Nobody is going to get useful, reliable information unless everyone is visiting the service regularly.
Loopt or Latitude or any other service can roll out as many features as they want (Journal, Mix, etc.), but the core service that these applications offer won’t become even remotely useful until I stop seeing days or weeks-old status and location updates. Given that most of my Loopt contacts are iPhone users, it’s possible that this may change if Apple actually does roll out an update in June that allows apps to run in the background, but then that raises all sorts of other questions about the perceived “creepiness” of a service tracking your whereabouts 24/7 (I write this, of course, after having just suffered through “Eagle Eye“), and it will only be the most intrepid of early adopters who will click OK when the “Loopt would like to use your current location…forever” option pops up.
At some point in the future, I really do believe that we will all be comfortable with having all our locations/preferences/activities tracked, as we start to understand the benefits that can be reaped in terms of computers being able to anticipate our actions and serve us better. In my mind, the only core difference between Loopt and Latitude as they stand now is that Google will be able to fund Latitude for several years until that time comes around, while Loopt will likely have perished much sooner. In the meantime, an interesting problem is looking at how we can design location-based services that maximize the utility of these services to the point that users actually feel compelled to update because they will gain access to useful, reliable information about their friends while minimizing any “ick” factor.
The first step, I think, will be to give up on the map as the hub of these services. This is an idea that I have explored a little bit, and some applications have already hit the iPhone app store that take this approach to networking (Borange comes to mind). I haven’t yet heard any feedback on Borange or any such services, so if you have, it would be great to have you share it here.
February 9, 2009
Tags: /Mobile, latitude, LBS, location-based, loopt Posted in: /Mobile Comments