Indolering.com

Learning Ubiq P2: Support Structures

Posted on 26. Jul, 2009 by indolering in Ubiquity

As outlined in Part 1, the traditional style of documentation is antithetical to actual usage.  Style is a major problem, but the delivery mechanisms are just as bad.

At best, a manual can be oriented to predefined tasks and known problems, at worst it is a dense technical read with a broad overview intertwined with nitty-gritty details.  Neither approach considers how people actually work with documentation.  Firstly users never consult a manual unless they encounter a problem they cannot solve on their own.  And even if they do consult some form of help reference,

“[Users] encounter a usability problem on average about once every 75 minutes and typically spend about a minute looking for a solution” -When and How People Seek Help with Computer Applications

I call this the 1st rule  of triage support, a problem or question must be resolved within 60 seconds or it won’t be resolved unless the problem is really bad.  This law explains why Twitter and Get Satisfaction are so successful- users find the most up-to-date answer upfront instead of  guessing which chapter is most likely to contain the desired solution or digging through a forum posts.

Documentation and Help resources need to be thought of in holistic terms, as a part of the user experience spectrum instead of a disparate collection of tools.  To push us closer to that less abstracted understanding we can change the definition to user support. Abandoning the terminology of help and documentation and thinking in terms of user experience and support includes more than just manuals and forums.  This changes the strategic importance of different items, magnifying some things and reducing others.

Don’t think of Documentation

As best psychologists can tell, humans recognize and categorize things in two ways, as described by instance theory and abstraction theory.  Instance theory is that we store a central prototype for a category, with all sub-items being variations upon that prototype- an instance of it.¹  I believe we generally think of documentation via the instance method method because documentation also has a literal meaning of recording details and specifications, as in “The case was very well documented” and due to way developers implement documentation resources.

Documentation’s central prototype is a manual, of which there are many variations; wikis, FAQ, knowledge bases, etc.  Thinking in this manner will bring up related help prototypes (through spreading activation) such as a mailing list and it’s variations, such as a forum.  Such thinking prevents us from improving upon the satus-quo, it starts our thought process at a solution and walks backwards into the problem.

Abstraction theory holds that we string together different categories via shared characteristics. What do manuals, wiki’s, FAQ, knowledge bases, mailing lists, forums, GetSatisfaction, IRC, and web-chat all have in common?  What is “documentation” in the context of the user experience?

All of these things are just forms of user support.  I want to talk and think about user support as a collection of actions, products, and features compensating for when the user interface falls short of perfection.  This starts thinking at the problem and designs solutions for it.  Solutions which I call support structures.

I think that this seemingly small tweak in definition leads to big changes in our reasoning- and the effectiveness of support structures saving users from the alpha nature of Ubiquity.

Support Structures

The knowledge base/wiki

If a user fails to find relevant results on their first search, 50% will not search again²

Yet most online documentation only offers links or a search box at the end of the page.  Sadly, the user is more likely to work around the problem or drop use of a feature -like Taskfox,

For these work-around episodes, the mean task time was 20 minutes and the median task time was 10 minutes. We estimate that use of available functions, had the participants known of them, would have reduced task times by 75 percent. -When and How People Seek Help with Computer Applications

So why not try to engage the user by offering a GSFN submission or chat support at the bottom of every page?

Click to enlarge

The Herd

The herd delivers information about a command, will show up high in google searches for the command, and will get a lot more traffic than any knowledge base we erect.  So why not make examples editable and sync them with the knowledge base?

Click to enlarge

This is extremely evolutionary, re-purposing material in pre-existing support structures.  It’s not a technological leap but a cognitive one.  Just as Ubiquity is only a cognitive leap- using a very old interface in places where it’s best suited for a task.

Error Pages

A seducible moment is when a user’s goal changes from performing their primary task to fixing the whatever is preventing them from accomplishing their primary task.

Google found that by placing the spell correction feature not only at the top, but also at the bottom of a search they were able to double it’s usage.  Users skimmed over what could have helped them originally because it was at the top.

Error pages could exploit this by offering a “best effort” landing page along with re-purposed knowledge-base materials.

Guided Exploration

Only a fraction of users have add-ons  due to the high barrier of actually adding them.  If we don’t just automatically add top-tier 3rd party commands we could at least offer them up on error pages.

However, we are limiting ourselves.  Google has replaced bookmarks, Wolfram is attempting to solve problems, and Bing wants to answer questions.  Isn’t Ubiquity not only a shortcut for these functions but also a replacement?  Why not embed suggestions where it is relevant, be it landing pages, a custom search page, or within the website itself?  Normal Google searches through Ubiquity could be redirected to a customized Google Custom Search page re-skinned with some JS magic:

Click to enlarge

This might seem hokey, and it’s effectiveness would be very limited in getting new commands onto Ubiquity.  But think of how the click-through rates and keywords from this “feature” can be used to improve the parsers logic.  User support isn’t just about teaching users, it’s a part of the user experience, it’s part of the testing cycle which improves Ubiquity.

Developer Support Structures

A more complex interface (such as MediaWiki, Trac, and Merc) filters out users who probably shouldn’t be patching code, logging bugs, or writing developer documentation.

However, the core developers are overworked trying to get the parser working,  internationalize it, integrate Taskfox, architect Jet Pack, design the UI, and help out on other Mozilla projects.  As a result, the core commands (among other things) have gone stale.  Commands are simple enough that even transient volunteers could improve them immensely.

I think a modified rule for these smaller items could be “Contributing shouldn’t take more than 60 seconds.”  Quality code takes longer than a minute- but hasn’t everyone found themselves spending hours on Wikipedia when they meant to just fix a minor thing?  Even hosting the commands on as individual GitHub projects would go long way towards increasing their exposure.

~

Please, leave negative feedback as well, challenge whatever I have to say.  I don’t get much feedback other than general “good job” stuff.  Not being a programmer, in mountain view, or being as visible as I could be really limits my understanding of the broader picture.  I often wonder if what I am doing is what what is most beneficial, or if I should change tactics or focus.  Take a moment to help me correct that : )

1. Anderson, John. Cognitive Psychology and its Implications. New York: Worth Publishers, 2004. [↩]

2. “47% of the users who failed only tried the search engine a single time. Another 30% tried twice. Less than 25% tried more than twice to get the search engine to produce a successful result…

   Now, the designers of many of the sites we tested went to great lengths to get users to continue searching. They put in encouraging search tips that said “Try a new search using different terms.”

   However, we did not see any evidence that these tips encouraged any user to search again. They pretty much assumed that the first (maybe second) try was the best they were going to get…

   These results indicate that designers get one, possibly two chances to help users find their content with Search. If most of the users don’t find what they want in the first try, it doesn’t seem likely they will ever find it.” -

   -People Search Once, Maybe Twice [↩]

Tags: featured, Ubiquity