Showing posts with label LongTail. Show all posts
Showing posts with label LongTail. Show all posts

Wednesday, May 23, 2007

The Conversation Gets Interesting: Creating the Adaptive Interface / Stephen Anderson

Saturday, March 24, 2007

The beginning of the abstract for this presentation provides an excellent intro:

"With the proliferation of rich Internet applications and interactions more closely aligned with how people think, we face some interesting challenges:

  • Do we design for one common audience and common tasks, or tailor applications around specific audiences and their unique activities?
  • How do we resolve the tension between creating simple applications that ‘do less’ and the demand for new features that some people really do need?
  • As we move beyond usability to create desirable interfaces, how do we handle a subjective domain like emotions?

"These types of challenges could all be addressed by creating a truly ‘adaptive' interface."

Examples of ways that applications could be/are being tailored for niche audiences (i.e. "the long tail."):

  • Expanding text box to accommodate use
  • Using IP address to guess at correct location of user
  • If the person attaches multiple files, give him the number of fields he typically needs
  • Assume info based on meeting types—lunch meeting pulls preferred lunch spaces.
  • Look for iterative actions and reveal features over time to tailor to need
  • Increase the button size if this user consistently misses it
  • Color and saturation to indicate age and importance of content—old data fades in color (see: ShaunInman.com)
  • Prominence of a help link minimizes over time if you never use
  • To fit smaller/different display sizes, changing layout (liquid versus fixed) and content (disappears to fit in new spacebased on display)
  • For mapping application, collapse neighborhood driving instructions based on history.
  • Changing [help] text based on audience? (travel agents versus travelers)
  • Text changes based on regional differences (Coke, pop, soda)—just like we’d do in a conversation
  • Removing L-shaped global navigation when applications are displayed
  • Changing help based on what you know about the person (novice user gets instructions for simpler tasks like drag and drop)

Challenges:

  • These kinds of options/features are currently being done primarily with cookies. Could also use rich profiles.
  • OpenID may provide more options when small bits of info about a user can be put together to paint a bigger picture (which, of course, if also a danger).
  • Requires a clean separation of content and the application.
  • First, get the basics right (metaphor of using rough grit sandpaper first; fine detail later)
  • Disclose what you are doing.
  • Provide opt-outs (i.e. "Please logout if you are not [Fred]."
  • Be wary of changing spatial organization (users will look for the same content in same spot)
  • Ease into this kind of info
  • Could use Web 2.0 model of testing live on users

Links for more info:

Tuesday, May 15, 2007

The Brave New World: Usability Challenges of Web 2.0 / Jared Spool

Saturday, March 24, 2007

Jared Spool, of User Interface Engineering, reported on research in progress. His company’s mission is to long term, improve quality of lives by elminiating frustrations of technology.

Describes Web 2.0 as…

  • designing with total user experience
  • combining users and content
  • moves beyond traditional interface
  • development/design teams shrinking (because teams are able to do more with less staff by adding onto the work of others)

A recent 37Signals survey asked users what Web 2.0 meant to them. The answer: AJAX, interactive, Rails.

Design tends to focus on three stages, or mutations:

  • Talking horse stage, where people are building stuff with a technology focus.
  • Adding features stage. Ex: Amazon adding features like blogging.
  • Designing for experience stage; Web 2.0. Described as a backlash against too many features. Ex: Craigslist, where individual user experience trumps classic views of design

Components of Web 2.0
1. APIs
2. rss feeds
3. folksonomies/tagging
4. social networks

Web 2.0 is not user-created content. That has always been there. Web 2.0 is leveraging that user-created content.

Ex: Flickr

  • Incidentally, flickr is #5 in popularity for photo sharing. Photobucket is top.
  • Flickr uses a personalized homepage. Most users never see the generic, non-user home page after signing up.
  • Flickr has a programming interface to create stuff (i.e. APIs)
  • The Geotagging and printing tools were adopted after someone else (non-Flickr employee) did the development using the APIs.

1. APIs have their challenges. They make everyone a designer.
They can also create seamless experience with code from multiple sources.

Overheard in New York

  • Example of mashup between Twitter and Google maps
  • Took Twitter streams and mapped it with Google maps
  • The result is randome overheard conversations from the streets of New York. Here's an example from today (4/26/07):

Old lady: This is a full sandwich. I said half sandwich.
Waiter: What's the big deal? I won't charge you for the whole thing -- just eat half.
Old lady: No, no, you don't understand -- I am claustrophobic.

Yahoo pipes

  • Yahoo providing the tools to create mashups with RSS feeds.
  • Then, users offer those mashups to the public.
  • Ex: UST Campus/Library/Community Flickr Associations, which finds Flickr images based on a University of St. Thomas news source, the same university's news blog, and a local news blog.

2. RSS feeds
Challenges include

  • explaining them to users. When do things come and go? Is it refreshing for corrections? How do users subscribe?
  • How do users deal with the number of feeds they track? (Google reader caps at 100 posts before it starts deleting)

3. Folksonomies
Challenges include

  • How tagging is being used. For instance, are tags for “me” and “hi_you_what’s_up?" useful to anyone else?
  • Difficulty in figuring out logic behind someone else’s tag
  • Are you tagging for yourself or for others?
  • Do we monitor? Who? How?

4. Social networking
Ex: Netflix

  • Ratings from friends are separate from everyone else
  • Compare your ratings with your friends
  • Games based on ratings

Challenges arise when more than one person is involved:

  • How do we prevent systems from being “gamed” (scoring/ranking people)
  • How do we encourage behavior; allowing for good behavior to propagate; not anti-social behavior

Challenge of the "long tail" of the Zipf curve

  • only a handful of CDs become really popular;
  • some that become sort of;
  • many that only a few folks like
  • get more sales from those unique—long tail—titles (only sell a couple of copies but there are many of them)
  • 98% of the Microsoft.com users are using 2% of the content; what do you do for the rest of the content?

New IA Challenges with Web 2.0

  • Most of IA has been dealing with known authors and static content.
  • New problem: dynamic content (same known authors)
  • Even newer problem: dynamic content; unknown authors

    Ex: LinkedIn.com
  • tracks contacts
  • can input resume content and output new resume but users don't tend ot put content in correctly.

Possible Application for L&ET:

  • What applications in L&ET would lend themselves to APIs?

Sunday, April 15, 2007

Using Search Analytics to Diagnose What’s Ailing Your IA / Rich Wiggins and Louis Rosenfeld

Saturday, March 24, 2007

Wiggins’ emphasis was best bets within search results. Rosenfeld spoke more generally about identifying problems from search logs.

Practicalities:

  • Zipf curve (long tail/short head) applies to search log—many users have unique needs
  • Look at top searches, and then dip down into the unique ones. Don’t treat all the searches as equal. Could look at top 50% of all searches, for instance.
  • Consider seasonality (by season, day, even hour). Some needs are higher by season. Could promote that content accordingly.
  • Capture search logs to SQL database to then process. Can dump relevant fields into Excel and then evaluate.
  • Use IP with time stamp to surmise single user.

Ways to Use Search Logs:

  • Look at most common unique queries; are there patterns?
  • Test common queries to see what results look like.
  • Look for null results.
  • Look for too large results.
  • Can grow content to satisfy searches (ex: Netflix did this in response to “yoga” searches)
  • Look at improving search entry, results, and/or algorithm
  • Combine with field study (ex: L.L.Bean saw users starting with catalog, then taking SKU to web—answered why users were searching for SKU)
  • Fixing a trend seen in long tail could help many.
  • Look for time variations; respond by positioning Best Bets or guides seasonally.
  • Add tools for results page (i.e. options for broadening/narrowing)—this moves advanced search options from search page to results page
  • Best bets as not the final answer; still should monkey with relevance ranking. (ex: rank company names higher if that’s what users search)
  • Consider a best bets index rather than/in addition to a site index. See MSU A-Z index as example of using common queries as a best bets index. Site index uis difficult to build. Do you make it comprehensive? Selective?
  • Look for the page the user is searching from to identify failure points.
  • Look at top pages found through search; how can these be easier to find in navigation?
  • When cleaning up site, start with what people want—rather than complete evaluation of content.
  • Look at “tone” in search (technical or popular; specificity; acronyms; plural) to help create labels.
  • Cluster queries to see parent/childs; look for possible metadata fields and contents for those.
  • Sample the long tail (tends to be more research oriented)
  • Compare spikes (proper names, companies) and compare with editorial content; identify future stories. (ex: Financial Times has done this)
Links for More Info: