白社会界面交互设计规范.docx
《白社会界面交互设计规范.docx》由会员分享，可在线阅读，更多相关《白社会界面交互设计规范.docx（48页珍藏版）》请在冰点文库上搜索。
白社会界面交互设计规范
白社会界面交互设计规范
2010-4-16初稿
第一章概述
1.目的
在产品设计初期，进行了部分功能的交互设计之后，将用户与界面之间的交互行为总结归纳出来并加以延展，从而形成设计规范，籍以帮助我们统一现有的交互设计，并指导后继开展的交互设计工作。
在产品开发过程中，给不同部门的相关人员提供统一的规范指导，使沟通与合作顺利有效进行，以实现产品界面的规范化。
2.适用范围
除游戏外的所有白社会服务应用界面。
3.适用群体
参与产品的设计人员以及运营和测试人员。
第二章原则
原则就是军规、法规，指导我们在交互设计中需要遵守的最基本的设计准则。
效仿"有法可依、有法必依、执法必严、违法必究"的方针，先把这个"法"建立起来，做到有法可依。
当然，交互设计原则也像其他法律一样，同样会遇到在某些情况下某条原则和另外某条原则冲突或度的多少不好把握的问题，这就需要在执行过冲中灵活运用，不能过于教条和死板，要发挥设计师的聪明才智，判定应该如何取舍和坚持。
把握用户的目标为宗旨，任何时候协调良好的界面都无需给规范制度让步，而界面设计的最高境界是没有界面。
4.宗旨
不让用户思考
交互设计的目的就是让用户不知道交互设计的存在，在不知不觉中完成任务。
其根本原则就是在用户和机器交互时，不让用户进行任务核心目标之外的任何无意义思考，一切以"下意识"的方式完成。
基于"不让用户思考"的基本原则，可以发展出下面几个大原则，每个大原则中又有一些小原则进行详细约定。
5.真实世界隐喻原则
不让用户思考，首要做的就是一切尽量以用户已经熟知的方式进行设计，那么用户最熟知的方式，就是来源于真实的世界。
2.1设计重用原则
再真实的模仿在目前的技术水平也很难完全还原，所以多少要在计算机世界种创造出一些真实世界没有的东西。
但这些都已经经历了前人无数次的总结，而且被用户们所习以为常，形成了很好的"模式"。
所以，这里说的真实世界隐喻中最好的原则就是设计重用。
这里有一些关于设计模式的总结文章，值得读一读：
《10UsefulWebApplicationInterfaceTechniques》
《10UsefulTechniquesToImproveYourUserInterfaceDesigns》
《12UsefulTechniquesForGoodUserInterfaceDesign》
《12StandardScreenPatterns》
2.2自然语言原则
老的设计来自于重用，新的设计来自于自然语言。
把自己想象成屏幕后面的电脑，应该如何与用户沟通？
真实世界的相似事情，应该如何进行？
设计时，不妨两个人一个扮演电脑，一个扮演用户，交互一下，会发现很多可行的设计方案。
比如邀请注册引导流程，可以想象成真实世界中某人邀请某人参加一个party，从主人发送邀请函，到被邀请者收到邀请来到会场，主人前来迎接，进行宾客登记，主人介绍其他朋友给他认识，被邀请者自我介绍，主人介绍party各个部分的内容......这样一个流程下来，直到被邀请者可以自主的在party中活动和交流，算是完成了整个邀请、注册、引导流程。
再比如sophie曾经举过的windows和mac对窗口最大化最小化的设计对比，哪种更自然，更像是真实世界可能发生的效果？
关于自然语言原则，臭鱼的一篇文章也提到"自然语言法"，可以读一读。
2.3默认状态原则
6.有效反馈原则
a.键盘可用原则
b.及时反馈原则
c.默认焦点原则
d.防止重复操作原则
e.可反悔原则
f.交互区统一原则
g.位置固定原则
7.简洁明了原则
a.主次分明原则
b.5色3主原则
c.去除干扰原则
d.逻辑清晰原则
e.层次清晰原则
f.相关较近、无关较远原则
g.知道我在哪原则
h.最少点击原则
i.操作流最短原则
8.一致性原则
a.同类一致原则
b.异类不同原则
c.元素最少化原则
第三章产品通用规范
1.页面结构
为确保产品的布局形式统一，根据目前的交互设计总结出产品的框架结构。
在后续添加的服务或栏目，都以此框架为基础，在相应区域进行添加或设置。
总体界面分为5各区域：
导航区、工具区、内容区、声明区、联络区
总体结构图（三-1）
2.内容区
内容区是信息展示和用户完成相应操作的主要窗口，根据不同使用场景。
内容区分为：
首页、主页、应用类页、参与类页。
2.1首页
首页是用户登录后的界面，也是寸土寸金的黄金地段，每个想在首页提供快捷入口的应用或服务都需谨慎，在相应分区下进行添加删除。
首页图（三-2.1）
2.2主页
主页是用户个人的首页或者是他人的首页，此模式适用于各种用户的主界面，以及主页个TAB下的页面。
主页图（三-2.2）
2.3应用类页
2.3.1用户自身的应用类
适用于自己的档案、日志、照片、好友、短消息等页面。
【应用规则】
头部表明这是哪个应用，并有这个应用最重要的操作；
第一级分类使用tabs导航方式；
第二级分类使用sidebar导航的方式，比如inbox；
如果分类层级较多，可以加入面包屑导航，比如照片；
如果需要补充性导航或提示引导等，可以在右侧添加sidebar，比如通知请求的分类；
自身应用页图（三-2.3.1）
2.3.2用户他人的应用类
适用于他人的档案、日志、照片、好友等页面。
【应用规则】
头部表明这是从属于某人的内容，并介绍出是哪个应用；
如果有很强烈的内容分类，比如某人的相同好友、某人的全部好友，可用tabs导航；
如果有较多的层级关系，可用面包屑导航；
用户他人应用页图（三-2.3.2）
2.4参与类页
考虑到参与型应用（游戏娱乐类）的特殊性（反复参与），特给出此类应用的内容布局，目前应用到的应用有投票、真心话、打死也不说。
【应用规则】
放弃了之前头部的小头像和个人主页链接；
加入了面包屑，为了能够找到别人的列表页；
头部导航跟我看自己的一致，方面来回跳转，参与游戏娱乐；
参与类页图（三-2.4）
3.页面Title
每个页面都有自己的名称，产品中页面较多。
在此制定一个统一的命名规则，避免命名的紊乱。
3.1总体规则
采用"XXX（空格）-（空格）搜狐SNS"
3.2BaseApp
♦XXX采用App名字，例如注册、首页、好友、站内信、通知、请求、邀请、隐私设置、账号设置等......大部分就是页面顶上小图标后面带的应用名称；
♦登录页特殊处理，直接采用"欢迎来到搜狐SNS！
"来做title；
♦个人首页特殊处理，XXX采用人名，比如"李池明-搜狐SNS"，看自己的就是自己的名字，看别人就是别人的名字；
♦看别人的应用时，XXX采用别人人名+应用的形式，比如"李伟的好友-搜狐SNS"。
3.3SystemApp
♦XXX统一采用页面顶上小图标后面带的应用名称；
♦考虑到应用都采用ajax加载方式，应用内不再做title区分；
♦看别人的应用时，XXX采用别人人名+应用的形式，比如"李伟的日志-搜狐SNS"。
4.交互行为
界面中具有交互行为的文字或图片，都应该在鼠标指针移过可点击区域时可点击区域的视觉变化，用以说明该对象是可操作的以及何时可以进行操作。
♦对象对鼠标指针移动的响应必须即时有效；
♦响应形式必须明确清晰；（如：
鼠标移过按钮，按钮有被按下的效果）
♦交互反馈表现必须保持高度的一致，同等功能和操作的元素反馈形式必须相同；（如：
鼠标指向链接文字时都做同样的变化）
♦在鼠标指针移开时对象必须即时恢复原来状态。
产品中的交互行为有较多，产品里的交互形式较多，下面罗列目前已有的交互行为并就特殊要求的行为作补充说明，其余不作说明的交互行为遵循界面中交互行为的反馈形式。
4.1输入
4.2点击
4.3切换
4.4划过
鼠标划过区域背景高亮，常用于表状内容体，内容过长较分散，为了使内容标齐，采用鼠标划过，背景高亮。
如：
好友管理列表、站内信列表
4.5关闭
4.6加载
♦内容块加载：
预加载的内容块先空白，在中间先出现大loading图片，加载完后显示全部内容；
♦信息条加载：
预加载的信息条先空白出一行，居左出现小loading图片，加载完后显示该信息条内容
4.7提交
♦提交按钮：
点击，按钮disabled，文字变为"提交/保存/发表中"，提交成功后，恢复原样
♦单输入框+提交按钮：
点击提交后，输入框和按钮disabled，按钮变为"提交中"，提交成功后恢复
4.8拖放
用户可以用鼠标抓取一个对象，并将它从一个指定位置移动到另外一个指定位置的操作，我们定义为“拖放”。
拖放能简单，直观，快速地帮助用户实现布局排序等操作。
如梦幻城游戏界面中建造房屋。
拖放遵循所见即所得的操作原则，使整个交互过程可视化，大大降低了用户由于误操作所带来的不便，同时也增加了用户参与互动的娱乐性。
拖放图示（三-4.8）
【设计意图】
♦让用户简单、直观、快速的达到移动对象的目的；
♦增加用户参与互动的娱乐性；通过单一性设备鼠标直接完成操作任务；
♦遵循所见即所得的操作原则，让用户的操作过程可见，减少出错几率。
【应用规范】
♦单条拖放：
鼠标划过：
拖动区域有响应变化，且鼠标变为十字形；
鼠标点击不松并拖拽：
拖动区域边缘高亮，且区域半透明；
拖动至目标：
周围元素让出空位，用高亮的虚线标出目标位置，提供是否可移动到该处的视觉反馈；
目标位置后松手：
插入目标位置，且其它元素自动排列；
拖动至其它非目标位置：
松手后回复原位置。
♦多条拖放：
鼠标点击：
单击激活选中元素，元素周围高亮，再次单击此元素或其它元素，取消选择，选中其它元素
按住Alt键点击：
单击多个元素，同时高亮，显示多个元素都被选中，再次点击选中元素时，取消选择
拖拽：
跟单条时一致
5.操作反馈
操作反馈规范主要用于用户进行一个操作之后的提示和引导，包括级别定义和各级别交互的定义。
5.1级别定义
分为如下几个级别：
♦成功通知：
主要是由于用户操作并得到成功结果的通知及引导
♦一级提示：
主要是由于用户操作不符合条件所得到的反馈，比如表单填写不充分等
♦二级提示：
主要是由于用户操作符合条件但遇到规则限制造成的，比如重复操作，达到好友上限等
♦错误提示：
主要是由于用户操作遇到了服务器端异常导致的，比如服务器宕机，数据库连接不上等
5.2各级别交互定义
♦成功通知：
直接显示结果
页面上显示成功提示（3秒后消失）
dialog通知
♦一级提示：
即时验证，单项文字提醒
dialog提示，逐项列举未完成条件
♦二级提示：
页面上显示限制提示（不消失）
dialog提示，列举限制条件
♦错误提示：
dialog提示，列举错误信息
之前是机器语言，现优化为用户语言
dialog详细定义：
标题：
出错了
内容：
啊哦......白社会运转出现了点小问题，请稍等片刻再尝试一下~
按钮：
确定
第四章组件交互细则
第一节信息输入
1.表单组合
“表单组合”，是含有预定义的区域用以输入信息的一种表单形式，它通常具有较好的数据组织结构并且易于查看。
用户通过“表单组合”输入并提交信息，从而完成指定功能，例如，用户注册，写站内信，个人设置等。
一个对于用户的操作具有指导性，可以从简洁流畅完成任务的角度提升用户体验的“表单组合”，将更有利于提高“表单组合”的完成率。
表单组合（四-一-1）
【设计意图】
使“输入表单”的设计对于用户更具指导性；
从简洁流畅完成任务的角度提升用户体验。
【组成】
输入表单由标签、输入域、提示信息、反馈信息和表单命令组成，如下图所示。
其中，一个标签及其相应的输入域可称为一个表单项。
♦标签：
相应的输入域的名称；
♦输入域：
允许用户输入、编辑、选择的区域，其表现形式可为文本框、下拉选择框、单选/复选框等（输入域中的控件要合理使用，请参见《windows用户经验》）；
♦提示信息：
出现在用户输入之前，起提示作用的信息。
通过对输入规则，输入目的，输入后果或对某个标签意义进一步解释等信息的表达，对用户的输入进行有针对性的提示，从而帮助用户完成输入。
♦反馈信息：
出现在用户输入完成之后，针对用户的输入，反馈给用户的信息。
在用户完成输入后，通过对用户已输入信息的校验，反馈给用户校验结果（对错），若用户输入出错，则反馈给用户出错原因，修改建议等，从而帮助用户及时、准确的修改错误输入。
♦表单命令：
对整个表单进行操作的一个或一组命令。
常见的有“完成”、“提交”、“重置”、“退出”等。
表单组合命名示例图（四-一-1.1）
【应用规范】
♦标签的命名要简明、易懂，使用社会化语言，而不是机器语言；
♦一个表单项中的标签和输入域在视觉表现上要为一体，不能造成用户阅读表单的障碍；
♦表单项不超过5项时，表单的完成率最高。
如果表单项超过20项，在无特殊要求的情况下，要让用户分步完成，并且提供进度指示。
进度指示要指明用户当前位置，距离完成本表单还有几步，进度指示要使用户在填写表单的过程中始终可见；
♦要合理利用整个表单的空间，输入域的大小要尽可能的显示出用户的所有输入内容；
♦若表单项进行了分组，那么分组标志应清晰标示分组。
例如，使用分组线，分组框；
♦若表单项存在必填项和选填项，那么在视觉上必须加以区分，例如，必填项以星号标识，必填项和选填项分组显示，并标注说明；
♦当判断出用户出错或存在无效输入时，不要清空用户原来的的输入，以便用户参考修改。
【对齐规则】
♦表单项目名居右对齐；
♦表单内容居左对齐；
♦表单中提示性内容另起一行，左对齐，使用浅色字；
♦验证信息紧跟着表单内容显示，默认使用图标+文字；
♦按钮跟表单内容一起左对齐
【提示反馈】
♦必填项为空状态的交互处理：
在必填项为空时，统一不用文字进行提示，采用点击按钮后，输入框红闪的交互效果。
♦文字超出时的交互处理：
对于文字超出的状态，通过限定输入框的最大输入字数，不能继续输入或粘贴
♦对于多表单提交的处理方式：
当多表单提交时，由于表单长度过高，可能会看不到为空的状态。
同时，可能是多项输入框都需要提示，所以采用弹出对话框，分项列出错误信息。
如例：
1.日志标题不能少于2个字
2.日志内容不能为空
♦对于对话层里表单提交的处理方式：
由于对话层内不可弹出新的提示层，所以当出现错误时，直接在错误的输入框下显示错误信息。
♦对于服务器端返回的错误提示：
关闭现有的提示层，出现新的错误提示层。
例：
好友加满时弹出新的提示层。
2.下拉层
下拉层用于在某模块有多条数据，但在界面中只显示一个标题或代表的情况。
这种组件形式的优点是可以保证主界面的简洁性，同时又能承载较多数据量；不足之处是交互不是很便利，数据有一定的隐蔽性。
所以在使用时谨慎权衡其利弊。
目前产品中有两种下拉形式：
下拉菜单和下拉列表。
一个好的下拉层可以让界面非常简洁，还能提供丰富便利的交互行为。
下拉层示例图（四-一-2）
2.1下拉菜单
常用于选择性的项目，即选择一项后即可；
一般为点击后触发，也会有个别情况是鼠标滑过触发；
选择某一项后或者鼠标点击菜单外，菜单消失。
下拉菜单图（四-一-2.1）
2.2下拉列表
常用于浏览型或设置型项目，即打开下拉后需要浏览或设置操作；
点击后触发；
再次点击触发位置或者设置完毕，菜单才消失。
下拉列表图（四-一-2.2）
3.权限设置
常用于选择权限设置的地方，如隐私设置、日志浏览权限、照片专辑浏览权限等。
一般存在于页面上，个别情况存在弹出对话框中，如个人档案中的联系信息设置。
应用规范如图示：
权限设置图（四-一-3）
第二节导航
1.面包屑导航
应用于标注当前操作所在具体位置的设计中，让用户清晰的知道自己的位置，不至于“迷路”，同时提供便捷的通道，方便用户切换到其他相关页面，图形化面包屑还提供一键回到较高层次的服务，帮助那些通过搜索或者深层次链接进入到特殊但是不合适页面的用户。
【设计意图】
♦防止用户在浏览过程中迷失；
♦同时提供多入口，方便用户随时到达目标位置；
♦方便用户定位在页面中的位置；
♦合理的有效的利用空间，整合地址栏和面包屑的功能于一体；
♦面包屑显示用户的当前位置，帮助用户理解所处位置与整个网站的关系。
【组成】
面包屑导航图（四-二-1）
【应用规范】
♦面包屑与地址栏合二为一；
♦路径关系要正确，路径文本要与上下文相一致；
♦在层级之间必须使有一个含义简单明确的分隔符；
♦面包屑的最末级，不再提供分隔符。
2.TAB导航
TAB是利用网页小空间展现大量信息的一种形式，并为用户清晰的指示出当前所处的位置。
一般情况下，当在分类标题数为2-10个，且标题数不经常改变时，可以使TAB。
TAB的使用可以帮助用户在大量信息中导航。
TAB导航图（四-二-2）
【设计意图】
♦在一系列可选标题中为用户清晰的指明当前位置。
♦可帮助用户在大量信息中导航。
【应用规范】
♦页签的表现形式可以多种多样，但分类标题的关联内容应在视觉上连接到当前激活的页签，并保持一致的设计风格，如使用相同的颜色，同一个边框，指示箭头等。
使用相同颜色的表现风格，为典型的页签表现形式；
♦页签标题文字最好保持在5个中文字符以内，或1，2个英文单词，并且页签宽度应能保证完整显示出标题文字;；
♦同一时间只有一个页签处于激活状态;；
♦激活的页签应提供视觉反馈，如：
高亮当前选择，标题文字字体颜色改变等；
♦页签应尽量单行显示，如实在显示不下，可考虑使用下拉菜单或其他解决方案。
3.翻页导航
数字翻页模式应用于列表数据条目较多，文章篇幅较长的设计中，来对数据和篇幅进行更好的展示。
根据页码数的不同情况，数字翻页控件有如下几种形式，在设计过程中酌情选择。
翻页导航图（四-二-3）
【应用规范】
♦页码数已知的情况，使用前三种
♦页码数未知的情况，使用第四种
♦页码数为1时，不显示分
第三节信息展示
1.头像和人名
头像和人名是白社会中用户必不可少的标示，根据不同页面有不同的组合使用情况。
目前制定出了一下组合形式和各种形式下的尺寸规范。
头像和人名的交互反馈形式参见：
三-3交互行为。
1.1头像：
用于个人主页上，最大170*200；
用于Home的头像位置，固定80*80；
用于最常用出现的头像或头像+名字，固定48*48；
用于右侧的好友列表上，固定40*40。
头像（四-三-1.1）
1.2头像+人名+状态：
用于垂直列表；
用于单独呈现某个用户
头像+人名+状态（四-三-1.2）
1.3头像+人名：
用于横向列表或多行；
用于群组呈现用户。
头像+人名（四-三-1.3）
2.信息列表
产品中多数信息的展示都是以列表形式提供给用户，是用户最主要的信息获取源。
根据不同的信息，我们归纳了如下几种信息情况的信息列表，并对相应形式做了图示说明。
信息列表的交互反馈形式参见：
三-3交互行为。
2.1Newsfeed列表
Newsfeed列表（四-三-2.1）
2.2Minifeed列表
Minifeed列表（四-三-2.2）
2.3评论列表
评论列表（四-三-2.3）
2.4留言列表
留言列表（四-三-2.4）
2.6feed规则
♦当前条数内，多人对同一主体内容进行相同操作的feed，合并主语显示；常用于参与型app，比如投票、真心话、说秘密......
格式：
小明，小王，小张参与了真心话+1+1=？
+2小时前
♦当前条数内，某人对同一app下同一主体进行多次操作的feed，只显示最近一条；常用于操作型app，比如评论、标记......；
格式：
小明对日志xxxxxxxxxxx进行了评论2小时前
♦当前条数内，某人对同一app下不同主体进行多次操作的feed，合并后面的主体；常用于修改或添加型app，比如好友、个人档案、应用......；
格式：
小明加了小张，小王，小刘为好友2小时前
♦当前条数内，某人在同一app下产生UGC内容，如果相似，只显示最近的n条；常用于UGC型app，比如日志、照片、分享......；
格式：
小明在专辑XXXXXXXXXX中上传了7张新照片2小时前
3.日期时间
产品中有很多时间提示信息，根据不同的使用场景，归纳出如下几种时间形式。
在后续的设计中，可以根据使用场景从中选取相应形式。
♦正序长版：
2009年1月15日2:
30pm
♦正序短版：
2009-1-158:
30am
♦倒序：
<2秒刚刚
2秒-59秒2-59秒前
1分钟-59分59秒1-59分钟前
1小时-23小时59分59秒1-23小时前
1天-6天23小时59分59秒1-6天前
1周-3周6天23小时59分59秒1-3周前
1月-1月3周6天23小时59分59秒1月前
>2月xxxx年xx月xx日
♦Feed时间显示：
时间线
1）小时线：
在今天范围内，按照每小时划分的线。
0:
001:
002:
003:
004:
005:
00......19:
0020:
0021:
0022:
0023:
00
2）日期线：
分为昨天、本周、上周、本月、上月、很久以前
Feed时间
1）今天：
显示为xx:
xx，例如6:
56am
2）昨天：
显示为xx:
xx，例如0:
30am
3）昨天以前：
显示为xx月xx日xx:
xx，例如12月1日11:
23am
评论时间
评论的时间始终显示xx月xx日xx:
xx，例如12月1日1:
23pm
第四节消息提示
1.通知消息体
1.1通知列表
♦通知消息体尽量简短，不显示用户操作的评论或留言的内容，但可以显示通知的对象。
例如真心话里，不要显示"他的真心告白是：
'我爱好读书'"
♦通知消息体尽量使用主动语式，主语为某人。
例如：
1.某人对你的某件东西做了什么样的事情。
例如：
张小敏对你的日志XXXXX发表了评论张小敏在一张照片中提到了你查看
2.某人和你做了怎样的事情例如：
张小敏也加你为好友 张小敏跟你交换了真心话：
XXX
♦通知尽量引导用户到最终页，进行下一步操作。
在消息体中，如果操作的最终对象是名词，则直接在该对象上加链接。
如果通知中没有最终对象，则在后面添加明确的"查看"或"阅读"等链接。
例如：
1.消息体：
"张小敏对刘小贺的日志XXX发表了评论""XXX"需要加链接，不需要添加其它的引导操作
2. 消息体：
"张小敏给你留言了查看"需要添加"查看"作为引导链接
♦人名和链接的左右都有空格，第一个字是链接时，不需要左空格。
1.2通知合并规则
1.2.1同一个人对同一个内容发生的相同操作，只显示最后一条。
常用于评论的通知
例如：
小A评论了你的日志XXXXXXXX3分钟前
小A评论了你的日志XXXXXXXX5分钟前
小A评论了你的日志
升级会员 