Hubbub GR1 - User and Task Analysis

User Analysis

We've observed the following characteristics in our user population:

1. They frequently access their information sources using mobile devices. For example  all of our interviewees mention using either their phones or tablets to read information.
2. They like reading information from sources that often produce high volumes of updates. For example, Twitter and/or Facebook are used by all the people we interviewed, and they all had complaints about the high volumes of updates. Reddit and RSS feeds from Google reader were also examples we found through our interviews.
3. They tend to read their information in a wide range of environments and time limits. Interviewee 3 reads his information everywhere except the shower, and mentions that he likes to use his time reading information as break from work. Interviewee 4 reads her information at home and on the go. Interviewee 2 reads her information at home and at work. We observed through our interviews that our user population tends to fill their pockets of "free time" with reading information. For example, as taking short/long breaks at work or reading information on the go. As an observation separate from our interviews, we also frequently see potential users checking their smart phones during the following events: waiting for/standing in the elevator; before meetings/lectures; while on the train/plane/bus/etc. All of these events characterize a broad range in environment/time constraints for our users.
4. They do a considerable amount of their filtering through information manually (note that this does not imply a considerable portion of their time, though this may be the case for some users as well). For example, interviewees 1 and 4 describe how they don't trust automatic filtering/suggesting, and feel that they are the best judge of what is important information. All interviewees mention having to skim titles/tweets/Facebook updates/etc. to figure out what they want to read in-depth. Though we don't aim to eliminate these issues, we seek to make this filtering process smoother and more automated when possible.

Our user population can be further divided into two classes based on how they deal with information overload; this problem can be defined as one having more information available than one is able to read in a reasonable time-frame (e.g. before the information becomes outdated or invalidated by new information).

1. People who are overwhelmed. When they consume information over the web, they flip through all the sources they are interested in and read what they can, until they run out of time and have to fulfill other obligations. They may miss out on information that might be interesting to them. They realize that this situation is not optimal, but they do not have an easy method of improving it. For example, Interviewee 2 feels guilty when marking all the items she couldn't get to as read each day. She also told us that she would probably enjoy the experience more if she read fewer items in depth, rather than as many as possible.
2. People who attempt action to bring the information influx under control. One method is to "whitelist" sources of information and avoid subscribing to information sources that are less relevant. A user practicing this with blogs might add a subset to an RSS feed, and read only the information from the feed. Another is to consciously evaluate all information sources from a first impression, and skip over datums that are not interesting. For example, interviewee 4 skips over tweets from certain people, and interviewee 3 completely removed his Facebook account.

A related problem to information overload is the need to remember specific data and refer to them in the future. As the feeds a user subscribes to increases, it becomes harder to find a data remembering mechanism that handles all of them. There are two methods of handling this issue:

1. Don't use technology to remember data; instead track it all mentally. We've observed that users tend not to use this technique in favor of technology like online calendars and email todos. We learned in class that users have to put in considerable effort to get items into their long-term memory, making this technique difficult for users.
2. Use existing technological solutions. However, existing solutions are not complete. Some users may bookmark web pages, but bookmarked information does not propagate across devices, and can easily become disorganized. In addition, some information feeds are not amenable to bookmarking (i.e. Facebook feeds). We observed in our interviews that some users utilize email as a TODO list, but this requires manual filtering to separate "todos" from the rest of the inbox. In addition, the interviewee admitted that her email "todo" list technique is inefficient.

Task Analysis

We consider 6 high-level tasks related to our problem, 3 essential and 3 non-essential. We list the three non-essential tasks as a reminder that they still need to be implemented, even if they are not significant for GR1.

Essential Tasks

Reading

This task focuses on how the user traverses their content, and how they read it.

• Why is the task being done? The user wants to know what’s going on in their world.
• What does the user need to know or have before doing the task? That what they’re about to read is likely to be interesting/useful
• Where is the task performed? in a smart phone’s web browser, potentially on the go
• What is the environment like? Noisy, dirty, dangerous? potentially
• How often is the task performed? Within a session, repeatedly and rapidly, and they may have several sessions per day
• What are its time resource constraints? As fast as possible (as quickly as a few seconds), but perhaps lasting several minutes for longer content
• How is the task learned? Primarily by recognition. Most users are familiar with reading material over the Web, and this experience should carry over.
• What can go wrong? accidentally lose the item they just read and having to find it again
• Who else is involved in the task? no one

Filtering

Users will often be interested in only a subset of information (written by a specific person or persons, or covering a certain topic), and thus want to run a filter over their content to identify this subset.

• Why is the task being done? The user wants to restrict the given information to that subset.
• What does the user need to know or have before doing the task? They need to be logged in, and know enough about the subset to describe it or pick a filter.
• Where is the task performed? Either on a desktop/laptop, or on a phone browser.
• What is the environment like? Noisy, dirty, dangerous? It could be, if the user is on the go with their smartphone or tablet.
• How often is the task performed? This depends on the user’s profile; some may do it all the time, others only once or twice per session.
• What are its time resource constraints? The feedback loop should ideally be very fast, comparable with Google Instant Search, so that refining the filter is easy.
• How is the task learned? The user can learn it by recognition; we plan to design the interface so its controls are very similar to Google Instant Search or other similar mechanisms.
• What can go wrong? The filter could be incorrect (too broad or narrow), or it could have a typo. A fast feedback loop will improve safety by ameliorating these issues.
• Who else is involved in the task? No one else in this case.’
• What subtasks are there? Navigating to the textbox (or other form element used for filtering, entering the author name or topic to keep (or reusing an old filter), scanning the subset displayed, and revising the input if needed. Optionally, users could save the filter for future usage.

Saving News Items

Users need to be able to organize the content (such as with tags or a directory structure), and control the lifetime of the content (marking items as read, marking as “read later,” etc). This also includes saving the information they find important as they read through updates in their news feeds. It should be noted that the term "save" may end up being misleading. The user's intent is to make it possible to revisit the item in question in the future. Saving it somewhere is one way of doing it, and how files are managed on the desktop. The exact implementation of this feature may be a less conventional model, such as tagging like what users can do with emails in Gmail to make them easily accessible later. Prototyping and testing will shed more light on which approach will be easiest for users to learn.

• Why is the task being done? The user would like to make an item accessible for reading in the future, or categorize items based on certain properties.
• What does the user need to know or have before doing the task? They need to be logged in, and know which item they want to save or tag.
• Where is the task performed? Either on a desktop/laptop, or on a phone browser.
• What is the environment like? Noisy, dirty, dangerous? It could be, if the user is on the go with their smartphone or tablet.
• How often is the task performed? This depends on the user’s profile; some may do it all the time, others only once or twice per session. It depends on how willing they are to categorize information. Some people use similar features (like bookmarks or the "Read it later" feature of browser addons like Readability or Instapaper) commonly, others not at all; and this mentality will carry over.
• What are its time/resource constraints? It should be fast, no more than a few seconds. The user does not have time to read the article in question now, so it is possible they may also not have a lot of time to save it. Even if they have time, they will want to get back to articles they are interested in as soon as they can; reading is more fun than organizing.
• How is the task learned? The user can learn it by recognition; the interface should be familiar (like existing methods of archiving information, like folders in operating systems, or tags in Gmail)
• What can go wrong? The user could save the wrong item by accident (in which case they could delete it later). The user could forget to save something they want to save (and they could recover by using the filtering feature to find it again).
• Who else is involved in the task? No one else in this case.
• What subtasks are there? Selecting the item to save, categorizing it into an appropriate area, and finding it to read again later.

Non-Essential Tasks

We simply list these tasks, since they are not essential to the problem our application is trying to solve.

• Configuring the display
• Identity creation/authentication
• Initial setup/management of information sources

Interviews

Interview 1

• Twitter** Follows 600+ accounts** Keep general tabs on various groups of people/areas of interest* Phone interface is most natural** In the morning, scroll back as far as the client will go to catch up** Wouldn't want tweets going to e-mail because it's harder to Mark All as Read (don't want to miss out) than to be limited by Twitter's scroll-back history* Receives tweets from important people as text messages** Favorites tweets she wants to revisit** Occasionally would want a tweet via e-mail

•  
• Google Reader** Doesn't want to think about how many unread items she has** Wants to split the feeds into Good and Meh (my words) so that she can regularly read the good without feeling bad about ignoring the meh
• E-mail** Uses e-mail as a TODO list (regretfully)** Would see tweets and RSS items as TODOs and doesn't want that* Sometimes, when she's expecting a stressful e-mail, she doesn't want to open her e-mail client at all
• Has never used an automatic filterer that worked well. She's the best judge of what she would find interesting and feels the investment is worth it.

Interview 2

Interviewee 2 is a graduate student. She reads information from a lot of sources, mainly Twitter, Facebook and 93 different RSS feeds via Google Reader (though many of these are comics and other things that aren’t quite news). She does most of her reading at home and at work, on her laptop and on her Kindle Fire.

She tries to get through all of the updates from her information sources, but almost never does. Whatever she doesn’t get through she marks as read to make room for more. However, she feels a twinge of guilt when she leaves items unread, and will read through things more quickly and with less care just to get through more information. Sometimes she feels she would enjoy it more if she took more time to read them thoroughly.

She has over 1000 friends on Facebook and has written over 10000 tweets, but still goes through all of the tweets/status updates in her feeds. Twitter is easier for her to keep up with because the tweets are short. However, between the two she only follows up on items she’s really interested in. Because she knows everyone she is friends with on Facebook, she does not unfriend people. However, she will stop following accounts on Twitter if they post high volumes of tweets with links she tends not to click through or people she finds uninteresting. She makes it a point to not unfriend or unfollow anyone she knows personally.

This year, she is giving up Twitter and Facebook for Lent.

Lessons Learned

1. Some users feel compelled to consume all of their information, and are disappointed when they are unable to achieve this goal.
2. There are users that have the problems we describe in our problem statement and would benefit greatly from our application, but do not use their phones to read information online (a group we primarily want to target)
3. Users have a wide range of reasons for wanting to permanently/temporarily hide/remove some of their information sources, so we should probably make this feature easy/fast to do and undo##  We may even want to let users dictate when to start/stop feeds through dates and times (like for Lent)

Interview 3

Interviewee 3 is a graduate student. He reads news from a wide range of sources, including email, reddit, hackernews, New York Times, TIME and various blogs. He surfs reddit and hackernews via their websites, accesses his email through gmail and reads his feeds via Google Reader. He consumes this information “everywhere except while showering,” which includes the office, home, cafes and while on the T. He spends half of this time on his laptop/desktop, and half on his phone.

He does not like using Twitter or Facebook. He even closed his Facebook account because he was annoyed with having to “see all this junk information” when trying to use it to connect with friends.

Despite the high volume of information he receives on a regular basis, Interviewee 2 is not frustrated by his inability to consume it all. In fact, he prefers it because it ensures he always has something to do when he’s bored. He lets some of his resources do the work of finding what’s interesting, such as sticking to the front page of reddit (which has a large number of “interesting” things due to users voting these items up). Otherwise, he quickly skims headlines and ignores what he thinks is not important.

Update: Interviewee 3 would like the ability to "star" items, similar to Gmail, and in general wants to be able to mark things he finds important for quick/easy access later. However, it does not matter to him whether items are stored physically in a separate location or not. He spends 30-60 minutes reading/managing information sources, and most of this time is spent reading information (not managing it). He quickly skims items and only reads in-depth what he finds interesting, which keeps the time required to look for interesting information down. He feels that there is a clear trend in the articles he reads, but he doesn't trust a system enough to recommend new sources to him. He feels that he alone is his own best judge of interesting information, and thus relies on this to find things to read.

Lessons Learned

1. Users want to be able to identify the most useful information as soon as possible (hence why Interviewee 2 does not like Facebook or Twitter, and utilizes the front page of reddit)
2. Not all users feel overwhelmed by their high-volume information streams, so our application should reflect this
3. Though users may have too much to read, they don’t want to have too little##  We should allow users to adjust this quickly and on the fly## example: when a user checks in with our application to consume some information, she runs out of things to read. So she adjusts her preferences to increase the amount of information she sees and our application immediately adds previously unseen items to her visible updates.
4. Our application would be most beneficial if users could access it on their computers and on the phone## We discussed this and for the scope of the class we will focus primarily on use via phone (but will more than likely have to make sure users can access it comfortably via computer)

Interview 4

Interviewee 4 is a freelance journalist who regularly networks over the Web on sites like Facebook and Twitter to make her name more well-known. She stays connected to Web-based networks at home with her laptop, and on the go with her Android tablet. Her activity on Facebook is fairly typical, and she does not use Google+ regularly because most of her friends do not, but her usage of Twitter reflects a need which this project will try to fulfill.

There are two major reasons why she follows people on Twitter.  The first is out of professional courtesy; a common practice in her profession is to follow colleagues and retweet their articles when they are posted. The implicit contract is that they will retweet your articles in return, improving the visibility of both parties. The second reason is out of genuine interest in their tweets.

She complained that the people from the first group often make tweets that she is not interested in, and they clutter up her feed making it harder to find posts of interest. Currently, she manually scans through the tweets, passing over the ones she does not want to read. She expressed interest in a tool that would filter out these posts leaving only posts from people she is interested in, and posts about articles that should be retweeted (possibly by scanning through posts from people in the first group, and removing any that do not link to articles). She commented that Tweetdeck used to provide this capability, but when Twitter bought Tweetdeck they either removed the feature or hid it somewhere.

Lessons Learned

1. Social websites currently excel at showing people information from a given person.
2. They can also be used to spread information virally, by asking friends to repost something.
3.  However, users can't easily apply granular, automatic filters (e. g. You can block all posts from one person, but blocking only some is harder). Twitter, Facebook, and Google may not want to implement a feature like this; it would shorten the time users spend on their sites exposed to advertisements.