<?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: UIEtips Article: 8 More Design Mistakes with Account Sign-in</title>
	<atom:link href="http://www.uie.com/brainsparks/2008/01/14/uietips-article-8-more-design-mistakes-with-account-sign-in/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.uie.com/brainsparks/2008/01/14/uietips-article-8-more-design-mistakes-with-account-sign-in/</link>
	<description>UIE\'s latest insights on the world of design</description>
	<pubDate>Fri,  5 Dec 2008 14:56:04 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Brian</title>
		<link>http://www.uie.com/brainsparks/2008/01/14/uietips-article-8-more-design-mistakes-with-account-sign-in/#comment-144152</link>
		<dc:creator>Brian</dc:creator>
		<pubDate>Fri, 24 Oct 2008 14:46:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/2008/01/14/uietips-article-8-more-design-mistakes-with-account-sign-in/#comment-144152</guid>
		<description>Re: Comment 2 - Garry Says: January 14th, 2008 at 1:47 pm  
Garry's link in Comment #2 -- http://www.goodsecurityquestions.com/examples.htm -- is now "Not Found"</description>
		<content:encoded><![CDATA[<p>Re: Comment 2 - Garry Says: January 14th, 2008 at 1:47 pm<br />
Garry&#8217;s link in Comment #2 &#8212; <a href="http://www.goodsecurityquestions.com/examples.htm" rel="nofollow">http://www.goodsecurityquestions.com/examples.htm</a> &#8212; is now &#8220;Not Found&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: 10 Blog-Lesetipps der Woche f&#252;r Shopbetreiber &#187; Tipps, Muster, Checklisten, News, Urteile f&#252;r Online-H&#228;ndler &#187; shopbetreiber-blog.de</title>
		<link>http://www.uie.com/brainsparks/2008/01/14/uietips-article-8-more-design-mistakes-with-account-sign-in/#comment-107781</link>
		<dc:creator>10 Blog-Lesetipps der Woche f&#252;r Shopbetreiber &#187; Tipps, Muster, Checklisten, News, Urteile f&#252;r Online-H&#228;ndler &#187; shopbetreiber-blog.de</dc:creator>
		<pubDate>Thu, 07 Feb 2008 09:50:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/2008/01/14/uietips-article-8-more-design-mistakes-with-account-sign-in/#comment-107781</guid>
		<description>[...] 8 More Design Mistakes with Account Sign-in von UIE Brain Sparks [...]</description>
		<content:encoded><![CDATA[<p>[...] 8 More Design Mistakes with Account Sign-in von UIE Brain Sparks [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Did I Get #13 Wrong? - Do All Sites Need Similar Security? &#187; UIE Brain Sparks</title>
		<link>http://www.uie.com/brainsparks/2008/01/14/uietips-article-8-more-design-mistakes-with-account-sign-in/#comment-105189</link>
		<dc:creator>Did I Get #13 Wrong? - Do All Sites Need Similar Security? &#187; UIE Brain Sparks</dc:creator>
		<pubDate>Wed, 30 Jan 2008 20:42:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/2008/01/14/uietips-article-8-more-design-mistakes-with-account-sign-in/#comment-105189</guid>
		<description>[...] folks wrote to tell me I&#8217;d gotten this wrong &#8212; that, in fact, this is intentional to throw off [...]</description>
		<content:encoded><![CDATA[<p>[...] folks wrote to tell me I&#8217;d gotten this wrong &#8212; that, in fact, this is intentional to throw off [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Premasagar</title>
		<link>http://www.uie.com/brainsparks/2008/01/14/uietips-article-8-more-design-mistakes-with-account-sign-in/#comment-103369</link>
		<dc:creator>Premasagar</dc:creator>
		<pubDate>Thu, 17 Jan 2008 05:46:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/2008/01/14/uietips-article-8-more-design-mistakes-with-account-sign-in/#comment-103369</guid>
		<description>Nice set of observations here, Jared.

&lt;a href="http://en.wikipedia.org/wiki/Openid" rel="nofollow"&gt;OpenId&lt;/a&gt; login is becoming more common these days and will probably become fairly ubiquitous soon. It is a new kind of login where you only need to have a username and password on one website on the Web, which you use to log in to other sites. The use of OpenID bypasses a number of the issues that you raise.

However, a number of user experience issues have started to crop up with OpenID's implementation into sites. For example, on &lt;a href="http://premasagar.onaswarm.com" rel="nofollow"&gt;Onaswarm&lt;/a&gt; (a lifestream social network), the OpenID login looks like it requires a password (but there is no need for a password with OpenID) and does not function unless the 'http://' part of the url is included (yet does not mention that it requires it). Still, we live and learn...</description>
		<content:encoded><![CDATA[<p>Nice set of observations here, Jared.</p>
<p><a href="http://en.wikipedia.org/wiki/Openid" rel="nofollow">OpenId</a> login is becoming more common these days and will probably become fairly ubiquitous soon. It is a new kind of login where you only need to have a username and password on one website on the Web, which you use to log in to other sites. The use of OpenID bypasses a number of the issues that you raise.</p>
<p>However, a number of user experience issues have started to crop up with OpenID&#8217;s implementation into sites. For example, on <a href="http://premasagar.onaswarm.com" rel="nofollow">Onaswarm</a> (a lifestream social network), the OpenID login looks like it requires a password (but there is no need for a password with OpenID) and does not function unless the &#8216;http://&#8217; part of the url is included (yet does not mention that it requires it). Still, we live and learn&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Greg Nudelman</title>
		<link>http://www.uie.com/brainsparks/2008/01/14/uietips-article-8-more-design-mistakes-with-account-sign-in/#comment-103214</link>
		<dc:creator>Greg Nudelman</dc:creator>
		<pubDate>Tue, 15 Jan 2008 21:27:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/2008/01/14/uietips-article-8-more-design-mistakes-with-account-sign-in/#comment-103214</guid>
		<description>Excellent article, Jared!  Gold standard in sign in Partner Experience, as only UIE can put it.  This list was tremendously helpful in our recent eBay.com registration redesign.
Thanks again!</description>
		<content:encoded><![CDATA[<p>Excellent article, Jared!  Gold standard in sign in Partner Experience, as only UIE can put it.  This list was tremendously helpful in our recent eBay.com registration redesign.<br />
Thanks again!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Indu RS</title>
		<link>http://www.uie.com/brainsparks/2008/01/14/uietips-article-8-more-design-mistakes-with-account-sign-in/#comment-103113</link>
		<dc:creator>Indu RS</dc:creator>
		<pubDate>Mon, 14 Jan 2008 23:36:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/2008/01/14/uietips-article-8-more-design-mistakes-with-account-sign-in/#comment-103113</guid>
		<description>Jared, 

Excellent article on User Sign-in. This study provides quite a lot of information for UX and Usability engineers to set goals and standards. I agree in except for the #13.

Thanks again.</description>
		<content:encoded><![CDATA[<p>Jared, </p>
<p>Excellent article on User Sign-in. This study provides quite a lot of information for UX and Usability engineers to set goals and standards. I agree in except for the #13.</p>
<p>Thanks again.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Larry Halleran</title>
		<link>http://www.uie.com/brainsparks/2008/01/14/uietips-article-8-more-design-mistakes-with-account-sign-in/#comment-103101</link>
		<dc:creator>Larry Halleran</dc:creator>
		<pubDate>Mon, 14 Jan 2008 20:55:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/2008/01/14/uietips-article-8-more-design-mistakes-with-account-sign-in/#comment-103101</guid>
		<description>Jared, 

This is great information to think about before designing a sign in. I think of only part of my problem as not thinking through the design to better address these kinds of issues up front. The bigger part is not finding a way to let my users tell me when I am making mistakes. How do we make it easy for any user of our websites to quickly and easily give us feedback on their experience? I would think a quick rating sytem (select 1 through 9) would give only a crude measurement of effectiveness and user satisfaction with my website. Alternatively, asking them to type a long explanation that would provide specific information does not seem to be very user friendly either.

Thanks,</description>
		<content:encoded><![CDATA[<p>Jared, </p>
<p>This is great information to think about before designing a sign in. I think of only part of my problem as not thinking through the design to better address these kinds of issues up front. The bigger part is not finding a way to let my users tell me when I am making mistakes. How do we make it easy for any user of our websites to quickly and easily give us feedback on their experience? I would think a quick rating sytem (select 1 through 9) would give only a crude measurement of effectiveness and user satisfaction with my website. Alternatively, asking them to type a long explanation that would provide specific information does not seem to be very user friendly either.</p>
<p>Thanks,</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cris</title>
		<link>http://www.uie.com/brainsparks/2008/01/14/uietips-article-8-more-design-mistakes-with-account-sign-in/#comment-103092</link>
		<dc:creator>Cris</dc:creator>
		<pubDate>Mon, 14 Jan 2008 18:39:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/2008/01/14/uietips-article-8-more-design-mistakes-with-account-sign-in/#comment-103092</guid>
		<description>Great article(s), Jared. A friend of mine sent me the links today.  I think most of these problems spring from developers coding for their own convenience rather than the user's. 

I do have to take issue with your assertion on Mistake #12: "Coding the return point from the registration process is technically very difficult."  It's not difficult at all. That information can be stored several ways (e.g. on the url, in a cookie, in a server-side session) so it's available at the end of the registration process.</description>
		<content:encoded><![CDATA[<p>Great article(s), Jared. A friend of mine sent me the links today.  I think most of these problems spring from developers coding for their own convenience rather than the user&#8217;s. </p>
<p>I do have to take issue with your assertion on Mistake #12: &#8220;Coding the return point from the registration process is technically very difficult.&#8221;  It&#8217;s not difficult at all. That information can be stored several ways (e.g. on the url, in a cookie, in a server-side session) so it&#8217;s available at the end of the registration process.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Garry</title>
		<link>http://www.uie.com/brainsparks/2008/01/14/uietips-article-8-more-design-mistakes-with-account-sign-in/#comment-103083</link>
		<dc:creator>Garry</dc:creator>
		<pubDate>Mon, 14 Jan 2008 17:47:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/2008/01/14/uietips-article-8-more-design-mistakes-with-account-sign-in/#comment-103083</guid>
		<description>Hello Jared, 
Thanks for you great newsletter and excellent experience. Much appreciated. 

I also disagree with #13 - Not Explaining If It’s The Username or Password They Got Wrong. As a user, when I fail a sign-in, I wish I knew what was wrong, but as a developer I know it would significantly reduce the security if we told the user what was wrong: the username or password. The solution is to provide a way for the user to retrieve both the username and password through a smart and secure method. I don't think it should be configurable by the user since they often don't understand the consequences.

Regarding #11 - Using Challenge Questions They Won't Remember In A Year, I agree and would suggest this goes further than remembering in one year. Security questions actually present a hole or weakness in a sign-in and in reality should be called "in-security" questions. However, the risk is low if developed correctly and developers use "good" questions. After being frustrated on numerous websites with "favorite" questions (which are poor questions), I decided to offer a list of questions that developers can use along with my opinions about which are better than others: http://www.goodsecurityquestions.com/examples.htm

Thanks again.</description>
		<content:encoded><![CDATA[<p>Hello Jared,<br />
Thanks for you great newsletter and excellent experience. Much appreciated. </p>
<p>I also disagree with #13 - Not Explaining If It’s The Username or Password They Got Wrong. As a user, when I fail a sign-in, I wish I knew what was wrong, but as a developer I know it would significantly reduce the security if we told the user what was wrong: the username or password. The solution is to provide a way for the user to retrieve both the username and password through a smart and secure method. I don&#8217;t think it should be configurable by the user since they often don&#8217;t understand the consequences.</p>
<p>Regarding #11 - Using Challenge Questions They Won&#8217;t Remember In A Year, I agree and would suggest this goes further than remembering in one year. Security questions actually present a hole or weakness in a sign-in and in reality should be called &#8220;in-security&#8221; questions. However, the risk is low if developed correctly and developers use &#8220;good&#8221; questions. After being frustrated on numerous websites with &#8220;favorite&#8221; questions (which are poor questions), I decided to offer a list of questions that developers can use along with my opinions about which are better than others: <a href="http://www.goodsecurityquestions.com/examples.htm" rel="nofollow">http://www.goodsecurityquestions.com/examples.htm</a></p>
<p>Thanks again.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: leovernazza</title>
		<link>http://www.uie.com/brainsparks/2008/01/14/uietips-article-8-more-design-mistakes-with-account-sign-in/#comment-103080</link>
		<dc:creator>leovernazza</dc:creator>
		<pubDate>Mon, 14 Jan 2008 17:15:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/2008/01/14/uietips-article-8-more-design-mistakes-with-account-sign-in/#comment-103080</guid>
		<description>Hi Jared, I have to disagree with you in the #13...

This is just another case of security -vs- UX trade off, but in this case I agree with this kind of solution. 

Accurate error messages are great for everyone trying to enter the account, and it's not just you, it could be i.e. a hacker. If the system explicits that the username is VALID, thay can just fix it and try passwords until violate your account. Besides, sometimes the username is an email address, and that's ALL a spammer need to know about you. If the system helps them to discover the customer's email, it will produce a huge user experience detriment via spam... 

It would be great to have the best of all worlds, but in this case, I think the trade off is completely necessary and the examples you presentes are a good solution.

Ok, maybe it should be configurable by the user. After all, he should be the one to decide about what is worst for him... What do you think?</description>
		<content:encoded><![CDATA[<p>Hi Jared, I have to disagree with you in the #13&#8230;</p>
<p>This is just another case of security -vs- UX trade off, but in this case I agree with this kind of solution. </p>
<p>Accurate error messages are great for everyone trying to enter the account, and it&#8217;s not just you, it could be i.e. a hacker. If the system explicits that the username is VALID, thay can just fix it and try passwords until violate your account. Besides, sometimes the username is an email address, and that&#8217;s ALL a spammer need to know about you. If the system helps them to discover the customer&#8217;s email, it will produce a huge user experience detriment via spam&#8230; </p>
<p>It would be great to have the best of all worlds, but in this case, I think the trade off is completely necessary and the examples you presentes are a good solution.</p>
<p>Ok, maybe it should be configurable by the user. After all, he should be the one to decide about what is worst for him&#8230; What do you think?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
