iOS 9人機界面指南(三):iOS 技術 (上)
3.1 3D觸摸(3D Touch)
3D Touch 給 iOS 9 用戶提供了一個新的交互維度。在所支持3DTouch的設備上,人們可以通過按壓應用的圖標去快速選擇應用定制的操作。在應用內,人們可以使用多種按壓操作去獲取一個項目的預覽,可以在獨立的視圖里打開一個項獲取相關操作。(了解更多在你的代碼中如何添加3D Touch支持,參閱?Adopting3DTouchoniPhone
3.1.1?輕壓和重壓(Peek and Pop)
輕壓讓用戶可以在不離開他們當前環境的情況下預覽一個項和執行相關操作。支持輕壓的該項會在輕壓后給出一個小矩形視圖作為反饋。
在Safari中的一個輕壓視圖
在Safari輕壓中的快速操作
輕壓(Peek):
- 當用戶按壓在一個支持輕壓的項上時出現輕壓,用戶手指抬起后會消失
- 當用戶在輕壓視圖下再更加重一點的按壓稱之為重壓,重壓可以查看該項的詳細視圖
- 當用戶在輕壓視圖中向上滑動,可以提供與該項相關的快速操作
當用戶輕輕按壓在屏幕,支持輕壓的這個項會展示一個你提供的矩形視圖,示意可以進行下一步交互操作。那個視圖應該夠大,這樣才能讓用戶手指不會混淆內容,這個視圖應該足夠細節,這樣可以讓用戶選擇是否去更加重一點按壓從而轉換到輕壓視圖。
重要
你在應用中始終如一提供輕壓和重壓的體驗是至關重要的。如果你在有些地方支持輕壓和重壓,在某些地方不支持,用戶有可能認為你的應用或者他們的設備出現了問題。
使用輕壓去為該項提供一個生動的,內容豐富的預覽。當輕壓能夠給用戶提供關于該項的足夠信息,從而幫助他們擴展當前的任務,這樣做是最好的。例如,在用戶決定好是在Safari中打開信息中的網頁還是分享這個鏈接給朋友之前,用戶可以使用輕壓預覽信息中URL的頁面。在表單視圖中,輕壓可以給用戶提供一個行項的詳細內容。
為每個輕壓提供重壓。雖然一個輕壓可以提供給用戶所需要的大部分信息,但是你應該可以讓用戶過渡到重壓,從而讓用戶放開當前正在進行的任務,轉移專注力到該項上來。重壓的內容應該與用戶點擊該項后的內容一致。
不要為同樣一個項授予輕壓和編輯菜單( 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口可以找到這兩個按鈕(想要了解更多信息,請查閱。有關使用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中瀏覽網頁時,他們可以使用你的分享擴展來發送一張圖片或一篇文章到你的社交網站上?;蛘弋斒褂肞hotos(照片)應用時,人們可能會使用你的圖片編輯擴展來為一張圖片加上一個濾鏡效果。(在這些場景中,Safari和照片應用承載用戶使用擴展的場景,因而被稱為宿主應用(host apps)。)
你需要提交包含應用擴展的完整iOS應用到App Store(包含擴展的應用被稱為容器應用(containing app))。在你的容器應用中啟用擴展之后,人們就可以在使用其他應用時,使用擴展來執行快速任務。例如,在郵件中瀏覽某個商品時,人們可以不用離開郵件應用就使用你的動作擴展來把商品添加到購物清單中。 表?22-1?列舉了可以多個創建的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),并配以合適的結束語句符號??赡艿臅r候,可以使用一個整句
注意:如有必要,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賬戶的接口。
相關閱讀:
本章英文原文訪問地址:iOS Human Interface Guidelines
本章中文翻譯PDF下載:點擊下載
來源:騰訊ISUX(http://isux.tencent.com/ios9-guideline-ch3-1.html)
版權聲明:若該文章涉及版權問題,請聯系我們主編,QQ:419297645
- 目前還沒評論,等你發揮!