2011年10月24日 星期一

第三個 Android 新作品 - 『車上安心睡』

        暌別許久,我的第三支 Android App 總算誕生上架,而且這算是第一個以我工作室名義正式對外發表的作品。從這麼一個貌似簡單的 App,我體會並學習到了相當多的知識和經驗,正所謂「越是簡單的東西越不簡單」。

        首先整個點子的發想,雖然不是什麼新穎的原創,但卻是我家那讀小學的女兒在公車上自發性地想到,希望做個「讓人可以在車上安心睡覺,並且在車子快到目的地時提醒」的工具。這樣的需求其實確實存在,也早就有人做過相同用途的程式,但為了表達對自己女兒發想點子的重視,並且鼓勵她繼續發表提出更多自己的創意 ( 而且在我的規畫下,這支程式將會符合今年度的目標計畫 ),所以我們全家毅然決然地要把這支程式完成!

        分析了現存的競爭對手 App,很單純地就是從 Google Map 上點選目的地並取得該經緯度座標,然後在 App 執行的狀態中,不斷地輪詢 ( Pooling ) 使用者所在位置,在兩者相距於指定距離內發出聲音提示。

        這類應用程式的原理與架構基本上沒有太大差異,但是我總覺得透過地圖選取目的地點太過繁瑣與不便,而且大多數的狀況,我們要去的地點和下車的車站地點其實是有一段距離。既然車站的位置是固定的,如果使用者又不熟悉那個下車站點的實際位置,為何不能只透過『選擇搭車路線』、『選擇下車站牌』兩個動作就完成設定呢?


        於是,下圖的操作方式與畫面就是我們這次設計的方向:

         然而這樣的設計勢必要導入雲端資料庫的運用,而路線和站點的資料,單靠我們自己實在難以負荷資料輸入的工作量,於是乎,讓全體使用者一起幫忙建立站點資料的 WEB 2.0 概念就形成了

          由於「要求使用者必須保持 App 執行而不能退出這種限制並不合理,所以決定使用「背景服務」的方式來進行偵測,這也是新學習到的開發經驗和挑戰。整個 App 的操作流程也規劃出來:

          「背景服務」的狀態機分析圖:
          熟悉軟體工程與開發的我,做這些設計當然是輕而易舉、易如反掌。然而真正的考驗卻是文件無法呈現的細節之中。所謂『魔鬼藏在細節裡』真的一點都不假。首先被老婆打槍的就是嚴重工程師思維導向不合人體工學之爛介面左邊是原始設計右邊是改善後




          對於如何設計出『使用者一看就會操作』的使用者介面,著實讓我吃了好幾次釘子。

          以工程師的角度而言,新增、刪除、修改是再自然不過的用詞,但對一般使用者,他們卻不懂什麼情況下要選擇『新增路線』,以及『新建路線名稱』是在問什麼鬼東西?所以,改善後的介面,我們用當使用者找不到需要的資料時,腦海裡會出現的念頭來引導他

          『新增路線』變成『沒有我要的』,一整個直接命中使用者內心第一個聲音,很自然地讓使用者選了這個項目因而進行我們要的資料新增功能。而與使用者互動的過程中,也用對話交談的方式來引導使用者輸入資料。例如工程師想的『新增路線名稱』改為對話交談方式的『你要搭乘的客運路線?

          像是這類的調整不勝枚舉。

          另外既然是走 WEB2.0 路線,當然要有使用者回報評價來反應網友提供的資料正確性。原本設計的評價畫面引來所有人的大聲撻伐:鬼才會想使用你這個回報功能。


          看看左邊的資料正確性回報功能,乍看之下專業、豐富、完整!但這完全是工程師看來自爽用的使用者根本就不會專程進入此功能做回報!站點資料錯誤不符合他需要,使用者會直接退出程式;資料若正確,他會直接使用,也不會想要雞婆回報五顆星

          撇開工程師的自爽心態,新的回報機制雖然畫面並不特別,但是卻將回報的動作隱含在一般的操作當中。也就是每次使用者選取站點後,一個看似貼心的確認畫面其實就是誘導使用者進行我們原本需要的資料回報功能。

          這次開發其實還學到許多程式開發方面的技巧與經驗,包含手指操作與地圖之間互動的眉眉角角,背景服務與前景程式介面的溝通與互動…。要聊技術其實有很多心得可以談,但是那些,都比不上這次經歷一個『好的使用者經驗與介面設計』所獲得的經驗與學習那麼重要與豐富!

          也許自己的開發職涯長期在處理後端自動化交易系統太過缺乏與人互動的開發經驗,相信這會是我日後最重要補強的弱點!

Google+ Badge