<?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: To Dash or Not To Dash</title>
	<atom:link href="http://www.uie.com/brainsparks/2006/02/23/to-dash-or-not-to-dash/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.uie.com/brainsparks/2006/02/23/to-dash-or-not-to-dash/</link>
	<description>UIE\'s latest insights on the world of design</description>
	<lastBuildDate>Thu, 18 Mar 2010 16:06:49 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Jack Bellis</title>
		<link>http://www.uie.com/brainsparks/2006/02/23/to-dash-or-not-to-dash/comment-page-1/#comment-1925</link>
		<dc:creator>Jack Bellis</dc:creator>
		<pubDate>Wed, 08 Mar 2006 22:22:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=187#comment-1925</guid>
		<description>For as long as there&#039;s been code, there&#039;s been a lack of all the right code in all the right places, and we usability nuts have complained about it. There will be no end to the problems and no end to the complaining if we don&#039;t seek out systemic solutions. Every highschool programmer is repeating this problem all day long because all software development starts over again from a blank page instead of from a robust, usable solution and working in the other direction. Progammers aren&#039;t any lazier or culpable than we usability folks. They are working in an unreasonable set of circumstances.</description>
		<content:encoded><![CDATA[<p>For as long as there&#8217;s been code, there&#8217;s been a lack of all the right code in all the right places, and we usability nuts have complained about it. There will be no end to the problems and no end to the complaining if we don&#8217;t seek out systemic solutions. Every highschool programmer is repeating this problem all day long because all software development starts over again from a blank page instead of from a robust, usable solution and working in the other direction. Progammers aren&#8217;t any lazier or culpable than we usability folks. They are working in an unreasonable set of circumstances.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jared Spool</title>
		<link>http://www.uie.com/brainsparks/2006/02/23/to-dash-or-not-to-dash/comment-page-1/#comment-1919</link>
		<dc:creator>Jared Spool</dc:creator>
		<pubDate>Wed, 08 Mar 2006 17:31:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=187#comment-1919</guid>
		<description>David wrote:
&lt;blockquote&gt;It’s appalling. &lt;/blockquote&gt;

I&#039;m thinking there&#039;s going to be a special place in hell for the developers who perpetuate these crimes. :)</description>
		<content:encoded><![CDATA[<p>David wrote:</p>
<blockquote><p>It’s appalling. </p></blockquote>
<p>I&#8217;m thinking there&#8217;s going to be a special place in hell for the developers who perpetuate these crimes. <img src='http://www.uie.com/brainsparks/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David D. Levine</title>
		<link>http://www.uie.com/brainsparks/2006/02/23/to-dash-or-not-to-dash/comment-page-1/#comment-1917</link>
		<dc:creator>David D. Levine</dc:creator>
		<pubDate>Wed, 08 Mar 2006 17:27:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=187#comment-1917</guid>
		<description>Even worse are the fields that not only require that you type the value without spaces or dashes, but also place a limit on the number of characters entered.  If you type or paste the phone number 206-555-1212 into such a field, you will get just 206-555-12 -- you have to manually delete the dashes and manually type the missing digits (which you might not even know, if you just copied and pasted the value from a window that is now closed).  I see this all the time for credit card numbers -- so often that I have developed the habit of typing credit card numbers without spaces.

It&#039;s appalling.</description>
		<content:encoded><![CDATA[<p>Even worse are the fields that not only require that you type the value without spaces or dashes, but also place a limit on the number of characters entered.  If you type or paste the phone number 206-555-1212 into such a field, you will get just 206-555-12 &#8212; you have to manually delete the dashes and manually type the missing digits (which you might not even know, if you just copied and pasted the value from a window that is now closed).  I see this all the time for credit card numbers &#8212; so often that I have developed the habit of typing credit card numbers without spaces.</p>
<p>It&#8217;s appalling.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andy Duncan</title>
		<link>http://www.uie.com/brainsparks/2006/02/23/to-dash-or-not-to-dash/comment-page-1/#comment-1840</link>
		<dc:creator>Andy Duncan</dc:creator>
		<pubDate>Sat, 04 Mar 2006 01:16:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=187#comment-1840</guid>
		<description>That functionality saved a programmer at least 10 minutes of time: 30 seconds to find the example code on google 1.5 minutes to implement  4 rounds of testing at 2 minutes each Who cares if it aggravated every single user on the site? Those are REAL hours... Er, minutes... I can&#039;t tell you how many times I&#039;ve had this argument with a programmer and the argument usually ends up with me finding the example code for them. Not to mention the conversations involving you, the programmer, the project manager and two business analysts, the total bill for the conversation far exceeding the amount of time required to write the World&#039;s Greatest Phone Number Validator(tm) in Java, C++ and Ruby combined, with enough left over to throw in some client-side javascript validation for good measure.Heck, at most bill rates you might as well outsource the number validation to a 3rd world country and do each and every one by hand if you&#039;re even going to waste five minutes talking about whether or not to implement it.</description>
		<content:encoded><![CDATA[<p>That functionality saved a programmer at least 10 minutes of time: 30 seconds to find the example code on google 1.5 minutes to implement  4 rounds of testing at 2 minutes each Who cares if it aggravated every single user on the site? Those are REAL hours&#8230; Er, minutes&#8230; I can&#8217;t tell you how many times I&#8217;ve had this argument with a programmer and the argument usually ends up with me finding the example code for them. Not to mention the conversations involving you, the programmer, the project manager and two business analysts, the total bill for the conversation far exceeding the amount of time required to write the World&#8217;s Greatest Phone Number Validator(tm) in Java, C++ and Ruby combined, with enough left over to throw in some client-side javascript validation for good measure.Heck, at most bill rates you might as well outsource the number validation to a 3rd world country and do each and every one by hand if you&#8217;re even going to waste five minutes talking about whether or not to implement it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dey Alexander</title>
		<link>http://www.uie.com/brainsparks/2006/02/23/to-dash-or-not-to-dash/comment-page-1/#comment-1554</link>
		<dc:creator>Dey Alexander</dc:creator>
		<pubDate>Fri, 24 Feb 2006 11:18:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=187#comment-1554</guid>
		<description>Couldn&#039;t agree more Vitaliy.  While I&#039;ve encountered the dashes problem a few times, I&#039;ve tended to run into the 4 separate text fields problem more often, and it is sooooo annoying!</description>
		<content:encoded><![CDATA[<p>Couldn&#8217;t agree more Vitaliy.  While I&#8217;ve encountered the dashes problem a few times, I&#8217;ve tended to run into the 4 separate text fields problem more often, and it is sooooo annoying!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Vitaliy</title>
		<link>http://www.uie.com/brainsparks/2006/02/23/to-dash-or-not-to-dash/comment-page-1/#comment-1549</link>
		<dc:creator>Vitaliy</dc:creator>
		<pubDate>Thu, 23 Feb 2006 21:52:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=187#comment-1549</guid>
		<description>You should thank them that they didn&#039;t provide you with handy-dandy 4 separate text fields (one for each part).  That way you wouldn&#039;t be able to past the entire number at all. Duhhh..</description>
		<content:encoded><![CDATA[<p>You should thank them that they didn&#8217;t provide you with handy-dandy 4 separate text fields (one for each part).  That way you wouldn&#8217;t be able to past the entire number at all. Duhhh..</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Coda Hale</title>
		<link>http://www.uie.com/brainsparks/2006/02/23/to-dash-or-not-to-dash/comment-page-1/#comment-1548</link>
		<dc:creator>Coda Hale</dc:creator>
		<pubDate>Thu, 23 Feb 2006 21:44:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=187#comment-1548</guid>
		<description>This has to be my #1 pet peeve in e-commerce. Soooo easy to fix, too.

I disagree with Ezra, though: the best way to get around this problem is to use whitelist stripping, in which you remove everything *but* the characters you know to be good.

In this case, we would want to remove everything that&#039;s not a numeric digit or A-F (case insensitive):

&lt;code&gt;s/[^0-9A-Fa-f]//g&lt;/code&gt;

Not exactly rocket science.</description>
		<content:encoded><![CDATA[<p>This has to be my #1 pet peeve in e-commerce. Soooo easy to fix, too.</p>
<p>I disagree with Ezra, though: the best way to get around this problem is to use whitelist stripping, in which you remove everything *but* the characters you know to be good.</p>
<p>In this case, we would want to remove everything that&#8217;s not a numeric digit or A-F (case insensitive):</p>
<p><code>s/[^0-9A-Fa-f]//g</code></p>
<p>Not exactly rocket science.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lar Veale</title>
		<link>http://www.uie.com/brainsparks/2006/02/23/to-dash-or-not-to-dash/comment-page-1/#comment-1545</link>
		<dc:creator>Lar Veale</dc:creator>
		<pubDate>Thu, 23 Feb 2006 17:53:11 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=187#comment-1545</guid>
		<description>PS. The most excellent book by 37 Signals, &quot;Defensive Design for the Web&quot; covers this topic really well, and is a must read for any design/usability professional.</description>
		<content:encoded><![CDATA[<p>PS. The most excellent book by 37 Signals, &#8220;Defensive Design for the Web&#8221; covers this topic really well, and is a must read for any design/usability professional.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lar Veale</title>
		<link>http://www.uie.com/brainsparks/2006/02/23/to-dash-or-not-to-dash/comment-page-1/#comment-1544</link>
		<dc:creator>Lar Veale</dc:creator>
		<pubDate>Thu, 23 Feb 2006 17:51:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=187#comment-1544</guid>
		<description>It&#039;s a constant problem we see when evaluating website usability. Even worse, when there is no clue upfront and you only find out what format is required AFTER submitting your information.</description>
		<content:encoded><![CDATA[<p>It&#8217;s a constant problem we see when evaluating website usability. Even worse, when there is no clue upfront and you only find out what format is required AFTER submitting your information.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ezra</title>
		<link>http://www.uie.com/brainsparks/2006/02/23/to-dash-or-not-to-dash/comment-page-1/#comment-1543</link>
		<dc:creator>Ezra</dc:creator>
		<pubDate>Thu, 23 Feb 2006 17:12:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=187#comment-1543</guid>
		<description>&lt;em&gt;First, why not accept the number with dashes? How hard is it to write code to strip dashes or spaces out?&lt;/em&gt;

The regular expression to remove dashes from a string, which can be used in javascript, java, perl, etc., etc., is 

s/-//g

That&#039;s it!</description>
		<content:encoded><![CDATA[<p><em>First, why not accept the number with dashes? How hard is it to write code to strip dashes or spaces out?</em></p>
<p>The regular expression to remove dashes from a string, which can be used in javascript, java, perl, etc., etc., is </p>
<p>s/-//g</p>
<p>That&#8217;s it!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Eric Meyer</title>
		<link>http://www.uie.com/brainsparks/2006/02/23/to-dash-or-not-to-dash/comment-page-1/#comment-1542</link>
		<dc:creator>Eric Meyer</dc:creator>
		<pubDate>Thu, 23 Feb 2006 16:53:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=187#comment-1542</guid>
		<description>Nearly as bad are the inverse cases: the fields that require you to use a specific delimiter pattern, like 123-456-7890 when you&#039;re rather type (123) 456-7890 or 123.456.7890 or even just 1234567890.

Whenever I see that kind of thing, I think to myself: a lazy programmer passed this way.</description>
		<content:encoded><![CDATA[<p>Nearly as bad are the inverse cases: the fields that require you to use a specific delimiter pattern, like 123-456-7890 when you&#8217;re rather type (123) 456-7890 or 123.456.7890 or even just 1234567890.</p>
<p>Whenever I see that kind of thing, I think to myself: a lazy programmer passed this way.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Zuschlag</title>
		<link>http://www.uie.com/brainsparks/2006/02/23/to-dash-or-not-to-dash/comment-page-1/#comment-1538</link>
		<dc:creator>Michael Zuschlag</dc:creator>
		<pubDate>Thu, 23 Feb 2006 14:50:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=187#comment-1538</guid>
		<description>In the early &#039;90s I worked on a DOS-based DBMS which supported &quot;pictured&quot; fields in its forms, where the programmer could specify the format (e.g., &quot;(###)###-####&quot; for a North American phone number). The user was allowed to type format-specified delimiters to make the entry easy to check. If the user didn&#039;t type the delimiters, they were put in automatically (sort of like cell phones today), making for fast data entry *and* easy checking. If the user typed a character not allowed by the format, the typing was merely ignored, as opposed to letting it be entered, then throwing a blame-the-user &quot;invalid entry&quot; error back when the data are submitted. It would seem the UI design practices of many web page forms remain stuck in the 1980s.</description>
		<content:encoded><![CDATA[<p>In the early &#8217;90s I worked on a DOS-based DBMS which supported &#8220;pictured&#8221; fields in its forms, where the programmer could specify the format (e.g., &#8220;(###)###-####&#8221; for a North American phone number). The user was allowed to type format-specified delimiters to make the entry easy to check. If the user didn&#8217;t type the delimiters, they were put in automatically (sort of like cell phones today), making for fast data entry *and* easy checking. If the user typed a character not allowed by the format, the typing was merely ignored, as opposed to letting it be entered, then throwing a blame-the-user &#8220;invalid entry&#8221; error back when the data are submitted. It would seem the UI design practices of many web page forms remain stuck in the 1980s.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
