創業者，請不斷的問自己：我幫使用者解決了什麼問題？我到底幫使用者解決了什麼問題？

你幫使用者解決什麼問題？ 這是 500 Startups 創辦人 Dave McClure 上次來台灣，每個創業者跟他 Pitch 時，他劈頭就問的第一個問題 — 真的是劈頭，常常連你的第一句自我介紹都還沒講完，他已經丟下這顆炸彈。 見賢思齊，從此之後我也常常把這個問題第一個就丟出去。令人驚訝的是，幾個月的實驗下來，能夠精確回答的人，居然是少數。 當然每個人蓋網路服務、做 App、設計遊戲，都是希望給使用者，很多很多使用者來玩，來用。而創業者更常常以顛覆既有產業，改變人們生活為終極目標。但如果連這個最核心的問題都沒有好的答案，那或許你的希望與執行之間，還存在著不小的差距。 當然要能夠「精確」的回答這個問題，並不簡單。因為它不是「一個」問題，而是很多很多問題的集合。以下就是那些「子題」的列表，你可以試著檢查看看，如果你越能夠回答以下這些題目，那就表示你越清楚你到底在幫使用者解決什麼問題。 你的使用者是誰？ 你的早期使用者是誰？中期使用者？長期使用者？ 他們都有怎樣的特徵？(e.g. 性別、年齡、收入、居住地區、興趣、婚姻…) 你可以在哪裡抓到他們？ 他們有哪些共通的問題？ 你幫他們解決的又是其中哪些問題？ 你如何確定這些問題實際存在？ 這些問題有多麼困擾他們？ 他們願意付錢解決這個痛苦嗎？ 在沒有你的產品之前，他們都如何解決這個問題？ 原本的解決方案的優點是什麼？缺點又是什麼？ 人們都花多少錢在這些原本的解決方案上？ 你知道什麼事情是原本那些解決方案提供者所不知道的？ 為什麼原本的解決方案提供者不知道這些事情？ 為什麼原本的解決方案提供者不修正他們的缺點？ 這個問題是因為使用了某個產品/服務而造成的嗎？ 這個產品/服務的生命週期如何？能夠等待/支撐你的解決方案嗎？ 如果你能夠很有信心的回答上述問題，恭喜你，你正在解決一個很重要的問題。如果其中有某些問題無法確定，那請你做更多實驗去找到答案，當然，除了跟使用者對談、問卷、Focus Group 等傳統方法之外，建造並推出 MVP (Minimum Viable Product) 也是一個取得答案的方式。尤其是早期創業，你做產品的目的往往比較是在釐清問題的存在，而不是在創造一步登天的成功服務。 答案一直在那邊，所以重點是問對問題。只要你不斷的質問自己這些核心的問題，你的創業之路就會越來越清晰。 與大家共勉。 ___ 許多我看到的新奇資訊，都會分享在 Google+ 上，歡迎追蹤。 (Photo via mobilestreetlife, CC License)

借 Mr. Jamie 這篇文章書寫一下我今天的感想。一開始有產品 idea 的發想時，我想大家都能了解一個好的產品應該是要去解決某個使用者遇到的問題，不管這個使用者是自己還是別人都好。但是當產品在開發的時候，慢慢的就會有其他聲音跑出來了，像是「你的產品有沒有賣點？」、「你的產品有沒有市場？」、「你的產品有沒有創意？」、「你的產品策略是什麼？」、「你的獲利方式是什麼？」

以前我都會覺得這些聲音都對，都是要去思考的。但是我今天的想法更清楚了，不管如何，自己要不斷去問自己一個問題：「產品本身要解決使用者哪個問題？」如果當你的創意、賣點、行銷方式、收費方式跟要解決的問題沒有直接關係，那麼這些東西將只是雜音而已。你的賣點再漂亮，創意再獨一無二，如果跟使用者痛點無關，那麼就僅僅是個賣點、是個創意，並無法幫產品本身帶來多少價值。

A Custom Callout View for iOS

nfarina:

Check out SMCalloutView on Github.

There’s a great UI widget that’s been on iOS since day one:

image

Ever wonder what that black pointy bubble is exactly? It’s kind of a strange beast. The way it “bounces” when opening is an animation that I believe is unique across the entire iOS platform. It kind of grows out from the tip of the arrow then springs back like a UIAlertView. I still find it fun and satisfying to watch.

So when we were creating our indoor mapping UI for Meridian, I naturally wanted to use this widget. Unfortunately, it’s considered a private API. Bummer!

There are some existing 3rd-party controls out there that mimic this one, but they aren’t a perfect replica. And I demand perfection! So I made my own version, and dubbed it SMCalloutView.

Read More

談 X Team

寫這個標題對我來說壓力有些大，因為我畢竟不是這方面的專家，怕給人好像我很會的假象，所以這篇只談心得，不講方法論。

第一次知道 X Team 是在前公司。前公司相當重視 Innovation ，而且是內部創意，但是就跟所有需要創意的大公司有一樣的毛病 — 不知創意如何而來，所以就會尋找許多外援，找專家來協助，所以那時候就有跟政大合作一起成立了 Cross Team ，也稱之為 X Team (X 意指 cross)。 X team 來自於 IDEO，IDEO 是世界相當知名的 design consulting firm，IDEO 最知名的在於它的 design thinking 的方法，什麼是 design thinking 我也不會講，也講不好，所以就不講 (可以參考這部影片: http://www.designthinkingmovie.com/index_ch.html)。我那時候是一開始實驗的 X team 成員之一。

在 design thinking 裡有一個很重要的角色存在 — X Team，X 意指 cross ，代表一個 team 裡面的成員組成來自於不同的背景，或者擁有不同的專業。X team 是扁平的組織，沒有階層或者利害關係。 所以在做內部創意發想，或者 brainstorming 時，X Team 比較容易帶入不同的觀點，避免最後得到的創意過於狹隘，整個創意發想過程也會更有效率。

雖然我之前待的公司，在我離開之前都還沒有把 X team 執行的很成功，或者還沒看到什麼實質的成效，但是我還是對於這個方法很有信心(前公司也還一直很有信心，目前正擴大實施中)。離開後，也沒有什麼機會能夠真正接觸到 design thinking process，直到前不久才有一次我認為最接近的 X team 的創意發想過程。幾個禮拜前我跟公司 designer Kimies 一起參加了 Evernote 舉辦的 designathon，當天又在會場遇到了 Kimies 的同學跟學妹，所以我們就四個人組了一個團隊參加比賽。有趣的是，雖然這是一個 designer 的比賽，理論上成員應該都是 designer，但是我們這個 team 裡面成員還是有著不同的技能: 我自己本身是 iOS 開發，Kimies 是 visual designer，學妹學 industry design，同學則是熟悉 web frontend design。這是一個兩天的 hackathon，第一天作 idea 發想時，我還沒有注意到我們成員的組成有這獨特性，直到第二天 idea 慢慢成形時，我才意會到這應該就是一個簡單而且具體而微的 X team (應該還要加上 xteam 專家 haha)。所以最後成果很顯著，我們拿到這次 designathon 的第二名！

但是要在一間公司裡面找到不同 background 的成員其實沒有想像中的那麼容易，尤其我現在的公司是作 app 為主，其實成員大多數都是相類似領域裡的專家，developer 佔多數，雖然 developer 都是相當有創意的一群人，但是我以往的經驗是，一群 developer 聚在一起常常會演變成技術討論，觀點也經常雷同，創意常常會遇到瓶頸。

所以最近我們開始發想一個新的產品功能構想，brainstorming 是很重要的，不僅是在盡可能的找到解決方案，更重要的是透過 brainstorming 的方法讓團隊成員進入情境當中，讓最後實作出來的功能能更合乎使用者的角度 (user centric)。所以 brainstorming 就是要讓大家參與討論，不論 idea 是好或不好。在發想過程中，會發現一些有趣的現象，有些人看起來參與慾望似乎不高，但是卻常能提出一些有趣的觀點。有的時候，一些 idea 乍聽之下似乎跟當前討論不太相關，但是其中某些細節卻有值得玩味之處。brainstorming 的結果不一定是要結合每個人的想法，我覺得更重要的是要取得大多數人的認同，並從過程中一直去迫近更棒的解決方法，一次又一次的 brainstorm 會讓 solution 更加成熟。所以很重要的是，X team 的 brainstorming 中，沒有「什麼什麼」是「誰誰誰」的創意這回事，是屬於這個團隊討論出來的最終結果。

此外，要讓 x team 的 brainstorming 更容易執行，我覺得需要找到一些喜歡參與討論的成員。有自己的想法和意見，喜歡與人討論的人，不論他的意見是否與你相左，這樣的成員很容易幫助這個 x team 的討論進行下去。但也要盡量避免想要 dominate 整個會議討論方向的人，畢竟 X team 存在的目的就是用各種不同的角度去迫近最好的 solution ，如果只是一人發聲，那其實也沒有 x team 存在的意義。

IDEO / Design Thinking / X Team / Prototype 是我蠻有興趣的 topic ，我相信這些是在產品開發公司裡作內部發想創意的方法 (不是只存在於 design firm 裡)，但我們也都是幼幼班，作法有些土法煉鋼，就看這些方法是否能真正帶來什麼功效。

有興趣多研究的可以參考這本書: http://www.amazon.com/X-teams-Build-Innovate-Succeed-ebook/dp/B001E52R9M/ref=tmm_kin_title_0

我自己本身是還沒讀過就是了  XD。

換裝 Fusion Drive

前不久，Apple 剛推出 Fusion Drive 時，網路上就出現如何自己 DIY Fusion Drive 的作法，我同事們也一窩蜂的一一換裝。不過那時候比較忙，不想在最忙的時候還要騰出一天作這些雜事，況且拆機器也是要擔一些風險的，所以一直拖到今天，趁著過春節假期的前一天，反正公司內大家也沒什麼認真上班的心思，好好花上一天把 MBP 升級為 Fusion Drive。

升級的過程其實很簡單，只需要按照這個網頁的步驟一步一步來就好：

http://www.macuknow.com/node/21313

不過我們的作法稍有不同，因為公司裡 MBP 眾多，可以找到一台備用機來做資料備份，所以我們就拆了兩台 MBP ，對調裡頭的硬碟，然後將我的 MBP 光碟機拆掉，換上 SSD，切割 LVM 成 Fusion Drive，重新安裝 Mountain Lion ，最後再將另外一台 MBP 裡的資料透過 Migration Assistance 移回剛新安裝好的系統中。整個流程中，我覺得風險比較大的是拆卸光碟機跟安裝SSD。MBP 的組裝非常精細，拆卸時要一步一步做對，螺絲也不能亂放，要不然很可能東西拆下來了，才發現組不回去就哭哭了。所以拆解的過程一定要按照 iFixIt 的流程說明一步一步來。

等到拆完了，組合完了，也弄好 Fusion Drive 了。Migrate system 又是另外一個曠日廢時的工作，我總共花了 6 個小時的時間才把我的備份從另外一台 MBP migrate 回我的工作機中。

換好 Fusion Drive 最直覺的感受就是開機時間明顯變快了。其他的就有待體驗了。

換裝過程中有個小插曲是，我發現我 MBP 裡有小強屍體。我們公司之前樓下是開餐廳的，有一度曾經小強為患，公司裡偶爾會看到小小強竄出，小強又喜歡溫暖的環境，常常會躲到螢幕或者電腦裡，所以會在 MBP 裡清出小強也不是太意外。

Untitled

Untitled

Untitled

Untitled

Untitled

完成的結果，500G HD + 120G SSD => 620G Fusion Drive

Keep it simple, and release earlier

It is always inspiring when reading Jason Fried and his companies’ small book, “getting real” or “rework”.

Here is some quotations from “getting real”.

Fix Time and Budget, Flex Scope
”There’s always time to add stuff later - later is eternal, now is fleeting.”
”Scope down. It’s better to make half a product than a half-assed product.”

Ignore Details Early On
”Success and Satisfaction is in the details. However, success isn’t the only thing you’ll find in the details. You’ll also find stagnation, disagreement, meetings, and delays. These things can kill morale and lower your chances of success.”
”Work from larger to small, always.”

Half, Not Half-Assed 
“Throw in every decent idea that comes aloneg and you’ll just wind up with a half-assed version of your product. What you really want to do is build half a product that kicks ass.”
“Stick on what’s truly essential. Good ideas can be tabled. Take whatever you think your product should be and cut it in half.”

It Just Doesn’t Matter
”Most of the time you spend is wasted on things that just don’t matter. If you can cut out the work and thinking that just don’t matter, you’ll achieve productivity you’ve never imagined.”

 

Subclass UICollectionViewLayoutAttributes

[前情提要] 我在 2012 年 12 月台北 Cocoaheads 介紹 UICollectionView 時，裡頭所用的範例 - 一個簡單的月曆程式: https://github.com/syshen/YACV

這個月曆程式除了簡單的 UICollectionView 應用外，也透過 subclass UICollectionViewFlowLayout 與 UICollectionViewLayout 來額外提供不同的 Collection 排列方式。

基本上，UICollectionView 是一個彈性非常大的函式庫，除了強大的基本功能外，你還可以透過繼承的方式來客製自己的應用，最常見的範例就是 Coverflow 的實作。整個 UICollectionView 的架構大致像這樣：

Collection View 透過 Datasource delegate 取得每個 Cell ，再透過 Collection View Layout 取得每個 Cell 的 Attributes ，將這些資料整合在一起排列在介面上。想要改變排列方式就透過繼承 UICollectionViewLayout 來客製，並透過設定 UICollectionViewLayoutAttributes 來設定每個 Cell 的屬性，像是大小、位置，甚至是 transform3D 等。

但是萬一你想要設定的屬性並不在 UICollectionViewLayoutAttributes 的 property 當中的話，你還是可以透過 subclass UICollectionViewLayoutAttribues 的方式來額外提供你想要的屬性，並讓 UICollectionView 幫你傳達這些屬性。只是客製的方式比較不是那麼直覺就是了。

底下是簡單的 Code snippet ：

這段 Code subclass 了 UICollectionViewLayoutAttributes 來額外增加一個新屬性: gradient，也 subclass 了 UICollectionViewFlowLayout 來設定這個新的屬性。裡頭有三個地方要特別注意的：

- SSLayoutAttributes 裡要實作 copyWithZone。因為 UICollectionView 裡會對 UICollectionViewLayoutAttributes 做 copy 的動作，如果你沒有實作 copyWithZone，你所新增加的屬性內容就沒辦法傳到 UICollectionViewCell 了。

- SSFlowLayout 裡需實作 +(Class)layoutAttribuesClass 讓 Collection View 知道你的 Attributes 類別是什麼。

- 根據 Cell 的位置等資訊設定你的新屬性。

接下來，就是在你的 Collection View Cell 類別中實作 applyLayoutAttribues 函式，UICollectionView 會在適當的時機點叫用這個 method，所以你在可以在這個 method 裡套用你的新屬性。

這樣大致就做到了客製 UICollectionViewLayoutAttributes 。

用 Core-Image 裁切跟縮放圖片

接著昨天的 UIImage+FaceFirst ，想說 CIDetector 是植基於 Core Image 之上，何不乾脆把 Crop 跟 Resize 也交給 Core Image，將 Image 處理交給 GPU 去做運算。改寫如下：

程式碼放在 Github 的 Core-Image branch 。

不過實際執行的結果跟我預期有所落差，在 Simulator 上得到極差的效能。效能差的地方在於 CIContext 將 CIImage 轉成 CGImageRef 時，而且不是只有 ms 上的差異而已，甚至是可以以秒來計。不過當我把 app 載入到 iPhone5 或者 iPhone4 上時，速度又快的亮眼，Profile 測出來完全看不到 Simulator 上 createCGImage 的問題。只能猜測是 Simulator 跟真正手機上，GPU 跟 OpenGL 差異所造成。

image

但是跟前一個版本比較起來，效能沒有顯著差異，所以就沒有把這個 branch merge 回 master 了。