<?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/"
		>
<channel>
	<title>Comments on: &#8220;Beyond Here Be Dragons&#8221; &#8211; Or, Don&#8217;t Design For The Edge Cases</title>
	<atom:link href="http://www.usabilityblog.com/2009/09/dont-design-for-the-edge-cases/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.usabilityblog.com/2009/09/dont-design-for-the-edge-cases/</link>
	<description>Blogging about usability, user experience and design</description>
	<lastBuildDate>Thu, 09 Feb 2012 16:40:00 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: baileys</title>
		<link>http://www.usabilityblog.com/2009/09/dont-design-for-the-edge-cases/comment-page-1/#comment-9362</link>
		<dc:creator>baileys</dc:creator>
		<pubDate>Sat, 02 Jan 2010 11:17:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.usabilityblog.com/index.php/2009/09/04/dont-design-for-the-edge-cases/#comment-9362</guid>
		<description>That picture is from an interaction design book...my brain is refusing to remind me which one, though. The author put the paper over the remotes for his parents so that they could find the important controls without getting confused by the ones they didn&#039;t need.</description>
		<content:encoded><![CDATA[<p>That picture is from an interaction design book&#8230;my brain is refusing to remind me which one, though. The author put the paper over the remotes for his parents so that they could find the important controls without getting confused by the ones they didn&#39;t need.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: baileys</title>
		<link>http://www.usabilityblog.com/2009/09/dont-design-for-the-edge-cases/comment-page-1/#comment-9243</link>
		<dc:creator>baileys</dc:creator>
		<pubDate>Sat, 02 Jan 2010 06:17:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.usabilityblog.com/index.php/2009/09/04/dont-design-for-the-edge-cases/#comment-9243</guid>
		<description>That picture is from an interaction design book...my brain is refusing to remind me which one, though. The author put the paper over the remotes for his parents so that they could find the important controls without getting confused by the ones they didn&#039;t need.</description>
		<content:encoded><![CDATA[<p>That picture is from an interaction design book&#8230;my brain is refusing to remind me which one, though. The author put the paper over the remotes for his parents so that they could find the important controls without getting confused by the ones they didn&#39;t need.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: pjsherman</title>
		<link>http://www.usabilityblog.com/2009/09/dont-design-for-the-edge-cases/comment-page-1/#comment-9029</link>
		<dc:creator>pjsherman</dc:creator>
		<pubDate>Fri, 04 Sep 2009 19:07:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.usabilityblog.com/index.php/2009/09/04/dont-design-for-the-edge-cases/#comment-9029</guid>
		<description>Here&#039;s a comment from a colleague whose organization frowns on his commenting on blogs and FB and other social media. Hence, I&#039;ve de-identified him. (And no, I&#039;m not sock-puppeting...)&lt;br&gt;&lt;br&gt;Says colleague: &lt;br&gt;&lt;br&gt;&quot;One of the challenges that many face is that people want the feature that they are advocating to be visible. After a while, this ends up being a lot of features and no one wants to &quot;hide&quot; their feature. For the user, though, the signal-to-noise ratio gets out of control.&lt;br&gt;&lt;br&gt;When you propose testing to establish which features are most used and which are least used, to determine which should be &quot;hidden underneath the door,&quot; no one wants to support it. This is likely because they do not want to find out that their feature doesn&#039;t make the cut.&lt;br&gt;&lt;br&gt;We have tried to do something like Option #2 in our [redacted] utility. It is a powerful tool, but most of the functionality goes beyond the needs of the average user. So, the UI has a &quot;basic&quot; and &quot;advanced&quot; mode. The basic gets the user to the core functions quickly and makes them easy to use. The advanced mode gives the user access to the more robust functionality and customization.&quot;</description>
		<content:encoded><![CDATA[<p>Here&#39;s a comment from a colleague whose organization frowns on his commenting on blogs and FB and other social media. Hence, I&#39;ve de-identified him. (And no, I&#39;m not sock-puppeting&#8230;)</p>
<p>Says colleague: </p>
<p>&#8220;One of the challenges that many face is that people want the feature that they are advocating to be visible. After a while, this ends up being a lot of features and no one wants to &#8220;hide&#8221; their feature. For the user, though, the signal-to-noise ratio gets out of control.</p>
<p>When you propose testing to establish which features are most used and which are least used, to determine which should be &#8220;hidden underneath the door,&#8221; no one wants to support it. This is likely because they do not want to find out that their feature doesn&#39;t make the cut.</p>
<p>We have tried to do something like Option #2 in our [redacted] utility. It is a powerful tool, but most of the functionality goes beyond the needs of the average user. So, the UI has a &#8220;basic&#8221; and &#8220;advanced&#8221; mode. The basic gets the user to the core functions quickly and makes them easy to use. The advanced mode gives the user access to the more robust functionality and customization.&#8221;</p>
]]></content:encoded>
	</item>
</channel>
</rss>

