哈喽小伙伴们~消息通知是任何APP都必备的功能,但我们真的足够了解它——或者说能正确设计它吗?今天小编就给大家推荐一篇Medium上39k的高赞文章,作者是Flipkart的产品设计师Shashank Sahay,在文章中他为我们详细阐述了APP消息通知的三种设计模型,以及如何使用、选择它们,希望可以对大家有所帮助~
原文内容
Medium的朋友们,大家好。今天我们来讨论一下关于APP的消息通知设计,这是一个相对比较复杂的特性。本文没有涵盖关于它的所有细节,但我们希望它能为你们提供一些清晰的设计思路和方向,以便各位选择正确的App通知模型。
在开始讨论通知模型之前,我们先简要介绍一下什么是通知以及它们由什么组成。
消息通知就是APP希望用户们看到或处理的一些信息段,下面是消息通知的重要组成部分。
来源 - 这是App发出通知的部分。在应用程序信息架构中信息被分类存储在几个模块中,这些存储模块就是信息通知的来源。
信息 - 这是APP传递给用户的消息。例如“彭于晏给你发了一个好友申请”或“吴彦祖已关注你”等等。
类型 - 通知主要有两种分类:信息类和可操作类。根据APP使用场景的不同,这两种类型还会有更多的子类型。
通知标记 - 这是提醒用户有通知消息的可视化指示器。也就是我们通常在APP图标右上方看到的红点,或者未读通知的数字。
锚点 - 锚点就是APP界面上显示通知的可视化组件。简单地说,就是用户看到通知标记所在的那个组件。但锚点并不是通知的来源,而是显示通知的位置。一个锚点可以显示一个或多个来源的消息。换句话说,消息来源是架构/信息层面的概念,而锚点只不过是实现层面让你可以看到通知标记的可视化组件。
通知是App与用户沟通、并吸引用户的重要媒介之一。因此接下来我们将更深入的介绍一些现有的最流行的通知模型,分析如何去选择以及运用它们。
通知中心
在这个模型中,会有一个特定的区域来显示所有的通知提醒。通知中心可以是一个单独的界面,也可以是弹出窗口,这取决于可用的空间。在这个模型中,所有来源的通知都会显示在通知中心中,我们可以从通知中心导航到不同的信息源。
Medium App就使用了此通知模型,响铃图标是所有通知的入口点,并且已读和未读通知在视觉上的不同可以让用户更轻易的区分它们。
Medium — 通知中心
这个模型最大的优点是它的灵活性。它可以容纳所有的通知提醒,不管是已存在或是新的来源。
指导方针 :
在使用通知中心模型时,我们需要考虑不同类型的通知消息,并且遵循统一的设计形式。重要的是,要将其可扩展性作为我们的首要目标
如果APP中有太多的通知来源,那么这个模型可能会看起来有点混乱。所以我们可以将相似类型的通知组合在一起,以帮助用户减少认知负荷。例如,“周杰伦和其他三个人请求添加您为好友”。
确保通知中心容易被用户发现和访问。
何时使用通知中心?
当APP中的某些消息通知无法集成到任何现有导航选项中时,这可能是因为通知与产品上的现有对象不一致,或者通知并不源自于当前信息架构中定义的任何消息源。
当有很多消息无法在APP着陆页中显示出来时。
当你的时间有限,可能还没来得及考虑清楚每一种可能的场景及相应的锚点,你就必须交付一个功能了。在这种情况下,通知中心是你最简单的解决方案,它天生就很灵活。
来源锚定通知
在这个模型中,每个通知都会有一个固定的导航选项,这个选项一般都是通知的来源,并且没有承载所有通知提醒的中心。
看看WhatApp我们就会有更清晰的认识。在两个平台(android和iOS)中,聊天和通话的消息通知分别被锚定在各自的导航菜单上。这个模型的优势在于它能引导用户发现更多内容,用户可以直接访问所有通知传递的信息,而无需中间操作。但这个模型并不像通知中心那样灵活和可扩展。
WhatsApp — 锚点在消息源上的通知提醒
这个模型在很大程度上依赖于APP的信息架构,导航必须能够容纳所有不同类型的通知。并且与前面的模型一样,已读和未读通知在视觉上的区别化是非常重要的。
指导方针
如果要确保每个通知都可以链接到界面中的某一导航选项,那么随着APP复杂程度的增加,通知的来源数量也可能增加。所以这种情况下,我们可以将模型改为通知中心,或者考虑一种混合模型(那就是锚点模型和通知中心的结合)。我们会在下一节讲到混合模型。
在此模型下,每个锚点都应有一个对应其所含内容的设计形式,以确保我们的通知符合锚点的设计形式。为了理解这个,让我们看一下 WhatsApp 的例子。锚点“聊天”有一个设计形式,它定义了聊天对象的外观,这意味着任何与聊天绑定的通知都必须遵循此模式。“呼叫”也是如此。
确保锚点易于发现和访问,并且避免使用嵌套锚点。
何时使用源锚定通知
当所有通知来源都需要在同一界面中显示时。
我们已经考虑了通知的所有场景,并且所有通知都可以使用现有的设计模式。这些通知必须遵循其锚点所在的消息源的设计形式。
混合模型
这个模型是两个模型的组合,同时也是最常用的模型,很多流行的应用都在使用这种模式,如Facebook、LinkedIn、Twitter和Instagram等等。在这里,通知中心成为导航菜单中的一个选项,它集合了各种不够资格在首页中显示的来源锚点。比如,Facebook 把请求添加好友的通知锚点到“朋友”选项,但邀请点赞被锚点到了通知中心。
该模型具有两种模型的优点,能够方便地适应大多数情况。不过尽管我们现在能够将消息提醒锚点到通知中心,仍然有必要考虑所有的场景,筛选出适合放到通知中心的锚点并将它们排出优先级。
如同锚点通知模型,这个模型也严重依赖于导航菜单,而且还有一个通知中心的菜单选项。
指导方针
在混合通知模型中,我们需要筛选并排列出产品架构中最重要的信息,这样才可以决定哪些锚点应该放在消息源,哪些应该放在通知中心。并且,由于此模型依赖于导航,所以以通知消息的具体设置可能会因为可用空间的变化而改变。
确保主锚点和通知中心作为界面导航中的一部分很容易被发现。
何时使用混合模型
你已经考虑了所有通知场景,并且有一些通知可以锚定到它们各自的来源中,但是还有一些无法放在当前架构的任何消息源上
导航中有嵌套的消息来源。例如,Facebook APP中的汉堡式菜单图标是一个锚点,它对应于多个消息源,比如 Groups, Watch, Memories, Saved, Marketplace 等等。
结论
上面提到的这些模型在正确的场景中使用时是非常有效的。并且,为我们的APP选择哪种模型取决于信息架构和我们想要满足的通知类型。
原文链接:https://medium.muz.li/designing-notifications-for-applications-3cad56fecf96
用设计的角度看世界,用学习的方式来成长
BigDcc
暂无评论
违反法律法规
侵犯个人权益
有害网站环境