The TwigKit Blog

Apple’s iOS Human Interface Guidelines, Google’s Android Design Guidlines, and others such as Luke Wroblewski’s Mobile First book provide valuable guidance for designing general mobile applications. Yet there are a number of design principles unique to crafting mobile search experiences in particular. Namely: prioritizing content over controls, providing answers over results, being sensitive to context, and ensuring cross-channel continuity.

Content Trumps Controls

Search is often accompanied by a number of knobs and dials: filters, breadcrumbs, sort controls, pagination; the list goes on. When moving from the design of desktop to mobile search interfaces, the temptation is to replicate all of these controls on the main search results screen. Yielding to this temptation, however, leads to cluttered, frustrating interfaces that add stumbling blocks to the user’s path.

The primary search screen of a mobile application should be focused on the clarity of search results; bells and whistles must take a back seat. Mobile users, after all, often use their devices for short bursts of time, enter fewer queries per search session than do desktop users, and may seek answers to simple, lookup-based information needs. These realities suggest that navigation bars should be kept to a minimum, filtering and sorting displaced off-screen, and pagination controls omitted so that the search results receive as much screen space as possible.

Left: 50% of AOL’s mobile search interface is consumed by chrome.

Answers over Results

In addition to minimizing search controls and emphasizing content, focusing on precision over recall is usually in the best interest of mobile users, particularly time-sensitive smartphone users. Precision, as you know, describes the accuracy of the top results. Because mobile users reformulate their queries less often than desktop users, prioritizing the relevance of the top few results is generally more useful than providing high recall.

Providing direct answers to users’ lookup queries can make the mobile search experience more efficient still. Rather than force users to click on a search result to discover straightforward facts, such as “director of third man movie”, for instance, a more desirable approach is to provide a computed answer directly on the search page, eliminating the need for further action.

But tablets are a different story. While phones are often used for short periods of time to accomplish tangible goals, tablets are more likely to be used for longer durations and with more casual information needs. Optimizing for precision over recall and answers over results is a good rule of thumb, but should be balanced with the user’s context.

Google provides a direct answer to the query.

Contextual Sensitivity

Few argue about the importance of context on mobile devices. But effectively designing for context is another matter. The trick is to carefully interpret the user’s current context so that the interface can be optimized accordingly, while being accurate and forgiving enough that users don’t get frustrated when the system identifies the context incorrectly. Interpreting the user’s context could include determining their task—driving, cooking, or doing bicycle repairs, for example—whether or not their physical location is important, or whether they’re alone or with others.

Each of these aspects of context, if correctly identified, provides opportunities for optimization. A query for “basel”, for example, could be interpreted as a city if the user is driving in Switzerland, or as an ingredient if the user’s task is cooking. A trivia-lookup query originating during a conversation with friends could prompt a direct answer, while a casual ‘window shopping’ query originating on a tablet via the sofa could be better addressed with an image grid that encourages undirected browsing.

Amazon’s Windowshop iPad app invites casual browsing.

Cross-Channel Continuity

Every business recognizes the value of consistency across channels: customers benefit from a coherent, holistic experience where the learning from one channel can be applied to all the rest. A user familiar with Amazon on the desktop will instantly recognize the similarity of Amazon’s mobile application, for instance. But while consistency ensures the learnability of each channel, continuity makes it personal. Continuity is adding an item to the shopping cart via a desktop computer, and having it appear in the shopping cart on your phone; it’s saving a search on your phone and returning to it later on your tablet. In other words, continuity ensures that your actions aren’t performed in isolation, but propagate from the source channel to each of the others.

Continuity between channels can facilitate the figure-it-out-later approach often taken by users, as well as reduce the number of information needs that fall through the cracks. For starters, search history should be synchronized across devices so that inconclusive information seeking can be easily followed up later. What’s more, allowing saved searches that are accessible from every channel enables users to organize and return to important, ongoing information needs.

Zillow allows users to save searches, but fails to synchronize them across devices.

Related Reading

• The Rise of Cross-Channel UX Design
• Mobile Information Needs

Mobile is the new desktop. The adoption of mobile Internet makes the introduction of the World Wide Web seeming glacial by comparison; Morgan Stanley predicts that mobile Internet usage will outpace desktop-based access in just three years.

Search—or information seeking more broadly—is pivotal to circumnavigating this convergence of the digital and physical worlds. But before designing experiences for the new frontier, we must first grasp the needs of users. Specifically, we must understand the information needs of mobile users.

“Information need is an individual or group’s desire to locate and obtain information to satisfy a conscious or unconscious need.” — Wikipedia

Two dimensions: scope and type

Mobile information needs can be assed by two criteria: scope and type. Scope describes the sophistication of the information need, the degree of higher-level thinking it involves, and the time commitment required to satisfy it. The lookup, learn, and investigate elements of scope are derived from Gary Marchionini’s work on exploratory search, while the casual component has been more recently advocated by Max Wilson and others.

Type, on the other hand, is concerned with the genre of the information being sought. Broder is often cited for recognizing the informational and transactional nature of many needs, while the geographic and personal information management goals identified by Church & Smyth are especially prominent for mobile users.

Scope

• Casual. Undirected/semi-directed with a hedonistic rather than task-driven purpose.
• Lookup. “Known item” searching for a concrete fact. Most common form of search.
• Learn. Iterative information gathering requiring greater interpretation and judgement.
• Investigate. Long-term research and planning demanding high-level of thinking.

Type

• Informational. Any search for information about a topic.
• Geographic. Points of interest searching or retrieving directions between locations.
• Personal Information Management. Private information not publicly available.
• Transactional. Goals which are action-oriented rather than informational.

A matrix of information needs

While the scope and type provide a framework, they don’t actually tell us about the information needs themselves. That’s where ethnography comes in. Sohn et al. and Church & Smyth have each conducted diary studies in which smartphone-toting adults spread across the globe were instructed to record any information need that arose over a period of weeks. This research enables us to construct a matrix of mobile information needs:

Below are quotes of information needs recorded by participants in the two studies mentioned above. Those without quotations indicate my own additions.

Informational

• Checking Notifications. I’ll glance over status updates to kill time while waiting.
• Trivia. “What did Bob Marley die of, and when?”
• Information Gathering. “How to tie correct knots in rope?”
• Research. What is Keynesian economics and is it a good idea?

Geographic

• Friend Check-ins. “Where are Sam and Trevor?”
• Directions. “Directions to Sammy’s Pizza”
• Local Points of Interest. “Where is the nearest library or bookstore?”
• Travel Planning. Flights, accommodations, and sights for my trip to Italy.

Personal Information Management

• Checking Messages. “Email update for work”
• Checking Calendar. “Is there an open date on my family calendar?”
• Situation Analysis. “What is my insurance coverage for CAT scans?”
• Personal Planning. What should my New Year’s resolutions be this year?

Transactional

• ‘Window’ Shopping. I don’t know what I want. Show me stuff.
• Price Comparison. “How much does the Pantech phone cost on AT&T.com?”
• Online Shopping. I want to buy a watch as a gift. But which one?
• Product Monitoring. I know the make and model of used car I want. Alert me when new ones are listed.

A penny for your thoughts?

Though this matrix does accommodate the most common information needs identified by Sohn et al. and Church & Smyth, it is still a work in progress. As such, I would very much appreciate your feedback.

This is a book review of Search Analytics for Your Site: Conversations with Your Customers by Louis Rosenfeld, published by Rosenfeld Media, July 2011.

Financial services company The Vanguard Group had just purchased a shiny new search engine to improve search for their 12,000 employees. There was only one problem: the search results were worse than what they had before.

John Ferrara, an information architect who had helped select the new search platform, blew the whistle, asking the project to be delayed so that relevancy could be improved before the search engine went live. Unfortunately, he failed to make a convincing case to his IT colleagues. Technically, the new platform was running just fine. Besides, the search vendor undoubtedly new more about this kind of stuff than the internal guys.

But not to be deterred, John Ferrara turned to the search logs. He aggregated the most popular search queries from the old platform and, going down the list one by one, measured two metrics for each: relevancy and precision. To measure relevancy, John typed in the query (“company address”, for instance), and checked to see how far down the best match appeared from position #1. To measure precision, on the other hand, John looked at the top five results for a given query and marked each as either relevant, nearly relevant, misplaced, or irrelevant. The output from each of those exercises is shown below.

Source: Rosenfeld, Louis. 2011. Search Analytics for your Site. New York: Rosenfeld Media.

Source: Rosenfeld, Louis. 2011. Search Analytics for your Site. New York: Rosenfeld Media.

By turning to the data, John was able to convince his colleagues that there was, indeed, a problem. With hands on deck, the team was fortunately able to tune the new search platform before it went live, bringing relevancy and precision up to parity with the old system. Thanks to search analytics, John had saved the team from what could have been a serous blunder.

What’s it all about?

Lou Rosenfeld opens with this relatable story in his latest book Search Analytics for Your Site: Conversations with Your Customers. The book is a very practical guide on how to exploit query logs to improve your company’s search experience. Lou outlines a collection of simple but potent techniques for analyzing search logs, spotting insightful patterns, and putting those insights to use.

As mentioned in the Vanguard story, Lou demonstrates the value of understanding users’ most common queries. But he also goes much further. From studying failure situations (which queries lead to zero results), to session data (who searched what when), audience segmentation, and goal-based analysis (using key performance indicators), Search Analytics presents a sweeping collection of techniques for turning search logs into an organizational goldmine.

And if those techniques weren’t practical enough already, Lou ends the book with a comprehensive list of tips for using search data to improve your website’s search, content, navigation, and metadata.

Search Analytics is well-written, to the point, and does what it says on the tin.

Search Analytics is well-written, to the point, and does what it says on the tin. The author is authoritative — he wrote Information Architecture for the World Wide along with Peter Morville — as well as experienced, having consulted for companies such as PayPal, Caterpillar, Ford, and others. I was able to put into practice techniques I learned within days of first picking up the book. If you in anyway share responsibility for search in your organization, this book is well worth your time. I highly recommend it.

Resources

• Use promo code TWIGKIT to receive 20% off at RosenfeldMedia.com
• Purchase from Amazon.co.uk or Amazon.com
• View Lou’s presentation, “Site Search Analytics”, on Slideshare

Have you ever noticed a honeybee fly in a tight loop? Individually a bee will set out on its in own in search for food. But rather than hoard an abundant source of nectar for itself, the honeybee will return to his swarm and dance in a figure-eight pattern to alert the others of the new food source.

Similarly, our information seeking is situated within a backdrop of social activity. While your fingers alone may type a query into the search box, our need for declarative (know-what) and procedural (know-how) knowledge — as well as the means by which we acquire it — is inseparably intertwined with other people.

In The UX of Learning I recently outlined six stages of learning — initiation, selection, exploration, formulation, collection, and action — which can also be thought of as stages of information seeking. Here I’d like to look at the two directions of social activity which occur throughout that six-stage process: pull and push. Understanding the social context of search will better position us to design the collaborative search applications of the future.

Pull

I’ve been having bicycle trouble recently. My pedal fell off, I had to replace a crank, and most recently, the chain snapped in two (not all at once, fortunately!). At some point I’ll have to sit down at my computer, do a bit of research, and order a replacement part. In the meantime, I’ve received several words of advice from friends, including things like:

“You should get the KMC X10 SL 10 Speed Chain Gold, it’s amazing!”
“Just ask the guys at Evans Cycles, they’re really knowledgable.”
“Hmm, you’ve been having so many problems lately I’d replace the entire crankset.”
“Yeah, I think you’re right: If I were you I’d save money and only replace the chain.”
“I talked to the guy at my local cycle shop and he strongly recommended the KMC double durability chain.”

Researches Rob Cross and Lee Sproull interviewed 40 managers from a major accounting firm to analyze the types of “actionable knowledge” that are shared through personal interactions. The feedback I received about bicycle chains fits into the five categories they identified:

1. Solutions. Direct answers to a specific questions.
2. Referrals. References to a person or information source.
3. Problem reformulations. Altering the question that is being asked.
4. Validation of plans. Confirmation of the approach.
5. Legitimization. Consulting an authority figure in order to expropriate their authority.

Pulling occurs when you interact with other individuals in order to satisfy your own information need.

Push

Pushing, on the other hand, is not associated with furthering your current information need, but revolves around sharing ideas with others.

In 1993 Vicki O’Day and and Robin Jeffries interviewed clients of professional intermediaries to discover how search findings were shared within the organization, while Preben Hansen and Kalervo Jarvelin conducted a similar study in 2005 with patent researchers. When combined, the two studies reveal a number of self-initiated push actions, including:

1. Sharing documents. Such as articles, reports, and presentations.
2. Sharing information about documents. Including annotations, references, citations.
3. Self-initiated broadcast. A tweet, status update, mass email, or blog post.
4. Archiving. Recording information for future retrieval.

In Conclusion

Social networks have come to define how we interact with our friends. Yet the enterprise — which stands to gain enormously through better collaboration amongst its employees — has yet to figure out how to use technology to best facilitate collaboration. Push and pull are certain to play a big role in the future of enterprise search.

Yesterday was the deadline to submit a redesign of Wikipedia’s search page to the search design contest organized by Greplin. While the contest isn’t officially endorsed by Wikipedia, we found the challenge too much fun to turn down.

The Status Quo

Most people use Google to search Wikipedia. What’s broken about Wikipedia’s search?

1. Search gets second-class treatment on Wikipedia

Can you even remember what Wikipedia’s search page looks like? Despite having a search box at the top right of every page, Wikipedia only shows search results as a last resort. They first try to send users directly to other Wikipedia pages. Type in “London riots” and you’re redirected straight to List of Riots in London. Or type “US” and you get the US Disambiguation page. Only when no page exists, such as for ”egypt pyramid”, does Wikipedia show search results. Even then, the search results are treated as en error state, with a message saying “Sorry, this page doesn’t exist.”

2. Unnecessary clutter pushes results too low on the page

Even excusing the Wikimedia notice, there are a number of unnecessary elements on the page which cause less than three results to appear above the fold. The “Search Results” heading isn’t needed, a link to the search help page is mentioned not once, but twice, and there’s that long error message complaining that the page doesn’t exist. None of these are needed.

3. Lack of helpful filtering options

A look at Wikipedia’s contents pages reveals a robust, top-down categorization of knowledge into structured categories. Unfortunately, none of this encyclopaedic categorization makes its way to the search page. If searching for “beatles”, for instance, it would be nice to filter by either “Nature” or “Culture”.

4. Uninformative search results

A short title, a 20-word description — that’s all the user has to go on. Titles could be augmented with disambiguation information, the category of the article could be listed, descriptions could be longer, images could be displayed. There’s a wealth of useful information Wikipedia could pull from to improve the display of search results.

The Redesign

But enough complaining. What would a useful, usable Wikipedia search look like?

1. Results with strong information scent

Users quickly scan the page looking for trigger words and visual concepts meaningful to their search. By using images, longer descriptions, and providing greater context through categories and related articles, our redesign would helps users find what they’re looking for more quickly and more reliably.

2. Emphasize the best match

Rather than skip the search results page altogether by taking users directly to an article, we would instead use the result list to emphasize the most relevant article. We would us a visual container, a larger image, and links to sub-sections to highlight the top article.

3. Meaningful faceted navigation

There are at least two dimensions to Wikipedia’s content: aboutness and format. Aboutness is captured at a high level by Wikipedia’s portals: arts, biography, geography, history, mathematics, science, society, and technology. We chose to place these as tabs at the top of the page, allowing users to filter their search to any one high-level subject. Format, on the other hand, is represented by Wikipedia’s content types: article, list, picture, portal, sound, and topic. We thought these best-suited for the sidebar, where we also added a category facet to help users narrow in on lower-level sub-topics. To complete the faceted navigation, we also added a breadbox to keep track of any filters users apply.

The Last Word

There are doubtless many other approaches which could improve Wikipedia’s search. Our goal was to design a search interface in keeping with Wikipedia’s style and ethos, which they could conceivable implement in the real-world with a modest amount of effort. In fact, only the search results themselves were mocked-up in Photoshop; the layout, tabs, searchbox, faceted navigation, and surrounding elements shown in the redesign were all built using the TwigKit toolkit and are already functional in the browser. We are of course happy to donate these design ideas to Wikipedia should they come across this post.

Read more about the Wikipedia search design competition on TechCrunch.

Today I’ve been experimenting with a different take on faceted navigation. TwigKit’s current facet widget is already robust – it displays both flat and hierarchical facets, it’s expandable, it allows users to exclude a given filter, the list continues. But today, there are two additional use cases that I set out to address:

The Challenge

1. View all filters. Not just expanding from 7 to 20, but viewing all the available filters.
2. Search within a facet. If the filter of choice doesn’t appear at the top of the list, allow them to search for it.

Neither of these features are necessary in the average search interface (in fact, many interfaces are better off without them). However, they are useful when detailed analysis is required. An intelligence analyst, an academic researcher, and even a very dedicated shopper would appreciate the flexibility that these controls provide.

Design Philosophy

Once I understand what the user needs, I tend to look through three lenses when designing the how. In order of priority:

1. Minimize cognitive load
2. Minimize visual complexity
3. Optimize browser performance

Unfortunately, many of the search within/view all implementations I’ve seen are a bit heavy-handed. I was hoping for a gentler approach.

A Potential Solution

After experimenting with a few different approaches, I decided to prototype a design patten based on progressive disclosure. The series of screenshots below correspond to these four actions:

1. Default state. As few controls as possible are shown by default to minimize cognitive load and visual complexity.
2. Expanded state. Once the user clicks “Show more,” the container expands and the “search within” box appears.
3. Endless scrolling. Not only does the expanded container enlarge, but it also becomes scrollable. When the user hits the bottom of the list, we’ll ask the server for more and append them to the bottom of the list.
4. Search with autocomplete. As the user types into the facet search box, the filters will be refined as the user types.

(Here’s my partially-implemented webkit prototype for Safari and Chrome users.)

What’s Your Take?

A few reasons why I like this solution:

1. The search-within box and scrollbar are shown only after the user has expressed interest in the facet
2. It allows all the filters to be viewed without using an additional popover or modal.
3. The search box refines the list of filters below it, avoiding the need for the traditional popover-based autocomplete.

However, this is only the result of one day of experimentation. More than anything I’d love to hear what others think of this new take on an old design pattern.