中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

現如今消息通知也是一樁麻煩事，這篇文章旨在介紹幾種通知模型，幫助你的APP挑選到合適的通知模型。

通知是指源自于APP以用戶為目標的信息片段，以下是通知的幾個重要組成部分：

來源(Source)：這是APP中生成通知的源頭。每個APP根據自己不同的內容體系可以有多個內容池，信息在內容池中進行歸類，這些內容池將會變成通知的來源。

信息(Information)：以通知為載體傳達給用戶的消息。比如說“Jesse申請成為你的好友”或者“James贊了你的推文”。

類型(Type)：通知主要分為兩類——信息類和操作類。如果你APP需要的話，這兩種都可以繼續區分子類別。

徽章(Badge)：引導用戶查看通知的視覺元素 。徽章里的指示可以是一個簡單的點，也可以展示未讀消息的計數。

錨點(Anchor)：指的是界面中用來引導用戶進入通知的提示位置。簡單來說，錨點就是用戶看到通知指引或徽章的地方。錨點并不一定只能打在通知的來源，也可以打在你希望體現有通知的地方。錨點可以用來展示多種來源的通知，當然也可以只展示一類。你可以這樣想，來源是信息架構層面的概念，而錨點不過是你可以看到徽章的視覺元素。

通知是一種媒介，APP使用它與用戶溝通，讓用戶有再次打開APP的可能性。因此通知是APP中十分重要的部分。讓我來介紹幾種常見的通知模型，并說明為什么它們適合于自己的APP。

一、通知中心式

在這個模型中，把所有的通知都放在了通知心中里。通知中心可以是一個精致的頁面，也可以是一個彈窗，這取決于你的界面設計。

無論通知的來源是什么，所有的通知都被錨點到通知中心里，然后再對通知進行導航分類。Medium就是使用這種模型，底部導航中的鈴鐺圖標會出現徽章，從而作為指向所有通知的入口。視覺上區分已讀和未讀通知變得尤為重要，用戶需要清晰地辨別這兩類信息。

這種方式的最大優點在于靈活性，以一含百，即使未來有新的來源出現也可以應對。

設計原則：

• 所有不同類別的通知都需要使用同一種設計模式，而且一定要考慮這種模式的伸縮性。
• 如果你有太多通知來源，可能會出現界面亂糟糟的情況，這時候你就要考慮將同一類的通知合并成一個組，有助于減少信息重復出現。例如：James與2位好友開始關注你。
• 請確保通知中心的入口容易被發現與觸達。

通知中心式適合于：

• 產品中的通知無法被錨點到任何一個已有的導航中?？赡芤驗橥ㄖ缓鸵延袃热菀恢拢蛞驗閮热菁軜嬛袥]有可以生成通知的來源。
• 有些來源的通知在已有頁面中無法承載。
• 當時間很緊急，你可能很難把所有可能的通知場景該如何錨點都細想一遍。這種情況下，通知中心是一個很簡單的方案，在實際操作中也很靈活。

二、來源錨點式

這種方式中，所有的通知都被錨點到導航的菜單中，這些菜單也正是通知的來源。

APP中并沒有一個共有的通知中心。看下WhatsApp的截圖會更易理解，無論是安卓還是iOS版本，通知被錨點到了各自的來源——Chats和Calls。

這種方式的優點在于內容的易發現性，憑借通知用戶可以非常直接地獲取到信息，過程中無需進入額外的中間頁。不過這種方式的靈活性和伸縮性不如通知中心式。

這種方式高度依靠APP本身的信息架構，導航本身必須可以容納不同類別的通知。和上一個模型一樣，這里也需要通過視覺設計來區分已讀和未讀通知。

設計原則：

• 確保每一個通知可以和導航里的菜單對應起來。隨著你APP復雜度的增加，各個通知的來源也隨之變多，這個時候你可以考慮使用通知中心或者混合式的模型（把通知中心式和來源錨點式混合起來）。我們將在下一個段落中講到混合式。
• 每一個錨點的設計模式應該可以承載各自的內容，并確保你的通知適合這種錨點的設計模式。用WhatsApp舉例，錨點“聊天”本身有自己的設計模式定義了每一個聊天應該長成什么樣，那關于聊天的通知就必須跟隨這個設計模式?！半娫挕币彩峭?。
• 確保每一個錨點都易被發現與觸達，盡量避免在子級頁面中出現錨點。

來源錨點式適合于：

• 當所有的通知的來源可以被安置到APP首頁（包含主導航）中。
• 你必須仔細想一遍所有需要通知的場景，且所有的通知可以被安置到現有的設計模型里。通知和來源的設計模式必須保持一致，這一點很重要。

三、混合模式

顧名思義是前兩種模式的混合體，且使用最為廣泛，Facebook、LinkedIn、 Twitter、Instagram等一些熱門APP都在使用它。

例如：Facebook，消息中心變成了主導航中的一個菜單，用來展現哪些無法在主頁面中展示錨點的通知。Facebook把好友邀請的通知錨點在了主導航的好友菜單中，而把推薦用戶錨點到了通知中心。

*Facebook目前已更新：

這種模型同時具備了前兩種模型的優點并且可以適用于大部分情況。雖然你現在可以把所有通知都錨點到通知中心里，但仍有必要仔細考慮一下是不是有些場景的通知更應該優先使用來源錨點式。

設計原則：

• 定義產品體系中所有的內容池，并按重要等級排序，這樣可以幫助你列出哪些通知應該被錨點到來源，哪些可以直接進消息中心。由于這種模型與導航非常相關，通知的配置方式會影響到你導航的設計。
• 確保主錨點和通知中心易被發現，并且作為主頁導航的一部分。

混合式模型適用于：

• 當你仔細考慮通知的場景后，發現一些通知可以被錨點到對應的來源中，但是有些卻找不到已有的來源。
• 在你的導航體系中，有些來源藏得比較深。舉個例子，Facebook導航中有個漢堡包餐單，當他的二級餐單中有通知來源時，漢堡包餐單就會變為錨點，例如：小組、視頻、那年今天、收藏夾等。

結論

上述的模型都要用在正確的環境中，根據你APP的信息架構來挑選適合的模型，可以幫助你提供想要的通知類型。

原文作者：Shashank Sahay

原文鏈接：https://medium.muz.li/designing-notifications-for-applications-3cad56fecf96

翻譯：Jesse Zhou

本文由@Jesse Zhou 翻譯發布于人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash, 基于CC0協議