<?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"
	>
<channel>
	<title>Comments on: Fielded Input Considered Harmful</title>
	<atom:link href="http://cafe.elharo.com/ui/fielded-input-considered-harmful/feed/" rel="self" type="application/rss+xml" />
	<link>http://cafe.elharo.com/ui/fielded-input-considered-harmful/</link>
	<description>Longer than a blog; shorter than a book</description>
	<pubDate>Fri, 21 Nov 2008 15:54:09 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: taw</title>
		<link>http://cafe.elharo.com/ui/fielded-input-considered-harmful/#comment-20866</link>
		<dc:creator>taw</dc:creator>
		<pubDate>Fri, 06 Oct 2006 09:49:59 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/ui/fielded-input-considered-harmful/#comment-20866</guid>
		<description>Actually it makes perfect sense to split dates or enforce single format. In languages other than English dates can only be little-endian or big-endian. In English middle-endian is also possible, so 3.6.2006 can be June 3rd or March 6th. Not to mention ambiguity of 12-hour time with AM/PM (12:00 AM is 00:00 or 12:00 or 24:00 ?), also English-specific.

If such forms are allowed, you're going to have many problems. I'm all for forcing people to use "2006-06-03 12:00" format.</description>
		<content:encoded><![CDATA[<p>Actually it makes perfect sense to split dates or enforce single format. In languages other than English dates can only be little-endian or big-endian. In English middle-endian is also possible, so 3.6.2006 can be June 3rd or March 6th. Not to mention ambiguity of 12-hour time with AM/PM (12:00 AM is 00:00 or 12:00 or 24:00 ?), also English-specific.</p>
<p>If such forms are allowed, you&#8217;re going to have many problems. I&#8217;m all for forcing people to use &#8220;2006-06-03 12:00&#8243; format.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dave Garbutt</title>
		<link>http://cafe.elharo.com/ui/fielded-input-considered-harmful/#comment-20219</link>
		<dc:creator>Dave Garbutt</dc:creator>
		<pubDate>Tue, 03 Oct 2006 08:25:38 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/ui/fielded-input-considered-harmful/#comment-20219</guid>
		<description>Eliotte:

I liked your remark about the address book. Actually the free-form version exists and is called Sbook5 at http://www.sbook5.com/ by Simson Garfinkel.

It can synchronise with Apple's address book.
It identifies fields and adds an icon, then you can manually fix the icon if it gets it wrong. Very nice approach and it makes copy&#38;paste of addresses easy-peasy.

Dave</description>
		<content:encoded><![CDATA[<p>Eliotte:</p>
<p>I liked your remark about the address book. Actually the free-form version exists and is called Sbook5 at <a href="http://www.sbook5.com/" onclick="javascript:pageTracker._trackPageview('/outbound/comment/www.sbook5.com');" rel="nofollow">http://www.sbook5.com/</a> by Simson Garfinkel.</p>
<p>It can synchronise with Apple&#8217;s address book.<br />
It identifies fields and adds an icon, then you can manually fix the icon if it gets it wrong. Very nice approach and it makes copy&amp;paste of addresses easy-peasy.</p>
<p>Dave</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stephan Schmidt</title>
		<link>http://cafe.elharo.com/ui/fielded-input-considered-harmful/#comment-16402</link>
		<dc:creator>Stephan Schmidt</dc:creator>
		<pubDate>Mon, 18 Sep 2006 18:40:41 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/ui/fielded-input-considered-harmful/#comment-16402</guid>
		<description>Around 10 years ago we deployed a intranet time management software. We used free input fields for dates, and users entered everything.

18.09.2006
18/09/2006
06/09/18
09-18-06
20060906
9 Spetember 06

And every time we thought we had all, there was another user with another idea of how to write dates. Some of them were hard, like choosing between 09.06.2006 and 06.09.2006. Worked in the end though.</description>
		<content:encoded><![CDATA[<p>Around 10 years ago we deployed a intranet time management software. We used free input fields for dates, and users entered everything.</p>
<p>18.09.2006<br />
18/09/2006<br />
06/09/18<br />
09-18-06<br />
20060906<br />
9 Spetember 06</p>
<p>And every time we thought we had all, there was another user with another idea of how to write dates. Some of them were hard, like choosing between 09.06.2006 and 06.09.2006. Worked in the end though.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aaron</title>
		<link>http://cafe.elharo.com/ui/fielded-input-considered-harmful/#comment-16397</link>
		<dc:creator>Aaron</dc:creator>
		<pubDate>Mon, 18 Sep 2006 17:52:16 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/ui/fielded-input-considered-harmful/#comment-16397</guid>
		<description>I'm not sure what's the problem with delineating fields of input...although it should be done in a standard way which shouldn't depend underlying data structures but rather the standard way people represent the information.

Look at the examples:

Phone Number: (simple case) 111-111-1111 
Dashes represent breaks which can in turn be separate textboxes.

Address:  Look at an addressed envelope.  There are separate lines for the street address and city state zip.  The city and state are separated by a comma.

Date: It is usually separated by dashes or slashes.

Time: Colon separates hours from minutes.

And so on...so is it really the programmer or just naturally how certain data structures translate to computer UI as closely as possible to what people are used to in everyday lives?

I guess I should try free form entry next time I give someone a phone number or address an envelope and see how it goes.</description>
		<content:encoded><![CDATA[<p>I&#8217;m not sure what&#8217;s the problem with delineating fields of input&#8230;although it should be done in a standard way which shouldn&#8217;t depend underlying data structures but rather the standard way people represent the information.</p>
<p>Look at the examples:</p>
<p>Phone Number: (simple case) 111-111-1111<br />
Dashes represent breaks which can in turn be separate textboxes.</p>
<p>Address:  Look at an addressed envelope.  There are separate lines for the street address and city state zip.  The city and state are separated by a comma.</p>
<p>Date: It is usually separated by dashes or slashes.</p>
<p>Time: Colon separates hours from minutes.</p>
<p>And so on&#8230;so is it really the programmer or just naturally how certain data structures translate to computer UI as closely as possible to what people are used to in everyday lives?</p>
<p>I guess I should try free form entry next time I give someone a phone number or address an envelope and see how it goes.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ken</title>
		<link>http://cafe.elharo.com/ui/fielded-input-considered-harmful/#comment-16387</link>
		<dc:creator>Ken</dc:creator>
		<pubDate>Mon, 18 Sep 2006 14:57:20 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/ui/fielded-input-considered-harmful/#comment-16387</guid>
		<description>I wouldn't call it lazy programming.

Sadly, these things are not given importance during the software development while scheduling time &#38; effort. With programmer pushed to 'add more features', these things get pushed down the priority list.</description>
		<content:encoded><![CDATA[<p>I wouldn&#8217;t call it lazy programming.</p>
<p>Sadly, these things are not given importance during the software development while scheduling time &amp; effort. With programmer pushed to &#8216;add more features&#8217;, these things get pushed down the priority list.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Daniil S</title>
		<link>http://cafe.elharo.com/ui/fielded-input-considered-harmful/#comment-16381</link>
		<dc:creator>Daniil S</dc:creator>
		<pubDate>Mon, 18 Sep 2006 13:55:50 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/ui/fielded-input-considered-harmful/#comment-16381</guid>
		<description>I'm probably the most annoyed person when it comes to entering data or reading data. I absolutely refuse to read unformatted numbers like 1562.000005 or dates 20061809. It gets me furious. Or when I can't copy &#38; paste into field $1,001.11 - it is not that complex!!! I remember back in the old days when I was studying Pascal, their StrToNum (I think thats what it was called) was very loose function. It would convert string 1b1c2d into 112 without any problems. Why we can't have a nice loose function like that these days. It has good and bad in it, but still, sometimes we do need it.

Once I had to work on an online store application where I spent hours for all those UI cases to make user's life easier. Just a note, that app handled US and Canadian phone numbers with about 99% accuracy. That 1% was for people who actually put in textual values - I didn't even know people do that!!! But in any case, what I'm trying to say is that neither users nor site owners noticed my effort. This sort of thing is never appreciated because people simply assume it's there. But oh well, it did teach me a lot and improved me as a programmer.</description>
		<content:encoded><![CDATA[<p>I&#8217;m probably the most annoyed person when it comes to entering data or reading data. I absolutely refuse to read unformatted numbers like 1562.000005 or dates 20061809. It gets me furious. Or when I can&#8217;t copy &amp; paste into field $1,001.11 - it is not that complex!!! I remember back in the old days when I was studying Pascal, their StrToNum (I think thats what it was called) was very loose function. It would convert string 1b1c2d into 112 without any problems. Why we can&#8217;t have a nice loose function like that these days. It has good and bad in it, but still, sometimes we do need it.</p>
<p>Once I had to work on an online store application where I spent hours for all those UI cases to make user&#8217;s life easier. Just a note, that app handled US and Canadian phone numbers with about 99% accuracy. That 1% was for people who actually put in textual values - I didn&#8217;t even know people do that!!! But in any case, what I&#8217;m trying to say is that neither users nor site owners noticed my effort. This sort of thing is never appreciated because people simply assume it&#8217;s there. But oh well, it did teach me a lot and improved me as a programmer.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Uncle Dave</title>
		<link>http://cafe.elharo.com/ui/fielded-input-considered-harmful/#comment-16377</link>
		<dc:creator>Uncle Dave</dc:creator>
		<pubDate>Mon, 18 Sep 2006 12:50:48 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/ui/fielded-input-considered-harmful/#comment-16377</guid>
		<description>How about an e-mail account entry form that separates it into two chunks by providing the "@" in the middle!? SSN entry with three fields! IP addresses in pieces. MAC IDs. I've had to deal with all of these.</description>
		<content:encoded><![CDATA[<p>How about an e-mail account entry form that separates it into two chunks by providing the &#8220;@&#8221; in the middle!? SSN entry with three fields! IP addresses in pieces. MAC IDs. I&#8217;ve had to deal with all of these.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Erik Neu</title>
		<link>http://cafe.elharo.com/ui/fielded-input-considered-harmful/#comment-15600</link>
		<dc:creator>Erik Neu</dc:creator>
		<pubDate>Thu, 14 Sep 2006 21:09:01 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/ui/fielded-input-considered-harmful/#comment-15600</guid>
		<description>Good topic, very annoying stuff for the user to put up with. It seems like there should be standard UI widgets (or at least after-market OCX-type controls) that take care of the common cases. I must note that many of the Microsoft products are pretty flexible this way. Various apps in the Office suite will accept measurements in "in" or "pi" or "li". Outlook is quite flexible this way, too. And Streets &#38; Trips does very, very well in parsing. You can often copy and paste in a formatted address from a web page and get the results you want.</description>
		<content:encoded><![CDATA[<p>Good topic, very annoying stuff for the user to put up with. It seems like there should be standard UI widgets (or at least after-market OCX-type controls) that take care of the common cases. I must note that many of the Microsoft products are pretty flexible this way. Various apps in the Office suite will accept measurements in &#8220;in&#8221; or &#8220;pi&#8221; or &#8220;li&#8221;. Outlook is quite flexible this way, too. And Streets &amp; Trips does very, very well in parsing. You can often copy and paste in a formatted address from a web page and get the results you want.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gene</title>
		<link>http://cafe.elharo.com/ui/fielded-input-considered-harmful/#comment-15515</link>
		<dc:creator>Gene</dc:creator>
		<pubDate>Thu, 14 Sep 2006 12:53:22 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/ui/fielded-input-considered-harmful/#comment-15515</guid>
		<description>My pet peeve for input is credit card number fields with the note: "do not enter spaces or dashes". I mean, how hard is it to strip them out if you don't want them?</description>
		<content:encoded><![CDATA[<p>My pet peeve for input is credit card number fields with the note: &#8220;do not enter spaces or dashes&#8221;. I mean, how hard is it to strip them out if you don&#8217;t want them?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ivan</title>
		<link>http://cafe.elharo.com/ui/fielded-input-considered-harmful/#comment-15324</link>
		<dc:creator>Ivan</dc:creator>
		<pubDate>Wed, 13 Sep 2006 20:01:32 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/ui/fielded-input-considered-harmful/#comment-15324</guid>
		<description>I can't understand why my phone number can't be input as "two hundred 2, nine five 5 (4 + 1), four thousand two hundred thirty-1.

Silly programmers, sheesh!</description>
		<content:encoded><![CDATA[<p>I can&#8217;t understand why my phone number can&#8217;t be input as &#8220;two hundred 2, nine five 5 (4 + 1), four thousand two hundred thirty-1.</p>
<p>Silly programmers, sheesh!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
