Pages

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