用户 窗口 操作 在弹窗（上）篇，我们讲完了弹窗的定义与应用场景，弹窗（中）篇说完了基本布局，那么这篇内容，我们将讨论两个日常工作中深恶痛绝的常见问题：连续弹弹窗、弹窗叠弹窗，本篇内容中提到的“弹窗”多指 modal dialog 模态对话框——毕竟99%的弹窗体验问题都是模态对话框的问题。用超多案例，从3个方面帮你掌握PC端弹窗设计（上）不知道大家对交互设计中的控件持一个什么样的态度，反正我自己入行的时候其实是挺“怕”这玩意的。阅读文章 > 用超多案例，帮你掌握PC端的弹窗设计（中）上期我们小聊了一下弹窗的定义与使用的常见场景，本期我们来聊点实际的：弹窗的内容布局，本来本期想把常见的两种弹窗问题：弹窗的从属关系（弹窗叠弹窗）、弹窗的流程关系（连续弹窗）都讲一遍，但写完基本布局以后发现字数超了，所以弹窗这个话题从 2 期变成 3 期了。阅读文章 > 信息弹窗的体验问题弹窗留给广大群众的印象很糟糕。即使不是交互设计师，聊起“弹窗”这个东西的时候，脑海中一下子蹦出来的第一印象都是 PC 时代铺天盖地、像电线杆子上小广告一样密密麻麻、层层叠叠的广告弹窗。假如你不小心点开了不该点的网站，或者安装了“急速下载器”的客户端，那开机后迎接你的就是十几个按顺序打开的弹窗、并且往往还附带震耳欲聋的音乐——每个都需要你亲自、纯手工点掉。广告弹窗之所以成为体验问题，也很好理解。即使不是专业设计师的人也能细数一二，比如 19 年这篇法治周末就列举了广告弹窗的三宗罪：推送频率过于频繁关闭按钮过于隐蔽重叠的窗口影响正常网页的浏览https://finance.sina.com.cn/chanjing/cyxw/2019-12-18/doc-iihnzahi8244276.shtml前两个问题本篇不作讨论，主要是第三个问题很值得细究：之所以重叠的广告弹窗很恶心，一定程度上是因为它让低用户价值、低优先级的内容（垃圾广告）遮住了高优先级、高用户价值的内容（用户自己打开的页面），并且除非用户和弹窗进行交互（关闭广告、或者拖动自己想看的窗口），否则根本无法获取自己感兴趣的内容。基于我们在从交互的角度讲讲弹窗（上）中的结论：弹窗是一种对注意力的引导形式，我们可以说，作为一种信息展示弹窗，弹窗堆叠导致用户的注意力被错误地强引导向了低价值的内容，并且关闭成本太高，因此这种设计手段不可取。操作弹窗的体验问题既然连续弹信息弹窗的体验问题部分在于遮挡了高价值的内容；那么连续弹操作弹窗是否存在体验问题呢？毕竟操作弹窗都是用户自己主动打开的，因此对于操作弹窗的内容多少是有预期的，甚至可以说操作弹窗上的内容都是存在用户价值的，用户为了完成某些操作，的确需要看到这些内容。先说结论：在网页端存在多种处理弹窗层级关系的方式，的确应该尽量避免模态操作弹窗的堆叠，但并不是完全不可接受。然后我们来细细的拆解操作弹窗的“连续弹窗”和信息展示弹窗的“连续弹窗”有什么差异。1. 弹窗的层级与任务的从属关系上文使用的例子是多个广告弹窗连续弹出，各个广告弹窗之间实际上没有层级关系——没有哪个广告弹窗是另一个广告弹窗的入口。但操作弹窗却很经常出现这样的情况：想象你打开一张工资编辑表，新增/删除员工可以在页面上进行，但是对每一个员工的工资/补贴做编辑，则需要进入下一级员工工资编辑弹窗进行操作，那么此时“工资编辑表页面”和“员工工资编辑弹窗”就构成了页面上的层级关系（或者父子级关系），而从目标与任务维度上来讲，“编辑员工和工资”是用户想要达到的总任务目标，“编辑某个具体员工的工资”是延伸出来的可选子任务。用户目标与任务之间的关系，映射到页面上，也就形成了页面、弹窗之间的从属关系。这个映射做得是否符合用户的使用习惯，就看设计师的功力了。比如大部分艺术创意类工作的目标都没有那么精确，所以任务也就经常是非线性的：用户总是需要调整一下这个滑杆，不太满意，然后又去调一下那个参数。而不是像填表单、编辑表格那样，打开页面之前心里就想好了：这里要从 0 调成 10，这个按钮给它拧开，这个项目给它删了。因此工具性产品或者创意生产类产品都采用工作台的模式，使用非模态弹窗或者干脆不使用弹窗，从而允许用户多线程、多维度地自由工作。这部分看的迷糊的请看前篇：从交互的角度讲讲弹窗（上）。同理，设计师会把一般来说用户不需要也没办法同时处理的、具有逻辑上从属关系的任务，做成具有父子级关系、或者一定展示顺序的页面（或者弹窗），而不会把这些东西全部一起呈现给用户。交互设计师的其中一项基本工作是将页面的信噪比维持在一定的区间内、提供给用户他们当下需要的信息。假如一件事情没那么急迫，那么就没必要把它招呼到用户面前。2. 从属关系的实现方式与问题即然页面/弹窗之间可以具有从属关系，那么我们如何在页面中体现这种从属关系？它们各自有什么特征与问题？我这里总结了 3 种常规的表现形态，我们一项一项地盘点它们各自的问题。3. 操作弹窗的“弹窗叠弹窗”“弹窗叠弹窗”，或者“父子级弹窗”是一种古老的交互形式，在 PC 应用程序设计场景下，所有的任务都在弹窗的前身——窗口或窗体（window）下完成，因此窗口相互重叠是不可避免的。应用程序端的窗口重叠有两种情况：物理上的重叠与层级上的重叠。用户在 windows 和 mac 或者其他操作系统上可以打开多个窗口，但用户不可能同时和所有的窗口互动，因此窗口拥有的一项特性：当存在多个窗口时，只有最顶层的窗口是正在与用户互动的窗口，称为“活动窗口/当前窗口 active window”。用户的输入焦点、键控都仅对当前活动窗口生效。以MacOS-文件夹为例我们从这种设计中可以发现在窗口物理上有重叠的情况下，系统虽然允许用户快速切换窗口，但事实上限制了每次和用户交互的窗口。同时，在桌面端上也允许存在从属于某个主弹窗的次级弹窗。这种“次级弹窗”更类似于网页端所讲的“模态弹窗”，如果你不关闭它就无法与其父级弹窗交互，所以我把这种弹窗的重叠称之为“层级上的重叠”。以MacOS-网络-WiFi为例虽然“弹窗叠弹窗”这种设计形式历史悠久，但是问题也颇多。其中最明显的两个问题如下：弹窗层级过多，不容易找到可交互的活动窗口多层嵌套弹窗的生效模式比较反直觉，并且经常在网页端被错误应用第一个问题我相信大部分用过 windows 的人多少碰见过。windows 的次级窗口（ owned window ）可以随意拖动，位置并不固定，而且部分 windows 版本中并不展示在底部栏 taskbar 上，所以有时并不容易一眼发现到底应该操作哪里。因此 Mac 改进了它的次级窗口样式，使其紧贴父级窗口的标题栏，这样窗口的从属关系比较明确，一眼容易发现可操作的位置。类似的问题在网页端上也比较容易出现。当弹窗层级过多，而当前最顶层的模态弹窗容器又比较小时，页面噪音就过多了。这个时候用户就要费好大的劲儿从一堆弹窗中找到最顶层那个的可交互弹窗，不说交互体验如何，视觉上就不太简洁，也就丢失了弹窗“引导用户注意力”的基本价值。第二个问题其实发生得很普遍。举个例子，假如你现在在做一款人力资源管理系统，现在有一个“编辑员工角色”的弹窗长成这样：前端一看哎呀太好了，我们刚好之前做了一个“新增角色”弹窗，直接往这个“编辑员工角色”弹窗上一放就解决问题了，甚至还不打断用户的工作流，我看体验非常好：此时假如用户点击“确认新增”，就对输入的字段进行校验，没问题了那么角色就在后端保存上了。此时回到上一级“编辑员工角色”弹窗，用户立刻就能在“角色”下拉框中找到自己刚刚新增的角色，但美中不足的是假如用户在“编辑员工角色”弹窗上点击“取消”，那只是取消了对员工角色的编辑，角色的新增操作已经生效了。好像没什么问题是吧？然后我们举第二个例子：假如我们作为 HR 正在新增一群员工，每个新员工可以有自己的花名和备注，但我们也可以现在不填，等以后再说。新增员工的弹窗长这样：假如花名和备注因为填写频率不太高，所以被放在了二级弹窗上，那么：现在点一下“确定”，前端校验仍然可以做，但员工徐莉莉的花名和员工备注只是在弹窗上暂存，除非用户在“新增员工”弹窗上点一下“确认新增”，否则这批新员工的数据都不会提交后端保存（毕竟员工花名和备注大概率是和员工姓名存在一张表上的选填字段）。上面两个例子讲到这里不难发现，虽然它俩看起来长得一模一样，但是数据的提交方式却存在差异。当出现这种问题时，就非常难以简洁地和用户解释为什么类似的交互形式造成了截然不同的后果。一般来讲，我们做父子级弹窗+延迟生效模式时，（不清楚什么叫延迟生效模式也请看：）采用第 2 个例子数据提交方式，即子级弹窗的数据仅作暂存，当父级弹窗提交时才一起生效；另外假如存在第 1 个例子的情况时，一般以导航的形式打开新的网页窗口引导用户前往“新增角色”模块进行操作，而避免和第 2 个例子造成混淆。但总体而言，应该尽量在网页上避免操作弹窗叠操作弹窗的设计方式，并且完全杜绝 2 级以上操作弹窗的重叠，因为大部分用户很难理解这其中的弯弯绕绕。4. 流程弹窗/多级弹窗流程弹窗的历史和多级弹窗其实都是在同一个弹窗容器上做内容的变化，它俩的差异是：流程弹窗有步骤上的顺序（上一步、下一步），并且一般与延迟生效模式搭配，在最后一步统一提交信息。多级弹窗没有步骤上的顺序，且往往与即时生效模式搭配（尽量避免与延迟生效模式搭配，否则会存在与弹窗叠弹窗一样的问题）不管你用哪一种弹窗类型，注意弹窗只有一个容器，因此右上角的“X”是对流程/多级弹窗起全局作用的关闭按钮。近年来 B 端/工具型产品的形态愈发复杂，多级弹窗也变成了一个比较常规的设计方式，建议大家花点时间搞搞清楚。比如说飞书的「分享」功能，就有这么一个非模态的、介于 context menu 和 dialog 之间的东西，也符合我们「层级高于页面、容器是方形」的弹窗定义。5. 连续弹窗一般不存在多个不同的操作弹窗衔接在一起，但是因为种种原因，连续给用户弹多个反馈/再确认弹窗还是挺常见的。我们在这里就简短地带过一下这种情况。总体而言，我把连续弹反馈弹窗分成两种类型：把用户当大傻子型：意图用多重再确认来阻止用户进行一件事情（一般是卸载软件），我们都知道这体验很差，假如用户体验并不是你的产品主要的考量点，那么当我没说。绝大部分的场景下，合理设置再确认弹窗能够避免 99%的误触，虽然亦有意见表示用户可能日常关闭各种弹窗已经形成了肌肉记忆，只有一次的再确认弹窗可能顺手就被关闭了，并没有起到防错的作用。所以极少数误触造成问题比较严重的场景下，可以用输入文字等方式提高再确认弹窗的操作成本，但绝大多数产品的绝大多数场景只需要 1 个常规的再确认弹窗就够了。产品各干各的型：当一个模块有多个产品经理负责时很容易出现这种情况，每个产品都提出了自己的再确认措施，并且各调各的接口，每个弹窗的触发规则都有点差别。那么这种情况就需要交互去协调同一个产品的不同再确认弹窗弹出逻辑，尽量把这些弹窗的重点信息整合在一个弹窗上，并且优先展示阻断性的问题，建议不那么急迫的事情优先级适当往后调。如何优化B端弹窗的使用体验，这里有7个设计方向！本文会讲一些实用的 B 端弹窗设计方法：如何使用弹窗：根据应用场景、交互需求、内容量、一致性原则如何优化弹窗体验：弹窗按钮、弹窗高度、关闭方式、优化流程…阅读文章 > 欢迎关注作者微信公众号：「白话说交互」本篇来源：优设网原文地址：https://www.uisdc.com/popup-design-3
用户 窗口 侧边 不知道大家对交互设计中的控件持一个什么样的态度，反正我自己入行的时候其实是挺“怕”这玩意的。这些东西好像都来头不小，让我一个不小心就犯很多体验错误。但现在来看这样的心态其实很不必要，因为尽管控件设计有很多约定俗成的规则，但严格来说控件的应用不该讲“对”和“错”，只讲一致性与更好地贴合场景。面对控件时态度放松一点，也能让人更好地去思考未来改进的可能性。另外，由于市面上已经存在很多比较基础的、移动端场景下或者 UI 角度的弹窗文章，所以这一篇我将着重讲一讲 PC 端那种特复杂的大弹窗怎么做，内容比较多，所以会分两期。初识弹窗想象一下你去一家意大利餐馆吃晚饭，正餐刚端上来你正吃的高兴呢，一个服务生空着手走到你旁边戳戳你：“这位客人，外面有个人叫你，你站起来跟我过去一下。”你不得不（很不情愿地）暂停吃饭，站起来跟他走了。同一个吃晚饭的场景，假如这次服务生端着托盘走了过来，你一抬头，他“啪”一下把托盘上的罩子打开，盘子上放着一个小纸条，并且示意你拿起来看看。在交互设计中，假如把全页面的跳转类比成那个叫你“站起来跟我走”的服务生，弹窗就是那个端着托盘的服务生。他用一个新的任务或信息（托盘里的纸条），打断了用户原本的任务（吃饭），但是并没有把用户从桌子上拽起来，完全离开当前场景——也就是饭桌。因此可以这么说：网页与移动端设计中，弹窗本质上是一种对用户注意力的引导形式。它弱于全页面跳转、可能具有打断性，要求用户从原来的场景中抽出一部分精力来应对它。什么是弹窗？既然弹窗是引导注意力的一种形式，那是不是所有引导注意力的控件，都能叫弹窗呢？在 PC 应用程序设计的时代，所有的任务都是在窗体或者窗口 （window）上面完成的。因此实际上不存在所谓“全页面”和“弹窗”的差异，只有“这种窗口”和“那种窗口”的差异。比如在我的这篇文章里出现过的两种“弹窗”，在 windows 7 中同属于 dialog box 类；而除了这种窗口（弹窗），当时还定义了 wizard、property sheet 等多种不同的窗口样式。每种窗口都有一个主要的解决问题与标准样式。PC 设计从应用程序进入网页时代后，用户不再在多个窗口之间跳来跳去，而是在一个网页窗口下完成任务。因此在网页状态下，设计师模仿继承了“窗口”的样式与交互形式，产生了我们熟悉的“弹窗”。随着网页/移动端设计的不断发展，我们也发现，其实不用完全依照应用程序设计窗口的那一套来做弹窗或者做触达，因此网页/移动端产生了很多独有的设计样式。这些样式虽然起源于窗口，但更灵活多变、和传统意义上的“窗口”有一些差异。由于中文表达的含糊和不清晰，现在国内设计界倾向于把这些形形色色的触达/操作形式全部都统称为“弹窗”，但细究起来，我们甚至可以画一张九宫格：你是弹窗原教旨主义者吗？我在这里无意于给“弹窗”这个概念正本清源，但为了下文能够更有指向性，我们这里只把“层级高于页面的”、“容器大概是个方形”的控件纳入接下来“弹窗”的概念范围。并且由于 callout/tooltip 的一些变体和 menu 菜单不太好区分，为了方便，这期就不讲这些比较小的非模态控件了。同时我也认为，大家日常工作中特别是做控件的时候，可以去思考一下控件的具体定义，以防沟通起来鸡同鸭讲。为什么弹窗？还是承接上文那个吃饭场景，那个端着托盘的服务走后，你急急忙忙放下刀叉，把字条从托盘里拿出来：展开一看发现上面写的是——气不气人？你可能当场就想跳起来大骂服务生：这点事情需要这时候来打扰我吗？同样的道理，既然弹窗只是一种形式，那么是否选择这种形式，必然是由其实质内容（也就是场景与任务）决定的。我基于我自己的经验把弹窗的作用分成三种（当然你也可以分得更细，比如 IBM 就把他们的弹窗组件分成 5 种）：触达弹窗：这个弹窗是由系统触发的，而非用户主动触发的，一般用作信息通知，可能附带简单操作信息展示弹窗：用户主动触发，一般用来收纳全页面上放不下的信息详情操作弹窗：用户主动触发或受用户的操作触发，可能用来承载复杂操作（比如表单）在决定要设计一个弹窗时，至少要思考三个关于弹窗内容的问题：是否急迫：假如这是一个触达弹窗，用户是否需要马上处理/查看弹窗上的内容/任务？具体情境：假如这是一个操作或信息展示型弹窗，用户在处理这个内容/任务时，是否需要对照或查看其他内容？这个内容/任务是否反复发生/需要反复处理？生效方式：假如这是一个操作弹窗，用户是否需要对照自己处理的结果，再次对内容进行调整？1. 是否急迫这个问题决定了你需要占用多少用户注意力，是否要选择“弹窗”作为你的触达方式。就像我们上面提到的，触达弹窗不是由用户自己触发的，因此这个弹窗肯定不在用户预期之内，这意味着用户有很大可能性不会去看这个弹窗。对于触达弹窗来说，假如这件事情不那么急迫，不需要用户马上进行处理、或者用户根本处理不了，那么你可以考虑用以下方式弱化、降级触达：降低视觉音量：模态弹窗变成非模态弹窗，或者设置弹窗消失时间主动触达降级为被动展示：将触达弹窗变成用户主动点击查看由于触达本身是个很大的话题，我们这里不做赘述。未来讲触达的时候再细讲。2. 具体情境对于操作或信息展示弹窗来说，这个问题决定我们选择组件的层级、以及是否需要阻断用户和页面其他内容的交互（也就是模态/非模态）。想象这么一个场景：假如你是一个中学老师，你正在给每个小朋友写期末评语。学校提供的写评语系统长这样：你发愁了：班上有 50 个孩子，每个人的期末评语得按照他们的平时表现和期末成绩来写。为了写这个评语，你得打开期末成绩 excel、打开学生档案，再打开百度搜索评语模板，一边复制、一边粘贴：再来一个场景：假如你是一个第一天上岗的客服，用户来找你咨询：“这件衣服有几个码呀？我能穿上吗？”你一愣，“等等哦，我给你去查查”，然后打开了商品链接一通翻找。等你找到了，关闭商品页正准备回复呢，这时候客户也消失了。这就叫完成任务时，需要“对照或查看”其他内容。这种情况下假如设计一个模态弹窗，的确好像起到了“引导注意力、让用户专注当前任务”的效果，但也严重影响了用户完成任务的能力。对此，我们一般有以下几种方式来解决：尝试不用弹窗，而采用侧边栏来承载信息或任务使用各种形式的非模态弹窗，来让用户在完成任务的同时，可以自由行动、甚至允许暂时中断任务比如第二个案例里，我们可以尝试用侧边栏承载商品信息，这样客服就不需要离开当前聊天页面，而可以直接通过侧边栏获取商品规格，直接给到顾客及时的反馈。而在第一个案例中，也许我们可以尝试在学生的单人信息页上打开侧边栏，或者做成停驻窗口（docked window）的形式。这样即使在输入中，用户也可以去查阅完成任务所必要的信息，降低任务的完成难度。这个案例之所以我们不使用侧边栏，而采用了层级高于页面本身的面板来完成，主要还是考虑到写“期末评语”这个情景比较偏向长文本输入、一次性提交后不再支持编辑，所以相对于页面内输入，面板感觉起来比较“郑重”。这个就纯属个人习惯了。3. 生效方式这个问题在操作型弹窗非常多见。设计师用 Mac 的多，不知道平时打开系统偏好设置的时候，有没有注意过不同的菜单，右下角一会有“应用”和“复原”按钮，一会儿又没有。很明显，这两种弹窗的生效方式（或者叫生效模式）是不同的。有提交按钮的弹窗，在你没有真正点击“提交”之前，所有的修改都只是暂存，并没有真正生效。而右边这种没有提交按钮的弹窗，在你与弹窗内容区交互时，就已经即时生效了。windows 给这两种模式起了名字：前者叫延迟提交模式 delate commit model，后者叫即时提交模式 immediate commit model。我们大部分在网页端能见到的常规模态操作弹窗，都应该采用有提交按钮、需要再次确认的延迟提交模式：它的潜台词是，你可以仔细思考一下你键入的内容、选择的选项，随意修改到符合你的想法之后，再提交生效。相比起效率，这种模式更加关注准确性，填错了可能造成一些后果。但假如你的任务本身操作量不大，但是变更很频繁，比起准确性、更关注效率，那么就应该思考是否可以采用非模态弹窗或者侧边栏+即时提交模式，来创造相对高效、轻量的体验。比如 windows edge 的这个侧边栏，虽然也是设置，但采用了非模态面板+即时生效。5000字干货！从5个方面帮你完整掌握弹窗设计方法！前言产品经理：我觉得这里要加个弹窗，你去设计吧。阅读文章 > 欢迎关注作者微信公众号：「白话说交互」本篇来源：优设网原文地址：https://www.uisdc.com/popup-design
拖动 屏幕 窗口 本文为 Material Design 折叠屏设计指南中文版译文第三篇，超多干货建议收藏。往期回顾：Material Design 折叠屏设计指南（1）：概述折叠屏使用柔性屏幕可以折叠或展开，根据你的需要无缝扩展可用的屏幕空间。阅读文章 > 如何设计折叠屏？来看这份设计指南！最近做了HUAWEI Mate Xs手机折叠屏的相关设计，借此机会「趁热打铁」分享一手界面操作体验、适配技巧分享给大家，希望对各位设计师同学有所帮助和参考。阅读文章 > 导航组件在可折叠设备上，将导航组件放在靠近屏幕边缘的地方，因为这样更容易触及。使用导航栏组件作为主导航。使用底部导航栏作为主要导航，会使用户很难触及屏幕中间的位置。当心！底部导航栏最好用于移动设备，而侧边导航栏（Navigation rail）则更适用于可折叠和屏幕较大的设备。App 可以在到达次级页面后隐藏侧边导航栏，只要你能显示返回到主页面的按钮。次级页面在打开时可能会隐藏导航栏，所以显示返回按钮有助于返回主页面。次级导航1. 顶部应用栏（Top app bars）应用栏容器用于显示和对组件分组，帮助用户执行主要操作，或对主体容器中的元素执行操作。应用栏容器可以与导航容器组合使用。当心！使用顶部应用栏会在屏幕上产生带状效果临时组件1. 对话框将对话框放在屏幕两侧，避免将关键交互放在中间。可以这样！将对话框放在屏幕两侧。多窗口交互折叠屏提供更大的显示面积，经过优化，可以同时显示多个 App。这种额外的空间对于多任务处理或依赖信息比较或管理的工作流程特别有用。通过最大限度地减少用户在单个屏幕上的 App 之间的切换，使得生产力、授权和更无缝的用户流成为可能。在 Android 12 中，用户可以在新的概览（overview）中创建和审视多个窗口。请点击以下链接了解更多关于 Android 12 “最近使用的应用屏幕”的内容。（ https://developer.android.com/guide/components/activities/recents ）拖或放（Drag & ｄｒｏｐ）使用 Android 的拖和放框架，你可以让用户以图形化地拖放手势来移动数据。该手势可以在同一 App 中移动到一个视图到另一个视图，或者在启用多窗口模式在一个 App 和另一个 App 之间移动。尽管该框架主要是为数据移动而设计，但你也可以将其用于其他 UI 操作，例如，你可以创建 App，当用户将一个颜色的图标拖到另一个图标上时，将两个颜色混合。1. App 连续性在可折叠设备上运行 App 时，App 可以从一个屏幕自动过渡到另一个屏幕。过渡后，App 应该在相同的状态和位置上继续运行，当前的任务无缝衔接。用户需求创建、排列和调整窗口的方式对所有用户和任何屏幕尺寸来说都应该直截了当。无缝窗口管理的模式包括：运用 Material 动效指南中所描述的平滑过渡（smooth transitions）确保用户可以轻松创建多个窗口，并根据需要在它们之间移动确保心智模式（mental models）和交互模式的简单性，这样用户就不需要考虑哪种模式适合哪种任务。在可折叠设备中，包括那些带物理、有缝铰链的设备，设计和实现窗口交互应该一致用户通常使用多个窗口来并排显示和使用 App。例如，收件箱 和 照片 App 并排。窗口创建和行为Android 为用户提供了多种创建多窗口视图的模式。1. 任务栏（Taskbar）在 Android 12 中，任务栏为钉住和建议的 App 提供了一个启动点，可以很轻松把 App 变成独立的窗口。要创建一个新窗口，用户需要从任务栏中选择并拖动 App，然后移动 App 图标来指示窗口应该显示的位置。任务栏可以作为创建多个窗口的起点。将 App 从任务栏拖到屏幕的一侧会创建一个分窗口视图（split-window view）。上下文菜单用户可以通过 App 上下文菜单的概览（overview）来创建多个窗口。当使用上下文菜单将 App 固定在屏幕边缘后，从概览中点击第二个 App 将触发分屏。3. 调整窗口大小默认情况下，多窗口被创建为 50/50 并排分割窗口。多窗口是一种临时状态。当把手（handle）拖动到屏幕的边缘时，被缩小的窗口将关闭，退出多窗口视图。窗口可以进一步调整为 1:3 或 2:3 的比例。这些比例提供了主窗口和副窗口相互转换，提供了更大的灵活性，并允许根据需要将重点放在其中一个 App 上。屏幕把手可以被拖动和释放以创建所需的窗口比例。把手会自动调整到最近的捕捉点（Snap point）。把手也可以用来关闭其中一个窗口，这将退出多窗口视图。使用分屏把手调整和关闭多个窗口大小竖屏 50/50 分割横屏 50/50 分割App 的大小可以填满三分之一的可用窗口空间。由于屏幕面积减少和对布局的挤压，确保 App 在这个狭窄的宽度上仍然可以提供可用的体验，避免在这个比例下进行复杂的操作。App 的大小可以填满三分之一的可用窗口空间。由于屏幕面积减少和对布局的挤压，确保 App 在这个狭窄的宽度上仍然可以提供可用的体验，避免在这个比例下进行复杂的操作。拖和放（Drag and ｄｒｏｐ）在可折叠设备上的拖和放交互用于组织、编辑和一次为一个或多个元素应用操作，使普通用户目标更简单、更高效。可折叠设备为拖和放操作提供一个优势，因为额外的屏幕或表面区域可以简化操作，并为拖和放的项目提供即时反馈。请记住，对于较大的屏幕，当拖动由触摸板或追踪速度较慢的鼠标控制时，可能很难将一个对象移动较大的距离，因为手指可能在拖动的对象到达目的地之前就移动到了触摸板的边缘。Android 拖和放框架（Android drag and ｄｒｏｐ framework）尽管该框架主要是为数据移动而设计，但你也可以将其用于其他 UI 操作，例如，你可以创建 App，当用户将一个颜色的图标拖到另一个图标上时，将两个颜色混合。1. 粗略和精细的投放投放的粗细程度通常应该随着完成一个动作对交互的预期依赖而提高。对于触摸交互，避免将拖动的项目放在可能被手指或手遮挡的地方。粗略投放可拖动项目的目标可以是粗略的，也可以是精细的，这取决于 App 场景的不同。拖动到一个粗略的位置通常会导致该项出现在一系列条目或内容块的末端。精确投放相比之下，对于精确投放的交互在过程中提供反馈，提示投放将发生的确切位置。例如，在发信息和编写文件时，光标可以用来显示被放下元素将出现的相对精确的位置。光标反馈对被拖动的图形的移动做出反应。这些微妙的指示器显示了对象将在文本中精确位置。视觉指示器显示可拖动个元素的视觉指示器可以非常突出，也可以大部分时候隐藏，这取决于优先级。指示器模式从最明显到最不明显排列如下：对象上可见的持久可供性（affordance，译者备注：人对事物功能的理解），如表示视觉抓握的把手上下文中的明确的提示（call-out），比如标签文案（labels）在被动交互（如悬停）或通过上下文暗示之前，线索在视觉上是隐藏的完全隐藏直到拖动动作被启动根据用例和流程，有时可能需要提高指示器的级别，而在其他时候，它可能不是流程中的主要交互，作为支持和补充性的指示器更合适。放置区域（ｄｒｏｐ zones）放置区域是一致的视觉模式，它阐明了预期和交互类型。放置区域模式的例子包括：持续性区域： 在任何拖动操作开始之前，静止时显示的占用空间。用于告知拖放操作是可用的，并且可以作为功能拖放。例如页面上用于上传文件时的加载区域。热点（Hotspots）： 当拖动开始时出现的指示器，以帮助告知可发生拖放交互的位置。当有个多个拖放区域可用时，或者当它有助于指出屏幕的哪一部分将被拖放影响时，这种方法可能很有用。预定义区域： 当拖动启动时显示边界。告知作为容器的预定义空间，拖放将填充该空间。例如，在主屏幕上重新对 App 排序，或者显示重新排序的列表条目将被放置在哪里。窗口： 告知拖动的条目将在何处替换屏幕的一部分，例如用于创建多窗口。默认情况下，这种模式是共平面的（coplanar，译者备注：几何术语，指几何形状在三维空间内占用同一平面的关系），导致周围屏幕元素被推动。1. 在 App 之间拖动当一个条目从一个 App 移动到另一个 App 时，交互会受到拖动项目的 MIME 类型（Mutipurpose Internet Mail Extensions Type，译者备注：网络中的媒体类型，比如图片、视频、文本等）和放置区域的影响。大多数被拖动的元素都属于图像或文本类型。拖动单一条目2. 无障碍无障碍拖和放交互的主要考虑因素包括：依靠键盘导航的用户可能看不到光标的变化状态来表示某个条目是可以拖动的。可以增加视觉可供性（例如抓握、图标或更高的视觉层级）来向用户传达这一信息。为启动拖动提供一致的模式，或者引入后备方案，以帮助用户在多个产品和平台上迁移。Aria 和 Role 属性（译者备注：帮助视力障碍用户的功能，例如放大镜、语音朗读和高对比度等）、一致的键盘控制和读屏器支持应该在整个交互过程中表明可拖动性和状态。打开、关闭和旋转设备1. 折叠状态到横屏展开动效被用来突出由更大的展开的画布所显示的新内容。导航栏和详情页的动画用来引起人们的注意。可折叠设备上的邮件 App 从折叠姿态到展开的横屏姿态。避免在折叠或展开后停留在之前姿态的布局上。相反，随着设备的折叠和展开，进行不同姿态的无缝过渡。千万别这样！避免启动布局变换时出现延迟。姿态的连续性也可以在 banner 的动效中得到加强，banner 宽度延展以利用更大的屏幕宽度。搜索栏也可以有类似的表现。当进入立放模式时，像视频这样的主角元素可以扩展到屏幕的上半部分。像媒体控件这样的辅助元素填补屏幕的下半部分。2. 组件变换边框进入和退出这种变换用于靠近屏幕边缘的组件，这些组件根据布局自适应时退出或进入。底部导航侧边导航应用栏面板（Sheet）媒体控制随着屏幕的展开，底部导航变换成侧边导航新增一个面板这种变换是用来吸引人们对一个新面板的注意，这个面板由一个更大的画布（canvas）展示出来。随着屏幕尺寸的增加，一个辅助面板从侧面进入视图。同级变换：导航顶级导航条目之间的对等变换使用共享的 Y 轴。详情页面根据所选列表条目的对应顺序向上或向下滑动。Y 轴上的元素同步变换，以加强内容状态的微妙变化。父子导航：列表嵌套列表的父子变换使用共享的 X 轴转换。列表条目转换成详情视图父子导航：卡片卡片使用容器变换进行父子变换。卡片容器可以从一个小元素扩展到沉浸式视图对话框出现使用动效将注意力吸引到对话框中显示的新内容。文本和按钮的垂直动效为对话框扩展增加了细节。可以这样！可以用分阶段垂直动效来显示对话框不要从中心均匀地展开对话框。对话框展开时，内容不应淡入、重叠或相反的方向运动。千万别这样！避免引入拒用统一缩放的对话框。欢迎关注作者的微信公众号：「龙爪槐守望者」本篇来源：优设网原文地址：https://www.uisdc.com/material-design-component
落霞与孤鹜
飞翔的企鹅
