<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>DesignCaffeine &#187; Search Matters</title>
	<atom:link href="http://www.designcaffeine.com/tag/search-matters/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.designcaffeine.com</link>
	<description>UX Design of Intuitive &#38; Resourceful Systems</description>
	<lastBuildDate>Sat, 05 Jun 2010 01:49:03 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Design Patterns for Mobile Faceted Search: Part II</title>
		<link>http://www.designcaffeine.com/2010/articles/354/</link>
		<comments>http://www.designcaffeine.com/2010/articles/354/#comments</comments>
		<pubDate>Sat, 05 Jun 2010 01:27:45 +0000</pubDate>
		<dc:creator>Greg Nudelman</dc:creator>
				<category><![CDATA[Articles]]></category>
		<category><![CDATA[iPhone]]></category>
		<category><![CDATA[Mobile]]></category>
		<category><![CDATA[Search Matters]]></category>
		<category><![CDATA[Search Results]]></category>
		<category><![CDATA[UX Design]]></category>

		<guid isPermaLink="false">http://www.designcaffeine.com/?p=354</guid>
		<description><![CDATA[Originally Published on UXMatters.com May 3, 2010 ⇒
In Part I of “Design Patterns for Mobile Faceted  Search,” I looked at the challenges and opportunities of mobile faceted  search. 		To address the well-known challenge of limited screen real estate on 		mobile devices, I covered the Four Corners, Modal Overlay, Watermark, 		and Full-Page Refinement Options [...]]]></description>
			<content:encoded><![CDATA[<p><a title="Read this article on UXMatters (Opens in a New Window)" href="http://www.uxmatters.com/mt/archives/2010/05/design-patterns-for-mobile-faceted-search-part-ii.php" target="_blank">Originally Published on UXMatters.com May 3, 2010 ⇒</a></p>
<p>In <a title="Part I" href="http://www.uxmatters.com/mt/archives/2010/04/design-patterns-for-mobile-faceted-search-part-i.php">Part I</a> of “Design Patterns for Mobile Faceted  Search,” I looked at the challenges and opportunities of mobile faceted  search. 		To address the well-known challenge of limited screen real estate on 		mobile devices, I covered the Four Corners, Modal Overlay, Watermark, 		and Full-Page Refinement Options design patterns, which maximize the 		real estate available for search results on a mobile device. This 		month’s column covers strategies for making people more aware of the  filtering options that are available to them, as well as  methods of  improving 		 transitions between the various states a user encounters in a search 		user interface.<br />
<span id="more-354"></span></p>
<h2>Teaser Mobile Design Pattern</h2>
<p>Teasers are nothing new on  mobile phones. Most mobile user  interfaces 	implement this pattern in some manner or another. Consider, for  example, 	the Yelp iPhone application, shown in Figure 1.</p>
<p>Figure 1—Teaser design pattern in  Yelp’s mobile app</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/05/images/figure1_yelp_iphone.jpg" alt="Teaser in Yelp app" width="320" height="460" /></p>
<p>Yelp displays five complete search results, 	plus a teaser at the bottom of the page that shows a partial view of  the 	next result set. The Teaser design pattern is very useful in showing  that 	there are more search results below the fold. As I mentioned in a  previous column, “<a title="Choosing the Right Search Results Page Layout: Make the Most of  Your Width" href="http://www.uxmatters.com/mt/archives/2009/03/choosing-the-right-search-results-page-layout-make-the-most-of-your-width.php">Choosing 	the Right Search Results Page Layout: Make the Most of Your Width</a>,”  my 	usability testing has shown that Amazon is an absolute master of this 	pattern. Regardless of a screen’s resolution, they <em>always</em> display 	partial product descriptions and pictures just above the fold. Showing 	part of what is at the fold is a very effective means of inviting  visitors 	to scroll down and see more content.</p>
<p>Recently, when Microsoft came out with Windows 7  Mobile, they 	extended the Teaser pattern well beyond just showing the availability  of 	search results below the fold. In Figure 2, an excellent 	video from Luke Wroblewski’s 	blog entry “Windows Phone: User Interface Teases &amp; Transitions”	 effectively 	demonstrates this concept. As you can see, Windows 7 Mobile shows there  is 	more content   available on the left, right,  above, <em>and</em> below  what’s 	currently visible on the screen.</p>
<p>Figure 2—Teasers and transitions in 	Windows 7 Mobile (Compiled by Luke Wroblewski)</p>
<p><object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" width="474" height="380" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"><param name="allowFullScreen" value="true" /><param name="allowscriptaccess" value="always" /><param name="src" value="http://www.youtube.com/v/EUeNCzRhhDE&amp;hl=en_US&amp;fs=1&amp;" /><param name="allowfullscreen" value="true" /><embed type="application/x-shockwave-flash" width="474" height="380" src="http://www.youtube.com/v/EUeNCzRhhDE&amp;hl=en_US&amp;fs=1&amp;" allowscriptaccess="always" allowfullscreen="true"></embed></object></p>
<p>In its implementation of the Teaser pattern, Windows 7  Mobile 	uses lots of very obvious cues, including screen titles that are cut  off 	in midword, partially visible screen widgets, image fragments, and  abundant 	use of animated transitions.</p>
<p>A <em>teaser</em> is a specific application of the more 	general design principle: <em>fixing imperfection</em>, in which a  design immediately 	engages people by having them fix something that is intentionally not  quite 	right with a user interface or object. In the process of fixing an  imperfection, 	people learn the user interface’s 	interaction model. Studies have shown that this process of fixing  imperfection, 	or seeking symmetry, is very natural to humans and quite immersive,  even 	to the point of alleviating anxiety and pain in burn trauma.</p>
<p>The problem some may see with the   Windows 7 Mobile  design 	is that people cannot win at this particular game of fixing  imperfection. 	There is absolutely no way to fix the user interface to simultaneously  show 	<em>all</em> of a title, widget, or image that exceeds the size of the  screen. 	It’s 	kind of like a blanket that is intentionally made too small: if you  cover 	your legs, your chest is exposed; pull the blanket up to your chin and  your 	legs get cold. As UX designers, we often seek a kind of minimalistic,  authentic 	beauty and symmetry in our designs, so some  designers might find this 	kind of user interface profoundly disturbing. However, one cannot argue  against 	the effectiveness of this design approach.</p>
<p>The wireframe shown in Figure 	3 takes advantage of the Teaser design pattern to show a partial view  of 	some faceted search filters on the right and, thus, expand the  available 	virtual screen real estate.</p>
<p>Figure 3—Teaser design pattern  facilitates the discovery of faceted search 	filters</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/05/images/figure3_teasers_wireframe.png" alt="Wireframe showing Teaser pattern" width="473" height="383" /></p>
<p>The search results are on the left  in this wireframe;  filters, 	on the right. Following a basic convention of mobile 	user interfaces, buttons on the right let people drill down deeper into  the 	application’s information 	architecture (IA) space, while tapping buttons on the left moves them  closer 	to the top of the IA or to the home page. In this example of what  Microsoft 	calls <em>panoramic 	applications</em>, 	the mobile device acts as a sort of viewfinder that displays only a  small 	part of a much larger virtual space.</p>
<p>The Teaser design pattern very effectively  facilitates 	discovery through its use of partially exposed screen elements—in my 	example, faceted search results filters. This pattern 	also enables people to make rapid transitions from looking at search  results 	to narrowing down the search results, so it is highly suitable for  applications 	in which it is advantageous for people to discover a set of filters  quickly 	and use them often.</p>
<h2>Basic/Advanced Parallel Architecture Pattern</h2>
<p>Another good design pattern for efficient discovery and use of  filters is 	the Basic/Advanced Parallel Architecture design pattern, depicted in  Figure 	4. This design pattern is especially effective in applications that  offer 	a fixed set of filters—for instance, booking air travel.</p>
<p>Figure 4—Basic/Advanced Parallel  Architecture design pattern</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/05/images/figure4_parallel_wireframe.png" alt="Basic/Advanced Parallel Architecture" width="473" height="691" /></p>
<p>The idea behind the Basic/Advanced Parallel  Architecture design 	pattern is that there are two modes of interacting with filters: basic  and advanced. 	The <em>basic mode</em> lets customers easily engage 	with your application and dramatically shortens their learning curve.  However, 	people who want an <em>advanced mode</em> of filtering can easily  obtain this 	functionality—in 	the example shown in Figure 4, by returning to the filter page and  tapping 	the <strong>Advanced Search</strong> tab.</p>
<p>The <em>parallel architecture</em> part of this pattern 	comes in when a customer needs to adjust the filter values. For  customers 	who started their query from the <strong>Basic Search</strong> tab,  tapping 	<strong>Back</strong> returns them to that tab. For customers who  started from 	the <strong>Advanced Search</strong> tab, tapping <strong>Back</strong> returns 	them to that tab, where they can adjust the expanded set of filters.  While 	the relationships between these three contexts—Basic 	Search, Advanced Search, and Search Results—are a bit difficult to  explain, 	they offer a very natural interaction model that most people have found  very 	intuitive to use during testing.</p>
<p>The Basic/Advanced Parallel Architecture 	design pattern offers the added advantage of a flatter architecture.  Instead 	of an advanced mode that requires people to go deeper into an  application’s 	IA, the advanced flow sits in parallel with the basic flow, so both are  equally 	accessible with a single tap.</p>
<p>It is important to note that, in both cases, the search  results 	page has a persistent status bar across the top of the screen,  displaying 	an entire search query, <em>plus</em> any applied filters. Recall that a  persistent status 	bar was one of the features I described in Part I of “<a title="Design Patterns for Mobile Faceted Search." href="http://www.uxmatters.com/mt/archives/2010/04/design-patterns-for-mobile-faceted-search-part-i.php">Design 	Patterns for Mobile Faceted Search.</a>”</p>
<p>One application that successfully implements the  Basic/Advanced 	Parallel Architecture design pattern is the Thirsty Pocket 	iPhone app, shown in Figure 5.</p>
<p>Figure 5—Basic/Advanced Parallel  Architecture design pattern in Thirsty Pocket</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/05/images/figure5_thirsty_pocket.png" alt="Thirsty Pocket" width="473" height="841" /></p>
<p>Notice that, instead of labeling this feature <strong>Advanced</strong>, 		Thirsty Pocket uses the label <strong>More Search Options</strong>. In  Thirsty 		Pocket, the purpose of the advanced search page is to provide options 		for searching outside the device’s current 	GPS location, as well as narrowing a search by price. Most people would  <em>not</em> use 	the location filter, and the price filter might, in fact, severely  limit 	the effectiveness of search by too frequently narrowing a search to  zero search 	results. The price filter is a great example of the “ejector 		seat lever” Alan 		Cooper so eloquently describes in his book <em>About Face 3</em>. 	Therefore, this price filter is best hidden on a separate page. 	In the Thirsty Pocket app, the label <strong>More Search Options</strong> describes the purpose 	of the advanced search page perfectly and has the added bonus of being  less 	intimidating.</p>
<p>In another variation on the Basic/Advanced Parallel  Architecture 		design pattern,  instead of <strong>Basic Search</strong> and 		<strong>Advanced Search</strong> tabs, Thirsty Pocket presents two  buttons 		on its home page: a prominent <strong>Search Near Me</strong> button  for  basic 		search and a de-emphasized <strong>More Search Options</strong> button  for 		 advanced search options. Tapping <strong>More Search Options</strong> lets 		 you set filters, then tap <strong>Advanced Search</strong> to see the  filtered 		 search results. Nevertheless, the Thirsty Pocket 		user interface still preserves the essential features of this pattern, 		 because tapping  <strong>Modify Search</strong> on the search  results page 		 takes you back to the appropriate search page—basic 		or advanced—depending 	on how you initiated a search.</p>
<h2>In Conclusion</h2>
<p>A lot of people have asked me about these design patterns and the  best ways 	to use them. Thank you all for your questions. Unfortunately, the  answer 	would go well beyond the scope of even a two-part article. The best  recommendation 	I can make is that you learn as many design patterns as possible;  understand 	why these patterns have emerged, what customer and business goals they  support, 	and what limitations they have. Then, once you understand the unique 	goals of your own customers and business leaders, you can either choose 	the right design pattern or combination of patterns or develop your own  design 	patterns that fit the task at hand. Our understanding of user  interfaces is 	still evolving—and 	for mobile design, still in its infancy. Mobile design patterns and  paradigms 	are just beginning to emerge, but they represent the beginning of  something 	magnificent.<a title="Top" href="http://www.uxmatters.com/mt/archives/2010/05/design-patterns-for-mobile-faceted-search-part-ii.php#top"><img src="http://www.uxmatters.com/images/ux-bug.gif" alt="" width="18" height="18" /></a></p>
<h4>References</h4>
<p>Bucolo, Sam et al. “The Design of a Tangible  Interaction Device to Alleviate 	Anxiety and Pain in Pediatric Burns Patients.” <em>CHI ’06 Extended  Abstracts 	on Human Factors in Computing Systems</em>, Montreal, Quebec, Canada,  April 22–27, 	2006.</p>
<p>Cooper, Alan, Robert Reimann, and David Cronin. <em>About  			Face 3: The Essentials of Interaction Design.</em> 3rd ed.  Indianapolis, IN: 	John Wiley &amp; Sons, Inc., 2007.</p>
<p>Nudelman, Greg. “<a title="Design Caffeine for Search and Browse UI" href="http://www.slideshare.net/gnudelman/design-caffeine-for-search-and-browse-ui-iasummit2010">Design Caffeine for  Search and Browse UI</a>.”<a title="Design Caffeine for Search and Browse UI" href="http://www.slideshare.net/gnudelman/design-caffeine-for-search-and-browse-ui-iasummit2010"><img src="http://www.uxmatters.com/images/new-window-arrow.gif" alt="" width="14" height="12" /></a> <em>Information 	Architecture Summit 2010</em>, Phoenix, Arizona, April 9–11, 2010.  Retrieved April 30, 2010.</p>
<p>—— “<a title="Design Patterns for Mobile Faceted Search" href="http://www.uxmatters.com/mt/archives/2010/05/mt/archives/2010/04/design-patterns-for-mobile-faceted-search-part-i.php">Design 		Patterns for Mobile Faceted Search</a>.” <em>UXmatters</em>, March 8,  2010. Retrieved 	April 30, 2010.</p>
<p>—— “<a title="Experience Design for a Viral Mobile Community" href="http://www.slideshare.net/gnudelman/experience-design-for-a-viral-mobile-community">Experience  Design for a Viral Mobile Community</a>.”<a title="Experience Design for a Viral Mobile Community" href="http://www.slideshare.net/gnudelman/experience-design-for-a-viral-mobile-community"><img src="http://www.uxmatters.com/images/new-window-arrow.gif" alt="" width="14" height="12" /></a> <em>Net 	Squared Conference</em>, San Jose, CA, May 2009. Retrieved April 30,  2010.</p>
<p>—— “<a title="Choosing the Right Search Results Page Layout: Make the Most of  Your Width" href="http://www.uxmatters.com/mt/archives/2009/03/choosing-the-right-search-results-page-layout-make-the-most-of-your-width.php">Choosing 		the Right Search Results Page Layout: Make the Most of Your Width</a>.”  	<em>UXmatters</em>, March 9, 2009. Retrieved April 30, 2010.</p>
<p>Wroblewski, Luke. “<a title="Windows Phone: User  Interface Teases &amp; Transitions" href="http://www.lukew.com/ff/entry.asp?1003">Windows Phone: User Interface  Teases &amp; Transitions</a>.”<a title="Windows Phone: User  Interface Teases &amp; Transitions" href="http://www.lukew.com/ff/entry.asp?1003"><img src="http://www.uxmatters.com/images/new-window-arrow.gif" alt="" width="14" height="12" /></a> <em>LukeW Ideation +  Design</em>, February 17, 2010. Retrieved April 30, 2010.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.designcaffeine.com/2010/articles/354/feed/</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
		<item>
		<title>Design Patterns for Mobile Faceted Search: Part I</title>
		<link>http://www.designcaffeine.com/2010/articles/348/</link>
		<comments>http://www.designcaffeine.com/2010/articles/348/#comments</comments>
		<pubDate>Thu, 22 Apr 2010 18:24:03 +0000</pubDate>
		<dc:creator>Greg Nudelman</dc:creator>
				<category><![CDATA[Articles]]></category>
		<category><![CDATA[Article]]></category>
		<category><![CDATA[Finding]]></category>
		<category><![CDATA[iPhone]]></category>
		<category><![CDATA[iPhone App]]></category>
		<category><![CDATA[Mobile]]></category>
		<category><![CDATA[Search Matters]]></category>
		<category><![CDATA[Search Results]]></category>
		<category><![CDATA[UX Design]]></category>

		<guid isPermaLink="false">http://www.designcaffeine.com/?p=348</guid>
		<description><![CDATA[Originally Published on UXMatters.com April 5, 2010 ⇒
In my previous Search Matters column, “Mobile  Finding: Turning Limitations into Opportunity,” I discussed how  mobile 		search user experiences differ from those on the Web. In this and my 		next column, I’ll look specifically at the challenges and  opportunities 		of mobile faceted search. This column [...]]]></description>
			<content:encoded><![CDATA[<p><a title="Read this article on UXMatters (Opens in a New Window)" href="http://www.uxmatters.com/mt/archives/2010/04/design-patterns-for-mobile-faceted-search-part-i.php" target="_blank">Originally Published on UXMatters.com April 5, 2010 ⇒</a></p>
<p>In my previous <em>Search Matters</em> column, “<a title="Mobile Finding: Turning Limitations into Opportunity" href="http://www.designcaffeine.com/2010/search-matters/337/">Mobile  Finding: Turning Limitations into Opportunity</a>,” I discussed how  mobile 		search user experiences differ from those on the Web. In this and my 		next column, I’ll look specifically at the challenges and  opportunities 		of mobile faceted search. This column covers design patterns for  maximizing 		the real estate available for search results, while the next will  cover strategies 	for making people aware of filtering options.</p>
<p>Faceted search is extremely helpful for certain kinds  of finding—particularly for ecommerce apps. Unfortunately, the designers  of mobile applications do <em>not</em> have established user interface  paradigms they can follow or abundant screen real estate for presenting  facets and filters in a separate area on the left or at the top of a  screen. To implement faceted search on mobile devices, we 	need to get creative rather than following established Web design  patterns. 	Join me in exploring the Four Corners, Modal Overlay, Watermark, and  Refinement Options design patterns for mobile devices. Following these  patterns can 	move us one step closer to making faceted search a usable reality on  mobile 	devices.<br />
<span id="more-348"></span></p>
<p>But first, let’s take a look at the challenges of  designing 	mobile faceted search, which include navigational elements that use up  precious 	screen real estate, limited search-refinement options, and the general  lack 	of an iterative refinement flow.</p>
<h2>Mobile Faceted Search Challenges</h2>
<p>Recall that one of the mobile applications I discussed in my last  column was 	Amazon’s iPhone app. Figure 1 shows its search results screen.</p>
<p>Figure 1—Faceted search in Amazon’s  iPhone app</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/04/images/figure_1_amazon_mobile.png" alt="Faceted search in Amazon’s iPhone app" width="473" height="327" /></p>
<p>On the Web, Amazon’s faceted search is nothing short of 	gold standard, so comparing their Web faceted-search experience to that  of 	their iPhone app is instructive. Looking at the Amazon iPhone 	app in Figure 1, the first 	thing to note is the amount of screen real estate Amazon has devoted to  things 	other than search results. Their fairly standard iPhone page layout has  a 	navigation bar at the top and a tab bar at the bottom, which together  take 	up about 74 pixels. In all, Amazon has permanently devoted almost 22%  of 	their precious screen real estate to navigation and other features. As a  consequence, 	they can display <em>only</em> three search 	results at a time. And Amazon is actually fairly frugal with its screen  real 	estate—at 	least in comparison to other mobile ecommerce applications.</p>
<p>Another interesting issue is that the user’s keyword  query—in 		this case, <em>green 	lantern</em>—does <em>not</em> appear in its entirety in the  application’s navigation bar—both 	because the user interface displays the query in a really large font  and 	because the query text has to compete with a large search refinement  button 	that is also  on the navigation bar. With the screen‘s limited real  estate, 	the query gets cut off, allowing only <em>green…</em> to appear there.</p>
<p>Last, but not least, the only search refinement Amazon 		presents to customers is <strong>By Category</strong>—a button that  takes 		a customer to a different category-selection screen. While <em>category</em> is 		definitely one of the most useful and frequently applied facets,  offering 		category selection alone hardly compares to the rich array of  search-refinement 		options that is available on Amazon’s Web site, as shown in Figure 2. 		Conspicuously absent are various sorting options, as well as filtering 		by price.</p>
<p>Figure 2—Search on Amazon’s Web site  presents many refinement options</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/04/images/figure_2_amazon_web.png" alt="Search on Amazon's Web site" width="467" height="360" /></p>
<p>However, in these screenshots, you cannot see one of  the most important and 	striking differences between search on the Web and on mobile devices,  which 	you can understand <em>only</em> in terms of the app’s  search-refinement flow. Figure 	3 illustrates the differences between Amazon’s Web and mobile  search-refinement 	flows.</p>
<p>Figure 3—The differences between the  Web and mobile search-refinement flows</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/04/images/figure_3_amazon_flows.png" alt="Differences between Web and mobile" width="460" height="160" /></p>
<p>On the Web, Amazon’s search supports progressive,  faceted search refinement 	and exploration as one of its primary goals for the search process. As  Peter 	Morville said in his brilliant book, <em>Search Patterns</em>, “Faceted 	navigation 	… helps us learn. Search becomes an iterative, interactive experience 	where what we find changes what we seek.” For example, on the Web, a  customer 	who starts with the keyword query <em>Nike</em> can narrow down the  search results 	by category (Shoes), additional keywords (<em>Nike Air</em>), product  type (Cross 	Training), and size (12).</p>
<p>In contrast, Amazon’s iPhone app does <em>not</em> preserve search 	refinement as part of its finding flow. The customer who starts with  the 	keyword query <em>Nike</em>, then refines the results <strong>By  Category</strong> (Shoes) 	is unable to refine the results further. If a customer attempts to  refine 	a query by adding more keywords (<em>Nike Air</em>), the app removes  the customer’s 	prior category selection (Shoes), doing a completely new search for the  query <em>Nike Air</em> and searching <em>all</em> categories. This  behavior has the 	unfortunate effect of interrupting the flow of step-wise exploration  and 	discovery that is central to the faceted search experience. Obviously,  there 	is a real need for better patterns for the step-wise narrowing,  expanding, 	and refining of faceted search results on mobile devices.</p>
<p>Mobile faceted search needs to balance customers’ needs 	to both refine results and maintain their search-refinement flows  against 	the limited screen real estate and fat-finger issues. We must  especially 	guard against introducing false simple-mindedness in the name of <em>simplicity</em>. 	Simplicity is a great goal, but as John Maeda said in his masterful  book, 	<em>The Laws of Simplicity</em>, “Some 	things can never be made simple.” Using the words of Albert Einstein, 	we have to strive to make the most of the tools available to us and  make 	user interfaces “as simple as possible, 	but not simpler.” The four design patterns that follow make the most of 	the available screen real estate, while providing intuitive and useful  search-results 	refinement capabilities and improving the mobile faceted-search  experience.</p>
<h2>Four Corners and Modal Overlay Patterns</h2>
<p>As I described in my column “<a title="Search Results Satori: Balancing Pogosticking and Page  Relevance" href="http://www.uxmatters.com/mt/archives/2009/06/search-results-satori-balancing-pogosticking-and-page-relevance.php">Search 		Results Satori: Balancing Pogosticking and Page Relevance</a>,”  maximizing 		the number of results on a search results screen is key to improving  information 		scent and overall finding efficiency. One of the most successful  design patterns 		for maximizing the use of screen real estate is the Four Corners  pattern, shown 	in Figure 4.</p>
<p>Figure 4—Four Corners and Modal  Overlay patterns</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/04/images/figure_4_four_corners.jpg" alt="Four Corners and Modal Overlay patterns" width="473" height="332" /></p>
<p>The Four Corners pattern devotes almost the entire  mobile screen to search 	results. Users can display particular functions by tapping the  semitransparent 	corners, which provide access to filters, the home page, and two  additional 	menus. This pattern includes a thin, persistent status bar across the  top of the screen, which displays an entire search query, <em>plus</em> any  applied filters, 	rather than just the few characters Amazon Mobile displays in a large  font. 	Displaying an entire query is highly beneficial, given users’ mobile  context 	of use and the frequent interruptions inherent in the mobile finding  experience.</p>
<p>Although the design pattern is called <em>Four Corners</em> and 		triangles are the most effective shape for the corners, they don’t  necessarily have to be triangles. 	Other alternatives include semitransparent buttons or floating icons.  However, 	for transparent buttons, it’s best to keep icons simple and avoid text 	labels.</p>
<p>Another pattern that works really well with Four  Corners 		is the Modal Overlay pattern, shown on the right in Figure 4. A modal 	overlay can display various search-refinement options such as filtering  and 	sorting. As I wrote in “<a title="The Mystery of Filtering by Sorting" href="http://www.uxmatters.com/mt/archives/2009/07/the-mystery-of-filtering-by-sorting.php">The 	Mystery of Filtering by Sorting</a>,” it is <em>not</em> necessary to  place 	filtering and sorting in two different areas of a screen. Most people  have, 	at best, just a vague idea of the differences between the two features.  This 	is particularly true for the mobile experience, where screen real  estate 	is at a premium and minimizing the number of taps necessary to  achieving 	a goal is key.</p>
<p>The Four Corners and Modal Overlay patterns work  particularly well in combination. 	In Figure 4, each user interaction on the modal overlay refines the  search results 	interactively. This dynamic interaction model works great, because  users can 	always see where they are and what filters they have applied, and they  have 	easy access to further refinement options, all without ever leaving the  context 	of the search results screen.</p>
<p>Some touch phones—like the iPhone—do not provide 	an API (Application Programming Interface) for modal overlays, but  instead 	deliver content one screen at a time, with transitions between screens.  On 	such devices, you’ll need to fake modal 	overlays. You can achieve this effect by rendering the <em>same</em> search 	results on a new screen—this time with a slightly darkened  background—with 	a modal overlay over the results. When displaying this new screen, an  application 	should minimize any transition to help to preserve 	the illusion of maintaining the search results context.</p>
<h2>Watermark Pattern with the Full-Page Refinement Options  Pattern</h2>
<p>The latest generation of smartphones—including the Apple iPhone, Palm 	Pre, and Google Android—provides designers with a whole bevy of novel 	interaction models. Some of the ways in which people must interact with  new 	smartphones may not be obvious to them, because they may not match  their 	existing mental models or the affordances of devices with which they’re 	familiar. Nevertheless, once people discover these interactions, they  seem 	surprisingly intuitive and fun, and people do <em>not</em> easily  forget them.</p>
<p>In 	mobile computer games, it is common practice to teach players by  allowing 	them to manipulate their mobile devices through various gestures,  including 	tilting, turning, and shaking them—or even using a device’s  accelerometer 	to mimic the way one would use a magic wand: 	“Incendio!”</p>
<p>Figure 5—Fun ways of employing the  iPhone’s accelerometer in the <a title="Harry Potter game" href="http://www.wired.com/geekdad/2009/11/review-harry-potter-spells-iphone-app-is-magical-if-imperfect/">Harry 	Potter game</a><a title="Harry Potter game" href="http://www.wired.com/geekdad/2009/11/review-harry-potter-spells-iphone-app-is-magical-if-imperfect/"><img src="http://www.uxmatters.com/images/new-window-arrow.gif" alt="" width="14" height="12" /></a></p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/04/images/figure_5_harry_potter2.jpg" alt="Harry Potter game uses iPhone accelerometer" width="320" height="480" /></p>
<p>In ecommerce applications, customers’ object in  interacting 	with a mobile device is <em>not</em> typically entertainment, but the  efficient 	acquisition of goods, services, or information—so necessity typically 	shortens their learning curve. If we want people to be able to perform a 	nonstandard interaction to use a device’s 	essential features, the interaction must be fairly obvious—and it must 	<em>not</em> require them to read instructions they would perceive as 	obnoxious or distracting. This is where careful use of the Watermark  design 	pattern can be especially powerful.</p>
<p>A <em>watermark</em> is a transparent 	outline that appears either over or behind the primary content on a  screen. 	In some ways, a watermark is similar to a splash screen, but it is  considerably 	less distracting because watermarks let users see the content on the  screen 	at the same time. Figure 6 shows two variations of the Watermark  pattern, 	plus a full-screen example of a Refinement Options pattern.</p>
<p>Figure 6—Two variations of the  Watermark pattern and a Refinement Options 	pattern</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/04/images/figure_6_splash_screen.jpg" alt="Variations of Watermark and Refinement Options patterns" width="473" height="656" /></p>
<p>The two examples of the Watermark pattern, shown in  Figure 6, 	demonstrate a circular swiping gesture and a shaking gesture on 	a multitouch device. In both cases, 	once a user launches an application, each watermark appears just once  or 	twice, gently dissolving to let the user view the screen’s 	main content. Watermarks can  also use animation—for 	example, to demonstrate the motion of the circular swipe by displaying  one 	arrow at a time on the screen. However, animation greatly increases a  watermark’s 	visibility, so you should use it with care. Circular swiping emulates  the 	motion of digging into a pile of puzzle pieces to find the right one,  while 	shaking recalls the action of shaking up small, loose objects in a bag  or 	a box.</p>
<p>In each case, the idea behind the watermark is to  educate or 	remind people about the gesture or interaction that is necessary to  view 	a screen containing additional search-refinement features. Once people  decide 	to dig in further or shake up their search results, the application  displays 	a full screen of refinement options, as shown at the bottom of Figure  6. 	This screen provides an example of the Refinement Options pattern.  Again, the 	thin, persistent status bar across the top of the screen shows the  query. Together 	with the watermark, this helps maximize the real estate the screen can  devote 	to search results, while making exploration intuitive.</p>
<p>With a full screen of refinement options, a user can  view four 	or five of the most popular values for each of the facets and select a  facet 	value with a single tap. This is almost like having the entire array of  refinement 	options on a typical faceted search results Web page. Having the search  box 	integrated into the refinement options page also re-enforces the idea  of 	applying search query terms and facets together as a set, just as they  are 	on a Web page. Together, these patterns let us duplicate the intuitive  and 	efficient step-wise refinement and expansion flow our customers expect  from 	a faceted search results page on an ecommerce site. Using a scrollable  screen 	of facets rather than a 	modal overlay like that shown in Figure 4 allows us to devote the full 	screen width to the search results, sprucing them up with icons for  popular 	refinement options and letting customers refine the results with fewer  taps.</p>
<p>Does this mean presenting a full page of refinement  options 	is better than a modal overlay? Not at all. A modal overlay displays  its 	refinement options within the context of the search results, while  displaying 	a separate results-refinement screen, along with its associated  transition, 	yanks customers out of the search-results context and presents what  some 	people might think is an overwhelming variety of refinement options.</p>
<p>When discussing design patterns, avoid getting caught  up in 	judging one pattern to be better than another. Each pattern is useful  in 	specific contexts and applications and for particular purposes and  types 	of customers. Design patterns are like a language we can use to  communicate 	with our customers. It helps to have a vocabulary of patterns that is  as 	complete and varied as possible, as well as to use each pattern  appropriately 	to communicate your design message with clarity and precision.<a title="Top" href="http://www.uxmatters.com/mt/archives/2010/04/design-patterns-for-mobile-faceted-search-part-i.php#top"><img src="http://www.uxmatters.com/images/ux-bug.gif" alt="" width="18" height="18" /></a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.designcaffeine.com/2010/articles/348/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Designing Mobile Search: Turning Limitations into Opportunities</title>
		<link>http://www.designcaffeine.com/2010/articles/337/</link>
		<comments>http://www.designcaffeine.com/2010/articles/337/#comments</comments>
		<pubDate>Tue, 09 Mar 2010 05:46:32 +0000</pubDate>
		<dc:creator>Greg Nudelman</dc:creator>
				<category><![CDATA[Articles]]></category>
		<category><![CDATA[Finding]]></category>
		<category><![CDATA[iPhone]]></category>
		<category><![CDATA[iPhone App]]></category>
		<category><![CDATA[Mobile]]></category>
		<category><![CDATA[Search Matters]]></category>
		<category><![CDATA[Search Results]]></category>
		<category><![CDATA[ThirstyPocket]]></category>
		<category><![CDATA[Usability]]></category>
		<category><![CDATA[UX Design]]></category>

		<guid isPermaLink="false">http://www.designcaffeine.com/?p=337</guid>
		<description><![CDATA[Originally Published on UXmatters.com March 8, 2010 ⇒
Thinking of porting your Web finding experience to iPhone, Android, or Windows 	Mobile? Just forget about the fact that these devices are basically full-featured 	computers with tiny screens. Having gone through this  design exercise 	a few times, I have realized that designing a great mobile finding experience [...]]]></description>
			<content:encoded><![CDATA[<p><a title="Read this article on UXmatters (Opens in a New Window)" href="http://www.uxmatters.com/mt/archives/2010/03/designing-mobile-search-turning-limitations-into-opportunities.php" target="_blank">Originally Published on UXmatters.com March 8, 2010 ⇒</a></p>
<p>Thinking of porting your Web finding experience to iPhone, Android, or Windows 	Mobile? Just forget about the fact that these devices are basically full-featured 	computers with tiny screens. Having gone through this  design exercise 	a few times, I have realized that designing a great mobile finding experience 	requires a way of thinking that is quite different from our typical approach 	to designing search for Web or desktop applications. To put it simply, designing 	a mobile finding experience requires thinking in terms of turning limitations 	into opportunities. In this column, I’ll discuss some of the limitations 	of mobile platforms, as well as the opportunities they afford, and share 	a few design ideas that might come in handy for your own projects.<br />
<span id="more-337"></span></p>
<h2>Understanding Mobile Platforms</h2>
<p>One of the challenges of mobile application design is understanding  both the 	capabilities <em>and</em> limitations of each platform. Let’s use the 	iPhone finding experience as an example. On the plus side, the iPhone  has 	a high-resolution screen, Multi-Touch controls, accelerometer,  persistent 	data storage, cool video transitions, push content delivery, GPS, and a  device 	ID. The benefits of these features have been pretty much beaten to  death 	in advertisements, so I will <em>not</em> discuss them here. On the  other hand, 	the problem constraints and limitations of mobile devices are much more  interesting. I have found few sources that discuss these in detail, so  in this column, 	I’ll attempt to describe the most important challenges of designing for  the new generation of smartphones—at least as they pertain to finding:</p>
<ul>
<li>the difficulty of typing</li>
<li>the small amount of screen real estate</li>
<li>awkward touch controls</li>
<li>the so-called <em>fat-finger problem</em></li>
</ul>
<h3>The Difficulty of Typing</h3>
<p>Searching requires users to type a search string, and typing on a  mobile 	phone is  difficult—partly because of the size of the device. In a 	July 2009 blog post on <em>Alertbox</em>, Jakob Nielsen called the  mobile experience “miserable” 	and reported, “Text entry is particularly slow and littered with typos, 	even on devices with dedicated mini-keyboards.”</p>
<p>For many users, touch 	devices like the iPhone exacerbate this problem. Their 	screens display a virtual keyboard and other buttons. One issue with  touch 	devices   is poor visibility, because a user’s fingers 	must, by necessity, cover buttons on the screen when a user is pushing  them. 	Thus, when pushing a button on a virtual keyboard, a user’s 	hand obscures his view of the keyboard.</p>
<p>The lack of tactile response on touch 	devices presents a particular problem when a user is  multitasking—whether 	riding in taxi, using public transportation, or walking down a city  street. 	On <em>any</em> mobile device, it’s very difficult to type when a  person is crammed 	into a bus or subway car and being jostled around. A user’s desire to 	avoid typing becomes a necessity when using a mobile device while 	driving.</p>
<p>Another challenge users encounter when searching on  smartphones is that they’re 	likely to lose anything they’ve laboriously typed into a search box if a  device 	receives an incoming phone call, because mobile applications cannot  block phone 	functions. Nor should an application, however useful, be able to  prevent a user 	from receiving incoming calls.</p>
<h3>The Small Amount of Screen Real Estate</h3>
<p>Mobile screens are, by necessity, small, because a mobile device has  to fit 	into a person’s pocket or purse. The small size of mobile screens  limits 	the number of controls and the amount of content that can appear on  them. 	In that <em>Alertbox</em> post 	I mentioned earlier, Jakob Nielsen reported, “Unsurprisingly, the  bigger 	the screen, the better the user experience.” According to Nielsen,  users’ success 	rates with touch phones like the iPhone are about double their success  rates 	with feature phones.</p>
<h3>Awkward Touch Controls</h3>
<p>One of the consequences of mobile devices’ having smaller screens and 	controls that users must manipulate through touch interfaces is that  some 	controls no longer look like their Web and desktop counterparts. For  example, 	rather than the usual drop-down list or set of option buttons, the  selection 	control on an iPhone is instead a spinning control called a <em>picker</em>, 	shown in Figure 1.</p>
<p>Figure 1—Three pickers in the Urban  Spoon iPhone app</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/03/images/figure_1_urbanspoon.jpg" alt="Pickers in the Urban Spoon iPhone app" width="320" height="460" /></p>
<p>A picker that a user can quickly manipulate with a  finger eats up precious 	real estate, so it’s not possible to show users much outside the  picker. Large 	pickers also place limitations on how users can filter search results  on mobile 	devices. Similar size restrictions exist for <em>all</em> of an  application’s touch controls.</p>
<h3>The Fat-Finger Problem</h3>
<p>The high-resolution screens on better mobile devices—like the iPhone,  Android, 	and Palm Pre—can accommodate fairly high information density.  Unfortunately, 	at the same time, touchscreens <em>limit</em> the on-screen density of  controls that 	users can accurately manipulate with a finger. Thus, placing multiple  controls 	close together on a touchscreen mobile device presents difficulties.  This challenge 	is known as the <em>fat-finger problem</em>.</p>
<p>Typically, an iPhone touchscreen can comfortably  support a maximum 	 of only three to five clickable buttons or tabs across a screen. More  than 	this leads to frequent frustrations due to users’ inadvertently  pressing 	the wrong control. While five controls across a screen is the absolute  limit 	for relatively frustration-free mobile computing for people with  relatively 	small fingers, I highly recommend a limit of four or fewer controls. Of  course, 	if one control is bigger than the others, you’ll 	have to reduce the overall number of controls accordingly. For example,  Figure 	2 shows the Yelp mobile application, which has only three controls  across 	the navigation bar at top of the screen, but four controls across tab  bar 	at the bottom.</p>
<p>Figure 2—Yelp iPhone app</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/03/images/figure_2_yelp.png" alt="Yelp iPhone app" width="327" height="490" /></p>
<p>Because Yelp’s search box takes up a large part of the  navigation 	bar, the designers had to reduce the overall number of controls to  three 	to ensure users’ wouldn’t 	press the wrong controls with their fingers too often.</p>
<h2>Understanding User Experience within a Mobile Context of Use</h2>
<p>The challenge in designing mobile applications is the need to  accommodate 	the design constraints and usability challenges mobile devices impose,  while 	focusing on users’ goals within a mobile context of use. Simply 	duplicating the functionality of a Web application—while trying to work 	around the mobile design challenges I’ve described—<em>always</em> results 	in a subpar mobile application. It’s not enough to think: <em>How 	can I duplicate our Web application’s user experience within the  limitations 	of the mobile platform?</em> Instead, it’s better to start from  scratch, focusing 	on <em>What experience would work best for mobile users?</em> Putting  users’ goals 	first allows a design team to concentrate on the new opportunities a  mobile 	application presents rather than seeing the challenges of mobile simply  as 	barriers to implementing a Web application’s existing functionality.</p>
<p>Next, I’ll present some ideas about how to approach the 	design of finding experiences for mobile devices in a way that lends  itself 	to taking full advantage of their capabilities within a 	mobile context of use. These ideas by no means represent an exhaustive  catalog 	of all possibilities. I merely want to provide a few examples that may  inspire 	further exploration as part of your own finding projects.</p>
<h3>Preloading Pertinent Search Results</h3>
<p>As I discussed earlier, typing on mobile devices is difficult. Plus, a  phone 	call, a text message, or an opportunity to take a picture is likely to  interrupt 	a user’s finding experience at least once. Saving a user’s previous 	searches is an obvious and simple way of re-engaging users in a finding  task 	and provides useful context when an application first opens.</p>
<p>Unlike Web applications, 	native mobile applications are persistent, so it’s easy to cache their 	search results. Cached results load quickly, users’ re-engagement is  immediate, 	and there is little to compete for a user’s attention—that is, at 	least until another phone call comes in. Some mobile device APIs even  enable 	native applications to detect whether a phone call interrupted a user’s 	previous session or the user exited an application normally and  determine 	how much time has elapsed since a user last opened the application.  These 	capabilities present interesting possibilities for fine-tuning an  application’s 	welcome-back screen to re-immerse users in their previous tasks or  offer 	pertinent new content and present new possibilities for interaction.</p>
<h3>Providing Local Results</h3>
<p>On mobile devices that support GPS, Wi-Fi, or other location-tracking  mechanisms, 	you can determine the current location of  another person who is using a 	mobile device, allowing applications to offer location-aware services.  Mobile 	applications with search capabilities can serve highly relevant, fresh  results 	that perfectly match a user’s 	current mobile context. For example, Loopt is just one of a whole cadre  of 	social networking mobile applications that allow users to track the  locations 	of their friends who are currently nearby and exchange messages with  them, 	get coupons from local merchants, and discover neighborhood happenings, 	as Figure 3 shows.</p>
<p>Figure 3—Local search results in the 	Loopt iPhone app</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/03/images/figure_3_loopt2.png" alt="Local search results in Loopt iPhone app" width="320" height="977" /></p>
<h3>Offering a Value-Added Interpretation of the Real World</h3>
<p>Using mobile devices for sense-making in the real world offers one of  the 	most intriguing possibilities for mobile applications. Luke Wroblewski  described 	some interesting possibilities, including augmented reality  applications, 	in his <em>Smashing Magazine</em> article “Enhancing User Interaction 	with First Person User Interface.”</p>
<p>When it comes to finding, however, 	the Amazon Mobile iPhone app offers the <strong>Amazon Remembers</strong> feature, which is 	a forerunner of many exciting things to come. Amazon Mobile lets  customers 	take pictures of any real world items and add them to their lists of  things 	to remember. Once a user uploads a photo, Amazon figures out what the  item 	is and, if there is a corresponding item available for sale on Amazon,  displays 	that item and sends the customer an email alert, encouraging her to  purchase 	the item. Customers often get a response in a matter of minutes, but  the 	search can take up to 24 hours. This application lays a solid  foundation for 	the idea of a mobile Internet of objects that I described in one of my  previous 	columns, “<a title="Brave New World of Visual Browsing" href="http://www.uxmatters.com/mt/archives/2009/08/brave-new-world-of-visual-browsing.php">Brave 	New World of Visual Browsing</a>.”</p>
<h3>Providing Various Sorting Options</h3>
<p>As I previously mentioned in my column “<a title="The Mystery of Filtering by Sorting" href="http://www.uxmatters.com/mt/archives/2009/07/the-mystery-of-filtering-by-sorting.php">The 		Mystery of Filtering by Sorting</a>,” 	sorting options are an excellent way of opening up an ecommerce site’s 	inventory for browsing. One of the best ways of doing this is to  provide 	two or more buttons on a search results screen that allow multiple ways  of 	dissecting an inventory, without ever failing to serve <em>some</em> results. 	By using sorting options together with geolocation, customers can even  avoid 	having to type in 	<em>any</em> query at all. As Figure 4 shows, the ThirstyPocket iPhone  app lets 	customers simply press the <strong>Search Nearest</strong> or <strong>Search  	Newest</strong> button to see 	a sample of local results without having to type anything in the search  box.</p>
<p>Figure 4—ThirstyPocket iPhone app</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/03/images/figure_4_thirstyPocket.jpg" alt="ThirstyPocket iPhone app" width="320" height="480" /></p>
<p>Of course, a customer can always type keywords in a  search box 	to narrow down the results. As I explained in my <a title="presentation" href="http://www.slideshare.net/gnudelman/experience-design-for-a-viral-mobile-community">presentation</a><a title="presentation" href="http://www.slideshare.net/gnudelman/experience-design-for-a-viral-mobile-community"><img src="http://www.uxmatters.com/images/new-window-arrow.gif" alt="" width="14" height="12" /></a> at 	the Net Squared Conference in May 2009, using this design pattern lets  customers 	engage with an inventory of items or content immediately, then invest  the 	effort of typing in keywords once they have caught the scent of  something 	that interests them or to refine the search results further. Of course,  given 	the fat-finger problem and a mobile device’s limited screen real 	estate, we can’t provide more 	than three to five sort options on the screen at one time. However, as  the 	ThirstyPocket example shows, even a couple of sort options is often  enough 	for customers to begin exploring.</p>
<h3>Considering Custom Controls</h3>
<p>One consequence of mobile devices’ having a smaller screen is <em>not</em> having 	the space to create a navigation bar of filters, facets, or categories  on 	the left, providing a key to the properties by which a user can  effectively 	narrow down a result set. Consider, for example, the all-important  category 	filter. If an application were to use the standard iPhone picker, shown  in 	Figure 1, it would obscure most of the search results on the screen.  Various 	applications deal with this challenge in different ways. Some mobile  applications 	have created custom category-filter controls—like those in Amazon  Mobile, 	shown in Figure 5.</p>
<p>Figure 5—Custom category-filter  controls in Amazon Mobile</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/03/images/figure_5_amazon_categories2.png" alt="Amazon Mobile category filters" width="474" height="340" /></p>
<p>Clicking <strong>By Category</strong> takes a customer  to a different, full-sized screen on 	which he can select a category. The ThirstyPocket application, shown in  Figure 	4, uses the same principle for its custom category selector, with an  added twist: 	the visual design of the category selector is reminiscent of the  familiar drop-down 	list, taking full advantage of customers’ existing mental model and  helping 	them understand what behavior to expect.</p>
<h2>Changing Search Paradigms</h2>
<p>Because of the unique mix of constraints and opportunities that  mobile application 	design presents, this design space is rich with possibilities for  changing 	the existing paradigms for search and finding. Consider speech  recognition, 	for example. While, on the desktop, speech recognition does not yet  enjoy 	widespread popularity and use, mobile represents an entirely different  context—where 	speech recognition can offer an ideal solution. Not interpreting a  spoken 	word correctly on a mobile device might not be quite as big a deal as  it 	is on the desktop, because the accuracy of speech recognition may  actually 	approach, if not exceed, that of typing on a mobile phone’s awkward  mini-keyboard. 	Combine speech recognition with the use of an accelerometer and  magnetometer, 	allowing gestural input, and you have the Google Mobile search  application 	for the iPhone, shown in Figures 6 and 7.</p>
<p>Figure 6—Google Mobile iPhone app</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/03/images/figure_6_google_mobile.png" alt="Google Mobile iPhone app" width="320" height="480" /></p>
<p>Figure 7—Google Mobile Voice Search  on the iPhone</p>
<p><object width="474" height="380" alt="Google Mobile Voice Search on the  iPhone"><param name="movie" value="http://www.youtube.com/v/y3z7Tw1K17A&amp;hl=en_US&amp;fs=1&amp;" /><param name="allowFullScreen" value="true" /><param name="allowscriptaccess" value="always" /><embed type="application/x-shockwave-flash" width="474" height="380" src="http://www.youtube.com/v/y3z7Tw1K17A&amp;hl=en_US&amp;fs=1&amp;" allowscriptaccess="always" allowfullscreen="true"></embed></object></p>
<p>The iPhone application Google Mobile recognizes the  		gesture of a person’s swinging the phone up to his ear to know when to 	record a search command. When the user speaks, the search engine  accepts 		and interprets his voice commands, then serves up search results. This 		user interface implements what is literally a game-changing design  paradigm, 		because its designers have taken the time to truly consider the mobile 		context of use and map natural interactions like speech and gestures 		to mobile device functions. As Peter Morville said in his book <em>Search  		Patterns</em>, “We 		simply raise our phones to our ears and speak our search, relying on 		Google Mobile to derive what we want from who we are, where we stand, 		and what we say…. Like placing your hands under a tap to turn on the 		water, this is the type of smart design that ‘dissolves in behavior’.”</p>
<p>When it comes to designing for a mobile context, we are 		just starting to scratch the surface. As Tom Chi of <em>OK/Cancel</em> famously quipped 		in his interview with Luke Wroblewski, “A well defined-and exciting  problem (and its associated constraints) 	is the catalyst that makes design go.” When we stop thinking about the 	limitations of mobile platforms and, instead, truly focus on the user  goals 	we are working to support, we might just find those limitations turning  into 	opportunities for redefining how people find, remember, and discover  things 	in their world.<a title="Top" href="http://www.uxmatters.com/mt/archives/2010/03/designing-mobile-search-turning-limitations-into-opportunities.php#top"><img src="http://www.uxmatters.com/images/ux-bug.gif" alt="" width="18" height="18" /></a></p>
<h4>References</h4>
<p>Morville, Peter. <em>Search Patterns</em>.  Sebastopol, 	CA: O’Reilly, 2010.</p>
<p>Nielsen, Jakob. “<a title="Mobile  Usability" href="http://www.useit.com/alertbox/mobile-usability.html">Mobile 		Usability</a>.”<a title="Mobile  Usability" href="http://www.useit.com/alertbox/mobile-usability.html"><img src="http://www.uxmatters.com/images/new-window-arrow.gif" alt="" width="14" height="12" /></a> <em>Alertbox</em>, July  20, 2009. 	Retrieved February 27, 2010.</p>
<p>Wroblewski, Luke. “<a title="Enhancing User Interaction With First Person User Interface" href="http://www.smashingmagazine.com/2009/09/21/enhancing-user-interaction-with-first-person-user-interface/">Enhancing  User Interaction With First Person User Interface</a>.”<a title="Enhancing User Interaction With First Person User Interface" href="http://www.smashingmagazine.com/2009/09/21/enhancing-user-interaction-with-first-person-user-interface/"><img src="http://www.uxmatters.com/images/new-window-arrow.gif" alt="" width="14" height="12" /></a> <em>Smashing Magazine</em>, September 21, 2009. Retrieved February 27,  2010.</p>
<p>Wroblewski, Luke. “<a title="Defining the  Problem: Q&amp;A with Tom Chi" href="http://www.lukew.com/ff/entry.asp?336">Defining 	the Problem: Q&amp;A with Tom Chi</a>.”<a title="Defining the  Problem: Q&amp;A with Tom Chi" href="http://www.lukew.com/ff/entry.asp?336"><img src="http://www.uxmatters.com/images/new-window-arrow.gif" alt="" width="14" height="12" /></a> <em>Functioning Form</em>,  April 27, 2006. Retrieved February 27, 2010.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.designcaffeine.com/2010/articles/337/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Numeric Filters: Issues and Best Practices</title>
		<link>http://www.designcaffeine.com/2010/articles/321/</link>
		<comments>http://www.designcaffeine.com/2010/articles/321/#comments</comments>
		<pubDate>Mon, 08 Feb 2010 18:34:44 +0000</pubDate>
		<dc:creator>Greg Nudelman</dc:creator>
				<category><![CDATA[Articles]]></category>
		<category><![CDATA[Article]]></category>
		<category><![CDATA[Filters]]></category>
		<category><![CDATA[Finding]]></category>
		<category><![CDATA[Search Matters]]></category>
		<category><![CDATA[Search Results]]></category>
		<category><![CDATA[Usability]]></category>

		<guid isPermaLink="false">http://www.designcaffeine.com/?p=321</guid>
		<description><![CDATA[Originally published on UXMatters.com February 8, 2010 ⇒
Faceted search has been around for a long time and has become the de facto 	standard for search on most ecommerce sites. However, filters with numeric values 	remain among the most confusing, because many sites have not able to design 	usable numeric filters that people can use in [...]]]></description>
			<content:encoded><![CDATA[<p><a title="Read this article on UXMatters (Opens in a New Window)" href="http://www.uxmatters.com/mt/archives/2010/02/numeric-filters-issues-and-best-practices.php" target="_blank">Originally published on UXMatters.com February 8, 2010 ⇒</a></p>
<p>Faceted search has been around for a long time and has become the de facto 	standard for search on most ecommerce sites. However, filters with numeric values 	remain among the most confusing, because many sites have <em>not</em> able to design 	usable numeric filters that people can use in an intuitive manner. Recently, 	powerful user interface controls called <em>sliders</em> have become all the rage for 	specifying numeric attributes in finding user interfaces. Unfortunately, in 	their rush to implement this latest, greatest feature, many companies have <em>not</em> designed easy-to-use sliders. Rather than solving usability problems, poorly 	designed sliders create even more issues around numeric filter usability. In 	my experience, the following three usability issues surface most often with 	numeric filters:</p>
<ul>
<li>representing discrete values for aspects as sets of ranges</li>
<li>inadvertently emphasizing overly constrained filter states</li>
<li>being parsimonious with inventory information</li>
</ul>
<p>In this column, I’ll examine each of these issues and present 	the best practices that solve these problems. <a title="Link" href="http://www.uxmatters.com/mt/archives/2010/02/numeric-filters-issues-and-best-practices.php"></a><br />
<span id="more-321"></span></p>
<h2>Representing Discrete Values for Aspects as Sets of Ranges</h2>
<p>One of the most common pitfalls with numeric aspect filters is their representing 	discrete values as sets of ranges. What makes a filter value discrete? Certain 	types of products typically have widely recognized, discrete values—for example, 	a digital camera might have a 10MP resolution and a lens with 3X zoom—which 	can often consist of either whole numbers or fractions. These discrete values 	tend to be consistent across competing brands and models and rarely change 	from one vendor to the next.</p>
<p>Many sites offering faceted search do <em>not</em> present discrete numeric values 	for aspect filters in the most useful fashion. Designers are often tempted to 	present such values to customers as sets of ranges. Presenting discrete filter 	values as a set of ranges typically results in a user interface similar to that 	in Figure 1, showing a camera-resolution filter on a major ecommerce site.</p>
<p>Figure 1—Camera-resolution filter with values presented as a set of ranges</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/02/images/Figure_1_ranges.png" alt="Set of ranges" width="188" height="182" /></p>
<p>My usability studies have shown that many people have trouble finding <em>10MP</em> within a <em>9.9MP-11.9MP</em> range and applying the filter correctly. The problem is 	a mental model mismatch. People don’t think of <em>10MP</em> as falling within some range. 	When customers look for discrete values in aspect filters, they are most often 	looking for a specific value—for example, <em>10MP</em>—that forms a critical part of 	the information scent. Most people typically think of a camera resolution as 	a specific value—<em>not</em> as a numeric value within some range.</p>
<div></div>
<p><!-- End pullquote -->When users try to look for the value <em>10MP</em> within a 	range, usability problems arise, because the resolutions <em>9.9MP</em> and <em>11.9MP</em> simply 	do <em>not</em> exist as discrete 	values. While, numerically, it is true that <em>10MP</em> lies within 	a <em>9.9MP-11.9MP</em> range, this range has very poor information scent and 	requires additional thinking and interpretation on the part of users, which 	does <em>not</em> make for intuitive and efficient finding. Having to think 	hard just to find something causes problems for users.</p>
<p>In my user research, 	I have often observed that people who are in a rush, distracted, or simply 	not that great at working with fractions in math often select the wrong range 	of discrete values, wonder <em>why</em> they are not getting the results they expected, 	get frustrated, and quickly leave a site to navigate to a more usable one.</p>
<p>Instead of providing ranges, it is much more effective to 	present lists of discrete values, showing <em>all</em> of the possible values 	for an aspect filter. If doing this results in a filter with too many options, 	simply rounding off the value to <em>around 10MP</em> works very well, as shown 	in Figure 2. (Note that the word <em>around</em> is usually implied. Although 	it sometimes shows up in a short form such as <em>~10MP</em> or <em>10+MP</em>. 	However, this extra precision is usually unnecessary, as I will explain 	in a future column.)</p>
<p>Figure 2—Recommended redesign of camera-resolution filter</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/02/images/Figure_2_recommended_mpx2.png" alt="Recommended redesign" width="474" height="216" /></p>
<p>When a customer clicks a link representing a discrete 	value, one option is to expand a list of subvalues—for example, clicking 	an <em>around 10MP</em> link would show all of the available subvalues: <strong>10.0MP</strong>, <strong>10.2MP</strong>, 	<strong>10.3MP</strong>, <strong>10.4MP</strong>, as shown in Figure 2A. Should 	you bother designing and implementing this? Usually not. Unless your customers 	are professionals who might be looking for a particular value, they typically 	would <em>not</em> drill down past the <em>around 10MP</em> link. Is there really 	that much difference between digital-camera resolutions of 10.2MP and 10.3MP 	to a typical consumer? So, unless your company’s inventory is extremely 	large or you have a very specialized clientele, it is often much more useful 	to present an approximate value like <strong>10MP</strong>.</p>
<p>Should you support single or multiple selection for displaying 		discrete filter values? The answer is always: <em>It depends</em>. Up until 		a few years ago, guidelines generally recommended the simplicity of single-selection 		links for discrete values. Today, however, I highly recommend that my 		clients implement multiple selection for discrete filter values—provided 		the finding user interface also supports multiple selection. Mark Burrell 		of Endeca echoed this sentiment in the 2010 UIE Webinar, “<a title="Leveraging Search &amp; Discovery Patterns for Great Online Experiences" href="http://www.uie.com/events/virtual_seminars/search_patterns/">Leveraging Search &amp; Discovery Patterns for Great Online Experiences</a>,”<a title="Leveraging Search &amp; Discovery Patterns for Great Online Experiences" href="http://www.uie.com/events/virtual_seminars/search_patterns/"><img src="http://www.uxmatters.com/images/new-window-arrow.gif" alt="" width="14" height="12" /></a> in 		which he emphasized that most ecommerce customers no longer find multiple 		selection hard to use and prefer the flexibility it offers.</p>
<h2>Numeric Sliders for Filters</h2>
<p>Numeric sliders have recently become the rage for faceted search. Sliders 	can add a touch of interactive fun to what many business people refer to as 	<em>a boring finding interface</em>. Note that boring user interfaces usually work extremely 	well, because they are intuitive and easy to use, and UX powerhouses like Amazon 	and Netflix do quite well without any sliders whatsoever.</p>
<p>That said, sliders <em>can</em> be helpful in some applications, because 	they give people tremendous filtering power when they are implemented correctly. 	With great power, however, comes great responsibility: Sliders deserve special 	consideration from designers—<em>precisely</em> because they make it <em>so</em> easy for your 	customers to screw up and overconstrain their queries, leading to search 	results that are either incorrect or of poor quality. This, in turn, results 	in frustrated customers who leave your Web site quickly without buying anything. 	The two issues I see most often with sliders are:</p>
<ul>
<li>inadvertently emphasizing overconstrained filter states</li>
<li>being parsimonious with inventory information</li>
</ul>
<p>Let’s take a closer look at each of these issues and what we can do about 	them.</p>
<h3>Issue: Inadvertently Emphasizing Overconstrained Filter States</h3>
<p>To examine the issue of overconstrained filter states, let’s take a look at 	an example—the slider rating control on TripAdvisor, shown in Figure 	3. Ratings seem deceptively simple, yet raise a host of usability issues 	when they are implemented incorrectly.</p>
<p>Figure 3—Slider rating control on TripAdvisor</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/02/images/Figure_3_tripadvisor_rating.png" alt="Slider rating control" width="160" height="101" /></p>
<p>TripAdvisor has implemented ratings using a <em>double</em> slider 	control, which presents a perfect example of inadvertently emphasizing overconstrained 	filter states. This double slider control allows a wide variety of ranges—some 	of which are much more useful than others when it comes to finding particular 	items or content of interest. For example, rating ranges spanning <em>only</em> a 	single star—such as <em>0-1 stars, 1-2 stars,</em> or <em>2-3 stars</em>—are 	simply <em>not</em> useful, 	because short ranges do <em>not</em> match the mental model of the people using 	the system.</p>
<p><!-- End pullquote -->Most of the time, people click a rating filter to get <em>all</em> of 	the merchandise <em>above</em> a certain rating—that is, as a way to find higher-quality 	items in their search results. However, a double slider control <em>overemphasizes</em> the ability to constrain the range from both sides, making it 	very easy to get this wrong by overconstraining a query.</p>
<p>A much more useful way of approaching this design problem is to use a single 	slider or a set of links like those shown in Figure 4, which shows ratings as 	they are currently implemented on Amazon.</p>
<p>Figure 4—Amazon’s more useful implementation of ratings as links</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/02/images/Figure_4_amazon_star_rating.png" alt="Amazon's ratings" width="200" height="117" /></p>
<p>We could further improve the rating control shown in Figure 	4. Since the goal of people using this  control is to get better-quality 	items, it is <em>not</em> actually that useful to show <em>only</em> a single star—the lowest 	possible rating. Instead, it might be more intuitive to replace the single 	star with the word <strong>Any</strong> and make that the default filter state. The filter 	shown in Figure 4 also has the important added advantage of providing vital 	inventory information. Item counts following each set of stars help people 	using the ratings filter to clearly understand the consequences of their 	actions and builds appropriate expectations. Understanding what to expect 	from their actions lets people be more efficient and effective, leading to 	higher customer satisfaction and better usability. Next, we’ll explore how we 	can use sliders to show inventory information.</p>
<h3>Issue: Being Parsimonious with Inventory Information</h3>
<p><!-- End pullquote -->Do <em>all</em> dual sliders emphasize overconstrained filter states? Not 	necessarily. For some filters dual sliders are entirely appropriate—for 	example, for price ranges. 	However, the problem  that I described earlier of overconstraining queries 	and, as a result, providing inadequate information never really goes away. 	As Figure 5 shows, the dual slider control for the price range filter on 	TripAdvisor provides no inventory information, so customers 	would have <em>no</em> idea what the effect of manipulating the sliders might 	be. Any 	action customers take might be a hit or a miss—but it is <em>never</em> clear 	in advance which it will be, because the system simply does <em>not</em> provide 	the necessary inventory information.</p>
<p>Figure 5—Dual-slider filter for price range on TripAdvisor</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/02/images/Figure_5_tripadvisor_price.png" alt="Dual-slider filter" width="160" height="106" /></p>
<p>Compare the dual slider for price range on TripAdvisor to the 	price control on Staples.com, pictured in Figure 6.</p>
<p>Figure 6—Price control on Staples.com with multiple check boxes</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/02/images/Figure_6_staples_price.png" alt="Price control" width="157" height="168" /></p>
<p>As I mentioned in one of my previous columns, “<a title="The Mystery of Filtering by Sorting" href="http://www.uxmatters.com/mt/archives/2009/07/the-mystery-of-filtering-by-sorting.php">The 		Mystery of Filtering by Sorting</a>,” overconstraining search results by price 		is one of the most common human errors we see in usability testing for 		search user interfaces. Which control would you expect to result in more 		overconstrained queries: a dual slider or a set of check boxes? The control 		that makes overconstraining results easier is the dual slider, because 		it gives <em>no</em> clue 		as to what to expect from a particular action. On the other hand, the 		dual slider provides the <em>bling</em> many business people crave as a means 		of differentiating their user interface from the competition.</p>
<p><!-- End pullquote -->In this age of highly interactive Ajax interfaces, clicking links or typing in numbers 	to specify a price range seems so old-fashioned. Is there a control that 	would provide the interactivity and fun of the slider, yet offer the inventory 	information so necessary to helping customers make informed decisions?</p>
<p>One approach would be to use a dual slider for setting a price 	range, combining it with a sparkline that graphically represents the available 	inventory information for every price in the range. Figure 7 depicts my 	suggested redesign of the TripAdvisor price filter, which combines a dual 	slider with a sparkline, showing the available inventory for each price in 	the range.</p>
<p>Figure 7—Suggested redesign of the price range filter on TripAdvisor</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/02/images/Figure_7_dual_slider_with_sparkline.png" alt="Redesigned price range filter" width="160" height="106" /></p>
<p>In his book <em>Beautiful Evidence, </em>Edward Tufte describes 	<em>sparklines</em> as “data-intense, 	design-simple, word-sized graphics.” Although I have no idea who first 	thought of combining a slider with a sparkline, I have been recommending 	this solution to my clients for over four years, and I can claim to have 	arrived at this idea independently. Unfortunately, so far, most of my fellow 	designers and the business people with whom I have worked have remained cold 	to this idea, stating that a slider with a sparkline would be “above and 		beyond what an average user could understand.” However, my own experience 	as a user researcher backs the opposite conclusion. Every usability test 	participant who has seen the user interface  in Figure 7 has confidently 		stated that he or she understood that the sparkline represented the number 		of items available, eloquently proving once again that “clarity and simplicity 		are completely opposite of simple-mindedness,” as Tufte said in his book <em>Envisioning 	Information</em>.</p>
<p>Recently,  during the UIE Webinar I mentioned earlier, I was 	supremely gratified to hear Mark Burrell of Endeca recommend dual sliders 	with histograms as one of the best ways of showing price ranges. Burrell’s 	experience with dual sliders was similar to mine: he said that most people have 	no trouble understanding that histogram bars—a step-wise variant of a sparkline—represent 	item inventory for each part of a slider’s range and that histograms clearly 	help people to avoid overconstraining their queries.</p>
<h2>In Conclusion</h2>
<p><!-- End pullquote -->In our age of rapid development, new ideas and new controls hit the Web almost 	every day. Even as companies are struggling to overcome the old challenges 	 of numeric faceted filters, designers are innovating interesting new controls 	with which they can solve those challenges. One such control is the slider, 	which gives unparalleled power to customers. However, successfully offering 	this power requires careful UX design in order to avoid potential pitfalls. 	Again, the following three issues with numeric filters surface most often:</p>
<ul>
<li>representing discrete values for aspects as sets of ranges</li>
<li>emphasizing overconstrained filter states</li>
<li>being parsimonious with inventory information</li>
</ul>
<p>Designers’ uninformed use of sliders for filters often 	exacerbates these issues. In this column, I have presented  best practices 	as well as some novel approaches to help designers overcome these challenges. 	But there is simply no substitute for empathy and solid qualitative 	user research. Understanding <em>why</em> customers 	do certain things is extremely important in designing effective user interfaces. 	No matter what metrics we have, we cannot improve our user interfaces 	unless we understand <em>what</em> our customers’ goals are and <em>why</em> people fail 	to reach them. With every new filtering innovation, it becomes ever more 	important to stay focused on our customers, with patience, empathy, and understanding.<a title="Top" href="http://www.uxmatters.com/mt/archives/2010/02/numeric-filters-issues-and-best-practices.php#top"><img src="http://www.uxmatters.com/images/ux-bug.gif" alt="" width="18" height="18" /></a></p>
<h4>References</h4>
<p>Morville, Peter, and Mark Burrell. “<a title="Leveraging Search &amp; Discovery Patterns for Great Online Experiences" href="http://www.uie.com/events/virtual_seminars/search_patterns/">Leveraging 			Search &amp; Discovery Patterns for Great Online Experiences</a>.”<a title="Leveraging Search &amp; Discovery Patterns for Great Online Experiences" href="http://www.uie.com/events/virtual_seminars/search_patterns/"><img src="http://www.uxmatters.com/images/new-window-arrow.gif" alt="" width="14" height="12" /></a> <em>UIE 			Virtual Seminar, </em>2010. Retrieved February 7, 2010.</p>
<p>Tufte, Edward. <em>Beautiful Evidence</em>. Cheshire, 		CT: Graphics Press, 2006.</p>
<p>—— <em>Envisioning Information</em>. 4th     ed. Cheshire, CT: Graphics Press, 1990.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.designcaffeine.com/2010/articles/321/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>More Like This: A Design Pattern</title>
		<link>http://www.designcaffeine.com/2010/articles/223/</link>
		<comments>http://www.designcaffeine.com/2010/articles/223/#comments</comments>
		<pubDate>Tue, 19 Jan 2010 22:43:26 +0000</pubDate>
		<dc:creator>Greg Nudelman</dc:creator>
				<category><![CDATA[Articles]]></category>
		<category><![CDATA[Browse]]></category>
		<category><![CDATA[Finding]]></category>
		<category><![CDATA[More Like This]]></category>
		<category><![CDATA[Query Disambiguation]]></category>
		<category><![CDATA[Search Matters]]></category>

		<guid isPermaLink="false">http://www.designcaffeine.com/?p=223</guid>
		<description><![CDATA[Originally Published on UXMatters.com January 4, 2010 ⇒
In my last installment of Search Matters, “Cameras, Music, and Mattresses: Designing Query Disambiguation Solutions for the Real World,” I presented several design strategies for query disambiguation.
Unfortunately, most sites do not make sufficient use of this pattern and some that do use it design and implement it incorrectly.
Show [...]]]></description>
			<content:encoded><![CDATA[<p><a title="Read this article on UXMatters (Opens in a New Window)" href="http://www.uxmatters.com/mt/archives/2010/01/more-like-this-a-design-pattern.php" target="_blank">Originally Published on UXMatters.com January 4, 2010 ⇒</a></p>
<p>In my last installment of <em>Search Matters</em>, “<a title="Cameras, Music, and Mattresses: Designing Query Disambiguation Solutions for the Real World," href="http://www.uxmatters.com/mt/archives/2009/12/cameras-music-and-mattresses-designing-query-disambiguation-solutions-for-the-real-world.php">Cameras, Music, and Mattresses: Designing Query Disambiguation Solutions for the Real World</a>,” I presented several design strategies for query disambiguation.</p>
<p>Unfortunately, most sites do <em>not</em> make sufficient use of this pattern and some that do use it design and implement it incorrectly.</p>
<h2>Show Me More</h2>
<p>The idea behind the <em>More Like This</em> pattern is very simple: within each group of items representing a particular category from a catalog or accompanying each item in search results, provide a prominent link or button with a label that is some variation of <strong>More Like This »</strong>. Of course, the devil, as they say, is in the details. <span id="more-223"></span>Figure 1 shows one of the more successful implementations of this pattern, the Amazon.com home page.</p>
<p>Figure 1—Amazon’s successful implementation of <em>More Like This</em></p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/01/images/Figure%201%20Amazon.gif" alt="Amazon's More Like This" width="471" height="783" /></p>
<p>On close examination, this design yields a few important lessons:</p>
<ul>
<li>Make group organization simple and obvious. Each group title should be prominent and simple, not inviting deep thought or much examination. The words and the color treatment of group titles should flow in a way that lets customers easily skim groups. Their titles exist to clearly separate various groups and direct the eye to the items they contain.</li>
<li>Focus on helping customers make decisions. Although the items in each group are themselves fairly relevant, the subtle focus of the whole page is <em>not</em> on finding <em>exactly</em> the right item on the current page, but instead on displaying some relevant entry points to an unfathomable cornucopia of relevant choices on Amazon.com that each group exemplifies.</li>
<li>Format groups differently from search results. The items in each group have a horizontal layout, in a gallery format, so it’s easy to differentiate them from the search results, which typically appear in a vertical list.</li>
</ul>
<p>The most important thing to keep in mind is that <em>all</em> of these design features support a single key goal: to help customers find what they want by providing the information scent and motivation that makes their navigational decisions easy and intuitive. Let’s examine what happens when sites ignore these lessons by looking at some other implementations of the <em>More Like This</em> design pattern.</p>
<h3>Make Group Organization Simple and Obvious</h3>
<p>Any cognitive friction around the organization and format of different groups makes navigational decisions more difficult. Instead of making decisions primarily on the basis of the information scent embedded in each group’s content, customers must try to understand <em>why</em> certain groups have a different format—a confusing and usually futile endeavor. Figure 2 shows one example of such an over-designed <em>More Like This</em> page, displaying search results for the query <em>Thai Restaurant San Francisco</em> on Yelp.com.</p>
<p>Figure 2—Yelp’s over-designed <em>More Like This</em> page</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/01/images/Figure%202%20Yelp.gif" alt="Yelp's More Like This page" width="469" height="778" /></p>
<p>The aim of this page is <em>not</em> to present <em>all</em> possible choices, but to help customers make a quick choice of the method that would best let them explore a bevy of Thai-food restaurant recommendations. Unfortunately, the purpose of the page is far from obvious. Observe that the page has no fewer than <em>seven</em> different groups, each with its own branding and formatting, in an overly complex, nonstandard layout. Together, all of these differences create a cacophony of results, making it very hard to compare the different groups without studying them in detail. Too much fancy formatting and too varied a layout hinders customers’ ability to make navigational decisions quickly, which should be the page’s primary aim.</p>
<p>Contrast this page with the Amazon home page in Figure 1, in which each group has the same simple format, drawing the eye to the content. On Amazon, with the aim of making customers’ navigational decisions quick and easy, groups’ simple, intuitive organization lets customers easily scan them and decide whether to explore a particular group further.</p>
<p>Last, but not least, the first section, <strong>Best of Yelp</strong>, does <em>not</em> even look like the other groups. It is the only one that contains breadcrumbs. As a rule of thumb, on <em>More Like This</em> pages, breadcrumbs should appear <em>above</em> all of the <em>More Like This</em> groups, <em>not</em> within any of them.</p>
<h3>Focus on Helping Customers Make Decisions</h3>
<p>To help customers make navigational decisions within <em>More Like This</em> groups, is <em>more</em> content better? The answer is: <em>it depends</em>. Amazon’s <em>More Like This</em> pattern includes one subtle, but very powerful feature: if a customer increases the page width, the number of items in each horizontal group in this liquid layout increases, so higher resolution screens and wider windows show more items in each group. I’ve already discussed the benefits of liquid screen layouts in my column “<a title="Choosing the Right Search Results Page Layout: Make the Most of Your Width," href="http://www.uxmatters.com/mt/archives/2009/03/choosing-the-right-search-results-page-layout-make-the-most-of-your-width.php">Choosing the Right Search Results Page Layout: Make the Most of Your Width</a>,” so I will not cover that topic in detail here. Be aware that this kind of horizontal expansion is no simple trick, so don’t expect it to work out of the box, as it were. Though, if you can afford the labor that developing the right CSS stylesheet involves, this is one feature well worth implementing.</p>
<p>On Amazon, more content <em>is</em> better. Partly, this is because every additional item a wider screen shows might be the one that catches the interest of a prospective buyer. But most important, showing a greater number of items presumably creates better information scent for each group, helping to motivate customers to explore a group in more detail.</p>
<p>What if there were a way to show even <em>more</em> content in each horizontal group on a page? One way to do that would be with a carousel widget that scrolls from side to side like that shown in Figure 3, on a category page on Netflix.com.</p>
<p>Figure 3—Netflix’s <em> More Like This</em> carousel pattern</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/01/images/Figure%203%20Netflix.gif" alt="Netflix More Like This" width="474" height="654" /></p>
<p>In many ways, the Netflix  implementation of a <em>More Like This </em>carousel is very similar to the Amazon implementation of <em>More Like This</em>. The page organization is simple and obvious, and the groups look different from the search results. There is, however, one important difference: clicking an arrow at either side of each group scrolls the contents of the group to the right or left, displaying an additional four items. Does the addition of this carousel widget help or hinder the primary goal of the page?</p>
<p>Well, the jury is still out on that. However, I <em>can</em> tell you that the carousel takes a customer’s focus away from making a decision about which group to explore and instead invites the customer to linger on the page a bit longer, while exploring each of the groups. This is <em>not</em> necessarily a bad thing. But keep in mind that, even though a carousel can show customers <em>twice</em> as many items in a group, it still shows them only 8 to 10 items in total. This is in contrast to the <em>hundreds</em>, if not <em>thousands</em> of items a customer could see in a complete list of search results by clicking the <strong>See all &gt;</strong> link for a group. Providing larger secondary targets—the left- and right-pointing arrows—also makes people think they <em>should</em> click them. If customers <em>do</em> click the arrows, there is a pretty good chance they might become mesmerized by the fancy scrolling interaction and miss the fact that this page is supposed to help them choose a subcategory to explore. A customer might look at the eight items the widget presents, find none of them relevant, and leave the site, thinking those eight items are all there were to see in a particular subcategory.</p>
<p>A carousel might seem like a fun, beneficial feature, but remember that the main purpose of the <em>More Like This</em> design pattern is to direct customers to explore the entire cornucopia of items under each category—that is, to <em>select</em> a category to explore—<em>not</em> to find exactly the item they want among the 8 to 10 items each carousel displays. To drive people to explore, the overall design of each group must be fairly Spartan, so customers can make their decisions quickly and move on to exploring the main body of the search results. If fancy group formatting or Ajax carousels make customers disregard the more important <em>More Like This</em> buttons, such a page fails to meet its primary objective.</p>
<p>If you are still thinking about using carousels for your <em>More Like This</em> groups, consider that Netflix has one of the best recommendation engines in the world and can usually select <em>very</em> relevant items to include among the 8 to 10 options their carousels display. Amazon, which also has an exceptional recommendation engine, tried incorporating carousels for all of their groups, but now uses the carousel feature more sparingly, presumably because the results underperformed the Spartan group design, which is optimized for quick scanning.</p>
<p>Although a typical <em>More Like This</em> page does <em>not</em> warrant the use of carousels, in some circumstances they can be appropriate. One place where a carousel widget might come in handy is in the <em>Two-Dimensional More Like This</em> design pattern I’ll discuss later. But first, let’s take a quick look at what happens when groups look just like the actual search results.</p>
<h3>Format Groups Differently from Search Results</h3>
<p>So far, we’ve covered <em>More Like This</em> pages that, for the most part, look pretty different from search results pages. What happens if you apply the <em>More Like This</em> pattern to subgroups containing <em>vertical</em> lists of results?</p>
<p>The query disambiguation page on TripAdvisor.com, shown in Figure 4, does a particularly poor job of helping customers choose either a means of exploring or a category of items to explore.</p>
<p>Figure 4—Search results for the query <em>San Francisco</em> on TripAdvisor</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/01/images/Figure%204%20Trip%20Advisor.gif" alt="TripAdvisor search results" width="474" height="527" /></p>
<p>This is clearly a page that does <em>not</em> inspire or invite further exploration. There is much that really does <em>not</em> work on this page, including the bevy of no less than <em>ten</em> generic, monochrome icons; intermixed, ungrouped results that seemingly show up in random order; the small number and poor quality of results; and the absence of any pictures. My list could go on and on. However, as bad as <em>all</em> of these problems are, customers might actually overlook them, if the page did not <em>also</em> commit the cardinal sin of any grouping presentation: making the groups on the page look like actual search results.</p>
<p>In all of my user research, I have found that <em>nothing</em> is more confusing to participants or generates more sheer exasperation in customers than dealing with a page that looks and feels like a search results page, but is actually some kind of fancy, special-purpose page containing groups, whose aim is to take customers to actual search results. TripAdvisor’s query disambiguation page for <em>San Francisco</em>, shown in Figure 4, is exactly such a page. Take care to avoid this approach in your designs.</p>
<h2><em>Two-Dimensional More Like This</em> Pattern</h2>
<p>How could we improve TripAdvisor’s query disambiguation page for <em>San Francisco?</em> In my user research, I’ve discovered that <em>precisely</em> because it is possible to show only a very small number of items for each topic—typically 4–5—customers’ do <em>not</em> expect to discover specific items of interest on this kind of page, but instead to see a <em>representative</em> set of items in each specific subcategory.</p>
<p>What if, instead of showing a fairly random sample of 4–5 <em>specific</em> hotels, attractions, or restaurants, we showed 4–5 <em>generic</em> items that represent a more granular subdivision, or <em>aspect</em>, of each category? In other words, instead of getting item details for 4–5 specific hotels, customers could drill down to one of the most popular hotel types—for example, <strong>Family</strong>, <strong>Business</strong>, <strong>Bed and Breakfast</strong>, or <strong>Boutique</strong>. Clicking one of the 4–5 generic hotels in the <strong>Hotels</strong> group would take customers to a  search results page with  results filtered by <em>both</em> the category <strong>Hotels</strong> <em>and</em> a type of popular hotel, making it possible for them to rapidly perform a visual, two-dimensional drill down into their area of interest. This is the idea behind my <em>Two-Dimensional More Like This</em> pattern. Figure 5 provides an example, showing my suggested redesign for the TripAdvisor query disambiguation page.</p>
<p>Figure 5—Suggested redesign for the query disambiguation page</p>
<p><img src="http://www.uxmatters.com/mt/archives/2010/01/images/Figure%205%20Trip%20Advisor%20Redesign.gif" alt="TripAdvisor redesign" width="470" height="412" /></p>
<p>This <em>Two-Dimensional More Like This</em> pattern is particularly appropriate for cases where the content includes thumbnail images and both the category and aspect are clearly defined—as they are in the case of hotel types, for example. In many cases, brand is another popular search facet that provides an easily recognizable secondary aspect you can apply across a group.</p>
<p>Interestingly, I have found that there is little need for secondary aspects to be consistent across categories. Let me give you an example. In my last column, “<a title="Cameras, Music, and Mattresses: Designing Query Disambiguation Solutions for the Real World," href="http://www.uxmatters.com/mt/archives/2009/12/cameras-music-and-mattresses-designing-query-disambiguation-solutions-for-the-real-world.php">Cameras, Music, and Mattresses: Designing Query Disambiguation Solutions for the Real World</a>,” I showed how HomeDepot search results for the query <em>drill</em> fell into three categories: <strong>Drills</strong>, <strong>Drill Bits</strong>, and <strong>Hammer Drills</strong>. If we were to apply the <em>Two-Dimensional More Like This</em> pattern to that example, it would be highly appropriate to use <strong>Brand</strong>—for example, <strong>Black &amp; Decker</strong>, <strong>Dewalt</strong>, and <strong>Makita</strong>—as a secondary segmentation for the <strong>Drills</strong> category. On the other hand, it would be best to segment the <strong>Drill Bits</strong> category by the type of drill bit—for example, <strong>Sets</strong>, <strong>Drill Bits</strong>, <strong>Philips Screwdrivers</strong>, and <strong>Flat Screwdrivers</strong>.</p>
<p>In my user research, I have found there is little problem with applying different secondary aspects to different <em>More Like This</em> groups on a page, so long as they make <em>some</em> intuitive sense. I have theorized that this is because the customers using a search results page usually quickly narrow the results down to a specific category, by following its information scent. So, they need to figure out the organizational pattern behind a single subcategory in which they are interested rather than to compare different subcategories to one another.</p>
<p>As I mentioned earlier, the <em>Two-Dimensional More Like This</em> pattern is an excellent use case for using a carousel widget. As Figure 5 shows, if there are more aspects—like brands or hotel types—than can fit in the 4–5 thumbnails that can appear on a page at once, you can safely hide the less popular aspects on the carousel. In this case, the expectation would be for customers to first narrow down their search to a specific <em>category</em>, then invest more attention to selecting the appropriate secondary aspect. If customers cannot find the secondary aspect they want by scrolling from side to side with the carousel, they can still click the group’s <strong>See All »</strong> link to view <em>all</em> of the search results for an entire category.</p>
<p>The <em>Two-Dimensional More Like This</em> pattern works particularly well for resolving ambiguous queries and creating category pages on which customers can clearly express search refinements by clicking a single label or image. However, it would be less appropriate for information categories that are somewhat arbitrary and less clearly defined. In the Netflix example shown in Figure 3, is there really that much difference between the categories <strong>Anime Action</strong> and <strong>Anime Sci-Fi</strong>? Applying the <em>Two-Dimensional More Like This</em> pattern to the recommendations on the Amazon home page would also be problematic. What single image could you choose to represent the categories <strong>New for You</strong> or <strong>Recommended for You</strong> and their subcategory aspects?</p>
<p>One difficulty in designing a <em>Two-Dimensional More Like This</em> page is selecting which specific items to show as representatives of each aspect. I recommend that you select the first thumbnail in the set of search results that would appear if a customer clicked a subcategory plus an aspect. Selecting the first thumbnail in a list of search results as the representative aspect performs particularly well for sorting a search result set by <strong>Best Selling</strong> or <strong>Best Match</strong>, because the first item usually provides an excellent representation of the constrained results set. Sometimes customers click a specific item <em>not</em> to select a subcategory and aspect, but simply because they liked the item in its thumbnail for some reason. Placing the item that represents both a subcategory <em>and</em> an aspect first in a set of search results satisfies both the display criteria and the I-want-this-specific-item mental model perfectly.</p>
<p>What if a specific criterion like price is important in a customer’s decision making when selecting an item on a <em>Two-Dimensional More Like Thi</em>s page? In this case, as Figure 5 shows, it is perfectly appropriate to use a sorted list format—for example, <strong>Priced from $XX.XX</strong>, which shows the lowest-priced item in a given set of search results first—even if the set of search results customers see once they click a link is sorted by <strong>Bestselling</strong> or <strong>Most Popular</strong>.<a title="Top" href="http://www.uxmatters.com/mt/archives/2010/01/more-like-this-a-design-pattern.php#top"><img src="http://www.uxmatters.com/mt/archives/images/ux-bug.gif" alt="" width="18" height="18" /></a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.designcaffeine.com/2010/articles/223/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Cameras, Music, and Mattresses: Designing Query Disambiguation Solutions for the Real World</title>
		<link>http://www.designcaffeine.com/2010/articles/221/</link>
		<comments>http://www.designcaffeine.com/2010/articles/221/#comments</comments>
		<pubDate>Tue, 19 Jan 2010 22:38:57 +0000</pubDate>
		<dc:creator>Greg Nudelman</dc:creator>
				<category><![CDATA[Articles]]></category>
		<category><![CDATA[Categories]]></category>
		<category><![CDATA[Filters]]></category>
		<category><![CDATA[Finding]]></category>
		<category><![CDATA[Query Disambiguation]]></category>
		<category><![CDATA[Related Searches]]></category>
		<category><![CDATA[search]]></category>
		<category><![CDATA[Search Matters]]></category>
		<category><![CDATA[Search Results]]></category>

		<guid isPermaLink="false">http://www.designcaffeine.com/?p=221</guid>
		<description><![CDATA[Redesigned Home Depot results

Originally published on UXMatters.com December 7, 2009 ⇒

Our language is limited and imperfect. Typically, people type search queries quickly and with little forethought, so queries are definitely less than perfect. When a customer constructs a query that may have more than one meaning, a good search user interface provides tools to help the customer define the query in less ambiguous terms, so the search results more closely match the person’s intention. This process is known as disambiguation, and best practices for effectively supporting the disambiguation of search queries are the subject of this column. ]]></description>
			<content:encoded><![CDATA[<p><a title="Read this article on UXMatters (Opens in a New Window)" href="http://www.uxmatters.com/mt/archives/2009/12/cameras-music-and-mattresses-designing-query-disambiguation-solutions-for-the-real-world.php" target="_blank">Originally published on UXMatters.com December 7, 2009 ⇒</a></p>
<p>Our language is limited and imperfect. Typically, people type search queries quickly and with little forethought, so queries are <em>definitely</em> less than perfect. When a customer constructs a query that may have more than one meaning, a good search user interface provides tools to help the customer define the query in less ambiguous terms, so the search results more closely match the person’s intention. This process is known as <em>disambiguation</em>, and best practices for effectively supporting the disambiguation of search queries are the subject of this column.</p>
<p>Recently, I came across a new search engine—which shall remain nameless—that promised a combined search and browse approach to finding products. I was curious, so I put this new search application through its paces by typing the query <em>Canon</em>. In addition to results for cameras, the search engine displayed results including the company’s profile for investors, Pachebel’s <em>Canon</em>—a form of music—and, to my great surprise, a Canon mattress and a Canon ottoman, which the products section featured prominently.<span id="more-221"></span></p>
<p>Unfortunately, these search results represented a fairly typical situation that occurs when a search application does <em>not</em> correctly understand the meaning of a query. Especially frustrating was the fact that the user interface did <em>not</em> provide any tools to help people to refine their queries and, thus, improve the quality of their search results. The <em>only</em> way people <em>could</em> improve their search results was by typing more keywords into the search box, which takes both thought and work—two things any busy, distracted Internet user can do without.</p>
<p>In her recent column on <em>UXmatters</em>, “<a title="First, Do No Harm" href="http://www.uxmatters.com/mt/archives/2009/11/first-do-no-harm.php">First, Do No Harm</a>,” Pabini Gabriel-Petit quoted Jef Raskin: “A computer shall not waste your time or require you to do more work than is strictly necessary.”</p>
<p>What can we do to remedy this situation? In this column, I’ll discuss three simple strategies designers of search applications often use to help people resolve ambiguous queries:</p>
<ol>
<li>Show related searches.</li>
<li>Select a default category automatically.</li>
<li>Prominently display a category selector.</li>
</ol>
<p>Let’s look at the advantages and limitations of each approach.</p>
<h2>Showing Related Searches</h2>
<p><strong>Related Searches</strong> is a fairly standard module on mainstream ecommerce sites and search engines. Figure 1 shows an example on Amazon.com.</p>
<p>Figure 1—Amazon’s <strong>Related Searches</strong> module in the search results for Canon</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/12/images/figure_1_amazon.png" alt="Amazon's Related Searches module" width="474" height="367" /></p>
<p>Most search applications track how people modify their original queries, then apply an algorithm to this tracking data to display the most common modifications to queries in a <strong>Related Searches</strong> module. As Figure 2 shows, people who typed <em>Canon</em> augmented their queries by typing <em>Canon camera, Canon lens,</em> or other more specific queries.</p>
<p>In her recent book, <a title="Search User Interfaces" href="http://searchuserinterfaces.com/"><em>Search User Interfaces</em></a>,<a title="Search User Interfaces" href="http://searchuserinterfaces.com/"><img src="http://www.uxmatters.com/mt/archives/images/new-window-arrow.gif" alt="" width="14" height="12" /></a> Marti Hearst discusses the related searches algorithm in detail and quotes several impressive studies that document the effectiveness of this approach. Indeed, in my own user research, most people have found the alternatives a <strong>Related Searches</strong> module presents very relevant and clicked them to find what they wanted—mainly because of their very good information scent. Related searches often seem to present the keyword combinations people had unconsciously desired, but could not quite formulate themselves without more thought.</p>
<p>Essentially, a <strong>Related Searches</strong> module eliminates the effort and thought creating a good query requires, making a search user interface more intuitive and enjoyable, without using a great deal of precious screen real estate. The back-end algorithm for this module does require a fair bit of infrastructure to implement the query tracking. However, some APIs like Yahoo! BOSS are now available to make the job easier.</p>
<p>In my studies, I discovered people had a positive response to most suggestions revolving around <em>modifications</em> of their original queries, because of their very strong perception that the recommended queries represented the combined wisdom of crowds—as with tagging and folksonomies. However, many people I observed were highly suspicious of any <em>orthogonal</em> queries that recommended competing brands or products.</p>
<p>For example, in Figure 1, a related query that recommends <em>Nikon</em> in response to the query <em>Canon</em> would quickly cause people to become mistrustful and question the value of <em>all</em> suggestions in the <strong>Related Searches</strong> module.  For this reason, I recommend that search user interfaces concentrate on showing <em>only</em> query modifications in their <strong>Related Searches</strong> modules. Show competing products and brands in a different module instead—for example, in a sidebar. You can easily limit search results to those that contain the original keywords with a simple <em>grep</em> command. Done properly, a <strong>Related Searches</strong> module is a very useful device for helping people disambiguate their queries and improving the quality of their search results—thus, creating a better finding experience.</p>
<h2>Selecting a Default Category Automatically</h2>
<p>Displaying <em>only</em> search results belonging to a specific category or topic by default is another very common strategy for disambiguation. An ecommerce system can determine what category or topic to display by default, using supply data, demand data, or some combination of the two. <em>Supply data</em> refers to the number of distinct product or content entries currently available in a site’s inventory that match a certain keyword query. In contrast, <em>demand data</em> refers to the number of people who selected products from a specific category after typing the same keyword query during a given period of time.</p>
<p>To automatically determine the default category using supply data, an ecommerce system might fairly easily measure the number of items currently in the inventory that match a specific keyword query. For example, if 70% of the items that match the query <em>Canon</em> belong to the <strong>Digital Gadgets</strong> category, the search algorithm might automatically display results in the <strong>Digital Gadgets</strong> category whenever a customer submits that query—omitting results in <strong>Music</strong> and other categories. A more sophisticated way of doing the same thing would be to use demand data to determine how many customers in the last week proceeded to view or buy items in the <strong>Digital Gadgets</strong> category after searching for <em>Canon</em> versus products in <em>all</em> other categories; then, if the number exceeds a certain threshold, to display the <strong>Digital Gadgets</strong> category of results by default.</p>
<p>What are some advantages of selecting a category of results by default? Automatically interpreting the query <em>Canon</em> as a request for <strong>Digital Gadgets</strong>, then showing a <em>Canon</em> brand product catalog lets Best Buy create a very compelling visual browsing experience, complete with custom subcategories and aspects, as shown in Figure 2.</p>
<p>Figure 2—Best Buy search results for <em>Canon</em></p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/12/images/figure_2_best_buy.png" alt="Best Buy search results" width="474" height="501" /></p>
<p>I’ll cover best practices for product catalogs in more detail in future columns, but for now, notice how extremely committed this category selection is in comparison to the Amazon search results for the same query, shown in Figure 1. Not only is the Canon brand selected, there is <em>no trace</em> of any results matching <em>Canon</em> for other types of products on the site. This provides a great user experience for someone looking for electronic gadgets, but it could be very confusing to someone looking for something in the category <strong>Music</strong>, for example.</p>
<p>A final word of caution: Automatically selecting a default category or topic is a <em>very</em> committed action, so communicating how to undo this action can be a challenge. Evidence shows that half-hearted measures for indicating the presence of other results on a Web site do <em>not</em> work particularly well.</p>
<p>Here is an example. When doing some user research for one of the top Web retailers, I tested a memorable user interface that automatically selected the category <strong>Shoes</strong> when a user typed the query <em>Nike</em>. However, unlike the Best Buy user interface shown in Figure 2, the user interface I was testing also provided a prominent link to let users undo the category selection—<strong><span style="text-decoration: underline;">Not looking for Nike Shoes?</span></strong> The usability test task involved finding Nike bags. The study’s significant finding was that the vast majority of participants did <em>not</em> discover or click the link <strong><span style="text-decoration: underline;">Not looking for Nike Shoes?</span></strong></p>
<p>I theorized that this might have occurred, because the link did <em>not</em> contain any information scent for the category <strong>Bags</strong> for which participants were searching. Additionally, when people quickly scanned the page—as most people tend to do—mentally processing this negative statement was fairly difficult. Dynamically displayed links for other Nike categories that started with strong keyword scent words might have been much more successful—for example, <strong>Other Nike products: <span style="text-decoration: underline;">Bags</span>, <span style="text-decoration: underline;">Shirts</span>, <span style="text-decoration: underline;">Pants</span>, <span style="text-decoration: underline;">Jackets</span>, <span style="text-decoration: underline;">More…</span></strong>.</p>
<p>The moral of this story? If you <em>do</em> commit to using a default topic or category as part of your disambiguation strategy, make sure it is for a good reason, based on metrics that help your company meet its business goals. Decrease your company’s risk by providing a clear way out of the default category, using links that start with prominent keywords and provide strong information scent for other popular categories or topics matching a keyword.</p>
<h2>Prominently Displaying a Category Selector</h2>
<p>In addition to a <strong>Related Searches</strong> module, most ecommerce sites also provide a category selector widget. Notice that, in Figure 1, Amazon presented its available categories in a navigation bar on the left. While this strategy is pretty standard and widely accepted, some sites go still further, emphasizing their categories as a strategy for disambiguation. For example, compare the Amazon search results shown in Figure 1 to The Home Depot search results for <em>drill</em>, in which the categories appear prominently above the search results, as shown in Figure 3.</p>
<p>Figure 3—Home Depot search result categories</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/12/images/figure_3_home_depot.png" alt="Home Depot search result categories" width="474" height="529" /></p>
<p>There are many good reasons for emphasizing categories as part of your disambiguation strategy. Prominently displaying categories above search results clearly signals to customers that their queries may have more than one meaning on a site. Providing categories also lets customers correctly customize search results by selecting a category, then aspects or other finding tools matching a specific category. For example, the category <strong>Drills</strong> might feature the aspects <strong>Power Tool</strong> and <strong>Hand Tool</strong>, while the category <strong>Drill Bits</strong> might have the aspects <strong>Size</strong> and <strong>Hardness</strong>. Showing categories above the search results—as opposed to in a navigation bar on the left—also allows the display of longer category names without wrapping, providing improved information scent without compromising readability.</p>
<p>However, as we can see in Figure 3, showing categories above the search results can also lead to some pitfalls. If you look carefully at Figure 3, you’ll notice that The Home Depot search results actually feature <em>two</em> separate category selectors—one in the navigation bar on the left, the other above the search results—which could be pretty confusing. The two sets of categories are <em>not</em> the same, leading customers to wonder where they should click and why. The links in the navigation bar are sorted alphabetically—<em>not</em> in their order of popularity—which is suboptimal. It’s not clear <em>how</em> the categories above the search results were selected or sorted or <em>why</em> they appear in such a prominent location. As a result, the categories above the search results feel a bit like a Band-Aid—letting customers jump directly to popular areas of the site.</p>
<p>Providing additional information scent for the main categories on The Home Depot site would serve that function better. Customers might expect each of the subcategories to be a separate link—so, for example, clicking <strong>Power Tools</strong> would display a level-two subcategory—but this is <em>not</em> the case. Instead, each link constitutes an independent selection, forcing customers to navigate three or four levels deep into the site hierarchy and make committed category selections <em>before</em> they’ve had a chance to see the wider inventory. Since each link exposes just a subset of a very detailed hierarchy, these links force customers to learn the site’s category structure to be able to make informed decisions.</p>
<p>Last, but not least, hierarchical categories can introduce a huge readability problem if many categories start with the same keywords. For example, seven of The Home Depot’s categories start with the keywords <strong>Tools &amp; Hardware &gt; Power Tool…</strong>, making it hard to distinguish the <strong>Tools</strong> and <strong>Accessories</strong> categories from one another and make the right choice.</p>
<p>This page displays far too many categories—fourteen, in all—above the search results. Plus, despite the generous amount of screen real estate the page allots to categories, the category names are too long, so they wrap. Together, these two factors push the actual search results <em>way</em> down on the page, placing <em>all</em> products below the fold at many screen resolutions. My research has indicated that many customers might be confused by this. Instead of scrolling, they might feel the site is forcing them to click a category <em>before</em> they can see any actual search results.</p>
<p>A better choice would be to commit to showing the first-level categories just once, above the search results, while avoiding wrapping, and augmenting them with additional keywords—as space allows—to help customers make the right choices. As Daniel Tunkelang notes in his book <a title="Faceted Search" href="http://thenoisychannel.com/faceted-search-the-book/"><em>Faceted Search</em></a>,<a title="Faceted Search" href="http://thenoisychannel.com/faceted-search-the-book/"><img src="http://www.uxmatters.com/mt/archives/images/new-window-arrow.gif" alt="" width="14" height="12" /></a> showing four to seven values for each aspect seems like the sweet spot. His finding is well supported by my own research. Sticking to Daniel’s recommendation, I would reduce the number categories on The Home Depot site at least by half. The resulting user interface might look something like that shown in Figure 4.</p>
<p>Figure 4—Redesigned Home Depot results, with an expanding category widget</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/12/images/figure_4_home_depot_redesign.png" alt="Redesigned Home Depot results" width="474" height="491" /></p>
<p>Figure 4 demonstrates an <em>Expanding Category Widget</em> design pattern that is very similar to a search user interface I recently redesigned for an enterprise client. The original design had very long category names, forcing categories in the navigation bar on the left to wrap three or four times.</p>
<p>Placing categories above the search results solved the problem, effectively handling long category names and providing a great way of disambiguating complex queries. However, be aware that even this improved user interface distracts customers from shopping. Prominently displaying categories practically forces your customers to deal with the complexities of your user interface and the category hierarchy on your site rather than actually shopping.</p>
<p>For a less ambiguous query, a good middle ground might be to automatically collapse the wide category widget to its standard size in the navigation bar, allowing users to drag its handle if they want to expand the category hierarchy again, as shown at the bottom of Figure 4. Judicious use of a simple animation, showing an expand/collapse transition might be very helpful in improving the attractiveness and usability of this widget. The <em>Expanding Category Widget</em> is a useful design pattern that might be worth exploring when determining your category-driven disambiguation strategy.</p>
<h2>Conclusion</h2>
<p>It is a fact of life that ambiguous queries are fairly common. In a post-Google world, most people expect a very high degree of relevance for search results after typing just a single keyword. They are often surprised and dissatisfied when your search user interface does <em>not</em> deliver. In this column, I’ve covered a wide range of tools and design patterns that can help reduce the thought and effort necessary to convey the desired meaning of a customer’s ambiguous query.</p>
<p>Numerous variations on disambiguation strategies exist, from adding a fairly simple <strong>Related Searches</strong> module to completely redesigning your search results page, following the <em>Expanding Category Widget</em> pattern. However, this column has <em>not</em> provided an exhaustive list of design patterns for query disambiguation. It is my sincere hope that this installment of <em>Search Matters</em> will inspire you to seek more information and explore new ideas for query disambiguation. It is only through trying out new ideas and careful experimentation that you can find the optimal approach for your Web site and your customers. Your customers depend on you to help them find what they are looking for. Do not fail them.</p>
<p>In my next column, I’ll cover another powerful, but underused design pattern, <em>More Like This</em>, which—among its many uses—can also be very helpful in query disambiguation.<a title="Top" href="http://www.uxmatters.com/mt/archives/2009/12/cameras-music-and-mattresses-designing-query-disambiguation-solutions-for-the-real-world.php#top"><img src="http://www.uxmatters.com/mt/archives/images/ux-bug.gif" alt="" width="18" height="18" /></a></p>
<div id="_mcePaste" style="overflow: hidden; position: absolute; left: -10000px; top: 5px; width: 1px; height: 1px;"><tt>&lt;!--more--&gt;</tt></div>
]]></content:encoded>
			<wfw:commentRss>http://www.designcaffeine.com/2010/articles/221/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Make More Money: Best Practices for Ads in Search Results: Part 2</title>
		<link>http://www.designcaffeine.com/2010/articles/219/</link>
		<comments>http://www.designcaffeine.com/2010/articles/219/#comments</comments>
		<pubDate>Tue, 19 Jan 2010 22:34:13 +0000</pubDate>
		<dc:creator>Greg Nudelman</dc:creator>
				<category><![CDATA[Articles]]></category>
		<category><![CDATA[Ads]]></category>
		<category><![CDATA[Search Matters]]></category>
		<category><![CDATA[Search Results]]></category>

		<guid isPermaLink="false">http://www.designcaffeine.com/?p=219</guid>
		<description><![CDATA[Co-written with Frank Guo ⇒
Originally published on UXMatters.com November 2, 2009 ⇒
In this installment of Search Matters, we’ll continue our discussion of ads in search results. If you missed it, read Part 1,  which covered these best practices:

Integrate your ads’ appearance with the rest of your site.
Make sure customers can easily distinguish ads from [...]]]></description>
			<content:encoded><![CDATA[<p><a title="Visit Frank Guo's biography on UXMatters (Opens in a New Window)" href="http://www.uxmatters.com/authors/archives/2009/10/frank_guo.php" target="_blank">Co-written with Frank Guo ⇒</a><br />
<a title="Read this article on UXMatters (Opens in a New Window)" href="http://www.uxmatters.com/mt/archives/2009/11/make-more-money-best-practices-for-ads-in-search-results-part-2.php" target="_blank">Originally published on UXMatters.com November 2, 2009 ⇒</a></p>
<p>In this installment of <em>Search Matters</em>, we’ll continue our discussion of ads in search results. If you missed it, read <a title="Part 1" href="http://uxmatters.com/mt/archives/2009/10/make-more-money-best-practices-for-ads-in-search-results-part-1.php">Part 1</a>,  which covered these best practices:</p>
<ul>
<li>Integrate your ads’ appearance with the rest of your site.</li>
<li>Make sure customers can easily distinguish ads from content.</li>
<li>Keep ads relevant and appropriate.</li>
<li>Understand how your customers interact with ads.</li>
</ul>
<p>In Part 2, we’ll discuss the following best practices:</p>
<ul>
<li>Understand what makes a good ad.</li>
<li>Limit cannibalization.</li>
<li>Provide ads for internal merchandise instead of third-party advertising.</li>
<li>Pay special attention to ads on pages that appear if there are <em>no</em> search results.</li>
</ul>
<p>Let’s dig in!<span id="more-219"></span></p>
<h2>Understand What Makes a Good Ad</h2>
<p>Based on the findings of eyetracking studies, we’ve seen that users spontaneously pay attention to things that are</p>
<ul>
<li>concrete</li>
<li>actionable</li>
<li><em>not</em> like marketing</li>
</ul>
<p>These findings apply to both typical search results and third-party ads. Thus, a good ad is concrete and to the point rather than full of generic, marketing jargon. For example, it might present a picture of the actual item being advertised or indicate clearly that there’s free shipping rather than saying something like <em>We have thousands of cheap items in stock!</em> As shown in Figure 1, the ads on Cars.com are actually pretty good.</p>
<p>Figure 1—Good ads with appropriate content on Cars.com</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/11/images/figure_1_cars.png" alt="Good ads on Cars.com" width="474" height="487" /></p>
<p>This ad on Cars.com follows an important principle: It is highly <em>relevant</em> to the search results on the page, calling customers’ attention to the specific item in the search results. Even though the ad at the top of the page is a banner ad, it doesn’t have the drawbacks of typical banner ads—such as presenting irrelevant content or being positioned too far away from the main content. The price quote, showing good value, is prominent and provides a good call to attention. The presentation of the ad is very straightforward, with concrete information and little marketing language or visual noise.</p>
<p>Is it enough that an ad’s content be appropriate? While content is important, it is just one aspect of the marketing message. Another important principle of ad appropriateness is keeping an ad’s <em>style</em> appropriate to the topic. Contrast the style of the Cars.com ad to the ad on the Yahoo! Movies page, pictured in Figure 2. Even without seeing the flashy animation, it is clear that the ad is quite vibrant.</p>
<p>Figure 2—An appropriate ad style on Yahoo! Movies has bling</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/11/images/figure_2_yahoo_movies.png" alt="Appropriate ads on Yahoo! Movies" width="474" height="298" /></p>
<p>An ad with this animated style is highly appropriate if we expect customers to be getting ready for an action-adventure movie experience complete with special effects. In this case, tasteful, yet somewhat loud movie ads, providing links to previews, are not only appropriate, but expected. This example shows how carefully chosen ads can form a large part of a Web page’s useful content, making it unnecessary for Yahoo! to work so hard at keeping the page exciting. The ad in Figure 2 calls out a specific item within a set of search results that appears on the page.</p>
<p>When it comes to hosting ads, it definitely pays to get creative. In our research, we learned that the way an ad is presented matters a great deal in how customers perceive both the ad and the site hosting it. Creative, interesting presentations get extra points, especially if they are unobtrusive. For example, the peel-the-corner ad on EddieBauer.com, shown in Figure 3, is a great example of an ad that draws attention and invites participation, without obnoxiously dominating an experience.</p>
<p>Figure 3—Getting creative with an interactive, peel-the-corner ad</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/11/images/figure_3_eddie_bauer.png" alt="Peel-the-corner ad" width="474" height="265" /></p>
<p>Anecdotal evidence suggests that most people do <em>not</em> mind interacting with this kind advertising and consider peel-the-corner style ads acceptable or even positive on a wide range of sites—<em>if</em> the ads contain appropriate content.</p>
<p>What kind of customer action should an ad invite? In Figure 1, the ad on Cars.com asked customers to purchase or consume a specific item on the same Web site—for example, purchase a Lexus. The ad in Figure 2 invited customers to participate in an offline interaction they will perform after viewing the ad—see a movie after reading a movie review and referring to a theater schedule on Yahoo! Movies. These are both examples of <em>passive ads</em>—that is, they do <em>not</em> invite customers to click, so much as capture eyeballs, with the purpose of instilling a subliminal desire to select a specific item among many that a site offers. This mirrors a classic bricks-and-mortar advertising strategy, in which certain companies pay stores to feature their brands on banners and place their products in prominent locations.</p>
<p>However, the Web is a very dynamic medium, leading to all sorts of novel advertising models. One advertising model involves carrying your competitors’ ads, advertising similar products for sale on a different Web site or in another store. On the one hand, customers’ clicking these ads generates marketing revenue. On the other hand, this marketing revenue literally eats into the sales revenue from products and services your Web site provides. Thus, competitors’ ads cause what is known as <em>cannibalization</em>.</p>
<h2>Limit Cannibalization</h2>
<p>Generally, carrying competitors’ ads is a dangerous and losing proposition, because cannibalization involves many hidden costs that are often hard to quantify. Most companies spend a lot of money on advertising, to bring customers to their own Web sites. If customers click a competitor’s advertisement, not only is there an <em>opportunity cost</em>—because those customers do <em>not</em> buy your own service or product—there is also a <em>hidden cost</em>—you’ve wasted your marketing dollars.</p>
<p>In addition to cannibalization’s threatening your bottom line, the experience of your customers’ clicking your competitors’ ads is likely to be disconcerting to them, leaving them less satisfied with <em>your</em> site as a result. Most competitors’ ads just dump customers on the home page of their site or, at best, on a search results page, leaving them to figure out how to navigate to the one item they want—for instance, to compare a competitor’s price for an item they were looking at on your site. Thus, clicking an ad almost <em>always</em> involves extra work for your customers. For this reason, if your customers are getting the results they want on your site, most do <em>not</em> click  a competitor’s ad—unless</p>
<ul>
<li>the ad makes a very attractive offer <em>or</em></li>
<li>the competitor’s brand is stronger</li>
</ul>
<p>Some sites understand their customers’ reluctance to do extra work and consciously decide to exploit this fact by hosting competitors’ ads—boosting their revenue <em>without</em> much cannibalization of their own sales. The key to doing this <em>successfully</em> is making rational judgments regarding which ads to host, based on your overall site revenue strategy and hard site traffic statistics. Some successful strategies for carrying competitors’ ads include the following:</p>
<ul>
<li>making competitors’ ads <em>look</em> like advertising—Customers deliberately ignore such ads, and they get very few clicks. This strategy works great if you get paid for ad impressions, <em>not</em> by the number of clicks.</li>
<li>carrying <em>only</em> ads for weaker brands—This limits the number of customers who click away from your site.</li>
<li><em>not</em> allowing ads to display competitors’ prices—Displaying the actual prices for specific competing goods or services encourages customers to click ads.</li>
</ul>
<p>The competitor ad on Yahoo! Cars, shown in Figure 4, provides a good example for all three of these strategies.</p>
<p>Figure 4—Competitor advertising on Yahoo! Cars</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/11/images/figure_4_yahoo_cars.png" alt="Competitor ads on Yahoo! Cars" width="474" height="774" /></p>
<p>Another interesting strategy involves completely embracing the experience of offering <em>the best marketplace price</em> from whatever source and being fully committed to <em>always</em> carrying ads from various competitors. You can see one example of this strategy on Buy.com, which we discussed in Part 1 of this column. Buy.com shows prices from eBay and Dell, as well as the price for the product from its internal search engine. This strategy works well in any of the following cases:</p>
<ul>
<li>Your site has the best price.</li>
<li>Differences in price are <em>not</em> significant.</li>
<li>Competitors’ prices do <em>not</em> give a complete picture—for example, items for sale are used or have high shipping costs, but their ads do <em>not</em> communicate these details.</li>
</ul>
<h2>Provide Ads for Internal Merchandise Instead of Third-Party Advertising</h2>
<p>Amazon.com uses an interesting variation on this strategy, carrying the same items from both Amazon’s own store and their online marketplace, as pictured in Figure 5.</p>
<p>Figure 5—Ad for the Amazon marketplace</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/11/images/figure_5_amazon.png" alt="Ad for the Amazon marketplace" width="229" height="452" /></p>
<p>This is a win-win situation for both Amazon and their customers. Amazon collects rich fees from sellers in their marketplace, so they make money regardless of which items customers purchase. Having a marketplace also benefits consumers by providing multiple, highly relevant shopping options <em>without</em> presenting anything that looks or feels like an ad. This strategy is very tricky, because Amazon is essentially competing with their own sellers. However, despite the challenges, this strategy has been quite successful—in large part because Amazon has been very proactive, constantly adjusting their price points and the inventory of items they carry to keep their marketplace thriving and provide customers with the comfort of knowing they are getting very good prices from a brand they trust.</p>
<p>Amazon’s strategy reflects a more general principle: Whenever possible, providing and upselling merchandise to customers is almost always better than hosting third-party ads. There are many good reasons to host your own merchandising rather than third-party ads, including the following:</p>
<ul>
<li>control—No matter how carefully you screen third-party ads, undesirable content sometimes slips through, harming your brand and sending your hard-earned customers to your competition.</li>
<li>visual design—Despite your best efforts at ad customization, third-party ads look like, well, ads. On the other hand, you can fully integrate merchandising into your site, make the best use of your available space.</li>
<li>specificity—Third-party ads are often <em>not</em> very specific to a site’s own products—nor would you want them to be, because that would drive your customers to the competition. On the other hand, you can make merchandising as specific as necessary, because in this case, <em>all</em> ads ultimately drive traffic back to your own site, where transactions convert directly to your bottom line.</li>
</ul>
<p>Merchandising simply offers a better user experience. People like specific, targeted content that does <em>not</em> look like an ad, but helpfully provides ideas and choices.</p>
<h2>Pay Special Attention to Ads If There Are <em>No</em> Search Results</h2>
<p>When there are <em>no</em> results, search results pages are an especially dangerous place to host advertising. <em>All</em> of the negatives of displaying competitors’ ads that we discussed earlier become further exacerbated on a no search results page. Such a page is generally devoid of your own content, making third-party ads their primary calls to action.</p>
<p>As I described in my earlier column “<a title="Starting from Zero: Winning Strategies for No Search Results Pages" href="http://www.uxmatters.com/mt/archives/2009/02/starting-from-zero-winning-strategies-for-no-search-results-pages.php">Starting from Zero: Winning Strategies for No Search Results Pages</a>,” no search results pages indicate to customers they’ve over-constrained their query and need to reformulate or broaden their search. Displaying third-party ads on a no search results page invites customers to abandon their natural behavior of iterative search in favor of following a fresh information scent. This interrupts the finding flow on your site and dumps your customers directly into your competitors’ greedy hands.</p>
<p>Unfortunately, marketing folks often simply fail to grasp the iterative nature of the finding process and the critical role the no search results page plays in helping customers reformulate their queries. Some of them like to put ads on no search results pages, justifying their viewpoint by saying something like this: <em>We are simply meeting the customer’s needs with our ads. The customer would leave our site anyway. We are just helping him and making some money along the way.</em></p>
<p>This thinking demonstrates a dangerous and fundamental lack of understanding of the differences between how search engines and ad-hosting services should work. Search engines that are internal to a Web site typically combine keywords, using an AND operator. Thus, they look for items or content that contain <em>all</em> of the keywords a customer provides. This practice often leads to over-constrained queries, limiting the finding conversation between a person and a Web site.</p>
<p>Now, let’s contrast search engine results with hosted advertising results. Search engines providing hosted ads have <em>no</em> requirements for fidelity or specificity—the rules by which a site’s own search engine usually abides. By using an OR operator instead of AND, hosted ad servers can cherry-pick ads, displaying <em>only</em> the most relevant ads or those matching the most profitable keywords in a customer’s query, and ensure the ad server <em>never</em> fails to produce results. Also, when an ad only approximately matches a query, you can replace the ad’s title with dynamic text that exactly matches the keywords in the query.</p>
<p>For example, in one particularly memorable usability study, a task asked participants to find a ticket to a performance of the <em>Nutcracker</em> in San Francisco, during the holidays. After reading the task, one participant typed the query <em>Nutcracker Ballet in San Francisco December 1-31st</em>, which, of course, matched <em>no</em> results on the site. However, the ad hosting engine produced a page similar to that shown in Figure 6.</p>
<p>Figure 6—Ads matching the query <em>Nutcracker Ballet in San Francisco December 1-31st</em></p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/11/images/figure_6_nutcracker_ads.png" alt="Ads on a no results page" width="287" height="520" /></p>
<p>Upon seeing the no search results page displaying these ads, the participant promptly clicked an ad and bought a ticket from a competing site, even though <em>cheaper</em> tickets were readily available on the site we were testing. If the participant had relaxed her query, she would have discovered this, but instead, the third-party advertising appearing on the no search results page led her down a different path. When there are <em>no</em> search results, that is the <em>wrong</em> place and time for displaying third-party ads.</p>
<p>As this story demonstrates, it is very easy to lose customers on no search results pages, which represent a critical juncture in a conversation between a customer and a Web site—an opportunity for the customer to reformulate a query and gain a deeper connection with your brand. Host third-party ads on your no search results pages <em>only</em> as a last resort. We recommend you carefully calculate the cost of doing so. Which click would generate more long-term revenue: the ad or the tools for query reformulation? Which click would ultimately engender more long-term loyalty and a better relationship with your customers?</p>
<h2>In Conclusion</h2>
<p>In his keynote speech at the <em>2008 Business Of Software</em> conference, Seth Godin famously quipped, “Marketing is too important to be left to the marketing department.” The same goes for hosting advertising. UX professionals should be actively involved in ad-hosting decisions to make sure your company’s golden goose continues to thrive, well beyond the current quarter.</p>
<p>We want to encourage you to use these ideas as a starting point for developing your own comprehensive merchandising and ad-hosting strategies. Making the tough choices that are necessary and getting creative with ad hosting is not easy, but it is an absolute must if your company is to survive and thrive in the current economic environment.<a title="Top" href="http://www.uxmatters.com/mt/archives/2009/11/make-more-money-best-practices-for-ads-in-search-results-part-2.php#top"><img src="http://www.uxmatters.com/mt/archives/images/ux-bug.gif" alt="" width="18" height="18" /></a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.designcaffeine.com/2010/articles/219/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Make More Money: Best Practices for Ads in Search Results: Part 1</title>
		<link>http://www.designcaffeine.com/2010/articles/216/</link>
		<comments>http://www.designcaffeine.com/2010/articles/216/#comments</comments>
		<pubDate>Tue, 19 Jan 2010 21:54:21 +0000</pubDate>
		<dc:creator>Greg Nudelman</dc:creator>
				<category><![CDATA[Articles]]></category>
		<category><![CDATA[Ads]]></category>
		<category><![CDATA[Search Matters]]></category>
		<category><![CDATA[Search Results]]></category>

		<guid isPermaLink="false">http://www.designcaffeine.com/?p=216</guid>
		<description><![CDATA[Co-written with Frank Guo ⇒
Originally published on UXMatters.com October 5, 2009 ⇒
Conflicting demands make many UX professionals think of ads as a necessary evil. Customers frequently go out of their way to say they hate ads, while marketers always seem to try their hardest to stuff as many of them as they can on each [...]]]></description>
			<content:encoded><![CDATA[<p><a title="Visit Frank Guo's biography on UXMatters (Opens in a New Window)" href="http://www.uxmatters.com/authors/archives/2009/10/frank_guo.php" target="_blank">Co-written with Frank Guo ⇒</a><br />
<a title="Read this article on UXMatters (Opens in a New Window)" href="http://www.uxmatters.com/mt/archives/2009/10/make-more-money-best-practices-for-ads-in-search-results-part-1.php" target="_blank">Originally published on UXMatters.com October 5, 2009 ⇒</a></p>
<p>Conflicting demands make many UX professionals think of ads as a necessary evil. Customers frequently go out of their way to say they <em>hate</em> ads, while marketers always seem to try their hardest to stuff as many of them as they can on each search results page on your site. This leaves many UX design professionals caught in the middle, trying to balance the ad equation—and frequently failing to fully satisfy either customers or marketers. For this 2-part column, I’ve teamed up with advertisement and eyetracking research guru Frank Guo to present real-world strategies for successfully integrating ads into your search results. The goal is making money <em>without</em> unduly turning off your customers.<span id="more-216"></span></p>
<h2>Don’t Kill Your Golden Goose</h2>
<p>Internet ads have gone full circle—from the <em>Ads are great! Now, we can make money on anything!</em> mania of the early 1990s to the <em>Ads are dead</em> post-dot-com bust philosophy. Currently, the notion that ads are a legitimate way of boosting revenues on an ecommerce site seems to be making a comeback—in part, because this is a tough economy for many etailers. Every penny counts, and every stream of potential revenue demands careful consideration. However, research and experience show that, for an online business to succeed and thrive, it is important to temper any temptation to load up on ads and get a quick revenue boost <em>this</em> quarter with broader, long-term considerations—like user experience, customer loyalty, and brand attributes. If you are not careful, trying to squeeze out a few more eggs can easily kill your golden goose.</p>
<p>However, following a few simple guidelines—while listening carefully to your customers—can help your business make money with ads, <em>without</em> compromising either long-term customer loyalty or your brand image. Here are the best practices we’ll discuss in Part I of this column:</p>
<ul>
<li>Integrate your ads’ appearance with the rest of your site.</li>
<li>Make sure customers can easily distinguish ads from content.</li>
<li>Keep ads relevant and appropriate.</li>
<li>Understand how your customers interact with ads.</li>
</ul>
<h2>Integrate Your Ads’ Appearance with the Rest of Your Site</h2>
<p>In recent years, Google has emerged as the industry-leading supplier of ads on the Web. Indeed, Google ads make it easy—and often profitable—for you to sign up and host ads on your Web site. Most of the time, the ad content is fairly well targeted, so many retailers, bloggers, and developers of social networking sites have taken advantage of the opportunity to host Google ads. Unfortunately, few have made the effort to customize the boxed ads to make them look like the rest of their site. Figure 1 shows the social networking site Fishing.net, which carries Google ads just as they come “out of the box,” without any customization.</p>
<p>Figure 1—On Fishing.net, Google ads have no customization.</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/10/images/figure_1_fishing_net.png" alt="Ads by Google aren’t customized" width="472" height="475" /></p>
<p>Neglecting to customize third-party ads is, of course, easier, but there are consequences to this approach:</p>
<ul>
<li>Customers frequently perceive your entire site as cluttered and disorganized.</li>
<li>Customers mostly ignore the ads, because they look different from the rest of your content.</li>
</ul>
<p>This is a lose-lose situation. Your customers lose out, because their experience of your site is degraded. Your marketers lose out, because customers click their ads less often—if at all.</p>
<p>Experience shows that a small amount of visual design and programming effort that makes your ads look like the rest of your site can yield tremendously positive responses from your customers. They stop seeing ads as clutter and instead perceive them as content. Google, of course, provides a superb example of this strategy in practice, as shown in Figure 2.</p>
<p>Figure 2—Google.com sets the standard for ad placement and integration.</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/10/images/figure_2_google.png" alt="Ads on Google" width="471" height="352" /></p>
<p>Google has carefully crafted their customer experience, paying strict attention to everything from page balance and spacing to tweaking even the smallest visual design elements. In a recent <a title="Q&amp;A" href="http://searchengineland.com/070126-124723.php">Q&amp;A</a><a title="Q&amp;A" href="http://searchengineland.com/070126-124723.php"><img src="http://www.uxmatters.com/mt/archives/images/new-window-arrow.gif" alt="" width="14" height="12" /></a> with G. Hotchkiss, Marissa Mayer, Google’s VP of Search Products &amp; User Experience, described how replacing the box that used to contain ads on the right side of search results pages with a vertical line separator improved ad traffic, because of the ads’ closer integration with the content.</p>
<h2>Make Sure Customers Can Easily Distinguish Ads from Content</h2>
<p>When taken to the extreme, the guideline to better integrate ads and content becomes a design antipattern. Customers’ being unable to distinguish ads from content becomes especially painful and disruptive when a Web site carries a large number of ads. For example, on Fishing.com, as pictured in Figure 3, there are so many closely integrated ads that they become virtually indistinguishable from the content—to the extent that it becomes difficult to understand what service the site actually provides.</p>
<p>Figure 3—Ads on Fishing.com are overwhelming and confusing.</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/10/images/figure_3_fishing_com.png" alt="Confusing ads on Fishing.com" width="474" height="479" /></p>
<p>However, even if the number of ads on your site is not overwhelming, customers can have difficulty distinguishing them from content. One very common problem is providing different types of search results—some of which stay on the same site, while others take customers elsewhere. (We should note that surprising customers about where links go is <em>never</em> a problem for Google or other Web search engines, because both their ads and their search results take searchers to other sites.)</p>
<p>On the other hand, for destination sites that sell their own merchandise or provide a branded service, while also hosting third-party ads, it is important to positively differentiate between ads, legitimate content, and featured—that is, paid—results. Autotrader.com, which is pictured in Figure 4, mixes many different types of search results together, so it’s hard to tell what clicking each result might do. Orange results are actual, “organic” search results, while the slightly padded results in blue are really paid advertisements.</p>
<p>Figure 4—Autotrader.com mixes many different types of search results.</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/10/images/figure_4_autotrader2.png" alt="Many types of results on AutoTrader" width="468" height="605" /></p>
<p>When clicking a search results link takes searchers somewhere surprising or, by mistake, they click a featured result, their reaction is often very negative. Yet, to the extent that a link satisfies a customer’s need, clicking it can be a very positive experience—finding exactly what the customer was looking for. The key to solving this problem is <em>grouping</em> the different kinds of content, while making it clear what are paid advertisements or featured results and clearly differentiating paid content from organic search results through subtle, but telling visual cues.</p>
<p>Colin Ware, in his book <em>Information Visualization: Perception for Design</em> describes so-called <em>preattentive attributes</em>, which involve the early stage of visual perception that occurs mostly below the level of conscious thought, at a very high speed. He distinguishes four categories of preattentive attributes: form, color, spatial position, and motion. We can apply the grouping strategies for all four categories of these attributes to ads, typically using line size, shape, hue, and enclosure to subtly differentiate ads from content. Motion applies mainly to animated ads, which can be an appropriate differentiation strategy, depending on their content. (We will discuss this further in Part 2.)</p>
<p>Google’s search results provide a great example of subtle preattentive differentiation. As shown in Figure 2, Google displays three kinds of results on search results pages:</p>
<ul>
<li>ads at the top—Their subtle, yellow background hue differentiates them from the organic results.</li>
<li>organic search results in the middle—These are the actual content.</li>
<li>ads in the column on the right—Their placement and narrow column format differentiate them from the organic results, plus a vertical line sets them off.</li>
</ul>
<p>Overall, the results on this page fit together and flow really well, while the ads’ formats subtly, but unequivocally differentiate them from the content.</p>
<p>Customers’ ability to effectively differentiate various types of content diminishes as the numbers of different types and sources of content appearing on a page increase—even when the content is grouped appropriately and visually integrated, using the site’s colors and fonts. At some point, a search results page simply reaches its point of saturation, and it becomes impossible for customers to tell the different types of search results apart. When doing usability studies for a major etailer that provided ten different types of search results, Greg found that most test participants could <em>not</em> distinguish one type of result from another when scrolling through search results pages. Thus, the experience became overwhelming for people using the site, who were often frustrated, because they never knew where they were about to go when they clicked a search result.</p>
<p>Buy.com, pictured in Figure 5, is another site that is oversaturated with different types of search results and ad content. There are at least 13 different formats for third-party ads on a single page! No surprise, the site rating service <a title="Internet Retailer" href="http://ak.buy.com/buy_assets/v7/img/Hot100Buy.pdf"><em>Internet Retailer</em></a><a title="Internet Retailer" href="http://ak.buy.com/buy_assets/v7/img/Hot100Buy.pdf"><img src="http://www.uxmatters.com/mt/archives/images/pdflogo.gif" alt="" width="37" height="16" /><img src="http://www.uxmatters.com/mt/archives/images/new-window-arrow.gif" alt="" width="14" height="12" /></a> commented, “The site all but overwhelms its visitors with information and options.”</p>
<p>Figure 5—Buy.com’s different types of ads and third-party content are overwhelming.</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/10/images/figure_5_buy2.png" alt="Overwhelming ads on Buy.com" width="455" height="538" /></p>
<p>For your search results pages to be effective, they must display only a limited number of different types of content and ad formats. Otherwise, with no clear guidance, your main content gets lost and customers become confused, because they are overwhelmed by the number of things competing for their attention. The key to integrating ads into your search results, <em>without</em> destroying the finding experience is becoming really clear about what generates the most site revenue. Is it the ads? Or the content? Does it depend on the query? Have you made the costly mistake of serving as many ads to your top customers as you do to window-shoppers and people who just happen to drop by? Once you’ve answered these key questions, you must remain disciplined and stay focused on your core earning potential. Though you can provide occasional, helpful third-party content on the side—particularly, if it helps a customer make a decision.</p>
<p>For example, can you tell whether Buy.com makes more money if people buy the headphones shown on the page—or instead investigate how to make their sandwiches moist and juicy with Best Foods Mayonnaise? Or maybe Buy.com <em>really</em> rolls in the dough when people buy their headphones from eBay or Dell instead? From their page content and layout, it is impossible to tell. One gets the impression that Buy.com may itself be somewhat confused about where the bulk of their revenue is coming from.</p>
<h2>Keep Ads Relevant and Appropriate</h2>
<p>While many people are, at best, only dimly aware of ads, some ads are so toxic that hosting them can damage your brand perception and destroy the entire user experience of your site. While everyone, no doubt, has his or her own list of the most annoying advertisements ever, one of Greg’s favorite examples is the infamous animated popup ads featuring the X10 spy cam that became popular in the early 2000s. The ad was, at once, so annoying and so ubiquitous, that X10 bears the dubious distinction of having been one of the first companies to get people to register on the company Web site <em>just</em> to <a title="opt out" href="http://www.x10.com/pressroom/press2_aa_msnbc_x10.htm">opt out</a><a title="opt out" href="http://www.x10.com/pressroom/press2_aa_msnbc_x10.htm"><img src="http://www.uxmatters.com/mt/archives/images/new-window-arrow.gif" alt="" width="14" height="12" /></a> from seeing their ads for 30 days. Figure 6 shows one version of the X10 ad.</p>
<p>Figure 6—The infamous X10 popup ads were some of the most annoying ever.</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/10/images/figure_6_x10.png" alt="Infamous popup ads" width="470" height="193" /></p>
<p>Even though ads may not be utterly obnoxious, they can nevertheless be completely inappropriate. Ad placement is often the key. FoxNews.com, which is pictured in Figure 7, shows just how insensitive and inappropriate some ads can be.</p>
<p>Figure 7—The insensitivity of inappropriate ads on FoxNews.com is striking.</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/10/images/figure_7_fox_news.png" alt="Insensitive ads on Fox News" width="472" height="429" /></p>
<p>The news story on the page describes the accidental death of a Marine, yet ads for yellow teeth litter the page. Putting politics aside, how do you think the dead person’s family felt when viewing this story? How about all the other families who have fathers, husbands, sons, or daughters serving overseas? Please, make sure your ads are appropriate to the content on a page. One way of doing that is to conduct user research and learn how your customers react to particular ads.</p>
<h2>Understand How Your Customers Interact with Ads</h2>
<p>Although usability studies and field research can give us important clues about how people interact with ads, eyetracking research can be especially helpful. Eyetracking studies help us to understand <em>how</em> customers perceive and interact with ads, then, depending on our objectives, design ads intelligently—to either catch or <em>not</em> catch their attention. Let’s look at an ad user experience that is different from the typical user experience. Customers definitely <em>don’t</em> come to a site just to look at ads, so they pay attention to them only in a spontaneous, but not intentional way. Thus, it’s hard to ask them about whether they paid attention to ads, because they probably won’t be 100% sure. Eyetracking can fill this gap in our knowledge.</p>
<p>By meticulously tracking <em>all</em> eye movement during a test, you can tell whether and how a participant pays attention to the ads on a Web page, what visual search pattern he uses, and how he either skips or focuses on particular information on the page. (Note—When running eyetracking studies, spontaneity is key. If you interrupt a participant, ask questions, or have a broken prototype that doesn’t let a participant interact with it naturally, your eyetracking data gets contaminated with all sorts of noise.)</p>
<p>So, what does eyetracking methodology tell us about ads? First and foremost, we’ve observed the well-documented <em>banner blindness</em>—that is, customers typically ignore static banners—which are often located at the top of a Web page—even if they are of a ridiculously large size like those on Tutorialized.com, which are shown in Figure 8. Though research clearly shows people usually ignore banner ads, the banner ads on that site take up the entire area of the page above the fold, negatively impacting the user experience and forcing customers to scroll.</p>
<p>Figure 8—Banner ads on Tutorialized.com take up the entire window.</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/10/images/figure_8_tutorialized.png" alt="Huge banner ads" width="474" height="292" /></p>
<p>As Jakob Nielsen wrote in his August 20, 2007 <a title="Alertbox" href="http://www.useit.com/alertbox/banner-blindness.html"><em>Alertbox</em></a>,<a title="Alertbox" href="http://www.useit.com/alertbox/banner-blindness.html"><img src="http://www.uxmatters.com/mt/archives/images/new-window-arrow.gif" alt="" width="14" height="12" /></a> “The most prominent result from the new eyetracking studies is not actually new. We simply confirmed for the umpteenth time that banner blindness is real.”</p>
<p>At this point, you may ask <em>What makes a good advertisement?</em> An excellent question we will answer—along with providing some other useful guidelines—in Part 2 of this column on <em>UXmatters</em> next month. Be sure to stay tuned for our thrilling conclusion!<a title="Top" href="http://www.uxmatters.com/mt/archives/2009/10/make-more-money-best-practices-for-ads-in-search-results-part-1.php#top"><img src="http://www.uxmatters.com/mt/archives/images/ux-bug.gif" alt="" width="18" height="18" /></a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.designcaffeine.com/2010/articles/216/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Best Practices for Designing Faceted Search Filters</title>
		<link>http://www.designcaffeine.com/2010/articles/213/</link>
		<comments>http://www.designcaffeine.com/2010/articles/213/#comments</comments>
		<pubDate>Tue, 19 Jan 2010 21:46:02 +0000</pubDate>
		<dc:creator>Greg Nudelman</dc:creator>
				<category><![CDATA[Articles]]></category>
		<category><![CDATA[Faceted Search]]></category>
		<category><![CDATA[Filters]]></category>
		<category><![CDATA[Finding]]></category>
		<category><![CDATA[Search Matters]]></category>

		<guid isPermaLink="false">http://www.designcaffeine.com/?p=213</guid>
		<description><![CDATA[Originally published on UXMatters.com on September 7, 2009 ⇒
Recently, Office Depot redesigned their search user interface, adding attribute-based filtering and creating a more dynamic, interactive user experience. Unfortunately, Office Depot’s interaction design misses some key points, making their new search user interface less usable and, therefore, less effective. That’s the bad news. The good news [...]]]></description>
			<content:encoded><![CDATA[<p><a title="Read this article on UXMatters (Opens in a New Window)" href="http://www.uxmatters.com/mt/archives/2009/09/best-practices-for-designing-faceted-search-filters.php" target="_blank">Originally published on UXMatters.com on September 7, 2009 ⇒</a></p>
<p>Recently, Office Depot redesigned their search user interface, adding attribute-based filtering and creating a more dynamic, interactive user experience. Unfortunately, Office Depot’s interaction design misses some key points, making their new search user interface less usable and, therefore, less effective. That’s the <em>bad</em> news. The <em>good</em> news is that the Office Depot site presents us with an excellent case study for demonstrating some of the important best practices for designing filters for faceted search results, as follows:</p>
<ol>
<li>Decide on your filter value-selection paradigm—either drill-down or parallel selection.</li>
<li>Provide an obvious and consistent way to undo filter selection.</li>
<li>Always make <em>all</em> filters easily available.</li>
<li>At every step in the search workflow, display <em>only</em> filter values that correspond to the available items, or inventory.</li>
<li>Provide filter values that encompass <em>all</em> items, or the complete inventory.</li>
</ol>
<p>By following the attribute-based filtering design best practices this article describes, you can ensure your customers can take care of business <em>without</em> having to spend time struggling with your search user interface.<span id="more-213"></span></p>
<h2>1. Choose either drill-down or parallel selection.</h2>
<p>There are two basic ways of selecting values for filters: drill-down and parallel selection. Ignoring the various modalities of the many derivative mechanisms for these primary modes of selection, the two basic ways of specifying a value for a filter essentially boil down to two choices: links and check boxes.</p>
<p>A <em>link</em> is the simplest mode of filter selection. By clicking a link, a customer can either select a single value for a specific filter or drill down a level in a taxonomy, like a category or department hierarchy. Amazon.com, shown in Figure 1, provides one of the best examples of a search results user interface that uses links to indicate filter value selections. Links usually indicate a straightforward <em>equals</em> condition—for example, <em>I want to narrow my search results to Department = Books</em>—as they do on Amazon.</p>
<p>Figure 1—On Amazon, links let customers indicate a single filter value</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/09/images/figure_1.png" alt="Link filters on Amazon" width="474" height="471" /></p>
<p>In contrast to links, which let customers indicate a <em>single</em> filter value, check boxes let customers indicate parallel selections of <em>multiple</em> filter values, limiting the scope of search results to those that match them. The Kayak.com search user interface, shown in Figure 2, uses check boxes to limit search results to specific airlines. As on Kayak, check boxes typically indicate an additive <em>OR</em> condition—for example, <em>I want to narrow the search results to: Airline = American OR Delta OR United</em>.</p>
<p>Figure 2—Kayak airline selector uses check boxes to select multiple values</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/09/images/figure_2.png" alt="Multiple filter values on Kayak" width="473" height="639" /></p>
<p>Links and check boxes complement one another very well. Links are great where customers need to display multiple levels in a hierarchy—for example, multilevel category drill-downs. Check boxes are great for selecting one or more options for attributes like brands or sizes. Unfortunately, not all Web sites use these two value-selection paradigms correctly.</p>
<p>As shown in Figure 3, the Office Depot user interface uses check boxes for indicating value selections, leading customers to expect a <em>parallel</em> selection paradigm, in which they could indicate they want to search multiple price ranges by clicking several check boxes. For example, to find chair mats that are priced from $0 to $100, you might expect to be able to select the price filter’s first two check boxes. Thus, after clicking the <strong>$50-$100</strong> check box, you would expect to retain the ability to select the <strong>$50 and below</strong> check box.</p>
<p>Figure 3—Office Depot mixes the drill-down and parallel selection paradigms</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/09/images/figure_3.png" alt="Office depot mixes selection paradigms" width="474" height="625" /></p>
<p>However, once a customer selects the <strong>$50-$100</strong> check box, the Office Depot search user interface does something <em>completely</em> unexpected. It drills down into the $50-$100 price range and <em>removes</em> the <strong>$50 and below</strong> check box, breaking the affordance of a group of check boxes that should let customers select multiple, parallel <em>OR</em> values for a single filter. Instead, the user interface now displays <strong>$50-$60</strong> and <strong>$60-$70</strong> ranges, while still displaying the range of <strong>$50-$100</strong> the customer originally selected as one of the available <em>OR</em> values. Mixing the drill-down and parallel selection paradigms results in a very confusing search user interface.</p>
<p>Another confusing thing about the Office Depot user interface is that it does <em>not</em> provide any obvious way to deselect filters and return them to their original, pre-filtered state. This brings us to the next best practice: providing an obvious undo mechanism.</p>
<h2>2. Provide undo for filter selections.</h2>
<p>Both Amazon and Kayak—pictured in Figures 1 and 2, respectively—provide a clear and consistent way to undo a filter value selection and go back to <em>All</em> or <em>Any</em> for a specific filter. For example, Amazon provides a link to <strong>Any Department</strong>. Notice that the link is offset to the left, and a less than (&lt;) symbol helps customers understand that this particular link <em>goes back</em>.</p>
<p>Under <strong>Airlines</strong> in Figure 2, you can see that Kayak solves the undo problem by letting customers click an <strong>All</strong> check box to view flights from all of the available airlines. Note that the Kayak undo is slightly less clear than that in the Amazon user interface, primarily because the <strong>All</strong> check box is neither highlighted in any way nor separated from the rest of the check box options. Instead Kayak highlights the airline that offers the best price. While not standard, this is hardly something that would cause undue confusion.</p>
<p>On the other hand, the Office Depot user interface, shown in Figure 3, does <em>not</em>, at first glance, provide an obvious way of undoing the selection of the <strong>$50-$100</strong> price filter. There <em>is</em> actually a mechanism that lets customers do this, but it is <em>not</em> at all obvious. The way for a customer to return to <em>Any</em> price is to <em>deselect all</em> filter selections. While this design may be completely valid from a computer’s standpoint, deselecting all check boxes does <em>not</em> effectively communicate the concept of <em>All Prices</em> to a person using the user interface. It would be much more effective to provide an <em>All</em> or <em>Any</em> option.</p>
<p>There <em>are</em> sites that use the deselect-to-undo paradigm successfully—one fine example is Yelp.com. However, sites that use deselect-to-undo typically take special steps to ensure consistency in the filter value options that do <em>not</em> change based on other filter selections.  For example, instead of <em>removing</em> options, the Yelp user interface makes certain filter values <em>unavailable</em> to indicate lack of inventory availability. Items that are unavailable appear dimmed, as shown in Figure 4.</p>
<p>Figure 4—Yelp ensures consistency in its deselect-to-undo paradigm</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/09/images/figure_4.png" alt="Deselecting to undo on Yelp" width="474" height="242" /></p>
<p>However, in cases where consistency is difficult to achieve, it is a far safer option to use <em>Any</em> or <em>All</em> to undo filter selections, particularly when a filter’s value options are dynamic. As shown in Figure 5, when a user deselects filters out of sequence on the Office Depot site, even more confusion results.</p>
<p>Figure 5—On Office Depot, the order in which filter options are deselected matters</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/09/images/figure_5.png" alt="Deselecting filters on Office Depot" width="473" height="666" /></p>
<p>The Office Depot user interface is particularly sensitive to the order in which a user deselects the check boxes for a single filter. For example, the price filter option <strong>$50-$100</strong> simply disappears if a user deselects it before deselecting the <strong>$50-$60</strong> filter option. A customer would have to click the browser’s <strong>Back</strong> button twice to undo both selections, because there is <em>no</em> other way to return to the default state. Typically, <em>all</em> of the available filters and options, plus the data that appears on a page can change after each click. The key is to avoid completely <em>removing</em> options in the <em>same</em> filter where a click took place.</p>
<h2>3. Always make <em>all</em> filters easily available.</h2>
<p>Please don’t misunderstand me. I am <em>not</em> saying <em>all</em> filters should be <em>visible</em> at the same time. It is perfectly acceptable to collapse filters to just a label, providing a single link like <strong>View All Filters</strong>, or to display previously selected filtering options in a unique way. However, if at different steps in the search workflow, filters start randomly disappearing from the search user interface with <em>no</em> way to bring them back, bad things start to happen very quickly.</p>
<p>Figure 6 shows what happens to the Office Depot search results when a user selects the option <strong>Red</strong> in the <strong>Color</strong> filter. As you can see, once a user selects a color, <em>all</em> of the other filters disappear entirely.</p>
<p>Figure 6—On Office Depot, filters disappear randomly</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/09/images/figure_6.png" alt="Filters disappear on Office Depot" width="474" height="332" /></p>
<p>Does this system behavior make any sense? Let’s say I want to buy a red chair mat. Under <strong>Color</strong>, I can select the <strong>Red</strong> check box and view a great variety of red chair mats. Is there really a compelling reason for me to do anything else with the color filter? Will I, as a true connoisseur of all things red, perhaps drill down into shades of red for my chair mat, such as Burgundy, Farmhouse Red, or Ripe Tomato? Not very likely—at least not for chair mats. Instead, I am <em>much</em> more likely to say, okay, these are all of the red chair mats. Great! Now, can I select a mat from a known brand? Or perhaps I would like a budget-priced mat, so I need to further constrain my search by price. Or maybe I am a stupendous fan of the Ohio Buckeyes and want to find a chair mat with my team logo, leaving fans of the Michigan Wolverines green with envy. Using other filters to continue massaging my <em>red chair mats</em> query is a far more likely scenario.</p>
<p>Alternatively, let’s consider a different use case: I just selected <strong>Red</strong>, and now I can see a bunch of red chair mats. Almost immediately, I realize these red chair mats are almost, but <em>not</em> quite, entirely unlike the mat I actually want to buy. So, I immediately attempt to seek out two things:</p>
<ol>
<li>a way to undo my most recent selection</li>
<li>a way to review what other filtering options I might want to use</li>
</ol>
<p>Unfortunately for both these use cases, when I selected a color, the Office Depot search user interface unhelpfully <em>removed</em> all other filters. This action would be tantamount to Kayak’s removing <em>all</em> other filters like departure and arrival times, number of stops, price, and class whenever a customer selected a particular airline. How helpful do you think that would be to someone trying to find a flight? Removing <em>any</em> filters completely can be detrimental to customer success and is, therefore, <em>not</em> recommended. If you really feel compelled, for some reason, to minimize the screen real estate you devote to filters, you can collapse individual filters or hide their options temporarily under a <strong>More Options</strong> link.</p>
<h2>4. Display <em>only</em> filter values that apply to the available inventory.</h2>
<p>I touched on the idea of showing <em>only</em> options and links that actually point someplace useful in my first <em>UXmatters </em>column, “<a title="Starting from Zero: Winning Strategies for No Search Results Pages." href="http://www.uxmatters.com/mt/archives/2009/02/starting-from-zero-winning-strategies-for-no-search-results-pages.php">Starting from Zero: Winning Strategies for No Search Results Pages</a>.” At every step in the search workflow, any visible filtering options should reflect <em>only</em> the inventory that is available. This is dependent on a customer’s previous actions—both the keywords in the original query and the other filtering selections. As shown in Figure 7, the chair mat color selections expand to reveal tasty color choices like Maple Pale and Cherry Spice. Selecting Maple Pale and Red together <em>should</em> give us <em>both</em> red and Maple Pale chair mats. Unfortunately, the user interface does <em>not</em> seem capable of supplying Maple Pale chair mats, because, when the page reloads, it displays the same five <em>red</em> chair mats.</p>
<p>Figure 7—Office Depot shows color selections that are <em>not</em> applicable to a query</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/09/images/figure_7.png" alt="Office Depot shows options that aren't applicable" width="474" height="622" /></p>
<p>This idea seems really obvious, but quite a few otherwise first-rate sites seem to miss it. Often, the underlying issue is technical. On many sites with Ajax search user interfaces, pages retrieve and recompute all the summary data for all filter values in response to each change a customer makes, so speed becomes a primary concern. For many legacy systems, the demands of just-in-time data delivery are simply too much. At the end of their development cycle, developers are often frustrated to find that, despite their best efforts, their aging systems simply <em>cannot</em> deliver the speed necessary to retrieve <em>all</em> the filtering options, plus the items themselves, plus the data for pagination, in a single Ajax call. In such an event, rather than redesigning the system from scratch to address the root cause of this problem, developers often end up taking shortcuts—either</p>
<ul>
<li>caching <em>all</em> of the filters <em>or</em></li>
<li>providing a generic list of  values that may or may <em>not</em> be applicable to the specific query at hand—like the color values on Office Depot</li>
</ul>
<h2>5. Provide filter options that encompass the <em>complete</em> inventory.</h2>
<p>An equally important point is that we must <em>always</em> strive to design every filter to include a list of options that encompasses the <em>entire</em> available inventory. Let me give you an example. As you can see in Figure 7, the color filter in the Office Depot search user interface does <em>not</em> display the most common chair mat color, which is <em>clear</em>. Therefore, once a user clicks any of the color options, the site can display only a fraction of the available inventory—in this case, only 16 of 23 available items. The seven chair mats that are clear have <em>no</em> color attribute, so customers can never <em>choose</em> to view <em>only</em> those items using the Office Depot user interface. Instead, by specifying a color value, they unknowingly <em>remove</em> clear mats from consideration. This system behavior is clearly <em>not</em> beneficial to someone looking for a chair mat—especially if they are looking for the most common variety.</p>
<p>I am not sure what Office Depot’s reason for omitting <em>clear</em> from their color options might be, but it is reasonable to assume that the clear chair mats have the color attribute of empty, or null. Therefore, it is not possible to group these items under a valid color filter attribute. Fortunately, one fairly straightforward way to resolve any missing or inconsistent data is to include <strong>Other</strong> or <strong>All Others</strong> as a filter option. The SQL condition corresponding to <strong>Other</strong> should specifically include any items for which the color field is empty, or null, enabling customers always to view the entire inventory by using some combination of the available filter selections.</p>
<p>Often, there are more options for a given filter than you can show at once. Typically, best practice tells us to show 4 to 7 options for each of the filters. If there are too many options to display, it is often desirable to hide the rest of the options in a <strong>More Choices</strong> panel or popup. In this case, <strong>Other</strong> might be an option that shows up only once a customer is viewing the additional options. Specific queries dictate where to show each particular option. In our example, given the popularity of clear chair mats, I think <strong>Other</strong> should be at or very near the top. However, regardless of their order, it is critical to include <em>all</em> of the options that encompass the complete inventory. This is especially important in cases where there is no <em>All</em> or <em>Any</em> undo option—as in the Office Depot search user interface. Otherwise, we risk making some of the most popular items on a site unfindable.</p>
<h2>In Conclusion</h2>
<p>Faceted search user interfaces are fairly new, and potential design pitfalls abound. Fortunately, there are a few relatively simple and straightforward design best practices that should help designers to minimize cognitive friction and create search user interfaces that are easy to understand and use.</p>
<p>In this column, I’ve presented five best practices for designing filters for faceted search results. Of these, I think the first—choosing either drill-down or parallel selection—is the most important. If you choose your filter value-selection paradigm correctly, you are already half way there.</p>
<p>Whichever filtering paradigm you decide to implement, be sure to test your search results user interfaces thoroughly with both your potential and existing customers. I cannot overemphasize the importance of testing search user interfaces using realistic tasks. If your budget allows, it is best to avoid predefined search tasks. Instead, study how real people find items they are actually interested in—preferably in an environment where they would normally do the kind of searches you want to study. When designing search user interfaces, field studies are a crucial tool for continually making and validating design improvements—not just something you do as a formality at the end of a project.<a title="Top" href="http://www.uxmatters.com/mt/archives/2009/09/best-practices-for-designing-faceted-search-filters.php#top"><img src="http://www.uxmatters.com/mt/archives/images/ux-bug.gif" alt="" width="18" height="18" /></a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.designcaffeine.com/2010/articles/213/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Brave New World of Visual Browsing</title>
		<link>http://www.designcaffeine.com/2010/articles/210/</link>
		<comments>http://www.designcaffeine.com/2010/articles/210/#comments</comments>
		<pubDate>Tue, 19 Jan 2010 20:55:25 +0000</pubDate>
		<dc:creator>Greg Nudelman</dc:creator>
				<category><![CDATA[Articles]]></category>
		<category><![CDATA[Finding]]></category>
		<category><![CDATA[images]]></category>
		<category><![CDATA[iPhone]]></category>
		<category><![CDATA[Mobile]]></category>
		<category><![CDATA[Search Matters]]></category>
		<category><![CDATA[Visual Browse]]></category>

		<guid isPermaLink="false">http://www.designcaffeine.com/?p=210</guid>
		<description><![CDATA[Co-written with Ahmed Riaz ⇒
Originally published on UXMatters.com August 3, 2009 ⇒
When the Web began, pages were mostly text, but today, everywhere we look, it seems like image content is taking over the Web. The ubiquitous use of digital cameras and improvements in the picture quality of mobile phone cameras has likely helped this phenomenon [...]]]></description>
			<content:encoded><![CDATA[<p><a title="Visit AhmedRiaz.com (Opens in a New Window)" href="http://ahmedriaz.com/mind/" target="_blank">Co-written with Ahmed Riaz ⇒<br />
</a><a title="Read this article on UXMatters (Opens in a New Window)" href="http://www.uxmatters.com/mt/archives/2009/08/brave-new-world-of-visual-browsing.php" target="_blank">Originally published on UXMatters.com August 3, 2009 ⇒</a></p>
<p>When the Web began, pages were mostly text, but today, everywhere we look, it seems like image content is taking over the Web. The ubiquitous use of digital cameras and improvements in the picture quality of mobile phone cameras has likely helped this phenomenon along. The shift toward content that is primarily visual introduces new challenges and opportunities for developing intuitive and powerful user interfaces for browsing, searching, and filtering visual content. To help me cover this important topic, I’ve asked Ahmed Riaz—Interaction Designer at eBay and physical interaction design enthusiast—to contribute his insights and ideas.<span id="more-210"></span></p>
<h2>Introducing Visual Browsing</h2>
<p>What, you may ask, is visual browsing? Loosely defined, <em>visual browsing</em> user interfaces are those that let people navigate visual content—that is, search for content using pictures. We will discuss four types of visual browsing:</p>
<ol>
<li>browsing images or photos using text attributes or tags—for example, on Google Images and Flickr</li>
<li>using images in queries to describe attributes that are hard to describe with text—as on Like.com and Zappos</li>
<li>using images to facilitate wayfinding and navigation in the real world—such as on Google Maps and Photosynth</li>
<li>collecting and browsing images on mobile devices—like on RedLaser and NeoReader</li>
</ol>
<p>Each of these approaches to visual browsing supports different goals for searchers and introduces its own unique challenges, design directions, and best practices, which we’ll explore next.</p>
<h2>Browsing Images Using Text Attributes or Tags</h2>
<p>While there are many image-centric sites, the majority of the Web’s image content is on either Google Images or Flickr. No discussion of visual browsing would be complete without mentioning these two sites. When it comes to <em>finding</em> images that are published somewhere on the Web, Google Images is the site most people go to. Google uses a proprietary algorithm to assign keywords describing each image, then index and rank <em>all</em> of the images in their enormous database. They also capture a thumbnail of each image and store it along with the source URL.</p>
<p>While Google Images is undeniably a very useful site, it exemplifies some of the challenges of automated image finding. The primary mechanism for finding images is a text-only query, which perfectly demonstrates the impedance mismatch that exists between text and image content. Because <em>no</em> single keyword can adequately describe <em>all</em> of the pixels that make up an image—and, most of the time, the keywords that surround an image on a page provide an incomplete description at best—Google Images interprets search queries very loosely. Typically, it interprets multiple keywords using an OR instead of the usual and expected AND operator. As a consequence, it omits some keywords from the query <em>without</em> letting the searcher know explicitly what is happening.</p>
<p>On the one hand, because Google Images interprets search queries in a such a loose fashion, it rarely returns zero search results. On the other hand, image searches sometimes give us strange and unpredictable results, while making it challenging to understand what went wrong with our queries and how to adjust them to find the images we’re really looking for. Figure 1 shows an example—the search results for <em>Africa Thailand elbow Indian</em>.</p>
<p>Figure 1—Google Images search results for <em>Africa Thailand elbow Indian</em></p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/08/images/figure_1_google_images.png" alt="Google Images search results" width="466" height="486" /></p>
<p>Judging from the search results, Google Images seems to have omitted keywords randomly from   the query, <em>without</em> indicating to the searcher it has done so. Of course, one could argue that getting such poor results for a query is an example of garbage in/garbage out. However, we think this example demonstrates that the keywords Google takes from the surrounding content on a Web page—and possibly some Web pages that link to it—do <em>not</em> always match an image. While an image may <em>technically</em> be located at the intersection of <em>Africa, Thailand, elbow,</em> and <em>Indian,</em> this by <em>no</em> means guarantees that the image would actually <em>show</em> Indian warriors demonstrating the perfect Mai Thai elbow-strike technique on the plains of the Serengeti.</p>
<p>Plus, a computer-generated index usually makes <em>no</em> distinction between the different possible meanings of an image’s surrounding keywords—for example, a search engine can’t tell when an image appears in juxtaposition to text to add humor. Nor do automated indexing engines handle images well when they have purposes other than providing content—such as images that add visual appeal or bling or those for marketing or advertising. Such image content is, at best, orthogonal to its surrounding text.</p>
<p>Image search filters that are based on text are, at the moment, <em>not</em> particularly robust. For example, Figure 2 shows Google Images search results for <em>iPhone</em> with some filters applied. As you can see, the resulting images have <em>little</em> to do with the iPhone.</p>
<p>Figure 2—Google Images filtered search results for <em>iPhone</em></p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/08/images/figure_2_google_images_iphone.png" alt="Search results for iPhone" width="472" height="532" /></p>
<p>As a photo-hosting site, Flickr enjoys the distinct advantage of having <em>people</em> rather than computers look at, interpret, and tag the images they create and view. Users can search for images by their tags. While Flickr is <em>not</em> a perfect image-searching system, it provides an entirely subjective, human-driven method of interpreting and describing images. Why is that valuable?</p>
<p>According to Jung’s conception of the <em>collective unconscious,</em> we can assume <em>all</em> individuals experience the same universal, archetypal patterns. These archetypes influence our innate psychic predispositions and aptitudes, as well as our basic patterns of human behavior and responses to life experience. Likewise, at the root of <em>all</em> folksonomies is the inherent assumption that people—when we look at them collectively—tend to respond in similar ways when presented with the same stimuli. Simply put, people looking for images of cats would be quite happy to find the images that a multitude of other people have taken the time to tag with the word <em>cat</em>.</p>
<p>As Gene Smith describes in his book, <em>Tagging: People-Powered Metadata for the Social Web,</em> folksonomies and tagging usually work quite well—in most cases, nicely resolving the kinds of issues that occur in Google Images due to auto-indexing, which we described earlier. Unfortunately, the <em>human</em> element also introduces its own quirks along the way. Take a look at the example of a Flickr image shown in Figure 3.</p>
<p>Figure 3—One of the most interesting Flicker images tagged with <em>iPhone</em></p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/08/images/figure_3_flickr.png" alt="Flickr images tagged with iPhone" width="468" height="555" /></p>
<p>Among almost 2 million Flickr images tagged <em>iPhone</em>, Flickr considers this image one of the most interesting, with 785 favorites and 37 comments. As you can see at the bottom of the page, one of the problems with having a community-driven popularity algorithm is that some people post nonsense comments just to be able to say they’ve added a comment to a popular item.</p>
<p>Another problem has to do with tags that are strictly personal. For example, tags like <em>GOAL:EXPLORE!</em> and <em>hawaalrayyanfav</em> have meaning <em>only</em> to the person who actually tagged the item—and little or nothing to the population at large. On the other hand, adding tags like <em>funny</em> and <em>humor</em> is actually quite useful, because computers don’t recognize humor at all. In fact, humor is the aspect of image description where algorithm-based search results fail most spectacularly. We’ll talk more about folksonomies, controlled vocabularies, and searching for tags in future columns. For now, we’ll just say that <em>neither</em> way of finding images—through text tags or associated surrounding text—is perfect, and there is a great deal of room for improvement, perhaps through combining both search approaches, using a single algorithm and a user interface that does <em>not</em> yet exist.</p>
<h2>Using Images in Queries</h2>
<p>We think one of the most intriguing aspects of visual browsing user interfaces has to do with the mismatch between images and the text algorithms or people use to describe them. They highlight the inherent limitations of finding and managing images through text-based queries. Typically, a person sees an object, determines what to call it, then tries a few keyword searches based on that interpretation. Adding a photo to a query lets a searcher bypass the interpretation step and just let the computer <em>see</em> what the query is about.</p>
<p>On the Web, one of the more successful examples of image-based search is the shopping site Like.com, which lets searchers use images as part of their queries to describe the attributes of items that are difficult, if not impossible, to describe precisely using text alone.</p>
<p>While Like.com has some issues when it comes to presenting good entry points into their enormous inventory for people who like to browse, once you find an item you’re interested in, the search engine is absolutely <em>phenomenal</em> at picking up visually similar items. For example, Figure 4 shows the results for an image-based search that is based on a picture of a striped shirt. The algorithm is smart enough to explore useful and popular degrees of freedom, deviating from the starting image, while keeping the <em>zeitgeist</em> of the original image intact.</p>
<p>Figure 4—Like.com image-based search results</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/08/images/figure_4_like_com_v2.png" alt="Like.com image-based search results" width="473" height="184" /></p>
<p>In addition to doing a great job of exploring the possible degrees of freedom from the original image, the system lets shoppers fine-tune their queries to match a specific part of an image by zooming in on the part they’re interested in. This is very similar to selecting part of an image on Flicker and tagging <em>only</em> that part of the image. For example, a user could tag a person in an image as <em>friend</em> and a snake in the image as <em>giant anaconda,</em> while naming the entire image <em>The last-known picture of Billy</em>—hopefully adding the tag <em>humor</em>, while he is at it. As images become more ubiquitous on the Web—and generate evermore layers of meaning—being able to select and annotate only part of an image will become more and more important in a visual browsing user interface.</p>
<p>The Like.com search algorithm can relax different attributes, including color, pattern, and shape, as well combine image searching with text attributes, demonstrating the potential of image-based searching and browsing.</p>
<p>While government sources can neither confirm nor deny this, the Department of Homeland Security is allegedly interested in image-based search technologies, mainly in regard to facial recognition. However, as Munjal Shah, CEO and Cofounder of Riya told the audience at the MIT/Stanford Venture Lab’s <a title="Next Generation Search Symposium" href="http://www.vlab.org/article.html?aid=121">Next Generation Search Symposium</a> in 2007, commercial-grade facial recognition technology is <em>not</em> quite there yet. Such search algorithms can generally recognize which part of an image is a human face and venture a fairly accurate guess at a person’s gender, but recognizing a specific face requires matching the precise expression and angle of the face in a photograph with the sample, which can often be difficult. Despite these limitations, the potential of image-based search technology is enormous.</p>
<p>Does a user interface need to have a true visual-search algorithm to perform image-based search? Although technology helps, it does not afford the <em>only</em> way of performing a visual browse. One alternative is to have a human being tag items, using abstract visual attributes—such as a range of icons or outlines of shapes, using limited screen real estate—that, in turn, would let customers describe their visual queries. This kind of a pseudo-image-based search could, for example, successfully complement the existing <em>people who shopped for X, also shopped for Y </em>metrics-based algorithm.</p>
<h2>Using Images for Navigating in the Real World</h2>
<p>By now, most people are familiar with  street view in Google Maps, which is pictured in Figure 5.</p>
<p>Figure 5—Google Maps street view</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/08/images/figure_5_google_maps.png" alt="Google Maps street view" width="474" height="339" /></p>
<p>Using this phenomenal technology is <em>almost</em> like being there, with virtual-reality controls for navigating through nearly continuous photos of real space. Google Maps is an excellent example of automated sense-making of images, using precise GPS coordinates. Visual browsing controls let users walk, turn around, and jump through real space, using virtual projection. However, as anyone who has looked up their street and their house can tell you, these pictures are frozen in time. Some people can even tell you when the Google Maps picture of their house was taken, because a friend’s car was captured in the satellite photo.</p>
<p>In contrast—or perhaps as a complement to Google Maps—Photosynth, Microsoft’s new acquisition, uses crowd-sourced photographs to construct and let users navigate through 3D street-level space. It can also add the fourth dimension of navigating through time, letting users cross-reference multiple images. The feel of the interaction evokes looking into vignettes and being able to shift your point of view through space and time. One of the best examples available of this new capability is the <a title="Photosynth of the Obama inauguration" href="http://edition.cnn.com/SPECIALS/2009/44.president/inauguration/themoment/">Photosynth of the Obama inauguration</a><a title="Photosynth of the Obama inauguration" href="http://edition.cnn.com/SPECIALS/2009/44.president/inauguration/themoment/"><img src="http://www.uxmatters.com/mt/archives/images/new-window-arrow.gif" alt="" width="14" height="12" /></a> shown in Figure 6.</p>
<p>Figure 6—Photosynth of President Obama’s inauguration</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/08/images/figure_6_photosynth.png" alt="Photosynth of the Obama inauguration" width="474" height="261" /></p>
<p>What is <em>really</em> interesting about this emerging technology is that it sidesteps—quite literally—the issue of a finite density of information within a single photograph. With systems like this, we are moving into a world where—rather than relying on just keywords and tags—we can use deep image analysis to sort and restructure sets of images and make sense of what we are looking at. The computer can truly <em>see</em> a real 3D space.</p>
<h2>Collecting and Browsing Images on Mobile Devices</h2>
<p>Using images as input for searches on a hand-held device is reminiscent of using barcode readers to enter inventory counts into a computer. Historically, barcode recognition required the use of a specialized device that was available only to governments and larger businesses. However, recent developments in mobile technology are rapidly changing this paradigm. An increasing number of mobile phone applications like RedLaser, LifeScan, and NeoReader, which is shown in Figure 7, now let customers snap photos of barcodes, using their mobile phones, then immediately use the photos as input for a search algorithm.</p>
<p>Figure 7—NeoReader iPhone application</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/08/images/figure_7_neoreader.png" alt="Neoreader" width="400" height="323" /></p>
<p>Another tool called Semapedia offers an interesting way of using mobile barcode recognition. Semapedia makes it possible to tag any item in the physical world with a barcode that contains a link to the appropriate Wikipedia Web page. A person can use a mobile phone with the free NeoReader application to read the link’s URL and navigate to the Web page providing Wikipedia content about the object or place a person is looking at. Figure 8 shows a historical site that is tagged with a barcode linking it to a Wikipedia page.</p>
<p>Figure 8—Historical site tagged with a Semapedia barcode</p>
<p><img src="http://www.uxmatters.com/mt/archives/2009/08/images/figure_8_historical_site.png" alt="Semapedia barcode" width="474" height="355" /></p>
<p>Another example of the capability of mobile barcode-recognition technology comes from the Suntory Company in Japan, which tagged their beer cans with a special 2D barcode. Scanning this barcode with the application NeoReader takes a consumer to a mobile Web site that lets visitors register to offset 100g of CO2 emissions once per day and get tips on mitigating their own greenhouse gas emissions.</p>
<p>Both of these examples demonstrate that we are moving ever faster toward a world that is populated by smart objects, which Bruce Sterling dubbed <em>spimes</em>. We can track spimes’ history of use and interact with them through the mesh of real and virtual worlds that pervasive RFID and GPS tracking create. Mobile picture search is certainly emerging as the input device of choice for connecting the real and the virtual worlds to create the Internet of Objects.</p>
<p>Peter Morville, in his book <em>Ambient Findability,</em> talks about the sensory overload, trust issues, and bad decisions that are sure to result from our interactions with the Internet of Objects. However, it is hard to elude the siren’s call of such technology. It is now <em>almost</em> possible to use technology similar to that of Like.com to analyze every image and frame of video a mobile phone captures and tag them with text, GPS coordinates, time, and author. At the same time, it <em>is</em> possible to cross-reference each image with other images of the same place or similar things, along with <em>all</em> the tags, content, and links an entire world of users has added to this collection of images. The technology to collect all of these images in a massive 3D collage that users can navigate along a time axis, Photosynth-style, is also just around the corner.</p>
<p>Interactions of this kind make it possible to establish a unique and natural connection between the real world and the Internet computing cloud. The key is the added meaning the computer provides, based on its understanding and interpretation of the content of an image. Imagine, for example, taking a picture of a CD cover with your mobile phone’s camera and sharing it with your friends to learn what they think about the music; using the same picture to get more information about the artist on the Web—for example, pictures, videos of recent concerts, and a biography; finding out where you can buy the CD at the best price online; or using GPS to find coupons to purchase the CD from a local merchant. Imagine being able to do <em>all</em> of this with only a few screen taps and <em>without</em> typing a single character, while listening to a sampling of the CD’s tracks, playing through headphones connected to your mobile phone.</p>
<p>We are just starting to scratch the surface of these types of massively distributed, image-based, human-to-mobile interactions. Although image-processing speeds are getting much better—witness the smooth, fast scrolling of iPhone photo album images versus the slow shuffle of images on a Treo—the time it takes to process images on a mobile device and send them back and forth between that device and a server is still the biggest barrier to this type of technology. Once the image feedback loop is nearly instantaneous, this new paradigm for mobile input will truly come into its own, bringing the digital world ever closer to the real world and ushering in the arrival of a brave new world of visual browsing.<a title="Top" href="http://www.uxmatters.com/mt/archives/2009/08/brave-new-world-of-visual-browsing.php#top"><img src="http://www.uxmatters.com/mt/archives/images/ux-bug.gif" alt="" width="18" height="18" /></a></p>
<h4>References</h4>
<p>Jung, Carl Gustav. <em>Man and His Symbols.</em> New York: Dell, 1968.</p>
<p>Morville, Peter. <em>Ambient Findability.</em> Sebastopol, California: O’Reilly, 2005.</p>
<p>Nudelman, Greg. “<a title="Making $10,000 a Pixel: Optimizing Thumbnail Images in Search Results" href="http://www.uxmatters.com/mt/archives/2009/05/making-10000-a-pixel-optimizing-thumbnail-images-in-search-results.php">Making $10,000 a Pixel: Optimizing Thumbnail Images in Search Results</a>.” <em>UXmatters</em>, May 11, 2009. Retrieved July 26, 2009.</p>
<p>Riflet, Guillaume. “<a title="Semapedia, or How to Link the Real World to Wikipedia" href="http://webtopmania.blogspot.com/2008/08/semapedia-or-how-to-link-real-world-to.html">Semapedia, or How to Link the Real World to Wikipedia</a>.”<a title="Semapedia, or How to Link the Real World to Wikipedia" href="http://webtopmania.blogspot.com/2008/08/semapedia-or-how-to-link-real-world-to.html"><em><img src="http://www.uxmatters.com/mt/archives/images/new-window-arrow.gif" alt="" width="14" height="12" /></em></a><em> Webtop Mania,</em> August 26, 2008. Retrieved July 26, 2009.</p>
<p>Smith, Gene. <em>Tagging: People-Powered Metadata for the Social Web.</em> Berkeley: Peachpit Press, 2008.</p>
<p>Smolski, Roger. “<a title="Beer, Carbon Offset, and a QR Code Campaign" href="http://2d-code.co.uk/beer-can-qr-code-2/">Beer, Carbon Offset, and a QR Code Campaign</a>.”<a title="Beer, Carbon Offset, and a QR Code Campaign" href="http://2d-code.co.uk/beer-can-qr-code-2/"><img src="http://www.uxmatters.com/mt/archives/images/new-window-arrow.gif" alt="" width="14" height="12" /></a> <em>2d code,</em> July 27, 2009. Retrieved July 26, 2009.</p>
<p>Sterling, Bruce. <em>Shaping Things.</em> Cambridge, Massachusetts: MIT Press, 2005.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.designcaffeine.com/2010/articles/210/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>
