編者按：iOS 10人機界面設計指南中文版也來了！今天第二部分是交互部分，包括16個小節，從最新的3D Touch到身份驗證、加載、導航等等細節都有細致入微的教學，感謝譯者@喵大神經 ，一起來學習。
往期回顧：《UI設計師必讀的IOS 10人機界面設計指南 （一）》

英文好的同學可以直接到這學習：https://developer.apple.com。

2. 交互（Interaction）
2.1 3D 觸摸（3D Touch）
2.1.1 主屏幕交互（Home Screen Interaction）
2.1.2 輕壓（Peek）和重壓（Pop）
2.1.3 Live Photos
2.2 輔助功能（Accessibility）
2.3 音頻（Audio）
2.4 身份驗證（Authentication）
2.5 數據輸入（Data Entry）
2.6 反饋（Feedback）
2.7 文件處理（File Handling）
2.8 啟動初體驗（First Launch Experience）
2.9 手勢（Gestures）
2.10 加載（Loading）
2.11 模態（Modality）
2.12 導航（Navigation）
2.13 請求許可（Requesting Permission）
2.14 設置（Settings）
2.15 用辭（Terminology）
2.16 撤銷和重做（Undo and Redo）

2.1 3D 觸摸（3D Touch）

3D Touch 為觸碰式交互增加了一個維度。在支持3D Touch 的設備上，用戶通過對觸摸屏施加不同的力度來實現更多的功能，譬如觸發菜單、顯示更多的內容或是播放動畫。用戶無需學習新的手勢來使用3D Touch。當他們輕壓屏幕并且獲得應答的時候就能立即發現這一新的交互維度。

2.1.1 主屏幕交互（Home Screen Interaction）

在支持3D Touch的設備的主屏按壓應用圖標會觸發相應的操作視圖。該視圖讓你能夠快速地執行常用的應用任務和預覽有趣的信息，譬如日歷應用，它能夠提供創建新事件的快捷操作，同時顯示日程表上的下一個事件。了解相關設計指導，請參閱Home Screen Action和Widgets。

2.1.2 輕壓（Peek）和重壓（Pop）

輕壓允許用戶使用3D Touch在當前環境上預覽一個臨時視圖內的對象，譬如一個頁面、鏈接或者文件。要想在支持該功能的設備上實現預覽，只需用手指對應用施加一點壓力，而抬起手指就能退出預覽。要想打開對象來瀏覽更多的內容，請更重地按壓屏幕直到對象放大到填滿屏幕。在一些輕壓視圖上，你可以通過上滑來顯示相應的操作按鈕。譬如，在Safari打開了某個鏈接的輕壓視圖時，你可以通過上滑展開相應的操作按鈕——打開鏈接，添加至閱讀列表和復制鏈接。

1467626118946457.png

理想情況下，輕壓視圖為該項提供足夠的信息以補充說明當前任務，或者幫助你決定是否完全地打開該項。例如，預覽郵件（Mail）信息中的鏈接，從而決定是否在Safari瀏覽器中打開或者分享給朋友。輕壓視圖一般被利用于表單視圖中,提供一個行項的詳細信息，從而決定是否選擇該項。

設計足夠大的輕壓視圖

設計一個足夠大的輕壓視圖從而保證手指不會遮擋到內容。確保輕壓視圖能夠提供足夠詳細的信息，以便用戶決定是否按地更重來完全地打開該項。

統一使用輕壓和重壓功能

如果你只在某些地方使用輕壓和重壓，而不在另一些地方使用，用戶就不會知道到底哪里可以使用這個功能，而且可能會認為你的應用或是他們的設備出了問題。

允許每個輕壓視圖都能夠被重壓

雖然輕按視圖能夠提供給用戶他們所需的大部分信息，但如果他們想離開當前任務并轉移注意力至該項時，應該允許他們過渡到重壓。

避免在輕壓視圖中呈現按鈕式元素

如果用戶抬起手指去點擊類似按鈕的元素，輕壓就會消失。

1467626148575920.png

當一個項目同時啟用兩個功能時，不但會讓用戶感到困惑，也會讓系統難以判斷用戶目的。了解更多指導，請參閱Edit Menus。

適當時提供操作按鈕

不是每個一輕壓都需要操作按鈕，但這是一個為常用任務提供快捷操作的好方式。如果你的應用已經為項目提供了自定義的點擊并長按（touch-and-hold）動作，那么最好在輕壓里包含同樣的操作。

避免為打開被輕壓的項目提供操作按鈕

用戶一般都通過更重的按壓來打開他們輕壓的項目。所以，沒有必要再提供一個明顯的打開按鈕。

不要讓輕壓成為唯一的執行項目操作的操作

并不是所有設備都支持輕壓和重壓，甚至有的用戶會關閉3D觸摸功能。你的應用為這些情況考慮其它觸發項目操作的方式。譬如，你的應用可以將輕壓的快捷操作映射到一個視圖中，該視圖會在點擊和長按時出現。

2.1.3 Live Photos

應用可以通過支持Live Photos，并在照片中加入壓感用來查看動態回憶。當你按壓它們時，Live Photos死而復生，通過動作和聲音再現拍照的前后時刻。了解相關設計指導，請參閱Live Photos。

2.2 輔助功能（Accessibility）

iOS 提供了大量的輔助功能來幫助失明、失聰以及其他殘疾群體。大部分以UIKit為基礎的應用能夠輕易地具有輔助性，讓更多的用戶來使用你的應用，因為你為所大眾提供了平等的使用體驗。

為圖片、圖標和界面元素提供可選擇的文字標簽

可選擇的文字標簽在屏幕上是不可見的，但是他們讓VoiceOver能夠通過聲音描述屏幕上有什么，讓失明用戶能夠輕易地使用導航。

相應輔助功能的偏好設置

如果你的應用使用UIKit來實現用戶界面，文字、界面元素就會自動調整至相應輔助功能的偏好設置，譬如加粗并且更大的文字。你的應用也應當在適當的時候檢查并相應輔助功能的偏好設置，譬如當減弱動態效果（reduce motion）的開關被打開時。采用自定義字體的應用應該力圖和系統字體的輔助特性保持一致。

測試應用的輔助功能

除了文字和動態效果的變化，輔助功能選項還能改變對比度，反轉顏色，降低透明度以及更多。為那些需要這些功能的用戶啟用設置并觀察你的應用將會變成什么樣并且如何運作。

包含隱藏式字幕和口述影像

隱藏式字母幫助失聰以及重聽用戶明白視頻中的對話和其它音頻內容。口述影像為視覺受損的用戶提供了關鍵視頻內容的口頭解說。
了解更多信息，請查閱iOS Accessibilty和Accessibility Programming Guide for iOS。

2.3 音頻（Audio）

無論聲音是你應用體驗的要素或只是一個點綴，你都應該知道用戶對聲音有什么要求并且滿足他們的期待。
用戶通過音量鍵、靜音鍵、耳機聲控和屏幕上的音量調節滑塊控制聲音。非常多的第三方配件也包含聲控功能。音頻可以通過內部和外部的揚聲器、耳機輸出，甚至通過支持AirPlay或是藍牙設備無線輸出。
靜音：用戶將他們的設備調節至靜音來避免被意外的聲音（比如電話鈴聲和短信提示聲）打擾。他們也想要關閉沒有意義的聲音，包括按鍵聲、音效、游戲配樂以及其它音頻反饋。當設備被設置成靜音，只能出現被明確被打開的聲音，比如媒體播放中的聲音、鬧鈴和音頻/視頻信息。
音量：無論是使用物理的設備按鍵或是屏幕上的滑塊，用戶都希望系統的所有音量都能夠被改變，包括音樂聲和應用內的音效。但是鈴聲音量是唯一例外，它只能在沒有任何聲音播放的情況下被單獨調節。
耳機：用戶使用耳機來私密地聽聲音并且能夠釋放他們的雙手。當用戶插入耳機時，他們希望聲音能夠自動繼續播放而不被打斷。當拔掉耳機時，他們希望播放能夠立即停止。

必要時自動調節不同層級的聲音，但不是整體音量

為了達到更好的混合音效，你的應用可以單獨調節不同層級音頻間的相對音量。但是，最終的音量輸出應該由系統音量決定。

恰當的時候允許音頻重選路由（rerouting）

用戶會經常想要選擇一個不同的音頻輸出設備。比如，他們會想要通過客廳的立體音響、車載收音機或是蘋果電視來聽音樂。請支持這個功能除非你有令人信服的理由不這么做。

使用系統提供的音量視圖來調節音量

音量視圖（volume view）是最好的能提供調節音量的界面控件。這個視圖是自定義的，包含一個音量調節滑塊，甚至包含一個用來替音頻輸出重選路由的控件。了解實現方法，請參閱MPVolumeView Class Reference。

短音和振動請使用系統聲音服務

了解實現方法，請參閱System Sound Services Reference。

如果聲音對你的應用十分重要請設置音頻類別

不同的音頻類別允許聲音被靜音按鈕靜音、與其它聲音混響、或是當你的應用在后臺時播放。根據類別的含義和當前設備的音頻播放情況來選擇一個類別，然后將其分配給你音頻對話（audio sessions）。比如，非必要情況下，請不要打斷用戶正在收聽的來自其它應用的音樂。總的來說，盡量不要在你的應用運行時更改所屬的音頻類別，除非應用需要經常地錄制然后播放音頻。了解實現方法，請參閱Audio Session Programming Guide。

在適當時候繼續播放被干擾打斷的音頻

正在播放的音頻有時會受來自其它應用的聲音干擾。暫時性干擾（比如來電鈴聲）被認為是可恢復的。永久性干擾（比如被Siri打開的播放列表）被視為不可恢復的。當一個可恢復的干擾出現時，你的應用應該在干擾結束時恢復音頻播放（假設音頻在干擾出現之前就已經開始播放了）。比如，一個在播放配樂的游戲和一個在播放音頻的媒體應用都應該恢復聲音的播放。當干擾發生時應用沒有在播放任何音頻，那么它也就不需要恢復任何對象。

1467626323596138.jpg

如果你的應用可能會暫時性地干擾到其它應用的音頻，那么就應該恰當地標明聲音片段，從而讓其它應用知道確切的恢復時間。了解實現方法，請參閱AVFoundation Framework Reference中的AVAudioSessionSetActiveOptionNotifyOthersOnDeactivation。
只有在有意義時才對聲音控件作出反應

無論你的應用在前臺還是后臺，用戶都能夠通過應用界面以外的東西控制音頻的播放，比如在控制中心（Control Center）中，或者耳機聲控。如果你的應用正在一個明確與聲音相關的環境下播放音頻，或是連接到一個支持AirPlay的設備上，那么對聲音控件作出反應是合理的。但是，你的應用不應該混淆其它應用的音頻，因為它們可能會在控件被激活時播放。

不要重新定義聲音控件

用戶希望聲音控制在任何應用都保持一致性。永遠不要重新定義聲音控件。如果你的應用不支持某些控件，那么只需不對它們作出反應即可。

2.4 身份驗證（Authentication）

要求用戶進行身份驗證時應該用有價值的東西交換，比如個人化體驗、獲得更多功能、購買內容或者同步數據。如果你的應用要求身份驗證，請保證登陸流程快速簡單并且低調，這樣就不會減少應用的樂趣。

盡可能地延后登陸

用戶經常遺棄應用因為他們在做一些有用的事前被強制登陸。在強制用戶前給他們一個愛上你的應用的機會。在購物應用內，允許用戶啟動應用后能馬上瀏覽你的商品，然后在他們決定購買時才要求登陸。在流媒體應用內，允許用戶先探索和了解你能夠提供的內容，然后在他們播放時讓他們登陸。

解釋身份認證的優勢以及如何注冊

如果你的應用要求身份認證，在登陸界面簡要友好地介紹之所以要登陸的原因及其優勢。并且請牢記不是每個人在開始使用應用時都擁有一個賬號。請確認你解釋了如何得到賬號，或者提供一個簡單的應用內的注冊方式。

展示適合的鍵盤來減少數據輸入

比如，當要求填寫一個郵箱地址時，請展示包含信息輸入所需快捷鍵的郵件鍵盤窗口。

2.5 數據輸入（Data Entry）

無論是點擊界面元素還是使用鍵盤，信息輸入都是一個冗長的流程。當一個應用在做一些有用的事情前要求用戶一連串的輸入，進而拖慢了流程，那么用戶會很快感到失望，甚至會徹底地拋棄這個應用。

1467626408370756.png

1467626414288975.png

盡可能地提高信息輸入的效率。比如，考慮使用選擇器或是列表來替代輸入欄，因為從一列提前設定好的選項中選擇一個比打字容易。

可能時從系統中獲取信息

不要強迫用戶提供那些可以自動或是在用戶許可內就能獲取的信息，比如聯系人或是日歷信息。

提供可靠的默認值

盡可能地預填最可能的信息值。提供一個可靠的默認值縮短了做決定的時間從而加快了流程。

只有在收集完必需信息之后才能進行下一步

在允許“下一步”或“繼續”按鈕前，確保所有必要的輸入框都有信息。盡可能地在用戶輸入之后就立馬檢查輸入值，這樣他們就能立即改正。

只要求必要的信息

只有系統運行真正必需的信息才使用必填欄。

簡化值列表的導航

尤其是在列表和選擇器中，必需能夠簡單地選擇值。考慮通過將值列表按首字母排序或是其它邏輯排列，從而加快瀏覽和選擇的速度。

在輸入欄顯示提示以輔助說明

當輸入欄沒有其它文字時，可以包含占位符文字——比如“郵件”或“密碼”。當占位符文字已經足夠說明時不要再單獨使用標簽來描述。

2.6 反饋（Feedback）

反饋讓用戶知道應用現在在做什么，發現下一步他們應該做什么，并且理解操作的結果。

1467626441151640.png

悄悄地在你的界面中加入狀態或其它類型的反饋

理想中，用戶能夠在不采取任何操作或是被打擾的情況下得到重要的信息。比如，當用戶在郵件應用中查看郵時，狀態信息被巧妙顯示在工具欄上。這個信息不會和屏幕上的主要內容搶風頭，但是用戶在任何時候快速一瞥就能查看。

避免不必要的警告

警告是一種有威力的反饋機制，所以它應該只被用于傳遞重要的并且最好是需要操作的信息。如果用戶看到太多包含無關緊要信息的警告框，他們很快就會學會忽略之后的警告。了解更多幫助，請參閱Alerts。
2.7 文件處理（File Handling）
用戶在創建、查看和操作文件時無需思考文件系統。如果你的應用需要運行文件時，盡可能地淡化文件處理。

1467626458583323.png

讓用戶相信除非主動取消或刪除

文件會隨時被保存。總而言之，不要讓用戶去即時保存文件。反之，在文件被打開、關閉，或是跳轉至其它應用時，應該自動定時地替用戶保存文件。但在某些情況，比如正在編輯一個已被創建的文件時，保存和取消的選項也是有意義的，因為它們幫助確認何時編輯的內容應該被保存。

不要提供創建本地文件的選項

用戶總是希望他們全部的文件都能在任何設備上讀取。如果可能，你的應用應該支持文件云儲存，比如通過與iCloud類似的服務。

設計一個直觀并且圖像化的文件瀏覽界面

理想情況下，使用用戶熟悉的系統文檔選擇器來瀏覽文件。如果你想設計一個自定義的文件瀏覽器，請確保它是直觀且高效的。最好的文件瀏覽器應該是高度圖像化的，提供了文檔的視覺再現。要想加快導航速度，減少手勢的使用，并且考慮提供一個添加新文件的按鈕，這樣用戶就無需再到其它地方去創建新文檔。

讓用戶在你的應用內就能預覽文件

你可以使用Quick Look 功能讓用戶查看來自Keynote、Numbers和Pages的內容，以及PDF文檔、圖片以及某些其它格式的文件，即使你的應用并沒有真正打開它們。請參閱Quick Look。

合適時，與其它應用共享文件

如果有意義，你的應用可以通過document provider extension與其它應用共享文件。你的應用也可以讓用戶瀏覽和打開來自其它應用的文件。了解實現方法，請查閱Document Picker Programming Guide。

2.8 啟動初體驗（First Launch Experience）

應用的啟動時間是你接觸新用戶并與老用戶再次連接的第一個時機。請設計一個快速、有趣并有教育意義的啟動體驗。

提供啟動畫面

啟動畫面在應用打開時出現，在加載應用初始內容的同時，讓人感覺你的應用的響應速度很快。因為這個畫面很快就會被應用的首屏替代，所以它應該盡量與首屏相似，除非出現可定位的文字和可交互的元素。了解更多，請參閱Launch Screen。

選擇合適的方向啟動

如果你的應用同時支持豎屏和橫屏模式，那么應該以設備目前的方向啟動。如果你的應用只在一個方向運行，那它只能在相同方向啟動并在需要時允許用戶旋轉設備。除非有迫不得已的原因，否則處于橫屏模式的應用正確地選擇方向，無論Home鍵是在左側還是右側。了解更多信息，請參閱Layout。
快速使用。避免出現延遲用戶使用應用時間的啟動畫面、菜單和說明。反之，允許用戶快速進入應用內。如果你的應用需要教學或是介紹步驟，為用戶提供一個跳過的選項并且不要對老用戶展示這些。

提前設想用戶可能會需要的幫助

經常主動地考慮用戶何時會遇到麻煩。比如，一個游戲，能夠在暫停或是角色很難升級時提供一些訣竅。當用戶錯過啟動畫面的內容時，允許他們之后重新觀看教程。

只在教程中展示最關鍵的內容

雖然為新用戶提供引導沒錯，但是教學不能成為優秀的應用設計的代替品。更重要的是，確保你的應用是直觀的。如果你的應用需要過多的引導，那么請重新審視你的設計。

讓學習變得有趣而且易于學習

通過操作來學習比閱讀一長串說明來的更有趣和有效。 在上下文環境中，通過動畫和可交互性循序漸進地教導。避免展示看起來似乎可交互的屏幕截圖。

避免在最開始要求用戶設置信息

用戶期待應用馬上工作。為大多數人設計你的應用，然后讓余下少部分需要不同配置的人自己調整參數來滿足他們的需求。盡可能地，從設備設置和默認中或許設置信息，或者通過同步服務，比如iCloud。如果應用一定要求設置信息，那么在最初在應用內提示用戶，然后允許用戶稍后在應用設置中修改。

避免展示應用內的接受許可協議和免責聲明

在你的應用被下載之前直接在蘋果商店展示接受許可協議和免責聲明。如果你必須將這些東西放在你的應用里，那么以和諧融入它們，以避免干擾用戶體驗。

在你的應用重新啟動時恢復之前的狀態

不要讓用戶重新操作來回到之前的應用定位。保存并且復原應用的狀態，這樣用戶就能從他們上次離開的位置繼續。

不要太快或是太頻繁地要求用戶對你的應用評分

太快或是太頻繁地要求評分會讓用戶惱怒，并且減少最終收到的有用反饋的數量。為了鼓勵考慮周到的反饋，在要求評分之前，給用戶足夠的時間直到他們形成對應用的看法。總是提供跳出評分提示的選項，并且永遠都不要強迫用戶對你的應用評分。

不要鼓勵重啟

重新啟動耗費時間并且讓你的應用看起來即不可靠又不可用。如果你的應用出現儲存或者其它問題，導致它無法運行只能系統重啟，那么你應該解決這些問題。

2.9 手勢（Gestures）

用戶通過在觸摸屏上使用手勢來與iOS設備交互。這些手勢表現了一種親密的人與內容之間的聯系，并且加強了對屏幕上對象直接的操作感。用戶普遍地希望一下的標準手勢能夠在操作系統和每一個應用內保持一致。
點擊（Tap）：激活一個控件或者選擇一個對象。

拖曳（Drag）：讓一個元素從一邊移動到另一邊，或者在屏幕內拖動元素。

滑動（Flick）：快速滾動或是平移

橫掃（Swipe）：單指以返回上一頁，呼出分屏視圖控制器（split view controller）中的隱藏視圖，滑出列表行中的刪除按鈕，或在輕壓中呼出操作列表。在iPad中四指操作用來在應用間切換。

雙擊（Double tap）：放大并居中內容或圖片，或者縮小已放大過的。

捏合（Pinch）：向外張開時放大，向內捏合時縮小。

長按（Touch and hold）：在可編輯或者可選文本中操作，顯示放大視圖用以光標定位。在某些與集合視圖類似的視圖中操作，進入對象可編輯的狀態。

搖晃（Shake）：撤銷或重做

一般使用標準手勢

用戶已熟悉了標準手勢，并不喜歡在做相同事情時被強迫去學習不同的方式。在游戲等沉浸式體驗的應用中，自定義的手勢能夠成為體驗的有趣要素。但是在其它應用中，最好使用標準手勢，這樣用戶就無需花費多余的力氣去學習和記憶它們。

不要禁止系統性的手勢

除了標準手勢，還有一些手勢會觸發系統性的操作，譬如呼出控制中心或是通知中心。在每個應用中，用戶都依賴使用這些手勢。

避免使用標準手勢來執行非標準的操作

除非你的應用時一個極具可玩性的游戲，否則重新定義標準手勢會變得混論和復雜。

為基于界面的導航和操作提供補充性的快捷手勢，而不是取而代之

可能時，提供簡單明顯的方式來導航或是執行操作，即使它可能意味著額外的點擊。非常多的系統應用包含一個提供了清晰可點的返回上一頁的按鈕的導航欄。但是用戶也能通過在屏幕邊緣右滑來返回。在iPad，用戶能夠點擊Home鍵退出到主屏幕，或是使用四指捏合的手勢。

使用多指手勢來加強某些應用的體驗

雖然涉及多個手指同時操作的手勢不適用于每一個應用，但是他們能夠豐富一些應用的體驗，譬如游戲和繪畫應用。比如，一個游戲可能包含多種屏幕上的控件，比如同時操作的的控制桿和發射鍵。

2.10 加載（Loading）

當內容在加載時，一片空白靜止的屏幕好像應用被凍住了，讓人感到困惑和失望，而且很可能讓用戶離開你的應用。

明確加載的狀態

至少，展示一個活動旋轉器（activity spinner）來表明有任務在進行中。更勝一籌的是，顯示明確的進度，這樣用戶就能知道他們還需等待多久。

通過教育或娛樂用戶來填充加載的時間

嘗試展示游戲訣竅、令人愉悅的視頻序列或者有趣的占位圖。

自定義加載畫面

盡管標準的活動指示器還不錯，但他們有時會感覺是脫離上下文環境的。嘗試設計符合你的應用或游戲的自定義動畫和元素，以實現一個更沉浸式的體驗。

盡快顯示內容

不要讓用戶在看到屏幕畫面前去等待內容的加載。立馬顯示屏幕畫面，然后通過占位符、圖片或者動畫明確告知用戶哪個范圍的內容還未顯示。當內容加載成功之后再把占位元素替代掉。可能時，比如當動畫在播放時或是用戶在某個層級或菜單導航時，在后臺預加載接下來要出現的內容。
了解更多指導，請參閱Progress Indicators。

2.11 模態（Modality）

模態突出焦點，因為用戶只有在完成當前的任務或關閉一個信息或視圖之后才能去做其它事情。操作列表、警告框和活動視圖都提供了模態化的體驗。當屏幕上出現一個模態視圖時，用戶必須采取一個決定（點擊按鈕或是其它）才能退出模態化體驗。在日歷（Calendar）中編輯事件或是在Safari瀏覽器中選擇書簽都是模態視圖在應用中被采用的例子。一個模態視圖可以占據整個屏幕、整個父視圖（比如浮出層）或者屏幕的一部分。一個模態視圖一般都含有“完成”和“取消”按鈕來退出視圖。

1467626658524842.png

△ 警告框

1467626673358978.png

減少模態的使用

一般來說，用戶更喜歡與應用進行非線性的交互。只在必須要引起用戶注意時、某個任務必須被完成或是確認關閉時，或保存重要數據時才考慮使用模態視圖。

提供一個明顯并可靠的退出模態任務的方式

確保用戶總是知道他們關閉一個模態視圖將導致的結果。

保持模態任務簡單、簡短并且高度集中

不要在你的應用中創建一另一個應用。如果一個模態任務太過復雜，用戶在進入模態視圖時就會看不到視他們本想執行的任務。當創建一個包含多層級視圖的模態任務時請格外謹慎，因為用戶可能會在多個視圖中迷失并不知道如何返回。如果一個模態任務必須含有次視圖，那么請提供單級的跳轉路徑以及清楚的完成路徑。除非完成任務否則不要使用標有“完成”的按鈕。

如果合適的話，請使用能夠明確說明任務的標題

你也可能在視圖的其它部分提供詳細描述任務的文字或是提供指導。

只有在傳達關鍵以及需要操作的信息時才使用警告框

警告框干擾體驗，并且需要單擊才能關閉，所以必須要讓用戶認為這個打斷是有理由的。了解更多，請參閱Alerts。

尊重用戶的通知偏好設置

在設置里，用戶明確規定了他們想要如何地接受來自你應用的通知。遵循這些個人偏好，這樣他們就不會想要完全地關閉來自你應用的通知推送。

不要讓模態視圖蓋在在浮出層上

除了警告框，任何元素都不應該覆蓋在浮出層之上。在極少數情況下，你需要讓模態視圖在用戶完成浮出層內的任務之后彈出，那么請先關閉浮出層再展示模態視圖。

讓模態視圖的視覺風格與你的應用相符

一個模態視圖可能包含一個導航欄。在這種情況下，請使用與你應用內的導航欄一樣的視覺風格。

選擇合適的模態視圖樣式

你可以使用到以下任何一種樣式：

1467626724900137.jpg

為展示模態視圖選擇一個合適的過渡方式

使用與應用風格相符的過渡方式來加強用戶對當前內容轉變的認知。默認的過渡方式讓模態視圖垂直地從屏幕底部向上滑出，然后在被關閉時下滑。彈出樣式的過渡是指當前視圖水平滑出，顯示出模態視圖，看起來就好像模態視圖藏在當前視圖的背后。當模態視圖被關閉時，原先的視圖便重新滑回來。在你的應用內容部使用統一的模態過渡方式。
了解更多模態視圖的實現方法，請參閱UIViewController Class Reference和UIPresentationController Class Reference。

2.12 導航（Navigation）

用戶往往意識不到一個應用的導航，除非它沒有達到他們的預期。你的工作就是實現一種能夠支持應用結構和目的的導航，并且讓人們注意到到導航的存在。導航應該讓人覺得自然和熟悉，并且不應該主導界面或者搶走內容的風頭。在iOS，主要有三種導航結構。

分層導航：

在每屏都做一次選擇，直到你到達目標位置。要想到達另外的目標位置，你必須原路返回一些層級或是從頭開始重新選擇。原生應用設置（Settings）和郵件（Mail）就是采用這種導航結構。

1467626807587326.png

扁平導航：

在不同的內容類別間切換。原生應用音樂（Music）和App Store就是采用這種導航結構。

1467626815968094.png

內容驅動或是體驗驅動式導航：

在內容中自由地轉換，或是內容定義導航。游戲、閱讀以及其它沉浸式應用一般都采用這種導航結構。

1467626823871011.png

有的應用結合了多種導航形式。比如，采用了扁平導航的應用也可能在每個類別之內使用層級導航。

總是提供清晰的路徑

用戶應該一直知道他在應用的什么位置以及如何去往下一個目標位置。除了要有清楚的導航形式，還應該確保對象間的路徑是合理的、符合預期的并且容追溯的。一般來說，為用戶提供到達某一屏的唯一路徑。如果他們需要在非常多的情景下看到某一屏幕的內容，那么考慮采用操作列表、警告框、浮出層或是模態視圖的形式展示這些內容。了解更多內容，請參閱Action Sheets,Alerts,Popovers和Modality。

設計一個能夠快速簡單地訪問內容的信息結構

合理地組織你的信息結構，保證它只用最少次數的點擊、橫掃和屏幕間跳轉就能訪問相應的內容。

使用觸摸手勢來制造流暢感

讓用戶能輕松地在界面內跳轉，而感受不到阻力。比如，你可以讓用戶在屏幕邊界右滑，而返回到上一屏。

使用標準的導航組件

可能時，使用標準的導航控件比如頁面控件、標簽欄、分段控件、表格視圖、集合視圖和拆分視圖。用戶已經熟悉了這些控件，他們很自然地就知道如何玩轉你的應用。

使用****導航欄訪問分層內容

導航欄內的標題欄能夠說明當前的層級位置，使用返回按鈕能夠輕易地回到上一個位置。了解更多指導，請參閱Navigation Bars。

使用標簽欄來展示內容或功能相似的類別

標簽欄讓用戶能夠快速簡單地在類別中切換自如，而不受當前位置的限制。了解更多指導，請參閱Tab Bars。

使用多頁面展示同類型的內容時請使用頁面控件

頁面控件能夠清楚地表示總頁數，以及當前頁的位置。天氣（Weather）應用就使用了頁面控件來表示不同地理位置的天氣頁面。了解更多指導，請參閱Page Controls。
TIP
分段控件和工具欄不具備導航功能。使用分段控件能夠組織信息放入不同的類別。使用工具欄為當前內容提供交互控件。了解這些元素的更多信息，請參閱Segmented Controls和Toolbars。

2.13 請求許可（Requesting Permission）

1467627029752473.png

用戶必須對應用予以授權，應用才能獲取用戶的個人信息，比如當前位置、日歷、聯系人信息、提醒事項以及照片。雖然用戶在使用獲得這些信息的應用時會感到方便，但是他們還是希望能夠控制自己的私人數據。比如，用戶希望為他們的照片自動標上當前的地理位置，或是尋找附近的朋友，但是他們又同時希望能有關閉這些功能的選項。

只在應用真的需要時才向用戶請求獲得個人數據

用戶會質疑個人信息的請求是很自然的，尤其是他們發現當前的請求沒有明顯的必要時。確保允許請求只在用戶真的在使用某些需要個人數據的功能時才出現。比如，一個應用只有在激活一個位置跟蹤的功能時才請求獲得當前的位置。

當需求不明顯時向用戶解釋為什么你的應用需要這些信息

你可以在系統提供的允許請求警告框上添加自定義的文本。使用明確且有禮貌的文本，這樣用戶就不會感到有壓力。使用簡短文本，并且使用句子。沒有必要包含你的應用名字。系統已經替你在警告框上說明了應用的名字。

在應用一啟動時就請求允許那些對運行你的應用至關重要的信息

如果用戶明確地知道你的應用只有獲得這些個人信息才能運行，那么他們就不會反感。

不必要時不要請求位置信息

在獲得位置信息之前，檢查系統以查看位置服務是否已經被打開。使用這個知識，可以延遲提醒，直到使用需要該信息的功能時才進行提醒，甚至可能完全避免提醒。
學習如何實現定位功能，請參閱Location and Maps Programming Guide。

2.14 設置（Settings）

有一部分的應用可能需要一開始就讓用戶決定設置或布局選項，但是大部分應用避免或是延遲這么做。成功的應用能夠一開始就讓用戶很好地使用，并且同時提供了一個便捷的途徑去調整體驗。當你的應用被設計成滿足大部分用戶的需求，你就可以減少他們對對設置的需要。

推斷你可以從系統中得到什么

如果你需要關于用戶、設備或是環境的信息，那么盡可能地向系統請求而不是直接詢問用戶。比如，如果你想要知道用戶的郵編來提供本地的選項時，可以向用戶請求獲取他們的當前位置。

在你的應用中對配置選項的優先排序深思熟慮

應用的主屏是一個放置關鍵或是常用選項的絕佳位置。次屏則適合放置只偶爾才更改的選項。

把不經常更改的配置選項放到系統設置里

系統的設置（Settings）應用是更改系統配置的核心地帶，但是用戶必須離開的應用才能到達那里。因此在你的應用中直接調節設置更加方便。如果你的應用必須提供很少改動的設置選項，請參閱Preferences and Settings Programming Guide中的Implementing an iOS Settings Bundle 部分。

適當時提供去設置的快捷路徑

如果你的應用包含引導用戶去設置的文本，比如“去設置>我的應用>隱私>定位服務”，請提供一個能夠自動打開該界面的按鈕。了解如果實現這個行為，請參閱UIApplication Class Reference中的Settings Launch URL部分。

2.15 用辭（Terminology）

每一個在應用中的文字都是與用戶對話的一部分。利用好這個對方讓用戶在你的應用中感到自在舒適。

使用熟悉易懂的單詞和短語

科技可以讓人感到害怕。避免使用用戶可能不理解的或是技術術語。根據你對用戶的了解來決定哪些單詞和短語是合適的。總的來說，能夠吸引每個人的應用是不應包含深奧的技術語言的。這類語言比較適合針對高端或是技術用戶的應用。

保持界面文本的清晰和簡潔

用戶能夠快速且輕易地理解短而直接的文本，他們不喜歡在完成任務時被強迫去閱讀很長的文本。找到最重要的信息，簡潔地陳述它，然后突出地展示它，這樣用戶就不需要為了知道他們在找什么或是下一步該做什么而閱讀太多信息。

避免使用讓人聽起來很傲慢的語言

避免使用“我們”，“我們的”和“我的”（比如“我們的教程”和“我的鍛煉”）等字段。他們有時候被理解為無禮或是傲慢的。

盡量使用日常且友好的語氣

一個日常親近的風格就類似你在和別人吃午飯時聊天的語氣。偶爾使用簡寫，并使用“你”和“你的”來直接與用戶對話。

請謹慎使用幽默

記得用戶可能會多次閱讀你界面上的文字，而那些第一次看起來很俏皮的文字可能在多看幾次之后會顯得惱人。同樣記住在一種文化中的幽默方式可能并不適用于其它文化。

使用相關且一致的語言和圖像

確保引導在當前環境中總是合適的。如果某人在使用iPad，那么久不要給他展示與iPhone相關的文字和圖片。根據平臺選擇使用相符的語言。你在觸摸屏上點擊、滑動、橫掃、捏合或者拖曳對象。你按壓物理按鈕，或者按壓對3D觸摸作出反應的對象。你旋轉和搖晃設備。

提供精確的日期

使用今天、明天這類友好的詞語是合理的，但是如果你沒有詳細說明當前的位置，那么這些詞語就會令人困惑或是顯得不夠精確。請考慮一個在午夜12點前發生的事件。在某個時區，這個事件可能發生在今天。但是在另一個時區，同樣的事件可能在昨天就已經發生了。總而言之，日期應該體現出正在查看事件的用戶所在的時區。然而，在某些情況下，比如一個跟蹤航班狀態的應用內，明確地顯示起飛地區的日期和時區才更加清楚。

恰當地指出可交互的元素

用戶應該瞥一眼就能知道這個元素是什么用的。當給按鈕或是其它可交互元素標記時，使用操作動詞，比如連接、發送和添加。

2.16 撤銷和重做（Undo and Redo）

很多的應用都允許用戶通過搖晃設備來撤銷或是重做某個操作，比如打字或是刪除。當該撤銷和重做通過搖晃被觸發時，會出現一個提示框，詢問用戶是要撤銷（重做）操作還是什么都不執行。

1467627176468232.png

簡明扼要地描述將要被撤銷或是重做的操作

撤銷和重做的提示框標題會自動地包含“撤銷”或是“重做”這樣的前綴（以及后面的空格）。你需要在前綴后面提供額外的一兩個詞語用來形容什么會被撤銷或是重做。比如，你可以創建一個提示框標題叫做“撤銷命名”或者“重做地址更改”。

如果你已經把搖晃手勢用來撤銷和重做，那么就不要把它用于其它操作

即使你能通過編程賦予搖晃手勢不同的意義，但同時你也冒著很大的風險使用戶困惑，并讓你的應用變得不可預知。

節制地使用撤銷和重做按鈕

如果在應用中為執行相同任務提供多種途徑便會讓人困惑。如果你的應用真的需要專門的撤銷和重做按鈕，那么請使用系統提供的標準按鈕并且把它們放在一個符合預期的位置，比如導航欄。

只在當前情境中執行撤銷和重做操作

撤銷和重做必須對當前的（而非之前的）情境有明確直接的影響。
了解更多實現方法，請參閱Undo Architecture。