Pages

Saturday, April 30, 2011

Git-flow 讓 Dev Team 步上穩健開發之路

A successful Git branching model 點圖放大
從去年開始我認識了 Git 這套新一代版本控管,最大不同是,它採取了分散式的控管,每一個開發人員都可以當作 branch,當然會有中樞在定義 master 或者主要開發幹線,當開發完畢要彙整回主要中樞位置,幾乎採取是 merge 的指令,光談 Git 使用,它已經強化了 merge 的功能,而且因為分散式的管理,每一位開發人員都可以自己做版本控管 (commit, reset 等) 當要跟中樞控管溝通才使用 (push, pull 等) 這些種種新的功能特色,讓 open source project 在開發上可以更為的順利與方便。

既然 Git 在 branch 開設與事後 merge 這方面強化,在開發上是否有更好的開發模式,來協助我們軟體開發呢?

Git-flow 是一套成功 Branch model 開發經驗而設計出來的協助工具,當安裝好之後,在 command line 下 git-flow 即可知道它的功能樣貌。

主要分為幾個主要幹線和分支之間做交互轉換。接下來以開發一個從 0.2 進入 0.3 版本階段為例,這個開發里程碑裡面,需要完成三個主要 features:為軟體的 UI 做動線改善、UI 元素的修正、需要將物件導向的 data model 做翻修調整,套用在此 git-flow 上,作為一個使用 git-flow 生命週期介紹。

首先準備好 master 和 develop 這兩個主要線,master 是做為最穩定可以交付出去的版本路線,develop 是開發人員的開發路線,這邊是有最新功能的路線。
 
Day 1~2 將 UI 做動線改善,採用這樣指令 git-flow feature start uiNavigationArrange,於是幫在 feature 類別裡面,開設了 uiNavigationArrange 的 branch,於是任何程式開發都在這裡做 commit,如果需要同仁協助,就 push 到中樞管理位置,讓同仁可以一起開發。當完成後,下達 git-flow feature finish uiNavigationArrange。於是 git-flow 幫忙把此 local branch delete 掉,merge 回 develop 路線,再將 develop 路線 push 到最新位置,讓同仁可以做同步。

Day 3 將 UI 元素修正,採用 git-flow feature start uiElementsEdit,於是在 feature 開設了新的 branch,將畫面需要各種元素控制項做些調整之後,下達 git-flow feature finish uiElementsEdit,於是 git-flow 幫忙把 local branch 移除掉, merge 回 develop 開發路線。

Day 4 將 Data model 調整,採用 git-flow feature start refactorDataModel,於是在 feature 開設了新的 branch,將物件彼此間做些調整與擴充之後,修改完成後,下達 git-flow feature finish refactorDataModel,於是 git-flow 幫忙把 local branch 移除掉, merge 回 develop 開發路線。

Day 5 要做版本 Release,採用 git-flow release start 0.3,於是從原來 0.2 的進展到本次新版本 0.3 的路線,進入測試階段,過程如果發現想要些微調整都在此 commit,完成確定此版沒有問題,採用 git-flow release finish 0.3,這時候就是 git-flow 幫忙,它會砍掉此 release/0.3,幫忙下 tag v0.3 (如果當初開始 git-flow 有為 tag 做 prefix 'v' 命名,這邊會自動加上去),且 merge 到 master 和 develop 路線,於是範例產品 0.3 版誕生了,此版功能有改善 UI 動線、變更 UI 元素控制項、後面 data model 的修正。

如果上線發現有問題要修,就可以採用 hotfix 的方式來做些調整與修正,回饋到 develop 路線,也作為 master 的修正。

以上是一個套用在開發專案或者產品所採用的開發範例,git-flow 讓開發過程站對腳步,又能將過程做個完整紀錄,不論開發團隊人數有多少,相信套用此模式開發,能讓 Dev Team 步上穩健的開發之路。最後要感謝 ihower 的部落格文章 Git flow 開發流程 介紹,以及圖片來自 A successful Git branching model 的文章。

Sunday, April 24, 2011

Whats the difference between UI Design and UX Design

From Quora, Dan Saffer, Interaction Designer and Author
在 Quora 網站上,有個討論主題是 "What's the difference between UI Design and UX Design?",在這篇的下方可以看到相當豐富的回答。

而從回答來做簡單歸納是:
UX 設計了整個物件主題的經驗,跟如何來使用這個產品或者服務有非常關聯關係。
UI 是設計該產品或者服務的使用者介面,UI 可以視為 UX 的一個部份,但是很多好的使用者體驗未必有 UIs。而在設計 UI 時候需要透過 UX 設計來做資料整理和程線,受到影響比較大。而對於 UX 而言不會被 UI 給受限。

我過去閱讀的互動設計這本書。對照到此圖,是位於整個 User experience design 裡面蠻重要的一環,它牽扯到人類行為,聲音設計、和人機互動設計等。而在互動設計這本書也探討過不同領域的設計概念。

但是在這個圖裡面還有一部份是在談 Content 和 Information architecture,這部份是在探討資料如何組成有效的資訊呈現給使用者來看與使用,是否快速導到使用者想要的地方,是否可以快速瞭解此產品要傳遞怎麼樣的資訊。這在資訊架構學主要著墨的。

回到整個 User experience design 來看,我們要設計好一個產品或是服務,有哪些面向我們要注意:
  • 資訊的呈現與動線
  • 內容提供什麼 (文字、影音、聲音、圖片)
  • 視覺設計 - 是否讓產品本身外觀看起來酷炫,有別於一般同類型的產品。
  • 人機介面互動
  • 聲音設計 - 是否在適當的時機提供恰當的音效或是音樂回應得使用者。
  • 工業設計
  • 架構
下次當我們要分析一個產品的使用者體驗好與壞,我們可以從這些面向來做分析,得到綜合分數就可以拿來衡量此產品跟競爭產品之間,誰的使用者體驗比較優了。

Sunday, April 17, 2011

Tells that the region just changed from MapView

我在開發某 iPhone app project 期間,當時 version 0.5 還沒有實作很多功能,有邀請了年輕的朋友 Bill 來體驗我們的 app,協助 Usability test。我跟 Bill 說明此 app 設計的目的,並且給他我的 iPhone 操作,題目是從手機上瀏覽商品搭配地圖使用與操作。而 Bill 在操作時候,我在旁邊靜靜的觀察。Bill 對於這套 app 很好奇,會切換到地圖上瀏覽,會觸控移動地圖看看效果,並且點選商品進去看詳細資料。

事後我的紀錄整理,在開發沒做完的功能會誤按到,所以 Usability test 過程會遭遇卡卡的。但是對於已經開發的地方尚可。商品在相簿瀏覽等待網路傳輸 Loading 會很久,造成使用者沒有耐心往下看。另外我在觀察有帶來新的發現:使用者希望移動地圖的同時,可以插入更多針,顯示更多的商品。這功能可以讓我們的 app 帶來很不錯的體驗,是我們在開發時候未曾發現的,這也是我們本次 Usability test 最大的收穫。

回到 iPhone app project,我開始思索如何來實作這個部份。想當然兒應該會從 MapView 著手研究,我查詢了 iOS Library document 發現有一個 Method 可以幫助我們。

Sunday, April 10, 2011

Paper prototyping for iPhone apps

iPhone apps 的 Paper prototypes 會包含整個裝置、組合的螢幕、重疊浮出視窗、和一些操作控制項目等。要畫一個 Paper prototypes 可以簡單分為三個步驟:
  1. 準備原料和素材:當我們要在腦力激盪討論場合用、當我們要把設計草稿畫出來時候,這些素材項目對於畫 Paper prototype 是很有幫助的。如果可以話也包含重複用的紙卡、可以反覆貼的膠帶、膠水和剪刀等等。
  2. 辨別整體版面形式:有時候可以畫跟真實 iPhone 畫面解析度一樣 320 x 480 pixels (iPhone 4 是 640 x 960),當然 paper prototypes 可以不用那麼確切。如果考量畫比原來更大的表格畫面,可以在跟別人互動設計上更方便。
  3. 開始畫 prototype:Prototype 會包含整個裝置形式、螢幕和使用者介面的控制項目等。可以做出些被選取 highlighted 和沒被選取到 non-highlighted 的版本樣式。如果還沒決定好要放的 icon 也可以先用文字代替。
點圖放大
素材方面,使用者介面常用的控制項目可以準備哪些?
  • Keyboard:可以自己手繪鍵盤樣式或者拍照下來。沒有必要一定要把每一個按鈕畫出來,但是把焦點放在特殊鍵和專門給 email 輸入或者純數字輸入的表達地方。 
  • Sliders:可以畫出使用者在操作上選擇到的大約位置。 
  • Text entry:對於文字輸入地方,使用者可以先寫在 Post-its 或者反覆貼上,再將這貼到 Prototype,這樣可以不影響到既有的畫面。 
  • Navigation bar:這在對於使用者現在所在的頁面位置很重要,上一頁到哪,按下另外的按鈕可以有哪些特性,都可以表現出來。
  • Search Bar:對於大量的列表資料可以讓使用者輸入做搜尋與過濾所需。
  • Image View:可以表達出個人的圖像或是應用程式要呈現商品的圖示。
  • Segmented controls:使用者可以點選出幾種選項,做出些切換的效果。 
  • Loading page indicator:當程式在運作會有等待的時候,顯示出等待轉圈圈的 Indicator 讓使用者知道請稍候。 
  • On/off switches:做出類似啓動關閉的按鈕,讓使用者可以做開關的選擇。 
  • Check mark:當使用者做出選擇了,表現出勾選的樣式。
  • ......還有更多控制項元素。

Paper prototypes 好處只有在快速的畫出與概念表達出來時候,才能達到提升協同討論和降低開發成本。 畫的太細緻是沒有那個必要的,使用者通常知道細節部份,所以我們只要可以表現出使用者看可以想像的出來即可。一樣的如果在準備 prototype 來做研究,不用擔心是否把介面元素畫夠仔細,反而的漂亮的 Paper prototype 是隨意畫出整個樣貌,添加控制項有如像飛的速度般在進行。
照片上是在 UI Stencils 購買的 iPhone Stencil Kit,仔細的瞧瞧它包含了我們設計上所需要常用的控制項與 icon,甚至它把畫 Prototype 所需要的等距都有明確定位出來。如果有興趣可以參考官網 http://www.uistencils.com/products/iphone-stencil-kit

Monday, April 4, 2011

Get distance between two location from CLLocation

Get distance
在開發 Location based system 的 iPhone app,我們會想要做出哪些特性。使用者現在所在位置這很重要 (Finding your way with Core Location),透過一些地理服務來描述使用者所在地的資訊 (從 MKReverseGeocoder 解析更多地理資訊),會把使用者附近所要的資訊顯示在地圖上 (Learning Flyweight pattern by using MKAnnotationView),如此一來可以做出很豐富的應用了。

如果今天我們要做到現在使用者距離這些地標各別距離有多遠,如果可以把這些資訊顯示出來,一定可以帶給使用者很有感覺,對於要找這些地標可以做出更好兩點概念。那麼我們要如何求出座標兩點距離呢?

這概念要從兩點經緯度來看,而在 Google search 座標距離,網路上也蠻多公式在求計算這些距離位置。回到我們的 iPhone app 上要怎麼求呢?很慶幸的是 Cocoa 已經有內建,從 CLLocation 有提供換算的 method。

iPhone app 與 Web service 的溝通良好關鍵在 API 設計

API
我們在使用 iPhone app 如果不是單一在手機上操作,任何像是 Facebook, Twitter, Foursquare 等等結合,讓使用者可以透過 iPhone app 從 Anywhere, Anytime 都可以操作服務,當回到電腦前打開瀏覽器也可以看到剛剛的資料,這樣的概念已經在我們現在 Web 3.0  (Social, Content, Mobile) 文化很常見了。而 iPhone app 在跟 Server 這邊透過網路帶出豐富的資料,以及透過手機輕巧隨時可以輸入的特性傳回資料給 Server 上,這樣的合作模式是需要良好的溝通默契的,一切都建築在 API 的良好設計上。


API (Application programming interface) 是一個特定的規則讓軟體開發雙方可以存取使用些服務,只要透過 API 溝通,Server side 可以選擇任何語言開發,而我們 iPhone app 則可以用 Objective-C 搭配 API 溝通的 Library 來連接。而在像是 Web development 上,API 是定義 Hypertext Transfer Protocol (HTTP) request 訊息,包含傳輸的內容,而內容格式通常會使用 Extensible Markup Language (XML) 或者 JavaScript Object Notation (JSON) 格式。而當這樣的形式來規劃平台即可做出 web service。


所以要設計出整個合作服務,我們需要的要件有:
  • API 文件。此來描述 API 長相,會有哪些開放的 Request URL,會需要傳送哪些 parameter 當作條件,會回傳哪些資料,內容的 key value 的長相。
  • API 內容格式。是採用 XML 還是 JSON,內容會是長怎麼樣子,這些影響到 iPhone app 解析上所需採用的相關 Library。
  • API Key。申請 API key 可以讓 Server 在處理網路外在呼叫進來所代表的身分,是來自登記哪一方的。這樣可以作為是否合法登記與授權過的信任來源。身為 Client 的 iPhone app 要當個好的公民,呼叫 API 也要呼叫的有禮,夠用的 Request 即可,不要造成自己網路負擔之外,也造成 Server 端的負擔。Server 端設計上也可以去紀錄哪些 request 是由哪些登記的 API_KEY 進來的,這樣在查不好的存取時,可以做出追蹤與查明原因。
  • 登入機制。每一家的 Web service 提供的登入機制都不同,身為開發 client 端的 iPhone app 要瞭解,這樣才能進行登入後後續的 API 操作。


在 iPhone app project 的設計規劃:
  • 如果今日 Web service 的 API 已經訂好,那麼我們在開發上 Data object 設計盡量以 Web service 回傳的內容格式的 key 為主,這樣開發上比較不會造成 naming 的誤解。所以我們在開發網路 Request 那邊程式僅需做好溝通與將內容資料轉換,塞進我們的 NSObject 讓 iPhone app 其他的程式 layer 使用即可。
  • 我們在 View Controller 或者是 Data source 的相關程式就可以依照我們自己來設計,專注做出自己想要的形式。
所以根據以上規劃,我們的 iPhone project 各個 layer 即可做出好的角色分工,以 MVC 的架構來說,Model 的部份做好 HTTP request, 資料轉換, 資料塞進 Objects 。而 View, Control 不需要知道 API 不要去管資料轉換問題,而是要以我們 Mobile 優勢做出好的使用者體驗。程式在開發上也會比較好維護與可讀性才會比較高。


一份良好的 API 設計,可以讓我們 iPhone app 在操作上行雲如流水,資料接的天衣無縫,讓 iPhone app 操作起來非常愉悅之於,資料也會很豐富的呈現在使用者眼前。

Saturday, April 2, 2011

Hackathon in one day

Hackathon
你參加過 Hackathon 嗎?Hackathon 是一個活動讓 Developers 聚集在一起,一同合作開發寫程式,針對一個題目開發討論到開始實作測試,希望在有限的時間內可以做出一個成果。

這跟平常我們工作上開發會有什麼不同呢?平常開發針對分配到的工作會去切割細分,排定到每日工作,可能一天除錯一兩個大任務,可能一天開發一兩個大功能就差不多。但是 Hackathon 是讓所有參與的開發人員站在同一個火線上一起開發,速度和穩定性要求是相當的高的。

很榮幸在幾天前,我第一次參與,和工作上同仁自己舉辦了約 5 人規模 (兩位參加過 Hackathon 活動,三位沒有), 限定一個工作天的 hackathon 活動,我們希望可以做出可用的作品,定了一個社群的服務的主題,最後產出會有 Web 端可以用 Browser 連進來、Server 端資料負責儲存和運算、Mobile 端可以讓使用者拍照紀錄留言的整合。時間從早上 9 點鐘開始進行,過程當中除吃飯和上廁所之外,剩下的時間就是要非常專注的共同討論與一同開發。

好的合作模式:

  • 活動開始前一到兩個小時,確定題目和方向之後,開始腦力激盪討論可以做到的需求,先從發想開始,再開始收斂分類,找出我們今天內可能達成的目標。
  • 彩色便利貼是我們合作上很好的工具,我在之前 Post-it! My knowledge wall 文章有分享過,使用便利貼可以讓大家瞭解目前進展,全貌是什麼,也方便歸納與分類。
  • 使用了 37Signals's Campfire 系統,讓大家可以共通討論,搭配程式更新的資訊發佈,大夥們有在同一個火線上的感覺。
  • 充足的飲食,可以讓開發人員保持愉快心情之餘,也可以減少很多不必要的外出時間。
  • 在系統建置初期資料還沒出來前,先用 Mock Data 也可以為稍候的程式做開發與準備,不會因為要等其他隊友而呆滯。
  • Quick and Dirty,敲定好目標與範圍,馬上開發,程式碼要寫好,因為影響後面測試整合,甚至活動結束後還要持續開發,程式碼最重要,文件先不急。
  • 使用 Git 和 github 做好版本控管,利用 branch 之間 master 切換與 merge,讓開發可以上軌道。

一天運作下來,我們也會發現缺陷可以列入改進讓下次更好:

  • 要知道時間有限,非常的珍貴。
  • 要知道自己今日參與扮演的角色,負責開發的項目。
  • 平日要對於自己開發上可能會用到的工具要夠熟悉,這樣上火線才能快速打造。
  • 開發上卡住一定要求救。
  • 溝通規則要訂清楚,何時可以求救,如何求救。何時同仁可以被打擾,何時同仁不能被打擾,要先講清楚,這是考驗默契的地方。
  • 開發能力與經驗很重要。這是平日功力的累積,一上火線優缺點都會被放大,開發需要翻找資料花費時間、功能做不太出來要找原因花時間。讓隊友可以銜接自己開發程式功能順利,是個不錯貢獻能力。

在 Hackathon 活動讓我印象最深刻是,負責 Server side 的隊友在啟動整個程式專案,Launch and build up 整個 service 和 API 之快,讓我們 mobile 的開發人員可以趕緊接上整合測試,這是個多麼欽佩與學習的榜樣。 同時也內心問自己,我選擇負責 iPhone app 部份,我的開發速度夠不夠呢。

我在學習 互動設計,在 Usability Test 有一種方法是透過錄影來觀察使用者操作系統的行為,作為後續改進的參考所用。愛好運動看過 NBA 球賽也知道,每場球賽結束,教練也會跟球員一同再看重播節目,來進行討論與改進。如果進行 Hackathon 過程能夠有個錄影機在旁錄影,那麼這效果會非常好,一天紀錄下來,誰在討論開發階段做出好的示範、誰在開發上露出哪些不好缺點的都可以獲得記錄,作為未來更好的紀錄參考方式。

最後,身為開發人員的你和我,不論過去在學校上機測試有好的開發本領,或者過去工作上在解刁鑽繁雜程式議題有相當經驗,一定要親身參與這樣的活動,這樣即可發現自己的優點和缺點有哪些,可以作為自己未來不論是個人開發的技術養成,或者跟團隊合作的經驗,可以有很不錯實質的幫助與收穫。