騰訊力作！超實用的iOS 9人機介面指南（3）：iOS 技術 (上)

騰訊力作系列：

1. 《騰訊力作！超實用的IOS 9人機介面指南（1）：UI設計基礎》
2. 《騰訊力作！超實用的IOS 9人機介面指南（2）：設計策略》
3. 《騰訊力作！超實用的iOS 9人機介面指南（3）：iOS 技術 (上)》
4. 《騰訊力作！超實用的iOS 9人機介面指南（3）：iOS 技術 (下)》
5. 《騰訊力作！超實用的iOS 9人機介面指南（4）：UI元素》
6. 《騰訊力作！超實用的iOS 9人機介面指南（5）：圖示與圖形設計》

文章索引

• 3.1 3D觸控(3D Touch)
• 3.1.1 輕壓和重壓(Peek and Pop)
• 3.1.2 主螢幕快捷操作(Home Screen Quick Actions)
• 3.2 Live Photos
• 3.3 錢包(Wallet)
• 3.4 蘋果的移動支付平臺(Apple Pay)
• 3.5 研究型應用程式(Research Apps)
• 3.6 應用擴充套件(App Extensions)
• 3.6.1 今天部件(Today Widgets)
• 3.6.2 分享和動作擴充套件(Share and Action Extensions)
• 3.6.3 圖片編輯擴充套件(Photo Editing Extensions)
• 3.6.4 文件提供者擴充套件(Document Provider Extensions)
• 3.6.5 自定義輸入法(Custom Keyboards)
• 3.7 HomeKit
• 3.8 多工處理(Multitasking)
• 3.9 通知(Notifications)
• 3.10 社交媒體(Social Media)
• 3.11 iCloud

譯者注：本文譯自蘋果官方人機介面指南 iOS Human Interface Guidelines (2015年10 月21日)，由騰訊ISUX設計師翻譯整理，非發 文者一人之作。譯文首發於ISUX部落格，如在閱讀過程中發現錯誤與疏漏之處，歡迎不吝指出。後續章節會陸續更新，敬請期待。

3.1 3D觸控(3D Touch)

3D Touch 給 iOS 9 使用者提供了一個新的互動維度。在所支援3DTouch的裝置上，人們可以通過按壓應用的圖示去快速選擇應用定製的操作。在應用內，人們可以使用多種按壓操作去獲取一個專案的預覽，可以在獨立的檢視裡開啟一個項獲取相關操作。（瞭解更多在你的程式碼中如何新增3D Touch支援，參閱 Adopting 3D Touch on iPhone .）

3.1.1 輕壓和重壓(Peek and Pop)

輕壓讓使用者可以在不離開他們當前環境的情況下預覽一個項和執行相關操作。支援輕壓的該項會在輕壓後給出一個小矩形檢視作為反饋。

在Safari中的一個輕壓檢視：

在Safari輕壓中的快速操作：

輕壓(Peek)：

• 當使用者按壓在一個支援輕壓的項上時出現輕壓，使用者手指抬起後會消失
• 當使用者在輕壓檢視下再更加重一點的按壓稱之為重壓，重壓可以檢視該項的詳細檢視
• 當使用者在輕壓檢視中向上滑動，可以提供與該項相關的快速操作

當使用者輕輕按壓在螢幕，支援輕壓的這個項會展示一個你提供的矩形檢視，示意可以進行下一步互動操作。那個檢視應該夠大，這樣才能讓使用者手指不會混淆內容，這個檢視應該足夠細節，這樣可以讓使用者選擇是否去更加重一點按壓從而轉換到輕壓檢視。

重要

你在應用中始終如一提供輕壓和重壓的體驗是至關重要的。如果你在有些地方支援輕壓和重壓，在某些地方不支援，使用者有可能認為你的應用或者他們的裝置出現了問題。

使用輕壓去為該項提供一個生動的，內容豐富的預覽。

當輕壓能夠給使用者提供關於該項的足夠資訊，從而幫助他們擴充套件當前的任務，這樣做是最好的。例如，在使用者決定好是在Safari中開啟資訊中的網頁還是分享這個連結給朋友之前，使用者可以使用輕壓預覽資訊中URL的頁面。在表單檢視中，輕壓可以給使用者提供一個行項的詳細內容。

為每個輕壓提供重壓。

雖然一個輕壓可以提供給使用者所需要的大部分資訊，但是你應該可以讓使用者過渡到重壓，從而讓使用者放開當前正在進行的任務，轉移專注力到該項上來。重壓的內容應該與使用者點選該項後的內容一致。

不要為同樣一個項授予輕壓和編輯選單(Edit menu)兩個功能。

當同一個項的這兩個功能都啟用的時會很混亂。(獲取更多編輯選單資訊，參看 Edit Menu.)

在輕壓操作裡，避免展現類似按鈕的介面元素。

如果使用者抬起手指去點選像按鈕的元素，輕壓會消失。

如果可能，提供輕壓快捷操作。

在輕壓裡，使用者可以向上滑動去顯示該項的相關操作。例如，Mail裡的輕壓快捷操作包括回覆全部，轉發和刪除資訊。並不是每個輕壓都需要快捷操作，但是如果你已經為該項提供定製的點選並長按的操作，那麼最好在輕壓裡提供相同的操作從而替代點選並長按操作。(注意在網頁檢視中，輕壓快速操作是自動提供的。)

不要將輕壓作為唯一開啟該項的指定操作的方式。

不是每一個裝置都支援輕壓和重壓，一些使用者可能選擇關掉3D Touch, 因此在你的應用中去尋找其他方式實現輕壓的功能是非常重要的。當你的應用在較舊的裝置上執行時，可以把輕壓的快捷操作對映到一個檢視裡，讓使用者通過點選並長按獲得。

3.1.2 主螢幕快捷操作(Home Screen Quick Actions)

主螢幕快捷操作可以在主螢幕給使用者呈現方便的、有用的、應用特定的操作。

Camara的主螢幕快捷操作

Mail的主螢幕快捷操作

主螢幕快捷操作：

• 當使用者在主螢幕採用比點選且長按更重的按壓，按壓在應用圖片上時，出現螢幕快捷操作
• 它會顯示一個你提供的短標題，一個圖示和可選的副標題
• 它不支援其他定製的內容
• 它可以隨著你應用的更新，更新顯示的資訊

使用主螢幕快捷操作去開啟引人注目的、高價值的任務。

例如，Maps可以讓使用者不需要開啟Maps，通過在當前位置附近搜尋就可以獲得回家的方向。一個應用至少需要把一個有用的任務放在主螢幕快捷操作裡；你可以提供最多四個快捷操作。

避免使用主螢幕快捷操作去減少應用裡導航的內容。

如果使用者訪問你應用的重要區域非常困難和耗時，那麼首先去修改你的應用的導航，這樣做是可以讓所有使用者都獲益的。接著，可以去為有用的深層次連結提供主螢幕快捷操作，從而開啟這些有用的、創造性的任務。

不要把主螢幕快捷操作作為通知使用者的一種方式。

iOS使用者期望以其他方式接收應用中的資訊(更多資訊參看 Notifications)。

為主屏快捷操作提供一個簡潔的標題(可有副標題)和一個模板的圖示。

標題應該直接傳達這個操作的結果；例如，“回家的方向”，“新建聯絡人”，和“新建資訊”。你也可以提供一個副標題給使用者更多上下文資訊。例如，Mail使用一個副標題在主屏快捷操作的重要位置去告訴使用者有未讀資訊。 不要把你的應用名字或者無關的資訊放在標題和副標題裡，同時要考慮到使用本地化的用語。

保持標題的簡潔不會被切斷從而幫助使用者快速理解操作是非常重要的。如果你提供的副標題一行顯示不全，系統會截斷；如果你沒有副標題，系統會把一行展示不完全的長標題以兩行展現。

你可以從很多系統提供的模板圖示中選擇圖示，你也可以創作定製的模板圖示。更多關於圖示尺寸、內邊距和定位的詳細引導資訊，可以下載主屏快速操圖示模板 https://developer.apple.com/design/downloads/Quick-Action-Guides.zip。更多關於設計模板圖示的資訊，參看Template Icons。

系統會自動安排圖示在快速操作列表中的位置是在左側或者在右側，這依賴於你的應用的圖示在使用者主螢幕的位置。(摒除圖示在列表中的位置，在自左向右的語言中文字總是左對齊。)這裡有主屏快捷操作的多種展現方式的例子。

3.2 Live Photos

Live Photos 讓使用者在豐富的聲音和動作環境下，捕捉和再現他們喜愛的回憶。從iOS 9開始，相機(Camera)應用可以捕捉附加的內容(拍照之前和結束後的聲音和額外的畫面)為傳統的、靜止的圖片增加生活氣息。

在iOS9.1及之後的版本中，你的應用可以讓使用者享受和分享Live Photos。這個指引可以幫助你給使用者提供更好的體驗。

在不支援Live Photo的環境中，把Live Photo像傳統照片一樣展示。

不要在支援Live Photos的環境中，自定一種與Live Photo相似的體驗。

不要分開展現Live Photo的附加畫面和聲音。

要讓使用者在不同的應用中體驗Live Photos時，有一致的視覺呈現和互動方式。把Live Photo拆分開展現是一個很壞的體驗。

確保使用者可以區分Live Photo 和傳統靜止圖片。

在使用者分享照片時，幫助他們做好區分是特別重要的。最好在使用者檢視一個LivePhoto的時候，展現一點移動作為提示。萬一這個提示沒有起到作用，你可以在LivePhoto上展示一個系統提供的標記。LivePhoto不要展現一個像視訊裡回放按鈕的介面元素。

注意，上圖這種情況，不支援像照片應用裡全屏瀏覽滑動切換照片時的顯示的。

把使用者所做的調整應用到Live Photo的所有幀中。

如果你的應用可以讓使用者為照片新增濾鏡或者調整，應確保它可以作用於整個LivePhoto中。如果你不支援調整使用者想分享的LivePhoto的所有內容，要讓他們知道可以以傳統照片的方式分享。 讓使用者在決定分享前，可以預覽這個Live Photo的所有內容。如果你的應用UI可以讓使用者選擇照片分享，要為他們提供一個把Live Photo作為傳統照片分享的方式。 如果你使用系統提供的標記，應該把它放在每個LivePhoto上同樣的位置。標記可以放在一個不會影響使用者檢視照片的角落。確保在你的應用中採用一致的方式新增標記，這樣可以讓使用者依靠它去識別LivePhoto。iOS有兩種方式提供標記：

• 覆蓋。這種覆蓋的方式包含一個陰影，適合覆蓋在照片上
• 純色。這種純色的方式(無陰影)可以被用來建立一個可調色的圖片模板
• iOS也提供了很多純色標記，其中，圖片上一個刪除線代表現在的LivePhoto被當做是一個傳統的照片

在使用者下載一個Live Photo的時候給他們一個好的體驗。

尤其重要的是，使用者需要知道他們正在下載的是一個LivePhoto，他們需要知道什麼時候可以播放它。如果你為一個Live Photo展示一個未播放的進度指示器，確保這個指示器與你的應用中其他的下載體驗一致。

3.3 錢包(Wallet)

Wallet應用是幫助使用者檢視和管理各種數字化票券的，他們是一些物理個體的數字展現，例如登機牌、優惠券、會員卡、獎勵卡和各種票。Wallet也可以讓人們新增他們的信用卡、借記卡和儲值卡結合Apple Pay使用。你可以在應用中建立一個票券，分發給使用者，並且在有更改時進行更新。

使用PassKit框架可以方便地用自定義內容來收集一個票券和使使用者票券庫中的票券。(想要學習Passbook技術的核心概念和PassKit介面的使用方法，請參考Passbook Programming Guide。)以下幾點可以幫助你建立一個使用者樂意保留並使用的票券。

設計一個在各個裝置上呈現很好票券。當你選擇一個票券的樣式——比如登機牌，優惠券，票據，獎勵卡或者通用的票券——你會獲得一個特別的佈局和一系列區域去處理(更加詳細關於不同票券的樣式，參看Pass Style Sets the Overall Visual Appearance)。這個系統在各個裝置上合理展示你的票券，所以正確使用票券的區域是非常重要的。例如，在Apple Watch上，條狀圖(strip)和縮圖(thumbnail)圖片是不顯示的，所以你不希望把基本的資訊放到這些元素裡。更多Apple Watch票券的佈局，參看 Designing Passes for Apple Watch.

使用合適的票券區域展現文字。在你的票券中使用允許VoiceOver的使用者獲取票券中的所有資訊的區域，保持你的票券外觀的一致性。避免將文字嵌入圖片或使用自定義的字型也是一個很好的方法，因為不是所有的圖示會展示到所有的裝置上，這樣對使用者來說閱讀這樣的文字會有困難。

避免使用識別一個裝置的語言。

你不能預料到哪些使用者將會檢視你的票據的裝置，因此你不想使用可能在一個特別裝置上不起作用的語言。比如，文字告訴使用者“滑動去檢視”內容，當這個發生在Apple Watch上將會不起作用。

儘可能，不要只是簡單複製已有的物理票券。

Wallet 已經建立了有美感的設計，票券也都配合這種設計以看起來更好。所以不要只是複製物理票券的外觀，抓住這次機會設計一個符合Wallet 組成和功能的乾淨簡潔的票券樣式。

對放在票券正面的資訊精挑細選。

使用者期望掃一眼票券就能快速獲得他們需要的資訊，所以票券正面的資訊應該是整潔且易讀的。如果有使用者可能會需要的額外資訊，將它們放到票券的背面要比擠在正面好得多。注意，Apple Watch上的票券沒有背面。

通常情況下，避免使用純白色背景。

通常，一個好看的票券應該使用鮮豔的純色背景或者使用強烈的，充滿活力的圖片作為背景。當然，在設計背景時還要確保內容的可讀性。

在商標文字區域顯示你的公司名稱。

所有票券的商標文字區域的文字都使用了統一的字型。為了避免和其他票券發生衝突，還是建議您在商標文字區域輸入文字，不要使用自定義字型。

使用白色的公司商標。

商標圖片放置在票券左上角公司名稱的旁邊。最好提供一個白色的，單色的，不包含文字的商標。如果你想要增強商標的效果，又想要與文字風格匹配的話，可以增加一個在y軸方向上有1畫素偏移，有1畫素模糊和透明度為35%的黑色陰影效果。

如果可以的話，使用矩形的條形碼。

類似於PDF417這樣的長方形條形碼比正方形二維碼更適合票券的佈局。如下右圖所示，正方形的二維碼會使兩邊有空白區域並且會在垂直方向上使上下方內容變得擁擠。

為效能去優化圖片。

因為使用者通常會通過電子郵件或者Safari接收票券，所以讓下載的越快越好是非常重要的。為了提高使用者體驗，使用能滿足視覺效果的最小的圖片檔案。

在合適的時候更新票券以增強其效用。

即使一個票券代表的是一個並不會改變的物理實體，數字的票券也可以通過對映真實世界的一些事件來提供更好的使用者體驗。例如，當某個航班延誤時你可以更新登機牌上的資訊，這樣使用者就能夠通過檢視電子登機牌來獲得當前的資訊。

3.4 蘋果的移動支付平臺(Apple Pay)

Apple Pay是蘋果公司面向iOS移動裝置推出的一種簡單、安全、個人的移動支付方式。當使用者在購買實體商品和服務時時，可以使用Apple Pay快速、安全地提供個人聯絡方式、收貨地址以及付款資訊。

通過用Apple Pay支付，使用者無需每次購物都要建立賬號或填一遍個人資訊。Apple Pay顯著加快了支付流程，有助於消除前期的各種資訊登記，進而為使用者的“無障礙”選購過程提供更好的體驗。欲瞭解更多資訊，請參閱 Apple Pay Programming Guide. Apple Pay的使用者介面非常清晰、簡潔高效、低調。它包含三個介面元素，各出現在不同的上下文情境中。

按鈕

Apple Pay的按鈕用來告訴使用者，他們可以在當前的情境下(比如商品頁面)完成購買。當使用者點選了Apple Pay的按鈕，立即顯示支付上拉選單(見下文) 開始幫助使用者完成支付流程。使用者通過“設定Apple Pay”的選項Apple Pay的相關銀行卡資訊繫結操作。通過呼叫PKPaymentButton API口可以找到這兩個按鈕(想要了解更多資訊，請查閱PKPaymentButton Class Reference)。有關使用Apple Pay支付按鈕的更多詳情，請參閱Identity Guidelines.

Apple Pay支付標識

當使用者需要在授權支付之前選擇付款方式並敲定其他資訊時，他們期望看到Apple Pay的支付標識。Apple Pay的支付標識應該同其他付款方式以相同或類似的格式顯示。

支付上拉選單。

在使用者提交訂單以及完成相關支付之前，Apple Pay會顯示一個包含了聯絡方式、收貨地址以及與結賬相關付款資訊的支付上拉選單。儘管使用者依然可以在支付上拉選單裡做些微調，比如選擇不同的送貨方式，但他們不用做出重大改變或輸入其他資訊。當使用者看到該支付上拉選單，他們應該能夠立即完成交易並授權付款。

對於可以使用Apple Pay付費的使用者，Apple Pay的使用者介面應當始終顯示。

如果使用者的移動裝置支援Apple Pay，並且他們已經啟用了相關可用的銀行卡因此可以通過將Apple Pay設為預設支付方式來滿足使用者的期望。

如果使用者無法使用Apple Pay服務，就不要顯示任何Apple Pay的使用者介面。

如果使用者使用的裝置不支援Apple Pay，仍強行將其作為一個支付方式選項，可能會對使用者造成混淆。但是，如果使用者使用的裝置是支援Apple Pay，但沒有繫結任何信用卡或借記卡，你可以在介面中顯示“設定Apple Pay”的按鈕。

當使用者點選了Apple Pay的按鈕，立即顯示支付上拉選單。

當使用者決定使用Apple Pay來結賬時，如果還要迫使使用者經歷額外步驟，會使支付流程顯得複雜，增加不必要的矛盾，並可能會讓使用者感到沮喪受挫。當使用者點選了Apple Pay按鈕，不要顯示其他警告或模態對話方塊檢視。如果使用者可以提供像打折或促銷程式碼之類的資訊，請在使用者點選Apple Pay按鈕之前找到一種方式來接收該資訊。

Apple Pay按鈕與其他可見的支付按鈕應保持相同的尺寸大小或更大。

將Apple Pay按鈕放置在醒目的位置，可以幫助使用者輕鬆找到它。

使用Handoff功能幫助使用者完成在Apple Watch上發起的購買。

Apple Watch佩戴者可以在商店完成支付，但他們無法完成由Apple Watch第三方應用程式呼叫的支付行為。當Apple Watch佩戴者發起了由第三方應用程式呼叫的支付行為，則顯示一條訊息告訴他們請在iPhone上完成支付。為了更好的使用者體驗，還可以使用Handoff功能深層連結到你的iOS應用程式上，並立即顯示包含預設好的相應付款資訊的支付上拉選單。

有關使用Apple Pay支付按鈕以及Apple Pay支付標識的更多資訊指南，請參閱 Apple Pay Identity Guidelines.

3.4.1 自定義支付上拉選單 (Customizing the Payment Sheet)

根據完成交易付款所需要了解的資訊，以及所要傳達給使用者關於本次購物的資訊，來自定義Apple Pay支付上拉選單所要顯示的內容。

支付上拉選單僅顯示對完成交易付款有必要的資訊。

如果Apple Pay支付上拉選單顯示了些無關的資訊，使用者可能會感到困惑或焦慮。舉個例子，如果商品是線上交付或通過電子方式完成，需要聯絡人的電子郵件地址是有意義的，而不是收貨地址。在這種情況下，要求收貨地址可能給使用者產生會有什麼東西將意外被派件到家中或公司的錯覺，或許還可能導致他們對個人隱私被訪問產生不必要的擔憂。

支付上拉選單允許使用者可以選擇更換送件或取件方式。

使用者可以從你在支付上拉選單中設定的幾種交付方式中隨意選擇一種。通過用文字標籤控制元件、報價以及可選的第二行預計到達日期，來具體描述一種收貨方式。另外，你還可以設定交付方式為“派件”或“取件”，讓使用者指定一個可接收快遞送貨上門或需要運輸服務取件的位置。

使用並排項來描述週期性付款和一些購買費用的小計。

並排項包含了一個標籤文字和花費數值。並排項被用來：

• 表明使用者授權一個定期付款專案，比如“每月訂閱 $19.99”
• 告知使用者關於額外費用，比如“禮品包裝 $5.00”和“稅費 $4.53”
• 顯示優惠券或折扣資訊帶來的減價，比如“週五特價 -$2.00”
• 描述某個專案需要按實際計費，比如運輸服務“時間&距離 …”

不要用並排項來顯示所要購買的商品的構成清單。

建立並排項標籤時，儘可能顯示在同一行。

並排項標籤應該具體、容易理解。如果行條目標籤字元數過長，那麼很難讓你的使用者一看就懂。

商戶名稱需要緊緊跟隨在同一行的“Pay”字元後面作為一個整體。

確保所使用的商戶名稱以及相應的開銷支出，必須與使用者檢查自己的信用卡或銀行對賬單時的資料保持一致。這一點很重要，因為它有助於使用者確信他們的開銷支出是無誤的。如果你的應用程式只是作為中間媒介，而不是最終的商戶支付，請明確向使用者表明這個具體說明“付款給 最終的商戶名稱（通過你的應用程式名稱）。

如果總價花費在支付授權時還不明確，請向使用者傳達有可能會有額外費用的資訊。

舉個例子，一次汽車旅程從支付授權時刻起到駛向最終目的地，它的開銷報價可能會受行車距離或時間的影響變化。或者，一個客戶可能想要給點小費在商品已派件之後。對於這樣的情況，在支付上拉選單中給予一個非常明確的解釋說明是很有必要的。當你使用一個並排項來配置最終總價的更新資訊時，總價金額會自動顯示為“總價待定”。另外，如果你是預授權支付一個具體金額的訂單，確保支付上拉選單準確地反映了這一資訊。

3.4.2 簡化結賬流程(Streamlining the Checkout Process)

Apple Pay使得購物變得快速、簡單，對此人們會欣然接受的。更少的步驟和更少的需要使用者手動輸入的資訊，使得整個結賬流程更好。

始終使用Apple Pay的最新資料資訊。

假設使用者一直保持Apple Pay個人資訊的完整性和時刻更新，那麼不要依賴於任何先前收集的資訊。即使你以前已收集過使用者的聯絡方式、交付方式和支付資訊，也要在結賬時獲取來自Apple Pay的最新資訊。在結賬環節，儘量避免使用者輸入本可以從Apple Pay獲取的任何資訊。

使用Apple Pay加快購買。

對於單個商品專案的購買，讓使用者只需通過點選商品頁面上的Apple Pay支付按鈕，即可顯示支付上拉選單並進行即時結算。購買單個商品時，無需採取額外的步驟，也無需將商品新增到購物車，使用者喜歡在應用程式中體驗到這種便利性。對於多個商品被新增到購物車中會使用相同的交付方式被送到相同地址的情況，一旦使用者有意向支付時，會通過顯示支付上拉選單的快速結賬流程來支援。

在顯示支付上拉選單前需提前收集好贖回程式碼或促銷程式碼。

因為在Apple Pay支付上拉選單中沒有辦法輸入這些程式碼，請務必在顯示支付上拉選單之前收集好相關程式碼。

如果人們可以將購買的商品派送到不同地方，或以不同的速度發貨，請在顯示支付上拉選單之前提前收集好該資訊。

對於這種極端情況，你需要在顯示支付上拉選單之前得到發貨資訊，因為在支付上拉選單中沒有辦法來指定多種交付方式和地址。一般情況下，在支付上拉選單中務必收集到交付方式和地址資訊。

顯示訂單確認頁面或致謝頁面。

在交易完成時，通過使用訂單確認頁，以這種直接的使用者體驗來顯示關於商品能派送到的預計時間以及使用者如何跟進訂單狀態的資訊。

如果合適的話，請在你的訂單確認頁上提到Apple Pay。

儘管在你的確認頁面上提到Apple Pay不是必要的，如果你願意選，可以使用其中的一種格式：

• “Visa 1234（Apple Pay）”
• “用Apple Pay已完成付款”

3.5 研究型應用程式（Research Apps）

研究型應用程式可以讓蘋果使用者充分利用iOS移動裝置的便利性，參與到各種研究性學習中來。通過呼叫開原始碼ResearchKit，使用預設的幾種介面檢視和轉場動畫，可以很輕易為你的研究和參與者自定義一個美觀易用的研究型應用程式，這些資源都可以在蘋果的開原始碼ResearchKit專案中呼叫。要想了解如何使用ResearchKit來為你的研究開發一個研究型應用程式，請查閱 researchkit.org.

重要

這些規範準則僅供參考之用，並不構成任何法律意見。對於與你的研究型應用程式發展以及任何法律適用的相關建議，你應該向律師諮詢。

通常情況下，一個研究型應用程式是由ResearchKit定製化的介面檢視以及應用程式本身具體設定的介面檢視組成，可歸納為三種主要的體驗：

• 參與者的就位培訓(Onboarding)
• 研究性調查(Study-specific investigation)
• 管理條目資訊(Management items)

設計你的研究型應用程式時務必要遵循以下每個部分的規範準則，將有助於你的使用者參與者感到舒服和保持參與感。

3.5.1 參與者的就位培訓(Onboarding)

就位培訓的體驗包含了一系列向潛在參與者介紹研究內容以及徵詢他們同意的環節。完成這些以後，參與者通常不會再重新訪問這些就位培訓的內容環節：

你應該按如圖所示的這個順序呈現就位培訓的各個體驗環節，也就是按介紹指引、適任、知情同意，以及授權訪問資料。

建立一個具有號召性用語的介紹指引。

指引環節應該幫助人們瞭解更多關於你的研究以及告訴他們如何成為一名參與者。指引環節最好也能向那些現有的參與者提供快捷登入的入口以便繼續正在進行的研究。

儘快確認招募的使用者是否合格。

適任環節呈現在指引環節之後、知情同意環節之前(如果參與者並不適合該研究則沒有必要讓其檢視知情同意環節)。請確認所呈現的適任資質要求對於你的研究來說是必要的。請使用簡單、直白的語言描述這些要求，並讓使用者可以很容易就輸入相關資訊。

在得到參與者的同意之前，確保他們已充分了解你的研究內容。

ResearchKit有助於讓知情同意流程顯得簡潔、友好，同時還允許將你同意的任何法律規定或由機構審查委員會和倫理審查委員會所設定的規定納入其中。(如果你的應用程式涉及到進行人體生物學相關的研究，必須確保你的應用程式符合現有的蘋果應用商店規範指南，並獲得參與者的許可。)通常情況下，知情同意環節包含了：

• 說明這項研究是如何工作的
• 確保參與者瞭解研究內容以及各自的責任
• 獲得參與者的許可

將冗長的同意書分解成易理解消化的小節。

每個小節可以只覆蓋研究內容的一個方面，比如資料採集、資料應用、潛在好處、可能的風險、時間承諾、如何撤出等等。每個小節請使用簡潔、直白的語言來說明一個高度概括的內容。如果有必要，提供一個檢視詳情的按鈕便於參與者瞭解該小節更詳細的解釋。應該讓他們在同意參與之前，就檢視完全部知情同意內容。

通過一個小測驗來測試參與者的理解情況是有意義的。

在獲得參與者允許的情況下，你可以選擇向每個參與者詢問相同的問題。

你的研究必須獲得參與者的同意，如果合適，還可以收集一些聯絡人資訊。

參與者同意參與研究後，他們需要提供個人簽名以及聯絡方式，最後會收到一個確認對話方塊。對於這些資訊記錄，大多數的研究型應用程式會向參與者電郵一份PDF格式的同意書。

參與者需要對這個確認自願參與研究的告警對話方塊給予響應：

參與者可以提供他們的個人簽名在知情同意流程中

如果你需要訪問參與者的裝置或資料必須得到他們的許可。

必須解釋清楚你的研究型應用程式為什麼需要訪問他們的位置資訊、健康應用程式或其他資料，並且確保避免向參與者索要對你研究並非至關重要的資料。同樣地，如果你需要向參與者傳送通知提醒也要獲得參與者的許可。

讓參與者準備授權訪問資料，比如健康應用程式的資料

讓參與者自己選擇他們願意與你共享的資料

3.5.2 具體研究的調查(Study-Specific Investigation)

為了從參加者獲得資料輸入，你的研究可能會使用情況調查、活動任務，或兩者的組合。根據你的研究的體系結構，參與者可能會在每個環節多次或僅需完成一次互動即可。

問卷調查的設計應該能讓參與者專注參與其中。

ResearchKit可以很容易就呈現多種答案型別的調查問題，比如對錯、多選、日期和時間、比例計算，以及開放式文字填寫。當你使用ResearchKit的介面檢視來建立一項調查，請遵循以下準則，來保證好的使用者體驗：

• 告訴參與者總共有多少道問題，以及完成調查預計需要花費的時間
• 每屏只呈現一道問題
• 顯示給參與者當前調查的進度
• 調查應該儘可能簡短。幾個簡短的調查往往好於一個冗長的調查
• 對於需要額外解釋的問題，問題描述請用標準字型大小，然後解釋文字用略小的字型大小
• 調查結束時要告知參與者

ResearchKit提供了許多用於調查環節的可自定義介面檢視。這裡有一些樣例。

使得活動任務容易理解。

活動任務需要參與者參與到一次活動中來，比如對著麥克風語音、手指在螢幕上完成點選、行走散步，以及執行一次記憶力測試。請按照以下幾點準則來鼓勵參與者執行活動任務，並給與他們成功的絕佳機會：

• 請用簡潔易懂的語言來描述如何執行本次任務。
• 如果任務必須在特定的時間或特定情況下進行，請務必明示。
• 確保參與者可以分辨出任務何時結束。

以下是ResearchKit所支援的兩個活動任務樣例。

3.5.3 管理條目資訊(Management Items)

ResearchKit提供了個人檔案的介面檢視來讓參與者可以管理他們的個人資訊。此外，建立一個可以激勵使用者並能讓他們追蹤他們在研究中的進度的介面檢視是個不錯的選擇。在大多數情況下，參加者應該能夠隨時訪問這兩個模組。

使用個人檔案來幫助參與者管理個人資訊和與你研究相關的資料。

個人檔案介面檢視允許參與者在研究程式期間可以編輯相應資料，比如體重或睡眠習慣，並且可以提醒他們即將到來的活動任務。你同樣可以在個人檔案中給予參與者一種簡單的方式離開該研究、檢視知情同意書，以及檢視該應用程式的隱私政策。

使用儀表盤概覽檢視來激勵參與者，並呈現進度。

一個概覽檢視可以讓你與參與者對資訊一覽無餘並鼓勵他們繼續參與。如果你的研究內容合適的話，你可以使用該概覽檢視給予參與者豐富的反饋，比如每日進度、每週評估、具體活動的結果，以及同其他參與者的彙總結果進行對比。

3.6 應用擴充套件(App Extensions)

應用擴充套件可以延伸應用的使用範圍。當使用者使用其他應用時，應用擴充套件使得使用者仍能使用你應用的核心功能。舉個例子，當人們在Safari中瀏覽網頁時，他們可以使用你的分享擴充套件來傳送一張圖片或一篇文章到你的社交網站上。或者當使用Photos(照片)應用時，人們可能會使用你的圖片編輯擴充套件來為一張圖片加上一個濾鏡效果。(在這些場景中，Safari和照片應用承載使用者使用擴充套件的場景，因而被稱為宿主應用(host apps)。)

你需要提交包含應用擴充套件的完整iOS應用到App Store(包含擴充套件的應用被稱為容器應用(containing app))。在你的容器應用中啟用擴充套件之後，人們就可以在使用其他應用時，使用擴充套件來執行快速任務。例如，在郵件中瀏覽某個商品時，人們可以不用離開郵件應用就使用你的動作擴充套件來把商品新增到購物清單中。 表 22-1 列舉了可以多個建立的iOS應用擴充套件型別。

應用擴充套件型別

人們使用擴充套件來做…

今天部件(Today widget)

在通知中心中獲得快速更新或者在今天檢視中快速完成任務分享(Share)

傳送到網站或者和他人分享內容動作(Action)

通過另一個應用的上下文資訊來操作或檢視內容圖片編輯(Photo Editing)

使用照片應用編輯圖片或視訊文件提供者(Document Provider)

進入和管理文件庫自定義鍵盤(Custom keyboard)

替換iOS系統鍵盤以下指南適用於所有型別的應用擴充套件，針對特定型別應用擴充套件的指南請參閱後續章節。(如果想了解如何開發、除錯和釋出一個擴充套件，請參閱App Extension Programming Guide.)

確保是單任務。

應用擴充套件並不是應用的精簡版，它幫助使用者在有全域性目標的上下文中完成狹義範圍內的有限任務。例如，動作擴充套件可以為使用者提供一種不同的方式來檢視當前內容。

保證使用者的互動是有限和流暢的。

好的應用擴充套件應該只需幾步點選就可以幫助人們完成任務，這樣他們就能儘快回到之前的場景中。例如，分享擴充套件只需一次點選即可完成一張圖片的分享。

將容器應用及其應用擴充套件的名稱保持一致。

一個容器應用中如果有多個擴充套件，需要使用不同的名稱，你需要確保使用者能夠理解你的擴充套件和應用之間的關係。人們會在很多不同的情況下遇到擴充套件，如果他們當下沒有認出來，那麼他們就未必會信任這些擴充套件。

大部分情況下，複用容器應用的圖示。

顯示使用者熟悉的圖示是獲得使用者信任的另一種方式。請注意，對於動作擴充套件來說，你應該使用單色版本的容器應用圖示(詳見分享和動作擴充套件)。

重要：和設計圖示和圖形一樣，不要重複使用iOS的圖示和圖片，不要為蘋果的產品和設計再設計一套圖片。

避免在擴充套件上顯示模態檢視。

很多擴充套件預設以模態檢視來顯示，所以應避免再疊加模態檢視。儘管有時候使用者可能會在擴充套件上遇到警告框，但是在設計擴充套件的流程時，應避免出現模態檢視。

3.6.1 今天部件(Today Widgets)

人們會在通知中心的今天區域中檢視今天部件(Today widgets)。因為人們會設定今天區域以顯示他們最關注的資訊，所以在此進行設計可以有效幫助你的部件在這些使用者最重要的資訊中佔據一席之地。

設計與通知中心風格一致的外觀。

當使用通知中心的預設邊距和背景時，你的今天部件就會給使用者以統一的體驗。為獲得最佳的結果，你應該重點關注你的內容而不是背景或者其他的，尤其應該避免繪製一片純色背景。

注意：

iOS會自動在自定義的部件內容上方顯示應用的圖示和標題(圖示會顯示在標題前面的空白處)。

將部件內容與標題對齊。

當你的部件內容與標題對齊時，人們就可以很簡單地瀏覽今天檢視中他們想要的部件。遵守今天檢視中的邊距規範，並將內容約束在如圖的部件內容區內。

一般情況下，使用白色的系統字型來顯示文字。

在通知中心預設背景下白色文字會看起來較好。對於二級文字，可以使用系統提供的vibrant外觀樣式(檢視notificationCenterVibrancyEffect瞭解更多)。

提供通知中心式的體驗。

人們訪問通知中心來獲取簡要的更新或者執行一個非常簡單的任務，所以今天部件最好只顯示適量的資訊和進行有限的互動，特別是：

• 避免使用者在部件中需要滾動或縱向移動來檢視全部的資訊。部件可以通過縱向擴充套件來顯示更多的資訊，但若部件的高度超過通知中心的高度就不是一種好的體驗了，因為這樣會干擾其他部件的檢視
• 避免使用橫向掃動或拖曳，因為這會干擾在通知中心進行導航
• 儘可能使使用者只需一步操作就完成任務或開啟你的應用(注意，在今天部件中鍵盤是不可用的)
• 優化效能以便人們可以即刻獲得有用的資訊。可以考慮在本地快取資訊，以便當有更新時就可顯示最近資訊。人們只希望在今天檢視中花很少的時間，如果部件使用記憶體不當，iOS就可能會終止它

在適當情況下，讓人們點選你的今天部件來開啟你的應用。

因為今天部件提供了專一的體驗，所以就能有效引導人們去到你的應用以獲取更多資訊或功能。最好不要顯示“開啟應用”按鈕，而是應該讓你的整個今天部件都可被點選來開啟應用。你也可以讓使用者點選部件中的UI物件，以開啟你的應用並跳轉到關於此UI物件的檢視中。舉個例子，日曆部件顯示了今天的事件，如果使用者想要獲得某個事件的更多資訊，他們可以點選部件中的事件來開啟日曆應用進行檢視。

注意：

雖然從部件開啟應用的方式對使用者來說還不錯，但繼續在部件中提供有用且及時的資訊依然是很重要的。人們可不一定會欣賞一個功能只是開啟應用的今天部件。

如果可能，在今天部件中讓人們知道他們需要登入來獲取有用的資訊。如果你的今天不見需要人們登入檢視資訊，展示一個資訊去鼓勵他們登入和解釋什麼樣的內容將會被呈現。例如，如果你的時間部件即將到來的預約是使用者登入後展現的，你可能需要讓使用者“登入我的應用去檢視即將到來的預約”。

不要製作一個今天不見需要開啟除了你自己應用外的應用。一個模擬iOS主屏的行為的時間部件不會為你的使用者提供有用的功能。

3.6.2 分享和動作擴充套件(Share and Action Extensions)

人們通過點選應用中的動作按鈕(Action button)來使用分享和動作擴充套件。在通過動作按鈕顯示的動作檢視控制器(activity view controller)中，動作擴充套件被列在底部，分享擴充套件被列在動作擴充套件之上。人們可以使用更多（More）按鈕來管理顯示在動作檢視控制器中的分享和動作擴充套件。

分享或動作擴充套件通常被認為是在當前使用者場景下用來輸入內容之用。例如，當在Safari中閱讀一篇文章時，使用者可能會點選動作按鈕並使用一個分享擴充套件來傳送這篇文章到分享網站上，也可能會使用一個動作擴充套件來檢視這篇文章的翻譯。

注意：

在動作檢視控制器中，iOS只會顯示支援當前內容型別的動作擴充套件。例如，當使用者當前內容是視訊時，iOS就不會顯示支援文字的動作擴充套件。

儘可能在分享擴充套件中使用系統提供的UI。

系統所提供的撰寫檢視控制器 (compose view controller) 提供給使用者一種一致的體驗，並能自動支援一些常用任務，例如預覽和確認標準項，同步內容，檢視動畫，以及完成一封郵件。欲知更多關於使用系統提供的撰寫檢視控制器，請參見 App Extension Programming Guide中的Share.

如果上傳需要一定時間，那就應考慮在分享擴充套件的容器應用中顯示上傳進度。

無論分享的檔案有多大，人們都期待在點選擴充套件中的傳送或分享按鈕後，能立即返回他們之前的場景。你需要讓進度狀態隨時更新，但是人們不想每次上傳完畢後都收到通知，並且也無法自動重啟擴充套件。在這種場景下，在容器應用中顯示上傳進度是一種解決方案，這樣容器應用就可以在後臺處理任務，並在遇到問題時傳送通知。

動作擴充套件使用單色的應用圖示。

不同的是，分享擴充套件則應該使用其容器應用的彩色應用圖示。 要為動作擴充套件設計圖示時，你可能需要從建立一個應用圖示的模版開始著手。如有需要，可以專注圖示所特有的元素來進行簡化設計。

如果你在容器應用中提供了多個動作擴充套件，那麼最好為他們設計一套圖示，且確保這套圖示中的每一個看起來都與容器應用的圖示是有關聯的。

3.6.3 圖片編輯擴充套件(Photo Editing Extensions)

當人們在照片(Photos)中檢視圖片或視訊時，可以使用圖片編輯擴充套件。一般來說，圖片編輯擴充套件能幫助使用者篩選圖片或進行一些其他的圖片或視訊編輯。在使用者確認之後，編輯後的內容就會出現在照片應用中。

照片應用提供了一個模態檢視來顯示圖片編輯擴充套件的自定義UI。當使用者在確認對圖片或視訊的編輯時選擇了取消(你必須要在程式碼上保證存在這個行為)，照片應用還可以顯示一個確認檢視。

避免在圖片編輯擴充套件中使用導航欄。

如圖所示，承載擴充套件的模態檢視已經包含了導航欄，若再增加另一個導航欄，既會佔據更多你的介面空間，還會使使用者產生困擾。(照片應用預設會以全屏高度來顯示你的檢視，所以你的內容會出現在內建的導航欄之下。)

如果可以，讓使用者能夠預覽編輯結果。

儘可能讓使用者在關閉擴充套件返回照片應用之前看到他們編輯的成果。

3.6.4 文件提供者擴充套件(Document Provider Extensions)

文件提供者擴充套件幫助人們在其他各種應用中查閱你的應用所管理的文件。在宿主應用(host app)中，文件採集檢視控制器(document picker view controller)會顯示你的擴充套件所提供的UI(想要了解更多有關文件採集檢視控制器的內容，請查閱UIDocumentPickerViewController Class Reference)。

注意：

文件提供者擴充套件由兩個不同的部分組成：文件採集檢視控制器擴充套件和檔案提供者擴充套件。文件採集檢視控制器擴充套件包括了你的自定義UI，檔案提供者擴充套件實現對檔案的訪問。為了簡單起見，本節所使用的術語文件提供者擴充套件(Document Provider extension)是為了表述擴充套件中文件採集檢視控制器部分的UI和體驗。

避免在文件提供者擴充套件中使用導航欄。

iOS會顯示擴充套件的自定義UI，而自定義UI又包含在文件採集檢視控制器中基於導航欄的介面之中。所以，在內建導航欄之下再顯示第二個導航欄會使使用者感到困惑，並且還會佔據原本你的內容區域。(文件採集檢視控制器預設會以全屏高度來顯示你的檢視，所以你的內容會出現在內建的導航欄之下。

3.6.5 自定義輸入法(Custom Keyboards)

人們在整個系統中使用帶有自定義輸入法的輸入法擴充套件來替換iOS的自帶輸入法。在啟用輸入法擴充套件之後，除了受保護的文字區域(例如密碼輸入區)和手機鍵盤區(例如聯絡人中的電話號碼區)外，當人們點選任何文字輸入區域後就能使用自定義輸入法。

為使用者提供明顯的方式來切換輸入法。

人們對於iOS的輸入法切換按鈕很熟悉，他們會期望在你的輸入法中也有類似的體驗。

如果可能，在你的容器應用中包括一個教程。如果必要，使用你的自定義鍵盤的容器應用去給人們講解如何啟用和使用你的鍵盤。不要把這個資訊直接放在鍵盤本身，因為它可能讓人們嘗試使用這個鍵盤時感到困惑。

3.7 HomeKit

通過HomeKit，使用者能夠方便地在家中使用iOS裝置上的智慧家居應用來操控家中相關聯的裝置(無論這些裝置製造商是誰)。最好的智慧家居應用整合HomeKit和iOS系統來幫助使用者：

• 建立家居環境、房間和區域
• 新增、尋找和移動家居裝置(如燈泡或溫度調節裝置)
• 定義能夠使一組多個家居裝置響應的行為
• 管理使用者
• 用Siri來操控他們的家居設施

想要了解如何在你的應用中使用HomeKit，可參閱HomeKIt Developer Guide。下面的指南可以幫助你做出一個容易上手、令人愉悅的智慧家居程式。

不要想當然地認為你的裝置會是使用者所設定的首個裝置。

你的應用除了能讓使用者很容易就能建立家居環境、房間和區域，還需要讓使用者能方便地將你的裝置接入之前已經設定好了的區域中。

讓新增新裝置變得簡單。

不要強迫使用者在新增裝置之前註冊賬號。最好讓你的應用能自動發現新的裝置並將他們顯著地展示在使用者介面上。確保所展示的資訊足夠充分讓使用者可以輕易辨識出該家居裝置。

幫助使用者辨認他們正在調節的裝置。

給使用者一個能夠幫助他們從物理屬性辨認裝置的控制器。例如，你可以讓使用者通過閃一下燈泡來確認他們正在調節的是他們想要調節的那個。

讓使用者能夠通過多種方式來搜尋裝置。

當天的時間、季節和使用者當前的位置會在特定的時刻成為判別某些裝置是否重要的影響因素。因此，你的應用應該允許使用者能在家中按型別、名稱、或者位置的方式來搜尋裝置。

為家中已接入的裝置提供推薦的操作集。

操作集允許使用者設定在某種情景下讓多個家居裝置按照特定的方式行動。例如，一個“離開”操作集可以將房屋內的溫度調低、關閉電燈和鎖上所有房門。你的應用可以向使用者推薦一些已經設定好了的操作集或者讓使用者建立自定義操作集。當使用者能夠基於房間或區域去建立自定義操作集時，讓使用者可以從你推薦的裝置列表中進行選擇，通常能使使用者獲得更好的體驗。

使用友好的交談式語言讓你的應用平易近人、易於使用。

智慧家居概念可能會懵到使用者，應避免使用他們可能不理解的縮寫和技術術語。例如，HomeKit是指代API的專用技術術語，它就不應該在你的應用中使用。

注意：如果你是蘋果MFi認證許可商，請訪問MFi入口網站檢視裝置包裝的命名及訊息通知的規則。

與Siri互動。

通過Siri，使用一個簡單的陳述句就能控制執行復雜的操作。Siri能夠識別操作集、房屋、房間和區域的名稱，並且能夠理解像“Siri，把前門關了”、“Siri，把樓上的燈關了”和“Siri，把多媒體房的溫度調高一點”這樣的陳述。遵循以下準則能幫助你為使用者提供使用Siri操控裝置時的良好體驗：

• 使用Siri能夠識別的功能名稱，而非裝置名稱。一個裝置可能提供多種功能(例如，一個既有風扇功能又有照明功能的風扇吊燈)，因此，幫助使用者區分這些功能是很重要的。最佳方案是讓使用者在一系列不包含公司名稱及型號的限定的名稱中進行選擇，並且允許他們以後編輯。你所推薦的名稱應該使用規範的、容易理解的詞語來描述功能，並可選擇是否包含家中的位置資訊，例如“客廳燈”或者“車庫門”。你還可以讓使用者指定一種控制插座開關的通用口令，例如“Siri，把燈關了”，來控制所有的燈具和其相關的裝置
• 當使用者配置操作集的時候，告訴使用者如何通過Siri去操控它。舉個例子，當“電影”這個操作已經確認配置完畢時，讓使用者知道他可以通過跟Siri說“Siri，把家調成電影模式”這樣的話來啟用這個操作。 注意，當使用者單獨對Siri說出某操作的名稱時，同樣也能啟用那個操作。Siri能夠識別系統預置以及使用者自定義的操作集，這些已配置的操作集至少包含一項操作

幫助使用者設定觸發機制。

在iOS9中，HomeKit支援觸發機制：當滿足特定的時間、地點或其他裝置的行為的條件時啟用操作的方式。比如使用者可以設定一個當太陽落山且車庫門開啟時，就開啟廚房燈操作的觸發機制。設定一個包含多個專案的條件關係容易使人感到混亂，因此，將你的設定介面做得簡單易用至關重要。舉例來說，使用與人們平常說話一樣的表達方式來展示專案、屬性和邏輯，就更容易使人理解。

3.8 多工處理(Multitasking)

多工處理讓人們在螢幕上(在合適的iPad模式上)檢視多個應用，可以在最近使用的應用之間進行快速切換。在iOS9,中，人們可以使用多工處理UI(下圖所示)去選擇最近使用的應用。

能否在多工處理中處理好取決於能否在裝置中與其他應用和諧共存。從更高的層面來說，這意味著所有的應用都應：

• 仔細調整資源使用避免佔用太多CPU，記憶體，螢幕空間和其他資源
• 處理好中斷或來自其他應用的聲音
• 停止和重啟，即快速平滑地從後臺切換到前臺
• 不在前臺時應恪守己任

下述指南細則可以幫助你的應用在專注應用切換的多工處理中取得成功。更多合格的iPad模式下關於多工環境中執行的資訊，參閱 Adopting Multitasking Enhancements on iPad.

準備好被打斷，並恢復。

多工處理增加了後臺應用中斷你的應用的可能性。其他特性，諸如廣告出現和更快的應用切換，也會造成更頻繁地打斷。越快速和越精確地儲存應用當前狀態，人們就可以越快地重新執行應用，並從之前離開的頁面繼續使用。你可以通過利用UIKit的狀態儲存和恢復來為使用者提供無縫的重新開始的體驗(檢視Preserving Your App’s Visual Appearance Across Launches瞭解更多資訊)。

確保你的UI可以處理兩倍高度的狀態列。

兩倍高度的狀態列會在諸如通話、錄音和共享等過程中出現。在未作處理的應用中，狀態列的額外高度會引起佈局問題，如UI被向下擠壓或者被遮住。在多工處理環境中，使兩倍高狀態列顯示正常是格外重要的，因為它可能會出現在更多的應用當中。

準備好暫停需要人們注意或主動參與的活動。

例如，如果你的應用是一款遊戲或媒體觀看應用，你需要確保你的使用者從應用切換走時，不會丟失任何內容或事件。當人們切換回遊戲或媒體播放器時，他們希望能繼續之前的體驗，就好像他們從未離開過應用。

確保音訊行為合適。

當你的應用正在執行時，多工處理會使得其他媒體活動更可能地同時進行，也會有更多可能性使你的音訊不得不暫停，並恢復處理中斷。檢視聲音來幫助你確保你的音訊能滿足人們的期望，並與裝置中的其他音訊和平共處。

適度使用本地通知。

應用可以在特定時間傳送本地通知，無論應用是在暫停中還是執行中亦或是根本就沒有執行。為了達到最好的使用者體驗，應避免用過多的通知來騷擾人們，並遵循通知中建立通知內容的指南。

必要時，在後臺完成使用者的任務。

當人們開始一個任務時，他們通常會期望即使已經從應用中切換走了任務仍能夠完成。如果你的應用在執行使用者任務途中，並且這個任務不需要額外的使用者互動，那麼你就應該在應用掛起之前就在後臺完成任務。

3.9 通知(Notifications)

通知為人們提供即時的重要資訊和功能。人們能在多種情況下收到通知，例如在鎖屏介面中，或者在使用應用時，或者訪問通知中心時。 通知中心有兩種檢視：通知(Notifications )和今天(Today)。

今天檢視顯示了一組可編輯的部件。今天部件是一個應用擴充套件，顯示了少量及時和重要的資訊或功能，這些資訊或功能則是由使用者所關注的應用所提供。舉例來說，日曆部件只顯示了今天的事件。點選日曆部件中的一個事件可以喚起日曆應用，並開啟該事件，使用者接下來可以編輯該事件或管理其他的事件。想要了解更多關於設計今天部件的內容，請參見今天部件。

通知檢視會顯示使用者感興趣的應用所發出的最近通知。使用者可以在設定(Settings)中來設定是否在通知中心顯示該應用的通知。 iOS應用可以使用通知來讓人們知道一些有趣的事情是什麼時候發生的，例如：

• 收到一條訊息
• 事件即將發生
• 有新的資料可下載了
• 某些狀態發生了變化

在iOS8及之後的版本中，應用可以定義使用者在通知中的操作。例如，使用者可以在待辦事項應用的通知中就標記該事項已完成，而無需額外開啟應用。 iOS定義了兩種型別的通知。

• 本地通知(local notification)由應用安排待傳送，最終通過iOS傳送到同一裝置中，無論該應用當前是否正在後臺執行。例如，日曆或待辦事項應用可以安排一條本地通知來提醒人們一個即將到來的會議或者日期。
• 遠端通知(remote notification)(也稱為推送通知(push notification))是由應用的遠端伺服器通過蘋果推送通知服務來傳送的，這類通知最終會被推送到所有安裝了該應用的裝置。例如，一款線上競技類的遊戲，使用者可以和其他玩家競賽的，可以更新所有玩家的最新狀態。

注意：應用擴充套件可能會要求遠端通知必須傳送到它的容器應用。在這種場景下，容器應用常常會在後臺執行來處理通知。想要了解更多關於應用擴充套件的內容，請參見應用擴充套件。

如果當你的應用正在後臺執行時收到了本地或遠端的通知，你就應該以你的應用所特有的方式將資訊傳達給你的使用者。 為了確保使用者能夠自定義他們的通知體驗，你應該儘可能多地支援以下的通知型別：

• 橫幅(Banner)
• 警告框(Alert)
• 小氣泡(Badge)
• 聲音(Sound)

注意：在iOS8及之後的版本中，你必須對所有你想傳送給使用者的通知型別進行註冊。當你第一次進行註冊動作時，使用者會遇到一個警告框，他們可以在其中操作來決定允許或拒絕所有來自你的應用的通知。不管使用者選擇的結果是什麼，他們應始終能訪問應用的設定來更改此項設定，或者設定他們想要接收的通知型別。

橫幅(banner)是一個小而透明的檢視，會出現在螢幕頂部並在幾秒後消失。使用者還可以看到在鎖屏當中的橫幅以及在通知中心中以通知形式出現的橫幅。在橫幅中，iOS會顯示通知的內容和應用的小圖示(欲瞭解更多關於小圖示的內容，請參見 App Icon)。使用者點選橫幅來隱藏顯示並切換到傳送通知的應用。

除了預設的點選動作之外，當使用者輕掃橫幅時,你還可以定義兩個動作按鈕。點選通知動作按鈕來隱藏橫幅的顯示並啟動你的應用(可能是在後臺)來執行動作。

通知警告框是顯示在螢幕上的標準警告框檢視，需要使用者操作後才會隱藏。當使用者點選Options按鈕後，你需要提供並顯示通知訊息以及任何一個預設動作，或最多四個特定動作。警告框的背景樣式不能做修改。 當使用者點選警告框中的一個預設或自定義動作按鈕時，iOS會同時隱藏警告框並執行你的應用(可能是在後臺)。點選關閉或確定按鈕會隱藏警告框而不開啟應用。

小氣泡(badge)是一個顯示未讀通知數量的紅色小圓(小氣泡顯示在應用圖示的右上角)。小氣泡的大小和顏色不能做修改。 橫幅、警告框和小氣泡這三種通知都可以使用自定義或系統提供的聲音。

在通知中謹慎使用具破壞性的動作。

要確定使用者有足夠的上下文來避免意想不到的後果。為了幫助使用者區分你所定義的破壞性動作，iOS會用紅色來顯示它。有時候，在應用執行破壞性動作之前，應該請求使用者進行確認。舉個例子，如果在鎖屏的橫幅(banner)中提供了一個破壞性動作，那麼就應確保只有裝置的主人才能執行該動作(你需要在程式碼上實現這一需求)。

為每個動作按鈕提供自定義標題。

建立一個簡短的標題來描述清楚將要發生的動作。例如，遊戲可能會使用“Play”作為標題來表明，點選這個按鈕會開啟應用來進行遊戲。確保標題：

• 使用標題樣式的大小寫(title-style capitalization)
• 足夠簡短，能不被截斷地顯示在按鈕內(也應確保測試各種語言文字的標題顯示正常)

不要為同一個事件重複傳送通知。

使用者可以選擇處理通知項；通知項在使用者未處理前會一直顯示。如果為同一事件重複傳送通知，通知中心列表中會滿是通知，使用者就有可能會關閉你的應用的通知。

不要在通知訊息中包含你的應用名稱。

自定義資訊會在警告框和橫幅中顯示，也會在通知中心中以通知的形式顯示。你無需在自定義資訊中顯示你的應用名稱，因為iOS會在顯示資訊的同時自動顯示應用名稱。 為了使本地或遠端通知資訊更有作用，你應該：

• 專注於資訊而不是使用者的行為。避免告訴人們點選哪個按鈕或如何開啟你的應用
• 足夠簡短，一兩行就可以顯示完整。較長的資訊對於使用者來說很難進行快速閱讀，也會造成在警告框中需要滾動才能檢視完整
• 使用句式大小寫(sentence-style capitalization)，並配以合適的結束語句符號。可能的時候，可以使用一個整句

注意：如有必要，iOS會縮短你的訊息以便能在各種通知傳送樣式下顯示；為了最好的效果，你不應主動縮減你的訊息。

保持小氣泡的內容是最新的。

當使用者注意到新資訊時，即時更新小氣泡非常重要，這樣使用者就不會覺得收到了額外的通知。注意，當小氣泡為0時也會移除通知中心中所有對應的通知項。

重要：不要使用小氣泡做通知以外的用途。記住，使用者能夠關閉應用的小氣泡，所以你無法確定他們一定能看到小氣泡中的內容。

當收到通知時，提供使用者可以選擇聽到的音效。

當人們沒有在看螢幕的時候，可以通過音效獲取他們的注意。例如，日曆應用可能會在顯示警告框的同時播放一個音效來提醒人們一個即將到來的事件。再如，協作任務管理應用可能會在小氣泡更新時播放一個音效來告知某個遠端協同的同事已經完成了某個任務。

你可以提供自定義的音效，或者使用內建的警告音。如果你建立了自定義音效，請確保它是簡短的、有特色的並且是經由專業製作的。(想要了解更多關於音效的技術需求，請參閱Local and Remote Notification Programming Guide中的Preparing Custom Alert Sounds。)注意，當通知傳送後，你無法以程式設計方式來觸發裝置的震動，因為使用者對於警告框是否伴隨震動擁有支配權。

3.10 社交媒體(Social Media)

人們會期望在任何場景下都可以使用他們喜愛的社交媒體帳號。iOS以人們喜歡的方式將社交媒體的互動與你的應用進行了整合。

注意：當使用者點選動作按鈕時，他們會得到一個如上圖的動作檢視控制器。想要了解更多關於這個檢視控制器的內容，請參見Activity View Controller。

動作檢視控制器的中間一行顯示了使用者啟用的和系統提供的分享應用擴充套件。想要了解更多關於設計分享擴充套件的內容，請參見Share and Action Extensions。

考慮在你的應用中為使用者提供一種簡便的方式來撰寫郵件。

使用者有可能會啟用分享擴充套件以便能在任何地方都可以傳送內容。但是你也可以使用系統提供的撰寫檢視控制器來呈現給使用者，他們可以在其中進行編輯操作。你可以在顯示給使用者進行編輯之前，預先載入具有自定義內容的撰寫檢視(在你呈現給使用者之後，只有使用者可以編輯這些自定義內容)。想要了解更多關於社交框架(Social framework)的程式設計介面，包括SLComposeViewController類，請參見Social Framework Reference.

如果可能，避免要求使用者登入進入一個社交媒體賬戶。

社交框架(Social framework)會和帳號框架(Accounts framework)一起來支援一個單點登入模式，所以你可以獲得授權來訪問使用者的帳號，而無需要求他們來重新授權。如果使用者還沒有登入進入一個帳號，你可以顯示UI來讓他們進行登入。

3.11 iCloud

iCloud可以讓使用者隨時隨地用不同的裝置訪問他們想要的內容。將iCloud整合到應用中，使用者不用進行同步操作就可以在不同場景下使用不同的裝置訪問並編輯私人資訊。

為了提供這種體驗，你可能需要重新檢查你的應用中現有的資訊，尤其是使用者自建內容的儲存、訪問和展示方式。想要了解如何使用iCloud，請參考iCloud Design Guide.

iCloud使用者體驗的一個基本方向是透明性：理想情況下，使用者不需要知道他們的資訊儲存在什麼地方，也不需要去思考當前瀏覽的資訊是哪個版本的。以下幾點可以幫助你建立使用者期望的iCloud體驗。

如果可能，讓使用者方便地在你的應用中啟用iCloud。

在iOS裝置上，使用者可以在設定中登入iCloud賬戶，因此多半使用者會期望應用可以自動啟用iCloud。但是如果你覺得使用者可能需要自主選擇是否使用你應用的雲服務，你可以在使用者第一次進入應用時提供一個簡單的選項來進行設定。大多數情況下，這個選項應該為：是否將所有內容上傳到雲端。

尊重使用者的iCloud空間。

一定要記住iCloud空間是使用者花錢買來的有限資源。你應該使用iCloud來儲存使用者自己建立和可理解的資訊，避免將可再生的應用資源和內容儲存在雲端。同樣要記住，當使用者登入了iCloud賬戶時，你的應用的資料夾內容也會自動備份到雲端。所以為了節省使用者雲端空間，你最好只挑選必要的資訊儲存於資料夾中。

避免讓使用者自己選擇在iCloud上儲存哪些檔案。

一般地，使用者會期望他們在意的所有資訊都能夠通過iCloud訪問到。實際上大多數使用者都不需要進行個人檔案儲存的管理，所以你的應用也可以不用考慮這個問題。為了提供更好的使用者體驗，你可能想要重新構建處理和展示內容的方式，這樣就可以給使用者提供更多的檔案管理功能。

決定哪種型別的資訊需要儲存在雲端。

除了儲存使用者自建的檔案和內容，你還可以儲存少量的其他資訊在雲端，例如使用者當前的狀態，使用者的偏好設定等等。你可以使用iCloud的關鍵值儲存來儲存這類資訊。例如，使用者使用你的應用看了一個雜誌，你可以使用iCloud的關鍵值儲存來儲存使用者瀏覽到的位置，這樣使用者在別的裝置上重新開啟這個雜誌時就能從上次離開的地方繼續瀏覽了。

如果你使用iCloud的關鍵值儲存來儲存使用者的偏好設定，確保使用者在每個裝置上都是想這樣設定的。例如，有些偏好設定在工作環境中比在家裡要更好用。在某些情況下，將偏好設定儲存在應用伺服器上要比儲存在雲端更合理，這樣偏好設定就不會受iCloud的限制。

確保iCloud無法使用時應用的行為是合理的。

例如，使用者退出iCloud賬戶，關閉應用的iCloud或者進入飛航模式時，iCloud都是無法使用的。在這些情況下，使用者都進行了某些操作來禁止iCloud服務，所以你的應用可以不用再進行提醒。但是，需要告訴使用者在開啟iCloud之前，當前做的修改在其他裝置上都無法看到。

避免給使用者建立“本地”檔案的選項。

不管你的應用是否支援iCloud，都不應該給使用者提供因裝置而區分的檔案系統。相反，你應該希望使用者關注通過iCloud訪問檔案的普適性。

在合適的時候自動更新資訊。

最好不需要使用者來確認他們正在訪問的是最新的內容。但是，也需要在使用者裝置儲存空間和頻寬限制之間做出平衡。如果你的使用者要使用非常大的檔案，那麼讓他們自己選擇是否要從雲端下載一個更新的檔案可能更合適。如果需要這樣做的話，可以設計一種方式來指出當前在雲端有一個該檔案的最新版本。當使用者選擇更新時，如果下載時間較長最好給使用者明顯的反饋。

告知使用者刪除某檔案的後果。

當使用者從有iCloud服務的應用上刪除檔案的時候，這個檔案同樣會從使用者的iCloud賬號和其他裝置上刪除。所以最好在執行刪除操作之前告知使用者刪除的後果，讓使用者進行確認。

必要時儘可能早地告知使用者衝突問題。

使用iCloud程式設計介面，你需要在不打擾到使用者的情況下解決大多數不同版本之間的衝突問題。但在有些情況下，你需要儘可能早地檢測出衝突問題來避免使用者在錯誤版本上浪費太多時間。你需要設計一種自然的方式來告訴使用者有衝突存在，接著給使用者提供方便的方式來區分不同版本以及做出決策。

確保在搜尋中包括使用者在雲端的資訊。

使用iCloud的使用者趨向於認為雲端的資訊是普遍可訪問的，所以他們會期望搜尋結果中也有云端的資訊。如果你的應用允許使用者搜尋他們的資訊，確保你使用了將搜尋擴充套件到iCloud賬戶的介面。

本章中文翻譯PDF下載：點選下載