网页登录界面设计需要注意的几个问题

登录界面经常遇到的几个问题：

1、“注册”“找回密码”等这些个非“登录”任务本身的嫡亲应该安排在那里？
我的观点：首先一定要明确“严格来说他们并不属于这个任务”。
放在那里不重要，重要的是我们需要给表现成“相关任务”，不要当作该任务界面的主要元素来处理。（无论在架构还是在交互上都不要让他“喧宾夺主”）

2、“保存cookies”“登录设置”等些个“登录”任务的直系亲属应该如何处理？
我的观点：首先，这些属于任务的一部分。
其次， 如果默认设置能够帮助完成这些信息可以尽量不需要在登录任务里显示，
然后，如果需要 一定要简洁，但简洁的同时要注意文字的表达（如，“自动登录=保存密码+自动登陆”的表达就很不合适）。而且一定要注意默认的备选项设置。

3、表单的排列是横排还是竖排？横排该怎么排，竖排又该怎么排？
我的观点：横排还是竖排要看页面的排版所需，没有什么大的原则问题。具体怎么排只要用心思考一下肯定就知道权衡了，
横排用户的焦点轨迹跨度较大，但空间占用较小；竖排用户的焦点轨迹可以是直线，但空间较大。如果条件允许我建议用竖排，如果规范所限或条件有限我不介意用横排。但大部分情况下我很介意在输入框中默认一些类似"再次输入密码"等傻瓜提示信息的行为。

4、是否需要验证码？
我的观点： 如果安全性没有大问题的话一定不要。
但好像你的技术搭档绝大部分时候都会告诉你“安全性”有大问题，所以很多时候我们不能“为了细节的良好体验而纵容了系统的安全受挫”...

所以这个命题索性可以改成“验证码”应该怎么设计？
我反对一： 中文验证码 （纯弱智的设计）
我反对二： 英文和数字混合的验证码 （给用户输入带来了不少麻烦）
我反对三： 超过4位的验证码 （记忆中好像据说是什么研究结果）
我反对四： 有大写字母的验证码，
特别是大小写混合且实际系统判断时还不区别大小写的 —— 虽然你不区分大小写，但你显示的是大写很多用户就会很费劲的打开大写输入填写大写字母，无形中给用户带来了负担。

5、目前看到的一个我最喜欢的登录任务的设计：

喜欢一：
任务明确，登录任务应该包括“登录信息+登录设置”，“找回密码”不属于登录任务，这些它都交代的很清楚。
喜欢二：
流程清楚，竖排排列用户可以直线思维操作， 用户>密码>保存密码>登录 一气呵成。
喜欢三：
设计精简，类似“保存我的信息”“自动登录”都没有放到这里，这就是我所说的“如果默认设置能够帮助完成，这些信息可以尽量不需要”。因为，大部分情况下如果你真的需要设置 说明你已经不是简单的初级用户，那么你一定有能力自己去找解决方案
喜欢四：
小细节大学问之 —— 错误密码记忆。
看看上图“用户>密码>保存密码>”三个步骤之间都有一个不小的行间距，这个间距空袭乍一看似乎并没有什么作用。
但研究过的人会发现里面的学问不小..
如：

当我第一次输入一个错误的密码时，系统在判断错误后会在提示错误的同时把我的这个输入记忆，当我再次输入这个错误密码时，系统会自动在客户端提示“密码错误”。今早在www.aspalliance.com上看到一篇文章（Stopping Automated Web Robots Visiting ASP/ASP.NET Websites
，http://aspalliance.com/1018_Stopping_Automated_Web_Robots_Visiting_ASPASPNET_Websites），
主要是讲了下如何采取一些措施，防止robot过度去抓你的网站。看了一下，有的东西还是值得探讨下的，现归纳如下：

1、辨认ROBOT的一些参考标准
    Large numbers of requests from a single IP address or a range of IP addresses within the same subnet (i.e. the first three numbers of the IP address are identical).
·         Large numbers of requests for database driven content compared to the rest of the website.

·         Many requests made from browsers that do not support ASP Sessions.

·         Lots of and increasing numbers of website visitors, but no corresponding increase in transactions (e.g. sales!).

·         Large numbers of spam or automated requests being generated from online forms.
2、到http://www.robotstxt.org/wc/norobots.html上，可以找到一个组织提出的防御robot的建议标准（可惜这个不是什么权威标准拉，没什么约束力），在这里有一些平常我们可以用到的例子和方法，主要是搞一个robot.txt文件，放在网站根目录下，比如
User-agent: *
Disallow: /
禁止所有robot

允许所有的robot访问：

User-agent: *
Disallow:

User-agent: *
Disallow: /cyberworld/map/      不允许robot探访/cyberworld/map目录下的文件

User-agent: cybermapper    允许cybermapper这个robot
Disallow:

User-agent: *
Disallow: /cyberworld/map/
Disallow: /tmp/
Disallow: /foo.html       不允许访问foo.html这个文件了

3、如果不方便设置robot.txt的话，还可以在meta里做手脚，比如用
<meta name="robots" content="noindex, nofollow">
可以单独对某页设置防御robot

4 减慢robot的疯狂访问。如果发现robot疯狂对你的站访问，而造成效率的降低的话，可以减低
robot的访问，
User-agent: Slurp
Crawl-delay: 10

是针对yahoo的，具体可以到http://help.yahoo.com/help/us/ysearch/slurp/slurp-03.html
去看详细情况。但其实有的robot很智能的，有时不会那么蠢真的一拥而上地去访问。

是否“完全以用户为中心做设计”是一个很值得关注的问题。
对于“用户登录”来说，要求用户必须登录会给用户的操作带来一定的不便和麻烦，但如果完全不需要用户登录也不利用长期的用户体验提高过程、更不利于很好的信息共享和交流。

记得在之前写过 Google Personalized PK Windows Live ,其中回忆过GMAIL刚刚推出时和朋友们的讨论“如果总是把用户赶出自己的网站，利润的想象空间非常之小！需要慢慢的让用户留在自己的网站上！要想让用户留在这个平台上那么首先要做的肯定是给他们一个属于自己的东西，让他们有所依附！让他们在这里可以创造点自己的"乐趣"。...”

我想这不光光是商业目的的需求，更是更深层次用户体验的需求。

刚刚看到刘韧在用户登录是web2.0的前提 中说到“用户登录进来之后，2.0就可以分析跟踪用户的喜好，向他展现最贴近他以往偏好的内容和服务。2.0的神奇在于，既是大规模的，又是个性化的。”

我想他实际想说的应该是“用户参与”。
是的，“用户登录”是“用户参与”的基本。

• 最近在搞个和2.0相关的兴趣性探索，其中就遇到了这样的问题“是否要求用户必须登录？用户不登录的时候允许他可以完成百分之多少的任务？什么时候要求用户登录才合适？”
  坦白的说这是一个头痛的问题：
  我们必将慢慢走向一个“信息开放、信息共享、信息交流”的世界，用户登录是其中一个必要的基础。我们需要用户“走进房间来交流”而不是“自由的在门口观望一切”。
• 用户的操作过程就是一个“流”。我们无法在“流”的源头就给他们一个卡子，所以用户必须在未登录的状态下应该一样可以完成一些简サ娜挝瘛＃ㄖ劣谀芡瓿啥嗌俚娜挝衲谌菥陀Ω檬且桓龆鹊目刂莆侍猓?彩且桓鐾吠吹奈侍猓?
• 什么时候打断用户“流”让用户登录？
  很多情况下当我们要求用户完成登录任务的时候，更多的可能就是给用户带来“厌烦”和“不爽”。
  可以看到现在我们现在很多地方的做法都是“在用户十分想要完成任务”的时候去打断用户的“流”，要求用户登录（就算你不爽，为了你的目标你也不会拒绝这么做）。
  我想，更好的做法应该是：把用户登录很好的人性化设计，使“用户登录”成为“流”的一个自然组成。（呵呵，说起来很随意，做起来就很让人郁闷了）

另外一个前段很被大家关注的：
Don Norman —— 过分以人为中心的设计是有害的 （来自UIG）

-------------------------------------------------------------------------
1、在讨论组里一个很有意思针对这篇BLOG的讨论：
HI，

有两个问题需要注意：

1、这里所谓的登录并不是说你“输入用户名+输入密码,登录成功..”，广义上说他是“用户对系统的一个信息提交”这个提交的过程可以有很多种形式。比如你登录带很多ASP论坛的时候会先提示你使用了cookie，其实这就是一种登录.
2、所谓的“。。、。。、信息交流”不单单是说用户和用户之间的对话，他应该还包括“用户和系统之间的交流”..

======== 2006-01-04 09:23:46 您在来信中写道： ========

小明的故事恰恰是没有登录但网站提供了实际有效的服务
"但如果完全不需要用户登录也不利用长期的用户体验提高过程、更不利于很好的信息共享和交流。"冠冕堂皇的是可以这么说，但实际上还不如说是不利于抄做、推广、拉钱之类的事情。常常听到我们的网站多少多少排名，多少多少用户之类的话,
这个"流"非常好和有必要。

-------------------------------------------------------------------------

2、2006年01月03号收到短信：
1860:"交通部门提示：今晨，东三环京广桥东南角辅路污水管放生漏水事故，东三环京广桥朝阳路附近实行交通管制，请车辆绕行。谢谢广大市民的配合与支持"

充分的说明有些时候“用户登录”也还是有些积极作用的嘛~~ 要看什么人怎么在用了， 说实话我收到那个短信的时候激动了半天，。。　

-------------------------------------------------------------------------
3、有位朋友在刘韧那里给了这样一个回复，吾胜是喜欢：

小明访问了一个查询天气的网站，初次访问时，被写入一个 COOKIE，小明查完“北京”的天气后就离开这个网站了。