了解d窗的案例战可以保障的工作，可以帮助你做出更合理的已经设想好的决策方案，也有助于你梳理目前战争定额的物质结构，打造战争的终极场景定额。
当B面素材已经构思好了，素材经理和设计师就会为了写一个考试成绩而争论:在已经有限的室内空房间里，我能借什么，放什么？d窗有小有大，在今天二维页面之外的有限房间空内都可以使用，几乎可以保证页面内可以做的一切。此外，只需从html中减去一句话，就可以将打开方式做成最简单的提示d出窗口。没错，d窗确实是物质想象中的“方便”！
关于确切的结果等等。，d出窗口可能是材料想象中被误用最多的一个，它往往是由应用程序控制的。如果用户打开一个连接或按下一个按钮，它充满了层层d出窗口，用户会觉得你的材料太庞大和实用！更有甚者，有些物质会轻率地d出各种“提示”和“警告”，强迫用户与请求面对面或关闭——可想而知，那种“友好的提示”是“用户在中间”，但很多时候，你可以用更平静的方式提醒用户(比如吐司、悬停浮层、敲框中间的橙色墨水笔等。).知道d出窗口有哪些情况，能做什么，可以帮助你在已经构思好的情况下做出更理性的决定。
d窗是一种“页面上方显示的疑似信息的器皿”，在X轴和Y轴的room空之外扩展了页面的层次和深度。这是一个比页面更灵巧的信息怀疑容器。细分的话会有很多情况，但是同一个战役有一个非常明确的名称。移动应用在过去一直很流行。有对话框，警告框，d出层，d出，气泡...现在由于衬托场景的趋势，安卓的toast提示，ios的Actionbar，透明煽动层(HUD)也被使用。另外，案例战还有很多不同的使用方式，与各种浮层战窗口不同。有鉴于此，我在重新讨论传统定义中的“d出窗口”，这种窗口常用于B端物质(PC)。
在功能战的层面上，边肖将d出窗口分为三种类型:可疑信息呈现、重责任和反射。
1。出现疑问信息
1。意见或指示
一般用户可以自动触摸，包括文字和信息。很少会出现“确定”“知道了”等简单的 *** 作按钮。
模型场景:谢谢， *** 纵指示，帮助，功能具体指导，数字指示，查看详细信息，浏览或查看地图…
那种d出窗口一般是用来填写页面内容的，用户可以在点击logo或者墨水笔按钮的全过程后，在页面中打破d出窗口。像 *** 作的介绍，数据图表中数字的表示， *** 作的表示，具体的指导等等。，那种怀疑往往和当前的情况紧密相关，所以在跳转页面、并排标签页或者二级页面中其实是不符合情况的，这无疑会降低页面中的层次，降低用户的认知能力。特别是对于一些按键 *** 作或者特定的指令，使得d出窗口的演示室空可以利用换页或者tab的情况进行扩展。
要求的是，很多素材兴趣标注这些通用字段名并显示也使用多形式d窗，并带有遮罩，要求用户当面打。在当时，这是一个粗心的假设。那种标注说明，细节可以用一般的非多表单浮动层代替，用户可以通过悬停快速阅读训练，快速分离(去掉touch-uparea键或者面击空隙区域)(虽然，如果内容太多，可以考虑自动跳转到新页面，而不是使用浮动层或者d出窗口)。
像那样填充页面，说明悬停浮层的感觉更好。
2。内容扩展
那种类型经常出现在一些数据图表、统计分析页、目录页。由于页面中整体规划的限制，以及需要突起管理中心提供的规则，大家总是将最贴心的统计分析结果字段呈现给用户，没有机会也不可能将统计图的所有实际数据信息呈现在页面中。而这些内容往往足以要求一个新的页面有容忍度(同样会削减页面中的层次)，那么就可以用d窗来呈现点了。
基于内容的d出，主次有本地场景:查看详细信息、浏览照片、数据透视、历史记录…
至于那种d窗，多形态战不是多形态战，但是很不一样。一般来说，内容少的话，不容易占用较大的显示屏，用非多形态的比较合适。如果用户只需要扫一眼内容，各种形式可能会给用户一种“被隔断”的感觉。而且非多形式的间接显示可以表明目的地正中间，联系关联性更强。此外，可以批准用户快速切换和检查其他类似的d出窗口，不存在会危及其他控制模块的 *** 纵或阅读文章。
d起窗侧滑内板展开方式
有一种和force比较常见的“d窗”，在侧滑的情况下会更新，而不是mask层减少的多形态d窗。这样做的好处是，用户已经查看了d出的内容，在当前页面没有疑问，方便用户停止对比和参考查阅。另外，实际上也不容易危及用户对世界其他地区的 *** 控。那种情况一般在报告中表现得比较多。虽然那边的d出窗口其实不是一般的提示框样式，但是也可以用侧滑浮动层。
但是，当这些疑点较大时(比如旋转杠、拖动 *** 纵等。)，这样会有一些替代的主干任务或者展开 *** 作，建议最好使用各种d出窗口。这样可以使用户的注意力更加不集中，并且可以减少可能的误 *** 作(一些非多种形式的d出窗口允许用户在关闭的d出窗口区域内点击d出窗口)。
渐进式演示:
除了d窗战的二级页面，还有一种信息呈现方式——渐进式开发策略，非常值得警示:即现有页面中只呈现结构化信息管理中心的元素，大量关键信息会在用户提出请求后立即呈现。虽然洞察的速度会受到一定的伤害，但是你可以得到一个更新鲜更简单的用户世界。
2。沉重的责任
1。伟大的任务
那种d窗在B端素材中也很常见。当用户阅读完文章的页面，有一些非常常见的场景:“登陆”、“评估”、“申请处理”、“编译”...这些相对繁重的任务和 *** 作，除了题型、墨迹书写、指示和按键 *** 作，还有一些巨大的可编译表格，揉捏、选择和拖动。在移动端，因为显示屏幕的控制限制，设计师更喜欢使用新的页面来容忍这些内容。而在pc上，更常见的是使用多形式的d出窗口来想象启动用户根据当前页面搞清楚用途的重要任务。因为d出的窗口会让用户知道被终止的任务是基于当前情况的，并且可以在“提交”或“消除”后返回首页。
其他的，关于一些重要的任务，虽然有很多疑点，但是大多数情况下，用户其实并没有要求编译所有的字段名，只是调整你的一两个。所以从用户的认知来看，使用d窗会让他们感觉更快更简单，就像在二级页面一样。
大多数情况下，用户只需要编译或调整一两个字段名。
有必要说一下那边的特殊d出窗口——登录/应用注册世界。虽然以d出窗口的形式呈现还是很常见的，但在过去，越来越多的物质会在用户亲自点击“登陆”时自动跳转到新的页面。这样做的好处是可以有一个更大的室内空间空，可以用来删除素材标语战斗场景的图片，从而达到向用户介绍素材管理中心的功能，烘托素材氛围，传播品牌文化的整体目的。
2。简单的任务
如选择器、输入资格证码、初中级别抢、分享、 *** 纵和管理权限确定、用户反映等。在大多数情况下，大量的这些d出窗口只是所有重要任务的一个汇聚控件和标准设置，你可以把它想象成只是一个选择器。
用悬停浮层替换。
有一些衔接 *** 作。实际上，没有必要使用传统的多表单d出窗口，如上面的场景:当用户面对面点击“打印”时，要求用户选择面对面打印的样式(竖排和横排)。一开始大家的设想是，用户面对面点击“getprinted”后，会d出窗口供用户选择面对面的打印样式，需要用户选择确定(或者间接确定默认选项)后，才显得符合逻辑战用户思维的模板；但是对于那些频繁使用打印功能的用户来说，每次d出的窗口“确认”都让人想到“产能过剩”和“愚蠢”:我总是横向打印(或者纵向打印)。为什么每次都要我选？碰巧的是，大家最后都抛弃了d窗，改成了浮动层的思路:当用户悬停在按钮上时，可选择的项目会立刻呈现出来。如果用户没有要求改变可选择的项目，那么间接地点击并打印它们会很好(大多数用户都是这样做的，等等)。).此外，用户可以快速切换到其他选项。通过对用户采取同样的观察的整个过程，我们发现他们比其他人对那种互动更感兴趣。
3。反射
当用户点击按钮，未能完成任务，或者管理系统的形态升级时，都要求给用户一个清晰的反映，这是人机交互技术中非常关键的一个单元。如果输入输出，很容易产生用户的不良情绪，比如怀疑、猜忌、不怀疑等。告诉用户发生了什么？有什么效果？此外，容错机制是评估材料可用性的关键标志之一。我们应该在用户“失败”之前给他们必要的提示和警告。
(1)按键 *** 作确定
确认撤回、确认删除、确认提交...需要在d出的窗口中公布用户正在终止的 *** 作可能发出的“风险”，以降低用户失败的可能性。有些可以使用非多形式浮动层，但最好呈现被 *** 纵过的触摸区域的中间，防止用户给出粗心的提示。
(2)参见 *** 纵效果
看到有效战的危害，有针对性地引导用户下一个可以终止的任务；
如果通常只告诉用户 *** 作并获胜(例如，成功处理申请，删除获胜，提交获胜...)，他们主张用吐司提示让用户“知道”，而不是要求分级用户注意当面攻击。如果 *** 作失败，结果已经被报告。此外，要求用户报告失败的结果以及应该做什么。
比如进口是一个庞大的相对任务，下沉率低控制不了重任。当它已经被 *** 控、被打败，通过询问用户的详细下沉影响力，可以帮助用户快速准确定位果实，找到解决方案。
(3)第十页
断线、数据信息下沉、管理系统分裂等。
(4)退出通知
页面登录请求超时，强制退出并从头登录；户口被压榨，劣迹斑斑。
(5)其他反射式d出窗口
4。摘要
B端web已经假设了d窗的视觉效果样式可以是多种多样的(文字并没有过多的接触到圆圈)，但是从功能上来看，上面三年的案例什么都没有。总的来说，如果可以替换，大家要冷静，少用d窗。但是，了解d窗的各种应用场景，可以让大家更容易考虑设想:d窗可以用吗？只能用d出窗口吗？使用二级页面、浮动层甚至吐司提示会不会更好...从这个另一个角度来看，也有助于理解d窗的各种功能，也有助于梳理目前战争规范的物质结构，打造交互和视觉效果规范的终极思路。
平时也是这样的假设总结。如果还不够，谢谢大家指正！
文章由@Rindy本创发布。我已经同意了，并劝阻拦截。
图片来自Unsplash，据CC0和平谈判。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）