标签栏是新的汉堡菜单吗?
在本文中,我们来讨论一种失策的导航模式。
通常,我不想只抱怨糟糕的UX设计,也不想只指出问题。相反,我总是尝试提出解决方案。这次是另一回事了:解决方案很明显-它的标签栏-但该解决方案的初衷在最近几年迷失了,导致了同样的老问题。在我们开始讨论解决方案之前,是时候再次讨论问题了。
01 回顾
2014年,苹果在移动导航应如何工作方面引发了根本性的转变。在此之前,“汉堡菜单”或“导航抽屉”(官方的Material Design命名)是最常见的移动导航解决方案。在2014年WWDC演讲“ 设计直观的用户体验 ”中,Apple基本上否定了此设计元素,并建议使用不同类型的导航(例如标签栏)。
WWDC演讲“设计直观的用户体验”
WWDC的讨论广为流传,全世界的UX和UI设计师开始谈论汉堡菜单的弊端:
从那时起,汉堡菜单开始消失,标签栏将其替换为解决方案。2015年,甚至是导航抽屉之父的Google也开始在自己的Android应用程序和《材料设计指南》中引入“底部导航”(即iOS“标签栏”)。它似乎是满足直观移动导航目标的最佳解决方案,设计师开始考虑他们想要再次实现的目标。
底部导航,Material Design设计指南导航目标
快速回顾:「导航」必须告诉用户的三件事:
- 我在哪里?
- 我还能去哪里?
- 我到那里会发现什么?
标签栏满足所有3个要求。它在每个屏幕上都是可见的,因此始终为你提供视觉定向。它显示了你在信息体系结构中的位置(活动标签突出显示),可以去的地方(其他标签)以及在那里可以找到的内容(图标和描述性标签)。你可以访问更深的内容(从父屏幕导航到子屏幕),而不会丢失上下文和您在应用中的位置。
换句话说:标签栏是一个完美的移动导航解决方案。至少是这样-直到设计师开始使用它们而没有考虑“为什么?”。在考虑实际问题之前先考虑解决方案时,他们忘记了标签栏最初试图实现的目标。如今,标签栏的使用方式与2014年之前使用汉堡包菜单的方式相同。
02 标签栏的问题
查看以下UI,你最喜欢的Medium iOS应用,并尝试找出问题所在:
屏幕截图:Medium 应用
一旦用户从顶层视图导航到子视图(例如,文章),该子视图就会覆盖整个屏幕,包括标签栏。
屏幕截图:Medium(个人设置)
现在,让我们再次看一下三个导航目标:
- 我在哪里?通过将导航隐藏在子视图中,用户将不再知道他/她所在的应用程序的哪个顶级页面。用户在你的整体信息架构中迷失了位置。
- 我还能去哪里?通过隐藏其他顶级页面,用户将无法直接导航到应用程序的其他区域。相反,他们首先必须导航回到信息体系结构的顶层。
- 我到那里会发现什么?子屏幕中唯一的导航元素是一个小的左箭头,没有标签或描述。它不会通过单击来告诉用户他/她要去哪里。
Medium包含选项卡导航时可能有最好的意图。数以千计的其他iOS和Android应用程序也是如此。它可以完美地在顶级视图上运行,但是它们的执行无法满足子视图中导航的每个目标。
子视图通过覆盖整个导航(选项卡栏)而表现为模态视图(弹窗),但它的动画效果类似于子视图(从右到左),并显示反向链接(箭头),类似于子视图。模态根本不是一件坏事。“模态通过阻止人们在完成任务或关闭消息或视图之前执行其他操作”(Apple)。
但是模态还需要使用模态动画(iOS:从底部到屏幕动画),并包括完成和取消按钮以退出模态视图。模态视图仅用于独立任务的短期任务并且可以完成或取消,例如写邮件,在日历中添加事件,取消通知等……它们不打算用作详细视图或替换子视图。这些子视图不是一个自包含的过程,不能被取消或保存。
有人可能会争辩说,这种限制性使用模态是有例外的,例如对于全屏细节视图(如单张照片)。隐藏应用程序的整体用户界面(如标签栏)可创建焦点并最大程度地减少干扰。在这种情况下,通常使用自定义过渡来解释模态的不常见用法。
虽然“Medium”文章可以被视为缺少自定义过渡和关闭功能的全屏详细视图,但应用程序的设置视图绝对不能。
沉浸式内容的过渡
03 谷歌和苹果的策略
苹果和谷歌只有在极少数情况下才同意某个观点。这是那些罕见的情况之一。Apple和Google的准则均鼓励设计人员在应用程序的每个屏幕上一致使用标签栏(底部导航):
“使用时,底部导航栏出现在每个屏幕的底部” – Google Material Design
“显示键盘时,[仅]隐藏标签栏[…]” — Apple人机界面指南
Apple通过将标签栏添加到其应用程序的每个子屏幕(例如Apple Music,Photos,Podcast,Health或Files)中,非常严格地遵循其自身规范。
Google相册和Apple相册的标签栏
另一方面,Google经常通过隐藏子视图的底部导航来打破自己的规则。尽管Google提供的Youtube始终保持底部导航的可见性,但Google相册和Google+会将其隐藏在子视图(如相册和群组)中。《Material Design 设计规范》从不明确要求设计者将底部导航添加到子视图,但他们要求他们将其添加到“每个屏幕”而不指定信息体系结构中的级别。
Apple始终按应用程序使用标签栏,而Google似乎经常按屏幕使用底部导航*。这样,Google创建的子屏幕既不是真实的子视图(因为没有可见的主导航),也不是模态视图(因为这不是具有取消和保存按钮的独立过程)–在两者之间。
这些中间的屏幕是一个日益严重的问题。从理论上讲,Google确实引入了等同于标签栏的标签,但实际上,他们可能只是引入了下一个汉堡菜单。后来,许多iOS开发人员改编了使用标签栏的“ Google之路”。这样一来,他们就忘记了标签栏最初取代汉堡包菜单的原因。
04 结论
Google为什么以这种方式使用底部导航?他们希望设计师如何使用这些中间的,模态的子视图?我不知道。这些是我的建议:
- 在模态视图和子视图之间划清界限,并知道何时使用哪个
- 只用 自包含过程的模态视图 (以及极少数情况下的全屏详细视图)
- 将子视图用于其他所有内容
- 在每个视图(包括子视图)上显示标签栏/底部导航
- 如果要创建焦点并最大化屏幕空间(例如,用于文章等),则在向下滚动时隐藏导航栏(位于屏幕顶部)和标签栏(位于屏幕底部)。
标签栏是新的汉堡菜单吗?从某种意义上讲,它们是。如果使用正确,它们都是强大的导航元素。但是一旦为了使用标签栏而开始使用标签栏(因为每个人都这样做),你将失去对每次导航的最重要目标的关注,同样的事情发生在4年前的汉堡菜单上。因此,不要停止思考“为什么?”。
原作者:Fabian Sebastian
本文作者 @Fyin印迹 。
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!