Pages

Wednesday, November 21, 2012

Google Analytics SDK for iOS v2 (Beta)

最近在留意 Google Analytics SDK 版本更新時候,發現它的 2.0 Beta 已經 Release 了,當回到官方網站找相關技術文章,也有了新的文件說明。

Google Analytics SDK 要讓開發人員可以更容易的從他們的 App 上收集使用者互動參與的數據。透過 2.0 Beta 可以追蹤到:

  • 多少活躍的使用戶。
  • 在世界上哪些地方有在使用。
  • 追蹤觀察特定的 Features。
  • 付費與交易的追蹤。
  • App 的 Crash 現象。
  • 以及更多有用維度分析。

但是開始前要注意到準備事項:

  1. 要使用 iOS 4.0 以上 
  2. GA Mobile Apps iOS SDK v2
  3. 一個想要追蹤的 iOS App
  4. 一個全新的 Google Analytics 的 App property 及 Profile。而我也是沒注意到這段而發生了資料送到異次元的狀況,後來找了文件才發現。

值得注意比較過去 1.0 和現在 2.0 的差異:

全新的 App profiles reports 介面

這邊不再是使用過去 Web 收集的版面,而是專門 Mobile 的分析圖表介面,所以包含了一系列相關的數據收集分析表。當然也只有支援 GA SDK 2.0 以上。

Exception tracking

GA SDK 開始追蹤錯誤,使用這項可以收集 crashes 和些非導致毀壞的錯誤立外資訊。

而在開發者要注意是,過去使用 trackPageview: 變成 trackView:,關於電子商務交易現在獨立出來做統計。過去用 Custom variables 收集在 2.0 被取消掉,不再支援。所以如果有進階額外資訊要收集,就用別的更新的 method 來取代。

對於 Google Analytics 想要了解更多,可以參考我的其它相關 Tag GA 整理文章。

GA beta - App Overview

Flurry Analytics 為我們提供更好閱讀的使用數據

Flurry - Create A New App

Flurry 平台統計服務 提供了一套簡易上手、容易閱讀的統計分析工具,只要將我們的 App 裝設 Flurry SDK,即可收集使用者的整體使用數據,作為些分析與改善使用,而當好奇 Flurry 這套 Analytics 要不要收費以及他們家獲利收費方式,在 Quora 找得到這樣的討論 How does Flurry make money? 而 Flurry 的 CTO Sean Byrnes 為大家解答。主要是靠 AppCircle 和 AppSpot,而 Flurry Analytics 還是依舊免費。

Flurry Analytics 可以幫我們收集與分析很多有用的數據

1. Usage

有多少新的使用者、多少活躍使用者、說少使用的次數、使用的時間長度、使用密集度、追蹤使用者安裝後的還使用的情況、使用者回流數、使用該 App 版本紀錄、逛 App 頁數與次數統計。

2. Audience

了解年齡分佈、姓別、地理位置、語言

3. Events

Event 記錄總表、使用者使用事件的路徑圖、Funnels 漏斗分析、收集到 Event 的 Logs 記錄表。

4. Technical

使用者的裝置統計、電信業者、裝置作業系統版本號統計。

以上藉由 Client 端行動裝置 ,裝載著對應的 SDK 工具,即可將數據收集回來平台上,讓我們對於使用情形作後續改版參考依據。

Tuesday, November 20, 2012

Build Static Library in Xcode 4

Cocoa Touch Static Library

寫程式總是一直提醒自己要 DRY - Don't Repeat Yourself,上從 Class Name 到 Method Name 到寫程式的邏輯都要謹記在心。因為當重複撰寫一樣的邏輯,在維護上就會變成做重複事情,一來浪費自己的時間,二來如果自己疏忽會造成忘記要修改,三來也會造成一起開發夥伴的困擾。

伴隨著 Project 的開發,會發現有些程式是可以模組化,讓它獨立出來變成單一 Xcode Project,除了維持它核心功能外,還能產生 Static Library 讓需要用到它的 Project 可以引用。如此一來 Static LIbrary 也可以重複使用在更多更多的 Project 上。


在 Xcode 的 Project Template 可以輕鬆完成這樣的設定,
將整個 Project 包裝起來成為 *.a 檔案,如此搭配釋放出的 Header Files,Client 端只要看懂 Header Files 不用知道實做細節,也就可以使用。操作步驟:
  • 選擇 Cocoa Touch Static Library。
  • 在 Build Phases 加入 Copy Headers 步驟,將要 Release 的 Header Files 挑選出來,放置在 Public 區塊。 
  • 回到 Build Settings 找到 Packing > Public Headers Folder Path,這邊是告知在包裝時候會將 Headers Files 放置位置。 
  • 因為 Xcode project 建置好的位置路徑很深,如果每次路徑要走那麼遠取用檔案也很不方便,於是在 Build Phases 可以加入 Run Script,在裡面撰寫將檔案取出來放置在桌面上的 Scripts。


當以上設定完畢,程式碼撰寫完,跑 Build & Run 就可以將整個 Project 的程式包裝產生 Static Library 了。

Xcode Pro Tip Setting - Treat Warnings as Errors

Treat Warnings as Errors

寫 iOS App 為了不要產生討人厭又不好沒用的程式碼,像是當在撰寫 Code 時候,Xcode 就可以即時產生 warnings。當大家一起在寫程式時候,我們不希望在當 Xcode 跑編譯時候產生一堆 warnings 列在那邊一直在警告與嚇著似乎有潛在問題存在。

小撇步:在 Build Settings > Other Linker Flags 加入 -Weverything,在 Build Settings > Treat Warnings as Errors 設定為 Yes。

能得知這方法是我的夥伴跟我分享 nshipster.com 的 Inhibiting Warnings 學到的。現在有在寫的 Xcode Project 我都會啓動這樣的設定了。如此在每次 Xcode 編譯就會把警告顯示出來,直到修正好才能過關。

Wednesday, August 29, 2012

UIViewController purgeMemoryForReason and crashes in iOS App

測試 iPhone App 時候,最怕測出自己無法預料的問題。所謂無法預料的就是很難重製,但是它就這樣存在 App 上。而當我們用心就知道,一定有問題存在。當 App 用 Ad hoc 方式發佈出去,這些 App 都裝在夥伴們的 iPhone, iPad 上,當真正發生 Crash 了,真的會覺得很不安與莫名其妙不知道從何下手。

好的 Crash Report 平台 如 TestFlight, Crashlytics 等等。這些 Tool SDK 都還算好安裝,再利用它們在當 App Crash 後,
收集 Crash 的 Log 將它們送回平台上,再利用網頁的優勢來做統計,讓我們知道最後僅有線索記錄。

ISSUE UIKit-[UIViewController purgeMemoryForReason:]

終於收到問題的通知信件了,當收到這樣的標題再進去看內容,還真的讓人不解。因為現在手頭上開發的 App 已經採用 ARC (Automatic Reference Counting in Objective-C and Xcode) 的寫法了,所有的物件釋放時機都交給這個機制去運作,我都不用太擔心應該釋放時機點問題,怎麼會出現最後 Memory warning 才會出現狀況呢?

到網路上找尋大家經驗,在這則三則找到了問題主因:

主要問題所在,當 App 操作上難免會有記憶體上升,所以系統會發出低記憶體的警告 Notification。但是如果在 UIViewController 寫了 [[NSNotificationCenter defaultCenter] removeObserver:self] 如此一來會把 UIViewController 還要接收註冊的 Observer 也一帶 Release 掉,因此 UIViewController 就不會進入 didReceiveMemory,也跟著不會去釋放該要被釋放的物件,導致最後記憶體下不來,而最後整個 App 直接 Crash 收掉。


而會這樣寫法有兩個主因:
  1. 懶惰。
  2. 對於 NSNotificationCenter 了解深度不夠。

正確的寫法是像這樣 [[NSNotificationCenter defaultCenter] removeObserver:self name:NotificationName object:nil] 也就是自己註冊的 Observer 就一對一在 View 要被移除掉時候一起移除掉。這樣才不會將不屬於自己的 Observer 也被移除掉。

寫程式最怕的就是亂處理非屬於自己掌控自己建立的物件、指令,這樣整個邏輯都會亂掉。最佳寫法就是要低藕合,只處理屬於自己掌控的。對的寫法就不能偷懶。

Saturday, August 25, 2012

iOS App 自行評估上的五個重要指標

身為一個開發出 N 個 iOS App 的你,對於一個 App 的好壞是否有心中的定數呢?怎麼樣的 App 在問市以前就可以先讓自己及贊助者、團隊都滿意呢?希望推出的 App 是一問市就獲得五顆星的佳評,還是要到後面自己在從一兩顆星慢慢追趕自己理想的五顆星呢?

根據我們的經驗,會發現每個使用者在針對 App 作出 Review 的時候不外乎就圍繞在五個主題上去描述他使用的經驗。而這五個主題是我們每天在追求要更上一層樓的。


1. User Interface

有好的 App 界面設計需要兩種專長有經驗的人才在一起合作才可行。App Designer 針對現在開發中的 App 的畫面,透過自己的設計能力去規劃畫面上每個地方的細節。套用各種 Designer 在美化上的公式,例如標齊對正、字體大小掌握、圖片材質的設計。這邊需要非常細心、創意、巧思才能完成理想圖。另外一種專長則是懂得實作進來的 App Developer,他的角色需要將 Designer 的用心根據自己程式的經驗將它實作起來,並且活化它,讓原本很美的靜態 App 理想圖變成實際看到、摸到、感覺到的 App,這時候開始後面的修改於調整,很多設計不是一次就能定數的。

2. User Experience

同樣的功能,同樣的企劃相信交由不同的開發團隊設計出來的使用體驗絕對會不一樣。是否需要很多步驟才能完成操作、還是操作的過程很不順利,要使用者等待很久、或者在操作過程讓使用者覺得干擾過多,很難達到使用者心中想要操作的指令。好的 User Experience 要能在操作上即反應出使用者心中所想要、所期待下一秒會出現的結果。並且可以依序的操作下去。這方面除了用心得開發之外,也要搭配好的程式技術來做各方面進一步的調整。往往 User Experience 的改進是在 App 開發出樣貌後,開始要精進的。

3. Information Architecture

iOS App 的寸土寸金的畫面上,要擺上哪些資訊是個極大的任務,這個畫面的出現是否讓使用者看的覺得有用、資訊是否足夠、資訊是否過多過少、資訊的上到下是否都對使用者而言很有意義,是否會讓使用者迷路,不知道怎麼進行上一頁、下一頁的各種操作。Information Architecture 的用心在於一個 App 的畫面有幾個,這些畫面上的資訊呈現與彼此的關聯性。要追求的是讓使用者覺得這樣的資訊呈現剛剛好。

4. Quality

所謂的品質是達到我們所有想要提供給使用者的功能都能正常的操作,都能順利的完成。當 App 操作過程會 Crash、操作的過程等待過久、操作的過程因為某些特殊原因,且沒有處理好,而讓使用者的操作路線斷掉,上不去下不來的狀況。所以好的品質是要讓使用者不但能完成 App 提供的功能之外,還能操作的夠久到使用者自己自行離開關閉此 App。

5. Content, idea

回到最初的問題,我們為何要設計這個 App,希望讓使用者可以看到哪些功能、讀到哪些資訊、讓使用者可以解決他們生活上哪些問題。在最開頭的企劃上是否就走對了路。內容相當的重要,不希望當以上四點都做到了,但是最後使用者卻嘆了一口氣:“這個 App 好無聊噢!對我一點用處都沒有。” 所以 App 能跟使用者緊密關係是這個項目要努力與用心的地方。

最後

當我們 iOS App 開發團隊進行每天工作的時候,時常都在天人交戰的部分就是以上這些項目,這些項目都是關係著我們推出後的 App 會帶給使用者哪些體驗。而這些過程很多部分會互斥或者互補的。有互補的狀況當然是最好的,最讓人擔心就是互斥的部分。

當為了好的 Information Architecture 缺犧牲了 User Experience,那麼我們必須要停下來問自己,哪一個最重要,如果能解決 User Experience 而 Information Architecture 再用別種方式來解決是不是很好呢?

這五個項目都是我每天在問自己的問題,對於現在手頭上正在進行的 App ,他在各個項目拿到幾分了呢?我們應該要在 App 問市前,心中就已經有譜了。戰爭還沒開打前,勝負就已經揭曉,這才是身為資深專業的 iOS App PM, developer 及每一個成員該有的知識。

NSKeyedArchiver 讓 iOS App 方便儲存 Objects 的資料

在 iOS App 開發裡面,我們要儲存使用者的購物清單,而這些購物清單透過使用者在瀏覽的時候,將它們一一記錄下來,當隨後使用者要查看即可方便顯示出來。

我們會規劃 Objects 來封裝我們的各種值,這些 Object 在規劃上研究深入就要由 Domain Model 來分析了。但是還好我們的 iOS App 不會到這麼複雜,只要基本的切分清楚在使用上方便即可。而我們是否有方便的方式將這些物件儲存起來呢?

NSKeyedArchiver 可以幫我們做到,透過 archive 即可將整串從 Root Object 開始將裡面所有的 Object 儲存起來。而下次要使用的時候只要透過 unarchive 取出即可還原。


實作 NSCoding

我們有 PersonalShoppingList 這樣的 Object,而裡面有 Food 的 NSSet 和 FoodWithIngredient 的 NSDictionary,而要記得是在所有要存的 Object 都要實作 <NSCoding> 並且規劃寫 - (id)initWithCoder:(NSCoder *)aDecoder; 和 - (void)encodeWithCoder:(NSCoder *)aCoder。當然的,所有裡面會牽扯到的 Object 自己寫的都要這樣去實作。所以最後會看到自己要存的各種 Object 都會有寫好要存取的值。

儲存

回到 NSKeyedArchiver 去將 PersonalShopping 指定給 archivedDataWithRookObject。當取得 NSData 後,一起將要儲存的 Path 規劃好之後,即可將它 writeToFile 寫進檔案。

讀取

取出的時候是將 NSData 透過完整路經將檔案指定回來,再將 NSKeyedUnarchiver 的 unarchiveObjectWithData 還原回來,即可繼續使用了。

NSKeyedArchiver 對於 iOS App 有做好 Object 規劃方面,儲存和讀取方面變的很方便,只要實作了此功能,我們的任何資料即可隨時存取,相當的方便。

Sunday, August 12, 2012

挫敗的上一步

圖為 Edward In Action 所有
很多現象永遠跟你想的不一樣。不論是已經收集了滿滿線索、信心滿滿、問了所有有經驗的夥伴自己的做法,只為了證明自己沒有錯。但是問題就是這樣的攤在面前,告訴著當事人你,是的,他就是錯了,不論怎麼試還是錯了。

這個現象常常發生在我們 iOS App 開發上,每當信心滿滿的按下 Xcode 的 Build & Run,就是會去預期這一次在模擬器上開起來後的測試效果要如自己預期般的呈現,結果,很抱歉,就是沒有。請問該怎麼辦?

我最常解決這樣問題的方法是借鏡於實驗。實驗裡面有實驗組與對照組,實驗組是投入要觀察的項目,而對照組是用來對照出來的實驗結果。所以為什麼問題會發生,程式功能跑不出來。是否有成功的案例,他是怎麼做的。我們要將這兩者的所有影響要素一一條列出來,將一樣的部分在腦海中一一刪去,剩下不一樣的項目。例如根據不同的經驗是:
  1. 程式的撰寫方式有改變。
  2. 引用的元件套件版本的差異。
  3. 設定上的不同。
  4. 在某種多重參數、要素組合的條件下造成的錯誤。

在卡住過程我們是最容易急的,因為當時間一直一直過去,可是問題卻一直攤在面前。所以面對這種挫折感的時候,最需要的就是冷靜,唯有冷靜才能平心靜氣的來慢慢穩健的分析。回到上一次成功的情境,去想想看為什麼那樣下會成功,但是現在卻不一行。

很多時候,當問題卡住了,透過回到上一次成功的經驗,能帶給自己更多的信心,也才能在這過程中找出差異性。所以有時候我們想要急著前進三步遇到挫折時候,何不先退後一步,深呼吸一下呢!

Called the Shot 談每日工作生產力

圖片為 Edward in Action 所有
每當談到軟體預估,我就想到《人月神話》第八章〈預估〉[Calling the Shot] 的貝比魯斯。在 1932 年美國職棒世界大賽,全壘打王貝比魯斯在打擊前伸手指向中外野,接著隨即打出了一支全壘打。打擊前他做了預估,憑藉著自己的實力與精準度打擊出去,這就是著名的貝比魯斯的全壘打預告 (Babe Ruth's Called Shot)

每當上司、主管、業務任何非技術背景同仁會來跟我商討功能的複雜度,以及大約需要多久,這個時間就要根據自己的經驗與了解度來做分析了,這沒有標準的答案,因為中間牽扯到執行寫程式的人技術、用心程度、負責程度,再到軟體測試是否能符合功能的需求來作開發,更不用再提任何變動的因素,而被迫要做調整。這些事情只要是軟體開發,就一定會碰到。前輩以及書上經驗跟我們說,只有不斷的練習,了解自己、了解團隊才能越來越掌控所需要的時間。

Called the Shot 的精神我會將它融入到每天的工作。早上進入公司,開發團隊會做個簡單的溝通同步了解彼此在哪一個戰線上,而對於自己,就會訂下一個本日可以完成的大項目,或者本日可以完成的兩個以上小項目。以現在 iOS App 開發為例:
  • 某主題的 UITableViewController 開發,因為它是負責資訊列表的提供,所以會在本日將它所需要的資料串接,放入 UITableViewDataSource,最後再讓資料呈現在畫面上。而有兩個基本原則會一起伴隨開發的,重新整理與載入更多。一個是使用者會需要將現在畫面上的資料更新到最新,另外一個是使用者會一直瀏覽瀏覽需要更多後面的資料,而將這些資料載入畫面中。
  • 使用者登入 UIViewController 設計,它是負責讓使用者可以來登入,所以這部分要將它規劃出輸入欄位,例如 Email, password,而當使用者輸入過程可以做些輸入上驗證,送出到伺服器上作密碼驗證,再回來跟使用者表達是否登入成功與否。最後再將畫面收掉,並且讓整體的使用體驗是給使用者有登入後的感覺。
  • 整個 App 會共用的照片拍照上傳程式,這邊設計上會以方便給予照片物件集合,讓使用者在拍完照片或者挑選完照片,即可透過這隻程式來上傳,過程中表現出目前進度。最後處理上傳成功與失敗的狀況。

這些是作為每天開始工作前,去思索一遍,動筆前先動腦,敲鍵盤前先想過,在自己展開工作一天,要來完成每日小目標。

1. 有明確目標

透過這樣的思索,讓自己在一開始即可想完整體面貌,而當面貌越完整,即可知道自己手邊資料材料是否足夠,在接下來一天設定這樣目標達成的可行性提升。

2. 排除萬難

因為設定了這樣目標,所以在接下來的工作時段,就是要全心全意的來實作,任何的阻礙都會視為仇敵的方式來看待。任何的干擾包含:無關緊要的電話、無管緊要的 Email 、無關緊要的人過來你身旁找你講不相干的事情、任何突然會讓你被迫離開座位阻斷你前進的因素,這些能免就要免。

最後每天傍晚跟團隊夥伴做一天回顧,如果有順利的執行以上項目,在自己一天內能完成的目標,並且順利地達成,最後還可以展示給夥伴們看,因為預估而實踐做了哪些功能、哪些昨天沒有今天才出來,今天因為我的用心而完成的小任務。

當完成了當初自己的預估,除了可以讓夥伴們眼睛一亮之外,自己在每個重要的一天,又完成了一個小成就。

Sunday, July 22, 2012

從被挑選過程談個人競爭力


新款 MarBook Air 讓我更有效率
數一數工作經驗也開始滿五年了。近日參加了些新鮮人年輕朋友們的咖啡廳聚會,聽聽小自己幾歲的年輕朋友們談他們的夢想、熱情與對未來的期待。有位年輕的小朋友跟我聊一聊天,覺得我對於自己的未來很有想法,也把我當老大哥在稱讚,讓我想起了一個自己小時候的故事。

小時候因為家父要到美國華盛頓大學讀企管研究所,讓我們家有機會搬到西雅圖生活兩年,也因此讓我有機會可以在西雅圖市立國小讀小學三、四年級。還記得那天上學的午飯過後,我從學校餐廳走到操場,步向橄欖球草皮場地,看到同齡的白人、黑人們大家分隊彼此追逐打著有計分趣味橄欖球賽,當下我就非常想要加入一起玩。當那場結束後,進入到新的一場時,兩隊就要重新分隊。

兩位資深體格好的男生站出來擔任兩隊的隊長,所有球員一字排開站在球場旁,分別由隊長以公平、一個一個彼此球隊輪流挑選的方式來進行。當時站在隊伍裡面的我,短短幾分鐘,對於這一切的遊戲規則和挑選過程產生相當大的震撼與難忘。內心想到兩個問題:

1. 你是什麼理由讓這位隊長挑選你?

2. 你是在第幾輪被挑選中?你的競爭力在哪?


我印象我是被第四輪挑中,我也不太清楚他選我的原因了,大概是看我身材不會太瘦太矮,看起來會跑步接球的樣子吧!我想。

這個被按照公平客觀的一輪一輪挑選隊友的方式,造就往後我對於自我要求、自我一人練習的最大動力。

不管做什麼事情,當你的戰場決定了,剩下就是認真以赴,贏得這場勝利。

在職場上我相當期許自己有特戰部隊特徵,有專長競爭力、有被長官及隊友挑選我加入的理由與吸引力、附有正義、客觀、服從、忍耐、克苦耐勞等要點。不管專案是好的案子、慘的案子都能殺進殺出,獲得好佳績、完成該階段被賦予的任務。

所以每當累了、疲倦了,想要找回更上一層樓的動力時,何不問問自己,這是你要投入的戰場嗎?如果這是你要投入的戰場,你希望是第幾輪被長官、被客戶挑選中呢?你的競爭力是什麼?為什麼別人要給你機會。

Friday, July 20, 2012

Mike Markkula 教導 Steve Jobs 的蘋果行銷哲學


馬庫拉 (Mike Markkula) 曾經教導賈伯斯 (Steve Jobs) 關於行銷,也在一張紙上寫下「蘋果的行銷哲學」,其中特別強調三點:

1. 同理心 Empathy

要能靈敏的察覺消費者的感受。要有能比其他公司,更了解消費者的需求。

2. 專注 Focus

為了一心一意做好決定做的事,必須要有焦點,以壯士斷腕的精神,捨棄其他不那麼重要的東西。

3. 聯想 Impute

一家公司或是產品傳達給消費者的感覺,會讓消費者聯想到該公司或產品。就像書的封面設計好壞與否,會影響買書人對書的評價。不但要有最好的產品、最好的品質,也要有最有用的軟體等。且如果包裝有創意且專業,消費者必然對我們的品質有信心。

賈伯斯從創立蘋果開始,一路走來對行銷、形象非常在意,甚至連產品包裝的細節也不放過。賈伯斯曾說:「從打開 iPhone iPad 包裝箱那一刻的觸感,就可以預知使用這個產品的感覺。這就是馬庫拉教我的」。

以上是來自於閱讀賈伯斯傳第六章關於貴人馬庫斯的心得整理。

Design by Committee 委員會設計


從設計法則這本書來談,裡面的第 74 頁談到 Design by Committee,是指一種設計的過程,為了達到共識、必須由團體決定且需要重複探討為基礎。一般人會普遍認為,專制領導者在推動的計畫或是專案會做出好設計,民主團體推動的計畫會做出壞設計。很多人覺得這樣老大領導者的觀念很浪漫,相當吸引人,偉大的設計就是需要卓越的設計領導者來掌舵,才會成功。然而這樣的觀念充其量只是一種過度簡化的方式。

怎麼樣適合獨裁設計領導者為主呢?在時間有限情況下、需求相對直接、可以容忍錯誤,以及相關計畫關係人不重視不發表意見的案子。除了發明家、名流設計師和企業創業家以外,所有現代設計規模稍大的都是委員會設計。所以在認為偉大設計都是來自獨裁設計師,往往是迷思而非事實。

委員會設計適合品質導向、需求複雜、不能容忍錯誤,以及相關人事意見重要的案子。

最理想的委員會組成是多元樣,有偏見和影響力的成員越少越好,以有效率的方式收集各個成員的貢獻與投入,簡化指揮模式以加快決策,才能確保過程不會過久甚至陷入僵局。

一般而言,在減少整體失敗風險這點上,委員會設計會勝過獨裁設計。畢竟壞獨裁者不會比好的獨裁者少,而獨裁往往缺乏委員會的錯誤更正能力與組織安全的考量面向。民主的確會重復進行且變慢,但是會比較謹慎,也比較不會犯錯。兩種模式都有其優缺點,所以要視情況而定。

自由塔 (Freedom Tower) 引人注目的原始設計,是由 Daniel Liberskind 透過典型獨裁式設計創造出來。然而因為世貿雙子星大樓的建築需求極端複雜,無法容忍設計上的差錯,而且相關厲害人士數量較多且充滿熱情。最後自由塔要採用委員會設計。當這項設計經過各式各樣的商業、工程、安全、和政黨派重複討論後,個人表現手法和氣質會被中和稀釋掉,最後設計上視覺也許不吸引人,但是就定義而言,卻是比較實用的設計。

Monday, June 25, 2012

iOS Music App Pause After A Headset Was Unplugged

當使用者在他們的 iPhone 上面聆聽著歌曲,聽著聽著,在還沒有暫停的情況下拔掉了耳機,這時候請問 iPhone 上的 Music App 是該繼續播放還是暫停?

好的互動設計應該是要暫停的。因為使用者因為要中斷聆聽而做出了拔開的行為,不論是拔掉耳機、拔掉音響的音源線都是要中斷現在操作行為,那麼音樂應該是要暫停的。

但是回到我們的程式設計,不做任何處理的話,程式是會一直讓音樂播放下去的。所以我們應該要在程式上做這樣的處理。那我們該分這些步驟規劃:

1. 註冊 Listener

在適當的位置登記一個 Audio Session 的 Listener,用意來監聽是否有任何 audio route 的改變。參考 Gist Code

2. 在對應 callback function 做邏輯處理

在對應的 function 裡面根據進來的改變原因來判定當下發生了哪種情境,而當耳機拔開算是 kAudioSessionRouteChangeReason_OldDeviceUnavailable,在文件上定義當裝置 UnPlugged 都算是這個原因,那麼我們就可以在那情境下將原本在聽歌的部分將它暫停掉。參考 Gist Code

那麼有哪些改變原因我們可以查詢呢?參考 iOS Developer Library 文件可以看到有這些情境可以讓我們來分析。
Audio Route Change Reasons

最後,我們就能因為加上這些貼心的程式碼,讓使用者可以在聆聽歌曲,搭配不同的情境下,而有更好的對應互動體驗。

Saturday, June 23, 2012

How To Test Blocks When Making Unit Tests For Objective-C

Gist Code: https://gist.github.com/2976465
當我們有個 Method 是使用了 Blocks 的方式來網路呼叫,這段過程不知道多久才會完成,有可能很快,有可能要等很久。這樣的過程在 Unit Test 方面是一直往下跑,所以結果沒出來我們也無法加入 Assertion 來確定結果是不是我們預期的。

- (void)loadMore:(BOOL)more didFinishLoad:(requestDidFinishLoadBolck)requestDidFinishLoad
   loadWithError:(requestLoadWithErrorBlock)requestLoadWithError

我們可以開一個 NSRunLoop 來輔助,先宣告一個 BOOL done 來控制影響後面我們的 Run Loop 的執行狀況。但是在 while 迴圈裡面也是有個上限,透過 usleep() 來控制要等待多少 microseconds 。當整個等待架構好之後,回到主要要測試的程式,在最後結果的 finish load 和 load with error 裡面都補上 loading done 的轉換成 YES,如此一來提早執行完我們也可以將等待的 Run Loop 結束掉。

以上透過這樣方式即可完成我們在程式是需要網路呼叫的測試了。程式使用 Blocks 方式撰寫也不成問題。相關文章:使用 SenTestCase 為後續整合更快速使用 SenTestCase 為 Continuous Integration 之路更踏實

Saturday, June 16, 2012

WWDC 2012 - My Most Memorable Tweets Collection


My (@EdInUbuntu) most memorable Tweets during WWDC 2012 week, from the very beginning til the last day.
  • Tourist Bus Driver: Mr. Hu left hes coat in the hotel. We wait for him a minute here.
  • Last day being at #WWDC, and got only few sessions left. I will miss here so much. http://t.co/AkmbTL0c
  • dispatch_get_main_queue()
  • During #WWDC session break, my favorite DJ plays song is “Gotye - Somebody That I Used To Know.” Just bought it from the iTunes Store.
  • @dannygreg Nice to meet you, thanks for sharing some best practices with me! Have a good time rest of the week.
  • Just arrived Appsterdam WWDC HQ! At @StackMob HQ
  • @featherless @heroku Feel so honor, glad, thankful, happy that I can attended too. Rocks!
  • I left my bugs in San Francisco.
  • @mattt @cocoapodsorg: What a great meet-up, lots of popular rock in the house! Me and @zetachang enjoy it so much. Thanks so much!
  • The T-Shirt what people wear represented the past, right now, and the future. #WWDC
  • There are heartwarming stories out there of what the combination of our incredible devices and your amazing apps have made in peoples lives.
  • @pixelcon Thanks for the party, and the T-Shirt is amazing, we love Crashlytics so much! See you this week. http://t.co/4AMX95aX
  • Fuel your body, feed your Mac. #WWDC http://t.co/0pewtdVq
  • ShawnKing: Cant's sleep. Watching WWDC Keynote. Does any other tech company make "Thank You" videos that make grown men tear up? Remarkable.
  • Just get in the waiting line for #WWDC, it’s 5:12 AM.
  • To @dlackty, @testflightapp team said they remember you were here #WWDC last year, and wanna say hi to you. http://t.co/NRVdpfq8
  • Next to the Moscone South, waiting for the afternoon #Pilgrimage to #Cupertino. #WWDC
  • Who is Edward Chiang, @polydice? But you are Chiang Chung-Chuan! … After all, went to member service line to explained for the badge name.
  • Yes, we are here With @zetachang, @polydice, waiting in line for #WWDC badge. http://t.co/iM8yzVJD
  • To the airport, with @zetachang #WWDC

Tuesday, June 12, 2012

WWDC 2012 Keynote with heartwarming stories

WWDC 2012 Keynote

今年 Apple 舉辦的 WWDC (World Wide Developer Conference),在當地時間 6/11 早上 10 點盛大展開,而第一場重頭戲大家擠迫頭排隊的就是 Keynote 了。而同時每次第一場的 Keynote 都會全球轉播。

整場 Keynote 的氣氛讓我們非常的感動與感恩。Tim Cook (CEO of Apple) 不斷的提到有今天這樣亮眼成績要感謝 Apple 的產品搭配全球優秀的開發者,開發的 App 改變了人們的生活方式。

“ There are such heartwarming stories out there of what the combination of our incredible devices and your amazing apps have made in peoples lives. ” - Tim Cook

最感人的就是 7:37 ~ 15:28 這段的影片播放。用了幾個感人的 App 為例,如何改變與協助人們來完成日常生活事情,這層關係是如此的緊密。

回到反觀自己


當我從多年 Java 開發背景,轉入到 iOS 開發,給我最大動力是期許自己可以透過 iOS 平台、工具、開放式原始碼、技術討論社群的力量,做出符合市場上使用者期待的產品,希望所有使用者可以因為下載,使用了喜歡再給這個產品更好的評價,讓使用者來跟他們的朋友們做介紹。

但是如果我們一直老是自私的想著小我,我要怎麼樣,這樣還是太侷限在自己了。這場 Keynote 一再提到 “What we can do more to make…., what can we do better for…” 我們跟應該把思想在自己為中心,而擴大到我們的使用者,我們有什麼優勢?身為 iOS Developer 的我們擁有了驚艷的技術,但是更重要的是,我們如何用心觀察人們需要怎麼樣的 App 來協助、來改變他們的生活。可以更有教育性、更方便、更簡便、更容易、更有娛樂性。這一些都是人機互動、互動設計再告訴我們的。

好的 App 有三大重要必備要素,缺一不可,Interaction, User Interface, Implement.。

Interaction

人們如何和設計出來的 App 互動,如何的使用可以啟動、操作、閒置到最後關閉,這段期間所有操作的狀況。

Interface

介面是人們與 App 接觸的窗口。畫面上的設計如何的簡潔、有效率的輔助使用者來讓整個過程,每一個閱讀、點擊和操作都是很容易的。

Implement

當有了概念、技術,身為 iOS Developer 我們該如何將它實作到好、高品質的,使得使用者可以在短期、中期、長期來使用都能達到與符合他們的預期。

最後

非常感謝我周遭的親朋好友,讓我這次有機會能順利規劃旅程、成功抵達舊金山參加 WWDC 一個星期,讓平常分散在全球各地的開發者,因為這樣的聚會全部聚在一起,一起分享、一起討論、一起研究,過去的技術與現在新設計出來的技術。When we learn together, we stay together.

Me & TestFlight Team with Founder Ben Satterfield.

Thursday, June 7, 2012

SVProgressHUD - A Progress HUD for iOS App

圖片參考自 http://samvermette.com/199
當我們在開發 iOS App,要從 iPhone 透過網路跟 Server 端溝通,過程一定是需要等待,而這過程會有來回時間,這依照網路的好壞來決定要多久。在這過程我們會需要適當的在 App 介面上顯示目前走到哪了,告知使用者目前還在進行當中,稍後就會告知結果。


對應上我們就需要  Progress HUD ( heads-up display ) 來顯示。使用上特點有:
  • 可以加入在當前的 View 上面。
  • 簡單的顯示,容易的移除掉。
  • 在過程當中,成功或失敗結果,根據階段顯示對應的圖片和文字。


推薦 GitHub 上面的這套 Project:samvermette / SVProgressHUD。使用上透過 SVProgressHUD 對應靜態的 method 即可做出這些需求組合:
  • Show
  • Show、伴隨狀態文字
  • Show、伴隨狀態文字、是否顯示 Activity Indicator。
  • Show、伴隨狀態文字、加上顯示 Mask Type。
  • Show 成功、伴隨狀態文字、過程停留秒數
  • Show 失敗、伴隨狀態文字、過程停留秒數
  • Set Status 過程可以轉換狀態文字
  • Dismiss
  • Dismiss 成功、伴隨狀態文字、過程停留秒數
  • Dismiss 失敗、伴隨狀態文字、過程停留秒數


這套類型上 HUD Mask Type 支援四種:None (過程還是可以讓使用者持續操作其他事情)、Clear (不允許使用者互動)、Black (不允許且用黑色的效果)、Gradient (不允許且加上 Gradient 的背景效果)。

而當然在使用這些狀況,我們要讓呼叫的程式寫在 UIViewController 會比較好,除了正常顯示之外,讓 View 的邏輯集中在這個地方。所以使用通常會伴隨三個階段:

1. 使用者操作,啟動 HUD

這邊伴隨著各種操作動作,例如 Query, Delete, Add to Favorite, Remove from Favorite 等等各種功能操作。

2. 使用者等待,持續顯示 HUD

如果是一般的網路溝通,就用一般 Activity Indicator 加上傳送中的文字。如果是上傳比較大的檔案,可以透過數學計算進度百分比,讓它持續更新狀態文字,讓使用者可以預期還要等待多久,完成了多久。

3. App 回饋結果,顯示文字後關閉 HUD

不論是成功或是失敗,透過適當的文字結果告知使用者,這次的操作行為結束了,而結果是這樣子。如此一來也把操作權交回給使用者,使用者可以繼續別的 App 功能操作下去。

使用 Progress HUD 很方便,效果也很清楚。但是它也帶來操作上另外一種缺陷。在使用上要特別注意的。因為在這過程畫面會被罩上這樣進度顯示,所以使用者的操作體驗是被中斷的。另外如果撰寫不小心,這個畫面停留太久讓使用者無法關閉,這樣是嚴重的 Bug 出現了。

所以以上在採用這樣的配套措施引用在 App 使用過程裡頭,有它的方便性、回饋準確效果,當然也是會帶來另外一種被中斷的等待體驗。

Wednesday, June 6, 2012

向上管理的 10 個著手方向

在任何組織裡面,只要人數稍微多一點,擔任產品經理也是會有他的上司。而在這樣的結構裡面要如何向上管理,扮演好自己的角色,讓自己可以是表現出符合上司期待之外,更能減少許多衝突與面對不同的見解處理。 


在新創公司也是會需要面臨這樣的挑戰,既然我們無法避免,那麼是否有些方法可以讓我們來將資源極大化的充分使用。 


Marty CaganInspired: How To Create Products Customers Love [Kindle Edition] 這本書的 Chapter 10 Managing Up 給了十個好的執行建議,而當我在閱讀與思考這十項建議之於,也對照了自己工作的經驗來做個記錄。 


1. 評估與計畫變動成本

每次當我們在計畫事情時候,一定會先預估,但是事情總是這麼美好,總是一次就做對嗎?而這之間最重要的因素就是在變動成本。在軟體開發裡面變動成本例子可能來自於將程式碼改寫、因應不同的需求,而程式碼也要跟著改變。或者可能來自於團隊因為新的成員加入,帶來新的想法,而造成產品必須要調整。這些都是超出我們當初預期的。所以我們必須除了計畫之外,也要把這些變動成本的事項也規劃出來。所以當在評估要花多久之於,要將一般評估與變動成本一起考量。依照這樣想法,再回顧自己過去參與的專案開發、產品開發,確實發現,往往原本十拿九穩的計畫最後還是拖延了,那麼拖延的因素多半來自於變動成本的項目。


2. 溝通的方式與頻繁度

團隊之間一定需要溝通,讓彼此站在同一條戰線上前進。但是如果溝通太頻繁導致真正的執行者例如開發人員沒有足夠的開發時間來執行,也是件困擾的事情。而如果不讓彼此知道在做什麼,這樣時間拉長也會容易導致些多於、重疊、非預期的事件發生。所以溝通上我們有專案進度控管的軟體輔助 (每個單一事件轉換才遞送報告)、群組軟體的溝通 (當下發生狀況需要在短時間被協調)、再到真的面對面討論當場解決的溝通方式 (即時修正,馬上釐清)。溝通的遊戲規則要被製定出來,這是團隊之間溝通的默契所在。目標可以有效的溝通、又能減少不必要的驚嚇打擾到第一線執行人員。


3. 會前會的準備

開會不能少,開會通常都在決定重要決策,有時候需要被拿出來討論,讓有效的時間內的可以解決開會前所擔憂的疑慮。但是由於與會者牽扯變多的話,同時又希望重要人士可以表現出主席的預期,那麼會前會的討論與追蹤是在所難免。我們最擔心是當開會的時候,牌一攤結果都出乎自己的預期。所以希望可以將這些非預期的因素,在會前會的協商就可以大略的敲定。


4. 給建設性的建議而不是提問題

身為一個產品經理,要能依照自己的專業度來提出建設性的方案,縱使不是自己能力範圍內,也是要能找出關鍵的夥伴,將解決方案一同擬訂。老是題報問題卻沒有任何建設性的作法,只是讓大夥們更加沮喪。


5. 爭取上司的協助

很多跨部門協調事情,如果牽扯到非屬於自己的團隊成員時候,自己有沒有什麼權利去控制別團隊的人事與資源,那麼跟自己的上司做個明確清楚的報告,讓上司可以了解來龍去脈,而適當的幫忙爭取到進一步跨部門合作的資源。如此一來才能讓合作計劃順利執行下去。


6. 做功課

身為產品經理要勤奮的做功課,讓自己能夠狀況內。用聰明的方式來定義問題,再透過用心與投入時間來找尋解決方案。


7. 簡短 Email

最大的毛病就是將 Email 寫的太冗長。我們要站在上司的角度去想,上司每天收到的信件實在太多,如何用有效簡短重點式的 Email,越上層的長官寫的信件就要越精簡。


8. 多用數據事實而不是個人觀點

當跟上司溝通,最重要要知道事是我們要提供的是我們的數據與資訊和分析。所以我們就要多做功課,如此一來才能找到這些


9. 傳遞與介紹自己產品概念

當合作上要跨部門時候,身為產品經理平日就要多多介紹自己團隊與自己產品的精神與文化。因為如何能有效的傳遞這樣的理念,那麼跨部門合作的夥伴在加入時,就會開始有興奮的期待,非常願意幫忙與協助。


10. 低維護成本的夥伴

產品經理在找尋的是屬於低維護成本的團隊夥伴。高維護成本的夥伴會需要太多得協助、太多的打擾與太多的溝通,犧牲掉太多寶貴的時間。所以高生產力、有效的處理事情的團隊夥伴是最重要的。如果真的需要訓練,那麼尋求外界的協助,產品經理與上司需要將時間花費在更多更棘手的問題上面。


透過以上這些方向來著手,不會說一定就此沒問題,但是整體運作而言,進步是一定會逐漸看到的。

Tuesday, June 5, 2012

即刻救援!一段搶救幼小動物生命的故事


受傷的鳥兒

受傷的鳥兒著陸在危險的忠孝東路四段巷弄裡,它無法飛翔,也很難步行。


我在前往購買咖啡的路上撞著,以為它只是逗留,所以想盡辦法把它趕到路旁,希望它不要被往來的車子給壓到。看著它一步一步的向旁邊移動,我也安心離去。


當我返回再次路過時,看到它停在停車場門口,很虛弱的不再動了。我當下真的不知道怎麼辦!拿起了 iPhone 找了附近的獸醫卻找不出個所以然,越想越急,越想越無奈,回到辦公室依然不放心,開啟電腦上網快速 Google 找附近的動物醫院,順便查了如何處理受傷的鳥兒。


網站上教學可以用適當大小的紙箱,約鳥的 2 倍大空間即可作為臨時的窩,因為紙箱可以將其與人類隔離,安靜的空間可以減少其受到驚嚇,免除因為衝撞再次受傷。可以在紙箱中放置固定的木頭或樹枝作為棲木,以供棲息,紙箱底部墊舊報紙或毛巾以便清理。千萬注意不要使用鳥籠,以免鳥因驚嚇衝撞而受傷。


於是我拿著紙箱,抓著我們另外位女勇士 ChiaChia 一起出門搶救。


ChiaChia:“Edward,只有你這麼熱心...,別人可能就不管了吧!”


當我指著前進的方向,也看著這位小女生內心的感動,以及正在做不可思議的事情。當我們回到附近,看到好心的警衛剛把它拿了起來,我們上前跟警衛說明我們來歷,我們不是要養,但是我們會把它送去治療。請將受傷鳥兒後續救到動物醫院任務交給我們吧!


我們放進了紙盒子,我沒有騎車所以將接下來任務交給我們公司的勇士兼女騎士 ChiaChia,讓她騎著機車帶著裝著受傷鳥兒紙箱,前往附近動物醫院了,完成後面的使命。


後來聽 ChiaChia 描述,跑遍了四家動物診所都沒有收留,但是有間接推薦適合的醫院,最後將它送往了全陽犬貓動物醫院,地點在台北市八德路四段上。醫生會將這位受傷的鳥兒轉診,往後復健之路會送到相關基金會,過程有一層一層的關卡,依照鳥兒復健狀況分級放,最後一關會有個小窗戶,它飛的出去就自由了,如果飛出去不適應還有另外一邊窗口讓它們回來休息。


有些事情比工作更重要,而當我在回想這過程覺得相當窩心,除了量力而為救了小動物生命,而這過程除了要我們自己本性是善良之外,也要有同理心、洞察力。當發覺任何事情不對勁,深入觀察與洞見,最後再做出最好的執行力。這不只是我們平日使用者研究訓練與培養,更是身為一個好的領導者在對的時間選擇做對的決定模範。


非常感謝 ChiaChia、熱心警衛、盡責任的獸醫以及相關的基金會、以及感謝鳥類急救教學網站,因為簡單的說明,讓我們可以緊急時刻也能冷靜從對的地方著手。這個社會因為有你我,而變得不一樣。

Product Opportunity Assessment - 10 個關於產品的基本問題

Kindle Edition
每個新產品的新機會不斷的出現在我們身活週遭,在每一個市場,甚至是成熟的市場。因為一直在改變。新的技術不斷出現,競爭對手出現又消失,和新的傑出夥伴加入公司團隊。產品經理必須要能快速的去探索和決定哪些是機會可以做,哪些不行。哪些可以投入、哪些適合留給別人,和哪些點子想法還沒準備好來變成產品。

Product Opportunity Assessment 是一份很重要的自問自答檢核表,透過這樣的問題清單來釐清產品定位,除了把握住好想法,專注讓它可以製作與設計出來變成好的產品,也要用來避免團隊浪費浪費成本在不必要的方向上。

這 10 個問題分別是:
  1. 怎麼樣的問題想要被解決? (價值主張,價值所在)
  2. 為了幫誰解決這樣的問題? (目標市場)
  3. 這個機會有多大? (市場的大小)
  4. 要如何定義與評估成功? (數據 / 利潤)
  5. 外面有哪些替代方案? (了解競爭對手的領土)
  6. 為什麼我們適合來做? (我們的不一樣在哪裡)
  7. 為什麼是現在? (市場的窗口出現了嗎)
  8. 我們要如何讓產品進入市場? (進入市場的策略)
  9. 有哪些表徵可以讓我們順利完成? (解決方案的準備)
  10. 根據以上,我們的擬訂計畫是? (進行嗎?還是不要進行?)

這些問題除了在回答之於,最重要最重要還是第一個 “怎麼樣的問題想要被解決”。我們不能因為有了好的解決方案就一直著重往那方面去思考,而需要更清楚的構想哪些問題想要被解決。

在怎麼樣的問題想要被解決,必須是要很清楚、明確和引人矚目的描述出問題想要被解決,而不是一系列的功能列表和技術能力。

評估市場的大小需要尋找該領域的分析專家協助、財務專家、或者自己從去計算。

"A product organization is all about pursuing good opportunities and providing great product solution."

機會總是存在著,產品經理需要有效的評估出新的機會和自己團隊的潛能。選擇對的產品組合來投入才是公司想要的。根據這樣的 Product Opportunity Assessment 除了可以明確找出產品價值外,甚至可以取得上司老闆的支持。不論怎麼樣,在這個計畫下至少還有更進一步明確的了解。

以上是我在閱讀 Inspired: How To Create Products Customers Love [Kindle Edition] 第 11 章的重點整理,也可以參考部落格 Assessing Product Opportunities

Tuesday, May 29, 2012

適合 iOS App Developer 的 Focus List 和 Ignore List


iOS App Developer 日常工作不外乎就是做 iOS App 的 Research & Development,研究哪些新的技術、新的方法來解決自己現在工作上面臨的挑戰,不論是介面上的設計或者讓使用者體驗的好功能,都需要非常用心的開發才能完成。

而除了自己工作以外,也會需要適當的跟同事溝通討論彼此開發的方向,與一些設計上的取捨商量。再來也會面臨跨部門跨公司合作的訊息溝通,甚至產品開發完畢,在 Deliver 出去的種種流程上,有沒有注意到每一個環節。

因此身為一個優秀的 iOS App Developer 必須擁有的 Focus List 和 Ignore List 有哪些呢?

Focus List
  1. Github.com / Organize - 隨時了解組織內夥伴們最新狀態。
  2. Campfire - 隨時了解與發佈關於自己的最新狀態與進展,溝通透過此。
  3. Wiki - 記錄工作文獻檔案
  4. Issues - 確認 Milestone 和 Issue
  5. Version Control - 程式控管,將記錄異動獲得良好管理
  6. Email - 工作上還是會需要收信、寫信和回信,確保不會錯失客戶的溝通郵件
  7. Cocoa Control - 涉獵、探索、找尋與學習各種 Cocoa 元件的 Open Source 網站
  8. iTunes Connect - 最新送審結果
  9. Ad hoc 測試進展 - 了解自己跟市場最新接軌的進展
  10. Data Analytics - 了解使用者使用情形
  11. Calendar - 管理好自己未來的時間,何時有空、何時沒空、何時可以預約會議和各種活動進來。

Ignore List
  1. Facebook feeds - 上班時段真的不應該使用,除非工作一段時間,在屬於自己休息時段。
  2. Away from the desk - 任何會讓你分心導致必須離開座位的事情都要避免
  3. Blog / Website - 我們要懂得區分影響圈和關注圈。如果跟影響圈有關就沒有關係,如果只是讓自己看看充實知識的就避免,而這些要留給自己非工作時段再來閱讀。
  4. Instant message - 工作事情才需要彼此救援,如果私人事情在重要工作時段不應該被打擾,也不應該在這時候去發送與回應。
  5. Phone call - 沒有什麼事情是非接不可,除非是此時此刻不解決不行的重大問題,不然任何一個電話都是干擾。
  6. People - 任何會嚇到寫程式的打擾人。

當有效的專心投入工作,會發現如此才能完成很多重要的任務。甚至會發現我們的每天工作時數不是用超時來定義 (量),而是自己最有效的開發來定義 (質)。我們真的不能欺騙自己、也蒙騙同事,真正的時間點做該做的事情,何不讓我們可以準時下班,去參加更多更有意義的休閒活動呢!

如果你可以參加一場一日的 Hackathon ,你知道要在日落以前完成可以 Demo 的程式,必須要跟一組開發 Team 合作,時間非常非常的寶貴,那麼你就會發現以上這兩種清單就是在無形中自己、夥伴間給建立出來了。

2012/05/29 更新:經過一天下來,獲得成效不錯。

Focus List & Ignore List

Focus & Ignore
世界跑的非常快速,科技也是一樣,資訊也是一樣。有太多要理解,有太多要想,要去反應。每天我們使用電腦、智慧型手機在隨時掌握我們的 Twitter、Facebook 和 linkin-in。我們會造訪非常非常多網站要確保我們有取得最新消息。我們甚至用 Push Notification 來逼迫自己訂閱和追蹤。

但是這樣是有害的。這麼多的資訊快速湧進來,容易讓我們變得不容易專心,甚至分心而沒有做我們該做的事情。所以我們要開始練習開始說不。我不會在這時候閱讀這篇文章,我不會這時候閱讀這封信件,我不會在這時候打這通電話,我不會這時候完成這件事情。

但是這還是有點難,如果過於專注甚至會讓我們錯失了大好機會,說不定下個事情進來是個成功的契機。這世界不斷的在改變,如果我們不能專心的保持向前,那麼我們就會被分心甚至最後發生了意外。

所以應該要建立優先順序該專注的項目,總共分為兩份清單: 

清單一、Focus List (the road ahead)
哪些事情要達成?哪些事情會感到滿意與開心?哪些事情是很重要?不論多努力我們每天的時間非常有限。

清單二、Ignore List (the distractions)
要明智有效的使用自己的時間,必須要時常問自己:有哪些事情是不應該去達到?怎麼做會不開心不滿意?哪些事情是干擾的?

很多人已經有了第一個清單,但是很少人擁有第二個清單。但是第二個卻是非常重要的,它會深深影響著我們日常工作、日常作息。所以我們不應該只是想想而已,我們應該把這兩件事情當作每天必須檢核的項目清單。每天早上,在行事曆上檢視和問自己,今天的計畫是什麼?我會怎麼分配我一天的時間?我該如何專心?我怎麼樣會被分心?那麼找個可以達成這樣的方式,做出決定,甚至會得罪幾個人在所難免。

我們每天可用的時間就這麼多,如何有效的展開不一樣的每一天,讓自己可以做事更有效率,做對事情,將自己放在最好的事情上投資。以上本篇是閱讀 Harvard Business Review Blog: Two Lists You Should Look at Every Morning 的心得與重點整理。

Sunday, May 27, 2012

iOS App 設計上須具備創意者的韌性

蔣道設計

“市場要買的是創意者的韌性”

在翻閱天下文化出版《蔣道設計》的設計力篇,在第 53 頁那段看的很有共鳴。


所謂韌性是指包容心與同理心。設計者應該以客戶的價值回包自己的假者,讓兩者有機會融合,有機會突變。在這種狀況下鎖產生的設計,客戶才會接受。一旦客戶真正接受創新,創意才有上市的一天。如同電器的董事長很有新的想法與價值,但是負責執行的窗口,卻習慣傳統電器的作法。在這開發過程是滿足安全感,最適合他們的設計。但是這樣子從外包的設計者只能來配合帶來包容心。而同理心的部分設計者要有能力置身客戶的鞋中,以客戶的狀況為狀況,在綁手綁腳的情況下做好創意,並有做白工的準備。因為 100 個好的 Idea 最後會被採用可能只剩下 2~3 個。設計其實是服務業,因為設計的往往不是課本中樣子,而是客戶。要像心理醫生,要不斷的聆聽客戶與市場的聲音,再藉由環境的改變,讓兩者接軌。所以多數時候,都會變成:付錢的是老大。

反觀回來自己 iOS App 設計

我們可以不用有包容心,因為 iOS App 的設計與實作都是自己親手處理,所以不會有設計一回事,開發是一回事。但是看到以上這頁內容讓我想到,當投入 iOS App 日常工作開發,自己是否有不斷的持續學習呢?還是變成永遠只會那幾個設計樣式、那幾種保險不會出錯的開發選擇,讓自己可以在很安穩的情況下只是把 App 設計出來,但是卻缺乏一點新的創新都沒有的結局。但是使用者為中心的設計還是不能少,要用心觀察與同理心

最近在看國際知名的 iOS App 與自己設計的 App 做比較的時候,其實會發現兩者落差很大,那麼要透過哪些方式來拉短彼此的差距呢?

Saturday, May 26, 2012

InfoTouchPanel 從 iOS App 底部出現提供使用者點擊

InfoTouchPanel
當 iOS App 需要呈現大量資料的列表時候,如果讓使用者需要一直滑動滑動要看最下方新的資料的話,勢必會很辛苦,因為使用者只是想看最下方最後幾筆資訊。於是如果能夠提供一個選擇來問使用者是否需要到最底部,當使用者點擊即可快速到達下方,那麼這樣的便利性的設計是不錯的。讓我們來想看看怎麼設計這樣的巧思。

1. 需要一塊長條型的畫面,並且從底部浮起來

有長條形的畫面除了可以有文字提示之外,從底部浮起來,即可讓使用者有往下閱讀的直覺提示。所以這樣設計上要考量用些 UIViewAnimation 來處理。但是設計的好,是需要可以讓呼叫的程式可以給予從哪邊浮現出來。

2. 需要支援點擊事件

因為如果這樣的長條畫面出現,要讓它可以讓使用者點擊,但是點擊後要做啥,這是需要讓呼叫的程式來處理各自邏輯的。所以在設計這樣的點擊事件,務必要把點擊後將操作權還給呼叫者。因次建議使用 selector 方式處理。如此一來不但圖形本身處理完自己事件,再讓點擊後處理要跑的程式邏輯。

3. 決定出現、隱藏過程秒數

這樣的提示如果能夠讓它根據呼叫者給與的秒數來決定顯現,這樣即可根據需求來決定它出現的效果。

以上這樣的設計最大巧思莫過於如何讓這樣的 InfoTouchPanel 設計將自己處理自身邏輯,如何出現、如何隱藏,但是又能讓呼叫的程式可以處理前後的邏輯。我在這個 Project 使用了 ARC 的開發方式,另外引用了 BlocksKit 來讓程式可以更簡單的撰寫。目前已經放在 GitHub 上面 edwardinubuntu/InfoTouchPanel,而在 License 方面是採用 MIT license。

Sunday, May 13, 2012

BlocksKit on GitHub

Blocks 可以讓我們的程式撰寫更簡潔和潛在的快速,更不用說當搭配 multithreading 時候和 Grand Central Dispatch。而 BlocksKit 這套 Libray 設計出來希望能在程式撰寫上帶來便利,且不會有擾人讓程式碼可以更結集在一起。當程式上使用了 Delegation Pattern 需要呼叫回傳,這不只讓邏輯程式碼分散之外,在傳遞指定程式邏輯撰寫上也很吃力。

當 iOS 4.0 介紹支援 block 技術後,BlocksKit 著重在這幾個層面上:
  • 需要 Callback 的 delegate 機制 (UIAlertView) 
  • 當使用了 target/selector pattern 時候 (UIControl, UIGestureRecognizer)
  • 需要不斷重複執行的狀況 (NSArray)
  • 必須使用到 selector 時候 (NSObject -performSelector:withDelay:)

Tuesday, May 8, 2012

Discovery - Mob Rules 黑幫管理學教我的事

Mob Rules [Kindle Edition]
昨晚 Discovery 頻道播放了《黑幫管理學》,路費倫特 ( lou ferrante ) 說:結合家族和企業, 最頂尖的高手就是黑幫。路費倫特本來是黑幫中的賺錢高手,賺了幾百萬美金還有一幫自己的搶劫團隊,坐牢後人生有了 180 度的轉變,現在他是個成功的企管顧問,要揭露黑手黨的賺錢秘訣,並用這一套黑幫管理學,來拯救垂危的家族企業!而觀賞過程有很多概念是相當適合在團隊運作。當兩人以上在同一個團隊完成計畫,就少不了管理與領導。

領導人是否具有領導能力

一群人完成計畫一定要領導人,他會是某些考量因素被指派,但是當他被指派了,我們要去判定他是否可以感染影響夥伴,帶領團隊發揮最好的一面。

努力工作與榮譽感

是否對於現在工作感到驕傲,唯有讓自己擁有榮耀感才會努力工作。同樣的要喜歡工作才會努力工作,創造出榮耀感。這些都是息息相關的,如果發現無法努力無法高績效表現,就該從榮譽感和成就感來檢討,發生了什麼現象。

如果產品與服務本身出問題,和團隊或者管理人的組合有問題

每一項產品服務顯現出來,一定可以從各種角度會發現他的優缺點,但是我們必須謙虛地承認這就是這個團隊與管理人表現出來的結果,是非常有關聯的。所以當發現產品服務出了問題,要從團隊與管理者本身去剖析與了解。

訂立清楚的目標

如果發覺整個團隊混亂不知道該怎麼做事情,就是目標不明確。訂定清楚目標是管理者要負的責任,除了從指標、方向訂定之外,再細分到里程碑,如何一個一個里程碑去計畫出來。

找尋內線人員了解感想

如果要為管理者打分數,要從多個面向。所以除了自己本身老闆角度去為管理者打分數之外,也要參考來自其他夥伴們的面向。不論是水平同層或是垂直部屬關係,都是可以當做參考的。

尋找適合的人選來協助搞定

當身為老闆或是負責人發現管理者有問題,自己如果沒有時間來處理,找尋自己信任和適合的人選來協助搞定是個非常有效的方式,不論是要找稽核角色或者是協助角色。

開始銷售

所有做生意都是要賺錢有利潤,所以當團隊運做起來順利了,就必須開始拓展人脈,從自我介紹開始,每一位必須要以自己為榮。只有以自己為榮才會做出好的產品與服務,才能開始驕傲的說出自己產品哪邊好。

控制脾氣

不論什麼職業,不論什麼階層的管理者都要控制住自己的情緒。情緒上只是會讓自己做出不好的決定,嚴重的話甚至會發生無法悲劇。因此要情緒留在個人生活,工作時候就要冷靜,才能繼續。

調查管理者過去

每一個人會有今天看得面貌,我們一定要了解他的過去。如果你對於現在這位管理者做出這樣決定與種種現象感到不安,那麼他的過去經驗是非常重要的,一定是哪些因素造就了今天這樣結果。調查過去,有不好的狀況如何來改善。

團隊成員比事業更重要

團隊間的士氣相當重要,彼此不能有心結。這個優先順序必須要在拼事業之上,如果團隊成員彼此間有問題,我們該如何來進行接下來的溝通與合作呢?所以團隊之間的感情必須要先被克服。

以上當這些要點在影片中最後逐一改善之後,整個新公司也擁有了新的形象,品牌也更確定,如此一來才能與消費者更靠近,才能做好生意。
路費倫特有出書 “Mob Rules: What the Mafia Can Teach the Legitimate Businessman [Kindle Edition]” 可以在 Amazon.com 上面找的到。

當我們跟夥伴要合作時候,團隊運作就非常重要,而這些要點特色在於移除那些讓我們不能做出好產品服務的障礙。如此一來我們才能與做好生意更靠近一步了。

Friday, May 4, 2012

GitHub 的 Pull Requests 可以這樣使用

在 GitHub 上最大特點就是希望我們可以多點社交讓 Open Source 可以更有系統的成長,而 Pull Requests 是最有名的功能之一,我在之前這篇 Opened Pull Request on GitHub 有做過步驟介紹與分享。在閱讀過 How we use Pull Requests to build GitHub 後,有了更進一步瞭解 Pull Requests 還有它背後另外一層涵意,我們可以這樣用。

Pull Requests 可以用在這些好的實踐方法上,例如圍繞著新 Idea 討論和請人來加入協助。 Pull Requests 讓大家看到最新進展之外,和凸顯出夥伴們如何踴躍地加了更好的貢獻。這運作方法就像是 Open Source Project 一樣。所以 GitHub 部落格分享了可以有這幾種不同觀點來使用 Pull Request:

1. 儘早啟動 Pull Requests 越早越好

Pull Requests 是個啟動討論新功能的好方式,所以越早開始越好,不用擔心程式還沒寫完。團隊們可以來討論這個新功能,不用到最後完畢了才來給予意見回饋。

2. Pull Requests 讓是 Branch 與 Branch 之間獨立運作

最大好處就是大家不會在同一個 Branch 上面來做先後 commit 與匯流參雜再一起,反而是彼此獨立在不同 Branch,當運作好的 Branch 才將它 Merge 回主要 develop 或是 master branch 上。除了多一層把關上,所有事情的改變也交代的更清楚。

3. Pull Request 不必真的要被 merge 合併

因為 Pull Request 是在另外獨立的 Branch 上,我們除了掌握最新進展外考慮是否要合併回來之外,同時也許改了不是那麼的恰當與適合。我們要有新的思維,我們是可以直接關閉它而不一定就非合併不可。

最後分享一個 GitHub 使用者資料,透過 GitHub 我們是可以查詢“ locaion: Taiwan ”同時也有參與“ Objective-c ”的 GitHub 使用者,目前在第二筆資料 edwardinubuntu 是我之外,您總共認識了幾位呢!

Thursday, May 3, 2012

Write down Successfully Pitch To Make Sure It Gets Reviewed

我們除了將 iOS App 順利通過審核上 App Store 那大關,我們下一步該做什麼?Review sites 是我們向外公告的最有效與有力的宣傳管道,但是 Review sites 每天那麼多的事情要報導,我們如何有效的準備來提起他們的興趣呢?

此為 Redmond Pie 一個 Review Site 在介紹 Chirps for iPhone 的範例

Chirps for iPhone
Chirps For iPhone | Redmond Pie

App Pitch 就顯現非常的重要,在 AppDesignVault 網站找到了這篇 How to Successfully Pitch Your App And Make Sure It Gets Reviewed – Interview With Erica Sadun 以及 Sample Pitch Document 範例。所以很清楚可以看見我們要準備哪些。
  • App 在 App Store 上面確切的名字。
  • 他是做什麼的,特別處與為什麼不一樣。
  • 價格。
  • 一個連捷到產品網站頁面。
  • 一個連捷到 iTunes 產品頁面。
  • 一到兩張螢幕截圖。
  • 一個介紹短片。
  • 一份簡潔的描述文。說明客戶會是哪些,你的 App 提供了哪些事情,在群眾中它的與眾不同地方。
  • 聯絡方式。
  • 是否有其它相關 Social Network 帳號作為聯繫用。

在這份範本裡面可以學習 Description 撰寫方式與 Features 列表的呈現方式,最後最重要的,這一切都是要練習,當寫得出好故事,我們再來為各國語言的用詞用法傷腦筋吧!

Wednesday, May 2, 2012

The Cross-Pollinator 把所見所聞應用到 iOS App 設計

The Ten Faces of Innovation
“偶爾離開大家常走的路,鑽到林子裡吧。這樣做,你每次都一定會發現一些前所未見的東西” ﹣ 亞歷山大 貝爾 (Alexander Graham Bell)

The Cross-Pollinator (異花授粉者) 能夠把一些看似不相干的構想或者概念隨意地並列在一起,從而創造出更新、更好的事物。他們經常要從某一個領域或產業中,找出聰明的方法,加以創新,進而成功帶到另一個領域或產業上。這是從書本 The Ten Faces of Innovation 決定未來的 10 種人,作者 Tom Kelley, Jonathan Littman 著裡面挑選出來一種。

在 iOS App 這個產業,身為 Developer / Designer 或者任何開發 App 角色,這種特質更為需要。當你發現那些 5 顆星的 App 所具備的條件裡面,單純也 App 本身來看,除了功能好用、介面有設計感、娛樂性之外,整體而言要到一種讓使用者有種,對,這就是我在找的 App 的感覺。而這就需要將整體的專業度和概念設計的更為的完美。所謂的完美是在有限的資源下設計出符合該 App 要表達的概念之外,而且還要能完成使用者需求、介面有設計感吸引下載,最後還要讓他會愛上這個 App。這樣的 App 相當的多,只要你隨意問身旁有用 iPhone 的朋友們,他們列舉出來的前 5 個一定都有這些特色。

回到異花授粉者,這樣的特質要如何輔助 iOS App 開發呢?有以下幾樣特質:
 

1. 分享秀 (Show-and-tell)
當打開部落格會不會不知道要寫什麼,就跟要同伴門提出新 App 功能想法一樣沒靈感?分享秀是需要平常離開辦公室、離開電腦,去收集各種現象與知識,當回來時候再透過有系統的分享,放入知識庫,當接下來的工作上,就可以使用。這樣不一定現在 App 規劃可以派得上用場,但是可以確保保持工作方法不會落伍。 


2. 聘請許多不同背景的人
如果要應徵 iOS App Developer 或者某某開發人員,那麼就只是再找另外一個張三工程師,面試就超級簡單了,人也可以滿地找。所以我們要能去找不同的領域的人才,增加自己團隊的人。
 

3. 跨文化和地理區域
能夠擁有不同文化與地理位置的同事是最棒不過,但是如果在還沒有發生以前,我們是否可以從自己的朋友圈開始,透過自己去結交認識,除了欣賞朋友的特質之於,再多去聽聽他的背景,從他的視野裡面看的角度,我們才能找出不是只有自己生活圈的知識。不同的文化、不同的人文特色是我們要了解,我們才能將我們的服務與產品規劃的更適用。

4. 時常自我舉辦「實務知識」(Know How) 學習
我們必須藉由講座、雜誌、書籍來獵取不同領域的知識,當我們未來要設計這方面的 iOS App 才能更為貼近與符合該領域需要。如果今天設計植物種植記錄 App,我們務必一定要是自己或是認識花卉園藝者、農夫作為朋友,再來實際去田野觀察與記錄,再將這方面的所有知識帶回我們的電腦桌,這樣我們才能設計出好的植物種植記錄 App。
 

5. 向參訪者學習
在新創公司一定會有各種新的訪客不論是合作夥伴或者是客戶談生意,這些都是我們學習的對象,他們來訪一定帶著他們的專業背景與知識,如果能透過這裡面學習更多知識更新的訊息。
 

6. 向外尋求不同的專案
我們不會永遠只做一種產品或服務,所以當我們接觸新的領域時候就是我們學習新產業的機會開始。

異花授粉者需要結合各種構想,扮演我們俗稱的 T 型人,橫向廣涉各種領域的知識,當要回來搭配開發 iOS App 才能將概念完整的實作執行出來。所以異花授粉者必須專精於一項領域,例如像是我在扮演的 iOS App Developer,那麼需要讓自己能在具備多種知識。

並非所有的異花授粉者都是如此多才多藝,但優秀的異花授粉者,當他們從外界引進大觀念時,往往能夠對整個 App 設計產生震撼效果。此外,異花授粉者並不一定要從聰明的人才能升任。即是微小、特定範圍的見解也能夠產生顯著的差異。

Wednesday, March 28, 2012

Facebook Mobile App 整合上的 5 個 Pro Tips

App Discovery 的範例
不論是您正在設計新的串接 Facebook 平台 Mobile App 或者您正在享用手頭上一款整合 Facebook 平台的 App,是否可以找到這些整合的設計面向呢?當我們在 Facebook 平台上開發我們的 Mobile App,有幾個要點可以來讓我們更加專業。


Pro Tip #1 Add your mobile app to timeline

讓 App 為使用者完成事情,規劃將它可以發佈到該使用者的 Timeline 上,除了可以做為個人的重要記錄之外,朋友們看到這樣的故事分享,也會好奇想要使用該 App。這篇文章有個影片做更完整的說明。 https://www.facebook.com/help?faq=105925952849619


Pro Tip #2 Be cross platform

讓 App 可以跨平台無疑是希望可以讓使用者不會因為擁有某種平台的智慧型手機而受限不能使用,因此在開發上儘量考量到所有的 Mobile 的使用者,所以除了在 Native App 的開發之外,Facebook 也很鼓勵大家開發 Mobile Web 等形式來擴大使用者族群。


Pro Tip #3 Implement single-sign-on in iOS and Android Apps

為了讓使用者能方便使用 Mobile App,目前在 iOS App 和 Android App 都有 single-sign-on 的方案了,而我們在設計我們 Mobile App 時候,考量到如何讓使用者可以在初次使用認證過程可以非常的順暢與熟悉。


Pro Tip #4 Implement request for app discovery

當使用者開始使用了跟 Facebook 整合的 App,有幾種方式可以讓它更容易被使用與發覺。
  • Bookmarks - 當使用者在自己的 iPhone 上透過 Facebook app 認證使用後,之後在 Facebook App 的左手邊 Navigation 區塊的 Apps 區,就可以看到連出去到該 Mobile App,這功能好把為該 Mobile App 加上了書籤捷徑。
  • Requests - 使用者可以透過邀請功能邀請朋友來使用 App。
  • News Feed - 設計好分享的內容,讓使用者可以在分享他們自己的自己的 Wall 上之後,朋友們也可以看到這樣有趣吸引人的事件。
  • Authenticated Referrals - 讓使用者可以透過 Facebook 搜尋找到 App,而且訪客在開始使用這個 App 可以適當顯示需要的權限與說明。而這樣的功能讓使用者同意授權後,讓 App 可以設計出更好更個人化的體驗。
News Feed
這篇有詳細的額外說明。 https://developers.facebook.com/blog/post/575/


Pro Tip #5 Leverage existing friend graph

Facebook 有很多的方式可以來擴散讓朋友們一同來使用,可以從朋友清單之外,如何利用適當的 Send request 或者像是 Tag 讓朋友們可以透過這樣擴散的影響力,讓朋友們知道有這樣的 Mobile App 可以使用。

這些專業的方法,可以讓我們在設計整合 Facebook Mobile App 時候除了更加貼近好用之於,也可以讓使用者方便和簡易的邀請朋友們一起來使用。以上是我在 March 22, 2012 前往香港參加 Facebook Mobile Hack Event 的部分心得筆記,詳情當天活動資訊可參考 http://fbmobilehackhongkong.eventbrite.com/

Tuesday, March 27, 2012

Kensignton PowerLift, Back-up Battery & Dock

PowerLift
如果說一位 iOS App Developer 該有的隨身攜帶幫手,PowerLift 就是一個必須擁有的好幫手。從設計角度來看,它很方便、很容易使用、美觀、且實用,它擁有了以下三大功能特色:

Kickstand
如果說 iOS App Developer 每天都需要開啟 Xcode 將 App 建置到手機上,是否有想過過程是什麼?將 iPhone 插上 USB 線,讓它躺在桌子上,當建置好了開始在跑,再用手把它拿起來開始操作測試。這樣的取的動作可能不是那麼的方便。這個 Kickstand 能將 iPhone 站立起來,就好比我們平日時常看到的手機座。但是它跟手機座又有什麼不同呢?手機座沒有下方可插槽,所以用一般的手機座就只能站立而已。

Dock connector for iPhone
在這台上面裝置了 USB 線,它跟另外一頭跟 Mac 接上之外,這邊的這端就是 iPhone 下方的插槽,可以讓 iPhone 跟 Mac 串接起來,不論是 Build & Run 或者是要用 iTune 同步備份,或者只是要讓 iPhone 充電,這樣的設計完成了這些行為。

Power check button and 2-position charging
他除了是辦公室書桌上的之外,更是我們平日攜帶在旁的好工具。別把它丟置在家或者是辦公室,它是一個方便攜帶的充電電池呢!這顆擁有 1200 mAh 的電容量,對應 iPhone 4S 的電池 1420 mAh,可以將 iPhone 4S 完成充電約莫 85% 的電容量,這樣攜帶 iPhone 4S 在外一整天,都可以充分使用無太需要擔心 iPhone 沒電。

這樣的商品可以設計如此貼近我們的生活所需,方便又實用且美觀之餘,它可是得到 2011 Design & Engineering Showcase Honors 的殊榮。如果下次您在 Apple Store 逛的時候,不仿留意一下此商品吧!了解更多 Kensington - Smartphone - iPhone & iPod - Batteries - PowerLift™ Back-Up Battery, Dock and Stand http://bit.ly/H8JRl2