<?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:georss="http://www.georss.org/georss"
	xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#"
	
	>
<channel>
	<title>
	Comments on: Do not burden your users with validations	</title>
	<atom:link href="/2009/08/do-not-burden-your-users-with-validations/feed/" rel="self" type="application/rss+xml" />
	<link>/2009/08/do-not-burden-your-users-with-validations/</link>
	<description>Plataformatec&#039;s place to talk about Ruby, Ruby on Rails, Elixir, and software engineering</description>
	<lastBuildDate>Fri, 08 Apr 2011 12:57:02 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.4.2</generator>
	<item>
		<title>
		By: Rhett		</title>
		<link>/2009/08/do-not-burden-your-users-with-validations/comment-page-1/#comment-256</link>

		<dc:creator><![CDATA[Rhett]]></dc:creator>
		<pubDate>Sun, 13 Sep 2009 21:00:18 +0000</pubDate>
		<guid isPermaLink="false">/?p=123#comment-256</guid>

					<description><![CDATA[Tim:  I definitely agree that sign up forms should be short. I often copy and paste the confirmation fields myself.

To build upon your Jakob Nielson quote, I think masking by default would be the way to go in this scenario.

If the password is not masked by default then I am assuming you would be using a textfield input with a type value of &quot;text&quot;. Presumably, this would allow the password to be cached in the user&#039;s autocomplete field in plain readable text. The next user might be able to arrow down on the autocomplete field and view the password.

On the other hand, if the password is masked by default, then you are probably using an input with a type value of &quot;password&quot; and then using JavaScript to turn it to an input type of &quot;text&quot; after the checkbox is clicked.

Is that what you&#039;re thinking?  I&#039;m not necessarily opposed to the idea, but I think that masked passwords are a convention that users are comfortable with.  It seems like superfluous work to me and if you add a bunch of checkboxes, like &quot;unmask password&quot; and &quot;remember me next time,&quot; your login form begins to take up more real estate.  That wouldn&#039;t matter in a dedicated login page, but if you want your login form to be in the header of the website, the design might get a little cramped.  Just my 2 cents.]]></description>
			<content:encoded><![CDATA[<p>Tim:  I definitely agree that sign up forms should be short. I often copy and paste the confirmation fields myself.</p>
<p>To build upon your Jakob Nielson quote, I think masking by default would be the way to go in this scenario.</p>
<p>If the password is not masked by default then I am assuming you would be using a textfield input with a type value of &#8220;text&#8221;. Presumably, this would allow the password to be cached in the user&#8217;s autocomplete field in plain readable text. The next user might be able to arrow down on the autocomplete field and view the password.</p>
<p>On the other hand, if the password is masked by default, then you are probably using an input with a type value of &#8220;password&#8221; and then using JavaScript to turn it to an input type of &#8220;text&#8221; after the checkbox is clicked.</p>
<p>Is that what you&#8217;re thinking?  I&#8217;m not necessarily opposed to the idea, but I think that masked passwords are a convention that users are comfortable with.  It seems like superfluous work to me and if you add a bunch of checkboxes, like &#8220;unmask password&#8221; and &#8220;remember me next time,&#8221; your login form begins to take up more real estate.  That wouldn&#8217;t matter in a dedicated login page, but if you want your login form to be in the header of the website, the design might get a little cramped.  Just my 2 cents.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Tim Case		</title>
		<link>/2009/08/do-not-burden-your-users-with-validations/comment-page-1/#comment-255</link>

		<dc:creator><![CDATA[Tim Case]]></dc:creator>
		<pubDate>Sun, 13 Sep 2009 15:51:16 +0000</pubDate>
		<guid isPermaLink="false">/?p=123#comment-255</guid>

					<description><![CDATA[Rhett: On the applications I work on there is a strong concern about losing users due to a complicated sign up so we do everything we can to minimize required fields and we try to delay sign up until later in the process. Adding more fields to the signup for  a person who mistypes both their email address and their password isn&#039;t important to us.

Security is subjective, and you&#039;ll need to apply judgement as to whether usability or security is a bigger concern for the application that you are working on.

“Yes, users are sometimes truly at risk of having bystanders spy on their passwords, such as when they’re using an Internet cafe. It’s therefore worth offering them a checkbox to have their passwords masked; for high-risk applications, such as bank accounts, you might even check this box by default. In cases where there’s a tension between security and usability, sometimes security should win.”  -- Jakob Nielson]]></description>
			<content:encoded><![CDATA[<p>Rhett: On the applications I work on there is a strong concern about losing users due to a complicated sign up so we do everything we can to minimize required fields and we try to delay sign up until later in the process. Adding more fields to the signup for  a person who mistypes both their email address and their password isn&#8217;t important to us.</p>
<p>Security is subjective, and you&#8217;ll need to apply judgement as to whether usability or security is a bigger concern for the application that you are working on.</p>
<p>“Yes, users are sometimes truly at risk of having bystanders spy on their passwords, such as when they’re using an Internet cafe. It’s therefore worth offering them a checkbox to have their passwords masked; for high-risk applications, such as bank accounts, you might even check this box by default. In cases where there’s a tension between security and usability, sometimes security should win.”  &#8212; Jakob Nielson</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Rhett		</title>
		<link>/2009/08/do-not-burden-your-users-with-validations/comment-page-1/#comment-248</link>

		<dc:creator><![CDATA[Rhett]]></dc:creator>
		<pubDate>Sat, 12 Sep 2009 18:08:22 +0000</pubDate>
		<guid isPermaLink="false">/?p=123#comment-248</guid>

					<description><![CDATA[Harry:  If you don&#039;t require the user to confirm their password, do you require that they confirm their email address?  One of the two probably needs to be confirmed. If they mis-type their email address, the &quot;forgot password&quot; feature will be useless.

Tim:  I definitely do not like the idea of using an unmasked password.  Too much of a security risk.  Imagine if you were using an ATM and your PIN number was visible to all the people standing in line behind you.  Maybe your Facebook account isn&#039;t as valuable, but it would certainly seem to indicate a laxness of security standards that your future clients may not be comfortable with.]]></description>
			<content:encoded><![CDATA[<p>Harry:  If you don&#8217;t require the user to confirm their password, do you require that they confirm their email address?  One of the two probably needs to be confirmed. If they mis-type their email address, the &#8220;forgot password&#8221; feature will be useless.</p>
<p>Tim:  I definitely do not like the idea of using an unmasked password.  Too much of a security risk.  Imagine if you were using an ATM and your PIN number was visible to all the people standing in line behind you.  Maybe your Facebook account isn&#8217;t as valuable, but it would certainly seem to indicate a laxness of security standards that your future clients may not be comfortable with.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Mike		</title>
		<link>/2009/08/do-not-burden-your-users-with-validations/comment-page-1/#comment-187</link>

		<dc:creator><![CDATA[Mike]]></dc:creator>
		<pubDate>Sun, 06 Sep 2009 18:50:56 +0000</pubDate>
		<guid isPermaLink="false">/?p=123#comment-187</guid>

					<description><![CDATA[The validatable gem allows validations to before performed sequentially so that multiple error messages aren&#039;t shown at once. Perhaps not so useful for rails yet, but it&#039;s a nice solution to the problem your post discusses.

http://validatable.rubyforge.org/]]></description>
			<content:encoded><![CDATA[<p>The validatable gem allows validations to before performed sequentially so that multiple error messages aren&#8217;t shown at once. Perhaps not so useful for rails yet, but it&#8217;s a nice solution to the problem your post discusses.</p>
<p><a href="http://validatable.rubyforge.org/" rel="nofollow ugc">http://validatable.rubyforge.org/</a></p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Hugo Baraúna		</title>
		<link>/2009/08/do-not-burden-your-users-with-validations/comment-page-1/#comment-154</link>

		<dc:creator><![CDATA[Hugo Baraúna]]></dc:creator>
		<pubDate>Wed, 02 Sep 2009 13:09:55 +0000</pubDate>
		<guid isPermaLink="false">/?p=123#comment-154</guid>

					<description><![CDATA[Thanks Tim! I hope we can always see your comments here.

See ya! =)]]></description>
			<content:encoded><![CDATA[<p>Thanks Tim! I hope we can always see your comments here.</p>
<p>See ya! =)</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Tim Case		</title>
		<link>/2009/08/do-not-burden-your-users-with-validations/comment-page-1/#comment-153</link>

		<dc:creator><![CDATA[Tim Case]]></dc:creator>
		<pubDate>Wed, 02 Sep 2009 12:50:22 +0000</pubDate>
		<guid isPermaLink="false">/?p=123#comment-153</guid>

					<description><![CDATA[Err sorry Hugo the post excellent!]]></description>
			<content:encoded><![CDATA[<p>Err sorry Hugo the post excellent!</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
