2016-1-7 用心設計
如果您想訂閱本博客內容，每天自動發到您的郵箱中， 請點這里
譯者注：本文譯自蘋果官方人機界面指南 iOS Human Interface Guidelines (2015年10 月21日)，由騰訊ISUX設計師翻譯整理，非發文者一人之作。譯文首發于ISUX博客，如在閱讀過程中發現錯誤與疏漏之處，歡迎不吝指出。后續章節會陸續更新，敬請期待。
往期：
《iOS 9人機界面指南（一）：UI設計基礎》
《iOS 9人機界面指南(二)：設計策略》
《iOS 9人機界面指南(三)：iOS 技術 (上)》
文章索引
在iOS 8及之后的版本中，使用HealthKit構建的應用可以利用從健康應用中獲取的數據為用戶提供更強大、更完整的健康及健身服務。在用戶允許的情況下，應用可以通過HealthKit來讀寫健康應用(用戶健康相關數據的存儲中心)中的數據。
舉例來說，用戶可以允許營養應用從健康應用中獲取體重及活動數據，用于告訴他們為了達到既定目標一天應該消耗多少卡路里。這個營養應用還可以通過 HealthKit更新健康應用上實際消耗的卡路里數據，讓用戶能更容易地跟蹤他們的健康計劃的進展。想要了解如何將HealthKit整合進你的應用 中，請參閱HealthKit Framework Reference.
下面的指南能夠幫助你設計出讓人信任且喜愛的健康類應用：
當且僅當你有令人信服的理由時才去訪問健康應用中的數據。HealthKit是為了專注于健康及健身服務的應用而設計的。如果一個應用請求獲取與其不相關的健康信息，用戶不太可能會放心地將個人數據提供給這個應用。因此，你需要確保用戶能夠理解你的應用需要獲取他們某些具體的個人健康數據的原因，并告訴他們共享這些數據的好處。
避免在用戶還不知道用途前就向他們請求訪問私人健康數據。當用戶能夠看到當前的任務和你需要訪問的數據的關聯性 時，會更樂意給予你訪問權限。舉例來說，當用戶在給一個減肥應用填寫資料時，讓他允許你訪問健康應用中儲存的體重數據是合理的。但如果那個減肥應用在啟動 時就立即提出訪問體重數據的請求，用戶更可能會選擇拒絕分享該個人數據。
使用系統提供的用戶界面來請求訪問用戶的數據。當用戶想要向應用授予訪問他們的數據的權限時，一般會期望看到如下圖所示的系統權限許可列表。為了確保給用戶提供良好的用戶體驗，應避免在應用的其他頁面中重復使用權限許可列表上的信息。而是應該在權限列表中添加些自定義信息來說明為什么你的應用需要訪問特定的數據(參閱HKHealthStore Class Feference可獲取更多信息)的原因。確保這些信息簡潔且能清晰地說明你的應用是如何利用健康應用中的數據，以及收集這些數據的好處。
![[ISUX譯]iOS 9人機界面指南(三)：iOS 技術 (下)](http://www.mobileui.cn/blog/uploads/2016/01/022403TCD.png)
注意：當用戶決定停止與你的應用共享數據時，讓他們可以在系統設置中即可完成變更，而不需要通過你的應用界面。
不要在你的應用界面中使用健康應用的圖標、圖片或者截圖。和蘋果所有的系統設計一樣，這些圖像都是受到版權保護的，不應該在你的應用中出現。
不要在你的應用中使用“HealthKit”這個專用術語。HealthKit是代表能夠獲取健康應用中儲存的數據的技術框架的專用技術術語。如果你需要向用戶解釋你的應用和健康應用中的數據的聯系，請使用“健康應用”這個用語。例如，你可以說你的應用“將保存信息至健康應用中”或“所使用的數據是從健康應用中獲取的”。
應用內購買服務使得用戶可以在你的應用中、你所設計的商店中購買到數字產品。
![[ISUX譯]iOS 9人機界面指南(三)：iOS 技術 (下)](http://www.mobileui.cn/blog/uploads/2016/01/022836trr.png)
例如，用戶可以做這些事：
你可以使用StoreKit框架以嵌入的方式將商店添加到你的應用中，并且用來支持應用內購買服務。當用戶進行購買時，StoreKit會連接到應用商店進行安全支付，然后再告知你的應用以便它可以提供用戶已購買的商品。
重要:應用內購買服務只提供支付功能，其他功能由你自己提供，例如向用戶展示商品，解鎖內置功能，從你自己的服務器上下載內容等等。當然，你所提供的所有商品都必須在應用商店注冊過。
想要了解關于在應用中添加商店的技術要求，請查看In-App Purchase Programming Guide.想要了解更多關于應用內購買的商業需求信息，請查看App Store Resource Center.當然，你還應該查看相關許可協議來確定你的應用可以出售哪些商品以及如何提供商品。
遵循以下幾點規范，可以幫助你設計出用戶喜歡的購買體驗。
將商店的使用體驗優雅地集成到你的應用中。在展示商品和處理交易時，給用戶提供一種熟悉、一致的體驗。你一定不希望用戶在訪問你的商店時感覺像是進入別的應用。
使用簡單明了的標題和說明。最好能讓用戶在掃過一組項目時，可以快速發現感興趣的內容。文案上不要截斷隱晦，簡單直白的語言和標題更容易讓用戶理解你所要展示的商品。
不要更改默認的確認對話框。當用戶購買一個商品時，StoreKit會提供一個確認對話框(如上圖所示)。這個確認對話框可以幫助用戶避免買錯東西，所以不要修改它。
游戲中心給用戶提供玩游戲、組織多人在線游戲以及其他更多功能。玩家可以使用內置的游戲中心應用來注冊賬戶、發現新游戲、添加好友、瀏覽玩家排名和戰績。
![[ISUX譯]iOS 9人機界面指南(三)：iOS 技術 (下)](http://www.mobileui.cn/blog/uploads/2016/01/022836TeV.png)
作為一名游戲開發人員，你可以使用GameKit應用接口來發布分數和戰績到游戲中心的服務器上，在你的游戲頁面中顯示玩家排名，幫助用戶找到其他玩家。想要了解如何將游戲中心集成到你的應用中，請查看Game Center Programming Guide.
遵循以下幾點規范，有助于你的應用給用戶提供好的游戲中心體驗。
不要使用自定義的用戶界面來提示用戶登錄到游戲中心。如果用戶在未登錄到游戲中心的情況下打開了一個需要啟用游戲中心的應用，系統會自動提醒他們去登錄。所以沒必要自定義一個登錄界面，而且有可能還會讓用戶感到困惑。
一般情況下，使用標準的游戲中心界面。在少數情況下，可能自定義游戲中心的界面是合理的，但是這樣做會有讓用戶感到困惑的風險。標準的游戲中心界面對于iOS和OS X的用戶是熟悉的，而且它會給用戶一種置身于一個龐大游戲社區的感覺。
允許用戶關閉語音聊天。有些用戶可能不想在進入游戲時就自動開啟語音聊天，而且大多數用戶希望在特定情境下可以關閉語音聊天。
如果你允許你的應用中出現廣告，那么你可以通過用戶瀏覽或者點擊這些廣告獲得收益。(如圖所示，這個底部預留位置就是用來放置iAd橫幅廣告。)
![[ISUX譯]iOS 9人機界面指南(三)：iOS 技術 (下)](http://www.mobileui.cn/blog/uploads/2016/01/02291393t.png)
通過iAd網絡你可以在你的用戶界面中以特定的視圖投放一則廣告。最初，這種視圖可以用來承載目標橫幅廣告，起到引導用戶進入查看全面廣告詳情的作用。當用戶點擊該橫幅廣告時，廣告就會執行預先設定的動作，例如播放一段影片、展示可交互的內容，或者啟動Safari打開目標網頁。該動作所展示的內容可以遮擋住你當前的用戶界面，或者使你的應用轉換到后臺運行。
有三種類型的橫幅廣告供你在應用中使用：標準(standard)、中等矩形(medium rectangle) 和全屏(full screen)。所有類型的橫幅雖然在外觀和行為上存在差異，但都提供同樣的功能，就是引導用戶進入廣告。
標準橫幅(standard banner)占用屏幕較少的空間，通常從始至終都可見。你可以選擇在應用的哪些頁面展示標準橫幅，并在給這些頁面設計布局時預留出空間。
![[ISUX譯]iOS 9人機界面指南(三)：iOS 技術 (下)](http://www.mobileui.cn/blog/uploads/2016/01/022914El2.png)
所有的iOS應用都可以展示標準橫幅。你可以使用ADBannerView類中的廣告視圖來顯示標準橫幅廣告。
中等矩形橫幅 (medium rectangle banner) 的行為同標準橫幅類似，同樣也可以選擇展示中等矩形橫幅的位置。
![[ISUX譯]iOS 9人機界面指南(三)：iOS 技術 (下)](http://www.mobileui.cn/blog/uploads/2016/01/023020Zk0.png)
中等矩形橫幅只能在iPad的應用中使用。你可以使用ADBannerView類中的廣告視圖來顯示中等矩形橫幅廣告。
全屏橫幅 (full screen banner) 會占用屏幕的大部分甚至是全屏空間，并且通常只在應用程序流的特定時間或特定位置顯示。你可以選擇使用模態視圖來顯示橫幅廣告，或者用獨立頁來展示可滾動的廣告內容。(在下面的示例中，應用提供了一種雜志閱讀的體驗，通過翻頁離開或回到全屏廣告頁面。)
![[ISUX譯]iOS 9人機界面指南(三)：iOS 技術 (下)](http://www.mobileui.cn/blog/uploads/2016/01/023021aaM.png)
你可以使用ADInterstitialAd類中的廣告視圖在你的應用中顯示全屏橫幅廣告。
iAd框架包含了所有類型的橫幅廣告，并且會在右下角顯示iAd的標識。iAd框架的設計固定在屏幕底部時看起來效果最佳。
為了保證廣告無縫植入，并且要提供最好的用戶體驗，可以遵循以下幾點規范。
將標準橫幅廣告視圖盡量放置在屏幕底部或底部附近。這個位置的差別取決于屏幕底部是否包含欄(bar)以及是什么樣的欄。
| 欄 | 標準橫幅的位置 |
| 屏幕底部沒有欄 | 屏幕底部 |
| 屏幕任何地方都沒有欄 | 屏幕底部 |
| 有工具欄(toolbar)或標簽欄(tab bar) | 底部欄的上方 |
將中等矩形橫幅廣告視圖放置在不會干擾內容的地方。和標準橫幅一樣，中等矩形橫幅也最好放置在屏幕底部或底部附近。放在底部附近也能減少干擾用戶的可能性。
當用戶體驗存在中斷時請使用模態視圖來展示全屏橫幅廣告。如果你的應用中有自然中斷或情景轉換，用模態樣式來展示會更合適。當你使用模態樣式來展示全屏橫幅時(通過用presentFromViewController實現)，用戶要么進入廣告，要么關閉它。出于這個原因，當用戶有做出轉變的預期時 (比如完成了一個任務后) 用模態視圖的形式來展示比較好。
應用的界面視圖進行轉場切換時不要使用模態樣式展示全屏橫幅。如果用戶在使用你的應用時會頻繁的進行屏幕切換操作，例如雜志翻頁或翻閱一些畫冊圖片合集，此時使用非模態的形式會更合適。當你使用非模態來顯示全屏橫幅時(通過使用presentInView實現)，可以在用戶界面中保留欄 (bar) 使得用戶可以通過應用中的控件進入或退出廣告。同其他橫幅廣告一樣，點擊全屏橫幅廣告也會觸發iAd體驗，但是如果條件允許的話，你的應用也可以對橫幅廣告區域支持其他手勢操作 (比如拖動或滑動)。
確保使用合適的動畫效果來顯示和隱藏非模態的全屏橫幅視圖。例如，雜志閱讀應用可以用和雜志翻頁一樣的動畫效果。
確保橫幅廣告在應用中出現的時間和位置是合理的。用戶只有在不覺得廣告會打擾他們正常的工作流程時才有可能去體驗iAd.這點對于游戲這樣的沉浸式應用尤其重要：你肯定不想將橫幅放置在影響用戶玩游戲的位置。
避免將橫幅放置在用戶只會一掃而過的頁面。最好不要將橫幅廣告放置在用戶會快速略過的頁面，比如用戶正要深入挖掘或前往他們所關注的內容。通常用戶在一個頁面停留至少1、2秒后才有可能會點擊廣告。
盡可能的支持雙向展示橫幅廣告。最好讓用戶在使用應用時不必旋轉設備就能瀏覽廣告。當然，支持雙向也能給你的廣告提供更大的展示區域。想要了解如何確保轉換方向時橫幅廣告能正常響應，請查看iAd Programming Guide.
不要讓標準或中等矩形橫幅廣告滾出屏幕。如果你的應用需要滾動來展示更多內容，確保橫幅廣告一直固定在它的位置上。
當用戶瀏覽或與廣告進行交互時，暫停那些吸引用戶注意力或需要操作的活動。當用戶選擇瀏覽廣告時，他們不想因此錯過應用中正發生的事件，也同樣不想讓應用打斷廣告體驗。一個好的經驗方法是像應用程序轉入后臺運行那樣暫停當前活動。
除非有特殊情況，否則不要中斷廣告。一般情況下，當用戶瀏覽并與廣告進行交互時，應用還是會繼續運行并接收事 件，所以也有可能突然出現一個事件需要獲得用戶的注意力。然而，需要打斷廣告的場景其實非常少。有一種情景是有的應用會提供互聯網語音協議服務 (VoIP).在這種應用中，有電話接入時可能會取消正在運行的廣告。
注意:取消廣告可能會對應用能接受的廣告類型以及能獲取的收益有不好的影響。
用戶可以通過AirPrint無線打印應用中的內容，還可以使用打印中心應用檢查打印任務。
![[ISUX譯]iOS 9人機界面指南(三)：iOS 技術 (下)](http://www.mobileui.cn/blog/uploads/2016/01/023108e5P.png)
你可以利用內置的支持程序來打印圖片和PDF文件，或者可以使用特定的打印程序接口來完成自定義的格式設置和渲染設置。iOS可以處理打印機的發現、任務排序以及在指定打印機上執行打印任務。
通常來講，用戶想要打印文件的時候，只需要點擊應用中的標準動作按鈕(Action button)。當他們在界面視圖中選擇了要打印的項目后，可以接著選擇打印機，設置打印屬性，最后點擊打印按鈕開始打印。
打印中心應用是一個只有在處理打印任務時才可見的后臺系統應用，用戶可以用它來查看打印任務。用戶可以在打印中心瀏覽當前打印隊列，查看某個打印任務的詳情，還可以取消某個任務。
只需添加少量代碼就可以支持基本打印功能 (想要了解在代碼中添加打印功能，請查看Drawing and Printing Guide for iOS).想要確保好的打印體驗，可以遵循以下幾點規范：
使用系統提供的動作按鈕。用戶對系統提供的按鈕的含義和行為都很熟悉，所以盡可能的使用系統動作按鈕。如果你的應用沒有工具欄或導航欄，那就要另當別論了。在這種情況下，你就需要自己設計一個可以出現在應用主界面的打印按鈕，因為動作按鈕只能在工具欄和導航欄中使用。
在當前情境下打印操作是基本功能時才顯示打印項(Print item).如果當前情境并不適合打印，或者用戶并不想打印，就不要在由動作按鈕顯示的視圖中將打印項顯示出來。
合適的話，給用戶提供更多打印選項。例如，讓用戶設置打印頁碼范圍或打印份數。
如果用戶不能打印，則不要顯示特定的打印用戶界面。在向用戶展示有打印項的界面前，確保用戶的設備是支持打印的。想要了解如何在代碼中實現，請查看UIPrintInteractionController Class Reference.
位置服務允許應用獲取用戶當前大致的地理位置，設備指向的方向以及用戶移動的方向。其他系統服務，例如通訊錄、日歷、備忘錄和相冊等，同樣也允許應用訪問用戶存儲在里面的數據。
![[ISUX譯]iOS 9人機界面指南(三)：iOS 技術 (下)](http://www.mobileui.cn/blog/uploads/2016/01/023109UZd.png)
雖然獲取了用戶數據的應用能帶來一定的方便，但還是需要為用戶提供維持信息私密性的功能。例如，用戶喜歡應用自動給內容加上位置標簽，或者可以找到附近的好友，但用戶也需要能在不想分享位置的時候關閉這些功能。(想要學習如何給應用增加獲取位置功能，請參閱Location and Maps Programming Guide.)
以下幾點可以幫助您以用戶不反感的方式獲取用戶數據。
確保使用戶理解分享私人數據的原因。如果沒有明顯的需要，用戶自然會對私人信息的請求感到懷疑。為了避免用戶反感，確保在用戶使用明顯需要個人信息的功能時再進行提醒。例如，即使沒有打開位置服務用戶也可以使用地圖，但是在用戶使用定位或導航功能時就會有提醒。
應用需要個人信息的原因不明顯時向用戶做出解釋。你可以在提醒框中給出文字性的描述，例如“這個應用需要訪問你的通訊錄”或者“是否允許應用獲取你的地理位置？”。這些文案最好明確且有禮貌以讓用戶無壓力的理解為什么需要訪問他們的信息。
講述原因的文案應該遵循以下原則：
只有當你的應用沒有用戶數據就無法提供基礎服務時，才在一開始就征求用戶的許可。如果你的應用在知道了用戶私人信息后才能提供主要功能是顯而易見的話，用戶不會因此覺得煩擾。
避免在用戶選擇需要數據的功能之前調用觸發提醒框的程序。這樣，就可以避免用戶疑惑為什么在使用不需要私人數據的功能時有請求提醒。(注意，檢查用戶位置服務的設置并不會觸發提醒。)
檢查位置服務的設置來避免觸發沒必要的提醒。你可以使用核心位置的程序接口來實現(想要學習如何做，請參閱Core Location Framework Reference).使用這些知識，可以盡可能地在使用需要位置信息的功能時才進行提醒，或者完全避免提醒。
通過使用Quick Look，用戶可以在你的應用內預覽文件，即使你的應用是打不開這個文件的。舉例來說，你可以允許用戶預覽一些從網站上下載或從其他來源獲得的文件。
![[ISUX譯]iOS 9人機界面指南(三)：iOS 技術 (下)](http://www.mobileui.cn/blog/uploads/2016/01/023207Agb.png)
想要學習如何在應用中加入Quick Look文件預覽功能，請參閱Document Interaction Programming Topics for iOS.
在你的應用內預覽文件之前，用戶可在你定制的視圖中查看該文件的信息。例如，用戶從一封郵件中下載了附件之后，郵件應用(Mail)會在郵件中使用定制的視圖展示文件的圖標、標題和大小。用戶可以通過點擊它來預覽文件。
![[ISUX譯]iOS 9人機界面指南(三)：iOS 技術 (下)](http://www.mobileui.cn/blog/uploads/2016/01/023208YZy.png)
你可以在應用中用一個新的視圖來展示文件預覽，或者使用全屏模態視圖。展示的形式取決于你的應用運行在什么設備上。
在iPad上使用模態視圖來顯示文件預覽。iPad的大屏幕適合在一個方便用戶離開的沉浸式環境中展示文件預覽。縮放操作(zoom transition)很適合展示預覽。
在iPhone上使用專用的視圖，最好是導航視圖來顯示文件預覽。這樣可以使用戶在應用情境中通過導航進入文件預覽，不至于迷失。雖然也可以在iPhone應用中使用模態顯示，但不推薦這樣做。(注意縮放操作在iPhone上并不適用。)
另外要注意的是，在導航視圖中顯示文件預覽意味著允許Quick Look在導航欄上放置特定的預覽控件。(如果你的視圖中包含工具欄，Quick Look會將預覽控件放在工具欄上。)
無論聲音在你的應用中是主要體驗的一環，還是錦上添花的元素，你都需要知道用戶對聲音表現的期望以及與如何滿足這些期望。
人們可以使用設備控件來調整聲音，他們還可能使用有線或無線的耳機和聽筒。人們也會對于他們的行為如何作用于他們聽到的聲音有各種各樣的期望。雖然你可能會發現有一些期望很讓人意外，但它們都會遵循用戶控制的原則，即應是用戶而非設備掌控聽到聲音的時機。
用戶會依據需要將設備靜音：
例如，在劇院中，用戶將他們的設備調至靜音以避免打擾劇院中的其他人。在這一情境下，用戶仍然希望能在他們的設備上使用應用，但他們不希望被無預期或突兀的聲音所打斷，如手機鈴聲或新消息音。
當用戶操作的明確目的就是聽到聲音時，鈴音/靜音開關(或靜音開關)不會屏蔽這些操作所產生的聲音。例如：
用戶使用設備音量調節按鍵可調節他們的設備所能發出的所有聲音的音量，包括歌曲、應用音效和設備聲音。不管鈴聲/靜音(或靜音)的開關在什么位置，用戶都能使用音量調節按鍵屏蔽所有聲音，使用音量調節按鍵調節應用當前所播放的音頻時同樣調整了全局系統的音量，鈴聲音量除外。
對于iPhone：當沒有音頻播放時使用音量鍵可以調整鈴聲音量。
用戶使用耳機的目的在于能夠私密地收聽聲音以及解放他們的雙手。不管這些配件是有線的還是無線的，用戶對這個體驗都有特定的期待。
當用戶插入耳機或連接無線音頻設備時，他們期望能以私密的狀態繼續收聽當前播放的音頻。因此，他們希望應用能夠不中斷地繼續播放當前正在播放的音頻。
當用戶拔出耳機或斷開與無線設備的連接時(抑或設備超出范圍或關閉時)，他們不希望他們剛剛收聽的內容被自動地與他人分享。因此，他們希望正在播放音頻的應用暫停播放，讓他們能夠在自己想要繼續播放的時候再開啟。
如果必要的話，你可以通過調整相關的、獨立的音量水平以在你的應用中制造最好的混音輸出效果。但最終音效輸出的音量也應該能由系統音量控制，可以通過音量鍵或音量滑塊進行調節。這意味著應用的音頻輸出的控制權仍然歸屬在用戶手中。
確保你的應用能適時地顯示音頻路徑選擇。(音頻路徑(audio route)是指音頻信號的電子通路，例如從設備到耳機或是從設備到揚聲器。)即使人們沒有物理性的插入或拔出音頻設備，他們也仍希望能選擇其他不同的音頻路徑。為了實現這一訴求，iOS能自動顯示可讓用戶選擇輸出音頻路徑的控件(使用MPVolumeView類能允許這個控件顯示在你的應用中)。由于選擇不同的音頻路徑是用戶主動的行為，用戶期望當前播放的音頻能繼續不中斷。
如果你需要顯示音量滑塊，在使用MPVolumeView類時，確保使用的是系統提供的可用的音量滑塊。注意，當正在使用的音頻輸出設備不支持音量控制時，音量滑塊會被合適的設備名稱所替代。
如果你的應用只產生一些與其功能無必要關系的界面音效時，(盡量)使用系統音效服務(System Sound Services)。系 統音效服務是一種能產生警示音、界面音效和發出振動的iOS技術；它不適合任何其他用途。當你使用系統音效服務(System Sound Services)來產生音效時，你不能干涉你的音頻與設備的音頻的交互方式，也不能干涉它處理干擾和設備配置變化的方式。想了解如何使用這一技術，請參 閱Audio UI Sounds (SysSound)中的范例項目。
如果音效在你的應用中扮演重要的角色，使用音頻會話服務(Audio Session Services)或是AVAudioSession類。這些程序接口不產生音效；相反，它們會幫助你了解你的音頻應該如何與設備的音頻進行交互以及如何響應設備配置的干擾與變化。
對于iPhone：無論你使用什么樣的技術來制作音頻，無論你如何定義來它的行為，電話總是可以中斷當前運行的應用。這是因為任何應用都不應該阻止人們接收來電。
在音頻會話服務(Audio Session Service)中，音頻會話(audio session)執行了你的應用與系統之間音頻中介的功能。音頻會話中最重要的方面之一就是類目(category)，它定義了你的應用的音頻行為。
為了實現音頻會話服務帶來的好處并提供用戶期望的音頻體驗，你需要選擇可以完美描述應用音頻行為的類目(category)。具體情況取決于你的應用只在前臺播放音頻還是也要在后臺播放音頻。在你做這一選擇的時候，遵循以下這些原則：
表35-1列舉了你可以使用的音頻會話類目。不同的類目可以允許通過鈴聲/靜音開關或靜音開關(或設備鎖)來實現靜音、與其他的音頻混合或者控制應用在后臺播放。(欲了解編程界面上所呈現的類目和屬性的準確名稱，請參見Audio Session Programming Guide.)
表35-1 音頻會話類目及其相關行為
| 類目 | 意義 | 靜音 | 混合 | 后臺播放 |
| 個人環境 | 聲音增強了應用的功能且應該靜音其他音頻 | 支持 | 不支持 | 不支持 |
| 環境 | 聲音增強了應用的功能但不應該靜音其他音頻。 | 支持 | 支持 | 不支持 |
| 播放 | 聲音對應用來說很重要且可以與其他音頻混合。 | 不支持 | 不支持(默認)支持(當“與其他音頻混合”屬性被添加時) | 支持 |
| 錄音 | 音頻是用戶記錄的。 | 不支持 | 不支持 | 支持 |
| 播放和錄音 | 聲音代表音頻輸入與輸出，按順序地或同時地。 | 不支持 | 不支持(默認)支持(當“與其他音頻混合”屬性被添加時) | 支持 |
| 音頻處理 | 應用執行硬件輔助音頻編碼(不播放或錄音)。 | 不適用 | 不支持 | 支持* |
*如果你選擇音頻處理類目并且你希望在后臺運行音頻進程，你需要在完成音頻處理之前防止你的應用被暫停。欲了解如何實現這一功能，參見《iOS應用編程指南》中的執行長時間運行的后臺任務。
以下是一些示例情境，其中指示了如何選擇音頻會話類目以提供用戶喜歡的音頻體驗。
情境1：一個幫助人們學習新語言的教育類應用。你需要提供：
在這個應用中，聲音對于主要功能是十分重要的。人們使用這個應用來聽他們正學習的語言的詞語與短語，因此即使當設備鎖定或者被調至靜音時也要能播放聲音。因為用戶需要清晰地聽到聲音，他們會期望其他他們可能播放的音頻都被靜音。
為了滿足用戶對于該應用所期望的音頻體驗，你應該使用播放(Playback )類目。雖然這一類目可以被定義為與其他音頻混合，但該應用應該使用默認的行為以確保其他的音頻不會干擾那些用戶明確選擇聽到的教育性內容。
場景2：網絡協議電話(VoIP)應用。你需要提供：
在該應用中，聲音對于主要功能是十分重要的。人們經常會在使用另一個應用時使用該應用與他人進行交流。用戶期望能在他們將設備調至靜音或設備被鎖定時接聽電話，他們希望在來電期間其他音頻被靜音。他們也希望應用在后臺運行時也能繼續打電話。
為了滿足用戶對于該應用所期望的音頻體驗，你應該使用播放和錄音(Play and Record)類目，并且你要確保只有在你需要時才會激活你的音頻會話，以便用戶可以在打電話過程中使用其他音頻。
場景3：允許用戶在不同任務中操作角色的游戲。你需要提供：
在該應用中，聲音會在很大程度上提升用戶體驗，但對于主任務并沒有那么重要。而且，用戶可能會希望能在玩游戲時靜音或聽他們樂單中的歌曲而不聽游戲配樂。
最好的策略是在你的應用啟動時確定用戶是否在收聽其他音頻。不要要求用戶選擇他們是要收聽其他音頻或是你的音效。而應該使用音頻會話功能中的AudioSessionGetProperty來請求kAudioSessionProperty_OtherAudioIsPlaying屬性的狀態。依據所請求的答案，你可以選擇環境(Ambient)或是個人環境(Solo Ambient)類目(這兩種類目都允許用戶靜音玩游戲)：
情境4：一個為用戶到達目的地提供準確、實時導航指示的應用。你需要提供：
在該應用中，無論應用是否是在后臺運行，語音導航指示都表現為主要任務。基于這一原因，你最好使用播放(Playback)類目，它允許你的音頻在設備被鎖定、靜音或是在后臺運行時仍可以播放。
你可以通過添加kAudioSessionProperty_OverrideCategoryMixWithOthers屬性來實現允許人們在使用你的應用時收聽其他音頻。但是你也想要確保用戶在他們正在播放其他音頻時能聽到語音提示。你可以為音頻會話添加kAudioSessionProperty_OtherMixableAudioShouldDuck屬性來確保你的音頻比其他音頻的聲音更大( iPhone上的電話音頻除外)。這些設置允許應用在后臺運行時也可以恢復音頻會話，可以確保用戶能獲得實時更新的導航。
情境5：一個允許用戶上傳文本和圖片到網站上的博客應用。你需要提供：
在該應用中，聲音提升了用戶體驗，但也不是必需的。主任務與音頻并沒有關系，用戶也不是必須要通過收聽聲音才能成功使用應用。在這一情境中，你最好 使用系統聲音服務來產生聲音。這是因為這個應用中所有聲音的音頻情境都符合本技術想要達到的目的，也就是說應制作符合用戶所期待的、能通過設備和鈴聲/靜 音(或靜音)開關來調節的界面音效和提示音。
有時候，當前播放的音頻會被來自于不同應用的音頻所打斷。舉個例子，在iPhone上，來電會持續中斷當前應用的音頻。在多任務情境中，這種音頻中斷的頻率可能會很高。
為了提供用戶喜歡的音頻體驗，iOS系統依賴于你能做到下面幾點：
每個應用需要識別會引起音頻中斷的類型，但不是每個應用都需要決定如何在音頻中斷結束后進行反饋。這是因為多數類型的應用應在音頻中斷結束后恢復音頻。只有那些主要或部分由媒體播放組成(以及提供媒體播放控制)的應用，才必須用額外的步驟來決定什么是合適的反饋。
從概念上講，基于中斷當前音頻的音頻類型以及中斷結束后用戶所期望的特定的應用反饋方式，有兩種類型的音頻中斷：
在可恢復性中斷結束后，有媒體播放控件的應用應該恢復它被中斷前的任務，無論是繼續播放音頻還是保持暫停。沒有媒體播放控件的應用則應該恢復播放音頻。
舉個例子，試想用戶在iPhone上使用應用播放音樂時，在播一首歌的中間來了一個網絡電話。用戶接起了電話，期望在他們通話時播放的應用能靜音。 在通話結束后，用戶希望播放的應用自動恢復播放歌曲，因為音樂而非電話才是他們的主要聆聽體驗，而他們在電話接入前也沒有暫停音樂。另一方面，如果用戶在 電話接入前暫停了音樂播放，他們會希望電話結束后音樂仍保持暫停。
其他能引起可恢復性中斷的應用的例子還有那些具備鬧鐘、音頻提示(例如語音方向指示)或其他間歇性音頻功能的應用。
下面的指南可以幫助你決定當一個音頻中斷后如何繼續以及提供什么信息:
確定由你的應用引起的音頻中斷的類型。在你的音頻結束時，你可以通過以下任意一種方式去禁用你的音頻會話來做到這一點：
無論提供與否，標識會在適宜的情況下允許iOS系統賦予被中斷的應用自動恢復播放它們的音頻的能力。
決定是否應該在一個音頻中斷結束后恢復音頻。你應依據你應用中所提供的音頻體驗來做這一決斷。
當人們使用iOS媒體控制器或輔助控制器(如耳機線控)時，應用要能響應遠程控制。使你的應用能接收來自于你的用戶界面之外的輸入，無論你的應用當前是在前臺還是后臺播放音頻。
應用可以在播放媒體的過程中，通過后臺向支持Airplay的硬件(如Apple TV)發送視頻。這樣的應用可以接收通過遠程控制事件實現的用戶輸入行為，因此用戶可以控制處于后臺運行狀態的應用中的視頻播放。除此之外，這類應用在后臺運行時也能恢復被中斷的音頻。
當一個媒體播放應用在后臺播放音頻或視頻時，尤其需要合理響應媒體遠程控制事件。
當你的應用在后臺運行時，為了滿足與播放媒體特權相關的責任，要確保遵循以下這些原則：
限制你的應用接收遠程控制事件的次數。例如，當你的應用可以幫助用戶閱讀內容、搜索信息或是收聽音頻時，它只有 在用戶處于音頻場景中時才應該接收遠程控制事件。當用戶脫離音頻情境時，你應該放棄接收事件的能力。如果你的應用允許用戶在支持AirPlay的設備上播 放音視頻，它應該在媒體播放期間都可以接收遠程控制事件。遵循這些原則能使用戶在你的應用中處于非媒體情境中時，通過耳機控制獲得另一個應用的媒體體驗。
盡可能地使用系統原生的控件以提供AirPlay支持。當你使用MPMoviePlayerController類實現AirPlay播放功能時，你可以利用標準的控件使用戶可以選擇當前范圍內支持AirPlay的硬件。或者你可以使用MPVolumeView類來顯示用戶可選擇的支持AirPlay的音頻或視頻設備。用戶習慣于這些標準控件的外觀和行為，因此他們可以理解如何在你的應用中使用它們。
不要改變事件的用途，即使這個事件在你的應用中沒有意義。用戶期望iOS系統的所有應用媒體控制和輔助控制能有功能上的統一。你不必實現你的應用所不需要的那些事件，但你所實現的事件必須產生符合用戶期望的結果。如果你重新定義一個事件的意義，你會使用戶困惑并冒險把他們帶入一個未知的狀態，他們只能通過退出你的應用來逃離。
VoiceOver增加了對盲人、弱視用戶以及一些有特定學習困難的用戶的可用性。
![[ISUX譯]iOS 9人機界面指南(三)：iOS 技術 (下)](http://www.mobileui.cn/blog/uploads/2016/01/023254d43.png)
為了確保VocieOver的用戶能使用你的應用，你需要在你的用戶界面中提供一些有關視圖和控件的描述信息。對VoiceOver的支持不需要你改變你用戶界面內的任何視覺設計。
當你完全遵照標準的方式使用標準的用戶界面元素時，幾乎不(即使有也很少)需要增加額外的工作。你的用戶界面越趨向定制化，你就越需要提供更多的信息來保證VoiceOver能準確的描述你的應用。
增加你的iOS應用對VoiceOver用戶的可用性，可以擴大你的用戶基礎并幫助你進入新的市場。支持VoiceOver也可以幫助你遵守由主流群體所制定的可用性指導準則。
地圖可以顯示到達用戶目的地的可選路線：
![[ISUX譯]iOS 9人機界面指南(三)：iOS 技術 (下)](http://www.mobileui.cn/blog/uploads/2016/01/023255DmB.png)
當人們想要獲得關于某條路線的更多交通信息時，地圖也可以顯示能提供路線選擇的應用列表(包括安裝在設備上的應用也包括應用商店中的應用)。
![[ISUX譯]iOS 9人機界面指南(三)：iOS 技術 (下)](http://www.mobileui.cn/blog/uploads/2016/01/023255izH.png)
路線選擇應用可以提供當前選擇的路線有關的信息。人們希望路線選擇應用能夠快捷、易用，特別是保證準確性。依據本章提供的指導原則能幫你為用戶提供他們可信任的交通信息和他們期望的用戶體驗。
重要：地圖能依據人們選擇的路線給他們提供駕車和步行的指示。路線選擇應用可以提供交通信息，它著重于使用交通工具(如公交車、火車、地鐵、渡船、自行車、行人、穿梭巴士等)的模型替代實物逐步地指示方向。
如果你的應用不能提供用戶指定的路線的交通信息，那么不要將你的應用定位為路線選擇應用。
實現你的應用所承諾的功能。當人們在交通列表里看到你的應用時，他們認為它可以幫助其到達目的地。但是如果你的 應用不能提供所選路線的信息，或者它沒能涵蓋它看似應該涵蓋的那些種類的交通信息，人們就不會愿意給它第二次機會。準確的表達出你的應用的能力是十分重要 的；否則，你的應用會看起來像是在故意誤導用戶。
在你的路線選擇應用中，有兩種主要的方式可以給用戶信心：
注意：雖然準確的報告你所支持的地區可能意味著會減少你的應用在交通信息列表里的出現次數，但這么做卻可以幫助用戶更加信任它。
為易用性合理組織界面。易用性對于路線規劃應用來說特別重要，因為用戶常常會在極具挑戰性的情況下使用它們——例如在明亮的陽光下、在昏暗的車廂內抑或是在顛簸的旅程中，或在非常緊急的情況下。要確保你的文字在任何光照條件下都能容易的閱讀，確保按鈕即使在并不平穩的旅程中也能易于準確點擊。
專注于路線。雖然輔助信息會很有用，但你的應用應該專注于為用戶提供逐步的指示以便他們能據此到達目的地。特別要強調的是，你要讓用戶知道他們處于哪一步，并知道如何到達下一步。你可以提供額外的數據(比如時間表或系統地圖)，但不要讓這些數據比交通信息還重要。
為路線的每一步提供信息。永遠不要讓用戶感覺被你的應用所遺棄。即使在可以準確的報道你所支持的地區時，你也不 能假定用戶已經抵達的路線中的第一個交通節點或是最后一個交通節點就是他們目的地點。為了控制這一情況，首先就是測量起點到終點距離。如果距離足夠短，要 提供從用戶當前位置到第一個交通節點及從最后一個交通節點到用戶目的地的步行方向指示。如果步行不是一個合理的選擇，嘗試描繪用戶的其他選項。如果必要的 話，你可以給用戶提供打開地圖，獲取這部分路線的步行或駕車方向指示的方式。
當用戶從地圖應用切回你的應用時，不要要求他們重復輸入信息。如果用戶從地圖應用切入(你的應用)時，你已經獲知了他們中意的起點與終點，因此你可以在應用打開時直接呈現適合的交通信息。如果用戶從主屏幕中開啟你的應用，要為他們提供簡潔的方式用以輸入路線詳情。
顯示圖文并茂的交通信息。地圖頁面可以幫助人們以更大的、實物性的視角查閱他們完整的線路；清晰的步驟可以幫助人們專注于他們抵達目的地所需采取的必要行動。最好可以同時支持這兩個任務并能讓用戶便捷地進行切換。
注意：無論以什么格式，最重要的是顯示與用戶線路相關的相同的交通信息。例如，如果路線中包含五個步驟，在地圖和路線列表頁中必須描繪相同的五步。
當你的應用被從交通列表中選中時，需要以顯示完整的線路做為良好的開始(包括在地圖頁面中顯示始于或抵達交通節點的步行路線)。地圖頁面可以為用戶提供他們旅途的多步驟的總覽，并能展示適于周遭地理環境的路線。
用附加信息豐富地圖頁面。人們期望你的應用中的地圖可以表現的與他們使用過的其他地圖相似。除了用戶能放大和縮小以外，你還應該顯示用戶所需的那些注釋信息。例如，你應該顯示圖釘用以代表用戶當前的位置、目的地以及沿路的轉乘點或重要的節點。
確保避免只顯示一個單獨的圖釘，因為對用戶來說，如果沒有額外的背景，很難理解它代表什么。欲了解在你的應用中使用地圖頁面的更多信息，請參閱Map View.
盡可能地整合靜態地圖頁面，例如在地圖視圖中加入地鐵系統地圖等。一個很好的實現方法就是在地圖頁面覆蓋靜態圖片，以便用戶可以看到他們的路線及他們的當前位置是如何與更大的交通系統相關聯的。
注意：如果你決定讓應用顯示一個靜態的地圖圖片，要確保使用高分辨率的圖片以保證用戶在縮放時維持高質量的顯示。
給用戶提供不同的方案來挑選多樣的交通選擇。很多因素會影響人們交通的選擇，例如不同的時間段，天氣以及他們攜 帶東西的多少，所以提供簡潔的不同交通方式的對比是十分重要的。例如，你要能讓用戶可以依據開始或結束的時間、需要步行的數量、沿途停下的次數抑或轉乘的 次數或所需的不同的交通類型等來挑選交通方式。不管你顯示多種交通選擇的順序如何，確保用戶能立即分辨出這些選項的不同之處。
考慮使用推送通知為人們提供與路線相關的重要信息。盡可能的讓人們了解交通情況信息的變化，以便他們可以據此調 節自己的計劃。例如，如果火車晚點或者巴士路線臨時停滯，人們可能會需要選擇不同的交通路線到達目的地。而在一條不同步驟的站點之間相隔很長距離的交通路 線中，人們會希望在他們的交通工具將要抵達行程中的下一部分時能獲得通知。
用戶能呼出一個編輯菜單來完成諸如在文本視圖、網頁或圖片視圖中的剪切、粘貼以及選擇操作。
![[ISUX譯]iOS 9人機界面指南(三)：iOS 技術 (下)](http://www.mobileui.cn/blog/uploads/2016/01/023346ZvA.png)
你可以通過調整一些菜單的行為使用戶對你應用中的內容有更多的控制權。舉個例子，你可以：
你不能改變菜單本身的顏色和形狀。
欲了解如何在代碼中實現這些行為的相關信息，請參閱Copy, Cut, and Paste Operations.
為了確保編輯菜單在你的應用中的表現符合用戶期望，你應該：
顯示在當前情境下合理的命令。例如，當沒有對象被選擇的時候，菜單中不應該包括復制或剪切(命令)，因為這些命令是針對選擇(的內容)而操作的。相似地，如果有對象被選擇的時候，菜單中不應該包括選擇(命令)。如果你在自定義頁面中支持編輯菜單，你就有責任確保菜單中顯示的命令切合當前的情境。
依據你的頁面布局調節菜單顯示。iOS依據可獲得的空間大小選擇在插入點的上方或下方來放置菜單指針以顯示編輯菜單，這樣用戶就能看到菜單命令是如何與內容相關的。在必要的情況下，你可以通過程序在菜單顯示之前決定它的位置，這樣可以避免用戶界面中的重要信息被遮擋。
支持兩種手勢來調用菜單。雖然點擊和長按手勢是用戶呼起編輯菜單的首選方式，但他們也可以在文本頁面中通過雙擊一個單詞來選擇該單詞并同時呼起菜單。如果你在自定義頁面中支持菜單，確保它能支持兩種手勢。除此之外，你可以定義用戶雙擊時默認的選擇對象。
避免在你的用戶界面中創建和編輯菜單中功能相同的按鈕。例如，使用編輯菜單讓用戶進行復制操作遠比提供一個復制按鈕要好，因為用戶將會想知道為什么在你的應用中會有兩種方法做同樣的事。
如果靜態文本的選擇對用戶來說是有用的，那么可以考慮使用它。用戶可能想要復制圖片的標題，但他們不可能想復制選項卡的標簽或是屏幕的標題，比如“賬戶(Account)”。在文本頁面內，文字的選擇應該是默認設置的。
不要使按鈕標題可選擇。如果按鈕的標題是可選擇的，用戶很難在不激活按鈕的情況下呼出編輯菜單。通常來說，像按鈕這樣操作的元素不需要是可選擇的。
將對撤銷與重做的支持與對復制與粘貼的支持組合到一起。人們經常希望在他們改變主意的時候能撤銷最近的操作。由于編輯菜單在它操作執行的時候是不需要確認的，你應該給用戶提供撤銷或重做這些操作的機會。
如果你需要創建自定義的編輯菜單項，需要像下面展示的這個例子一樣遵循這些指導原則：
![[ISUX譯]iOS 9人機界面指南(三)：iOS 技術 (下)](http://www.mobileui.cn/blog/uploads/2016/01/023346uih.png)
創建直接作用于用戶選擇的包含編輯、修改或其他操作的編輯菜單。人們期望在當前的情境內用標準的編輯菜單項操作文本或對象，那么你的自定義菜單項最好能有相似的表現。
將自定義項列在所有系統提供的項的后面。不要將你的自定義項與系統提供的項混置在一起。
保持自定義菜單項的數量在合理的范圍內。你不應該用太多選擇迷惑你的用戶。
使用簡潔的名稱命名你的自定義菜單項并確保名稱能準確的描述命令的作用。通常，項的名字應該是一個可以描述行為 如何執行的動詞。雖然你通常會使用單個的大寫單詞作為名字，但如果你必須使用一個短語(作為名字)時，就應使用標題式大寫短語。(簡潔的、標題性的大寫詞 就是將除了文章、四字及四字以下的并列連詞與介詞之外的單詞都大寫。)
用戶通過搖晃設備觸發撤銷操作，顯示提醒框讓他們可以：
![[ISUX譯]iOS 9人機界面指南(三)：iOS 技術 (下)](http://www.mobileui.cn/blog/uploads/2016/01/023347Xe1.png)
你可以通過在你的應用中定義出更通用的方式來支持撤銷操作：
欲了解如何用代碼實現這一行為，請參閱Undo Architecture.如果在你的應用中支持撤銷和重做，請遵循以下準則以提供好的用戶體驗:
為用戶提供簡潔的描述性短語使其能準確的獲知他們正在撤銷或重做的內容。iOS系統自動提供了“撤銷”和“重 做”的字符串(包括詞語后面的空格)作為撤銷警示按鈕的標題，但你需要提供一或兩個詞語用于輔助描述用戶的重做或撤銷操作。例如，你可能提供文本的“命 名”或“地址更改”之類的詞語用以創建像“撤銷命名”或“重新更改地址”這樣的按鈕標題。(要注意，在提醒框中，“取消”按鈕是不能改變或移除的)。
![[ISUX譯]iOS 9人機界面指南(三)：iOS 技術 (下)](http://www.mobileui.cn/blog/uploads/2016/01/023347PqB.png)
避免提供的文本過長。太長的按鈕標題容易被斷章取義并且很難被用戶解讀。由于這個文本用于按鈕的標題中的，要使用標題樣式的大寫形式并且不能添加標點。
避免過度使用搖晃手勢。即使你能程式化地設定你的應用將搖晃事件作為用戶激活撤銷操作的途徑，你也在冒著混淆用戶視聽的風險，因為他們也可能使用搖晃執行另一個不同的操作。分析你應用中的人機交互以避免創建那些用戶無法可靠地預測搖晃手勢結果的場景。
如果撤銷和重做在你的應用中是基礎性的任務，盡量使用系統原生的撤銷與重做按鈕。記住搖晃手勢是用戶觸發撤銷與重做操作的主要方式，而如果提供兩種不同方式完成同樣的任務則會使用戶困惑。如果你認為很有必要提供直觀專有的撤銷與重做操作，你可以在導航欄中放置系統原生的按鈕。(欲了解更多關于這些按鈕的信息，參見Toolbar and Navigation Bar Buttons).
將撤銷與重做能力與用戶當下的情境進行清晰地關聯，而非過早地介入情境。仔細考慮你允許進行撤銷與重做操作的情境。通常來說，用戶期望他們的改變和操作可以立即被有效的執行。
在iOS8與之后的系統中，你可以創建自定義的鍵盤擴展內容來替代系統的原生鍵盤。欲了解更多關于管理應用內擴展(包括鍵盤)的信息，請參閱APP Extensions；欲了解如何開發自定義的鍵盤擴展內容的信息，請參閱Custom Keyboard.
在合適的情況下，你9也可以在你的應用內設計自定義的輸入頁面來替代系統原生的屏幕鍵盤。例如，Numbers(譯者注：iWork中的電子表單應用程序)中提供了多種輸入頁面，這些頁面設計使數量、日期和其他值的輸入能簡單地完成。
![[ISUX譯]iOS 9人機界面指南(三)：iOS 技術 (下)](http://www.mobileui.cn/blog/uploads/2016/01/023348vJP.png)
如果你提供自定義輸入頁面，確保它的功能對于來用戶來說是清晰易懂的。
你也可以提供自定義的輸入輔助視圖，這種視圖通常表現為顯示在鍵盤(或你的自定義輸入頁面)上方的一個獨立元素。例如，在某些情境中，Numbers會顯示一個輸入輔助視圖用以幫助用戶執行針對電子表格中的值的標準或自定義計算。
![[ISUX譯]iOS 9人機界面指南(三)：iOS 技術 (下)](http://www.mobileui.cn/blog/uploads/2016/01/023349njn.png){kind=small}
當用戶在你的輸入頁面中敲擊自定義控件時，使用標準的鍵盤敲擊聲提供聲音反饋。欲了解在代碼中如何使用這一聲音，請參閱UIDevice Class Reference中的playInputClick章節
注意：標準的敲擊音效只適用于當前屏幕上的自定義輸入頁面。人們可以在設置-聲音中關閉所有的鍵盤音效(包括你的自定義輸入頁面中的那些)。
本章英文原文訪問地址：iOS Human Interface Guidelines
本章中文翻譯PDF下載：點此下載
感謝你的閱讀，本文出處 騰訊ISUX
藍藍設計( m.qdjdjx.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供有效的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務