As part of our New Ventures program, Adaptive Path worked with Sphere, a San Francisco-based startup, to develop and refine their weblog search engine. Project lead Ryan Freitas discusses the approach he and the Sphere team took to develop the application.
There is no shortage of competition among blog search tools right now, and most of them are trying to differentiate themselves by pushing an overwhelming array of features at their users. Unfortunately, many of those features are secondary to what users are actually trying to accomplish. Adaptive Path was recently faced with the challenge of designing an interface for the much-anticipated blog search tool Sphere. The company’s founder and CEO, Tony Conrad, knew that Sphere’s innovative algorithm needed a compelling and straightforward interface to engage users. So in the Summer of 2005, he approached Adaptive Path and asked us to craft a user experience that allowed searchers to explore the power of the tool, yet still felt “simple.”
The Sphere team had already put a lot of work into returning fresh, relevant search results, and had several ideas about how to evolve the standard search experience. Filtering results appropriately (to let users easily get at the exact result they were after) would be paramount. Deep context for results would also be offered, along with related items (from traditional media to podcasts).
Adaptive Path was impressed by the ideas the Sphere team had for the product, but we also recognized the tremendous design challenge they faced. The underlying technology was powerful, but without clear ways for users to explore the tool’s capabilities, Sphere ran the risk of becoming yet another also-ran in the blog search race.
The Challenge
Part of the challenge of this project was the relative universality of search. For many users, search has become so familiar that it’s a de facto means of navigation. Meanwhile algorithms have become more advanced, and the number of indexed pages has grown exponentially. There’s potential to do so much more with search, but there are relatively few standards for how to present users with more options.
The question for the Adaptive Path team was how to iterate the search experience without alienating users. More importantly, we wanted to do so without messing up the elegance of the search box.
We started by talking things through with the Sphere team. In those conversations, Tony expressed concern that anything more than a search box on the home page might distract users. He joked that he wanted “no more than thirty words” on the page, and while the comment wasn’t meant to be taken literally, the notion resonated with us. The phrase wound up on a note stuck to my monitor throughout the design process, and it was a constant reminder of the spare approach we wanted to pursue with this project.
Home Page
The goal on the home page was to let users engage with the tool and discover its power for themselves. We also wanted that relationship to remain consistent for every page on the site.
To help users engage, we decided to make novel and compelling features discoverable without letting those features overpower the simplicity of the search box. Our guiding principles were restraint and appropriateness, and those rubrics helped us judge which features to incorporate, and how.
At the same time, we didn’t want a design that was so overly focused that it seemed Spartan, so we balanced the home page’s spare direction with a sense of play.
My experience designing interactive kiosks has taught me that users don’t mind a page with a single purpose as long as that purpose suits their needs precisely. We felt that an enlarged input field would call attention to itself, and get users to the results they sought.
The Adaptive Path team then faced the question of how heavily to promote features, or the value statement, or even secondary navigation. While they all needed to be included, we decided they were less integral, so we subdued the presence of those elements on the page.
Figure 1: Screen shot of the Sphere home page search box (click to enlarge.)
The Results Filter
When designing the results page, calculating appropriateness became significantly more difficult because there were so many filtering features to consider.
Tony’s team, guided by social media entrepeneur Mary Hodder’s exhaustive research, chose to differentiate the quality of results based on relevance rather than timeliness.
Beyond the engines’ default results, users can filter the returned posts by factors such as language and date. Adaptive Path wanted to keep the search process simple, but still improve users’ access to options and more targeted results.
While other search engines scatter filtering options around the page, we saw a chance to consolidate the whole experience. We decided to show users what Sphere’s filters could do by providing clear explanations, and making it obvious how to change the filters at will.
To do that, we followed the example set by the FogBugz bug tracking software. I’m a tremendous fan of the sentence-based filter interface they use to help users pare down huge bug lists. With their interface as a reference, we put together a simple, powerful interface for filtering search results.
A single sentence at the top of each page uses plain English to tell the user what’s displayed below. Each word or phrase in that sentence is editable with just a click, and each change filters the results that follow. The screen isn’t crowded with multiple options; instead they become visible only when suited to the user’s task at hand.
The Histogram Slider
Regular blog readers understand that posts reference one another, creating conversation timelines with beginnings and ends. Sphere wanted to expose posting activity levels along those timelines, and let users filter posts by whatever dates interest them.
Visualizing and sorting results by custom date ranges is an enormous innovation in blog searching, so figuring out how to present these features to users was a formidable challenge.
We decided to use a flash module for displaying post frequency over time, a feature Adaptive Path had originally developed for our Measure Map application. The display presents a histogram of results grouped by time, while a slider on the bottom lets users specify a date range.
The sheer novelty of the module was a concern at first. A results page that defaulted to displaying the slider would detract attention from results, and it would be difficult for users to focus on the posts below with an attention-grabbing Flash widget at the top of the page, pushing results farther down.
Again, we were evaluating based on appropriateness. It may have been a cool feature, but we had to consider its value to average users versus its capacity to distract. Ultimately we decided that the module would require a trigger instead of displaying by default on the page load. For the sake of advanced users, for whom the slider would be most valuable, we wanted the trigger to require only a single click. We also wanted the slider to be discoverable, but not obvious.
We found that tying our trigger to a “custom date range” option in the filter gave us an equitable solution to all of our design problems. It’s not overt, and though mapping a pull-down option to a non-standard event breaks a few UI conventions, it felt right for what we were trying to build.
Figure 2: Screen shot of the Sphere histogram slider (click to enlarge.)
Profiles
The Sphere team designed blog profiles to assist users’ evaluation of a particular blog’s authority or relevance. The profiles give users a wealth of information, including which sites link to a particular blog and how old the blog is.
Of course Sphere has all kinds of data for every indexed blog. The Adaptive Path team had to decide what information was important for users making quick judgments on relevancy.
We truncated the total data to a few significant facts, and created what we call a mini-profile. We then contained that information in a JavaScript layer. Surfacing profiles was simple: we just put a link next to each blog name on the results page. Once clicked, the mini-profile layer loads right next to the blog in question. This keeps users on the page and within their task, while also providing them with the context they need to successfully complete their search.
Figure 3: Screen shot of a Sphere profile (click to enlarge.)
Wrap Up
By simplifying as much as possible, we’ve designed a tool that should stand out in a cluttered field.
Of course not every design decision we made will prove absolutely correct for every user, but the launch version of Sphere represents a well-conceived foundation, one from which the tool’s capabilities and interface will no doubt evolve.
In designing Sphere, Adaptive Path sought to innovate where we thought it was most valuable to users, but without wrecking the simplicity of the search experience. We built an interface without unnecessary distraction, hoping users will discover the tool’s powerful utility by simply letting them search.
Ryan Freitas is a Senior Interaction Designer with Adaptive Path. He is an experienced information architect, application and device interface designer. He writes online at Second Verse. Clients include Sphere, Flickr, Socialtext and Six Apart.
Source: Ryan Freitas
License: Creative Commons