网页设计配色应用——色调

　　网页布局类型

　　网页布局大致可分为“国”字型、拐角型、标题正文型、左右框架型、上下框架型、综合框架型、封面型、Flash型、变化型，下面分别论述。

　　1、“国”字型:也可以称为“同”字型，是一些大型网站所喜欢的类型，即最上面是网站的标题以及横幅广告条，接下来就是网站的主要内容，左右分列一些两小条内容，中间是主要部分，与左右一起罗列到底，最下面是网站的一些基本信息、联系方式、版权声明等。这种结构是我们在网上见到的差不多最多的一种结构类型。

　　2、拐角型:这种结构与上一种其实只是形式上的区别，其实是很相近的，上面是标题及广告横幅，接下来的左侧是一窄列链接等，右列是很宽的正文，下面也是一些网站的辅助信息。在这种类型中，一种很常见的类型是最上面是标题及广告，左侧是导航链接。

　　3、标题正文型:这种类型即最上面是标题或类似的一些东西，下面是正文，比如一些文章页面或注册页面等就是这种类。

　　4、左右框架型:这是一种左右为分别两页的框架结构，一般左面是导航链接，有时最上面会有一个小的标题或标致，右面是正文。我们见到的大部分的大型论坛都是这种结构的，有一些企业网站也喜欢采用。这种类型结构非常清晰，一目了然。

　　5、上下框架型:与上面类似，区别仅仅在于是一种上下分为两页的框架。

　　6、综合框架型:上页两种结构的结合，相对复杂的一种框架结构，较为常见的是类似于“拐角型”结构的，只是采用了框架结构。

　　7、封面型:这种类型基本上是出现在一些网站的首页，大部分为一些精美的平面设计结合一些小的动画，放上几个简单的链接或者仅是一个“进入”的链接甚至直接在首页的图片上做链接而没有任何提示。这种类型大部分出现在企业网站和个人主页，如果说处理的好，会给人带来赏心悦目的感觉。

　　8、Flash型:其实这与封面型结构是类似的，只是这种类型采用了目前非常游戏行的Flash，与封面型不同的是，由于Flash强大的功能，页面所表达的信息更丰富，其视觉效果及听觉效果如果处理得当，绝不差于传统的多媒体。

　　9、变化型:即上面几种类型的结合与变化，比如本站在视觉上是很接近拐角型的，但所实现的功能的实质是那种上、左、右结构的综合框架型。

　　关于第一屏

　　所谓第一屏，是指我们到达一个网站在不拖动滚动条时能够看到的部分。那么第一屏有多“大”呢?其实这是未知的。一般来讲，在800*600的屏幕显示模式(这也是最常用的)下，在IE安装后默认的状态(即工具栏地址栏等没有改变)下，IE窗口内能看到的部分为778px*435px，一般来讲，我们以这个大小为标准就行了，毕竟，在无法适合所有人的情况下，我们只能为大多数考虑了。

　　说了那么多，无非是一个标准的问题，其实接下来不用我说大家也能想到，第一屏当然要放最主要的内容，关键要知道的是，我们要对第一屏能显示的面积要有个估计，而不要仅仅以自己的机器为准。其实网页制作的一个很麻烦的地方就是浏览者的机器是未知的。

　　有关导航栏的位置

　　导航栏能让我们在浏览时容易的到达不同的页面，是网页元素非常重要的部分，所以导航栏一定要清晰、醒目，一般来讲，导航栏要在“第一屏”能显示出来，但是有时第一屏可能会小于上面所说的435px，积于这点考虑，那种横向放置的导航栏要优于纵向的导航栏考虑，原因很简单:如果浏览者的第一屏很矮，横向的仍能全部看到，而纵向的就很难说了，因为窗口的宽度一般是不会受浏览器设置影响的，而纵向的则不确定性要大的多。

　　什么样的布局是最好的

　　这是网页制作初学者可能会问的问题。其实这要具体情况具体分析的:比如如果内容非常多，就要考虑用“国字型”或拐角型;而如果内容不算太多而一些说明性的东西比较多，则可以考虑标题正文型;那几种框架结构的一个共同特点就是浏览方便，速度快，但结构变化不灵活;而如果是一个企业网站想展示一下企业形象或个人主页想展示个人风采，封面性是首选;Flash型更灵活一些，好的Flash大大丰富了网页，但是它不能表达过多的文字信息。还没有提到的就是变化型了，我只是想把这个留给读者了，因为，只有不断的变化才会提高，才会不断丰富我们的网页!

今早在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很智能的，有时不会那么蠢真的一拥而上地去访问。

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

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

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

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

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

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

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

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

当我第一次输入一个错误的密码时，系统在判断错误后会在提示错误的同时把我的这个输入记忆，当我再次输入这个错误密码时，系统会自动在客户端提示“密码错误”。是否“完全以用户为中心做设计”是一个很值得关注的问题。
对于“用户登录”来说，要求用户必须登录会给用户的操作带来一定的不便和麻烦，但如果完全不需要用户登录也不利用长期的用户体验提高过程、更不利于很好的信息共享和交流。

记得在之前写过 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，小明查完“北京”的天气后就离开这个网站了。