<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	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:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
	>
<channel>
	<title>Comments on: UIEtips article: Producing Great Search Results &#8212; Harder than It Looks, Part 2</title>
	<atom:link href="http://www.uie.com/brainsparks/2009/06/29/uietips-article-producing-great-search-results-harder-than-it-looks-part-2/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.uie.com/brainsparks/2009/06/29/uietips-article-producing-great-search-results-harder-than-it-looks-part-2/</link>
	<description>UIE\'s latest insights on the world of design</description>
	<lastBuildDate>Tue, 16 Mar 2010 00:07:14 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Erin Lynn Young</title>
		<link>http://www.uie.com/brainsparks/2009/06/29/uietips-article-producing-great-search-results-harder-than-it-looks-part-2/comment-page-1/#comment-147377</link>
		<dc:creator>Erin Lynn Young</dc:creator>
		<pubDate>Mon, 13 Jul 2009 16:34:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=698#comment-147377</guid>
		<description>Filter-able search results might be one solve.  Another option is to have users flag individual results as &quot;wacko&quot; so that you can review and suppress them.</description>
		<content:encoded><![CDATA[<p>Filter-able search results might be one solve.  Another option is to have users flag individual results as &#8220;wacko&#8221; so that you can review and suppress them.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pam</title>
		<link>http://www.uie.com/brainsparks/2009/06/29/uietips-article-producing-great-search-results-harder-than-it-looks-part-2/comment-page-1/#comment-147254</link>
		<dc:creator>Pam</dc:creator>
		<pubDate>Tue, 30 Jun 2009 18:11:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=698#comment-147254</guid>
		<description>This is sort of tangential, but I&#039;m wondering if anyone has dealt with how some of these things apply or don&#039;t apply when you&#039;re dealing with searches on huge databases of materials. Our search covers thousands of court opinions, hundreds of court rules, thousands of legal forms, and hundreds of book chapters, seminars, and short how-to articles (yes, they can search on the various types independently or together). It doesn&#039;t seem like anything we do can keep wacko results from coming in when we have this much material. Anybody have any relevant experiences or materials to point me to?</description>
		<content:encoded><![CDATA[<p>This is sort of tangential, but I&#8217;m wondering if anyone has dealt with how some of these things apply or don&#8217;t apply when you&#8217;re dealing with searches on huge databases of materials. Our search covers thousands of court opinions, hundreds of court rules, thousands of legal forms, and hundreds of book chapters, seminars, and short how-to articles (yes, they can search on the various types independently or together). It doesn&#8217;t seem like anything we do can keep wacko results from coming in when we have this much material. Anybody have any relevant experiences or materials to point me to?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Erin Lynn Young</title>
		<link>http://www.uie.com/brainsparks/2009/06/29/uietips-article-producing-great-search-results-harder-than-it-looks-part-2/comment-page-1/#comment-147224</link>
		<dc:creator>Erin Lynn Young</dc:creator>
		<pubDate>Mon, 29 Jun 2009 21:48:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=698#comment-147224</guid>
		<description>I&#039;d like to share a strategy on avoiding null listings.

In Robert Hoekman, Jr.&#039;&#039;s presentation &quot;7 rules of great application design&quot; presentation at SXSW 09, he emphasized the importance of not making users feel dumb.  One way to avoid it was to prevent errors whoever possible.  He cited Backpack from 37 Signals as a web app that manages to prevent errors very effectively.

When I get a null search result, I&#039;m immediately about 50% certain that I won&#039;t find what I&#039;m looking for on that site.  

So, rather than providing users with a null result, I like to do what I can to prevent them.  My favorite design patterns include responsive filters which become disabled when no more results are available, paired with predictive search which prompts the users before the button is pressed that there are no results for the query, helping the user bypass an unecessary page reload.

Obviously, each of these approaches can tax the server... but I consider them to be worth weighing for the gains in both user experience and likehood of conversion in the eCommerce setting.  Hitting quality results on the fisrt query is important.  

This design pattern would not change the recommendation for the Wii, however - which existed, had a page, but was not currently in stock. 

Just thought I&#039;d share.</description>
		<content:encoded><![CDATA[<p>I&#8217;d like to share a strategy on avoiding null listings.</p>
<p>In Robert Hoekman, Jr.&#8217;&#8217;s presentation &#8220;7 rules of great application design&#8221; presentation at SXSW 09, he emphasized the importance of not making users feel dumb.  One way to avoid it was to prevent errors whoever possible.  He cited Backpack from 37 Signals as a web app that manages to prevent errors very effectively.</p>
<p>When I get a null search result, I&#8217;m immediately about 50% certain that I won&#8217;t find what I&#8217;m looking for on that site.  </p>
<p>So, rather than providing users with a null result, I like to do what I can to prevent them.  My favorite design patterns include responsive filters which become disabled when no more results are available, paired with predictive search which prompts the users before the button is pressed that there are no results for the query, helping the user bypass an unecessary page reload.</p>
<p>Obviously, each of these approaches can tax the server&#8230; but I consider them to be worth weighing for the gains in both user experience and likehood of conversion in the eCommerce setting.  Hitting quality results on the fisrt query is important.  </p>
<p>This design pattern would not change the recommendation for the Wii, however &#8211; which existed, had a page, but was not currently in stock. </p>
<p>Just thought I&#8217;d share.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pete</title>
		<link>http://www.uie.com/brainsparks/2009/06/29/uietips-article-producing-great-search-results-harder-than-it-looks-part-2/comment-page-1/#comment-143584</link>
		<dc:creator>Pete</dc:creator>
		<pubDate>Thu, 21 Aug 2008 19:05:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=698#comment-143584</guid>
		<description>Hi Jared,
I&#039;ve noticed sites like clusty.com and powerset.com allow the user to view the documents in-line without having to leave the gallery / search results page.

Are these inline document viewing widgets effective mechanisms for helping users mitigate pogosticking pain?  
Thanks!
Pete</description>
		<content:encoded><![CDATA[<p>Hi Jared,<br />
I&#8217;ve noticed sites like clusty.com and powerset.com allow the user to view the documents in-line without having to leave the gallery / search results page.</p>
<p>Are these inline document viewing widgets effective mechanisms for helping users mitigate pogosticking pain?<br />
Thanks!<br />
Pete</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bbscan</title>
		<link>http://www.uie.com/brainsparks/2009/06/29/uietips-article-producing-great-search-results-harder-than-it-looks-part-2/comment-page-1/#comment-143346</link>
		<dc:creator>bbscan</dc:creator>
		<pubDate>Wed, 06 Aug 2008 13:42:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=698#comment-143346</guid>
		<description>This is an absolutely terrific article.  I have been working on a car review search engine (fasttie.com) for a while now and the article addresses all of the concerns that I have been running into.  A problem I have found is that you start losing the forest for the trees when you have been working on it too long.  At times it becomes hard to get the mindset back of a new user.</description>
		<content:encoded><![CDATA[<p>This is an absolutely terrific article.  I have been working on a car review search engine (fasttie.com) for a while now and the article addresses all of the concerns that I have been running into.  A problem I have found is that you start losing the forest for the trees when you have been working on it too long.  At times it becomes hard to get the mindset back of a new user.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aldra</title>
		<link>http://www.uie.com/brainsparks/2009/06/29/uietips-article-producing-great-search-results-harder-than-it-looks-part-2/comment-page-1/#comment-142961</link>
		<dc:creator>Aldra</dc:creator>
		<pubDate>Fri, 18 Jul 2008 18:57:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=698#comment-142961</guid>
		<description>thanks for a great article. I hadn&#039;t seen findings about number of search results like that before. Seems like the only reason left to use a per page limit is response times.</description>
		<content:encoded><![CDATA[<p>thanks for a great article. I hadn&#8217;t seen findings about number of search results like that before. Seems like the only reason left to use a per page limit is response times.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Producing Great Search Results: Harder than It Looks, Part 2 - Talk</title>
		<link>http://www.uie.com/brainsparks/2009/06/29/uietips-article-producing-great-search-results-harder-than-it-looks-part-2/comment-page-1/#comment-142708</link>
		<dc:creator>Producing Great Search Results: Harder than It Looks, Part 2 - Talk</dc:creator>
		<pubDate>Tue, 15 Jul 2008 15:23:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=698#comment-142708</guid>
		<description>[...] design patterns that have made your site more effective? Please tell us your thoughts on our Brain Sparks blog.    Published Jul 15 2008, 11:17 AM by electric Filed under: Usability, [...]</description>
		<content:encoded><![CDATA[<p>[...] design patterns that have made your site more effective? Please tell us your thoughts on our Brain Sparks blog.    Published Jul 15 2008, 11:17 AM by electric Filed under: Usability, [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Daniel Szuc</title>
		<link>http://www.uie.com/brainsparks/2009/06/29/uietips-article-producing-great-search-results-harder-than-it-looks-part-2/comment-page-1/#comment-142674</link>
		<dc:creator>Daniel Szuc</dc:creator>
		<pubDate>Tue, 15 Jul 2008 09:34:11 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=698#comment-142674</guid>
		<description>Good reading :) 

Hi UIE ... Have teams you worked with provided insights as to the ways they try to better understand the data associated with a search result to better inform a customer decision? For example, what data would you need to display on a hotel room, car, mobile phone (to name a few) to get someone to buy? What do designers and researchers need to do to better understand what to display on a search result?

This seems like a critical part of any search results -- displaying the precise product/service information in addition to pricing to inform a buy/no buy decision.</description>
		<content:encoded><![CDATA[<p>Good reading <img src='http://www.uie.com/brainsparks/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' />  </p>
<p>Hi UIE &#8230; Have teams you worked with provided insights as to the ways they try to better understand the data associated with a search result to better inform a customer decision? For example, what data would you need to display on a hotel room, car, mobile phone (to name a few) to get someone to buy? What do designers and researchers need to do to better understand what to display on a search result?</p>
<p>This seems like a critical part of any search results &#8212; displaying the precise product/service information in addition to pricing to inform a buy/no buy decision.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Davee</title>
		<link>http://www.uie.com/brainsparks/2009/06/29/uietips-article-producing-great-search-results-harder-than-it-looks-part-2/comment-page-1/#comment-142635</link>
		<dc:creator>Davee</dc:creator>
		<pubDate>Mon, 14 Jul 2008 19:32:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=698#comment-142635</guid>
		<description>Hi Jared, I&#039;m appreciating your articles about search results. A thought came up for me with respect to the pogosticking idea. In general I agree that finding the right amount of data in the search result is generally a good idea. But reading the reasoning that sales decreased with increased pogostick behavior, made me immediately think of another possible cause for that correlation or at least influence.

In your testing was the familiarity of the customer with the listed products somehow factored? It seems like customers very familiar with the products already, akin to &quot;knowing what they want already&quot; would look at the search results and be ready to make a purchase. But customers who were not as familiar might still be in a browsing state of mind and be more interested in product details and educating themselves. Therefore, the pogostick behavior might convey more what state of mind the customer is in, rather than attributing the behavior solely to distracting or tiring the user.

Perhaps you already accounted for that influence in the tests, your newsletter only summarizes the results. But that&#039;s what struck me when I first read it. Perhaps others in their testing of search results can account for that as well.
Best to you,
-Davee Evans</description>
		<content:encoded><![CDATA[<p>Hi Jared, I&#8217;m appreciating your articles about search results. A thought came up for me with respect to the pogosticking idea. In general I agree that finding the right amount of data in the search result is generally a good idea. But reading the reasoning that sales decreased with increased pogostick behavior, made me immediately think of another possible cause for that correlation or at least influence.</p>
<p>In your testing was the familiarity of the customer with the listed products somehow factored? It seems like customers very familiar with the products already, akin to &#8220;knowing what they want already&#8221; would look at the search results and be ready to make a purchase. But customers who were not as familiar might still be in a browsing state of mind and be more interested in product details and educating themselves. Therefore, the pogostick behavior might convey more what state of mind the customer is in, rather than attributing the behavior solely to distracting or tiring the user.</p>
<p>Perhaps you already accounted for that influence in the tests, your newsletter only summarizes the results. But that&#8217;s what struck me when I first read it. Perhaps others in their testing of search results can account for that as well.<br />
Best to you,<br />
-Davee Evans</p>
]]></content:encoded>
	</item>
</channel>
</rss>
