提交需求
赛事与广告咨询合作,请填写需求表单,我们会在第一时间与您联系!
本文将探索用户界面中模态的共同标准,讨论屏幕只有两种基本类型的原因,并分析APP和网站在将信息架构和用户流程转换为直观的用户界面的过程中是如何失败的。
许多设计师(主要是年轻设计师)根据自己的直觉来设计数字产品。尽管这在许多情况下可能有效,但有一些经过验证的通用标准可以帮助您有逻辑地构建有理有据的UI解决方案,而不是依赖于您的直觉。
只存在两种类型的屏幕
- 模态屏幕
- 非模态屏幕
就是这样,让我解释一下。 几乎每个可以想象到的视窗都属于这两个类别中的一个。 为了理解模态屏幕与非模态屏幕的区别,我们首先要定义模态屏幕。
什么是“模态屏幕”?
模态屏幕示例
模态屏幕可以有不同的形状和大小:
全屏模态视图(1)
弹窗(2)
漂浮选单(3)
灯箱(4)
警告/通知
...
多步对话框
模态屏幕和非模态屏幕都是子视图,这意味着它们从属于应用程序的主窗口。 但有一个重要的区别:
“[模态窗口]创建一个禁用主窗口的模式,但使用模态窗口作为上层的子窗口使主窗口保持可见。 用户必须先与模态窗口进行交互才能返回父应用程序“—— Wikipedia
大多数模态屏幕可以很容易被识别,特别是在桌面应用程序中,因为它们在视觉上覆盖了主窗口:对于从主窗口背景淡出的弹出窗口、弹出菜单和弹出对话框、灯箱、警告等都是这样。
但是,移动设备上的屏幕空间有限,这就是移动设备上许多模态屏幕占据整个屏幕的原因。 它们不再保持底层主窗口可见,因此更难将它们与非模态屏幕区分开来:
iOS示例:移动设备上的模态屏幕通常会完全隐藏应用程序的主窗口
主要区别在于您与每个屏幕进行交互的方式。 虽然非模态屏幕允许用户简单地返回到父屏幕,但模态屏幕要求用户在返回主窗口之前完成操作(在我们的示例中为“保存”)或取消当前操作。
非模态屏幕最明显的视觉特征是导航的可见性(在我们的示例中为标签栏)。即使非模态屏幕恰好位于子页面上,它也允许用户在主导航层级中来回跳转。 另一方面,模态屏幕要求用户在能够再次使用主导航之前关闭窗口(在我们的示例中为“保存”或“取消”)。 这种区别是大多数应用程序失败的原因之一,也是我撰写文章“Tab Bars是新汉堡菜单”的原因之一:https://uxplanet.org/tab-bars-are-the-new-hamburger-menus-9138891e98f4
为什么要使用模态?
模态屏幕解决了一个简单的问题:用户很容易分心,因此有时候必须使他们全神贯注。 模态屏幕正是这样:它要求人们在继续下一步之前专注于单个任务。
“模态通过阻止人们在完成任务或退出消息或视图之前做其他事情来创造焦点”—— Apple
何时使用模态?
现在我们知道模态屏幕的样子,它与非模态屏幕的区别以及它的使用目的,我们不得不问自己“我们应该在什么样的情况下使用它?”
我答应了你们聊聊小猫,所以是这样:让我们想象一下,我们正在创造一个巧妙而创新的硅谷应用程序:“purrrfect” —— 一个小猫数据库,允许用户上传,查看和评论可爱的猫咪GIF。 优秀的概念。
来源:https://giphy.com/gifs/tDgXAst2PhIYw
我们应用程序的一个简化用户流程可能如下所示:用户打开应用程序,他输入几个可用选项卡之一(我们的小猫数据库),点击其中一只小猫(输入详细的单一小猫视图),然后点击评论部分(进入评论部分)。
purrrfect用户流程
此外,用户可以在每个阶段执行补充动作。 例如,他可以在小猫数据库页面中将另一只小猫添加到数据库中。 或者他可以在小猫详情页面中编辑数据。 很好。
现在,哪些屏幕是模态的,哪些不是? 分类绝不简单——这是我个人的经验法则:
使用模态屏幕进行自包含过程,将非模态屏幕用于其他所有过程。
“自包含过程”是指每个行动都有明确的起点和终点。 在此操作的有限时间范围内,它将用户从一般用户流中移出,让他专注于该操作,然后将他带回到他开始的位置。
谷歌这样描述:使用模态屏幕(对话框)为那些
“需要特定用户操作、决策或确认的关键信息”—— Google
对于我们的purrrfect应用程序,这意味着主要用户流(用于浏览应用程序)不是模态的。 但是,特殊的限时动作,如添加小猫,编辑小猫和撰写评论都是模态的。
在用户返回主流程之前,可以取消或成功完成所有模态操作。 因此,模态屏幕使用取消和保存按钮(或其他类似操作)而不是后退按钮。 如果在非模态屏幕中您的后退按钮同时触发了保存操作,您可能需要考虑切换到使用取消和保存按钮的模态屏幕。反之亦然:如果两个不同的操作(例如取消和保存)在模态屏幕中没有意义(因为它们会触发相同的操作),您可能希望切换到非模态视图。 在这种情况下,主导航(例如标签栏)也应该在屏幕上保持可见。
让我们回到我们改变游戏规则的应用程序:purrrfect的界面可能如下所示:
可能的purrrfect用户界面
在现实情况下,模态和非模态屏幕之间的区别通常不太明显。 例如,图像的全屏视图在大多数应用程序中都是模态的,尽管它不是进程或对话框。 在其他特殊情况下,为了聚焦注意力,模态屏幕也可能有意义。 如果我们的小猫详情页面(图片中间)是没有其他操作(如编辑或评论)的终点视图,我们可能就会使用模态(全屏视图)。 但由于它允许用户更深入地浏览信息结构并执行各种其他操作(显示注释,编辑......),因此它不再具有明确的终点,因此它是主流程的一部分。 所以我们使用非模态视图。
设计师有责任评估一个动作是独立的还是应用程序的一般浏览流程的一部分,并决定使用模态是否有意义。 如有疑问,请记住Apple的话:
尽量减少使用模态。 通常,人们更喜欢以非线性方式与应用互动。只有当需要紧急获取某人注意,必须完成或放弃任务才能继续使用该应用程序或需要保存重要数据时,才去考虑创建模态。 —— 苹果
免责声明:当然,不需要严格区分模态和非模态视图界面也可以完美地工作。然而,模态的概念深深植根于Apple,Google,Microsoft等企业的界面生态系统中,并且用户已经形成了相应的期望。
如果Apple没有不时的违反自己的规则,就不成为Apple了:例如,新的App Store在“Today”标签页中以模态屏幕的方式打开推荐的内容(卡片),但仍然允许用户在打开的模态页最底端导航到进一步的推荐页面去(没有明确的终点)。这样,用户可以在模态屏幕内进行更深入的导航而无需固定的终点。在此过程中,他们无法再切换标签栏,也无法在子页面中关闭模态视图。从上述推荐页面以外的其他入口打开相同的页面会以非模态屏幕显示(例如直接搜索后打开)。这时保留了标签栏和后退操作按钮(再次单击当前标签栏图标会转到其主屏幕)。
不一致的Apple UI
左边的不一致可以通过以下方式来解决
A:在非模态子屏幕中打开推荐内容,并带有后退按钮和标签栏
B:一旦用户点击模态屏幕内的链接,关闭模态屏幕,接着在app父级页面上出现一个非模态的子屏幕。
模态应该如何使用?
到目前为止,我们应该对何时使用模态有一个大致的了解。 剩下的唯一问题是“我们如何设计它?”。 以下是模态屏幕的快速检查清单:
始终在顶部导航栏中显示关闭按钮(或“取消”/“丢弃”/“最小化”/ ...)。 当用户迷路时,他可以轻松关闭叠加层回到应用程序的顶层。
iOS和Android上的取消按钮通常位于导航栏的左上角。 Android更喜欢“关闭”/“X”图标,而iOS则喜欢使用“取消”文本。不过图标按钮也很常见,并且在iOS上广为人知。
默认情况下,iOS和Android上的保存按钮都位于导航栏的右上角。 但是,这种放置在较大的设备上是难以触及的。 因此,屏幕底部的固定悬浮位或页面最末的内嵌展示位置是我个人推荐替代右上角展示的位置。
多步模态
一旦模态对话框由多个步骤或子屏幕组成,事情就会变得更加困难。 默认情况下,“继续”按钮显示在右上角。 第二步屏幕不会打开新的模态屏幕,而是保留在当前模态屏幕内,并显示为覆盖现有模态的非模态子屏幕。
当在屏幕底部放置主要操作(“保存”,“应用”或“继续”)时(如前所述),模态第二步的右上区域释放了可选取消按钮的空间。 虽然它从左侧跳到右侧,但这种放置仍然比不能在子屏幕上关闭模态屏幕更好。
动画
到目前为止,iOS和Android模态视图的使用上非常相似。但是,涉及到动画的时候情况就会发生变化。
iOS:动画在iOS中高度标准化。
非模态屏幕从右侧进入框架。标签栏在屏幕底部保持不变。顶部的导航栏也保持不变,但其内容在过渡中淡出。此动画还为用于返回的边缘滑动手势提供了基础(从左到右滑屏返回),该手势可以为不方便触及的后退按钮提供方便。
另一方面,模态屏幕从框架底部滑入并覆盖整个界面(出现新的顶部导航栏)。他们不使用边缘滑动手势,如果没有什么可以保存,自定义下拉关闭手势可能会有所帮助。
Android:Android上的动画更加多样化。在Material Design指南中Google建议使用“有意义的过渡”。 “子元素在触摸时抬起并在适当位置扩展”,而顶部导航栏则淡化其内容。但是,Android不区分模态动画和非模态动画。
结论
许多设计师根据他们的直觉设计产品。有时候,直觉比常识更重要。但重要的是我们需要了解通用标准,以便在有意义时适应或忽略它。
在我看来,模态的概念是当今应用程序中最被忽视的UX原则之一。跨平台应用程序和Web-原生混合的应用程序并不能很好的使用平台指南和规范。但是模态的大致概念准则是你应该熟悉的,以便在必要时打破它。
原文:https://uxplanet.org/modality-the-one-ux-concept-you-need-to-understand-when-designing-intuitive-user-interfaces-e5e941c7acb1
原作者:Fabian Sebastian
Powered by Froala Editor
大牛,别默默的看了,快登录帮我点评一下吧!:)
登录 立即注册