【 3S Market 】 可穿戴產是否將是兩岸在國際市場另一個角力的焦點?以下文章給各位中智慧手表的實作觀摩。也請大家來思考:面對中國廠商,台灣中小企業未來發展之路,要將中國廠商視為「盟友」、「夥伴」、「競爭對手」;或是… 「死敵」?
VIDEO
按:本文來自百度MUX 。百度MUX 智慧硬體 團隊從去年年初開始,接手百度智慧手錶 OS 的設計工作,認為相對於智慧手機 的「碎片化」場景,智慧手錶在資訊和任務維度更加輕量,呈現「微粒化」的點狀用。本文將展示百度智慧手錶的OS 創新設計。
| 背景與挑戰
2015 年Google 、Apple 、阿里、華為均推出了智慧手錶或其作業系統,同時來自研究公司Strategy Analytics 的最新資料顯示, Apple Watch 2015 年的全球出貨量達到1500 萬支 ,可以說2015 年是智慧手錶的元年。
由於早期Android Wear 的部分服務無法在中國使用,各大互聯網公司設計的智慧手錶作業系統更是風起雲湧,如出門問問、YunOS 、TencentOS 等等。但是由於業內對智慧手錶的形態尚處於探索階段,多數產品對於手錶平臺所要承載的任務和資訊,並沒有進行清晰的定義。
百度MUX 智慧硬體團隊從去年年初開始,接手百度智慧手錶OS 的設計工作,認為相對於智慧手機的「碎片化」場景,智慧手錶在資訊和任務維度更加輕量,呈現「微粒化」的點狀用戶體驗。需要重新設計承載他們的容器。本文希望嚴肅地說,智慧手錶的 「微粒化」 設計是一種怎樣的體驗?
為「微粒化」時間而生—— 智慧手錶的屬性定義
定義新作業系統的第一步是定義設備屬性,我們分別從智慧手錶適合執行的任務,和適合顯示的資訊兩個維度進行定義。
智慧手錶有著極佳的便攜性,和極低的輸入效率(輸入效率由精準度和速率兩方面決定),因此它只適合執行輕量的任務,比如收到一個推送後簡單執行附帶的操作,P 圖這類需要長時間連續操作的任務,顯然不適合在手錶上進行。
在資訊維度,經測試智慧手錶一次使用舒適時長為15 秒左右(從抬起手腕到手臂有疲勞感,看文章的你請可以自行測試),螢幕展現尺寸極小,所以智慧手錶必須在繁雜資訊中做出抉擇,把重點放在高頻的簡短資訊上。
綜上分析,我們將目前技術所能實現的智慧手錶屬性,定義為「輕任務,短資訊」的承載設備。如果說手機讓我們利用生活中的碎片化時間,執任務和查看資訊,那麼智慧手錶就是利用我們的 「微粒化」 時間執行更輕的任務和查看更短的資訊。
| 分析:細分手錶承載的資訊和任務
智慧手錶展現尺寸十分有限,因此有必要將短資訊和任務按使用頻率細分,以便設計不同的「容器」承載它們。
適合放在手錶上執行的任務,應該是能在很短時間內完成的,這意味手錶的使用場景被限制!我們怎樣解決這一問題?我們發現將一些在手機上,總是被重複的長線任務進行自動化處理後,放在手錶上能有效加快效率和擴展使用場景。
比如叫車服務這個任務,我們用手機時的操作是「拿出手機 – 解鎖 – 打開App – 輸入位址
– 發出訂單」,在設計手錶時我們把這個流程內,最常用的一些任務(比如從家到公司)提取出來,利用智慧手錶用戶可以一鍵發出從家到公司的訂單,而不是單純的把手機的操作照搬一遍。
| 交互模型
如前文所述我們將手錶定義為「輕任務,短資訊」的承載設備,由於手錶螢幕展現尺寸的限制,我們不得不將資訊和任務分級,以便用不同容器承載,那麼我們設計什麼樣的容器來承載這些短資訊和輕任務呢?
錶盤 - 智慧手錶首先應該是手錶,因此錶盤是使用者最常使用的頁面,除了顯示時間之外,我們用它承載最高頻的任務和資訊。
快捷卡片 - 錶盤的空間畢竟有限,而一些中任務和資訊常常需要更大的空間,因此我們設計了快捷卡片,類似于安卓系統的Widght 。
Laucher - 是App 集合,即長尾的資訊和任務
不同於手機的App Laucher ,手錶的Lancher 不是被最常使用的模組,但是卻要承載大量的Icon ,且由於手錶螢幕尺寸的限制,給如何設計出足夠高效啟動器,帶來很大的挑戰(後文將會講述設計和驗證的方法)。
Notification – 智慧手錶作為使用者抬手既得的螢幕,可以主動推動一些任務和資訊,可以在不打斷當前任務的情況下,讓使用者利用微粒化時間快速處理,而Notification 適合承載這些被動任務和即時資訊。
(橫向操作與縱向操作構成立體模型)
加入新的輸入維度
實現單手查看資訊
利用Form 可以製作調用陀螺儀的高保真原型
我們通過設置任務讓使用者打分的方式來量化交互模型體驗
測試後我們發現,加入新的動作輸入後,明顯加快高頻資訊的查看效率,以及在非佩戴手被限制為用戶提供極大的便利。
測試後也發現了一些問題 - 轉動手腕和擺動手腕,只適合做執行任務的步長較短的操作,比在用戶想查看第3 個快捷卡片後的資訊時,這種操作方式並不具備效率優勢。因此我們對交互模型進行了微調,加入了快速切換快捷視圖和消息的方式,用以補足新的交互模型缺陷。
| 通知
通知—— 現在就需要和以後再看
Duwear 的通知處理裡將通知區分為,即時通知- 即現在就要顯示的,在這種場景下用戶的需求是「讓我高效的閱讀資訊」,因此不同於Android Wear 半螢幕顯示,我們將資訊全螢幕化。另一種場景是錯過或歷史的資訊,這種場景下使用者的需求,是幫我快速找到資訊,我們將消息橫向List 化加快查找效率。
即時消息全螢幕顯示提高閱讀效率
歷史消息關注查找效率
化繁為簡—— 將資訊卡片化
簡訊已經成為日常收納資訊的工具,將繁雜的資訊卡片花,並且你可以將卡片添加到快捷卡片,當你想用時只需要抬起手腕 .
將特殊簡訊提取關鍵資訊並做卡片化處理
當你收到影票兌換碼 你可以將卡片添加為快捷卡片 到影院後快速查看
| laucher
小螢幕內的App Laucher 怎樣設計?
我們對App Laucher 的定義是承載長尾功能和資訊的入口,即承載Watch App 的容器,不同於手機, 手錶App Laucher 不會被經常使用,但它會承載大量的App, 所以在設計時我們確定幾個體驗評估的維度:
1. 每屏展示App Icon 的個數
2. 記憶與理解難度
3. 操作的準確性
App Icon 的個數: 9 操作的準確性: 較高 記憶與理解難度:容 易
App Icon 的個數:6 操作的準確性:高
記憶與理解難度:容
易
App Icon 的個數:3 操作的準確性:很高
記憶與理解難度:容易
App Laucher 作為長尾功能和資訊的入口,會承載大量的App, 他的查找效率必須高,這意味這沒屏承載的App Icon 個數要足夠多- 我們首先排除了第三個。接下來我們要確定的是,方案1 和方案2 綜合來看那個更好?我們進行了新一輪的用戶測試。
通過與工程師合作我們實現了兩種方案的Dome, 並且可以輸出點擊的行為資料。測試環節我們關注如下三組資料,以此對比兩方案優略:
A. 連續點擊12 個Icon 的時間(點擊精準度)
B. 連續點擊3 個最常用Icon 的時間(常用App 點擊精準度)
C. 查找特定圖示並點擊的時間 (查找效率)
我們將兩組方案的輸出資料並進行對比,對比測試我們發現,方案1 並沒有由於沒屏顯示圖示數量的增多而明顯降低精準度,方案1 (綠色線)的資料優於方案2 (紅色線)。最終我們確定的方案1 為最佳方案。
| 快捷卡片
如前文所述,錶盤承載最高頻的資訊和任務,Laucher 承載低頻的資訊和任務。那麼用什麼承載中頻的資訊和人任務呢?為了解決這一問題,我們設計了「快捷卡片」,快捷卡片像安卓的桌面Weight 一樣,可以承載資訊和操作,使用者也可以對快捷卡片進行「增刪改」等操作。
使用者可以通過在定位符上滑動快速切換卡片
| 總結:關於作業系統的設計
設計一個作業系統與設計一款App 是完全不同的,當我們設計個新設備的作業系統時我們率先考慮的是—— 這種新的設備用來顯示什麼資訊和執行哪類任務,我們借由「輸入效率」「舒適時長」「便攜性」「展現尺寸」來定義智慧手錶的設備屬性,智慧手錶並不會像手機一樣承載所有的任務,而是像Pad 從PC 中拆分出打遊戲和看影片一樣,Watch 要做的是從手機中拆分出部分任務,並使其效率更高。
其次當我們清晰的定義了設計的屬性,我們必須對這些資訊和任務進行分析,是不同使用頻率的資訊和任務存在於不同的層級,是高頻的資訊和任務抬手即得。
設計作業系統很像建築一所房子(而App 是房子裡的擺件),我們必須清晰的設計房間的結構,劃分功能區域,由一個房間到另一個房間的路線。這也是作業系統設計中接下來要做的--- 儲存資訊和任務的容器以及他們之間跳轉的路徑,即系統的交互架構。
當我們設計新的設備,在設計的新的交互架構以後我們應該考慮是否需要加入新的輸入方式以進一步提高效率。
總結以上系統設計的步驟為:
1. 從資訊和任務維度定義設備屬性
2. 分析資訊和任務的層級
3. 設計系統的交互架構:承載資訊和任務的容器,以及這些容器間跳轉的路徑
4. 檢視是否需要加入新的輸入方式(必須與交互架構協調)
5. 用高保真Dome 檢視設計,並進行持續改進。
6. 設計統一的控制項/ 統一的通知機制