寫在翻譯之前：很早以前就有周譯這個想法，但一直沒有行動，也許有時翻譯還會和別人重復了，但也沒關系，就是要自己實際學到了這一個知識點就好了啊，加入翻譯的潮流，堅持下來，積累學習。

這篇文章以3W1H的方式討論了模態界面，從模態界面的角度討論了Apple的新APP Store設計，一個很好的思考點。下面開始正式翻譯：

 

 

很多設計師，主要是年輕的設計師，在創造數字產品時依靠的是他們的直覺。雖然在許多產品中這是起作用的，但是已經證明通用標準能幫助你有邏輯的構建良好的UI解決方案，而不是依靠你的直覺。

 

在這篇文章中，我們將探討模態在用戶界面中的通用標準，討論僅有兩種基本類型的界面的原因，分析APP和網頁在將信息架構和用戶流程轉變成直觀的用戶界面方面是如何失敗的。哦，我們將討論關于小貓們。

 

讓我們以一個大膽的斷言開始探索：

 

界面只有兩種類型：

1. 模態界面

2. 非模態界面

 

就是這樣，讓我解釋一下。幾乎每個可以想象的視圖都可以歸進這兩種類型中。為了理解模態界面和非模態界面的差異，我們首先需要明確什么是模態界面。

 

什么是“模態界面”？

模態界面示例

 

模態界面可以是不同的形狀和大小：

• （1）全屏模態視圖

• （2）彈出窗口

• （3）氣泡彈窗

• （4）燈箱效果

• （5）告警／通知

• （6）多步驟對話窗口

• （7）…

   

模態界面和非模態界面都是子視圖，這意味著它們都附屬于應用的主窗口之下。但是這里有個重要的區別：

 

“【模態界面】是一種主窗口可見但不可用，模態界面作為子視圖在最前面的一種方式。用戶必須先和模態界面交互之后它們才能回到應用的父級界面” — 維基百科

 

大多數的模態界面，尤其是桌面應用，可以輕松識別，因為它們會可視的疊在主窗口上面：比如淡出背景主窗口的彈出窗口，彈出菜單、彈出對話框、燈箱廣告、告警……

 

然而，移動設備的屏幕空間有限，這也是為什么許多模態界面在移動設備上占據全屏的原因。它們不再保持底層主窗口可見，所以也使得它們和非模態界面更難區分：

 

IOS示例：移動設備上的模態窗口通常會完全隱藏APP的主窗口

 

主要的區別在于你和每個界面交互的方式。當一個非模態界面允許用戶輕易返回父級界面，而模態界面要求用戶在他們回到主界面之前必須完成操作（案例中的“保存”）或取消當前的操作。

 

視覺上最明顯的指示就是非模態界面中可以看到導航菜單（案例中的Tab Bar）。非模態界面允許用戶在主導航級別來回切換，即使恰好位于子頁面中。另一方面，在模態界面中，用戶如果想再次使用主導航必須關閉當前窗口（案例中的“保存”或“取消”）。這種區別是大多數APP失敗的原因之一，也是我撰寫文章“Tab Bars是新的漢堡菜單”的原因之一：

 

Tab Bars are the new Hamburger Menus
In this article we are going to talk about a navigation pattern that got out of hand.uxplanet.org

 

 

為什么要使用模態？

 

模態界面解決了一個簡單的問題：用戶很容易被分心，所以你需要抓住他們全部的注意力。模態界面正是這么做的：它要求用戶在繼續之前集中精神在一個單一任務上。

 

“模態通過創造聚焦區域阻止人們在完成任務或刪除消息或查看之前分心去做其它的事情”— 蘋果

 

 

什么時候使用模態？

 

現在我們知道一個模態界面是什么樣的，它和非模態界面的比較以及它的目的是什么，我們必須問自己“我們應該在什么情況下使用它？”

 

來看我答應過你們的小貓們，我們開始吧：讓我們來想象我們正在創作一個獨具匠心和創新精神的硅谷應用：“purrrfect”——一個小貓數據庫，允許用戶上傳、查看和評論可愛貓咪GIF圖片。才華橫溢的概念。

 

Source: https://giphy.com/gifs/tDgXAst2PhIYw 

 

一個簡單的用戶流程圖可能看起來這樣：用戶打開APP，進入幾個可用tab選項之一（我們的小貓數據庫），點擊了其中一只小貓（進入了一只小貓的單獨詳情頁），接著點了評論部分（進入評論部分）

 

purrrfect用戶流程

 

此外，用戶可以在每個階段進行補充操作。例如，他可以添加另一個小貓的信息到數據庫中?；蛘咚梢栽谛∝埖脑斍轫摼庉嬓畔?。好東西。

 

現在，這些界面哪些是模態界面，哪些不是呢？這個分類一點也不簡單——這是我個人的經驗法則：

 

對于自包含流程使用模態界面，對于其它所有流程使用非模態界面。

 

“自包含流程”是指每一個動作有一個明確的起點和重點。在這個操作的有限時間范圍內，它將用戶從一般的用戶流中帶出，讓他們專注于當前的操作，然后再將他們帶回開始的地方。

 

谷歌有這樣一句話：使用模態界面（對話框）…

 

“關鍵在于需要一個特定的用戶任務、決策和確認"— 谷歌

 

在我們的purrrfect應用中，這意味著關鍵用戶流（經常瀏覽應用）是非模態的。然而，一些特殊的有時間限制的操作，比如添加、編輯小貓信息和撰寫評論都是模態的。

 

 

在用戶返回主流之前，可以取消或成功完成所有模態操作。因此，模態界面使用取消和保存按鈕（或一些類似操作），而不是返回按鈕。如果在非模態界面你的返回按鈕同時觸發了保存操作，你可能會考慮將它轉換成有取消和保存的模態界面。這種矛盾通常也是正確的：如果兩個不同的操作，比如取消和保存在你的模態界面中無法起作用（因為它們會觸發相同的操作），你可能會想將它換成非模態視圖。在這種情況下，主導航（比如Tab Bar）也應該在界面中保持可見。

 

讓我們回到改變游戲規則的APP， Purrrfect的界面可能是這樣的：

 

可能的purrrfect用戶界面

 

在現實中，模態和非模態界面的區別可能很不明顯。例如，一張圖片的全屏視圖在大多數APP中是模態界面，盡管它不是一個流程或對話。為了讓用戶產生聚焦，模態界面在其它特殊情況下可能也有意義。在我們小貓的詳情界面(中間)是一個沒有其它操作（如編輯或評論）的終點視圖，我們可能已經用了模態（全屏視圖）。但是，由于它允許用戶更深入的進入信息架構并執行各種附加的操作（顯示注釋、編輯…）,所以它不再具有明確的端點，因此它是主流程的一部分。因此，這是一種非模態視圖。

 

設計師有責任評估一個動作是自包含的還是應用程序一般探索流程的一部分，并決定模態是否有意義。如果有疑問，請記住蘋果的話：

 

“盡量減少模態的使用。一般來說，用戶更喜歡以非線性的方式與應用程序交互。只有在需要引起別人注意的關鍵時刻、必須完成或放棄某項任務才能繼續使用該APP或保存重要數據的時候，才考慮創建一個模態流程。”— 蘋果

 

說明：當然，無需嚴格區分模態和非模態視圖，界面就可以很好的工作。然而，模態概念已經深入蘋果、谷歌、微軟和其它公司的界面生態系統中，并且用戶已經形成了相應的期望。

 

如果蘋果不時不時的打破自己的規則，它就不會是蘋果：例如，新的APP Store在Today選項卡中以模態界面的方式進行高亮打開顯示，但仍然允許用戶導航到屏幕底部獲得進一步推薦的內容（沒有明確的終點）。通過這種方式，用戶無需固定端點就可以在模態界面中進行深入的探索。在這個過程中，他們失去了更改選項卡的能力，并且不能再關閉子頁面上的模態界面。從推薦之外的地方打開相同的APP界面會導致屏幕顯示為非模態界面。這將保留tab bar和返回操作（再次點擊當前的Tab Bar圖標能轉到其主界面）。

 

不一致的Apple UI

 

左邊的不一致可以通過…來解決

• A: 在非模態子界面中使用返回按鈕并高亮顯示，同時保留Tab Bar

• B: 在用戶點擊模態界面內的連接時立即關閉模態界面，并在APP的父級繼續使用非模態界面

 

 

如何使用模態？

 

到目前為止，我們應該對什么時候使用模態界面有了一個大致的了解。剩下的唯一問題就是“我們如何設計它？”，這里有一個快速檢查清單：

 

• 始終在頂部導航欄中顯示關閉按鈕（或取消/放棄/最小化/…）當用戶迷失，他可以輕易的關閉彈窗，并回到APP的頂層界面。

   

• IOS和安卓上的取消按鈕通常位于導航欄的左上角。安卓更喜歡用關閉圖標，而蘋果則喜歡“取消”文本。但是，圖標按鈕在IOS上也很常見，并且被廣泛理解。

 

• 默認情況下，IOS和安卓的保存按鈕都位于導航欄的右上方。但是，這種布局在大屏設備上遙不可及。因此，屏幕底部固定浮動放置或在頁面底部內嵌是我個人推薦的另一個位置。

 

 

多步驟模式

 

一旦模態對話框包含多個步驟或子界面，事情就會變得更加困難。默認情況下，繼續按鈕顯示在右上角。第二步并不會打開新的模態界面，而是停留在當前模態界面，并顯示為現有模態疊加的非模態界面。

 

當將主操作（保存、應用、繼續）放置到屏幕底部時，模態的第二步右上角區域就可以為取消按鈕騰出空間。盡管它從左側跳到了右側，但這種位置仍然比不提供關閉子界面的模態界面的功能要好。

 

動畫

 

到目前為止，IOS和安卓在使用模態視圖方面都非常相似。然而，當你查看動畫時，這種情況就會改變。

 

• iOS:  動畫在IOS中是高度標準化的

   

  非模態界面從屏幕右側進入視圖中。Tab Bar保持在屏幕底部不變。頂部的導航欄也保持不變，但其內容在自定義轉換中淡入淡出。這個動畫還為返回上一層級的邊緣滑動手勢提供了基礎，這也解決了返回按鈕不在單手可觸碰區域的問題。

  另一方面，模態界面從視圖底部進來，覆蓋整個界面（新的頂部導航欄）。他們不使用邊緣滑動手勢，如果沒有內容可保存，自定義下拉手勢可能會有所幫助。

   

• Android: 安卓中的動畫會要豐富的多。谷歌在Material Design的設計指南中推薦使用”有意義的過渡”。子元素在觸摸時抬起并展開的同時，頂部導航欄內容淡入淡出。然而，安卓并不區分模態動畫和非模態動畫。

 

 

結論

 

許多設計師根據直覺設計產品。有時候直覺比標準更重要。但是，重要的是了解公共標準，以便在有意義時適應或忽略它。

 

在我看來，模態的概念是現在的APP設計中最容易被忽略的UX原則之一。跨平臺APP或web本地混合應用并不能使平臺和規范的使用變得更容易。但模態的一般概念是一個知道原則，你應該熟悉，以便在必要時打破它。

 

PS: 原文鏈接限制100個字符是什么鬼，為什么定義是100個字符呢，文章鏈接長怎么了，麻煩想看原文的小伙伴手動粘貼一下吧，原文地址如下

https://uxplanet.org/modality-the-one-ux-concept-you-need-to-understand-when-designing-intuitive-user-interfaces-e5e941c7acb1