向使用者徵詢IOS授權的五種常見設計模式

 　　小文一篇，話題仍與上周銜接，小結了五種在iOS中向使用者申請許可權的實踐模式，可參考。下面進入譯文。

　　對於iOS app，當功能涉及到推播通知、訪問照片或調用相機、擷取地理位置等等時，都需要向使用者申請授權。申請會發生在app啟動並執行過程中，而不是像Android那樣在安裝的時候就莫名其妙的問使用者是否同意app調用某些系統功能。不過如今Android也在向iOS的方式靠攏。

　　對於產品設計方而言，這裡最大的問題在於，iOS只給你一次機會去徵詢授權 – 一旦那些缺乏耐心和理性的使用者(多數使用者)出於無論什麼原因而拒絕授權，其結果就是要麼無法使用關鍵功能，要麼需要退出app去到系統的Settings裡面重新設定授權然後再回到app。所以，怎樣儘可能確保使用者在初次使用產品時一次性通過授權?這是一個既有挑戰性，同時又有點意思的話題。

　　我們歸納了市面上常見的五種設計模式，供大家根據自己產品的實際情況進行參考。

　　1. 直接問，然後祈禱

　　很多app會在初次使用的過程中直接彈框索取許可權。確實是最簡單的實現方式，但被拒的可能性也最大(除了那些足夠大牌到使用者沒理由不信任的產品)，使用者如果決定重新授權，必須完整執行前面提到的設定流程，因為這個彈框是唯一一次決定的機會。

　　有些功能相對複雜的app更是會在初次載入的時候就執行一系列的授權申請，先是要求調用相機，然後問是否允許擷取地理位置，最後還要讓你授權接收訊息通知。某些時候，這種簡單粗暴的方式也確實可用，比如前面提到的，使用者已經足夠瞭解和信任這款產品的情況下。但對於多數產品，你不能做這樣的假設;即便對於那些大牌，說到底也無法100%確保使用者不會看走眼或習慣性的點擊拒絕。

　　2. 誘導使用者

　　從本質上講仍然是“直接問”的模式，但這類app會在詢問時通過一些小技巧變著法的誘導使用者點擊“允許”。實現成本不會比第一種高出很多，但擷取授權的幾率會增大。看看Lyft的做法：

　　3. 問兩次，讓使用者有所準備

　　你也可以使用變通的方式在某種程度上突破“只能問一次”的局限，譬如在真正的系統對話方塊出現之前展示一個定製化的“假”的對話方塊。

　　如上圖所示，左屏當中的對話方塊完全是定製化的UI元素，使用者點擊OK之後才會出現真正的iOS授權申請。這種方式有兩點好處：

　　- 如果使用者在“假”的申請中拒絕授權，那麼你不會浪費掉唯一的那次“真”的系統授權機會，只需要關閉對話方塊即可;當使用者將來再次需要用到相關功能時，你仍然可以通過這種方式徵詢授權。

　　- “假”的對話方塊在形式上可以自由發揮，譬如加入更多教學內容或引導元素。

　　兩次提問的情境是可以根據實際情況進行控制的，例如Shazam這樣，將第一次機會放在進入實際app之前，與引導頁當中的內容整合起來。

　　4. 等使用者用到相關功能時再問

　　另一種更加情境化的常見模式就是等到使用者實際用到與系統許可權相關的功能時再徵詢授權，例如當使用者點擊“當前位置”按鈕時，詢問是否允許使用當前地理位置，或是當使用者進入拍照介面時，詢問是否允許調用系統相機。

　　這種模式的優點很明顯，就是使用者在實際功能情境中會對將要發生的事情更具預期，所以通過授權的可能性就更高。

　　5. 清單模式

　　如果app較為複雜，功能涉及到的系統授權較多，那麼與一個接一個的彈框相比，清單模式更具積極的引導性。例如下圖所示的Periscope所做的這樣，將所需授權的資訊以清單的形式展示出來，使其在感覺上像是某種正式的任務流程，使用者每點擊一個任務便會彈出一個授權申請，同意授權後，該任務完成。

　　如果使用者拒絕授權？

　　無論怎樣努力，使用者還是有可能拒絕授權。這種情況下，一些app會簡單的告訴使用者怎樣一步一步進入iOS的設定當中開啟授權。

　　不過從iOS 8開始，app可以在自己的介面中提供deep-link將使用者直接帶去系統設定介面。下圖示範的就是一旦使用者拒絕在Shazam當中授權，他們仍可以點擊“Go to Settings”按鈕，一鍵進入系統設定，重新開啟授權。

　　當然，這並不屬於引導使用者進行授權的模式，但相比於從前來說，至少算是不錯的補救措施。