Pages

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 設計產生震撼效果。此外,異花授粉者並不一定要從聰明的人才能升任。即是微小、特定範圍的見解也能夠產生顯著的差異。