Pages

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

Wednesday, November 3, 2010

當你不是一位 Programmer 的時候,如何應徵一位 Programmer

我在 37signals 的部落格上面讀到了原文 "How to hire a programmer when you're not a programmer",看了相當有興趣,這篇可以拿來當作成為一位好的 Programmer 的借鏡,而且這篇是從聽聽他們給不是 Programmer 的面試官一些面試方向與參考的方向來寫,角度相當特別。

如果你不是 Programmer 要如何應徵一位 Programmer? 這邊有些方法可循:

1. 他們對於程式自信了解有多少?問問他們關於開發的主題 (例如:Ruby or Python?)。因為透過這樣可以揭露很多有意義的答案。當人們對於這方面事情有很強的觀點,他們有能力可以講出一些觀點,那這是代表他們很有熱忱的一個很好象徵。

2. 他們對於 open source 的 projects 貢獻有多少?
看看他們的貢獻。因為只要人們開始有貢獻一點點東西就是一個很好的開始。當人們有在貢獻就代表他們在使用該工具,他們就像在抓癢,像是碰到某些事情看了知道需要 improved,或者碰到 bug 然後自行解決掉。當這種層度的參與就是一個很好的辨識度。

3. 他們有多享受 programming?
他們不用空閒時候每分每秒 hacking,但是你希望可以看到一些層度的熱愛。所以在一些閒暇之於寫寫程式是相當重要,顯示出些熱愛。

4. 他們真的可以提交 (ship) 工作嗎?
找出他們如何管理他們的工作。軟體開發時常翻車滑倒,所以找出他們如何避免這樣。找出他們可以在規定時間內準時提交時候,這樣專案是成功的。或者從延遲裡面找出教訓。要 ship 軟體是很困難刁鑽的,他們如何管理將任務可以切割然後按照重要性完成,在一定的時間內完成。

5. 他們有沒有專長 (mastered) 項目?
找出他們有專精於某一項目。是個很好的主廚候選人?山岳腳踏車選手?或者其他?這是一個象徵,他們也能在你的專案變成 master。他們很難可以在工作項目變成 master 如果他們在來這工作以前沒有當過體會過 master。

6. 他們如何溝通?
當你了解的越少關於 programming,那麼你就要越依賴這位的翻譯能力。不論哪一個職務應徵,找一位很好的 writers 是個不錯點子。當 Programmers 可以同時 coding 又可以講給非 programmers 瞭解,事情就會很少出差錯或走錯。

還是要自己來?
雖然以上可以給些幫助,但是最好方式還是要去了解一些關於 programming。面試一個你從來沒有做過是很難的。當應徵進來之後要管理也一樣很難。所以多多少少還是要學一點。在 REWORK 裡面提過:"Never hire anyone to do a job until you’ve tried to do it yourself first." 在 37signals 在應徵工程師前,面試官會學 PHP,在應徵系統工程師前,面試官本身就要管理過 servers 等等,這樣才能有深入的瞭解要找的候選人是不是可以幫你解決問題。

一個簡單 iPhone app 顯示訊息和圖案


這是一個 iPhone app 顯示訊息外加上一個圖案,不需要寫任何程式碼的最基本範例。將會需要用到 Xcode 和 Interface Builder 這兩個開發工具。


首先打開 Xcode,建立一個新的 project。Xcode 提供很多種 Templates 可以用,像是 Navigation-based applications, tab bar applications, utility applications 等等。選擇 File > New Project 這邊建立新的 project,選擇 Window-based application 這是最簡單的 template,其他的 template 都是這個的加強版。當選擇了 Choose... 按鈕,就會彈出視窗選擇 project name 和路徑,好了之後按下 Save。


接著我們來到左邊 Resource 右鍵選擇 Add > Existing File.. 挑選一張想要擺的 image 檔案。選完記得勾選 Copy items into destination group’s folder (if needed) ,就可以看到將圖加進來了。


雙鍵點選 MainWindow.xib ,會開啓 Interface Builder。要建立接下來的 app,需要製作圖片和訊息。在 Cocoa,圖片是使用 UIImageView class,從 Library 可以找到 Image View,將它拖拉到 window,在透過邊筐來調整想要顯示的 Size,也可以按住上下左右調整位置。接著在圖片上點選,選擇 Tools > Inspector,Inspector window 就會開啓,可以讓我們調整 GUI 元件。在這邊我們將圖片調整:Image 選擇剛剛加入的圖片、Mode = Aspect Fit。


接著我們要配製訊息,在 Library 找到 Label,將他拖拉到 window,一樣可以調整大小和位置,接著打開 Inspector window,我們要調整:顯示的 Text、Layout 選擇置中、#Lines 2、調整 Font size minimum 為 20。


存檔之後,我們回到 Xcode,選擇上方 Build and Run,就可以看到 Simulator 啓動,載入我們的 app 顯示出來。iPhone 開發是伴隨著 GUI design 和 Objective-C coding, Interface Builder 可以用來開發視覺化 GUI,避免頭痛 GUI 開發、Objective-C 開發可以寫出程式想要表達的行為。


更多可以參考 IPhone for Programmers - Welcome App Dive-Into® Xcode, Cocoa and Interface Builder, gitHub 程式碼範例

Tuesday, November 2, 2010

Interface Builder

Interface Builder 通常簡稱為 IB,在 Project 下面有各種分類檔案,其中當打開 *.xib 會開啓 Interface Builder。

Interface Builder 有很長的歷史,它從 1988 年就開始被使用於開發 NextSTEP, OpenSTEP, Mac OS X, 和現在的 iPhone 應用程式。 Interface Builder 支援兩種檔案類型:一種是舊的格式附檔名為 .nib,新型的格式附檔名為 .xib。在 iPhone project 裡面預設都是使用 .xib,但是直到最近,所有 Interface Builder 檔案附檔名為 .nib。Interface Builder 檔案都通常被稱為 nib 檔案,不論是附檔名為 .xib 或者 .nib。而且實際上,Apple 實際在文件裡面都是用 nib 這個 term。

我們可以透過寫 code 來建立一個 button,但是更好用點,可以使用 Interface Builder 來建立 button ,且設定它的 attributes 不論是 shape, size, label 等等。舉例來說,想要加一個 button 到 application,可以寫這樣子:

UIButton *myButton = [[UIButton alloc] initWithFrame:aRect];

在 Interface Builder,我們可以達到同樣效果,透過拖拉一個 button 到 application 的主要是窗裡面。Interface Builder 讓它簡單來設定 button 的 attributes,當 button 會儲存在 nib 檔案裡面,應用程式再啟動時候,就會自動的建立 show 出來。

在每一份 Nib 檔案裡面,起頭一定會有兩個 icons,分別是 File's Owner 和 First Responder。它們是自動被建立起來,而且不能被刪除的。所以到這邊就可以知道,它們的重要性。File's Owner 是一個 object 記載這份 nib file 是誰 owns 它,而 First responder 是一個 object 記載當使用者正在跟它互動。例如當使用者正在輸入資料到一個 text field,這個 field 是正在使用的 first responder。先知到這樣概念,這兩個檔案一定會存在。剩下在 IB 的 object 就是開始逐漸透過旁邊介面一一建立出來。

在很多軟體開發環境會用到一些可以讓我們透過視覺界面建立 user interface 的工具。但是 Interface Builder 和其他工具有很大差別,在於 IB 不會產生任何需要維護的程式碼。IB 會建立 Objective-C objects,就如同從程式一般,但是它些會放入nib 檔案,透過 runtime 被載入到 memory 裡面。這樣可以避免很多 code generation 出來問題,而且這樣也是一個很強的特色。

更多資訊可以參考 Beginning IPhone 3 Development: Exploring the IPhone SDK - Introducing Interface Builder。