<?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; Google</title>
	<atom:link href="http://www.userkon.com/tag/google/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>榨干Chrome UI</title>
		<link>http://www.userkon.com/tolyer/analizing_chrome_ui.html</link>
		<comments>http://www.userkon.com/tolyer/analizing_chrome_ui.html#comments</comments>
		<pubDate>Sun, 07 Feb 2010 14:40:57 +0000</pubDate>
		<dc:creator>大脸</dc:creator>
				<category><![CDATA[交互设计]]></category>
		<category><![CDATA[Chrome]]></category>
		<category><![CDATA[Google]]></category>
		<category><![CDATA[ui]]></category>

		<guid isPermaLink="false">http://www.userkon.com/?p=301</guid>
		<description><![CDATA[目前的我，已经成为Chrome的严重依赖用户，甚至U盘内也随身装着Chrome便携版。对我而言，它有着其他浏览器无法代替的杀手级优势：快速，稳定，完美支持Google所有在线服务；简洁到一塌糊涂的界面。 而其他浏览器，他们只在一些特殊需求中才会使用，如Firefox的AutoProxy翻墙，IE插件下的网银支付，Opera的turbo加速等。 用过Chrome的的人都有个习惯：就是都不好意思说Chrome不好用。当然这是玩笑话，Chrome 3.0版本之前功能也一直较为简单，但并不妨碍它的用户对其赞不绝口。究其根本，还是出在其独具一格的UI体验上。 只用一句话来评价：Chrome 才是浏览器，其他的只是软件。 戈达尔曾经为证明斯皮尔伯格是一个平庸的导演而愤怒地说过：“如果你真想知道他为什么（平庸），我会在放映室里一个镜头一个镜头地讲给你听！” 现在我要做一件类似的事情，不过目的是为了证明Chrome是一款多么优秀的浏览器。 目标导向设计 Chrome刚推出的时候，所有人都大吃一惊：界面简单得以至于菜单栏都砍掉了。这么多的菜单栏命令去哪里了呢？被重新组合了。 示例问题：猜猜，“清除历史浏览记录”的功能分别在哪个菜单项里面？ 当你还在思考此命令在Firefox中的“History”还是“Tools”时；我想你应该早已确定这个功能位于chrome的“控制谷歌浏览器”的菜单内。 看，这是多大的差别！什么叫做符合用户第一直觉，这就是。 作为一个M粉，我个人的臆想是，Chrome是向Ribbon的致敬与学习： 1.基于用户的目标，对浏览器的命令进行再分类。 这使得Chrome只有两个菜单项：控制当前页，控制谷歌浏览器。这有效的降低用户对命令的记忆要求。（可用性原则之一：依赖识别而不是记忆。） M粉牢骚：这与Ribbon的的分类有异曲同工之妙。 2.先将命令砍掉一半，剩下的再砍掉一半。 Chrome对于命令的精简可谓大刀阔斧，把一些用户目标之外的功能都通通剔除，避免陷入了功能主义，打造一个纯粹的、100%的浏览器。（当然，这其中也有Google的产品战略原因） 看上图你就能看到Chrome是如何砍命令项的，命令虽然精简了，但实际使用上，Chrome的右键菜单并不会让我有功能缺失感。Chrome并不是为了精简而精简，他们的精简是有理有据的，由用户的目标而来。 而对比菜单项命令，以及对话框的命令。Chrome将“历史记录”“下载记录”“扩展记录”这些功能都采用独立标签页呈现。一些常用对话框呈现的命令修改为浮层呈现。如“设为默认浏览器”，“保存密码”，”添加至收藏夹“。 这些做法的好处就是：让Chrome的命令项始终保持在“浅并且窄”的结构内（可参阅《设计心理学》），遵循用户从外到内的认知规则，确保用户有较好的控制感（Sense of Control）： 大部分右键菜单项在10个以内。 没有三层或更深的菜单项或者窗口叠加。 少用模态的控件打断用户焦点，让其保持在标签页内。 M粉的我再次牢骚：Ribbon的设计的目的之一就是提高用户的控制感。BTW，如果数一下每个浏览器的工具栏命令数，Chrome再次证明它是最“纯”的。 最佳响应性与操控感 相对于其他浏览器，Chrome做了以下的变化： 砍掉了菜单栏以及窗口标题栏。 将地址栏与搜索栏整合。 动态的状态栏。 界面简单了，命令也少了。给Chrome的带来的第一优势就是：同等屏幕尺寸下，Chrome拥有最佳的最大的的显示区域。但在响应性上，Chrome却反而领先其他浏览器。Chrome的优秀反馈，让用户只需较少的注意力就能了解系统的状态，从而专注于自己的本身的任务与信息。 让我们从标签栏说起。这是Chrome最具魅力的地方。 1.向左转，向右转 注意到加载网页时，标签栏左侧的进度图标反馈吗？ Chrome精细的用三种相对的信息（方向，颜色，速度）来向用户传达浏览器的状态：正在连接服务器；已连接服务器，正在加载网站。 大部分情况他们只是一闪而过，但出现问题时，他有助与你了解情况：假如您访问一个不存在的网站，如twitter.com，那么你就只能看到逆时针的进度图标了。 2.向左走，向右走 &#8230; <a href="http://www.userkon.com/tolyer/analizing_chrome_ui.html">继续阅读 <span class="meta-nav">&#8594;</span></a>]]></description>
			<content:encoded><![CDATA[<p>目前的我，已经成为Chrome的严重依赖用户，甚至U盘内也随身装着Chrome便携版。对我而言，它有着其他浏览器无法代替的杀手级优势：快速，稳定，完美支持Google所有在线服务；简洁到一塌糊涂的界面。</p>
<p>而其他浏览器，他们只在一些特殊需求中才会使用，如Firefox的AutoProxy翻墙，IE插件下的网银支付，Opera的turbo加速等。</p>
<p>用过Chrome的的人都有个习惯：就是都不好意思说Chrome不好用。当然这是玩笑话，Chrome 3.0版本之前功能也一直较为简单，但并不妨碍它的用户对其赞不绝口。究其根本，还是出在其独具一格的UI体验上。</p>
<p>只用一句话来评价：<strong>Chrome 才是浏览器，其他的只是软件。</strong></p>
<p>戈达尔曾经为证明斯皮尔伯格是一个平庸的导演而愤怒地说过：“如果你真想知道他为什么（平庸），我会在放映室里一个镜头一个镜头地讲给你听！”</p>
<p>现在我要做一件类似的事情，不过目的是为了证明Chrome是一款多么优秀的浏览器。</p>
<p><span id="more-301"></span></p>
<h3>目标导向设计</h3>
<p>Chrome刚推出的时候，所有人都大吃一惊：<strong>界面简单得以至于菜单栏都砍掉了</strong>。这么多的菜单栏命令去哪里了呢？<strong>被重新组合了</strong>。</p>
<p><strong>示例问题：猜猜，“清除历史浏览记录”的功能分别在哪个菜单项里面？</strong></p>
<p><a title="menu_bar by 优涩控, on Flickr" href="http://www.flickr.com/photos/userkon/4317971055/"><span style="color: #0044aa; background-color: #ffffff;"> </span><img title="firefox与Chrome菜单项对比" src="http://67.195.19.74/4060/4317971055_11a8dbb844.jpg" alt="firefox与Chrome菜单项对比" width="500" height="191" /></a></p>
<p>当你还在思考此命令在Firefox中的“History”还是“Tools”时；我想你应该早已确定这个功能位于chrome的“控制谷歌浏览器”的菜单内。</p>
<p>看，这是多大的差别！什么叫做符合用户第一直觉，这就是。</p>
<p>作为一个M粉，我个人的臆想是，Chrome是向Ribbon的致敬与学习：</p>
<p><strong>1.基于用户的目标，对浏览器的命令进行再分类。</strong></p>
<p>这使得Chrome只有两个菜单项：<strong>控制当前页</strong>，<strong>控制谷歌浏览器</strong>。这有效的降低用户对命令的记忆要求。（可用性原则之一：依赖识别而不是记忆。）</p>
<p>M粉牢骚：这与Ribbon的的分类有异曲同工之妙。</p>
<p><a title="Tab in 2007 and Menu in 2003 by 优涩控, on Flickr" href="http://www.flickr.com/photos/userkon/4280737271/"><img title="Ribbon UI中的命令精简与分类对比" src="http://67.195.19.74/4028/4280737271_51dcfa3008_o.jpg" alt="Ribbon UI中的命令精简与分类对比" width="543" height="85" /></a></p>
<p><strong>2.先将命令砍掉一半，剩下的再砍掉一半。</strong></p>
<p>Chrome对于命令的精简可谓大刀阔斧，把一些用户目标之外的功能都通通剔除，避免陷入了功能主义，打造一个纯粹的、100%的浏览器。（当然，这其中也有Google的产品战略原因）</p>
<p><a title="right_menu by 优涩控, on Flickr" href="http://www.flickr.com/photos/userkon/4318059199/"><img title="很明显吧，左边三个家伙都没Chrome纯" src="http://67.195.19.74/4052/4318059199_cbc80b122c.jpg" alt="很明显吧，左边三个家伙都没Chrome纯" width="500" height="282" /></a></p>
<p>看上图你就能看到Chrome是如何砍命令项的，命令虽然精简了，但实际使用上，Chrome的右键菜单并不会让我有功能缺失感。Chrome并不是为了精简而精简，他们的精简是有理有据的，由用户的目标而来。</p>
<p>而对比菜单项命令，以及对话框的命令。Chrome将“历史记录”“下载记录”“扩展记录”这些功能都采用独立标签页呈现。一些常用对话框呈现的命令修改为浮层呈现。如“设为默认浏览器”，“保存密码”，”添加至收藏夹“。</p>
<p>这些做法的好处就是：让Chrome的命令项始终保持在“<strong>浅并且窄</strong>”的结构内（可参阅《<a title="去豆瓣看看这本书吧!" href="http://www.douban.com/subject/1288844/">设计心理学</a>》），遵循用户<a title="作为交互的8项基本原则，在GUI设计禁忌2.0中有明确提到。用户对于产品的理解是从外到内的，而设计师的顺序则是从内至外，认知顺序的冲突，是设计师需要慎重考虑的。" href="http://www.douban.com/subject/3263946/">从外到内</a>的认知规则，确保用户有较好的控制感（<strong>Sense of Control</strong>）：</p>
<ul>
<li>大部分右键菜单项在10个以内。</li>
<li>没有三层或更深的菜单项或者窗口叠加。</li>
<li>少用模态的控件打断用户焦点，让其保持在标签页内。</li>
</ul>
<p>M粉的我再次牢骚：Ribbon的设计的目的之一就是提高用户的控制感。BTW，如果数一下每个浏览器的工具栏命令数，Chrome再次证明它是最“<strong>纯</strong>”的。</p>
<h3>最佳响应性与操控感</h3>
<p>相对于其他浏览器，Chrome做了以下的变化：</p>
<ul>
<li>砍掉了菜单栏以及窗口标题栏。</li>
<li>将地址栏与搜索栏整合。</li>
<li>动态的状态栏。</li>
</ul>
<p>界面简单了，命令也少了。给Chrome的带来的第一优势就是：同等屏幕尺寸下，Chrome拥有最佳的最大的的显示区域。但在响应性上，Chrome却反而领先其他浏览器。Chrome的优秀反馈，让用户只需较少的注意力就能了解系统的状态，从而专注于自己的本身的任务与信息。</p>
<p>让我们从标签栏说起。这是Chrome最具魅力的地方。</p>
<h4>1.向左转，向右转</h4>
<p><a title="tab-bar-at-Chrome by 优涩控, on Flickr" href="http://www.flickr.com/photos/userkon/4334722206/"><span style="color: #ffffff; background-color: #303536;"> </span><img src="http://67.195.19.74/4028/4334722206_8126026dc8_o.png" alt="tab-bar-at-Chrome" width="500" height="97" /></a></p>
<p>注意到加载网页时，标签栏左侧的进度图标反馈吗？</p>
<p>Chrome精细的用三种相对的信息（方向，颜色，速度）来向用户传达浏览器的状态：正在连接服务器；已连接服务器，正在加载网站。</p>
<p>大部分情况他们只是一闪而过，但出现问题时，他有助与你了解情况：假如您访问一个不存在的网站，如twitter.com，那么你就只能看到逆时针的进度图标了。</p>
<h4>2.向左走，向右走</h4>
<p>Chrome的标签栏操作上始终保持着缓冲式的过渡动画，对于反馈而言，他提供了<strong>隐喻</strong>，符合用户的操作期望。</p>
<p>于是乎，当一个新标签打开时，看起来就像一个新的标签从左侧向右滑出（这里顺带说一下，Mac下是从下自上滑出，有点意思吧。）。当关闭一个标签时，看起来就像标签向左边缩进去一样。Chrome始终用一种与现实生活相符合的预期动画，去呈现用户的操作，而这种动画，是最高效最生动而又最小化的反馈。</p>
<h4>3.最小的操作需求</h4>
<p>无论什么样的用户，大都想不劳而获，都不喜欢软件向他索取过多的东西。用户不仅仅是讨厌输入，讨厌按键盘，用户甚至讨厌去过多的移动他的鼠标。尤其是面对多次的重复操作时，想想当你需求遍历多页网页时，网页那糟糕的，到处跳动的翻页导航是多么的让你愤怒，你就大概能了解为什么了。</p>
<p>Chrome的最小操作需求，是关闭标签栏，当你存在多个标签时，你可以不移动鼠标就能关闭多个，这种设计操控感非常的强烈。谷奥上已经有<a title="从关闭标签页的动作细节看 Chrome 和 Safari" href="http://www.google.org.cn/posts/closing-tab-in-chrome-and-safari.html" target="_blank">详细的分析</a>了。在此就不多说。</p>
<h4>4.一个顶俩</h4>
<p><a title="One box by 优涩控, on Flickr" href="http://www.flickr.com/photos/userkon/4318073655/"><img src="http://67.195.19.74/4021/4318073655_bbe0234416.jpg" alt="One box" width="500" height="279" /></a></p>
<p>我说的一个顶俩指的是Chrome的地址栏。网上有云：真正好的用户界面都只有一个按钮，比如iPhone，比如抽水马桶。说起来还真有那么一点道理。</p>
<p>地址栏的作用就是带我们去到想去的地方。这么说，一定需要把地址栏与搜索栏区分吗？</p>
<p>难道的士司机会和你说：hey，你说的这个地方我无法识别，你问问我旁边的这个家伙，他能搜索？</p>
<p>Chrome的一条地址栏减少了用户的思考。但地址栏的自动完成反馈反而让用户更直白了解浏览器接下来将带领去去到何处。可以看到，Chrome在这里进行了有效分类，不至于让用户迷失和困惑。</p>
<p><a title="onebox by 优涩控, on Flickr" href="http://www.flickr.com/photos/userkon/4336401603/"><img src="http://67.195.19.74/4045/4336401603_ed80a0a35e.jpg" alt="onebox" width="500" height="152" /></a></p>
<p>另外其的可学性也不差，你无需帮助即可了解Ctrl+Enter的快捷操作。<a title="onebox2 by 优涩控, on Flickr" href="http://www.flickr.com/photos/userkon/4337146480/"><img src="http://67.195.19.74/4026/4337146480_fc76c04c5a_o.png" alt="onebox2" width="498" height="228" /></a></p>
<p>Chrome的地址栏设计方法，我个人的看法而言，有点像我之前所讨论过的<a title="高度认知与低度认知" href="http://www.userkon.com/highly_cognitive_and_minuent_cognitive.html" target="_blank">低度认知</a>设计：将任务的开始点压迫得极度精简（只保留一条地址栏），提高任务的深度（输入后的可选路径浮层），反而能帮助用户做更多的工作。渐进式的操作结构，在满足低级用户的默认需求时，能够给高级用户带来更高的满意度。</p>
<p>但是，一条地址栏的缺陷在于：如果用户的第一目的是搜索，怎么解决？</p>
<p>在Windows的体验规范中，就有这么一条：在任何界面内ctrl+E，将使焦点定位在搜索框内。看看Chrome是怎么解决的？你可自行尝试。尝试之后记得说“Chrome牛X”。</p>
<p>这里还有一个<a title="Browser Speed Test 2 4 searches in 15 seconds" href="http://v.youku.com/v_show/id_XMTQxODM2MjIw.html" target="_blank">视频</a>，15秒Chrome能完成四次搜索。这才叫一个顶俩。</p>
<h4>4.最“有用”</h4>
<p>Windows用户体验规范中谈及状态栏时是这么说的：</p>
<blockquote><p>状态栏通常使用文本和图标来描述状态，但它也可以包含进度指示器，以及包含与状态相关的命令菜单与选项。确保状态栏中的信息对用户来说<strong>有用且有实际意义</strong>，但也<strong>并非至关重要</strong>。——<a title="Windows 用户体验交互设计规范——状态栏" href="http://www.uxguide.net/wiki/windows:Controls/status-bars" target="_blank">来源</a></p></blockquote>
<p><a title="statusbar by 优涩控, on Flickr" href="http://www.flickr.com/photos/userkon/4336459563/"><img src="http://69.147.90.215/2749/4336459563_a3b32b7dbc_o.png" alt="statusbar" width="500" height="115" /></a></p>
<p>那我们来仔细对比一下，状态栏中的进度条到底对用户有用吗？没用，因为大部分网站在完全载入之前都无法正常使用。而且一个网页的载入如果还需要进度条来反馈，那么这个网页本来就存在问题。用户也不会对载入超过10秒并且还需浏览器来提供进度反馈的网站有任何的耐心。</p>
<p>OK，进度条是没用的，应该去掉，那么类似IE右侧的状态信息有用吗？对于一个没有过多附属功能的Chrome来说，他确实没用。（但我个人认为，Chrome扩展开放之后，应该在此开拓扩展栏，与状态栏整合。）</p>
<p>什么是有用的且有实际意义的信息？看图:</p>
<p><a title="upload-status by 优涩控, on Flickr" href="http://www.flickr.com/photos/userkon/4337246446/"><img src="http://69.147.90.215/2681/4337246446_9160de9831_o.png" alt="upload-status" width="499" height="346" /></a></p>
<p>在一个较为古老的上传交互模型上，系统本身没有提供任何有效的反馈，Chrome通过状态栏秒杀了其他一切浏览器：他提供了进度的反馈。同时，他的标签栏采用逆时针方向，表示正在和服务器进行数据交换。</p>
<p>让我们回到标题的最开始，叫做最佳响应性：Chrome不是功能最多的浏览器，但响应性是最佳的。这也就不难理解同样功能简单，而且还是MAC系统默认浏览器的safari，占有率<a title="Google Chrome成為全球第三大瀏覽器" href="http://www.techbang.com.tw/?p=30716" target="_blank">转眼就被超越</a>。</p>
<p>响应性给用户带来何种好处：无语伦比的操控感；那种感觉，就像在极品飞车内遇到一款傻瓜式的操控豪华跑车一样，爽。</p>
<h3>暗藏的OS野心</h3>
<p>最后说一点题外话，对于Chrome OS，我们在Chrome内多少能看到其一点雏形，如Chrome的菜单内已经没有打开本地文件的命令，但其最重要的创意在于“创建应用程序快捷方式&#8230;”</p>
<p><a title="chrome mail163 by 优涩控, on Flickr" href="http://www.flickr.com/photos/userkon/4337648424/"><img src="http://69.147.90.215/2679/4337648424_66e5832874.jpg" alt="chrome mail163" width="500" height="312" /></a></p>
<p>在上图中，这个界面已经具有很强的软件外观了，并且其在于本地的东西，只是一个只有1K大小的快捷方式。</p>
<p>因此看来，我们还需要安装一大堆的东西在本地的硬盘，然后去启动吗？不用，一切可变得简单，也许有天你点击桌面的某个快捷方式，你就可以直接使用使用Photoshop，真正的免安装，且不限平台。</p>
<p>当然，目前而言，Chrome OS还有一大推的问题需要解决，比如如何定义模态对话框与非模态对话框的实现，网络应用如何避免过渡的单页呈现。但从长远来看，这种趋势是不可逆转的。</p>
<p>其实一开始听到Chrome OS我是拒绝的，因为你不能说这是OS，我就认为这是OS，第一我要试一下，因为我不愿意试了之后用一些蛊惑人心的话去赞美它，很好很强大很快。这样其他M粉一定会鄙视我，根本没有这么方便的OS，就证明上面那个是假的。后来我也证实Chrome 确实有OS雏形，我使用了它“创建应用程序&#8230;”大概一个月左右,感觉就像使用本地软件一样，后来我介绍给同事的时候，也没有吹牛，因为我让他们知道，我是这么使用的，很爽，你们用得时候很会这么爽。</p>
<h3>最后的话</h3>
<p>Chrome是我最爱的一个浏览器，同时它也是优秀的。Chrome的优秀在于它树立了浏览器新的未来方向，浏览器的任务不仅仅是网页的呈现，浏览器也不应该是传统意义上的软件，它应该是一个彻底脱离用户本地电脑的东西，它应该被赋予更多的用户目标与期望，利用云端的海量信息和即时技术让用户的目标更快更容易实现。</p>
<p>本文标题虽为榨干Chrome UI，其实只是力求榨干。我相信，每多使用一次Chrome，你就会多一次惊喜，多一份满意。最后附送几段关于Chrome的视频:</p>
<ul>
<li><a href="http://www.google.org.cn/posts/chrome-video-by-google-uk.html">非常有创意的 Chrome 新广告</a></li>
<li><a href="http://briian.com/?p=6282">19個有趣的Google Chrome廣告影片</a>(需翻墙)</li>
<li><a href="http://www.google.org.cn/posts/what-chrome-can-do-in-15-seconds.html">15秒种时间，Chrome 可以完成什么工作？</a></li>
</ul>
<p>最后，假设您能坚持看到这个，提前祝您虎年快乐，哥让我和你说：“爱老虎邮。”</p>
]]></content:encoded>
			<wfw:commentRss>http://www.userkon.com/tolyer/analizing_chrome_ui.html/feed</wfw:commentRss>
		<slash:comments>419</slash:comments>
		</item>
	</channel>
</rss>

