<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>优涩控 &#187; 高度认知</title>
	<atom:link href="http://www.userkon.com/tag/%e9%ab%98%e5%ba%a6%e8%ae%a4%e7%9f%a5/feed" rel="self" type="application/rss+xml" />
	<link>http://www.userkon.com</link>
	<description>一群对用户脑残的家伙</description>
	<lastBuildDate>Tue, 11 Oct 2011 13:49:37 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.1</generator>
		<item>
		<title>胡诌Buzz</title>
		<link>http://www.userkon.com/tolyer/jumble_buzz.html</link>
		<comments>http://www.userkon.com/tolyer/jumble_buzz.html#comments</comments>
		<pubDate>Sun, 11 Apr 2010 10:51:13 +0000</pubDate>
		<dc:creator>大脸</dc:creator>
				<category><![CDATA[产品]]></category>
		<category><![CDATA[Buzz]]></category>
		<category><![CDATA[Google]]></category>
		<category><![CDATA[低度认知]]></category>
		<category><![CDATA[高度认知]]></category>

		<guid isPermaLink="false">http://www.userkon.com/?p=314</guid>
		<description><![CDATA[从Buzz推出之后，纷纷扰扰的看法就从未停歇过，对于Google强推的一款社交产品，Buzz确实值得获得分析与讨论。 胡诌需求 如果我用的观点来定性Buzz与twitter的区别，我会这么说：Buzz是沟通工具，而twitter则是一款传播工具。 很多用户抱怨Buzz内的自动置顶给他带来信息干扰，以及默认同步好友并公开关注列表让用户觉得个人隐私被出卖了。诚然Google的做法也是令人反感的。但工具本身并无好坏之分，关键在于是否用在正确的场景中。而Buzz的目的并不在于帮助你发现更多新奇有趣的信息，不在于帮你扩展你的社交圈（手机上的Nearby功能除外），如果以twitter使用习惯强加于他，你会觉得处处受困。Buzz的目的只是用于你现有社交圈的沟通方式的拓展而已。 那么有没有一种沟通情景，很符合目前Buzz的需求设计呢？Google团队在解释为啥 Google Buzz 没经过太多内测就提前放出就有涉及到： Jackson说当Google员工内部测试这个产品的时候，他们从未想到过要mute掉任何同事的对话，他们的邮件联系人列表里的同事就是他们在Buzz里follow的人。很显然，对于那些不在Google工作的人来说他们并不需要这样的配置，所以Google后来紧急发布了一系列针对隐私保护的新功能。——摘自谷奥 从以上的描述中，我们可以大致了解到，Buzz的沟通情景，适用于那些对内公开，对外封闭的实名小圈子。如某个企业内所有成员，如某种爱好者组织团队…… 实际上，Buzz所具有的即时性，储存性，以及半公开性，尤其适合于这种小圈子的讨论，或者用kentzhu的话说：信息的局域化传播。 想象一下公司内决定举行一次旅行。正常的沟通方式是： 秘书群发一封邮件给大家通报情况。 IM群上开始狂轰滥炸的讨论，如好不好玩？风景好不？美女多吗？ 各种各样的问题蜂拥而来，秘书在IM上被烦死。 临时有变动，惨了，秘书再发邮件。 临行前，秘书要给所有人发个短信确定一次。 几个丢三落四的家伙没有看到之前的信息，临行前只能给秘书打电话。 我想，等事情都安排好了，秘书都泪流满面了。这样不仅繁琐，且容易丢失信息。暴露了传统沟通方式的缺失： 邮件缺乏即时性（接收者无法即时接收到信息，所以秘书要发短信告知变更情况。） IM缺乏储存性（没有记住之前和秘书在IM上面说的内容，只能给秘书打电话。） 如果换个方式： 秘书在Buzz上发布旅游公告。 大家直接在Buzz上版聊，而且不必一直盯着它，过几分之后来看也不必担心漏过信息。 秘书可在Buzz上直接公开的回答，避免了重复提问。 临行有变动时，秘书直接修改Buzz内容即可，与此同时Gmail的Inbox内，提醒邮件也会自动更新。确保你永远收到的是最新的消息，而且信息保存在邮箱内，方便回头检索。 丢三落四的家伙没有看到之前的信息，可直接在Buzz上和秘书聊天获取及时信息。 从这中角度上说，我个人非常的看好Google App内Buzz的推出，对于Buzz这种新型的沟通方式而言，Google App是我认为他大展拳脚的方式。顺便提一下，即使微软，也不是推出了Office talk吗？ 胡诌信息单位 在Buzz中，所有的信息都一个完整的，按照时间线的方式呈现。从个人理解上讲，Buzz扩大了产品的最小信息单位：他不像微博，任意的一句话，一个回复，一个RT，都当作一条新的信息单位来处理；而是把这一整块的信息，都打包成为一条Buzz。保持了Gmail中对话模式以及论坛帖子相同等级的信息单位结构。 而这种处理方式，不仅有效地降低了用户普遍在twitter中遇到的信息过载问题，同时，它让信息的呈现变得更加地具有层次之分（主题与评论），并且易于追踪和回顾。 从这种角度上说，Buzz其实是一种更加便捷的论坛功能，对于论坛中流行的直播，版聊等微信息交流行为，如果移植到Buzz上，将会有更好的体验和呈现效果。 胡诌设计 Buzz的信息单位过大，虽然降低了信息过载。带来的问题是，单位信息量巨大从而让用户难以即时消化。那么从呈现上说，他不能学twitter那样，将信息呈现简单化到只有文字与链接，利于扫描和浅层阅读。Buzz必须让信息的呈现多样化，丰富，利于阅读和思考。 那么，在设计上，Buzz传承了Gmail邮件的会话模式风格，把操作功能收起来，给每条Buzz足够大的展示空间，让用户沉浸与阅读Buzz中；同时，为了避免用户深层阅读容易导致的导航迷失感，Buzz尽量的让所有的信息都在单个页面内呈现。而不是像twiiter那样，更多的导航，更高的跳出率，满足操作感。 就如同之前我所说的高度认知与低度认知差异一样。Buzz的低度设计非常的明显，这点我们从Buzz的主题折叠以及twitter导入功能可以看出。Buzz并不实时同步twitter，目的就是不让twitter的信息干扰用户的深层阅读。 作为低度认知产品，Buzz在国内可能会在水土不服，因国内的用户普遍偏向高度认知，国内用户偏好自由与广泛的信息流通，不管是搜集信息还是处理货传递信息，彼此之间的寻求与机遇都非常的频繁，属于高度的信息共享。相对于微博这类高度认知产品在国内的火热，Buzz注定与Gmail一样，成为某些高端人士的小众沟通平台。 &#8230; <a href="http://www.userkon.com/tolyer/jumble_buzz.html">继续阅读 <span class="meta-nav">&#8594;</span></a>]]></description>
			<content:encoded><![CDATA[<p>从Buzz推出之后，纷纷扰扰的看法就从未停歇过，对于Google强推的一款社交产品，Buzz确实值得获得分析与讨论。</p>
<h3>胡诌需求</h3>
<p>如果我用的观点来定性Buzz与twitter的区别，我会这么说：<strong>Buzz是沟通工具，而twitter则是一款传播工具。</strong><br />
很多用户抱怨Buzz内的自动置顶给他带来信息干扰，以及默认同步好友并公开关注列表让用户觉得个人隐私被出卖了。诚然Google的做法也是令人反感的。但工具本身并无好坏之分，关键在于是否用在正确的场景中。而Buzz的目的并不在于帮助你发现更多新奇有趣的信息，不在于帮你扩展你的社交圈（手机上的Nearby功能除外），如果以twitter使用习惯强加于他，你会觉得处处受困。Buzz的目的只是用于你现有社交圈的沟通方式的拓展而已。</p>
<p>那么有没有一种沟通情景，很符合目前Buzz的需求设计呢？Google团队在解释<a title="Google 产品经理解释为啥 Google Buzz 没经过太多内测就提前放出" href="http://www.google.org.cn/posts/google-product-manager-talk-about-google-buzz.html" target="_self">为啥 Google Buzz 没经过太多内测就提前放出</a>就有涉及到：</p>
<blockquote><p>Jackson说当Google员工内部测试这个产品的时候，他们从未想到过要mute掉任何同事的对话，他们的邮件联系人列表里的同事就是他们在Buzz里follow的人。很显然，对于那些不在Google工作的人来说他们并不需要这样的配置，所以Google后来紧急发布了一系列针对隐私保护的新功能。——摘自<a href="http://www.google.org.cn/" target="_self">谷奥</a></p></blockquote>
<p>从以上的描述中，我们可以大致了解到，Buzz的沟通情景，适用于那些对内公开，对外封闭的实名小圈子。如某个企业内所有成员，如某种爱好者组织团队……</p>
<p>实际上，Buzz所具有的即时性，储存性，以及半公开性，尤其适合于这种小圈子的讨论，或者用kentzhu的话说：<strong><a title="说GoogleBuzz，谈我心中的微博" href="http://www.ikent.me/blog/2284" target="_self">信息的局域化传播</a>。</strong></p>
<p><span id="more-314"></span></p>
<p>想象一下公司内决定举行一次旅行。正常的沟通方式是：</p>
<ol>
<li>秘书群发一封邮件给大家通报情况。</li>
<li>IM群上开始狂轰滥炸的讨论，如好不好玩？风景好不？美女多吗？</li>
<li>各种各样的问题蜂拥而来，秘书在IM上被烦死。</li>
<li>临时有变动，惨了，秘书再发邮件。</li>
<li>临行前，秘书要给所有人发个短信确定一次。</li>
<li>几个丢三落四的家伙没有看到之前的信息，临行前只能给秘书打电话。</li>
</ol>
<p>我想，等事情都安排好了，秘书都泪流满面了。这样不仅繁琐，且容易丢失信息。暴露了传统沟通方式的缺失：</p>
<p>邮件缺乏即时性（接收者无法即时接收到信息，所以秘书要发短信告知变更情况。）</p>
<p>IM缺乏储存性（没有记住之前和秘书在IM上面说的内容，只能给秘书打电话。）</p>
<p>如果换个方式：</p>
<ol>
<li>秘书在Buzz上发布旅游公告。</li>
<li>大家直接在Buzz上版聊，而且不必一直盯着它，过几分之后来看也不必担心漏过信息。</li>
<li>秘书可在Buzz上直接公开的回答，避免了重复提问。</li>
<li>临行有变动时，秘书直接修改Buzz内容即可，与此同时Gmail的Inbox内，提醒邮件也会自动更新。确保你永远收到的是最新的消息，而且信息保存在邮箱内，方便回头检索。</li>
<li>丢三落四的家伙没有看到之前的信息，可直接在Buzz上和秘书聊天获取及时信息。</li>
</ol>
<p>从这中角度上说，我个人非常的看好Google App内Buzz的推出，对于Buzz这种新型的沟通方式而言，Google App是我认为他大展拳脚的方式。顺便提一下，即使微软，也不是推出了<a href="http://www.officelabs.com/officetalk">Office talk</a>吗？</p>
<h3>胡诌信息单位</h3>
<p>在Buzz中，所有的信息都一个完整的，按照时间线的方式呈现。从个人理解上讲，Buzz扩大了产品的最小信息单位：他不像微博，任意的一句话，一个回复，一个RT，都当作一条新的信息单位来处理；而是把这一整块的信息，都打包成为一条Buzz。保持了Gmail中对话模式以及论坛帖子相同等级的信息单位结构。</p>
<p>而这种处理方式，不仅有效地降低了用户普遍在twitter中遇到的信息过载问题，同时，它让信息的呈现变得更加地具有层次之分（主题与评论），并且易于追踪和回顾。</p>
<p>从这种角度上说，Buzz其实是一种更加便捷的论坛功能，对于论坛中流行的<strong>直播</strong>，<strong>版聊</strong>等微信息交流行为，如果移植到Buzz上，将会有更好的体验和呈现效果。</p>
<h3>胡诌设计</h3>
<p>Buzz的信息单位过大，虽然降低了信息过载。带来的问题是，单位信息量巨大从而让用户难以即时消化。那么从呈现上说，他不能学twitter那样，将信息呈现简单化到只有文字与链接，利于扫描和浅层阅读。Buzz必须让信息的呈现多样化，丰富，利于阅读和思考。</p>
<p>那么，在设计上，Buzz传承了Gmail邮件的会话模式风格，把操作功能收起来，给每条Buzz足够大的展示空间，让用户沉浸与阅读Buzz中；同时，为了避免用户深层阅读容易导致的导航迷失感，Buzz尽量的让所有的信息都在单个页面内呈现。而不是像twiiter那样，更多的导航，更高的跳出率，满足操作感。</p>
<p>就如同之前我所说的<a title="高度认知与低度认知" href="highly_cognitive_and_minuent_cognitive.html" target="_self">高度认知与低度认知</a>差异一样。Buzz的低度设计非常的明显，这点我们从Buzz的主题折叠以及twitter导入功能可以看出。Buzz并不实时同步twitter，目的就是不让twitter的信息干扰用户的深层阅读。</p>
<p>作为低度认知产品，Buzz在国内可能会在水土不服，因国内的用户普遍偏向高度认知，国内用户偏好自由与广泛的信息流通，不管是搜集信息还是处理货传递信息，彼此之间的寻求与机遇都非常的频繁，属于高度的信息共享。相对于微博这类高度认知产品在国内的火热，Buzz注定与Gmail一样，成为某些高端人士的小众沟通平台。</p>
<p>那么什么的沟通产品适合国内的用户，我个人倾向于那种能提供评论，但限制字数的微博与Buzz的结合物。而这个东西就是新浪微博。</p>
<p>当然我不是权威人士，无较大的说服力和高瞻远瞩。所以题目也定为胡诌，何谓胡诌：信口瞎编，随意乱说。但有凭有据，只求自圆其说。</p>
]]></content:encoded>
			<wfw:commentRss>http://www.userkon.com/tolyer/jumble_buzz.html/feed</wfw:commentRss>
		<slash:comments>79</slash:comments>
		</item>
		<item>
		<title>高度认知与低度认知</title>
		<link>http://www.userkon.com/tolyer/highly_cognitive_and_minuent_cognitive.html</link>
		<comments>http://www.userkon.com/tolyer/highly_cognitive_and_minuent_cognitive.html#comments</comments>
		<pubDate>Fri, 13 Nov 2009 12:22:00 +0000</pubDate>
		<dc:creator>大脸</dc:creator>
				<category><![CDATA[交互设计]]></category>
		<category><![CDATA[低度认知]]></category>
		<category><![CDATA[就这么简单]]></category>
		<category><![CDATA[高度认知]]></category>

		<guid isPermaLink="false">http://www.userkon.com/?p=197</guid>
		<description><![CDATA[这是爱情公寓的注册页面，看到这幅图片您一定会乐了，因为两个按钮上的文字；但我们所关注的并不是其情感化的贴心语句，而是其所包含的对于高度认知与低度认知的差异化设计。 高度认知与低度认知是对用户的分类的一种维度，他对按照熟练度区分而出来的新手用户与专家用户既有相同性但也存在差异。高度认知与低度认知的差异的原因更多是文化以及生活习惯的沉淀，他们之间的相互转化也比较困难。在设计上，有必要考虑对两种用户的差异化而进行设计。 什么是高度认知与低度认知？ 有些人对于大部分信息都了然于胸，在操作的时候，更加依赖自己的经验或者习惯，因此，他们对于信息的需求量非常的少，有时候他们只需要很少的信息就能了解系统的状态。但有时候他们也容易过渡遵循自己的习惯于经验，即使出错也会一次次的重复操作下去。 低度认知则刚好相反，他们在操作的时候总是小心翼翼，生怕错过了重要的信息。他们需要阅读大量的信息，不然他们就难以确定是否要驱动其操作。他们不是“笨蛋”，也不是“新手”，他们只是更加注意细节。 在《就这么简单》这本书内，作者有提到： 中国用户大多为高度认知，因为中国人偏好自由与广泛的信息流通，不管是搜集信息还是处理货传递信息，彼此之间的寻求与机遇都非常的频繁，属于高度的信息共享。（想想大家是怎么分享电影，音乐的） 而在德国等低度认知的区域，信息相当的零散与片面，信息通常也不会共享，而且通常经过筛选。（经研究统计，他们使用搜索引擎的频率非常的高）这些地区的人在处理事物时，总是习惯要对该事物有全盘的了解才肯信任它。 抛开其用户分类方式，我们可以考虑从用户习惯中来尝试佐证这一分类。中国用户偏好使用短信，QQ，等一些简短的信息进行沟通，对比而言德国用户则偏向使用邮件，电话或者面谈来进行沟通。这是否可以确定此分类呢？ 如何给这种两种用户提供信息？ 虽然说高度认知的用户需要的信息量很少，但他们的阅读方式通常都是跳跃式的，意味着他们很容易就忽略了你为他提供的信息，他们也不会很老实的照着你设计的那样去浏览与实用，他们喜欢多任务处理，去挑战你设计的系统的极限。 存在的问题是，设计师无法预估这些用户对于信息的忽略的选择，可为保证系统功能的可见性，又不得不把所有的信息量展现出来。这真是矛盾的所在。 对于低度认知的用户而言，他们的操作偏向于单线程，他们对于信息会较为细心的阅读，同时他们也更具有耐心，愿意去学习，愿意努力去尝试或者去挖掘一些高级功能。 从总的上来说，高度认知的用户的操作会偏向宽而浅，同时处理的进程较多，但不够深入。低度认知用户则窄而深，他们能够将一个进程挖掘到底，他们会更多的去尝试高级功能。 如何设计？ 对于高度认知用户，我们应尽量的保证不打断其操作：在反馈的提示上，尽量简练明显。而对于信息的呈现，则应全盘呈现，把控制权与选择权更多交予用户。 在另外一方面，高度认知用户缺乏挖掘的耐心，所以，尽量的让功能可见并且一步到位。 对于低度认知用户而言，设计师们面临着更大的挑战，虽然他们愿意学习，有耐心，这就代表着系统必须有很强的导向性以及可学性。同时能够有更多的高级功能。 注意：无论对于那种设计而言，其在布局以及视觉的导向性与隐喻都是一致的。一个清晰的布局和架构是任何设计都必须的。 回到最初的图片，可以预见，完整注册属于一种低度认知设计，而快速注册则属于高度认知用户。当然，我们也可以用下面的两张图片进行举例对比。 在两个邮箱内，我们分别点击导航上的另外一个链接，两个邮箱都同时提供了“Loading”的反馈。有所不同的是：在点击另外一个链接时，Gmail是先在浮层内提示Loading，然后再呈现左侧导航的选中状态变化，以及右侧邮件列表的变化。AOLmail则先展现导航的选中状态变化，并在右侧显示Loading，然后再在右侧显示邮件列表的变化。 也许只是短暂的不到一秒的情况，发觉不了差异，但我们不妨做个假设，这个Loading需要的时间是1分钟。你能感觉出设计的差异化吗？ 高度认知设计提倡用户多任务处理，无论用户行为怎么样，并不直接打断用户的操作，让用户来处理这些事情（有可能这是很严重的问题）。有点像CPU多核概念。 低度认知则尽可能的让用户专注于当前的任务，帮助他更好的处理好当前的任务，而对于其他，他们并不关心。 也许你还不甚明白，那么可以再看看下面的这个例子。 同样的表格填写错误，高度认知设计不建议打断用户的操作，而低度认知则强调了这种打断，因为他可能是必须且重要的。 总结 当然，高度认知与低度认知只是对于用户习惯一种维度的区分，在设计上其实是可以达到并存的。此文只对其进行一些行为上的区分。 而在具体的一些设计当中，会根据功能的重要级与其属性，采用不同的设计方案，灵活多用。高度认知与低度认知的设计差异只是有助于理解设计的出发点，对于设计的指导性并不强烈。]]></description>
			<content:encoded><![CDATA[<p><a title="点击查看大图" href="http://farm3.static.flickr.com/2463/3964791356_f85fed1e57_o.jpg"><img src="http://69.147.90.215/2463/3964791356_4c11aafdbf.jpg" alt="点击查看大图" width="500" height="261" /></a></p>
<p>这是爱情公寓的注册页面，看到这幅图片您一定会乐了，因为两个按钮上的文字；但我们所关注的并不是其情感化的贴心语句，而是其所包含的对于高度认知与低度认知的差异化设计。</p>
<blockquote><p>高度认知与低度认知是对用户的分类的一种维度，他对按照熟练度区分而出来的新手用户与专家用户既有相同性但也存在差异。高度认知与低度认知的差异的原因更多是文化以及生活习惯的沉淀，他们之间的相互转化也比较困难。在设计上，有必要考虑对两种用户的差异化而进行设计。</p></blockquote>
<h3>什么是高度认知与低度认知？</h3>
<p>有些人对于大部分信息都了然于胸，在操作的时候，更加依赖自己的经验或者习惯，因此，他们对于信息的需求量非常的少，有时候他们只需要很少的信息就能了解系统的状态。但有时候他们也容易过渡遵循自己的习惯于经验，即使出错也会一次次的重复操作下去。</p>
<p><span id="more-197"></span></p>
<p>低度认知则刚好相反，他们在操作的时候总是小心翼翼，生怕错过了重要的信息。他们需要阅读大量的信息，不然他们就难以确定是否要驱动其操作。他们不是“笨蛋”，也不是“新手”，他们只是更加注意细节。</p>
<p>在<a href="http://www.douban.com/subject/3118374/" target="_blank">《就这么简单》</a>这本书内，作者有提到：</p>
<blockquote><p>中国用户大多为高度认知，因为中国人偏好自由与广泛的信息流通，不管是搜集信息还是处理货传递信息，彼此之间的寻求与机遇都非常的频繁，属于高度的信息共享。（想想大家是怎么分享电影，音乐的）</p>
<p>而在德国等低度认知的区域，信息相当的零散与片面，信息通常也不会共享，而且通常经过筛选。（经研究统计，他们使用搜索引擎的频率非常的高）这些地区的人在处理事物时，总是习惯要对该事物有全盘的了解才肯信任它。</p></blockquote>
<p>抛开其用户分类方式，我们可以考虑从用户习惯中来尝试佐证这一分类。中国用户偏好使用短信，QQ，等一些简短的信息进行沟通，对比而言德国用户则偏向使用邮件，电话或者面谈来进行沟通。这是否可以确定此分类呢？</p>
<h3>如何给这种两种用户提供信息？</h3>
<p>虽然说高度认知的用户需要的信息量很少，但他们的阅读方式通常都是跳跃式的，意味着他们很容易就忽略了你为他提供的信息，他们也不会很老实的照着你设计的那样去浏览与实用，他们喜欢多任务处理，去挑战你设计的系统的极限。</p>
<p>存在的问题是，设计师无法预估这些用户对于信息的忽略的选择，可为保证系统功能的可见性，又不得不把所有的信息量展现出来。这真是矛盾的所在。</p>
<p>对于低度认知的用户而言，他们的操作偏向于单线程，他们对于信息会较为细心的阅读，同时他们也更具有耐心，愿意去学习，愿意努力去尝试或者去挖掘一些高级功能。</p>
<p>从总的上来说，高度认知的用户的操作会偏向宽而浅，同时处理的进程较多，但不够深入。低度认知用户则窄而深，他们能够将一个进程挖掘到底，他们会更多的去尝试高级功能。</p>
<h3>如何设计？</h3>
<ol>
<li>对于高度认知用户，我们应尽量的保证不打断其操作：在反馈的提示上，尽量简练明显。而对于信息的呈现，则应全盘呈现，把控制权与选择权更多交予用户。
<p>在另外一方面，高度认知用户缺乏挖掘的耐心，所以，尽量的让功能可见并且一步到位。</li>
<li>对于低度认知用户而言，设计师们面临着更大的挑战，虽然他们愿意学习，有耐心，这就代表着系统必须有很强的导向性以及可学性。同时能够有更多的高级功能。</li>
<li><strong>注意：</strong>无论对于那种设计而言，其在布局以及视觉的导向性与隐喻都是一致的。一个清晰的布局和架构是任何设计都必须的。</li>
</ol>
<p>回到最初的图片，可以预见，完整注册属于一种低度认知设计，而快速注册则属于高度认知用户。当然，我们也可以用下面的两张图片进行举例对比。</p>
<p><a title="高度认知-Gmail.png" href="http://www.flickr.com/photos/41128764@N02/4108164069/"><img src="http://69.147.90.215/2654/4108164069_df5aae13fc.jpg" border="0" alt="高度认知-Gmail.png" hspace="0" /></a></p>
<p><a title="低度认知-aol.png" href="http://www.flickr.com/photos/41128764@N02/4108163857/"><img src="http://69.147.90.215/2764/4108163857_3050c7f22b.jpg" border="0" alt="低度认知-aol.png" hspace="0" /></a></p>
<p>在两个邮箱内，我们分别点击导航上的另外一个链接，两个邮箱都同时提供了“Loading”的反馈。有所不同的是：在点击另外一个链接时，Gmail是先在浮层内提示Loading，然后再呈现左侧导航的选中状态变化，以及右侧邮件列表的变化。AOLmail则先展现导航的选中状态变化，并在右侧显示Loading，然后再在右侧显示邮件列表的变化。</p>
<p>也许只是短暂的不到一秒的情况，发觉不了差异，但我们不妨做个假设，这个Loading需要的时间是1分钟。你能感觉出设计的差异化吗？</p>
<p>高度认知设计提倡用户多任务处理，无论用户行为怎么样，并不直接打断用户的操作，让用户来处理这些事情（有可能这是很严重的问题）。有点像CPU多核概念。</p>
<p>低度认知则尽可能的让用户专注于当前的任务，帮助他更好的处理好当前的任务，而对于其他，他们并不关心。</p>
<p>也许你还不甚明白，那么可以再看看下面的这个例子。</p>
<p><a title="高度认知-填表.png" href="http://www.flickr.com/photos/41128764@N02/4108182687/"><img src="http://69.147.90.215/2581/4108182687_5902e6fb4d.jpg" border="0" alt="高度认知-填表.png" hspace="0" /></a></p>
<p><a title="低度认知-填表.png" href="http://www.flickr.com/photos/41128764@N02/4108182569/"><img src="http://69.147.90.215/2630/4108182569_88d53d0211.jpg" border="0" alt="低度认知-填表.png" hspace="0" /></a></p>
<p>同样的表格填写错误，高度认知设计不建议打断用户的操作，而低度认知则强调了这种打断，因为他可能是必须且重要的。</p>
<h3>总结</h3>
<p>当然，高度认知与低度认知只是对于用户习惯一种维度的区分，在设计上其实是可以达到并存的。此文只对其进行一些行为上的区分。</p>
<p>而在具体的一些设计当中，会根据功能的重要级与其属性，采用不同的设计方案，灵活多用。高度认知与低度认知的设计差异只是有助于理解设计的出发点，对于设计的指导性并不强烈。</p>
]]></content:encoded>
			<wfw:commentRss>http://www.userkon.com/tolyer/highly_cognitive_and_minuent_cognitive.html/feed</wfw:commentRss>
		<slash:comments>71</slash:comments>
		</item>
	</channel>
</rss>

