覆盖层设计(下)-上下文菜单 | 交互基础02
蒋蕊遥 Jerria 网易UEDC 2017-03-22
上篇讨论了“对话框”和“浮层”两种覆盖层中最为常见的样式：对话框主要分为提示型和输入型两大类；浮层主要分为Toast和Snackbar两类。在下篇中，想要讨论一些不那么常用的覆盖层交互形式：
弹出式半屏页面
弹出式气泡
1、弹出式半屏页面弹出式半屏页面其实并不是一种官方既有的交互形式，而是本文对iOS和Android平台中相似交互形式的统称。顾名思义，它通过弹出的半屏覆盖层来反馈用户操作，弹出式半屏页面优势在于它既能承载较多内容，又能保持上下文关系。1.1、ActionSheets
ActionSheets是iOS平台上的交互形式，在使用场景上与提示型对话框相似（提示型对话框的相关介绍见覆盖层设计上篇），它可以用于二次确认或呈现与当前操作相关的多个选择等。触发时，ActionSheets从下往上弹出；操作完成后从上往下收起。需要注意的是虽然点击空白处也能够退出ActionSheets，但iOS规范仍然建议始终为ActionSheet提供取消按钮。优点：相比对话框而言，Action Sheets对用户打扰程度较小。一般的对话框要求用户必须做出选择，当用户点击了某功能按键或取消后对话框才消失；而ActionSheets 允许用户点击空白处取消操作。建议尽量减少对话框的使用，如二次确认和选择菜单等场景，ActionSheets是很好的代替品。1.1.1、二次确认提示
【使用场景】通常用于在执行毁灭性操作前，让用户进行二次确认；【内容】一般由操作会造成的结果描述，继续执行操作的按钮和取消按钮构成。点击空白区域和取消都等同于取消操作。【设计Tips】一般用红色等警惕颜色来体现毁灭性操作的确认按钮；当按钮本身的描述清晰明确时，可以不需要额外相关描述。1.1.2、选项列表
【使用场景】通常用于展示上下文相关的2个或多个选项，每个选项可以帮助用户执行对应的任务；【内容】在界面中可以通过“一个功能键”或“更多按钮”承载多个相关且使用频率不高的选项。点击对应功能键后通过ActionSheets弹出全部选项，一般ActionSheets由选项列表+取消按钮构成。点击空白区域和取消都等同于取消操作。【设计Tips】
选项数量不宜过多，AnctionSheets中不能出现滚动操作；
iOS规范建议菜单项居中显示且不带图标；
1.1.3、选项网格
【使用场景】主要有以下4种场景，网格比列表更适合：1、更多选项相互之间的相关性不大；2、选项分别属于多种类别；3、选项数量过多，一般多于5个时；4、需要强调选项的图标，如分享时强调第三方平台logo等。【内容】在网格式的ActionSheets中，每个选项以icon+标题的形式展示；当选项较多时，以相关性分行展示，最多不超过2行为宜，当选项有2行时，每行可以单独横向滑动。【设计Tips】
每项的标题最好简介明了、不宜过长，当标题较长时可以通过缩小字体的形式展示，若仍然过长则截断标题。
1.1.4、小结针对3种不同的ActionSheets类型，主要有以下差异：
使用场景 差异
二次确认提示 可能有标题辅助说明，破坏性任务的描述需用醒目颜色标注
多任务列表 任务以列表形式展示，一般不加icon，任务数量在5个以下为宜
多任务网格 任务以网格形式展示，需展示icon+标题名称，一般在任务数量、类型较多或需要凸显icon时使用
1.2、BottomSheets
BottomSheets是Android Material Design规范中建议的一种交互形式。严格来讲BottomSheets分为两类，一类是模态Bottomsheets，其滑出时在页面内容上方；一类是内嵌式，其与页面内容在同一层级，滑出时会将页面内容往上推移；由于本文主要讨论覆盖层设计，所以此处也只考虑模态BottomSheets的应用场景。1.2.1、常规的BottomSheets
【使用场景】BottomSheets的使用场景与iOS中选项列表和选项网格的使用场景相同。BottomSheets也既可以通过列表和网格两种形式展示。
【设计Tips】在设计BottomSheets时最需要注意的是与iOS端ActionSheets的区别：
Android 端的BottomSheets中不需要展示“取消”选项，因为Android软键盘中的返回按钮等效于取消；
ActionSheets中不能出现滚动操作，但BottomSheets中可以，由于没有“取消选项”，BottomSheets底部是与屏幕联通的，所以在实际应用中BottomSheets也有更大的发挥空间。
1.2.2、更多BottomSheets
【使用场景】当页面中操作涉及到更多上下文信息时，则适合通过这种类似BottomSheets的形式进行展示。适用于展开筛选项、更深层级分类等场景。这类交互形式并不算是严格的BottomSheets，而是借用了BottomSheets理念的一种自定义样式。它既能保证用户在使用过程中的上下文连贯性，又能展示大量信息。【设计Tips】
与常规的BottomSheets类似，点击空白处时等效于取消操作，菜单需要收起；
BottomSheets高度不宜过高，顶部不应超过标题栏；
2、弹出式气泡
弹出式气泡在iOS规范中称为“Popover”，它在使用方式上与ActionSheets/BottomSheets类似，弹出时处于页面层级的最上方，点击气泡外任意地方收起。其实iOS规范中并不建议在手机端使用Popover，这种交互形式更适合在iPad等大屏应用中使用，它相当于分割了页面中部分视图用于完成一个临时任务，完成后关闭气泡并在当页进行刷新。但由于国内大量主流App都使用了Popover，似乎又为这种交互形式赋予了新的生命。现在常用Popover的形式来呈现页面中折叠的一些额外信息，或在首页位置呈现一些常用操作的快速入口。如下图所示。【设计Tips】
Popover弹出时是模态的，需要将用户的注意力聚焦到气泡上，并向用户传达“请先选择气泡中的内容再进行其它操作”的意思，所以最好在气泡下方增加蒙层。
气泡不易过长且不能滚动，当内容实在很多时应当考虑采用BottomSheets或全屏弹层的形式。
3、上下文菜单篇小结本篇主要讨论了“弹出式半屏页面”和“弹出式气泡”两类覆盖层样式，它们最大的应用场景即是“展示更多上下文相关信息”。既然气泡和ActionSheets / BottomSheets都能承载展示页面中更多信息的功能，那么什么时候用哪个更合适呢？
交互样式 使用场景
ActionSheets iOS系统使用，操作本身的对象是整个页面内容时，如分享、删除等
BottomSheets 主要Android系统使用，当选项内容较多、有多个层级的信息需要选择时iOS系统的应用也会采用自定义的BottomSheets
气泡 当操作本身只是页面中的局部功能或快速入口时则Popover的形式更适合
但总的来说这点并没有定论，主要以尊重应用的统一性和设计风格为准。

交互设计文档怎么写？ | 设计基础05
摘要交互设计师的工作虽不只是画交互稿子，但是好的交互稿不仅能够完美阐释产品内容和设计师的设计思路，还能够在项目各方协调工作中起到重要作用。保证完整的呈现产品需求和设计思路的交互稿，能够让各方工作人员有一致的工作目标，而有良好体验的交互稿，还能够便于各方理解，提高后期开发对设计的还原度，提高各方工作效率。对于一个设计团队来说，统一的文档规范和设计规范，不仅能够减少合作方的学习成本，提升设计师和设计部门影响力。即使产品不同需求不同设计师不同也能够带给前后端、底层和QA们一致的文档体验。或许每一个设计团队都有自己内部的交互文档规范，而且不同类型或量级的产品部门可能交互设计文档的体量和组织方式都是不同的，我们设计部是一个刚满一周岁的宝宝，部门里的设计师也都是设计行业的freshman，但是我们也在这一年中不断地积累和学习，提升设计文档体验，构建了组内的设计文档规范，以下共享，互相交流学习。✨一、结构篇-交互文档目录无论对于大型产品还是中小型产品，文档目录均需要有清晰的页面结构，无论以何种形式展现，整体交互项目应尽量包含明确的修改记录、交互规范、全局性设计说明、业务设计等。1. 便于查找信息的修改记录
明确的迭代上线日期：前后端、QA们能够对产品迭代内有有一直的认识，清楚哪些是自己某一个迭代要按成的事情；
业务需求及对应设计师：便于协作方进行工作分工，并能够随时找到交互设计师；
修改内容以及前端开发人员：明确写明什么页面修改了什么内容，或者一个需求增加哪些页面，便于协作方了解设计细节内容。写明前端开发人员，则有助于帮助自己和QA们找到对应功能点的前端开发人员是谁（我在一个迭代中可能对接好多个前端人员，具体哪些需求点是谁实现的是记不住的，太笨了～）。
2. 全局页面说明和全局交互全局页面说明主要包括Z轴内容层级，X轴和Y轴适配方案、整体跳转逻辑等，这些均需要在产品研发前期周知前端、视觉等协作同事的。准确传达自己的整体产品设计思路，便于他们进行框架搭建或者视觉定义。另外还可以指导后期复杂需求的交互设计。全局交互则是为了组件化设计，不仅保证产品设计的一致性，也能够提高视觉和开发工作效率。3. 全局性方案全局性方案不仅包含404／403方案、全局请求异常、空状态、页面／信息流加载方案等，还包含一些业务全局性方案，比如平台性的欠费停服流程（所有产品模块均需要）。✨二、布局篇-交互文档布局1. 单页面文档设计我们组做的基本都是 Web 端的设计，由于每一个页面的内容比较丰富且交互逻辑复杂，所以逐渐形成了每一个文档页面只做一个页面的设计的规则，保证设计文档中的页面与真实产品中的页面一一对应，便于交互文档按照产品业务组织和减少协作方查找内容时间。单页面设计其实与一个页面只讲一件事情的设计方法相通，在表述本页面内的设计内容时要说明清楚每一个与其他页面关联的用户接触点从哪里来到哪里去，保证开发、QA们阅读交互说明的时候能够理解当前页面内容与其他内容的关系。2. 统一页面内容布局作为交互文档，它的目标用户比较明显的主要是与我们协作的前后端开发、QA们、视觉小伙伴，其实我们可以很简单的就了解到他们几乎90%都在使用公司配置的显示器，公司配置的显示器基本尺寸微1920*1080，所以便可以根据显示器的尺寸定义Web页面大小、交互说明显示区域等，这样便可以尽量保证在首屏内显示相关内容。另外，根据向开发了解，他们较为习惯Y轴方向浏览信息（其实感觉大部分人都喜欢Y轴方向浏览信息），因此文档页面和交互说明布局以纵向为主，在他们单方向浏览时，保证所有交互点都能看到。
页面头主要包括页面名称、设计师信息和时间信息；
主页面可在Y轴方向延伸，X轴方向尽量不做延伸，但是不排除有特殊的业务需求需要在X轴方向做延伸（比如运营平台中有强需要在表格中横向显示十几项信息内容）；
交互说明主要包括交互点编号和交互逻辑。
✨三、色彩和字体篇1. 尽量使用灰阶色不少交互设计师做交互稿的时候是非常认真的，会尽量做高保真的设计，有蓝色或绿色按钮、橙色的警告图标等，有时候还会直接用视觉设计定义的视觉色彩规范去做交互稿，呈现出完美的交互稿，说实话真的是很漂亮的交互稿，几乎不需要视觉设计师做什么修改。这样完美的交互稿却在无形中对视觉设计师、开发、QA们造成了困扰。就这个问题，我跟对接的视觉师有过深入的沟通，对于视觉设计师来说，在交互稿中出现的那些彩色其实会对他们做视觉设计造成一定的干扰，表示不同明度的灰色调其实是他们能够理解到交互设计师所要表达的意思的。另外，交互稿中彩色内容还会成为视觉焦点，跟开发和QA们有沟通过，他们表示这会无形中会干扰他们对交互逻辑和细节的关注。就这个问题，我们总结了一些灰阶色使用的大致范围，基本来说明度低于#333灰色是尽量不用的，大面积背景是尽量不使用明度地狱#999的灰色等一些原则，也能尽量让交互看起来干净整洁和有一定的美观度。2. 统一字号和字体对于字体，其实没有特别的要求，只要统一字体即可。我们组内统一使用微软雅黑，选择这个字体纯属因为它是无衬线字体，看着简单，而且微软雅黑是各浏览器适配系统字体时的常用默认字体。对于字号，倒是有些要求的，比如正常页面文稿中不得使用小于12px的字号，通用字号为14px，强调可用加大字号和加粗解决。字体中有一个正常页面文稿唯一可以使用的彩色，即警告色#ff6666（彩色也尽量使用饱和度较低的彩色）。✨四、内容篇前面说了很多见面展示的东西，内容上的话主要是交互页面和交互说明了，这是个比较复杂的事情，要针对不同类型的业务需求做出不同的页面设计，我就简单说一下需要注意的几个细节点吧。1. 不同类型的需求应有不同的方法呈现设计我们都知道，产品需求大致可以分为两大类：任务型和信息型需求，针对不同类型的需求要能够通过一些基本的设计方法去呈现我们的设计。比如对于任务型需求，我们可以提供必要的流程图去帮助开发和QA们更好的理解用户在完成任务的过程中可能会走到哪里，有助于他们进行研发设计和测试设计。那么对于信息型需求，则提供信息结构图和业务架构图，让他们在宏观上能够更好的理解需求。2. 交互说明应便于阅读和查找交互说明中尽量字体稍微大一些，，交互说明的字体大小我们使用的16px，比一般字体会大2px，这一方面可以区分交互说明文案内容和页面内容，另一方面也便于开发和QA们阅读。面上内容与交互说明的组织方式可以有很多中，比如画上连接线、编号标记等。我们组目前做的业务需求还是都比较复杂的，考虑到不想让页面变成编织网一样的东西，便采取了实用编号标记的方式去组织交互说明，如果交互说明中出现不同内容的点需要再次写交互说明的时候，编号采用N-N的形式，交互点钟每一条交互内容以中划线开头，交互内容中如果再有分级，便可使用无序编号等等，依次类推下去。如果交互说明中出现与其他页面的关联，着重标出来，这样便于开发和QA们在阅读的时候能够很快定位跳转或回跳页面，明确本页面与产品其他部分的关系。3. 交互说明应具有逻辑性逻辑性或许是每一个设计师的必备属性，我们使用MECE也好，使用逻辑树分析法也好，都是让我们能够遍历或穷举我们想要写的交互点的各种情况的。这里我主要想说的是要真正的具有逻辑性，我接触的一些设计师，虽然也能对一些用户接触点做处详尽而无遗漏的说明和解释，却经常会出现说此言彼的情况，使得交互说明冗杂而不易阅读。而真正的具有逻辑性，是能够清楚自己在每一个用户接触点上想要说明的场景和处理方式，尽量减少各个用户接触点的交叉说明，保证交互说明思路清晰而内容详尽。为此我也总结了一套简单的方法，即PTC4，此处先简单的说明下，以后会专门介绍一下这个方法。4. 交互流程应具有封装性封装性的概念其实来源于研发中代码封装的概念，说的是如果一个方法被封装好了，当使用到这个方法时，只需要传入不同的参数便可以得到想要的结果。这里我引用到流程的封装上，一个全局性的需求流程可能是不一样的，定义好变量参数，便可以在不同的模块调用这块逻辑。这是比较符合开发们设计代码的主要思路的，所以和研发们解释起来是非常顺畅的，而且能够减少重复设计。