【3S Market】可穿戴產是否將是兩岸在國際市場另一個角力的焦點？以下文章給各位中智慧手表的實作觀摩。也請大家來思考：面對中國廠商，台灣中小企業未來發展之路，要將中國廠商視為「盟友」、「夥伴」、「競爭對手」；或是…「死敵」?
按：本文來自百度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適合承載這些被動任務和即時資訊。
- 從「容器」到立體的交互框架
如果容器是承載著資訊和任務一個個的房間，那下一步要做的就是將這些房間建立起聯繫，以此建立Duwaer系統的骨骼-交互架構。在Duwear的交互框架內將操作分為兩種：橫向操作和縱向操作，確保空間的秩序性，易於理解和記憶。配合新的輸入方式，借此創造適合手錶單手操作的全新交互模型（輸入方式部分在下文詳述）- 從「容器」到立體的交互框架
（橫向操作與縱向操作構成立體模型）
- 新的交互架構配合新的輸入方式
怎樣讓手錶在執行輕任務和查看短資訊時，效率進一步提高？僅僅在交互架構層面做改進遠遠不夠，我們在交互架構更新的基礎上，加入了新的輸入方式 - 轉動手腕和甩動手腕。經過使用者體驗測試，新輸入方式的加入使高頻資訊的查看，和雙手被佔用的場景效率明顯提高。- 新的交互架構配合新的輸入方式
加入新的輸入維度
實現單手查看資訊
- 對新交互模型進行使用者測試
為了對新的交互模型進行驗證、反覆運算、調整。我們利用Form製作高保真原型進行用戶測試- 對新交互模型進行使用者測試
利用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.設計統一的控制項/統一的通知機制
0 comments:
張貼留言