1.3D Touch

3D Touch為基于觸摸的交互提供另外一個維度。通過不同的屏幕壓感來觸發多種功能。

首頁屏幕的交互

在系統屏幕上按下支持3D Touch應用的圖標觸發動作菜單，這個菜單可以展示應用定義的通用任務和展示有趣的信息。關于設計指導可參考Home Screen和Widgets

Peek和Pop

Peek讓用戶可以通過3D Touch來預覽項目，例如一個頁面、鏈接或文件。如果要打開項目或查看跟過信息，可再原來基礎上重按來Pop（彈出）出頁面。在某些Peek的菜單中可以通過上劃來顯示相關的操作。

• 通過Peek來提供生動的內容預覽。理想狀態下，Peek提供足夠的信息來表述當前任務，或者幫助用戶是否需要全屏打開這個項目。
• 設計足夠大的Peek視圖。主要為用戶提供足夠的信息來決定是否要查看項目。
• 采用一致的Peek和Pop操作。如果你在一些地方使用這些操作，但另外一些地方沒有使用的話，可能會對用戶造成迷惑，沒有遵循一致性原則。
• 允許每個Peek都Pop出頁面。Pop出的頁面內容應該和Peek展示的內容保持一致。
• 在Peek頁面中避免使用類按鈕元素。因為用戶離開屏幕去點擊按鈕時，Peek就會消失了。
• 不要同時出現Peek和編輯菜單。因為這樣會讓用戶搞清具體的意圖。相關的知道可參考Edit Menus
• 在合適的時候提供操作按鈕。
• 避免提供一個打開Peek項目的操作按鈕，因為用戶可以通過深壓來打開他們正在預覽的項目。
• 不要把Peek作為展示項目操作的唯一方式。因為不是每個設備都支持Peek和Pop，而且有些用戶可能會關掉3D Touch。應該提供其他的方式來觸發這些操作。

2.輔助功能

iOS為視覺缺失、聽覺缺失或其他殘疾的用戶提供可擴展的輔助功能。

• 為圖片、圖標和界面元素提供可供代替的文本。可供代替的文本不會顯示在屏幕上，但可以讓VoiceOver為用戶描述屏幕上的內容。
• 響應輔助中的偏好設置。如果你的應用使用UIKit來實現界面、文本和界面元素的話，應該自動能響應輔助中的偏好設置，例如粗體或更大的字體。
• 測試你的應用對于輔助功能的支持程度。當用戶打開了輔助功能之后，測試下你的應用長什么樣或操作起來怎么樣。
• 包括匹配的字幕和聲音描述。匹配的字幕可以讓失聰人士或聽力障礙者了解對話你餓哦熱那個。而聲音則為視覺缺失的人提供更多的信息。

** 3.聲音**

不管聲音是不是你應用的重要組成部分，你都應該了解用戶對于聲音行為的預期。用戶可以通過音量按鈕、靜音開關、耳機操作和屏幕上的音量滑塊來操作聲音。聲音可以通過內置或外置的揚聲器、耳機萬甚至支持AirPlay或藍牙的設備進行播放。

• 如果需要的話，可以自動調節音量。但不要影響全局的音量。應用內可以自信調節音量來組成印個混合的聲音輸出。
• 允許更改聲音輸出設備。
• 通過系統自帶的音量調節視圖來調節音量。這個視圖是可定制的，包括一個音量控制滑條甚至可以更高聲音的輸出設備。更多實現細節可參考MPVolumeView
• 通過系統聲音服務來處理短聲音和振動。實現細節可參考System Sound Services
• 對聲音進行分類。根據用途、設備聲音的狀態來挑選合適的種類，并加入到聲音隊列中。一般來說，在應用運行的過程中，最好不要改變類型。更多實現細節可參考Audio Session Programming Guide
• 種類包括：Solo ambient、Ambient、Playback、Record、Play and record。
• 一個打斷事件結束后應該恢復聲音的播放狀態。有時當前應用的播放狀態可能會被其他應用打斷。臨時的打斷例如來電。
• 當你的app播放完臨時的聲音時，應該讓其他應用知道。更多實現細節可參考AVFoundation中的AVAudioSessionSetActiveOptionNotifyOthersOnDeactivation
• 只要當必要時才響應聲音控制。用戶可以在應用外控制聲音的播放，例如控制中心或耳機的控制。
• 不要自定義聲音控制的內容。用戶期望聲音控制的行為應該與所有應用保持一致。不要重新定義聲音控制的用途。

** 4.驗證**

只有在涉及重要內容時才向用戶請求驗證，例如定制界面、接入額外的功能、購買內容或者同步數據。如果你的應用需要驗證，應該確保整個過程是快速簡
單。

• 盡可能延遲登錄。如果在用戶還沒做任何事之前就強迫用戶進行登錄，可能會導致用戶流失。應該用戶盡早了解你的商品，當他們決定要購買的時候才要求登錄驗證。
• 解釋驗證的用處以及如何登錄服務。在登錄界面現實友好簡短的描述。另外不是所有用戶都有賬號，確保能告訴用戶如何獲得新賬號和登錄。
• 通過現實合適的鍵盤來減少數據的輸入。

** 5.數據錄入**

• 盡可能地提供選項。采用列表或撥輪取代輸入框
• 盡可能從系統中獲取信息。盡可能降低對用戶輸入的要求。
• 提供合理的默認值。減少用戶數據錄入的過程。
• 收集到指定數據后才允許進行下一步操作。通過按鈕的狀態來標識可用性。
• 動態校驗數據的合法性。在用戶輸入內容之后馬上進行校驗，方便用戶進行修改。
• 必要時才要求輸入內容。
• 使用數據列表提供導航式選擇。通過字母或其他方式排列數據，方便用戶快速找到對應的選項。

** 6.反饋**

注意把握反饋的有效性，關鍵在于用好反饋，而不是濫用反饋
反饋讓用戶了解應用當前在進行什么操作，發現他們接下來可以進行什么操作，以及理解操作的結果。

• 不打擾地地整合狀態和其他類型的反饋到你的界面。
• 避免無必要的警告（框）。合理的使用警告框，不然當應用需要給用戶提醒重要信息時，將會被忽略。

觸覺反饋

• 通知。變體：成功、警告和失敗。用途：指示任務或動作的完成情況，已完成、失敗、警告等。
• 碰撞。變體：輕、中等、重。用途：提供物理的借喻來補充視覺內容。
• 選中。用途：指示出選中項的動態改變。

使用視覺反饋之外的，觸覺或聽覺反饋

• 謹慎使用觸覺反饋。過度使用會削弱有意義反饋的效果。警告框的使用也符合這個規則。
• 一般來說，對用戶發起的操作提供觸覺反饋。
• 不要重新定義反饋的類型。遵循一致性原則。
• 合理地結合視覺效果和觸覺反饋。在動作與結果之間提供兩者更深層次的聯系。動畫切實符合用戶的感受。
• 不要依賴于單一的交流模式。同時使用視覺和聽覺的暗示來確保用戶不會錯過重要信息。多元化觸覺反饋的方式。
• 當視覺反饋阻塞時使用觸覺反饋。
• 開始反饋之前準備一切。觸覺反饋之前需預先準備好系統，否側可能會出現延遲情況，無法與用戶的操作進行關聯。
• 使用觸覺反饋和聲音進行同步。

7.文件處理

應用應該讓用戶在無需思考的情況下就可以進行文件的創作、閱讀、管理等操作。

• 經常保存文件，除非用戶取消或刪除。不要用用戶明確地進行保存，而應該提供固定間隔的自動保存。
• 不要提供創建本地文件的選項。如果可能的話，提供基于文件云存儲服務。
• 提供直觀和圖形瀏覽文件的界面。最好使用跟系統類似的文件管理界面。
• 讓用戶無需離開你的app也可以進行文件預覽。你可以通過Quick Look在自己的應用內預覽Keynote/Numbers/PDFs/圖片等
• 如果可以的話，允許分型文件到其他app。可通過Document provider extension分享自己的文件到其他應用。可通過其他應用來打開文件，參考這里

** 8.首次加載的體驗**

設計一個快速、有趣和教育性的啟動頁。

• 提供啟動頁。應該給用戶留有印象——應用是快速和熱情的，應該盡快地進入到應用的首頁。Launch Screen
• 在合適的方向上加載。為不同的旋轉方向提供不同的啟動界面方案。更多可參考Layout
• 快速進入到操作界面。避免讓用戶等待太久。
• 預料到可能需要的幫助。當暫停或角色創建過程中，不時為用戶提供有用的建議。讓用戶可以回放整個過程去檢閱他們第一次漏掉的信息。
• 輔導中提供必要的說明。最重要的是讓你的應用符合用戶直覺的認識。如果需要太多的引導，那么應該重新審視下你的應用設計。
• 讓學習變得有趣和可被發現。做一些有趣和高效的事情比閱讀輸入要有效。通過動畫和互動來逐步教育用戶。
• 避免要求用戶提供安裝信息。用戶可以通過設置來滿足他們的需求。可以考慮從iCloud中同步過來。如果真有必要讓用戶選擇，應該在首次加載時詢問用戶，并可以在設置中進行修改。
• 必要在應用內顯示許可證明和免責聲明。應該在應用下載之前就在AppStore中顯示。
• 重啟應用時應該恢復之前的數據。不要讓用戶一步步操作回到之前的位置。恢復到用戶離開應用時的狀態。
• 不用過于快或頻繁地要求用戶去評價應用。不要強迫用戶去評價你的應用。
• 不要鼓勵重啟應用。

** 9.手勢**

用戶希望在系統和每個應用中使用一直的手勢。遵循一致性原則

• Tap: 觸發一個控制或選擇一個項目
• Drag:將一個元素從一邊移動到另一邊，或者在屏幕上拖拽一個元素
• Flick：滾動或快速的Pan
• Swipe: 一只手橫劃出現操作菜單，或者在ipad上四只手同時滑動切換應用。
• Double tap: 縮放和居中內容或圖片，或者還原。
• Pin: 雙指張開放大，合攏縮小。
• Touch and hold: 在文本輸入框中通過放大鏡顯示鼠標的位置。
• Shake: 開始撤銷或重做。

原則：

• 作為一般原則，使用標準的手勢。游戲或沉浸式引用使用自定義手勢可以增加樂趣。而其他應用應該使用標準的手勢。
• 不要阻塞系統級手勢。例如呼出控制中心或通知中心。
• 避免使用標準手勢來觸發非標準的操作。濫用會妨礙用戶的理解。
• 提供更便捷的手勢來補充，而不是取代，基于界面的導航和動作。如從屏幕邊緣橫劃可以返回上一頁，或者在iPad上通過四指聚攏手勢回到系統界面。
• 使用多指手勢來增加某些app的體驗。不一定適合所有app。不過在類似游戲中可以通過多指操作提供更為方便的操作。

10.加載

當內容加載的時候，空白或靜態的頁面會讓應用看起來像是凍結，會讓用戶感到迷惑甚至離開應用。

• 加載時候要更加清晰地現實出來。至少提供活動標識來告訴事情正在發生。更好的方式是，提供明確的進度條告訴用戶還需要等待多久。
• 利用加載時間來教育用戶或提供有趣的內容。可以考慮提供操作提示、視頻或者有趣的圖畫。
• 定制加載頁面。通過自定義的動畫或元素來給用戶更好的體驗，不過前提是要匹配你的應用。
• 盡可能顯示內容。不要再界面顯示出來前就加載數據，相反應該馬上顯示界面，然后通過文本、圖像、動畫來告訴用戶內容正在加載。

可參考Progress Indicators

** 11.模態**

模態視圖會停止用戶當前做的事情，除非他們完成任務。Action sheets、alerts、activity view 提供了模態的使用。模態視圖可以覆蓋屏幕一部分或全部。

原則：

• 盡可能少的使用模態視圖。用戶更愿意非線性地操作應用。盡可能在非常有必要的時候使用模態視圖，例如需要用戶關注某系信息、必須完成某個任務、或者保存重要的數據。注意平衡
• 提供明顯和安全的方式退出模態任務。確保用戶了解取消模態視圖的結果。把重要信息用用戶可以接受的方式傳到給他，首要注意的是不要濫用
• 讓模態任務盡可能地簡單、簡短和聚焦。模態視圖可以讓用戶無需記住原路返回的路徑。除了完成任務外，避免使用Done按鈕。
• 如果可以的話，通過標題來闡述當前任務。你也可以通過文本來進行更詳細的描述。
• 保留警告（框）用于傳達重要和具有爭議的信息。讓用戶感覺通過警告框打擾他們是合適的。參考Alerts
• 服從通知的偏好。用戶通過系統的設置里面來統一管理接收的通知。
• 不要在popover視圖上現實模態視圖。更正確的做法是關掉popover視圖后再顯示模態視圖。
• 讓模態視圖跟你的應用協調一致。如采用一致的導航欄結構。
• 選擇一種合適的模態樣式：
  • 全屏：承載相對復雜的任務。
  • 頁面（Page sheet）：一般用于在較大設備橫屏的情況中，例如iPad。用于處理相對復雜的任務。
  • 表格（Form sheet）：屏幕居中顯示。但要確保鍵盤出現后依然可用。一般用于手機用戶信息。
  • 當前上下文：覆蓋父視圖
• 選擇合適的切換效果來展示模態視圖。在應用內對模態視圖采用一致的切換方式。更多實現可參考UIViewController、UIPresentationController

12.導航

導航應該是自然和熟悉的。但不要讓用戶脫離內容本身。

有三種導航的類型

• 層級導航。每屏做出一個選擇，知道你到達目的地。系統中的設置和郵件就是采用這種導航類型的。
• 平級導航。在多個內容目錄下進行切換。Music和AppStore就是采用這種導航類型的。
• 內容驅動或實例驅動導航。內容自由的切換，內容本省定義自己的導航。游戲、書籍和其他沉浸式應用采用這種導航類型。
  一些應用會綜合使用多種導航類型，例如在平級導航中的每個內容使用層級導航。

原則：

• 總是提供清晰的路徑。應該讓用戶知道當前在應用的什么位置，以及如何到達目的地。讓用戶覺得是可控的。不管采用什么樣的導航類型，重要的是要符合邏輯、可預知和容易理解。一般來說，每個頁面提供給用戶一種路徑。如果需要提供多種內容，可考慮通過Action Sheets、Alerts、Popovers和Modality來承載。
  • 設計的信息結構可以快速和容易到底用戶想要的內容。這樣的信息結構要求盡可能少的點擊、滑動和屏幕的切換。
  • 使用觸摸手勢來時得操作更加流暢。
  • 使用標準的導航元素。遵循一致性原則。根本原因在于降低用戶的學習門檻。除非能提供更好的體驗就另當別論。
  • 通過導航欄來承載層級結構的數據。詳細的說明參考Navigation Bars
  • 通過Tab bar來承載不同內容或功能的目錄。Tab bar可以讓用戶在不同內容之前進行快速切換。詳細的說明參考Tab Bars
  • 當你需要多個頁面來承載相同類型的內容時，使用Page Control。系統內的天氣app就是通過page control來現實不同地方的天氣情況。詳細的說明可參考Page Controls

注意：Segmented Controls和Toolbars沒法使用導航。可以使用Segmented control來組織不同類型的信息。可以使用Toolbar來對當前內容提供不同的交互操作。

** 13.向用戶請求許可**

授權之后應用才能獲取到用戶的私人信息，包括當前的位置、日歷、聯系人信息、提醒和照片.
詢問的內容包括：是否接收通知、是否使用數據、使用定位功能許可等。

• 只有當你的應用確實需要時才向用戶要求個人數據。例如當使用到位置跟蹤功能時才詢問用戶。
• 如果沒有明顯標記在哪里使用的話，解釋為什么需要這些信息。盡量以簡短和友好的方式。
• 當需要用到時，在加載過程中詢問許可。
• 不要就非必要的情況下，詢問位置許可。接入位置服務時線檢查系統地位置服務是否可用。盡可能延遲對用戶的請求和警告。關于定位的實現可參考Location and Maps Programming Guide

** 14.設置 **

成功的app都是對用戶友好的同事，提供更方便的方式去調整內容。當你設計的應用符合大多數用戶的預期，可以減少對設置的依賴。

• 通過系統來獲取你想要的信息。當涉及到用戶、設備、環境等信息時應通過系統來獲取這些信息而不是詢問用戶。
• 仔細考慮設置選項的優先級。首頁可以放置經常改變的選項。二級頁面可以放偶爾變化的選項。
• 如果合適的話，提供具體的路徑來設置。通過按鈕自動跳轉到相應的位置。可參考Settings Launch URL和UIApplication
• 在設置里面放置不常變化的選項。參考Implementing an iOS Settings Bundle在Preference and Setting Programming Guide

** 15.術語**

• 使用熟悉的，可理解的單詞和句子。避免使用縮略詞或技術術語。
• 保持界面上的文本清晰簡潔。
• 避免使用類似第一人稱的寫法。避免使用我、我們、我們的工作等。
• 爭取使用輕松友好的基調。可以偶爾使用下你或你們來稱呼用戶。
• 小心地使用幽默手法。幽默在不同文化中的效果可能不一致，要謹慎使用。
• 使用關聯和一致的語法和意境。使用與平臺一致的語言，避免在iPad上現實iPhone的字樣。
• 準確地引用日期。一般來說日期應該反映不同的時區。
• 辨認出交互元素。用戶應該可以快速的了解到元素是干什么用的。對按鈕等交互元素進行命名時，使用動詞，例如聯系、發送、增加等。

** 16.撤銷和重做**

很多應用允許用戶通過搖一搖設備來進行撤銷或重做的操作。

• 簡單明了地描述撤銷和重做操作。文本里面應該描述哪些內容被撤銷或重做。可以通過“撤銷XXX”來進行描述。
• 如果你使用搖動手勢來進行撤銷和重做，那避免使用這個手勢來進行其他操作。雖然該你可以為一個搖動的手勢提供多種用途，當你可能會造成用戶的迷惑。
• 節儉地提供撤銷和重做阿牛。提供多種方式來處理同樣的操作可能會迷惑用戶。
• 只在當前上下文提供撤銷和重做的操作。應該針對的是當前的內容，而不是其他。

實現的細節可參考Undo Architecture