Pages

Wednesday, December 29, 2010

Using PushPop demo to learn basic Navigation Controller

在 iTunes U 上面有一系列非常有名的 iPhone application development program在 Stanford 開的課程錄影。而在該堂客講師 Josh Shaffer 講到 Navigation 時候,我邊看著影片也邊跟著動手做了簡單的 Demo來學 Navigation Controller 的功能。這個範例透過 Navigation Controller,讓第一頁開啓後,畫面上顯示一個按鈕,按下按鈕,會轉換到第二頁,再從上方可以點選 Previous 按鈕回到第一頁,達到彼此 Navigate 效果,非常簡單的體驗,後來我也額外加入了第三頁,讓它可以做到三層 Navigate 效果。

Navigation Controller 採用 Stack-based design 概念,用了『先進後出 First in last out』的做法,而透過 Stack 相關辭彙 push, pop 來做出放進取出,所以當程式用到 push 時候,是往下更深入走一層,用到 pop 時候,是往回走到上層。每一個 Navigation Controller 擁有一個 root view controller,當走到 Root 時候,就是為最上層了。

使用 Windows base application 做起頭,將 Project 命名為 PushPop。在 Classes 區新增兩組 ViewController 以及包含 .xib 檔案,命名為 FirstViewController 和 SecondViewController, ThirdViewController。

在 FirstViewController 定義一個 IBAction pushViewController 的 method,在 xib 檔案透過 Interface Builder 拖拉出一個 Button 並且把它 event 效果和這個 method 串連起來。這樣我們可以回到 Implement 檔案將該 Method 實作。

在 SecondViewController, ThirdViewController ,只要打開 xib 檔案在 Interface Builder 裡面拖拉出一個 UILabel,顯示訊息,這樣即可。

一開始會有 PushPopAppDelegate.h,裡面宣告 UINavigationController,打算從 Xcode 裡面裝置 Navigation Controller。

接著在 Implement 檔案 PushPopAppDelegate.m 裡面開設實作


因為我們預計在這邊來規劃我們的 Navigation Controller。這個 method 會在 application launch 結束後,最先進來的地方。並且將 FirstViewController 宣告初始化,可以設定它的 title 為 "First",接著讓 Navigator Controller 一開始就 push view 為 FirstViewController,在把這個 Navigator Controller 加到 window 的 subview。如果這時候 Build & Run 已經可以看到一開始畫面是 FirstViewController 了。


再來進入到 FirstViewController.m 實作 pushViewController method,在這邊將 SecondViewController 宣告初始化後,將它標題設為 "Second",接著再把 Navigation Controller pushView 設定為 SecondViewController,將 Animated 效果設定為 Yes。


而要將 SecondViewController 導到 ThirdViewController 在實作 method 地方加入 pushViewController 導到 thirdViewController。


當完成以上後 Build & Run,即可從模擬器裡面簡單做出三個頁面和彼此互相 Navigation 的效果。以上如果有興趣可以到 github 上面進一步瞭解 Code edwardinubuntu / PushPop

Monday, December 27, 2010

Protocol in Objective-C

Protocol 在 Objective-C 裡面,是定義列出一系列 method ,讓任何 class 想要接上這個 protocol 的 class 並且實作它們,但是 protocol 不能新增 instance variable。宣告時候想引用多個 protocol,寫法上是 < protocol1, protocol2 > 。

我們來看放在 UITableView.h 裡面的 UITableViewDataSource :

@protocol UITableViewDataSource

他可以在 method 清單裡面,規劃不同區域出來 @required 和 @optional,最後以 @end 作為結尾。顧名思義 required 的 method 在 implement 上都要實作,而在 optional 區域裡面,可實作可不實
。所以這樣在呼叫的這方,在呼叫到一個 optional 的 method 前,記得要加上判斷,不然在未判斷以前,呼叫執行進去,即會發生 exception。若要檢查物件是否有實作 protocol 定義,,用 conformsToProtocol 判斷,寫法如下:


它很像 Java 的 Interface,定義出 method,並且讓想要使用的 class 來 implement,但是開發上又不太一樣。Protocol 在 iOS 開發上,主要用於 Delegate。反觀 Java 的 Interface,單一個 Java implement class 可以 implement 多個 interface 檔案,但是都必須要去實作它們。無法像 Objective-C 這樣給與 optional 不強制一定要實作完成。

Protocol 可以拿來當一般的型別使用,例如:

id myBook;

這意思說 myBook 必須是要實作 Document 這個 protocol 的物件,才能接收進來。也讓 Compiler 可以事先做型別檢查。

另外這邊以另外一個例子:

@interface Document

意思是,Document 這個 class interface 加入了 Document protocol。然後今天我們要寫一個 Method 可以做到加入文件,如果說這個 method 最後要判定是否加入文件成功,我們也希望傳進來的是有加入 Document protocol 的,在寫法上可以加入這些判斷:


所以碰到傳進來是要 protocol,且要判定測試它是否有此 protocol,用 conformsToProtocol 判斷。

另外回來看 header 檔案的 interface,定義上算是這樣同樣命名的一組 (*.h, *.m ) 的介面,但是它裡面可以配製 variables,和定義 methods。 再由 implement class 來實作該 header 檔案。而在 extend 方面,都是交由 header 來處理,而 implement 檔案部份只要實作就好,規劃出物件導向設計。

以上如此看來 Objective-C 的 Protocol, Interface, Implement 和 Java 的 Interface, Implement 在設計開發上,即可瞭解雙方的不同。

Saturday, December 25, 2010

從 iPhone 上的 Twitter App 學習互動設計的目標

互動設計的目標是在設計一個互動系統時候,瞭解使用者的需求來確認主要的目標。這其中要包含滿足特定的使用性標準,例如有效性。而使用者經驗的目標關於使用上的品質,包含了富有美感、愉悅的,所以從這兩大概念對照到 iPhone 上一款有名的 Twitter app 互相搭配與分析。

使用性目標可以分為幾個項目:

有效性:這是最普通的目標,指的是系統能否做到使用者該做的事情?從 Twitter app 它可以讓我們完成發 Tweet、接受最新 Tweet、列出是否有人提到我和關鍵詞搜尋等等。

迅速性:這是指系統支援使用者完成工作。使用者是否最有效率的經過最少的步驟完成工作。從 Twitter app 透過 Tab bar 方式來分類,可以快速切換找最新資料、切換到是否有人提到我、是否有私人訊息或者進入搜尋區域。透過 Table view 來顯示每一筆 140 字元內的 Tweet 列在畫面上,符合使用者可以用手指上下捲動來瀏覽。使用者可以在想要做事情到完成它動作,非常的方便與快速達成。

安全性:保護使用者遠離危險非預期的情況。藉由降低按錯鍵或按鈕的風險,以防止使用者犯下嚴重錯誤。提供使用者復原各種出錯狀況的方法。以 Twitter app 為例,今天如果我打了好幾行的 Tweet 過程,不小心按到畫面上的 Close,它會跳出問是否 Save or Don't Save 機制或者取消再回到畫面繼續編輯。這一關相當重要,不論是誤按、或者臨時不想打完想跳出也可以暫存、或者想取消直接離開,都是對於使用者進一步確認的關鍵點。

功能性:正確的功能類型,以便使御者可以做他們想要做的事情。Twitter app 提供了暫存機制,提供了搜尋的功能,可以加入最愛,可以 Re tweet 等等特色,符合了使用者在使用這套軟體想要完成它想要做的事情。

易學性:學習此系統的難易度。Tweet app 在透過網路要跟 Server 要資料,統一都是用滾動從最上層拉 Bar 機制,拖拉放開來更新,這樣不論在哪一個 Tab 裡面都是以此來更新最新資料,另外界面透過 Tab bar 分類頁面,並且在上面擺出了我們熟識的 icon,這樣相當容易知道現在要到哪個頁面區域,再且如果有最新資料,下面會有亮藍燈來抓住使用者的注意,所以以上這些方式相當容易上手。

易記性:使用者在學習一個系統時候,可以多快速與多容易回想使用方式。由於 Tab bar 介面與容易記的 icon 和 Table view 來顯示資料,加上有趣的下拉捲動來更新資料,且通常我們在新增某些資料,功能習慣放在上方,而 Twitter app 也是把發佈新的 Tweet 放在右上角有隻筆的小 icon。這些對於使用者很快就可以學會之外,如果隔很久沒使用,回來看到此畫面也容易上手。

再來談使用者經驗目標,互動設計不是僅止於關心使用系統上的高效率或者高生產力,也要能具備令人滿意 (satisfying)、愉快的 (enjoyable)、有趣的 (fun)、具有娛樂性的 (entertaining)、啓發動機的 (motivating)、美學愉悅感的 (aesthetically pleasing)、激發創造力 (supportive of creativity)、有回報的 (rewarding)、讓人情感滿足的 (emotionally fulfilling)。

從使用者經驗目標來看 Twitter app ,它的人物主角的大頭照顯示和帳號暱稱與 Tweet 內容安排上,大小位置控制相當好,讓使用者閱讀起來相當有質感,可以獲得滿意之於,還能被激發動機,把它再 Re tweet 出去。且更新資料用手指來滾動畫面來更新資料,令人使用起來相當愉快與有趣。我想當我們使用 iPhone 上面的 Twitter app 覺得相當棒好用時候,它的背後已經蘊藏了豐富的互動設計知識在裡頭了。下次不論是身為一個使用者在使用一個互動軟體,或者身為開發人員在開發一個軟體時候,想要讓系統更好用或者批評自家他家一個糟糕系統,何不拿以上這些分析指標來評估呢!

想了解更多也可以參考 互動設計(二版) - aNobii 何謂互動設計

Thursday, December 23, 2010

File's Owner


在 iPhone app project 裡面 Resource 區,都會看到 Nib 這樣的檔案,而每次開發時候將它用 Interface Builder 打開,在 Window 區就會看到固定有 File's Owner,而這和 File's Owner 又有什麼關係呢?

一份 Nib 檔案會以 dynamically 動態的方式在 Run-time 期間載入,回應使用者給與的事件,類似按下按鈕、做選單等等。在 Nib 檔案裡面的 File's Owner 是一個物件用來做新的 Nib 和舊的已經 app 產生的部份做溝通,像似 App 已經有建立好 instance of an object,希望可以傳進去檔案,需要知道 IBOutlet 是接到表單上的哪個欄位。所以 File's Owner 在 Apple document 上比喻為 proxy。

在 Design Pattern 裡面,Proxy 是這樣定義:"Provide a surrogate or placeholder for another object to control access to it." 會有 Proxy 這樣出現,一個大的好處是控制 access 到 object 時候,根據需要時機,再來建立和初始化,而且那種越貴重的 object 越建議這樣,當需要時候才建立。

Nib 檔案是用像似解凍準備執行樣子,這樣對於 App 可以更模組化降低記憶體使用。 Nib 檔案可以根據需要用到裡面物件時候,再被載入到記憶體當中。當 Nib 檔案需要被解凍,需要一個 pointer 對應到 object,而就是 File's owner。File's owner 會允許授權裡面的 object 和已經存在的 object 做串連。所以某方面 File's owner 扮演了新的 object 和舊的 object 之間的橋梁。

Implementing a Search Bar

在 iPhone app 裡面我們使用 UITableView 來呈現大筆資料,使用者透過手指可以上下移動來瀏覽資料,如果資料筆數多可以加入 Index 在畫面的右手邊輔助,但是如果資料還是太多,我們要找其中特定一筆還是要捲動半天。所以如果提供給使用者有一個搜尋的功能,讓使用者輸入 Term 來找資料比數,這樣用起來會更貼心。雖然要一點功,但是也不會太多拉。所以這邊來說明一下怎麼加入 iPhone search bar。從設計概念上來說明,步驟要完成哪些。

首先要從新思考 Design,把原來 plist 資料直接顯示在畫面的,要抽離出來,另外放到 NSDictionary ,如此才能讓使用者查詢時候,將資料過濾過再顯示在畫面上。

每次搜尋條件清空,開設 method mutableDeepCopy 要將 NSMutableDictionary 重新再 copy 重來一次。

針對 SectionsViewController.h header file 重新整理一番。開出 UITableView 將畫面可以在 Xcode 做些控制,例如 reload data, UISearchBar 新加入搜尋列, NSDictionary 將 plist 內容讀出放到這, NSMutableDictionary 將資料拆成 Mutable Dictionary, NSMutableArray 用來控制 key, BOOL isSearching 來告知目前是否正在搜尋,可以幫助一些判斷用。

修改 View,加入 UISearchBar,並且提供 cancel 按鈕。另外將相關的 Outlet 都串聯起來,作為後面 delegate 時候所需。

再來要針對 SectionsViewController.m 裡面來重新調整一番和覆寫些 delegate 的 method。有三個區域 Table View Data Source methods、Table VIew Delegate methods 和 Search Bar Delegate methods 等等。

在 github 平台上面,我開設了一個 Section project,透過 tag 紀錄來切出練習題的版本出來。剛好 github 這邊功能很貼心,可以列出每次 commit 和前次的差異,所以我們從這個紀錄統計可以看出,有 6 個變更檔案要介紹。並且透過 https://github.com/edwardinubuntu/Sections/commit/ 這一次 commit 頁面解析,紅色為移除掉程式碼,綠色是新增程式碼。再搭配前面描述那些步驟順序對照,即可很清出看出修改上的差異了。

開發上要注意到,在加入這些 delegate 所需要的 method 時候,命名上大小寫要小心,不然在測試時候,會跑不出要的特效。所以在相關行數加入中斷點 break points 並且使用 debug mode 來跑,才能確定程式都有跑到,例如需要 searchBarSearchButtonClicked, searchBar: textDidChange:, searchBarCancelButtonClicked:, searchBarTextDidBeginEditing: 等等各種觸發事件。另外寫的時候,如果有宣告 IBOutlet,在 Interface Builder 要記得將這些串聯起來,不然會發生程式明明都有寫對,為什麼開啓模擬器測試,卻畫面沒有出現預期的效果。


以上除了可以參考書本 Beginning iPhone 3 Development 章節 Implementing a Search Bar,程式碼完整收錄在 edwardinubuntu/sections,tag v0.1 有右手邊的 index 輔助查詢、tab v0.2 加入搜尋輸入欄讓搜尋資料過濾更容易。

Tuesday, December 21, 2010

Selector in Objective-C


Xcode
在物件導向程式語言,呼叫 methods 是一種由記憶體呈現控制實體端點指到程式碼,這樣對於設計程式會有限制,所以後來有 "command handling" 這種的需要,這被組織收錄在 Chain of Responsibility design pattern 中。

Chain of Responsibility 裡面的定義:"Avoid coupling the sender of a request to it's receiver by giving more than one object a chance to handle the request Chain the receiving objects and pass the request along the chain until an object handles it."規劃動機是希望可以分離 senders 和 receivers,透過多個 objects 來處理這些 request,request 就一直傳遞直到有真的實作的部份。


而 Cocoa 使用了以上這種方式,使得 Objective-C 的 late binding 開啓了更多的彈性。 在 Objective-C,methods 可以用 selector 來當代表呈現,一個字串來形容描述 method 要被呼叫的。當 message 傳遞,selector 會在 run time 時候傳遞出去。對應到符合的 method,然後進入該實作的 method 裡面繼續執行。

"selector" 有兩種含意。一種是可以當使用到程式碼對照 (source-code message),來參考對應 method 名稱。二種是可以是當編譯過後,參考到獨特定義名稱。編譯後的 selectors (Compiled selectors) 是使用型態 SEL。所有同樣名稱擁有同樣的 selector。可以使用 selector 來觸發啓用該物件的 method,這在 target-action design pattern 有用到。

編譯器會把每一個 method 名稱寫到 table,那個名稱就會成為獨立的辨識值 (identifier) 呈現在 runtime 時候。Runtime system 會確定每一個 identifier 是獨立的,沒有兩個 selectors 會是一樣,所有 methods 擁有同樣名稱,會擁有同樣的 selector。


以此為例,定義一個 SEL,讓它分配成為一個 method。而且實際實作的 method 是在 Runtime 才去察看,不是在編譯階段。這邊可能會有點 performance 探討,但是使用這種 late binding 可以讓同樣 selector 去對應到不同的實作。


在 Target-Action design pattern 裡面,我們平常都是會在 xxx.h 裡面去宣告我們的 method 定義成為 IBAction,再到 Interface Builder 裡面拖拉元件,配製事件連到某某 IBAction,這邊也是透過 selector 方式來指定 method 的。

在配製 selector 裡面的名稱時,要注意 method 名稱。例如配製一個 NSString 裡面的 lowercaseString,就要寫 "lowercaseString",而不是 "lowercaseString:" (多了 ":" 符號)。因為這邊要看該 method 是否需要傳遞參數,而對照到 API,lowercaseString 是不用傳遞參數的。那什麼時候要加入呢?當需要傳遞超過一個以上參數時候,要給與 ":" 符號,例如 "compare:", "options:", "setSize:" 等等。


另外想了解更多可以額外參考 wikipeida 上 Cocoa (API) 的 Late binding 以及 developer.app.com/library 的 selectors 文件。

Monday, December 20, 2010

Customizing Table View Cells

Tabel View 是一種在 iOS 裝置上面顯示多筆數的資料元件,其中每一筆稱之為 Table View Cell。在 Table View Cell 裡面提供了一些預設的 cell 樣式,default 樣式可以顯示圖片和文字在同一行、subtitile 樣式可以顯示細節比較小灰色字體在主要文字下方、Style Value 1 讓主文字靠左細節項目靠右顯示、Style Value 2 讓細節項目顯示在主文字的左邊。如果今天想要呈現不是 UITableView Cell 提供的,我們有兩種方式可以達到,一是直接在 UITableViewCell 加入 subviews,二是為 UITableViewCell 建立 subclass。

方式一、加入 subviews 到
Table View Cell
在 CellsViewController.m 裡面實作基本的程式碼,例如初始化要宣告哪些值配製,這邊參考 code 即可,比較值得提的部份是:


在 UITableViewCell 初始化時候,規劃 CGRect, UILabel 並且配製文字顯示和字體大小,然後將這些放置給 cell 的 contentView,像這樣子
[cell.contentView addSubview:nameLabel];
看要配製幾組,就依序這樣一一加入 contentView 裡面。當我們建置好 cell ,使用 indexPath 參數去決定說現在是哪一個 row 要取出事先配製在 dictionary 的 key/balue pairs。看完整 CellViewController.m 程式碼

方式二、加入
subclass 到 UITableViewCell
另外開設繼承 UITableViewCell 的 CutomCell 包含 (.h, .m, .xib 檔案),在 CutomCell.m 規劃出要顯示的 UILabel 名稱和顏色,規劃好 IBOutlet 後,進入到CutomCell.xib,使用 Interface Builder 我們可以拖拉 Table View Cell,指定 class,調整好位置大小後,我們再從 Library 區域拖拉 View 進來,讓它適合我們要顯示的大小,接著我們就可以依序將我們 Label 拉進來,再將 IBOutlet 串聯好,即可回到 XCode 實作去。


在這邊將宣告 CustomCell ,並且將他 nib 配製出來,再來就可以依序 cell 裡面的 colorLabel 和 cell.nameLabel。看完整的 CellViewController.m 程式碼

我們在做這樣練習時候,用同一個 Project,會發現前後要使用不同方法卻是做出同樣效果,所以在 github 上面可以切出兩個 tag,分別是 v0.1, v0.2,來做不同版本的差異紀錄,如此也可以事後進入兩部份對照不同的 CellViewController.m 的 code 做追蹤。以上除了可以參考
書本 Beginning iPhone 3 Development 章節 Customizing Table View Cells,程式碼完整收錄在 edwardinubuntu/cell

Wednesday, December 15, 2010

Date Picker and Picker View

Picker
Date picker 提供日期讓使用者選擇,而Picker View 可以做出比較多特效,有單一挑選值、兩個轉輪供挑選、兩個轉輪選擇值會互相依賴影響、或者在轉輪上面加上圖片和值。每一個轉輪稱為 Picker Component,可以依據實作方式決定它的外觀。使用 datasource 和 delegate 來做出特效。

使用 Picker 不能只是單純從 Interface Builder 拖拉配製就使用,需要額外提供 picker delegate 和 picker datasource。Datasource 告知 picker 有多少 components 需要運轉和多少項目供挑選來組成。Delegate 在這邊扮演最重要角色是每個 rows 要怎麼畫。Picker 會問 delegate 不論是顯示 String 或者圖片提供給該 component,picker 從 delegate 取得顯示資料。

DatePicker
在 DatePickerViewController 宣告 UIDatePicker,規劃出 IBOutlet 和 IBAction。另外在 Interface Builder 拖拉 Date Picker 之後,將相關的關聯配製好。之後回到 Xcode 在類似事件處理區,可以從 datePicker 取得 date 資訊了。

SingleComponentPicker
在 SingleComponentPicker 要記得 implement UIPickerViewDelegate, UIPickerViewDataSource。
@interface SingleComponentPickerViewController : UIViewController {...}
宣告 UIPickerView 和 NSArray 放置資料用,配製好 property 和相關 IBOutlet 以及 IBAction。在 Interface Builder 拖拉 Picker View 之後,將相關的關聯配製好,記得將 Delegate 和 DataSource 都要拖拉關聯到 File's Owner 上。
-(NSInteger)numberOfComponentsInPickerView:(UIPickerView *)pickerView {...}
告知 Picker View 只要 show 一組。
-(NSInteger)pickerView:(UIPickerView *)pickerView numberOfRowsInComponent:(NSInteger)component {...}
回傳每一列有多少筆資料
- (NSString *)pickerView:(UIPickerView *)pickerView titleForRow:(NSInteger)row forComponent:(NSInteger)component {...}
當畫面轉輪變換時候,可以更新取得值。

DoubleComponentPicker
跟 SingleComponentPicker 一樣的規劃,記得 implement UIPickerViewDelegate, UIPickerViewDataSource。
- (NSInteger)numberOfComponentsInPickerView:(UIPickerView *)pickerView {...}
告知要 show 兩組
-(NSInteger)pickerView:(UIPickerView *)pickerView numberOfRowsInComponent:(NSInteger)component {...}
當詢問哪一個 component 回傳該規劃的總量,類似給與 NSArray 的 count。
- (NSString *)pickerView:(UIPickerView *)pickerView titleForRow:(NSInteger)row forComponent:(NSInteger)component {...}
當畫面轉輪變換時候,更新該 component 的值

DependentComponentPicker
跟前面一樣規劃,在 DependentComponentPickerView.m 實作 Picker Data Source 和 Picker Delegate 的 methods
- (NSInteger)numberOfComponentsInPickerView:(UIPickerView *)pickerView {...}
告知要 show 兩組
-(NSInteger)pickerView:(UIPickerView *)pickerView numberOfRowsInComponent:(NSInteger)component {...}
當詢問哪一個 component 回傳該規劃的總量,類似給與 NSArray 的 count。
- (NSString *)pickerView:(UIPickerView *)pickerView titleForRow:(NSInteger)row forComponent:(NSInteger)component {...}
當畫面轉輪變換時候,更新該 component 的值
- (void)pickerView:(UIPickerView *)pickerView didSelectRow:(NSInteger)row inComponent:(NSInteger)component {...}
因為我們要做出互動,所以當選的時候,透過這邊來改變 picker 的值,達到例如挑選了主選單,更新了副選單的值。

CustomPicker
為了做出 5 個轉輪特效,在 viewDidLoad method 要把 png 檔案 load 進來,放置在 UIImageView 裡面,再將這些配製到 5 個 NSArray 中。利用 spin method 來啓動轉動輪盤。
-(IBAction) spin {...}
這邊透過隨機來轉動轉輪,根據五個的圖片值,來決定是否獲勝 (出現三個相同圖案) 或者重試。
- (NSInteger)numberOfComponentsInPickerView:(UIPickerView *)pickerView {...}
告知要 show 5 組
-(NSInteger)pickerView:(UIPickerView *)pickerView numberOfRowsInComponent:(NSInteger)component {...}
回傳轉輪上面的圖片數量,所以 return [self.column1count]; 即可。
- (UIView *)pickerView:(UIPickerView *)pickerView
viewForRow:(NSInteger)row
forComponent:(NSInteger)component reusingView:(UIView *) view {...}
根據 compoent 編號,取得 Array,再根據 row 來回傳選取到的圖片。

以上一種 DatePicker 和四種 Picker View 的效果,我們可以學到彼此共同點和差異點,如果有興趣可以參考
書本 Beginning iPhone 3 Development 章節 Tab Bars and Pickers,或者 Github:edwardinubuntu/Picker

Setting up the Tab Bar Framework

Xcode 提供了 tab bar applications template,我們還是可以自己來建置,不會很費力,而且可以做個很好的練習。所以從 Window-based Application template 開始。

我們從一個 Tab bar controller 做起頭,裡面要包含 5 個 View Controller 。這樣這個完成後可以作為後面額外學習 UIPicker 概念用。

xxxAppDelegate.h
先在 Xcode 建立 root view controller,它是 UITabBarController 的 instance。配製在我們的 xxxAppDelegate.h 裡面,宣告為
UITabBarController *rootController; 當然別忘了加 @property (nonatomic, retain) IBoutlet UITabBarController *rootController 。

xxxAppDelegate.m
另外在 xxxAppDelegate.m 加入 @syntesize rootController; 並且在
- (void)applicationDidFinishLaunching:(UIApplication *)application
配載 [windowaddSubview:rootController.view]; 達到畫面載入知道要加入這個子畫面進來。

xxxViewController
另外建立 5 個 xxxViewController,分別要建立 .h, .m, .xib 作為畫面切換各別所用,並且把要顯示的 icon 準備好,放到 Xcode 裡面 Resource 區域下面。

MainWindow.xib
打開 MainWindow.xib 啓動 Interface Builder。將 Tab Bar Controller 從 library 拖拉到 nib's main window。打開 inspector ,在 Attributes 分頁,可以配製加入我們的 ViewController,所以按下 "+" 符號開設 5 個,且 Title 命名好,依序點選 tab,將 nib name 配製對應到我們的 xib 檔案,切換到 identity 頁面將 class 指定到我們的 xxxViewController,接著點選 tab 上中間區域,到 item attributes 區域,我們可以命名且配製 image 挑選我們要的 icon。後面四個就依序照此步驟操作。過程要檢驗是否有配製正確的話,從看畫面是否顯示 View Load From xxxViewController,切換 tab 可以看到不同準備載入的畫面。

以上完成後,存檔。回到 Xcode 啓動,即可看到 Tab Bar Framework 建置完成,切換各個 Tab 看到畫面還是空白。不過這邊沒關係,後面再將各頁面,分別啓動 xib 檔案,再從 Interface Builder 配製,即可做出差異性了。此為後面 UIPicker 學習用,先製作出來的殼,同時也可以學到如何自己規劃 Tab Bar Framework。


以上可以參考書本 Beginning iPhone 3 Development 章節 Tab Bars and Pickers,或者 Github:edwardinubuntu/Picker

Tuesday, December 14, 2010

Utility Application Template 與 Painter, FlagQuizGame 開發重點


透過兩個練習題目來學習 Utility Application template ,一個是 Painter,另外一個是 Flag quiz game。

Painter 是一個可以讓使用者透過手指接觸螢幕畫圖的應用程式,透過按下 info "i" 切換到設定頁面,來調整畫筆的粗細和顏色,再返回到主畫面繼續畫圖。

Flag quiz game 是一個可以透過國旗題庫,讓使用者猜這是哪一個國家的國旗,共十題,最後會給與成績。透過按下 "i" 切換到後面可以設定考題的選像多寡,和選擇出哪幾個區域的國家國旗就好。

選擇了 Utility Application Template 作為設計的起點。Utility Application 包含前端主畫面給與主要功能,後端畫面讓使用者可以透過設定,返回主畫面進而調整。所以透過這樣開設,會有兩個 View Controller,分別是 MainViewController.h 和 .m、FlipsideViewController.h 和 .m。同時也會幫忙建立出畫面以及它的子視圖 UIView,以及 Info (i) 自動產生兩個視圖間進行切換的界面元素,和 Done 的按鈕作為切還回來的功能。

打開 Xcode,從 MainViewController.h 開始定義 Property 要用到哪些,搭配 IBOutlet, IBAction 規劃出可能會有動向。打開 MainView.xib 開始透過 Interface Builder 將需要的畫面元素拖拉進來,將彼此設定關聯,將 Target/Action 定義好。才再回到 MainViewController.m 開始寫實作部份。

MainViewController 是 UIViewController 的 subclass,implements 了 FlipsideViewControllerDelegate protocol。Protocol 是描述一系列的 methods 可以呼叫到另外一個 object,這概念有點像是 "interface"。FlipsideViewControllerDelegate 是自動建立出來,定義給 FlipsideViewController class。它定義了 flipsideViewControllerDidFinish method 讓當按下了 "Done" 按鈕可以回度 MainView 畫面。

Utility application template 常用 methods

在 MainViewController.m
  • - (IBAction)showInfo:(id)sender; 這邊將要導過去的 FlipsideViewController 宣告出來,透過 delegate 技巧,將 MainViewController 上的值傳遞過去給 FlipsideViewController 接收,最後在將 controller release。
  • - (void)dealloc; 將畫面會用到的 properties 記得 release 掉。
在 FlipsideViewController.m
  • - (IBAction)done:(id)sender 將 MainViewController 宣告出來,透過 delegate 將值傳回去
  • - (void)dealloc; 將畫面會用到的 properties 記得 release 掉。

Painter 額外加入地方


Sguiggle 來當作 Object 封裝點、顏色、寬度。
  • - (void)addPoint:(CGPoint)point; 加入新的點。
MainView 定義了 NSMutableDictionary 來儲存 squiggle 點、UIColor 當下的顏色、float 當下的線條寬度。
  • - (void)drawSquiggle:(Squiggle *)squiggle inContext:(CGContextRef)context; 支援畫圖。
  • - (void)resetView; 畫面歸零重來。
FlipsideViewController 儲存了顏色、和畫筆粗細。
  • - (IBAction)updateColor:sender; 更新顏色。
  • - (IBAction)erase:sender; 清空色彩。
  • - (IBAction)clearScreen:sender; 清空畫面。
  • - (void)setColor:(UIColor *)c lineWidth:(float)width; 設定顏色,在 delegate 呼叫用。

FlagQuizGame 額外加入地方

MainViewController 宣告諸多變數來儲存遊戲進行中的參考值,有國旗圖案、答案、答對幾題、圖案標準答案、總共幾題等等。
  • - (IBAction)submitGuess:sender; 提交使用者作答答案。
  • - (void)loadNextFlag; 載入下一張國旗。
  • - (void)setGuessRows:(int)rows; 設定考題選項多寡。
  • - (void)resetQuiz; 重新歸零。
  • - (NSMutableDictionary *)regions; 取得目前 Regions 資訊。
FlipsideViewController 宣告了選項數目、切換是否 on/off 控制考題的國家地理區域。
  • - (void)setSwitches:(NSDictionary *)dictionary; 設定只會出現哪些區域作為考題。
  • - (void)setSelectedIndex:(int)index; 設定考題選項的多寡。

寫這兩隻練習題目的時候,首先要找出套用 Utility Applicaiton 範本,在因應不同的功能需求,去規劃後面的開發。

當畫面需要哪些元素,搭配 MVC 架構在 Interface Builder 拖拉並且把各個元素連接起來。如果邏輯比較複雜的,在 Xcode 裡面要注意宣告 methods 來符合功能所需。另外當兩個 controller 主畫面副畫面切換,在傳值上要注意彼此是否有串接上。

當碰到程式模擬器跑出來不符合自己預期的結果時候,適當在程式裡面加入 NSLog 和插入中斷點,透過 step by step 去觀看值,再來推敲問題可能會局限在哪邊。最後如果還是無法突破,這代表瞭解還不夠透徹,先把 issue 記起來,作為備忘錄,留著未來學的越多,再回來試著解解看這些問題。相信最後可以做出來自己當初期望的 version 1.0 應用程式的。


相關程式與 issues 改進紀錄可參考 Github:edwardinubuntu/Painter, edwardinubuntu/FlagQuizGame

Friday, December 10, 2010

Autorotation and Autosizing

iPhone 允許應用程式當 Runtime 時候,使用者翻轉裝置時候,畫面也要跟著變動,支援 Portrait (高瘦型) 畫面和 landscape (矮寬型) 畫面兩種模式。想要體驗這種效果,可以打開 iPhone's web browser Safari 來體驗。我們的程式也可以支援這樣形式。

在 Interface Builder 裡面拖拉元件 (例如 UIButton) 進來,按下該元件打開 Inspector,切換到 view size ,在 Autosizing 區可以透過裡面的紅色箭頭,按下或者取消按下各種方向,來決定這個元件當翻轉時候要怎麼運作。在框框的外圍四周按下可以決定當翻轉的時候,要定位的位置。框框的內圍按下可以決定當翻轉時候,是否因為畫面大小而做自動化調整。這邊可以透過設定方式,讓畫面元件做出自動化調整。

當然元件透過 Interface Builder 拉出來的,要跟 Xcode 的程式碼連在一起,不要忘記透過定義 IBOutlet 將彼此串聯起來,如果要做出 event 處理,加入 IBAction 串聯起來再到該 method 實作程式碼出來。在 Xcode 裡面,我們也能透過程式來控制翻轉特效,首先要了解有四個指標用來判定目前裝置的狀態:UIInterfaceOrientationPortrait (畫面正向), UIInterfaceOrientationPortraitUpsideDown (畫面上下顛倒), UIInterfaceOrientationLandscapeLeft (畫面躺平 Home 鍵朝左), UIInterfaceOrientationLandscapeRight (畫面躺平 Home 鍵朝右)。

使用 view-based application template 裡面,在 ViewController.m 可以透過兩個 methods 來控制當 iPhone 裝置翻轉時候,是否支援翻轉,另外當翻轉時候畫面要做什麼事情。

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation {...}
這個 method 是當 iPhone 翻轉的時候,決定要不要讓畫面和畫面裡面的元件支援翻轉。裡面可以透過 interfaceOrientation 來判定目前是哪一種導向指標,可以來做判斷,最後回傳是否支援翻轉效果,例如回傳 return (interfaceOrientation != UIInterfaceOrientationPortraitUpsideDown);。如果通通翻轉,這邊回傳 YES 即可。


- (void)willAnimateRotationToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation duration:(NSTimeInterval)duration
{...}
這個 method 裡面可以配製當畫面翻轉到哪一種狀態,讓畫面裡面的元件可以做出什麼樣的特效,例如讓按鈕的框框可以對到哪個座標以及它的大小。 button1.frame = CGRectMake(20, 20, 125, 125); CGRectMake 是給與四個參數(座標 x, y 和長和寬),它會回傳CGRect 四方形回來。

以上可以參考書本 Beginning iPhone 3 Development 章節 Autorotation and Autosizing,或者下載 github 練習範例 https://github.com/edwardinubuntu/AutoSize

Thursday, December 9, 2010

Post-it! My knowledge wall.

如果有一面很大張的空白牆就在電腦桌旁邊,但是卻因為某種原因不能在上面張貼東西破壞它,(例如跟房東租的,到時租約到期後歸不想留把柄),卻那麼的遼闊空白不拿來利用,真的很可惜,你會想到怎麼運用?

如果當知識學習是自己責任的時候,當電腦上很多很好的平台和軟體工具可以幫忙蒐集組織我們的知識時候,但是卻碰到另外一個問題,每天要面對螢幕,甚至雙螢幕時候,為了自己眼睛健康著想,我們可否有更棒的主意呢?我們何不把大方向的知識當作一個一個 Object 帶出電腦網路世界,跟我們更靠近呢!想想自己平常最在意哪些事情。例如我最在意事情是電腦裡面重要軟體要記得使用、網路雲端上的平台資源要留意、讀書的心得重點、相關參考知識以及最重要的個人心得與經驗。

便利貼一直是可以幫我們記憶東西,方便黏貼,可以隨意寫重點上去,隨意的挪動位置,隨心所欲。甚至便利貼在互動設計裡面佔了很重要的協助工具的角色。且透過各種顏色互相搭配,使用起來可以達到不同且美觀的效果。

當以上這三樣東西組合在一起,著手準備了五種顏色的便利貼,開始將各種我最在意的事情抄寫下來,而且彼此會有它的相關性,就貼靠近些,
我的個人知識牆誕生了
  • 紅色為我個人筆記型電腦上重要不錯的軟體,可以告誡自己我有這麼棒的軟體,要常常使用。
  • 綠色為我在網際網路上最在意的平台,以及相關知識。這樣可以提醒自己,在網路那頭我還有很棒的資訊存在。
  • 黃色為個人的經驗記載。由於在大賣場買便利貼時候,黃色組合比彩色組合更優惠,所以拿份量最多的黃色來紀錄使用成長經驗,黏貼靠近各個它色的便利貼。
  • 紫色為書上的重要章節與知識,當學到什麼就黏貼起來。
  • 藍色為相關重要參考的知識。
每一張紙寫要點為,大標題小內容。標題字寫大一點,這樣當自己站在後退一點距離,可以看的到,可以全盤想這整體性的關聯。內容字由於要寫些關於標題的細節內容,所以字寫一般大小,靠近點看就可以一看就了然。

像目前為止我使用的 (Amazon web services, github) 平台的進展、Mac 上重要開發工具 (Xcode, Interface Builder, Axure RP Pro 等)、參與讀書會的學習,以及最重要心得感想,彼此都有關係,一定可以互相搭配在一起,都乖乖貼在這上面了。

這是我的知識牆,未來會持續增闊它的領土,保持最新關注事項,這樣就能當離開電腦走動休息時,依然可以做些思考以及腦力激盪。

Tuesday, December 7, 2010

了解使用者的工作

人種誌學 (Ethnography) 是源於人類學的一種方法,它的用意是將文化紀錄下來。它是一種廣泛基礎的方法學,觀察使用者如何進行他們日常的活動,觀察者將自身沈浸於使用者的環境,並參與它們每日的工作。包含了加入他們的對話、參與他們每日的工作。此目的是要讓隱性的變成顯性。使用者對他們的生活環境及每日的工作如此熟悉,以至於他們不了解這些熟悉動作或發生事情背後的重要性。而人種誌學的經驗特質是除了明確描述所蒐集的資料之外,必須和其他團隊成員分享。

一致性的方法 (Viller and Sommerville, 1999) 結合了將人種誌學運用在資訊設計及需求工程發展上的經驗。主張以人種誌學研究的系列觀點 (Viewpoints) 及關注 (Concerns),以讓產品中最重要的使用案例便方便於確認。

另外情境調查是人種誌學研究運用在設計上的方法,它遵循一種學徒制的型式。透過情境訪談,結合了觀察、討論、及過去事件的重新建構。這邊以四個主要法則:情境、合作關係、解釋、重點。

我們將這些方法與理論透用在一個練習假想作業,題目為開發一套『產品 Delivery』的系統,進行一位擔任過一年以上 Delivery 產品給客戶經驗的開發人員,透過在旁觀察與訪談,將『一致性』及『情境式設計』應用於當中。以下 Q 則為套用互動設計一致性的觀點問題,A 為某開發人員觀點描述。

一致性的三種觀點與四種關注的問題

分佈的協調
Q1. 請問你在工作分配上,如何貫徹個人工作及與其他人之間的協調?
A. 當開發時候,我們會按照功能模組或者元件來明顯切割。整合測試時候,因為大家都要 Build up 起系統,所以不論是個人自己要處理,測試環境我們會以熟悉人來負責。當最後要 Deliver 出去,我們會以主要一到兩位來負責。所以整體上還是以個人工作專長來劃分。
Q2. 請問一個人與另一個人之間的責任如何清楚的劃分界線?
A. 以個人手頭上負責的項目,為主要負責人。我們都清楚知道最近一到兩個禮拜,誰手頭上負責主要項目為何。
Q3. 人們對於其他人的工作、任務與所扮演之角色有何感激之處?
A. 通常不要因為自己開發系統,導致毀損擋住別人工作前進為原則就要偷笑了。至於感激方面,可能是可以看到新功能出現在整合測試的測試機上,會有興奮感覺因而想要進一步嘗鮮測試。

計畫及程序
Q1. 計畫及程序如何再工作場所中運作?
A. 這是由專案經理訂定,會記載在試算表、心智圖、最後謄到專案管理系統上,再由交代系統分派工作出來。我們則由專案管理系統和交代系統上面進行工作回報。
Q2. 他們經常都有用嗎?
A. 專案管理系統常常會讓工作切割模糊不清,一個任務可能會要做很久導致不好結束。交代系統則是我們每天要面臨的,這邊我們要祈求系統能穩定運作。
Q3. 它們為何失敗?
A. 主要在工作分配的切割,沒有明確切割,如果切割後,開始做,但是是後可能有事情影響,需要重新規劃,就會造成原計畫遭到阻礙。這時候也是考驗專案管理系統能否應付。
Q4. 它們失敗後之情況為何?
A. 會造成系統上面呈現的資訊跟實際工作上不符合,導致管理職或是上司需要透過別的管道持續溝通 (email、開會、面對面溝通)
Q5. 它們在何種狀況下如何避開困難?
A. 會找替代方案,或者就以單一系統為主,例如交代系統。

工作的察覺
Q1. 工作場地空間的組織如何協助工作人員間及他們所使用物件間的互動?
A. 我們有這些要接觸:個人 Notebook、電話、印表機、測試機器、幫忙管理的 MIS 機房。
Q2. 工作人員如何組織他們的周遭空間?他們所保留使用的物品即可能對他們完成每天的工作有很大重要性。
A. 我們無法組織周遭空間,但是我們開發人員擅長資訊管理,所以我們可以透過遠端管理,解決人們要親自走到機房或者機器旁的問題。
Q3. 工作人員經常參考的註記與項目為河?
A. 我們幾乎都參考網路上的資訊,我們很多資訊不管團隊內或是外面,都已經資訊化。
Q4. 物件的位置在何處?誰使用他們?多常使用?
A. Notebook 和電話是使用最頻繁的,這些都離開發人員很近。

紙上作業及電腦作業
Q1. 紙與電腦作業在何種程度可讓工作人員清楚他們在整體工作的哪一階段。
A. 我們很少用紙張。電腦上可以透過樹狀結構、完成度百分比、進度狀態等等來瞭解。
Q2. 科技在何種程度可以支援工作程序?如某一特定程序是否可以加強進行?或允許其他解決方案?
A. Email 的溝通,不論是我們工作回報或者是系統發佈出來,都是很好的通知或者提醒的服務。如果能讓這些溝通在加強,讓團隊成員彼此一目了然,減少管理者們的誤解,就可以減少很多日常多餘的溝通確認了。

科技及在地知識的使用
Q1. 個人或團隊所使用的哪些日常生活技巧可讓他們順利完成工作?
A. 以我們為例,善用資訊軟體可以讓我們完成團隊上很多工作。透過知識管理系統保存文件、版本控管保護與交付程式、問題追蹤系統紀錄問題與解決狀況等等。
Q2. 如何使用在地知識讓它隨時可用?個人檢核表或與專家詢問等方式。
A. 我們幾乎以查詢團隊內部系統為主,如果找不到才會找團隊以外的系統求助。如果再不行才會親自拜訪團隊成員求助。
Q3. 標準程序至某種程度要運用列入考量?
A. 當面臨嚴肅的問題,我們都會要遵從標準程序,通常都是跟團隊外面就會牽扯到,例如跟客戶的溝通應對等等。

空間及時間的組織
Q1. 工作場所的空間組織如何反映出工作是如何進行?
A. 我們工作越接近的,座位也會越接近。除了彼此工作,也會互相討論。
Q2. 有任何資料是依日期而使用的?
A. 幾乎所有事情都是跟日期有關。只要要做紀錄事情,都要時間紀錄。且工作上幾乎都要做紀錄。
Q3. 工作人員如何確定他們所使用的是最新的資料?
A. 由於我們幾乎都放在資訊系統上,所以要跟系統重新抓取最新資料即可。但是如果發現系統上面的資訊是舊的,我們要提醒當事人,把資料資訊放在系統上,讓大家可以得以同步。

組織的記憶
Q1. 工作人員如何學習與記憶如何去執行他們的工作?
A. 我們每天做的每一件事情都是會寫工作紀錄報告,所以這些都是會儲存在某某系統,這樣屆時透過系統搜尋功能,即可把它們找出來。
Q2. 正式紀錄如何完善的搭配工作實際上是如何完成的?
A. 一般來說是沒有準備這個。但是我們交代系統可以匯出工作紀錄,上面即有完整的資訊。

以上為一致性的方法透過問與答,做出觀察使用者的結果,這只是訪問單一人而已,所以會比較主觀。而且我們透過這些答案,即可看出許多優點與缺點。我們不評斷這樣做的對不對,而是先以取得這些重要資訊為主,因為我們要先了解使用者工作,藉由帶回到團體,大家在腦力激盪想出更好的規劃與設計,運用於接下來假想題要開發的『產品 Delivery』系統。另外書上有提到情境式訪談,這邊比較多的圖像和互動圖以及流程圖,就比較牽扯到個人工作詳細項目了,不在這邊多做闡述。

一致性是一種提供許多焦點問題的方式,引導人種誌學家研究系統發展的重要層面。情境式設計提供許多模式及技巧以蒐集情境式資料,並適於實際設計時的呈現形式。

以上資訊更多可以參考 互動設計(二版) - aNobii 以使用者為中心的方法於互動設計上。圖片為《清明上河圖》卷,北宋,張擇端作,描繪的是清明時節北宋都城汴京(今河南開封)東角子門內外和汴河兩岸的繁華熱鬧景象。

37signals 的 web-app interface designer

在 37signals 的 UI designer 除了要有不錯的視覺品味和天分,要會 coding HTML/CSS。基本的 JavaScript 或者有 Rails 能力可以加分,但是不是必須強制。書寫能力要好。

在 37signals 的 UI designers 要可以做不同面向的工作事情。可能參與加強已經存在功能的 Basecamp 產品或者要設計 Highrise 產品的新功能。可能需要改造 Backpack 產品或者重新思考 Campfire 產品的 UI。或者參與設計全新產品 (即將 2011 年問世),所以可能被要求做出沒有人看過的東西出來。

在 37signals 工作,是在為人們 (客戶) 依賴它完成工作的產品上開發,所以 UI designer 工作將會影響上萬個相互作用。跟頂尖的 designers、programmers、developsers 等,以及和相關領域的客戶協助人一同合作。37 signals 是頂尖的團隊,現在希望 UI designer 可以讓團隊變更好。

37signals 產品是專注於解決真實問題。當問題解決了,我們就知道設計是對了。所以擔任一個 UI designer,就是要幫助把客戶們的問題解決掉。

在 37signals,designers 領導團隊。每一個開發團隊是由三人組成,兩個 programmers 和一個 designer。而 designer 是要專案管理的。為了設計螢幕元素等,必須要保持團隊專注且告知什麼是重要的,所以會需要主動去找人溝通。

UI designer 要對於發現最佳解感到興奮,甚至把這種感覺帶到專案裡頭。不用在意把好的點子或者實作建議丟出來。回饋建立出雛形可以引導團隊方向。他們非常嚴格在意 code,因為希望設計或者 code 是可以容易被回饋回來的意見而改變的。

最後注意事項,文案是設計。文字就好比是每一個像素單點 pixels。好的視覺搭配虛弱文字描述是很差的設計,所以要在意文字用詞表達,就如同在意他們長相一樣重要。

以上這篇是參考來自 Signal vs. Noise 的 Hiring: We're looking for another wep-app interface designer Jason F. Dec 06 的文章,37signals 在找尋優秀的 web-app UI designer 加入他們的團隊,招募的工作地點在 Chicago。希望藉由觀看吸引人的工作招募文章,作為我們個人學習的目標。

Monday, December 6, 2010

Load Balancers

當有兩個以上或更多相同服務的 EC2 的 instances 時候,Load Balancer 可以支援分散 Application 的負載能力。當運轉上負荷吃力時,我們可以動態的增加註冊 EC2 instances 進來到 Load Balancer,達到增加更多機器來支撐需要。當不需要使用時候,也可以馬上一一解除。

每一個 Load Balancer 是由一組 DNS 名稱和設定好的目的 ports 對應,導到 Application 該去的地方。這樣在整體 Ports 配製上可以省去很多煩惱,例如在 Amazon Linux 上面運轉的 Tomcat,使用預設值 port 8080 即可,這樣透過 Load Balancer 規劃從 port 80 轉址到 port 8080 即可,這樣使用者在瀏覽器不用輸入特殊 port,我們後端也可以做些 port 運用。

透過 Health Check 設定檢查的參數與頻率,可以監控 EC2 instances 的健康狀況。指定要 Ping Protocol HTTP, TCP、Ping Port 例如 8080、Ping Patch 指定要檢查的目標路徑來檢驗是否該 Instance 健康,值例如是 /index.html、Response Timeout 當超過幾秒鐘就不合格,例如 5 秒鐘、Health Check Interval 檢查時間多久,預設 5 秒鐘、Unhealthy Threshold 當幾個以下開始為不健康、Healthy Threshold 設定當幾個開始健康後,把狀態不健康轉成健康。當以上參考指標讓 Load Balancer 偵測到有問題的 instance,會將它停止分散流量過去。當 Instance 又恢復到健康,才會再分配流量給它。

我準備了至少兩個 Amazon Linux instances,都個別裝上了 Tomcat6 server,預設 8080 port,和要提供相同的簡單 web 服務,另外在 HTML footer 偷偷動手腳,將該 Instance 代號填寫在上面,作為後面觀測所需。檢查所有 Amazon Linux 都準備妥當後,新增一個 Load Balancer,將網址設定 port 80 導到 port 8080。再將我準備好的 Instances 勾選掛進來,最後設定好 Health check 機制後,這個 Load Balancer 即建立完成。

來到 Amazon EC2 的 Load Balancers 管理介面,可以看到 Load Balancer 建立好了,且預設 Amazon 會給予一組電腦做的 DNS name 來做使用,當然是很長一串且是 amazon.com結尾的,如果不喜歡自己要再去另外註冊自己滿意的 DNS,這邊因為是練習階段,所以沒關係直接用。Status 我們可以看到 x of y instances in service 有個概括了解自己服務狀況、Port Configuration 可以看到目前設定上轉到哪個 port 的、Available zone 顯示目前橫跨幾個地區,因為 Instances 有可能會分配到不同區域,以我這邊查到,分別在 ap-southeast-1a, ap-southeast-1b。切換到 Instances 頁面,可以看到目前掛載了幾個 Instance,各個狀態狀況怎麼樣,如果想要移除掉某些 Instance,可以在這邊移除。

最後來看成果時候了,打開瀏覽器,輸入 Load Balancer 提供的 DNS 網址,即可看到我們 Tomcat6 server 上提供的 web page 檢視。檢查 HTML Footer 偷偷塞的代號,可以發現會出現哪一臺 Instance 是由 Load Balancer 隨機決定的。另外遠端 SSH 進入 Amazon Linux 管理,將其中一臺 Tomcat server shutdown,過幾秒鐘我們再返回 Amazon EC2 的 Load Balancers 管理介面,即可發現其中一個 Instance 狀態從 In Service 變成 Out of Service,Healthy 從 Yes 變成 No,這時候沒關係,回到瀏覽器將 Load Balancer 提供的 DNS 網址重新整理,即可看到它會轉到還在健康運轉的 Instance 上面了,HTML Footer 上顯示好的那台代號。

總結來說,Load Balancers 提供了相當不錯的服務,根據需求調整 Instance 供應數目,如果發生 Instance 因為不當原因失去該 Instance 服務,沒關係,整體對外運作還是正常的,達到服務不中斷,只要儘快瞭解再掛載上來,就可以通通回到一陣線上了。

Friday, December 3, 2010

Flat Stanley Project 跨區域拉近孩子們的距離

1995 年,Dale Hubert 一位國小三年級老師在倫敦、奧特羅、加拿大設計發起 Flat Stanley 計畫。他邀請其他老師們參與舉辦『平板訪客』活動,鼓勵他們的學生們去寫他們自己的 Flat Stanley 日記。

這裡面有很多優點,其中一項特別優點是寄平板紙片訪客給朋友們,只要透過一個信封即可。學生們透過信件開始這樣傳遞給遠方親朋好友。學生們首先在紙上畫出獨一無二的 Flat Stanley 然後開始讓它展開數日的旅遊。Flat Stanley 寄給遠方親朋好友,如果對方也是小朋友更好。小朋友們收到要扮演成主人,好好招待 Flat Stanley,帶他到當地拍照、介紹生活景點、寫下日常生活故事,讓它可以完成這趟旅程。最後 Flat Stanley 和日記就這樣歸還給原寄者。學生們可以把 Flat Stanley 的旅遊景點配製在地圖上,分享生活日記出來。方法有很多種,有的是寄電子郵件虛擬化有的是寄實體的郵件包裹。實體包裹的會比較好,因為在寄郵件過程,包裹裡面可以不單放 Flat Stanley 而已,還可以另外附上洗出來照片、紀念品等等。當然寄出這樣一個 Flat Stanley 前,要先有禮貌的詢問對方主人有沒有空,可以招待它。因為在美國有些學校班級,招待這位小朋友到超過負荷了。

Flat Stanley Project 是一種筆友的活動,但是它比這個更有意義。因為透過寄出 Flat Stanley,這樣寄件者和參與者彼此多了一個共同朋友 (僅僅是一張紙,卻是有很深的意義),多了許多話題可以聊聊。

因為 Edward 在 Facebook 上有來自美國德州的外國朋友,我們因緣透過網路而認識,但是我在台灣,對方在美國彼此有生活,僅能透過 Email 來聯繫,透過 Facebook 動態瞭解彼此生活點滴,還僅算是網友、筆友而已。昨天我收到他們這期學生作業邀請,寄來的國際包裹裡面除了有紀念品和還有 Flat Stanley。現在 Flat Stanley 就在我的旁邊,我正在參與了這麼有意義的活動,準備招待它約 10 天的日子,最後再把它送還給美國德州的小主人,2011 年 1 月的 school celebration day 上交作業同時分享給同學們,認識『臺北』。

我看 Flat Stanley 計畫運用在教育學習上,可以帶來最深的含意在於『因為小孩子沒有那麼多錢可以出國旅遊,這個計畫完成了小孩子們的夢想』,透過一個代表身分,一個不貴的國際包裹到了遠方朋友家,拉近了彼此生活。讓參與人可以扮演好主人的角色,好好做個招待規劃,到哪邊景點逛,不用太刻意就可以很有意義。因為已經跨了領域地區,所以只要是簡單日常食衣住行,都可以相當的與眾不同與那份獨特新鮮感。成本不用太高、不會造成彼此負擔、可以待上一段期限、讓主人可以規劃數個地點,最後他們在分享故事的同時,也打開了小孩子學生們的國際觀,相隔半個地球,彼此卻可以如此的靠近。

想了解更多可以參考 http://www.flatstanley.com/ 上面已經有計畫介紹,有簡單電子平台以及 iPhone App 也都開發出來在 iTunes Store 銷售。另外我在他們的 Blog 上看到其中一位 Okinawa, Japan 的老師寫信給原創人 Dale Hubert 的感謝信 "...I started out with this project to show the children of Okinawa how similar all children were. They like the same things and even though live in different places …all shared a common element……. they are kids."。如果您是教育體系的老師,相信您一定也會受到這樣活動而感動。

圖片為來自美國德州小主人的 Flat Stanley 正在台北市新北投圖書館陪我寫這篇 Blog 所攝。

Thursday, December 2, 2010

Launch an Amazon EC2 Instance

當進入 Amazon EC2 (Elastic Compute Cloud) Console 管理工具,主要頁面是 Console Dashboard,讓我們可以起頭使用 Amazon EC2,從 Launch 一個虛擬伺服器開始,也就是 Amazon EC2 Instance。

目前地區提供了 US East, US West, EU West, Asia Pacific,所以例如挑選了 Asia Pacific,它告訴我 instances 將會 launch 在 Asia Pacific (Singapore) region。於是開始要進入 Request Instances 的 Wizard 介面,一步一步操作,如果有系統工程師背景熟悉 Linux/Windows 的話,看到它們問的各種選單都能有所瞭解。
  1. Choose an AMI:選擇一個 Amazon Machine Image (AMI) 類型,目前 Quick Start 有 Amazon Linux AMI 1.0 Basic 32-bit/64-bit, SUSE Linux Enterprise Server 11 32-bit/64-bit, Microsoft Windows Server 2008 各種方案可以選。
  2. Instance details:選擇想要 Launch 是 on demand 或者是 spot instances, On demand 是用多少算多少,spot instances 是可以設定最多付多少錢等的進階設定。選擇 Kernel ID, RAM Disk ID 和是否要加入 Monitoring (Monitoring CPU, Disk I/O, Networking 等畫出圖表)。加入 Tag 做些自己管理上的辨識。
  3. Create key pair:第一次則建立 New Key Pair,命名好之後就會產生並且下載,這個要好好管理,作為之後遠端管理所需。如果已經有 Key Pair,可以選擇說這個 Instance 想要搭配哪個 Key Pair 來管理。
  4. Configure firewall:每一個 Security Group 可以設定不同組合的安全機制,可以設定到連線方式、Protocol、來源 Port、目的 Port、來源信任 IP 等等。而最後挑選 Security Group 來做為這個 Instance 的整體 Firewall 的設定。
  5. Review:當以上都挑選好,這邊會給個總攬,去看是不是這樣組合清單無誤,提供資訊有 AMI, Name, Description, Number of Instances, Availability zone, Instance Type, Instance Class, Monitoring, Kernel ID, RAM Disk ID, User Data, Key Pair Name, Security Group(s)
當確定開始 Launch 之後,等待幾秒鐘,即可看到 Your instances are now launching 的訊息了。現在 Launch 起來,就是開始要來使用與監看管理了。

管理方面:
  • Dashboard 可以看到整體用了多少資源,1 個 Running Instance, 1 EBS Volume, 1 Key Pair, 2 Security Groups 視目前為止最新的數字統計而定。
  • EC2 Instance 可以看到目前所有的 Instance 運作資訊,點選其中一個 Instance 可以查看關於它的所有說明資訊,加入 Monitoring 目前 Instance 的圖表和 Tagging 的 Key-Value 資料。
  • Elastic Block Store 的 Volumes 可以看目前開了多少出來,點選單一個 Volume 也可以看到它的各種資訊說明和監看圖表以及 Tagging。
  • Security Groups, Key Pairs 等等也可以做調整如果有需要的話。

使用方面:
由於我開設了 Amazon Linux,從管理介面查到了我這個 Instance 的 Public DNS,知道目的處後,打開了我們電腦上的 Terminal 用 SSH 連過去。

xxx-MacBook-Pro:~ user $ ssh -i mykeypair.pem ec2-user@YYYYYYY.compute.amazonaws.com
Last login: Thu Dec 2 00:36:19 2010 from YYY.dynamic.hinet.net

__| __|_ ) Amazon Linux AMI
_| ( / Beta
___|\__|__|

See /etc/image-release-notes for latest release notes. :-)
[ec2-user@ip-YYYYYY ~]$

這樣就可以用 Linux 等指令查詢與開始使用了。

Amazon Elastic Compute Cloud Pricing 記載了使用 Amazon EC2 的計費方式,有 Free Tier for new AWS customers 方案,依照它給的範圍內使用是不會 Charge 錢的。不過如果像我不小心貪玩,開了幾個更高檔服務測試,就在 Account Activity 開始看到收費了,如果還在學習階段,就趕緊把那些會需要付錢的功能先一一取消掉吧!因為 Amazon 會月結寄帳單的。快樂學習 Amazon Web Services 定期上來看 Account Activity 是否需要付出哪些使用費用有心裡準備,這樣子循序漸進一步一腳印上雲端。

如果您想要了解更多關於 Amazon 雲端服務,查看我的 Amazon web services Label 之外,推薦『Inside - 網路趨勢行銷與開發』的"雲端運算"相關文章。

Wednesday, December 1, 2010

以使用者為中心的方法應用於互動設計上

我們不斷強調以使用者為中心策略的必要性,關注於實際使用者及他們的使用目標而不是僅僅技術而已,這樣才能是產品開發的驅動力量。

也就是一個設計良好的系統要能將人的判斷和行為做最大程度的發揮與設計出來,而且要跟實際上運作有關聯。應該協助使用者,而不是限制使用者,這較不像是一門技術,而更像是一門哲學。

確認使用者對於新產品的觀點與預期為實際合理的程序,稱為『預期管理』;目的是在產品上市後,不會給使用者造成意外的感覺,如果讓使用者覺得產品與預期不相符,會產生被欺騙的感覺。讓使用者參與設計能夠對於預期管理有所幫助,因為很早階段可以發現產品具備和不具備的功能,比較了解這對於他們的幫助,對產品產生期待,不會造成失望的感覺。

1985年,Gould et al. 針對他們所認為的『有用的 (Useful)、且易用的 (Easy to use) 電腦系統』在書上提出了互動設計的三個主要特色:
  1. 儘早著重於使用者及工作上。
  2. 經驗主義的判斷。在發展初其,使用者對於開發給與觀察與評量。使用者與模擬的情境和產品互動,做觀察、紀錄及分析。
  3. 反覆式設計。如果使用者測試有發現問題要儘早修正,隨後在繼續觀察測試來修正結果,一直進行『設計、測試、評估及再測試』。
針對使用者部份要注意的原則是:
  1. 使用者的工作及目的式產品發展的驅動力量
  2. 研究使用者的行為及使用情境,再進行系統的設計
  3. 了解使用者的特性並運用於設計中
  4. 在發展初期直到結束階段都要請教使用者,並且審慎考量他們所提供的意見
  5. 所有設計的決策都應該考量到使用者情境、他們的工作及他們的環境
這邊以一個題目來做練習,假設有一個販售水族生態的電子商務網站請我們參與開發設計,試著把上面原則應用於工作中。

由於我過去大學參與過水族生態三年,所以對於使用者採購到使用週期有一定程度的瞭解,所以我以消費者的角度來分析與介紹。

消費者有分專業型、一般型。

專業型消費者通常對於從硬體器材到水族環境佈置到生物(魚+蝦+蝸牛等)的挑選都有一定的瞭解,對於要買什麼很清楚,所以購買上都是極為快速,速戰速決,甚至會跟店員討論最新行情與趨勢脈動。

一般型消費者不太瞭解,會特別觀賞店家佈置的水族缸範例,跟店家做進一步確認各種知識詢問,例如硬體是什麼怎麼搭配、水草分別是哪幾種要搭配怎麼樣才能有好佈置、魚兒挑選上是否可以讓生態維持平衡等。一般型消費者會慢慢逛,看各種生物(魚+蝦+蝸牛等)做為放慢腳步欣賞。

共同在意事情:價格計價、是否有優惠商品、生物本身的品質(不能生病的)、可以跟店員做知識交流。

所以根據以上些情境來設計,套用以使用者為中心開發,我們已經找出潛在使用者了可以當我們顧問了,把他們預期的目標、行為都列入功能開發裡面,另外我們也可以提供購物網站可以問與答等機制、信用評分等機制進行設計。經過這些使用者行為觀察、購買習慣我們可以找出新網站的使用情境。

最後如果有資源時間,再套用最新 Web 3.0 概念加入開發,Content 由專業店家或者專業的消費者來建立,Social 建立一些可以分享機制發佈到 Facebook、Twitter 等平台,Mobile 如果可以讓他們隨時追蹤最新資訊、下訂單後的進度追蹤可以取貨時間,這樣將會是很不錯的設計規劃了。

以上資訊更多可以參考 互動設計(二版) - aNobii 以使用者為中心的方法於互動設計上

Tuesday, November 30, 2010

Amazon web services: cloud best practices (part 2)

在 Amazon Web Services Blog 上,有一篇相當棒談論 Amazon Cloud 的技術文件:New Whitepaper: Architecting for the Cloud: Best Practices,以下為我對於 Amazon web services 對於雲端技術的概念介紹,做重點心得分享。

雲端技術加強了一些過去建置高延展性網路架構且介紹發展出新的概念,讓整個應用系統開發建置和部署的方式做了改變。當有實作寫過雲端技術這方面概念,會感覺到『怎麼每件事情都改了呀!但也不是全部拉。』雲端技術是改變了一些程序 process,模式 patterns,方式 practices,方法理論 philosophies 和加強了我們過去學到的傳統 service-oriented architectural 原理。


目的建置可延展 (Scalable) 架構
要規劃出延展性的開發架構來取得到延展性的內部硬體設施是相當不容易的。雲端雖然是設計出來概念用來提升延展性。但是如果我們的架構沒有辦法延展的話,也無法帶出內部硬體設施延展性的實力。兩者藥盒做。要定義出單獨的元件 (components) 和架構上的瓶頸 (bottlenecks),找出架構無法提供出好效能服務的地方,為了能得到雲端技術帶來延展性的內部硬體設施好處,需要重新建構 (refactor) 應用程式。

瞭解彈性 Elasticity:

Scale-up approach,這是不用擔心投資太多強大的電腦水平擴充來符合需要,能夠成本花費的有效,而且不是一階段一階段的擴充,比較貼近量而做調整。


傳統 scale-out approach,建造架構起來,水平擴充投資。大部份的企業或是大型 web application 跟從這樣的模式來部署他們的元件,放置他們的資料,發展出服務導向 (service-oriented) 的設計。這個方式有時候會有效率,但是她還是需要去預測需要量的時候。通常會導致太多的經費開支和人工勞力費力監看。甚至變成 Slashdot Effect。


Slashdot Effect 是發生在突然使用需求湧入,但是硬體裝置卻跟不上導致服務變慢或是停擺,這樣對於投資已久造成很大的冤枉。如果低估,就會無法應付突如其來的流量,導致顧客不滿意。如果高估的話,又浪費太的金錢投資在超過的資源。


此圖為 Whitepaper 裡面的介紹圖表,X 軸為時間 Y 軸為內部基礎設施的投資,如果紅色線是使用者流量需求,不論是一般 Scale-up 或者 Traditional Scale-out approach 都一直在跟著時間成長,但是當需了某段點需求超過成長,那段就會失去客戶的需求與滿意度,造成冤枉損失。而透過自動化 Automated Elasticity 可以即時自動根據來做預期做出應變上的措施,符合流量預期與達到客戶使用上預期的服務。

根據需求且彈性 (Elastic nature) 的提升 approach,簡單的控制電腦資源多寡且用很小的摩擦影響。另外過去軟體架構師不會花時間和資源去調整硬體的使用量,使用雲端這樣的概念要改變,如果沒法用抱改變去實作引用 elasticity 於應用系統架構中,就無法得到雲端技術的完整優勢。所以設計出聰明彈性調整雲端架構,這樣內部硬體設施根據需要去運賺,這是一個藝術。


不要害怕限制:

要瞭解雲端技術都是提供非常抽象 abstract 資源,根據需要把他們組成出好的模式是很強大的。例如:雲端不提供一臺機器用多少記憶體,而是使用分散式處理機制,將資料分散在不同台機器上。如果資料庫需要大量使用,那麼有件役選擇資料類型。如果是讀取很重應用系統,就要分散式的撒到同步的 slaves 節點上。

虛擬化管理:

雲端技術改變了系統管理員變成虛擬系統管理員。系統管理員不再只是監看伺服器和安裝軟體或者處理網路裝置,雲端現在只要簡單的 click 即可。所以系統管理員要開使瞭解技術上如何去管理抽象的雲端資源。像資料庫管理師也要改變變成虛擬資料庫管理師,去調整後面資料的儲存模式。從新對於資料的使用思考。如果待過傳統企業會知道,應用程式開發人員跟網路管理人員很不熟,網路管理人員也不知道應用程式是開發出來做啥。現在雲端技術,兩種角色已經合併唯一。當面臨這樣架構改變,企業公司要去鼓勵這樣的知識學習且兩種角色可能會合併的趨勢。

以上為雲端技術帶來思維上概念上的改變,在想做出 best practices,要先做中學才能對於這份後面介紹的 Best practices 有更多領悟了。

Amazon web services: cloud best practices (part 1)

在 Amazon Web Services Blog 上,有一篇相當棒談論 Amazon Cloud 的技術文件:New Whitepaper: Architecting for the Cloud: Best Practices 最後更新時間為 May 2010,可見這份還蠻新的,以下為我對於 Amazon web services 提供哪些特色的重點心得分享。

談到雲端架構 (Cloud architect),我們就要瞭解雲端運算的好處,從一般商業運轉上或者技術考量上,以及使用 AWS (Amazon Web Services) 今日可提供的服務來了解。

商業上考量,AWS 可帶來好處:
  • 可以從幾乎零的內部硬體投資做起頭。如果今天要打造一個 large-scale 系統一定要花很多空間實體設備硬體購買,以及周邊安全管理到運作控管,這些都是很高的起步投資,需要一堆管理的文件送審,擋住專案開始時間。如果用了可以根據使用量來調整的雲端運算,就不用需要擔心資金或者起頭成本。
  • 即時到位內部硬體支援。過去當系統變成有名使用量大,但是內部硬體卻無法 Scale 到位造成自己是成功的受害者。或者是,如果如果投資硬體過頭卻沒做起來,卻變成失敗的受害者。因此即時到位就不用擔心預購 large-scale 系統做準備,還可以敏捷的提升,降低風險和低運轉的成本成為 As you grow and only pay for what you use。
  • 更有效率的資源調整。系統管理員通常會擔心當硬體支援不夠的時候,或者硬體支援過多卻停擺時候。當使用 Cloud 可以更有效的管理資源,只要根據情況透過提需要或者放棄掉資源。
  • 根據用量來計費。透過用量寄費,只要去付使用到的 infrastructure 就好,這樣可以省去多餘的開支。
  • 降低進入市場所需的時間。Parallelization 平行運算是提升運轉一個最好的方式。當需要空間換取時間的時候,可以調整出多點運算來加快一個工作所需要運算時間。

技術上考量,AWS 可帶來好處:
  • 自動化。可以建立出 API-driven 的 infrastructure。
  • 自動化延展。可以根據 Application 來調整大小符合非預期內的需求。自動化可以帶來更多效益。
  • 主動預期的延展。預先根據流量模式的期盼需求,來控制延展系統大小。
  • 提升測試能力。絕對不要讓硬體不夠用來測試。開發過程,讓每個階段可以自動化測試。可以打造即時測試的實驗室,來做測試規劃。
  • 災難回覆和商業運轉持續。Cloud 提供了低成本的資料儲存,能夠幾分鐘內,透過點位置,進行分散部署備份環境。
  • 讓過量的流量帶到雲端。透過 load balancing 戰術,可以讓流量分散好好進入 cloud 。

Amazon Web Services 提供了很多樣化的 infrastructure 讓我們來部署 web-scale 的方案,我們了解一下 AWS 有哪些服務:
  • Amazon Elastic Compute Cloud (Amazon EC2) 是個 web service 提供雲端上可控制計算時所需大小。可以選擇需要的作業系統、應用軟體、和相關的設定。Elastic IP addresses 可以讓我們來分布動態 IP address 來分配到我們的各個 instance 上。透過 Amazon CloudWatch 來監看目前使用狀況。
  • Amazon Simple storage service (Amazon S3) 是個分散式儲存空間,可以任何時候存取大量的 data as objects 於一個大的 containers 中,只要透過標準 HTTP 的溝通協定。
  • Amazon CloudFront service 提供了 content delivery。
  • Amazon SimpleDB 是一個 web service 提供即時資料庫功能,可以即時查詢。只要將 Dataset 包裝成 domain 然後將它們儲存與使用。Domains 是包含了項目裡面有 attribute-value 組合。
  • Amazon Relational Database Service (Amazon RDS) 提供了簡單方式架設運轉關聯式資料庫於雲端。可以啓動 DB Instance 然後連進像是 MySQL database 不用擔心一般資料庫的備份管理與升級。
  • Amazon Simple Queue Service (Amazon SQS) 提供了分散式的 Queue 來儲存 messages,當這些遊走於 Computers 和 Application components 之間。
  • Amazon Simple Notifications Service (Amazon SNS) 提供了通知 application 或者人們透過建立標題和使用 publish-subscribe protocol。
  • Amazon Elastic MapReduce 提供了 Hadoop framework 去跑在 Amazon EC2 和 Amazon S3 讓我們去做 JobFlows。 JobFlows 是一種 MapReduce steps 的 sequence。
  • Amazon Virtual Private Cloud (Amazon VPC) 可以建置 Private Cloud 包含了各種 AWS 功能,建立安全連線,透過自己外部的 Data center 和進入 AWS gateway 進入裡面。
  • AWS 也提供了 payment 和 billing 服務,來計算目前使用所需要付的費用。

使用 AWS 雲端不用擔心犧牲太多,因為還是可以自由選擇 Programming model,程式語言 (Programming language) 和作業系統 (Windows, OperSolaris 或者各種 Linux) 作為選擇,可以自由選擇 AWS 的服務自由組合使用,提供了用量計費,所以可以根據用的來付費而已。而且提供了很多很好用的系統管理工具來幫忙上手。

以上僅僅是三分之一的重點整理,就覺得收穫很多,這份原文後面還有更進階更精彩的內容,包含了雲端概念和好的實踐模式,都是可以作為學習很好的題材。
另外如果您想要了解更多關於 Amazon 雲端服務,推薦參考『Inside - 網路趨勢行銷與開發』的雲端運算相關文章。

Monday, November 29, 2010

學習與道德 A World of Choice

資訊架構學書上談到關於教育的章節,作者分享了如何成為專家的方式,跟我們現在不論是個人學習或是團隊學習是很像的,所以稍微整理一下,更明確些方向出來。

現在 21 世紀讓我們有非常大自由去選擇我們要的。在教育方面,知識領域瞭解越豐富是成功的關鍵。有很多種方式可以學習,尤其想成為像資訊架構方面的技術與學問這方面的專家。相關的資源和方法可以如下:
  • 經驗學習:做中學是最好的方式。今日很多的專家是透過工作上學習的。所以自願性參與非營利組織或者參與社群、建立個人版是個最好的起頭開始。
  • 從學徒做起:從初學者進入專家,最快最好的方式就是和一位已經是專家很貼近的工作。嘗試找出啓蒙導師願意分享他們的知識。
  • 正式的教育:通常想成為這方面領域,就是去那方面領域學習,例如資訊背景的大學或是學院等。如果已經是職員了,也尋找相關學習的課程去上課。
  • 會議和研討會:只要去查詢,有蠻多相關課程、workshops和相關研討會不斷的在舉辦。嘗試去找並且參加與瞭解。
  • 閱讀書籍:書籍和相關文章關於資訊架構學。如果再用心找,可以找到相關的報告、問卷調查研究等資訊。
  • 社群:專業的線上社群是個很好的管道去學習最好的實踐方式,而且認識這領域的人們。線上討論串是個很好的起頭地方。
  • 新聞和論壇:新聞 News feeds 和部落格會包含這方面資訊和設計經驗,所以也可以很有價值的。可以持續跟上最新人們的想法。
要做到以上這麼全面有點困難,不過能越多方面的積極去參與,那將會是個學習很好的管道做為起頭。雖然這是資訊架構學提供學習方法,但是我想不論是學習何種領域的知識,只要從這些方式去找出資源來,那麼很快就能從初學者進入各個門道了。

另外資訊架構學談論道德方面,如果你我不曾想過這問題,沒關係這不是我們的錯,從來沒有人解釋一個好的系統要做 breadcrumb navigation,沒有人解釋過這方面資訊,如果沒有資訊架構學這些超級英雄定義出,我們初學者哪來潛在能力去分辨對的或是邪惡的。但是真實是道德是一個最被忽略的部份。作者提供了幾種方式讓我們去參考:

  • Intellectual Access。這邊舉例很好,好的資訊架構可以讓醫療研究人員找出疾病漏掉的那塊解。或者也可以讓一個生氣的小孩研究做出炸彈呢?不論是我們在怎麼樣環境工作,把這些道德資訊要做為個考量。
  • Labeling。我們在定義標籤系統時候控制辭彙時候,我們是要為了作者辭彙和使用者理解辭彙。希望將它們做到清晰可看懂,讓我們使用者產生的影響。
  • Categories and Classification。我們在建立 Category 分類法會很巧妙影響使用者理解,不致於產生不良的偏差或是陷入敏感話題。所以我們要照顧確保我們的分類法則。
  • Granularity。注重網站內容道德的品質。
  • Physical Access。如何將大量資料做成類似傳統的圖書資訊。資訊架構有角色要扮演好將有用實用資訊系統提供給觀眾使用。
  • Persistence。要做就要把他做好,所以處理後面資料儲存時,小心謹慎處理。我們不希望隨便打造出一個網站出來。
當一個資訊架構師,我們可以定義說這些道德議題出來,或者相反去說這不是我的問題,是使用者們使用上的責任。或者還是要去等一個英雄出來拯救呢?作者鼓勵我們讀一些關於關於資訊與道德相關的書籍介紹,把這些想法放到實作裡面,讓這可以讓為來更美好。

書籍介紹 Information Architecture for the World Wide Web: Designing Large-Scale Web Sites (By Peter Morville, Louis Rosenfeld )

Sunday, November 28, 2010

More User Interface Controls



在外文書籍 Beginning iPhone 3 Development: Exploring the iPhone SDK 裡面 Chapter 4 介紹 More User Interface control 的範例,可以學習更多 User Interface controls 的應用,和比次互動與牽連。

這個範例在畫面上我們將會有圖片,兩個輸入欄位,分別可以填寫 Name 和 Number。一個可以調整值的 bar 透過控制可以控制數值。一個切換選單可以選擇要秀 Switches 特效,或者切到按鈕出來,進行 action sheet 讓使用者做選擇。除了了解更多 iOS 特性,循序一步一步講解,讓我們體會 code-compile-debug 循環的方式,這也是軟體工程師日常工作模式。


經過這章節,可以學習到重點:

1. 顯現圖片:匯入與安排圖片 Image View ,透過控制調整圖片大小、從 Interface Builder 的圖片 inspector 裡面來設定關於這 Image View 的各種屬性。


2. 做出兩個 Text Field:引用 Text Fields,在 Text Input Traits 的 keyboard 讓它在輸入可以選擇引用的類型。要將 UI 輸入值讓 Controls 裡面抓的到,要分辨與引用 IBOutlet。要將 UI 操作產生事件,要分辨與引用 IBAction。


3. 按下任何背景可以達到收起來鍵盤效果:因為輸入數字的鍵盤沒有 Done,為了讓使用者使用起來輸入完後方便,加入了 backgroundTap method,然後將 UIView 改成 UIControl 再將 Touch Down event 拉向 -(IBAction)backgroundTap:(id)sender 串聯起來。


4. Slider Bar 可以挑選將其值顯現在 Label 上:加入 UILabel ,讓 UISlider 的 Valued Changed 可以跟 -(IBAction)sliderChanged:(id)sender 串起來。

5. 做出左右兩個 switch ,可以讓彼此互相聯動:所以要將兩者左右 value changed都拉向 -(IBAction)。


6. Button 按下去可以可以叫出 Action Sheet:將 ControlFuntionController 加入 ,實作 buttonPressed method 加入 UIActionSheet。


7. 讓使用者透過 Action Sheet 可以叫出 Alert 訊息:加入 actionSheet method,讓裡面可以帶出 UIAlertView。


8. Segmented Control 可以顯現隱藏 Switch 和 Button:將 value changed 事件拉向 - (IBAction)toggleControls:(id)sender,透過 Segment 值來決定 hidden 是要 on 或是 off。

9. 做個好的記憶體公民,記得時時做記憶體管理,在 dealloc method 裡面將有用到 property 記得 release,在 (void)viewDidUnload 也記得要將這些都清空。


當透過逐漸多的 Controller 學習,可以瞭解 IBOutlet 和 IBAction 以及和 Delegated 之間的引用,這邊真的要動手做學習,搭配 Xcode 和 Interface Builder 讓彼此可以輕鬆串聯我們要的特效出來。最後我有將實作的小 Project 放置在 gitHub https://github.com/edwardinubuntu/ControlFun,對
code 有興趣可以下載來試試。

Friday, November 26, 2010

iOS-based devices 上的 User Experience 準則

使用者經驗 (User Experience) 在 iOS-based 的裝置上,都是圍繞在使用者在乎關注的內容上互動。這篇是來自iOS Reference Library 裡面的 Guidelines,適用於所有 iOS-based 的裝置。這邊從 iOS Human Interface Guidelines整理了使用者體驗遵循手則,開發上要特別注意的內容重點:
  • Focus on the Primary Task:當一個 iOS app 是建立在專注在主要的完成事項上面,這不但可以滿足且在使用上可以帶來享受的。分辨每一個畫面上最重要的內容和彼此前後關係。總是問自己,決定要放在每一頁的顯示,這是複雜的資訊或者功能是使用者馬上需要的嗎?如果答案不是,考慮是否將這個資訊或是複雜功能先放在別的地方,或者它根本就不那麼重要。
  • Elevate the Content People Care About:強化使用者在意的內容,減少顯著控制項目的數量,幫 UI 做減重。
  • Think Top Down:設計上從上往下來思考,把最重要的資訊放在最上面,因為最上層是最常被看到的。
  • Give People a Logical Path to Follow:給與合理可預測的路徑讓使用者使用,也提供標誌可以回來。
  • Make Usage Easy and Obvious:讓操作簡單和明確,減少控制的功能、使用標準控制可以操作、標籤顯示讓使用者看了可以容易理解。
  • Use User-Centric Terminology:為使用者容易理解的辭彙去顯示在畫面上,越少的文字表達越好,也確保使用者看了會懂。
  • Minimize Required Input:能減少使用者輸入就減少,輸入時候讓使用者可以簡單的輸入。而當 iOS 本身可以提供這些資訊,就從那邊取得,當然些重要資訊取得要告知使用者。
  • Downplay File-Handling Operations:雖然我們電腦裡面有檔案管理系統,但是在設計檔案時候,不要讓使用者用像檔案管理一樣。可以透過高視覺圖片,讓使用者最少操作起來更順手。
  • Enable Collaboration and Connectedness:當可以時候,讓使用者可以簡單容易的和其他人分享事情,可以帶來不錯體驗,包含 location 和選像或者分數,人們也非常在意他們分享的重要資訊。
  • De-emphasize Settings:能減少使用者設定就減少,除了使用者為來使用上可能改變這些設定的才要做出來。
  • Brand Appropriately:設計自己的品牌圖像是不錯,但是避免拿走使用者在意的內容,所以放品牌圖像上去,都要注意到不要讓使用者覺得是在看廣告。
  • Make Search Quick and Rewarding:當資料多準備提供搜尋,所以要準備可搜尋。
  • Entice and Inform with a Well-Written Description:注重自己寫的說明,這是把 App 介紹給潛在可戶最好的機會。注意拼音漢文法還有標點註記。如果版本有更新,把修正的 bug 列出來讓期待很久的使用者可以看到。
  • Be Succinct:將描述寫的簡潔,好比是報章雜誌的編寫方式,標題法的風格。在建立內容也用最直覺一看就懂得的按鈕和圖案。
  • Use UI Elements Consistently:遵照使用者介面元素的標準來使用,如此一來使用者可以很快上手。
  • Consider Adding Physicality and Realism:能考量加入物理和實體的元素進來更好,把操作跟生活看起來行為接近,這樣可以讓使用者更好理解和操作,而且更享受。
  • Delight People with Stunning Graphics:用些可以吸引目光的圖型,例如木頭、皮革、金屬到系統裡面,確保這些看起來真實,這樣看起來會更漂亮,質感就會上來。
  • Handle Orientation Changes:設計上考量到裝置目前是哪一種拿法,要能針對這些時候作畫面和操作上的調整。
  • Make Targets Fingertip-Size:讓操作都符合拇指大小。像 iPhone 上面計算機操作最小就是採用 44 x 44 pixels。
  • Use Subtle Animation to Communicate:用微妙的動畫來顯示通訊狀況,透過動畫來顯目前速度是一般還是頗慢的。
  • Support Gestures Appropriately:在 iOS 裝置上都有些固定的手勢操作,避免使用到使用者不知道的。確保使用簡單直覺的方式來操作,簡單的順勢可以讓使用者注重在內容,而不是干擾。
  • Ask People to Save Only When Necessary:使用者可以有信心說當他們工作的內容是被服務的很好,除非去取消或者刪除。所以 App 幫忙使用者建立資料,確保他們不用特別去操作儲存。iOS 要能負責任幫忙使用者處理輸入。
  • Start Instantly:iOS app 啓動要越快越好,所以考慮使用顯現初始化圖片,避免顯現關於等資訊,而且能夠帶初使用者上一次跑的狀態。使用者不用去記得說上次操作步驟到他們要的位置。最重要,安裝完App,不要告訴使用者需要重新開機。所以開發上要注意到記憶體有效率的使用。
  • Always Be Prepared to Stop:隨時隨地做好使用者中斷的可能,所以在有理由地時間點儲存使用者的資料越快越好。當被停止要記得儲存使用狀態。
  • Don’t Quit Programmatically:不要莫名其妙的讓 App 停止結束,這樣莫名的結束會讓使用者以為應用程式操作毀損。假設真的發生了,要告訴使用者怎麼操作,提供描述問題的方式,給與修正的建議。如果使用者操作到一個不能運作的功能,顯示 alert 給使用者知道狀況。
另外一方面,我翻書回到互動設計裡面一開始在教導我們的何謂互動設計,其中的目標有這些大準則:有效性、迅速性、安全性、功能性、易學性、易記性。這邊是可以對照來看的。

我們在使用 iPhone 或者 Smart Phone 的 App 操作上用起來偏向滿意,其實背後開發者設計也要遵循這些標準作為開發上考量,自然能帶出好的使用者體驗。iOS 使用者介面開發準則不就是也包含互動設計目標的項目了嗎!所以下次要評估一個 Application 在使用上做的好與壞,看看可以給幾分,我們就可以拿以上這些來做評量標準,達到改善的空間。

以上詳細可以對照到原文 User Experience Guidelines 有詳細內容,也有包含了些圖片說明。

Thursday, November 25, 2010

Outlet 與 Action

我們會在 Xcode 寫程式和 Interface Builder 製作畫面,按照 Cocoa Touch 開發概念 Model-View-Controller 的切割我們的 GUI-based application。但是要如何將彼此連接起來呢?因為我們也是要寫 code 去處理這些 Interface Builder 建立出來的 elements。

我們的 Controller class 是可以參考到 nib 裡面,使用特定的 instance variable 叫做 outlet。把他想像是一個指標指向 nib 裡面的 object。舉個例子,今天在 Interface Builder 建立了 text label,希望這 label 上面的 text 可以從程式裡面改變。透過宣告 outlet 然後將它們彼此連起來,就可以從程式碼裡面調整值了。

Outlet 是用 IBOutlet 關鍵字來宣告成 instance variable,所以宣告完會像這樣:

@property(nonatomic, retain) IBOutlet UISlider *redSlider;

任何 instance variable 想要連到 nib file 都要用這樣關鍵字。當打開 Interface Builder,它會掃描 Project 裡面檔案開頭有這樣關鍵字,讓我們開發人員可以從程式連接到 nib。

在 nib 檔案裡面的 Interface Object 可以設定來驅動到我們 controller class 特定的 methods。而這是用 action methods。舉例,今天可以告訴 Interface Builder 當使用者按下螢幕離開後,呼叫程式裡面特定的 method。

Actions 是 controller class 裡面部份的 methods。他們是用特定關鍵字 IBAction,讓 Interface Builder 可以驅動將 action 帶到 control。一般來說會宣告類似這樣:

- (IBAction)updateColor:(id)sender;

Method 名稱可以自己定義,但是一定要回傳 IBAction,跟回傳 void 很像。這是另外一種 action methods 不回傳值的方式。一般來說,Action 會接受參數,定義 id 然後加上 sender。Control 會驅動我們的 action 而使用 sender 參數傳遞。所以如果 action method 是呼叫按鈕按下,就會讓它去對應到特並按鈕被按下。

不論在 method 要宣告 sender 或者不宣告都不會影響。因為可能我們在看些範例時候,會看到不一樣寫法,這是因為有歷史的,過去 Cocoa 不管有沒有使用到都是要規劃 sender。

最近寫了一些範例練習題,開始接處到這邊,原本 action, outlet 一直不是很懂,經過閱讀 Beginning iPhone 3 Development 的 Handing Basic Interaction 就更了解了。

Wednesday, November 24, 2010

appWorks 新秀團隊的大夢想

今天參加了 appWorks Demo Day,這是一個給關心台灣網路業發展的朋友,來見證歷史性一刻的活動,第一屆 appWorks 育成計畫團隊第一次向世界展示他們的創意,以及六個月來努力開發的成果。而我有如此特殊機緣(非請假或者蹺班的機會)坐在台下聆聽每一團隊帶來的感動,認真做了摘要心得筆記。這些團隊全部都很優秀,因為他們已經踏出去實踐他們的夢想。而我想要分享的是我參與得到的震撼性感動。

創立團隊
在創立團隊時候,有非常多的事情要考量。但是第一點一定要被點燃的,那就是『熱血與夢想』。當有這個共同的信念存在時,同好夥伴們就一拍擊合了,從兩人團隊逐漸擴充到十人團隊都可能。挑選成員很重要,除了要在該領域是頂尖有共通想法之外,最好是能組成不同產業背景的夥伴,且跟要賣的點子需求背景有息息相關,這樣能做出更廣更強的服務。


首先了解大環境的痛處與缺陷
大家齊聚一堂,一定是發現了不滿意現況,例如:消費使用者要花很多時間找他們要的資訊、太多的廣告不是他們要的、環境(實體或者虛擬環境)太困難無法實現他們的想法、希望可以讓消費使用者可以有一個新的選擇,節省他們的時間,在意消費者的痛處,最後讓自己做到供應商和消費者搭上的那條紅線的媒婆。

評估現在潮流趨勢

除了了解市場趨勢與需求,也要做 SWOT 分析,找出自己的優勢:要做一個操作簡單又好玩服務,善用 Web 3.0 改善使用者體驗。分析找出自己團隊的機會在哪邊,有哪些背景人才可以帶出多元的技術服務,且分析市場上有哪些競爭對手,找出彼此差異處,自己的優勢在哪之後,畫出區隔線來,這樣最後就可以蹦出那個『賣點』。


技術優勢
如果自己團隊不但可以把想法實踐做出來,甚至還可以提供整合上的 API 讓第三方或者合作方可以進一步整合,這將會是打開自己疆土的最佳契機。


分析消費使用者
是否可以解決他們金錢上的困擾,達到省錢,甚至不要當成冤大買貴了。做到貼心讓使用者只要 one click 即可解決很多的不便性。品質的承諾,內容是最重要,怎麼樣提供高優質的內容品質也是影響關鍵。最後如果使用者使用過後,能夠讓他們留下美好的使用者經驗,創造他們難忘的經驗,這樣在做 user story 就更有看頭。

分析供應商

這是一聯串的活動。從分析開始,了解供應商沒有你們這個團隊前,面臨怎麼樣的困處或者遺憾,找出這些供應商開始跟他們談接洽合作方案,可以整合店家完整資訊、找尋折扣訊息、和供應商合作同時是否可以有拆賬模式 (增加團隊收入來源)。如此一來資料就會齊全,讓消費使用者可以有完整資訊,甚至未來可以進一步談到 POC 或者 CRM 整合的願景。

開始實踐

因為現在最新的術語 Web 3.0 (Web 3.0 包含行動、社交、內容) 已經在改變整個趨勢,如果能達到虛擬搭配實體帶起行動力,將會是很棒的機會。在行動方面善用這些 device 的優勢,看圖方便、上網便利、搭配 location 找出附近最新消息都是不錯方法,套用 cloud computing 想解決的精神:Any time, any where, from any device。在社交方面整合 Facebook、Twitter 等可以幫忙供應商提升曝光度、讓資訊可以(連結 + 分享 + 跨網站)的特性。內容則是注重品質,了解使用者想要的資料內容、供應商可以給與的第一手消息,為彼此搭上橋,創造全贏的局面。


上次讓我有如此熱血沸騰感覺實在大學畢業專題一年多來的成果發表,我還記得站在台上賣力講解自己專題理念與實作方式的場景,今天身為台下觀眾之一的我,再次感受到那份要將最好一面帶給外面世界的那份熱情。最後讓我分享最喜歡的一句佳句最為結尾:『在實現別人夢想的同時,也實現我們自己的夢想。』


想了解更多關於 appWorks 在做什麼,可參考 appWorks Ventures 之初創投

Monday, November 22, 2010

原型 (Prototyping) 製作與概念設計

通常使用者說不出來他們想要什麼,但當他們看到某些事物,並使用過後,很快就知道他們不想要什麼,想要什麼。

在我們開始設計前,蒐集了相關資訊並了解系統應具備和不具備的功能後,我們需要藉由製作原型 (Prototype) ,甚至有不同版本,來驗證我們的構想,重複這循環月多次,產品的成果才會越理想。

原型可以是任何書面為主的故事板、軟體畫出來、紙板草模。一個能讓權益關係人和想像階段的產品互動,從真實環境中取得某些使用經驗,發掘出想像中的用途。原型可以測試出構想的技術可行性、確認某些模糊需求、進行一些使用者測試及評估或檢查特定設計方向是否與發展中的系統相容。這些目的都會影響到原型製作的種類。

低精準的原型製作
低精準的原型看起來較不像最終產品,例如是用紙或是硬紙板和最終實體電子螢幕或者金屬材質有很大差異。這樣優點有便宜、可以評估多重設計概念、對確認市場需求非常有用、證明構想。缺點則會有:較少進行錯字檢查、較少規範細節、需求建立後會限制功能、對使用者測試使用有限制、導覽和資訊的限制。

故事板是一種由情境法和結合使用性的低精準度原型,描述了使用者使用該系統可能必須經過的步驟。草圖也是一種,但是要著義到繪畫的品質和程度,Verplank 建議我們要發展自己速寫對象的符號或者標誌,並且練習使用它們。

高精準度的原型製作
高精準度的原型製作是使用預期上和最終產品有相同的材料,看起來和最終成果相當相似。使用起來優點有:完全功能性、互動性高、清楚定義導覽計畫、有最後專案一眼的感受、市場銷售的工具。當然也有缺點:製作花費時間過長、更花時間創造、對構想設計證明較不足、軟體原型可能高估了期望、測試過程中有小問題,會導致測試終止。

我們要如何在這之間取得妥協呢?目的在於快速生產可以測試產品某些問題的東西。像紙的原型妥協地方是無法像真實產品一樣運作。若是選擇軟體為主,就要妥協反應時間較慢、只能提供部份功能測試。

水平原型 (Horizontal prototyping),提供範圍更廣的功能但是只有少許細節。垂直原型 (Certical prototyping),提供了許多細節但是只有部份功能。這方面也一直是拉鋸和妥協要談得廣度和深度。

在運作上的指導原則是:

  • 牢記並不能忘記使用者和情境。
  • 儘可能和關係人討論。
  • 使用低精準原型取得快速回饋。
  • 反覆、反覆、再反覆。Fudd 的創造力的第一定律:欲取得好構想,先產生越多構想越好。

我們必須解決使用者和產品的溝通,他們是如何架構、關聯和呈現。所以了解產品將支援的工作是發展概念模式最根本問題。再來是功能都有了,彼此間也是會有相關。例如一項工作是要依另外一個工作完成才能開始。這樣就要限制使用者照著步驟來執行。

我們在概念設計時候引用了情境法,情境法可以用來解決現有的工作情形,更常用來表達所提出的想法情境可以幫助概念設計,Bodker 確認此可以有四種角色:作為整體設計的基礎、提供技術上執行、作為設計團隊間合作的工具、作為跨領域合作的工具,多元專業團隊溝通的工具。

以上為原型製作和概念設計的心得筆記,想要更詳細內容,參考 互動設計(二版) - aNobii
- 設計、原型製作及建構。圖片為 iPhone Mockup 繪製的使用者登入範例

Friday, November 19, 2010

John Sculley 談論 Steve Jobs methodology

John Sculley 是一位美國生意人,擔任過 PepsiCo 的 President (1977-1983),Apple Comupter 的 CEO (1977-1983),現在是 Sculley Brothers, LLC 的投資合夥人之一。

Q. 您說過 Steve Jobs 的方法論。Steve 的方法論是什麼?

Sculley:讓我給你一個框架 (Framework)。我第一次跟 Jobs 會面,是在 25 年前,他把所有這樣的原理放在一起,製作出傑出的產品,我稱作為 Steve Jobs methodology。

從最一開始我認識 Steve,他總是喜歡漂亮的產品,尤其是硬體方面。他來到我家,他也對於我門口有個特別的鎖門門閂設計樣式非常著迷。我是一個工業設計家,讓我跟 Steve 有連接地方是工業設計,而不是電腦。

我不太懂電腦,當時世界上大家也不太知道。這是最一開始個人電腦的革命,但是我們兩者相信漂亮設計,且 Steve 特別強調注意使用者體驗的設計。

他總是會透視長遠來看使用者體驗將會變成怎麼樣,但是跟現在大部份人做產品調查不一樣,現在是出去找客戶做測試、市場調查,問人們『他們要什麼?』Steve 不相信這樣。

他說:『我要怎麼可能去問某人圖像基礎的電腦 (graphic-based computer) 應該的樣子,當他們對於圖像基礎的電腦沒有任何了解?沒有人看過。』他相信就算秀給其他人看計算機,這樣對於他們要給電腦長相來給建議也跳躍太大了。

Steve 認為長遠來看要從使用者體驗開始,而工業設計是一個對於使用者觀點非常極為重要的。而他招攬我進入 Apple 因為他相信電腦會變成消費者產品。這對當時 1980's 是非長不像話的點子,因為大家想說個人電腦只是大型主機的小台版而已,這也是當時 IBM 這樣看待的。

有些人認為電腦會是像電玩機器,因為當時是這樣簡單在電視上面玩。但是 Steve 相信這將會是完整不一樣。他覺得電腦會改變世界,讓每個人做夢而言都沒想過,電腦可以擁有強大的性能。這不是電玩機器,這也不會是大型主機變小而已。

他是一個看事情非常透徹長遠的,但是他也相信對於每一個步驟都要看到非常精確才行。他會對於每件事情都非常詳盡小心,一直『完美主意』到最後。

讓 Steve's 的方法論和大家不一樣地方是,他總是相信最重要的決定是,不是那些要做的事情,而是那些決定不要做的
。他是一個簡約主義者。

當我第一次看到 Macintosh,這是一個系列過程產生的,Steve 有這樣能力去找出最好最棒最聰明的人才。他是一位極有魅力和極會促使人們願意跳進來和他工作,他也甚至在產品問世前讓人們相信他的願景。當我和 Mac team 碰面時,團隊僅有 100 人,當時我覺得這是小團隊,平均年齡僅有 22 歲。這些人是從來沒有建置過商業產品,但是他們相信 Steve 和他的願景。他們有辦法在同時間不同層級的一同工作。他總是可以找到該領域最頂尖的人才,他個人親自去募集他的團隊。他從來不把這事情委派他人。

Mac 團隊僅有一百人。Steve 有個規定就是 Mac 團隊不能超過一百個人。如果想要增加某人,就得把人拿掉。這是 Steve Jobs 的觀點:『我無法記超過一百個人的名字,所以我只希望和我個人知道一同工作。所以如果當他大超過一百人,那就會變成不同的組織架構,變成我不能這樣作業,我喜歡我觸摸到每件事情上來工作。』當時我就是這樣知道他就是如此去運轉 Apple 的。Steve 說:『組織可以變大,但不是指 Mac 團隊,Macintosh 是被設立產品開發部門。當然還有中央行銷組織,一個後端管理部門,法務等。高科技產品是這樣的,開發好產品是不用太多人來開發。』人們總是會相信一定是上百上百個人開發作業系統。但是實際上不是,就只是一個小團隊的人。想想看這就像是一個藝術家工作室,Steve 是一個總導師,會到處走動看大家工作,給與看法意見,通常也是會拒絕退回工作的東西。

他總是會要求人們提高對於自我的期望,所以人們是在他們連自己都沒想過有擁有這樣本領的工作。因為 Steve 會用很高的魅力感染力和動機交互切換來鼓勵讓他們興奮,他們覺得自己是可以如此瘋狂地棒。但是在另外一方面,Steve 是會最無情的形容來退回他們的工作,直到覺得已經達到一個夠完美的層級了,這樣的情形,Macintosh。

以上是其中一段訪談,翻譯自 John Sculley On Steve Jobs, The Full Interview Transcript

Sunday, November 14, 2010

設計規劃一個 iPhone Application: 從產品聲明書 (Product Definition) 到品牌化 (Branding)

當我們在開發一個 iPhone Application 必須學會知道 iOS 在各種獨特功能特色情況下,如何影響到我們的設計決定。這篇是閱讀 iPhone Human Interface Guidelines 重點整理,包含了怎麼引導開發 iPhone application 前,先考量將產品定義到變成品牌化,和裝置表現這樣一個 iPhone application。

建立一份定義產品的聲明書

在開始設計 application 前,定義出 application 要做什麼是很重要的。一個好的方式就是簡短的產品定義聲明書,一個可以明確定義產品主要的目的如何影響使用者。如此一來也能讓一系列的功能特色跟此產品有關聯。開始前,花點時間定義使用者:他們是有經驗還是新手、是嚴肅場合還是輕鬆休閒的,是找一個可以解決問題或者是要找一個娛樂呢?了解這些項目可以幫助我們更知道使用者需要的體驗,和使用者需要的介面。因為是設計一個 iPhone application,所以應該知道一些使用者行為了,例如:是使用 smart phone、他們希望可以快速開啓 application 即時看到有用的內容、他們只需要幾個步驟可以達成事情。

現在問問我們的使用者特徵,他們是商業人士、青少年還是退休人士?他門是每天結束使用我們的 application,還是每次檢查某項目、或者他們只要有閒暇時間?當我們可以越明確定義出我們的使用者,我們就能越明確為我們的使用者介面、功能、外觀做決定。

舉例來說,如果今天是要幫助商業人士追蹤他們的開支,那麼使用者介面就要專注於提供對的分類項目,簡單容易輸入花費,而不需要問太多他們不在意的細節項目。更好的話,在挑選界面外觀顏色要以專業為主,讓使用者可以一天看上好幾次。

或者今天是要開發遊戲,對象是青少年,這時候就會希望介面看起來活潑有趣、語言看起來生動、顏色看起來是很潮流酷炫。

最後,說明這套 application 一系列功能特色。為了讓使用者可以腦海中有概念,把一系列的功能特色放進簡單一句話,一個產品定義聲明,可以用來形容提供的產品,適用於哪些使用者。舉個例,在 Mac 上的 iPhoto 會說,讓使用者可以組織、編輯、分享、沖洗列印和觀看照片。但是一個好的產品定義不會希望只是把特色寫下,而是要描述可以打動使用者。那麼這個 iPhoto 定義就要是『給業餘攝影同好一個簡單使用照片管理應用程式』,英文可以這樣寫 "
An easy-to-use photo management application for amateur photographers." ,想想看這樣描述的差異。

一個好的產品定義可以用來作為勾勒出一個好的工具來思考開發上的特色、功能、和用詞術語。當然也消除掉那些不是產品定義的項目和特色。因為 iPhone application 沒有太多空間去放不是主要的功能。

想像一下,正在開發一個 iPhone application 讓使用者方便帶到雜貨鋪購買商品使用。在規劃階段,會想到一些使用者會喜歡的功能,像是:『取得食物的營養成份、找到折價卷項目、購物清單、商家位置、找出食譜、價格比較、計算目前購買商品總價。』但是我們相信使用者最需要是要記得他們要買哪些商品,他們可以省錢更好,他們可能急著購買後回家。定義出使用者,就可以將產品聲明書寫出來,這是『提供給趕時間的人,一個可建立購物清單和找出折價商品的工具。』,英文可以這樣子 "
A shopping list creation and coupon-finding tool for people in a hurry." ,經過這樣定義,就可以明確引導出功能特色,簡單建立、儲存、使用,提供使用者可以找到清單上折價商品。雖然其他功能特色也很不錯,但是他們不會定義在這功能主要的特色聲明。

當定義好產品聲明書,就可以透過這來過濾掉想開發的功能特色,再將這開發功能回來跟聲明做明確的對應比較,再次確認這些功能是我們定義的聲明書內容。

好的 iPhone Application 的特質

最理想的 iPhone application 就是可以提供恰恰好的功能給使用者使用來完成他們要做事情,為了達到這目標,我們可以參考一些好的 iPhone app 該有的特質,作為開發上重點考量。

打造簡單化容易使用

  • 使用 application 是可以容易明瞭的
  • 考量到頻繁使用情形,越重要資訊要擺在上方
  • 減少使用者輸入
  • 簡潔表達不可或缺的資訊
  • 各個介面元素項目要符合手指可操作大小
專注於主要的工作項目:馬錶計時專注時間、日曆功能

介面說明簡潔明確

將品牌元素小心翼翼整合

品牌是個容易理解的象徵。使用者使用 iPhone application 希望將事情完成或者是娛樂,他們不希望感覺到他們是要專注在看廣告。所以要將品牌的顏色圖片做重新定義一番,尤其是 application 的 icon,這是使用者們最常會看到的部份,所以這在設計上也要最注意,讓視覺上要被可接受和明辨的。

以上這是心得重點整理,當開發 iPhone app 需要參考 iPhone Human Interface Guidelines,其中 Designing an iPhone Application: From Product Definition to Branding 章節。

Friday, November 12, 2010

確認需求及建立需求

我們的目標是要儘可能了解使用者、他們的工作和工作的情境,藉此來發展支援使用者達成目的的系統,這是確認需求。再來是從確認需求,產生一系列穩定並且導向良好的設計需求。不用寫成很嚴格規定或者主要文件,但是要知道會隨著時間或者回饋的意見而做改變,我們最後目的就是要產生ㄧ系列的需求。

在這設計需求的過程裡面,我們會碰到『資料蒐集』、『資料解讀分析』、『產生工作描述』,這是一種反覆式的活動。

需求有分為兩種,一種是功能性需求,指出系統該做什麼。另外一種非功能性需求,則是界定系統開發上的限制。例如開發內容的格式被受限制。

環境需求在互動產品裡面被預期拿來使用的環境脈絡,有分為四種:
  1. 實質環境 - 預期產品使用時的環境需求,包含燈光、噪音灰塵等,可能影響互動的情況。
  2. 社交環境 - 是否需要協調或者協同,有無檔案資料需要共用。
  3. 組織環境 - 使用者本身是否有訓練的資源或設備,公共設施或者組織層級關係等等。
  4. 技術環境 - 任何技術限制都屬於此類。
這邊有一個案例探討,『一家自助餐廳中,讓使用者利用信用卡購買實務的系統』,為這情境提出關鍵的功能、資料、環境、使用者及使用性需求的建議。我們可以這樣劃分。
  • 功能:系統要計算購買金額,是否搭配活動折扣。
  • 資料:系統需能辨識餐廳產品的價格
  • 環境:餐廳使用者可能使用端盤,而且會匆忙。實質環境會吵,使用者使用系統時候,可能會和朋友同儕聊天。
  • 使用者:使用族群各年齡層都會有,所以製作新科技上,要考量到越簡單越好,以免造成不適應。
  • 使用性:系統要簡易,使新的操作者也能立即會使用。時常使用的人能記憶如何操作。使用者不願意等候系統執行時間,所以要有效率ㄝ對使用者造成失誤能輕易解決。
資料蒐集是需求活動和評估的重要部份,目的在於蒐集足夠、相關和適切的資料,並藉此產出套穩定的需求。方法有歸納以下幾種:

問卷,用於回答詳細的問題。資料種類是量性和質性資料。優點是可以以少資源方式接觸到許多人,缺點是問卷設計本身非常重要,回覆率可能很低,回覆的資料可能也不是想要的。

訪談,用於探索議題。資料是一些量性的資料,但多數質性資料。特色是如果需要訪問者可以引導受訪者,鼓勵開發者和使用者的接觸,缺點是較耗時,且在人工環境中會容易脅迫到受訪者。

焦點團體和工作坊,用於蒐集多種觀點,資料是屬於量性但是多數質性資料。將意見相同和不同明白指出,鼓勵開發者與使用者間的接觸。缺點可能會有碰到主導的角色存在。

自然觀察,用於了解使用者活動內容,資料屬於質性。優點為觀察實際的活動深入瞭解,此為其他活動無法造成的。但是缺點非常耗時,且資料量會龐大。

檔案文件研究,學習程序、法規及標準。屬於量性的資料。優點是對使用者而言無須時間上的承諾,但是缺點是每日的工作方式會跟程序尚有所不同。

每一種技術方法有一些優缺點,何種資料才是我們要的,會取決於我們採用哪一種位置活動去執行。當以上這些活動都進行了,資料蒐集到了,後面才會開始資料解讀和分析。

資料需求分析可用實體相關圖 Entity-relationship diagram、情境模擬 Scenarios、使用案例 Use cases、基本使用案例 Essential use cases 以及工作分析 Task analysis。這些技術在很多書本都有更專業的教導,當最後將這些分析輸出成文件結果,可以作為後續資料蒐集的工作上反覆地使用。

更多資料可以參考 互動設計(二版) - aNobii - 確認需求及建立需求

Wednesday, November 10, 2010

App Magnets Solution

First, 首先我們要知道使用者(真正)想要什麼。例如想要一個簡單的 Interface 來操作,可以和什麼 service 平台做溝通,使用者不用輸入太多。所以把想法和需求列成清單,作為設計的考量。

再來我們準備些磁鐵,沒有磁鐵準備便利貼,在上面寫下 Determine app layout, Build the GUI, Figure out how to use the controls, Handle the data, Send output to (Somewhere)。

這些步驟是個典型開發 iPhone app 的步驟,我在參考其他書籍介紹些範例,也都是以這樣模式。先把要做的整個概念先寫出來,再來去想想怎麼互動,假想的完成品要怎麼去使用和測試。在反推到大 概會用到 iOS 裡面哪些 framework 或者是 classes ,再來才開始設計與開發。

所以排出開發一個 App 的步驟會是:

  1. Determine app layout - 在開始寫任何程式之前,先把想到的草圖畫出來。
  2. Build the GUI - 將整個畫面的 layout 先勾勒出來。如果想先從 code 開始寫也是可以的。
  3. Figure out how to use the controls - 當已經佈置好 app 的設計後,要開使參考文件去想怎麼實作 controls 的部份。
  4. Handle the data - 處理將 controls 輸入進來的資料
  5. Send output to (Somewhere) - 將最後結果想要怎麼還給使用者畫面上
更多資訊可以參考 Head First Iphone Development - iPhone app patterns

Monday, November 8, 2010

Apple 邀請 Developers 可以準備送交 Mac 應用程式

根據 New York Times 的文章 Apple Invites Developers to Submit Mac Apps 報導,開發人員過去如果已經建立了 Apple 產品,包含 iPhone, iPad 和 iPod Touch,會在上週三收到 e-mail 邀請可以送交 applications 到未來的 Mac App Store。

Steven P Jobs,Apple 執行長宣布公司在上個月宣布過,未來會有 software 透過 Mac App Store 來 delivery 產品,一個系統讓使用者可以透過他們的 Macs 來下載安裝軟體。

Mr. Jobs 說公司已經學到很多關於 software, 遊戲和內容在 Apple iTunes store 上面相關經驗,想要把這樣的資源挪到支援 Mac 桌面上。

在這封信裡面,開發人員被邀請可以提交他們 Mac applications 的點子,當然還是首先必須要經過 Apple 檢驗程序,在准許放到 Store 上。

一些開發人員有疑問關於這樣新的 Store 要怎麼運作和這樣送交的應用程式,不論是遊戲、多媒體等等,怎麼跟傳統 applicaiton 像是 word-processing 和 photo-editing 等包裝的差異。

John Gruber, Daring Fireball 作者,一個 Apple 相關部落格。推測說可能一些開發人員會送交稍微修正 iPad 應用程式的介面符合桌面使用,再送交到 Mac App Store。

在未來兩個月內,Mac App Store 是還不會被宣布公開問世。現在邀請的開發人員,Apple 公司是希望確保可以營運以前預先有些 Software 在架上做準備。

以上想了解原文,可參考 Apple Invites Developers to Submit Mac Apps - http://nyti.ms/bXsRbu