Saturday, December 7, 2013

What I learned from games

前一陣子為了要研究手機遊戲到底為什麼會這麼吸引人好應用在Flirq交友(好啦, 其實是我自己想要玩XD), 花了一些時間玩了一代宗師和神魔之塔這兩個手機遊戲. 以下是一些我自己覺得他們做的很不錯, 雖然不一定適用在Flirq裡, 但是是很值得學習的點.

1. 容易上手, 培養使用者興趣與習慣: 之前看過一篇Nir Eyal的創業心得分享, 是在講習慣(habit)的重要性. 這些手遊在這一點都做的非常的好. 一開始先透過簡單的關卡, 一邊教學一邊建立使用者的信心跟興趣. 等開始要進入比較困難(通常也差不多是可能需要花點錢會比較容易過關的時候)的關卡時, 使用者的信心, 興趣跟習慣已經慢慢出現了.

2. 故事性: 這兩款遊戲, 雖然絕大部分做的事情都很類似. 就是擊敗敵人過關. 但是他們都有設定一個更大的故事架構. 讓每一關之間都是有些故事上的關聯. 而且過關的『獎勵』就不單只是虛寶上的獎賞, 還有故事上的進展. 而關卡又跟故事有些關係. 這一點對於增加遊戲性的幫助蠻大的. 這一點Candy Crush雖然也有一些琢磨(每一段的關卡都是在解救某些角色). 但是沒有那麼這兩個遊戲這麼強烈.

3. 平常活動: 玩遊戲最怕的事情之一就是卡關. 而且當一直重新闖關, 是唯一可以做的事情的時候. 蠻多使用者應該會在嘗試數次(或是數天)後過不了關而喪失興趣和信心(因為玩遊戲應該要帶來快感而不是失落感). Candy Crush這一點老實說做的不算太好. 在我還有在玩的時候, 印象中只有在某一個階段遇到連續登入幾天, 每天都會送一些寶物. 但是絕大部分, 都得靠自己或是孔方兄. 這一點一代宗師跟神魔之塔就做的比較好. 除了主線的過關劇情之外, 他們都加了不少支線或是小活動. 而這些支線或是小活動過關的獎賞都會對主線有幫助. 而且這些支線跟小活動通常每天都可以玩. 這對那些在主線卡關但是對於過關都還有一線希望的玩家會很有吸引力. 所以我自己在這些支線跟小活動上都花了不少時間:Q

4. 限時活動 & 主動通知: 這一點是我要特別讚賞神魔之塔這款遊戲的點. 雖然一代宗師也有限時活動. 但是可能因為這些限時活動需要玩家們彼此之間的互動. 所以最後他們設定成每週或是每天特定時刻舉辦這些活動. 這一點神魔之塔在設計這些限時活動的時候就聰明許多. 神魔之塔的一些限時活動, 會選定在每天不同的時段舉行. 雖然每天會公告. 但是有多少玩家會仔細閱讀跟記得呢? 所以這個時候神魔的主動推播提醒功能就很有吸引力. 這也讓他們賺到了每天至少兩次跟使用者產生互動的機會.

5. 社群: 社群功能幾乎是手遊必備的特色之一. 只是怎麼做才好才黏人. 其實還蠻各憑本事的. Candy Crush在熟悉朋友之間的社群功能做的很好. 而一代宗師和神魔之塔則是在陌生玩家之間的社群做的很不錯. 而這兩個遊戲的社群功能又各自有自己的特色跟玩法. 一代宗師採用的是比較像線上角色扮演遊戲玩家們的公會路線. 在遊戲中可以成立聯盟. 聯盟本身有第3點提到的平常活動. 讓玩家賺取過關需要的資源. 而且聯盟間又會有互動發生. 所以儘管玩家之間1對1的互動不一定會非常多, 但是因為聯盟的設計而帶來的隱性玩家互動. 這樣的設計我覺得有達到增加遊戲性和玩家黏性一魚兩吃的效果. 神魔之塔則是在陌生玩家之間的1對1互動上做的比較好一點. 而這一點是建立在遊戲規則設計上. 因為玩家之間主要角色功能上的互補. 所以玩家在要過某些關卡時, 會被半逼著去找到適合的"戰友"去協助過關. 不過有趣的地方是, 這種規則上產生的玩家互動, 更多時候是發生在遊戲攻略網站上而不一定是遊戲程式本身. 像神魔的攻略網站上就還蠻多玩家主動公佈自己的id和角色等級還有在找什麼樣的夥伴. 這也是社群功能設計很成功所產生的結果.

以上是一些這一段時間玩了這兩款手遊的心得. 除了記錄給自己看以作為Flirq之後改版可能的參考之外. 也希望有inspire到一些路過的讀者. 如果剛好對遊戲設計很熟的朋友不小心看到這篇. 就當我是野人獻曝囉. :)

Friday, August 30, 2013

Notes for CakePHP schema tool

最近要動到Flirq的database schema. 趕快來kk CakePHP的schema tool. 看起來挺簡單的.
基本上我需要的動作就是

1. 先在開發環境裡的mysql裡把DB的結構改好
2. 跑 cake schema generate
3. 因為之前已經有了 schema.php, 所以這個時候會問說是要 overwrite還是 snapshot
4. snapshot主要是讓你可以對schema.php做版本控制. 不過都已經用了版本控制系統了. 所以就overwrite吧!
5. 等要上線上環境的時候. 在線上機器跑cake schema update
6. 這個時候會跑出將會做哪些DB結構修改的指令確認. 檢查一下沒問題就可以讓它下去跑囉.

現在這些framework都提供了不少好工具. 不過使用上還是得注意就是了. :Q
以下是已經不小心踩過的雷, 記錄一下
1. CakePHP的schema tool不支援big int. 只會用int來處理. 一般int已經可以存很多東西. 只是如果存到facebook id. 恭喜你, 記得手動去調DB結構.
2. CakePHP的schema tool預設是只會掃有model file的DB table. 所以schema.php裡的table數目跟實際DB裡的table數目不同, 或是發現有些table沒被改到也不要覺得奇怪. :p 可以加 -f 解決這個問題.

Tuesday, August 27, 2013

Some thoughts about mobile ads

Facebook最近一季的財報中, 行動廣告的獲利跟佔營收的比重都有很可觀的成長. 看完了相關文章加上最近的一些經驗後有些感想. 趕快記錄一下.

1. Facebook在行動廣告上的漂亮表現, 這跟Facebook做對了Facebook nobile app上的"原生廣告" (Native Ad), 加上mobile app產業還在高度成長有關(Facebook nobile ad的主要客群之一是app發行商). Facebook mobile app上的使用行為基本上就是不斷的scroll跟按like. 而且使用者為了滿足目的(怕無聊+不想遺漏朋友的資訊)會讓他們更願意scroll. Facebook mobile app的native ad就是建立在這樣的使用行為上, 在不太破壞使用者經驗(幾篇朋友的post之後出現了一則長的很像post的promoted post或是mobile app install ad), 加上轉換動作還算簡單(可以like該篇post, like該粉絲團, 或是去App Store/Google Play下載該app). 讓Facebook有了這樣的好成績. 不過光靠app發行商的廣告是不夠的, 怎麼樣才能讓可能的廣告主變多? 這會是Facebook的下一個大課題. 但是動作很快的Facebook其實也已經在做這方面的實驗了. 除了之前的Facebook Offers(不確定可不可以在mobile app上使用, 但是這是Facebook想要把廣告機會拉到實體商家上的一大實驗). 最新的嘗試是跟mobile payment相關的實驗. 透過跟Facebook的整合, 行動購物app可以簡化使用者check out的流程(主要是shipping跟payment的資料輸入). 這項服務被視為Facebook要把mobile ad拓展到行動電商的第一步. 這一塊如果被Facebook做起來了, 那Facebook的mobile ad revenue爆發力相信會更驚人.

2. Google靠Web上的原生廣告(關鍵字搜尋結果旁邊的廣告)成為了Web廣告霸主. 但是行動裝置上對的原生廣告是什麼? 該怎麼做? 感覺Google還沒有好的頭緒. 我個人認為是Google還沒有掌握一個在Mobile上很關鍵的服務的關係. 加上在行動裝置上搜尋的目的以及行動裝置上廣告可視空間的差異. 這讓Google在行動裝置上的廣告會受到很大的影響. 不過, Google在行動裝置上雖然還沒有任何一個可以直接跟Facebook mobile app比拼的服務. 但是Google幾個主要產品 - 搜尋/地圖/Youtube, etc. - 應該還是有機會在調整使用者經驗以及廣告內容後把廣告營收拉起來. 比如說, 在智慧型手機上的搜尋結果可以考慮捨棄換頁而用scroll到底就自動載入其他結果的顯示模式, 配合上把廣告打散在搜尋結果中而不是只放在結果最上方/下方. 這樣或許更適合智慧型手機的操作經驗. Google Map也有一些可以玩的空間. 比如說在路線規劃結果後出現"叫車"服務(e.g. Uber? 反正都投資了這麼多錢了:p). 或是如果使用者搜尋的是比較一般性的關鍵字(e.g. 餐廳/咖啡店, etc.)而不是特定店家的名字. 這個時候就可以是出現餐卷/團購等廣告的好時機. 總而言之, 行動廣告這一塊Google還沒做得太好, 但是調整一下, 機會還是很多.

Google Adwords to drive app download? (Continued)

在幾經波折之後(主要是帳號被審核, 客服來信要我補資料證明帳號沒有被hacked XD), 廣告終於上了. 但是上了之後才發現結果沒有我想像中的理想跟美好. 本來打的如意算盤是, 在手機搜尋結果裡都沒出現廣告的關鍵字, 因為競爭比較不激烈, 所以CPC應該不貴? 但是沒想到讓系統自己bid的CPC比我想象中的高不少. 而自己期望的CPC價格又沒辦法讓廣告出現. 看樣子這條路不是我想像中的捷徑. 得要再找找看別的路了. :Q

Wednesday, August 21, 2013

Google Adwords to drive app download?

上禮拜去101聽了Google Adwords Challenge的分享, 席間忽然想到還沒試過用Google Adwords來宣傳Call Saver客服省錢通. 畢竟應該還是會有不少人用手機搜尋Call Saver裡目前已經蒐集的各大公司客服電話. 如果能夠在手機搜尋結果裡有Call Saver的下載連結, 說不定會有些不錯的效果?

Anyway, 剛剛照著 https://support.google.com/adwords/answer/2549053 試著建立了兩個Ad. 過幾天再來看看效果如何. :D

Thursday, July 25, 2013

Please use QR code right

因為最開始創業時的點子跟QR code有關, 所以一直都還蠻注意QR code的市場發展. 在路上看到有QR code都會看看到底這些QR code是怎麼被使用的. 最近在台北捷運站裡和車廂裡看到越來越多廣告使用了QR code. 雖然不確定有多少人會去掃瞄那些QR code. 但是看到有越來越多廠商肯試著使用QR code來傳遞更多資訊. 還是蠻開心的. 不過蠻多廠商在使用QR code的時候, 都沒考慮到實際的使用情境. 或是對於QR code不是很了解. 所以出問題的情況還蠻多的. 以下就是我最近的實際經驗.

昨天在公館站等車的時候, 看到了站內有四個廣告有用QR code, 心血來潮就想來測試一下這些QR code. 很可惜的是, 四個廣告裡面有三個廣告在使用QR code的時候都出了一些包. 這些廣告都是在月台上可以看到的燈箱廣告. 而我在測試的時候, 首先是盡量站在QR code的正對面. 如果能夠掃瞄得出內容, 會試著側移一些. 測試有點角度的情況下, 能不能掃描的出來. 距離上的話, 都是站在月台的黃線後方. 腳尖盡量貼齊黃線. 而QR code辨識軟體用的應該是最多人下載的Barcode Scanner. 手機是某牌的機皇. 所以我想每個廣告的測試基準應該還算合理且接近才是. 我自己給這些廣告使用QR code的正確度排名如下:

表現挺好的第一名: 

表現都不好的並列第二名:

完全不用懷疑的第四名:


我們就直接從問題面跟可能的解決方案來討論, 而不一個個廣告挑出來講. 第一個是QR code本身大小的問題. 我粗估我離這些燈箱廣告有4公尺 (淡水線車寬有3.2公尺). 而QR code scanner通常是沒辦法zoom in的. 所以QR code不夠大, 基本上就已經別玩了. 第四名最直接的問題就是大小. 要能夠掃描出這個QR code的距離太危險了XD. 第二個問題是並列第二名的兩個廣告都犯的錯誤, 就是把兩個QR code擺的太近. 上面那個, 我可以掃出右邊那個獨立的QR code (連到他們的粉絲團), 但是左邊那兩個相鄰的QR code. 我怎麼掃都掃不出結果. 而下面的廣告中裡面的兩個QR code. 我怎麼掃都只會掃到左邊的那個iPhone版本的連結. (我用的是Android Phone~~只能掃到iPhone的連結我也不能下載啊~~) 這兩個廣告的QR code都犯了太接近的問題, 而且從code的圖案就能看出來, 這些QR code的內容都太複雜了. (所以都密密麻麻的). 這就是第一名勝出的原因. 大小, 複雜度都適中. 所以很容易就掃出結果. 而且稍微有點角度也掃得出來. 

這幾個廣告如果不是擺在月台牆壁上的位置, 可能都不會有太大問題. 這也點出了使用QR code時第一個要考量的點: QR code會在哪裡被看到? 看到的人離這些QR code最近的距離可以有多近? 這些問題的答案會影響到QR code該有多大. 再來可以想想的點是QR code內容的複雜度. 從上面的例子來看, 可以看得出來第一名的QR code, code裡帶的資訊量最少. 掃出來的結果也是. (內容是http://www.xxxx.tw格式的網址). 第二名上面那個廣告裡能夠被掃出來的QR code看起來也沒有很複雜. 內容是他們的粉絲團網址, 格式是http://www.facebook.com/xxxxxxxx. 掃不出來的兩個相鄰QR code, 就複雜了些. 加上他們自己又在QR code裡加了圖案, 這會使QR code的辨識容錯率下降. 掃不出來也不會很令人意外. 第二名下面的那個廣告, 從QR code就看得出來. 內容相當的複雜. 掃出來的結果也完全符合我的推測. 是那種帶了一堆參數的URL. 就不在這邊打出來給大家看了. 除了第一名的QR code因為資訊量已經很少了, 其他的QR code我都建議可以改用短網址+轉址的方式生成一個夠短的網址, 再用這個網址去生QR code. 這樣的QR code, 對於QR code的大小還有加入其他圖案的容錯空間都會大一點. 而且因為轉址的關係, 更能有效追蹤掃瞄的人數. 而有些短網址+轉址服務還可以判斷手機類別. 直接轉到對應的下載連結. 這樣還可以省一個QR code. 算是一個還不錯的解決方案.
註一: Call Saver客服省錢通名片的QR code目前就是用這種方法.
註二: 這個方法在Android上會遇到一個問題. 就是透過轉址的話, Android不會直接把使用者帶去Google Play的App裡, 而是會跳出要使用者選擇要用哪個App開啟該網址的畫面. 這個時候可能會損失一些使用者. 

Call Saver的QR code

雖然有這些錯誤, 但是就像我一開始說的. 很高興看到越來越多廣告整合了QR code. 希望這些錯誤在新的廣告裡不會再出現, 更希望QR code能夠在台灣有更多更好更有趣的應用. :D 

Mobile App User Acquisition Experience Sharing: Facebook Mobile Ad

最近回創立方跟其他也在做Mobile App的朋友交換經驗的時候發現, 其實大家對於怎麼在Facebook Mobile App上打廣告不是很熟. 剛好之前有試著用FB Mobile Ad宣傳Call Saver客服省錢通的經驗, 加上要在創立方8/1的Pick'n'Mix裡分享一些Call Saver客服省錢通的宣傳推廣經驗. 所以就趁這個機會分享一下如何下Facebook Mobile Ad. 供對Facebook廣告操作有基本認識然後有興趣利用Facebook Mobile Ad宣傳自己的App的朋友做參考. (如果完全沒有下過Facebook廣告的人, 建議先去看看相關的文章)

第一步: 新建一個Facebook Application
先到 https://developers.facebook.com/apps 去建立一個Facebook Application (如果還沒註冊成Facebook Developer的話, 請先註冊成developer. 而怎麼註冊成Facebook developer? Sorry, 這不是這一篇文章要涵蓋的部分. 就請照著Facebook的指示註冊囉)

新建Facebook Application的畫面如下.
(App Name, App Category請照你的App屬性填入)










第二步: 填入Facebook Application細節
完成第一步之後, 應該會看到以下畫面



















我這篇是以Native iOS App作為例子. Sandbox Mode的設定我不確定在Mobile Ad上會有什麼影響. 不過既然App已經上架了, 所以我想把Sandbox Mode關掉了應該沒錯. :)


Native iOS App的設定展開後會長上圖的樣子. 把Bundle ID跟App Store ID填一填. (Facebook Login該填什麼?就看你的App囉) 就快要可以上路了. 為了怕填錯資料. 可以點一下Go to iTunes Store, 看看會不會正確帶你到你的App在iTunes Store裡的頁面.

*Android的設定也很類似, 只是改成填Package Name跟Class Name. (Key Hashes的話就要看你的App有沒有用到了. 沒有的話就空着就好).

第三步: 新建一個Facebook Ad
第二步搞定後. 就可以來幫你的App建廣告囉! Facebook的footer有一個Create Ad(刊登廣告)的選項. 或是右上角個人設定的地方也可以找到建立廣告的連結. (如下圖)

完全沒建過Facebook廣告的人, 看到的畫面可能會有些許不同. 但是我想應該不難找到對的連結才是. 

在點選了連結之後, 會看到下面這樣的圖

在Applications那邊, 應該會看到第二步完成後建立的App. 點了進去之後. 剩下的步驟就跟一般建立Facebook廣告差不多了(基本上就是設定好Target Audience族群). 所以步驟細節分享就到此為止.

聽說Facebook有提供SDK, 幫Mobile App Developer去計算出CPI (Cost Per Install). 我沒有研究到這麼深. 所以是用簡易法去計算User Acquisition Cost. 就是先抓出在廣告前的每日平均下載數, 再看看廣告期間的每日平均下載數. 再用Facebook收了我多少錢去除增加的下載量. 我自己操作近一個禮拜的數字算起來. CPI大概是3 NT. 這個實驗是在2013年6月初做的. 目前為止應該還沒有漲價太多. 所以目前來講, FB Mobile Ad應該還算蠻值得試試的一個宣傳管道.

最後, 還是要來幫Call Saver客服省錢通打個廣告. 還請大家多多支持啊~ (App宣傳不容易啊~)

PS. 最近因為想下FB廣告出了點問題, 所以仔細看了一下說明文件. 發現要下FB Mobile Ad可以更簡單. 不需要走過以上整個流程. 只要照著 https://developers.facebook.com/docs/tutorials/mobile-app-ads/ 裡面的Get started quickly過程就夠了. 

Thursday, July 18, 2013

Happy Problem

最近Flirq客服收到了不少說要關掉帳號的客服信. 令人高興的是這些使用者關掉帳號的原因多是因為找到了對象, 所以再也不需要使用Flirq的服務而關. 很高興Flirq能夠幫這些人找到理想的對象. 希望之後這樣的客服信會越來越多, 也很希望很快就會收到有Flirq使用者要結婚, 然後來跟我們分享喜悅的email! :)

Thursday, April 4, 2013

Revenue Models - Gaming

這系列最後一篇文章是關於Gaming, 正如Fred自已說的, Gaming已經自成一個很有趣的生態系統. 裡面已經很非常多有趣的而且很可能只有在Gaming這個生態系才有機會的revenue models. 文章裡列出來的models有點多, 這邊就不條列出來. 有興趣的朋友可以到這邊看https://hackpad.com/Gaming-pjp2LsfpGaz

簡單來說, Gaming這一塊也是靠purchase, advertising方式來創造營收. 不過現在很流行的方式是販售能夠增加遊戲趣味的virtual goods (虛寶). Fred他說他很期待這個方式在其他非Game的應用上出現. (雖然這一種方式其實在一些SNS裡面已經出現過, 像FB或是一些交友網站上都有出現過囉)

Revenue Models - Mobile

Revenue Models系列的文章, 很快的就來到了最後兩個主題. 不過這兩個主題其實都不能真的算式Revenue Models, 而比較算是兩個有著有趣的revenue models的產業. 第一個是Mobile

Mobile的revenue models簡單來講可以分成下面幾種. (來源: https://hackpad.com/SNtzG3izJ2b
Paid App Downloads - ex. WhatsApp
In-app purchases - ex. Zynga Poker
In-app subscriptions - ex. NY Times app
Advertising - ex. Flurry, AdMob
Digital-to-physical - ex. Red Stamp, Postagram
Transactions - ex Hailo

不過Fred把這些分類成三大種類(app purchases, advertising, and transactions), 雖然app purchase目前可能是最大的一塊, 但是他認為app purchases將來會是這三大分類裡面最小的一塊. 他覺得transactions會是最有趣的一塊(舉例來說: mobile ticketing, 換句話說, 就是mobile跟生活的結合更緊密). 而advertising則需要更創新的廣告方式, 不能照著以前那種使用者經驗不夠好的廣告方式. 

我很同意這advertising跟transactions有很大而且很有趣的機會. 不過我自己覺得他低估了app purchase的那一個市場. 以revenue總量來說, 或許app purchases之後不會有另兩塊來的大. 但是以profits跟成功機會來講, app purchase還是很有吸引力的囉!

App Store App Update Process

最近因為side project Call Saver 客服省錢通的關係, 比較常需要跟App Store打交道. 但是目前就只有一次上傳全新app的經驗, 而且忘了把步驟記錄下來. 所以只好先記錄升版app上傳的步驟, 以供自己或是其他人參考. 下次有機會上傳全新app的時候, 再把所有動作記錄下來. :Q

Anyway, 以下是幾個上傳app升版binary的步驟


1. 到xcode的project setting裡改版本號碼 (Version & Build)
2. 到xcode的edit scheme裡改build configuration還有選擇要build for iOS Device
3. build
4. 到xcode的project navigator下方products裡找出binary (應該會在Release-xxxxxxx目錄下)
5. 壓縮binary (zip格式, 檔名最好不要有中文)
6. 到itunesconnect.apple.com, 點進要升版的app頁面裡選add version
7. 填好版本資料和升版內容
8. 點選右上角ready to upload
9. 填完問卷
10. 用application loader將binary上傳即可 (這邊可能會出現不同的問題就是了 :p)

Monday, March 18, 2013

Revenue Models - Data

Data (資料) 是一種有趣的網路獲利模式. 照原文中Google董事長Eric Schmidt的說法, 現在每兩天產生的資料就相當於"人類有文明以來"到2003年所產生的資料. 以這種資料產生的速度來看, 如果有辦法利用資料產生獲利, 將會是很有趣的一種獲利模式.

Fred把這種獲利模式分成兩大類, 第一類是以收集彙整資料再賣出為主, 第二類是利用服務產生屬於自己的資料再從中獲利. 他認為第一類的模式比較危險. 因為很容易被取代. 第二類的模式就是目前Twitter, Facebook正在使用的模式. (只是從中獲利的方法目前看起來是原生廣告).

另外, Fred建議如果是走第一種模式. 以API的方式讓人存取收集彙整好的資料是比較好的方法. 因為這讓你的使用者比較沒辦法離開你. 還有, 如果能夠讓你的資料變成一個更大的生態系統的一部分, 這樣會讓你更有競爭優勢. (可惜沒有舉一些例子來給大家參考)

Revenue Models - Licensing

Licensing(授權)是這次的主角. Fred認為Licensing是最不網路原生的模式. (但是在傳統桌上型軟體業還是主流).

我想或許是跟授權這種模式在搬到網路上後很難有效的估量每個授權單位該收多少錢還有網路軟體服務本身的revenue model也開始轉變有關. 傳統的授權模式, 大多是跟"可見的產品"綁在一起. 就算是軟體, 也是一套套的算. 因為傳統桌上型軟體大多還是"一盒盒"的賣. 另外, 在網路世代, 很多軟體已經轉形成Saas模式, 通常都是以付月租費為主而不是傳統的一次買斷. 所以才會有Licensing是最不網路原生的獲利模式.

儘管如此, Fred提到了Open Source License是一個可以注意的模式. 雖然怎麼獲利並不明顯. 但是卻可以利用社群的力量幫忙讓本身的產品更好. 我自己覺得, Open Source License是一個有趣的方法. 可能不容易透過Licensing這部分直接獲利, 但是可以想想怎麼利用這種方式設法加速自己的產品開發速度還有讓開發成本降低.

Revenue Models - Transaction Processing

一轉眼, 這一系列的文章就欠了好多篇. 今天趕快來補一下. 這次的主題是Transaction Processing. 簡單來說就是抽"手續費". 雖然Fred提了幾個例子說, Transaction Processing可以應用在幾個不同的領域裡, 不過看起來最主要的還是在金融相關服務.

總的來說, Transaction Processing最大的挑戰是如何衝大交易量. 因為單筆手續費不可能收太高(不然大家就不用了), 但是在提供這些交易的解決方按時往往又有一筆不算小的固定成本要支出. 所以在交易量沒辦法衝出來的情況下, 這個revenue model是會虧錢的. (謎之音: 量衝不大就會虧錢, 這句話幾乎可以套在絕大多數的revenue model上啊XD)

Saturday, March 9, 2013

Impressive Facebook Fanpage

前幾天不小心看到了一個朋友分享了幾篇來自一個粉絲團的文章. 心血來潮點了過去看看. 馬上對於這個粉絲團產生了極大的敬意和興趣. 敬意是這個粉絲團的各方面數字都很漂亮. 50萬上下的粉絲數, 超過60萬人在討論這個粉絲團. 幾乎每一篇都至少有上百個分享跟上千個讚. 印象中沒看過其他台灣的粉絲團有這麼令人印象深刻的數字. (通常是粉絲很多, 但是活躍度沒那麼高)

研究了一下這個粉絲團為什麼有辦法衝出這樣的數字. 就對這個粉絲團充滿着興趣. 以下是我自己的一些觀察跟猜測.
- 粉絲團名稱. 這個粉絲團的命名跟包裝很聰明. 從名字來看, 像是某個名人的粉絲團. (在粉絲團剛成立時, 也真的有放了幾張這個名人的照片. 以增加"公信力"). 我個人認為, 這對於大家加入跟分享文章的意願都會提高.
 - 每篇分享都會放上很漂亮的圖. 這再次證明FB粉絲團上要用圖吸引人的目光. 至於文字的部分, 大多是一些"有感而發"類的文字.
- Po文的數量跟頻率非常驚人. 這個粉絲團大概每10~20分鐘就會po一篇文. 本來覺得這樣可能不是件好事. 但是後來想想這可能是應付FB調整post sorting algorithm後最好的方法. 以量來衝文章被粉絲看到的次數. 每一篇文章不會被所有粉絲看到, 但是夠多的文章就還是有機會增加整體看到文章的粉絲數.
- 這個粉絲團的目的? 有仔細看一下這個粉絲團除了po文之外的行為, 會發現這個粉絲團很明顯的不是那個名人的粉絲團. 舉例來說, 這個粉絲團like的其他粉絲團都是遊戲.... 所以看起來還是跟商業宣傳有關.
- 至於做了哪些商業宣傳呢? 這點就是另一個我覺得他們非常聰明的地方. 這個粉絲團一開始並沒有作任何感覺起來像是商業宣傳的動作. 後來開始偶爾"轉載"一些其他粉絲團的文章. 但是最讓我印象深刻的是最近的調整. 他們開始宣傳遊戲了. 但是宣傳的方法也非常的"隱晦"...但是感覺使用者會點選的機會很高. (細節就不在這邊說了...有興趣的可以私下問). 不過不確定多久之後會造成粉絲的反感.

這個粉絲團大概是我最近看過最有趣的粉絲團操作案例. 很好奇後面幫忙操作的團隊是誰. 真的是很會『搞』囉!

Monday, March 4, 2013

Interesting side project: Call Saver



一轉眼就三月了, 欠了不少東西要寫. 不過農曆年後第一篇文章要獻給過年後跟友人W推出的手機App: Call Saver 客服省錢通. 點子很簡單, 打客服電話為了要跟真人通到話, 常常都需要聽很多語音訊息輸入很多代碼. 所以我們收集了很多常用的客服電話跟代碼, 然後讓手機幫我們輸入. 這樣可以跳過很多語音訊息, 省掉很多等待的時間. 有興趣的朋友可以去下載玩玩

下載 Call Saver 客服省錢通
Android, iPhone: 送審中.

Sunday, March 3, 2013

Enjoy being sick!

今年過年本來想利用這個假期完成一些side projects的,沒想到在初一晚上襲來的一場重感冒完全打亂了原本的計劃。雖然來的又突然而且症狀還挺嚴重的(老婆說沒看過我感冒這麼嚴重過XD),不過因為近兩三年透過書籍和朋友的介紹,接觸到了一些比較屬於自然療法的醫療觀念。還蠻符合自己對於"身心健康"的想像的,所以有盡量試著在生病的時候依照一些自然療法提倡的理念來照顧身體。因此這一次的重感冒,我就把他當做了另一次和身體對話的好機會。

感冒的徵狀大約從初一晚上開始出現。首先是喉嚨痛,再來慢慢出現乾咳,頭痛/頭脹,額頭微燒,四肢無力,到最近兩天開始出現的鼻涕跟痰還有鼻塞。再再反應了身體的自我療癒機能正在努力的運作中。所以我也就順其自然的讓他自己發揮,而不像幾年前只要有感冒症狀的第一個反應就是先克一顆感冒膠囊。雖然整個"療癒"過程可能不會有像感冒膠囊一樣的速效,但是趁這個機會好好感受一下自己身體運作的感覺挺好的。

大概也就是這樣心態的改變,所以以前只要是身體一有不舒服,就會覺得很麻煩,只想要用藥物趕快解決掉"麻煩"。但是現在還蠻能正面的看待整件事。雖然說常常還是沒有好好照顧他,不過現在至少比較肯聽聽他的"反應",也比較能享受"感受"他療癒的過程囉!

Revenue Models - Peer to Peer

之前在寫這系列讀書心得摘要第一篇時提到, 不知道該怎麼翻譯或是解釋這個Peer to peer的營收模式才好. 但是看了文章之後, 發現還是很難用很簡單的一個詞或是一句話來解釋. 不過這大概也是因為這個模式算是因為有了internet才有機會做的模式. 所以中文還沒有一個特別好的對應. Anyway, 讓我們來看看這個模式. 

Fred對於這個模式的定義原文是: They connect one or more people together to conduct a transaction and take a fee for doing so. 看到這邊, 有人可能會想說, 那這跟之前在commerce裡提到的market place有什麼差別. 我自己是覺得差不多. 因為這些模式本來就很難完全的分清楚.

所以我自己覺得這篇對我來說最重要的點是: internet這個媒介讓這個model變成可行的一個model. 因為internet的關係讓交易量有機會可以變的非常大的緣故, 讓這個透過只收交易手續費而不用固定收"上架費"或是定期收"櫃位費"之類費用的模式存活甚至於成功. 這一點是傳統實體賣場/百貨公司不大可能做到的情況. 

不過這種模式最困難的挑戰還是怎麼樣讓供跟需兩端的"peer"做適度和平衡的成長. 因為不會有人想到沒有店家的賣場也不會有店想進駐沒人來的賣場囉. 

Revenue Models - Subscriptions

一轉眼就一月下旬了...也是該來補補這個系列文章的"讀書心得"的時候了:p
這次的主題是我本身最期待的主題: Subscriptions. (因為Flirq預期的主要收入來源就是subscriptions). 讀完之後有點點小失望. 沒有看到太多新的insights. 但是還是有些有趣的點可以記錄一下.
1. Subscriptions可以用在很多產品/服務/內容上. 舉例來說, SaaS 就是一個把軟體從傳統"販售使用授權"模式轉成subscriptions模式的例子. AWS則是把infrastructure變成subscriptions model的例子. 其他例子還有像是數位內容(ex. Video: Netflix, Music: Spotify, KKBox). 雖然Fred這邊沒有提到, 但是全世界主要的網路交友服務幾乎都是靠Subscriptions模式在產生營收(ex. Match.com, eHarmony.com).
2. Freemium (讓使用者免費使用基本服務, 然後提供一些付費功能把免費使用者轉換成付費使用者這種模式) 這個詞是在Fred這個blog裡"出生"的...:p
3. Subscriptions模式的一大挑戰之一是"使用者流失". 因為要維持"穩定"的營收, 代表了流失多少付費使用者就得補進多少新的付費使用者(當然前提是不調價, 不過調價雖然會增加ARPU但是也會流失不願意付新價錢的使用者. 所以有得有失). 這一個挑戰也會是婚戀交友網站最大的挑戰. 婚戀交友做得好的最終結果是使用者找到好對象就不會再回來. 這點雖然沒錯, 不過這是建立在"網路婚戀交友"這塊餅完全不會成長的情況下. 我相信只要我們能夠把服務做好, 雖然看起來"成功的使用者"不會也不需要再回來. 但是因為他們的成功幫忙帶來的新的使用者是有機會把這個市場做大而支撐起成長.
4. 因為可預期性跟穩定性, subscriptions是"傳統三大Revenue Models (advertising, commerce, and subscriptions)"裡最有吸引力的模式. 不過也會是相對需要一些時間跟資源來醞釀營收成長動力的模式. (謎之音: 就是要撐下去的意思 :p)

See things in big picture

忘了是怎麼不小心看到這篇blog, 因為對於歷史一直有著一份興趣, 加上在網路上看過不少對於"史實"的辯論, 所以對於這種對"我們自認為熟知的近代史"提出不同觀點和論點的文章很感興趣. 所以當作者出了"橡皮推翻了滿清"之後, 馬上去買了一本. 只是一直拖到新年假期才開始看. XD

整本書從世界史+當時世界政局/經濟變化的角度來看中國近代史. 檢視了很多過去過度被簡化跟美化的歷史事件的起因跟結果. 讓人看了停不了手. 看完之後有一個很大的感想, 就是我們得學習用更高更全面的角度來看事情. 這樣才有機會把看似無關但是其實是有關聯的事情串連在一起. 比如說, 中國茶葉跟美國獨立之間的關係? (這邊就不破梗了, 讓大家好好從書裡享受歷史事件連接起來的快感)

2013 Fortune App

這個是Flirq最近上的一個Facebook App: 2013運勢剖析. 趁這個機會練習練習寫FB app. 學到了不少東西, 希望下次寫起來會更快.

Revenue Models - Commerce

一轉眼2013就到了. 在這新年的第一天祝大家新年快樂!

 

趁這新年的第一天, 也是連假的最後一天, 來看一下Fred Wilson的Revenue Models第二課: Commerce .

e-Commerce可以說是一般人最容易懂而且也是revenue model最"清楚"的網路產業. (不過不代表好做:Q) 只要任何在網路上交易實體商品的行為都算是在這個範疇. 不過Fred還是把它分成了下面幾個大類.

零售(retailing): 進貨來賣. Amazon (雖然我自己覺得Amazon已經不單屬於這個範疇很久了:p). 最大的問題是利潤.

交易市場 (marketplaces): 提供平台讓人交易. Fred沒提供例子. 基本上那些讓大家很容易在網路上開店的電子商城網站都屬於這個類別. 看樣子前一篇的peer to peer跟這個類別有點關係. Fred沒提到marketplaces的問題. (大概是會在他的另一篇專門寫相關議題的文章裡會提到?). (但是這一個類別最大的挑戰是大家常提到的"雞生蛋, 蛋生雞". 要有夠多的買家,賣家才會想來. 要有夠多的賣家, 才會有足夠的商品, 買家才會有興趣來. 怎麼解決這樣的問題通常是這個類別最大的挑戰. 雖然Flirq不是commerce, 但是交友算是一種marketplace...所以我了解這邊的痛XD)

垂直整合零售(vertically integrated retailing): 這個跟零售最大的差別是不需要跟任何人進貨. 因為是自產自銷. 好處是利潤比一般零售高, 但是得想辦法建立出自己的品牌跟知名度. 使用者才會來. 例子有 Warby Parker (一家專賣自家出的高級流行眼鏡)

限時/限量販賣(flash sales and daily deals): 這個類別最大的問題是貨源怎麼來跟維持. 例子有Vente-Privee (另一個例子是Gilt). 雖然這個類別叫Daily Deals. (Fred沒有把Groupon放在這邊, 因為Groupon是被分在一個沒有被拿出來討論的類別, group buying裡.)

拍賣(auction): 這是最後一個被Fred特別提出來的類別. 最有名的例子當然是ebay. (這個類別跟交易市場最大的不同應該是"消費行為". 因為價錢是喊價喊出來的, 而商品的量也比較有限. 交易時間也會有限制. 這造成了消費行為跟交易市場上的消費行為不大一樣)

這一篇裡面Fred一直提出了margin(利潤)這個詞. 我覺得很值得從事相關產業的朋友想想. 看看internet是怎麼削弱了自己的margin, 又或是可以怎麼利用internet來保有自己該有的margin.

其他沒談到的commerce類別, 可以參考一下這份文件.

 

Revenue Models - Advertising

Fred Wilson的Revenue Models課程第一堂講的是Advertising, 也就是廣告. 

首先, Fred列舉了一堆目前可見的廣告形式 (可以參考此圖)

我自己覺得有些類別比較像是廣告內容以及技術的分類而不是廣告形式的分類. 不過這些廣告形式分類不是這一篇的主要討論. 這一篇的討論比較著重在用廣告當做revenue models時, 創業家要注意的事情. 比如說, 我們到底在賣的是什麼樣類型的廣告 (ex. 廣度 vs 精準, 靠sales去賣的 vs 線上自動販售) 和廣告費的算法(CPM/CPE/CPA/CPC/Sponsorship).

文章後半部提出了一些要注意的事項跟相關的數字(像是大概要多少impression才能撐起一家公司之類的數字). 我自己看完之後的感想是: 如果要純靠廣告收入撐起一家公司的營運, 可以先估計看看自己的business和所在的產業有沒有機會衝出那麼大的impression數字XD

還好Flirq從一開始就沒有打算靠廣告營收作為主要營收來源. :D

Fred推薦的參考資料  

Revenue Models

不知道是不是去美國都待在東岸的關係, 創業後一直對於東岸的VC有好感. (雖然大家都還是比較推薦西岸的VC XD) Fred Wilson 是其中一位算是一直有在follow的VC. 他十二月在他自己的blog上開始一系列關於revenue models的"課程" . 接下來有空的話, 會在這邊試著簡單翻譯跟做些筆記. 希望能夠對Flirq接下來的發展決定有些幫助. 有些太簡單或是很難找到準確翻譯的詞就不翻了.

廢話不多說, 今天就從他整個課程的第一篇開始: 目前常見的reveune models

- 廣告 (Advertising) - 免費/低價提供服務給使用者, 建立user base. 但是販售自己建立的宣傳管道給需要行銷/宣傳的人/單位做廣告.

- 電子商務 (Commerce) - 簡單來講, 賣東西. 但是有很多不同的賣法. 

- 訂閱 (Subscription) - 使用者定期付費才能使用你的服務. 

- Peer to Peer - 沒辦法想到很好的說法. 可能等他的討論文出來後再來想想可以怎麼一言以敝之.

- 交易處理 (Transaction Processing) - 幫忙處理各種交易, 透過手續費獲利.

- 授權 (Licensing) - 將技術授權給用得上你的技術的使用者

- 販售資料 (Data) - 販售你的服務生產/消化出來的有用資料

- Mobile & Gaming - 雖然這兩者都不是revenue models的一種, 但是課堂裡會拿出來討論這兩塊大餅的可能性跟挑戰. 

 

這些revenue models是怎麼決定的? 是Fred Wilson開了一個表讓大家去討論出來的. 最後版本的列表在這邊.

有人可能會問, 有些看起來很像耶. 這也是我的問題. 不過就來看看他的看法囉. :)

Always great to meet interesting people

上個禮拜在創立方的Pick 'n' Mix跟大家分享了我們幾個創立方的夥伴新加坡之行的經驗後認識了Schee. 對於短暫交談中, 他提到他的經歷非常的感興趣. 這個禮拜則是Schee變成了Pick 'n' Mix的主講人. 在活動中他分享了他怎麼看網路效應這件事以及分享更多了一些他相當有趣的經歷. 看到有人默默的(還是是我太孤陋寡聞XD) 為台灣這塊土地在做這麼多有趣的事. 很高興有機會認識一個這麼有趣的人!

The Last Millionaire

今天不小心在壹網樂上看到了BBC的The Last Millionaire節目, 節目內容簡單來說是"創業比賽". 這個節目把12個英國小有成就的創業家聚在一起, 每個禮拜在不同的城市和主題下兩兩一組的組隊白手起家創業. 每組都會有四個全天的工作天和基本的創業基金. 每個星期五就是比賽誰賺得多. 賺得最多的團隊就可以回家. 剩下的, 就繼續比下去. (這跟其他的比賽的邏輯通常是待越久越好不大一樣)

不確定裡面有多少的真實性(因為我都覺得很多reality show有點假:p), 但是對於創業上會遇到的問題(比如說, 夥伴合不合)倒是有不少有趣的記錄. 不過裡面最讓我佩服的還是這些人的行動力跟執行力. 以一個電視觀眾的角度, 會覺得他們好像做了不少錯事或是蠢事. 但是把自己放在那些人的角色去想像的時候, 大部份參賽者在四個工作天裡完成的事(不論最後成功勝出與否), 真的是很令人佩服的. 很建議有在創業的朋友看看這個節目.

Good is the enemy of great

這句話到底是誰先說的? 說真的我也不知道, 有人說是Jim Collins, 有人說是Jony Ives. 不過不管是誰說的. 只能說這句話非常有道理. 我們不能只追求"好", 因為一但覺得"好"就夠了, 就不可能變"偉大". 共勉之!!

Value of Flirq

(Image from Flickr's Light Through My Lense, used under CC license)

Flirq的價值是什麼? 我們對於Flirq希望幫我們的使用者們創造的價值很清楚, 就是幫助Flirq使用者在Flirq上能夠更有效的認識新的朋友, 進而找到人生伴侶.

可是對於怎麼更有效的創造這樣的價值? 老實說我們還一直在摸索. 這種在黑暗中摸索的感覺有點辛苦. 不過最近間接聽到一些Flirq使用者透過Flirq交到了男女朋友. 這給了我們很大的鼓勵! 因為這代表Flirq開始慢慢為了一些喜愛Flirq的朋友們帶來了價值! :) 我們會繼續努力下去, 希望能夠更有效幫大家創造更多的價值!

Penn's 2011 Commencement Address by Denzel Washington

 

前幾天看到的一段video. 是丹佐華盛頓2011年到賓州大學(UPenn)畢業典禮給的演講. 前面半段很搞笑, 但是後面講的非常精彩. 很多觀念跟看法都跟創業家該有的想法很接近. 值得一看! 

Attitude

昨天看到了以下的小故事, 非常有感覺. 特別記錄一下:

有人問洋基傳奇球星狄馬喬(DiMaggio): "你在大聯盟打了無數場比賽, 為什麼你每一場比賽都還要像菜鳥一般拚命?" 他這麼回答:"因為我知道每一場比賽數萬名觀眾裡, 一定會有哪個小孩是第一次來看我打球." 

Jin

週末老婆在看仁醫, 也跟著看了一下. 對於男主角"南方仁"在現代的女友跟他說的"上天不會給你過不了的考驗", 頗有感覺. 在此記錄一下! 

Thanks for the compliment

今天不小心看到我們之前想的Flirq Slogan"外表不是唯一, 交友從心開始" 出現在一個交友App的介紹裡. 這或許算是"英雄所見略同"? :)

MI4 vs Startup

今天不小心再看了Mission Impossible 4一次. 發現裡面阿湯哥這個"Team Leader"有很多想法, 還有他對於完成任務的堅持跟信念, 很值得Startup參考. 因為當連他的隊友都跟他說, This is impossible的時候. 他還是相信會成功, 也不斷的找方法讓任務成功. 真的很成功的把"Mission Impossible"變成了"Mission, Im possible!"

FLIRQ'S CHALLENGES - 3

Flirq上線後, 就比較難有時間寫blog. 今天來繼續寫寫Flirq的挑戰. 這個挑戰, 也不是Flirq獨有的挑戰. 不過這邊會跟大家分享一些我們計畫怎麼迎戰這個挑戰的想法.

網路交友有一個其他類型網站比較不會遇到的挑戰. 就是使用者比較不會幫你宣傳. 雖然時代慢慢在轉變, 但是大多數的交友網站使用者(中外皆然)通常還是比較不會特別跟自己週遭的朋友分享說: "我最近在玩一個交友網站, 超讚的! 你也趕快來一起玩." 所以怎麼找出能夠讓使用者幫你拉更多的使用者, 就變成成功成長使用者數量的關鍵之一. 幾年前, 一個常被利用的招數是"利誘"使用者分享他的聯絡人列表資訊(通常是從webmail裡import). 然後網站主動發信給這些使用者的朋友, 吸引/邀請他們進來. 更近幾年有些是利用Facebook的塗鴉牆來promote. 使用者的一舉一動, 三不五時就被post到他們的塗鴉牆上, 引起他們的朋友的注意再吸引他們來玩. 可惜這些招數在使用者也越來越重視自己跟朋友的隱私之後, 越來越不能用. 而且這些招數, 很多並不是使用者真心想推薦這個網站. 而只是被利用來幫忙宣傳. 所以其實真正能夠做出"口碑宣傳"的交友網站不算太多囉. 

而我們想到解決這個問題的方式是引進social features. 讓Flirq的使用者可以邀請朋友進來幫忙他交友. 這個是一個大方向, 實際做出來會有很多不同的功能. 但是主要目標就是希望讓Flirq不再只是一個想交友的人才能來玩的交友網站. 更是一個想交友的人跟想幫他的朋友都可以一起來玩的交友網站. 我們希望透過這些方法, 一來打破一般人對於交友網站的刻板印象 (不是只有要交友的人才能來) 也可以降低很多人加入的心理門檻 (因為可以是來幫朋友的). 希望這個方向能夠成功幫Flirq建立起跟其他交友網站不同的形象, 讓Flirq的使用者能夠幫Flirq做"口碑行銷"囉.

Discounted Tickets for CHINICT

不確定這邊的讀者有多少人會去參加 CHINICT (一個在大陸辦的Startup大型會議). 有一些看起來很有趣的講者. 我這邊有Discounted code, 有興趣的人可以從在買票的時候, 輸入code: CCTAIWAN  就可以有20% off囉. 

Startup = Always learning something new

MIT的校長說過"Getting an Education from MIT is like taking a drink from a Fire Hose". 現在在Run Startup的感覺也差不多. 一直都在學習新的東西. 不管大小. 就是一直像消防水管一樣, 停不下來的送過來. 今天又學到了一個小東西. 就是原來Gmail的收件人是有數量上限的. (請容我在這邊野人獻曝, 因為我之前真的不知道). 原來是今天要寄出通知信給之前預約註冊Flirq的會員. 跟他們說Flirq上線了. 結果沒想到copy & paste 名單到gmail的BCC列表要送出後, gmail的complain就跳出來了. 之前根本沒有機會遇到這樣的情況.(誰沒事會寄信給這麼多人, 看官你說是吧?). 一直到今天才知道有這樣的上限. 只能說, Startup, 每天都在學習新的東西囉! 

Flirq is online!

Flirq在3/30/2012的台灣時間晚上, 正式public beta. 公開上線了, 該開始訓練心理強度以接受使用者的使用反應跟加快對於這些反應的調整時間囉. 所以, 這不是個結束 , 而是個開始. 真正的挑戰, 正式到來! Fighting!

Flirq's Challenges - 2

Flirq出現的"時間點"是Flirq要解決的另一個挑戰. 網路交友已經不是新東西. 美國的Match/eHarmony已經經營了15~16年以上. 台灣目前的交友網站龍頭, 愛情公寓, 也已經要10歲了. 這些前輩網站都非常有他們的特色. 換句話說, Flirq怎麼做出跟他們不一樣的特色和市場區隔? 是我們一定要解決的一大挑戰. 我們目前的想法之一, 是建立一套不一樣的網路交友遊戲規則. 讓線上交友能夠更接近現實生活裡的狀況. 讓真心想認識新朋友的使用者, 能夠在Flirq設計的互動裡, 從"心"開始認識新朋友. 我們知道這不是件容易的事. 但也正因為這是件不容易的事. 才更需要有人試著去解決囉! 

Flirq's Challenges - 1

Facebook_icon20120311

(昨天收到我們設計師為了Flirq Facebook新作的Icon. 覺得很不錯. 今天就趕快拿來用一下囉!)

Flirq的第一個挑戰. 其實不是只是Flirq的挑戰, 而是所有交友網站的共同挑戰. 就是一般人對於網路交友的接受度. 儘管在美國, 網路交友已經成為了認識結婚對象的主要方式之一. 但是還是有很多人不願意去嘗試網路交友. 背後的原因有百百種. 我們知道Flirq不可能解決所有讓他們不肯使用網路交友的原因. 但是我們希望Flirq提供的新交友互動方式. 除了讓已經能夠接受網路交友的人有一個新的選擇之外, 也能夠改變一些目前不願意嘗試網路交友的人的想法. 讓他們肯嘗試網路交友. 進而找到好的異性朋友. 希望Flirq的出現, 能夠帶來些改變囉! :)

 

New Series: Flirq's Challenges

三個禮拜的Startup Labs活動告一段落. 總算又比較有點時間來寫些blog. 在Startup Labs的三個禮拜裡, 我們除了中文化Flirq之外, 也調整了一些遊戲規則. 目前正在進行封測, 跟修正一些封測使用者回報的問題. 很謝謝這些幫Flirq封測的朋友.

我們很清楚在這個時間點進入線上交友這個戰場, 不是件容易的事. 因為市面上已經有很多不同大小跟取向的交友網站, 更不乏各式各樣"類"交友網站. 不過創業遇見挑戰本來就是很自然的事. 而且設法解決不同的挑戰, 更是創業中的"樂趣"之一. 接下來會分享一些我們在做Flirq的時候遇到的或是預見的一些挑戰. 有機會的話, 也會順便分享一些我們的解決方法跟結果. 希望對一些也在創業的朋友有幫助! 

NTU Startup Day

今天去參加第一屆的NTU Startup Day. 遇到了不少星期五Startup Labs Demo Day上認識的台大學弟妹. 也看到了不少家很有趣的公司. 深深感受到了大家對於創業的熱情! 希望台灣這一波創業潮, 能夠出現更多家成功的公司. 為台灣的創業圈建立起更多模範跟打下更好的基礎! 台灣的創業家們, 加油!

Startup Labs Demo Day

今天是Startup Labs Demo Day. 給自己的表現85分. 該講的重點都算有講到. 裡面的梗, 聽眾該笑的也都笑了. 但是時間控制的不好. 超過了五分鐘的時限. 不過總算是順利結束. 22天的活動告一段落. 是個結束, 但是更是個開始. 趕快來好好睡個覺. 睡醒繼續前進! Fighting!

Flirq Slogan

今天吃晚飯的時候跟老婆在討論. 怎麼樣一句話表達Flirq的理念跟與其它網站的不同. 目前我們兩個人都最滿意的一句是: "外表不是唯一, 交友從心開始!" 很符合Flirq想要做的嘗試. 希望也能把Flirq的理念傳達給我們的使用者. 

Good mentors vs bad mentors

參加Startup Labs到目前最大的感想是: 好的Mentor帶你上天堂, 不好的Mentor帶你...

CakePHP i18n and l10n

最近為了要幫Flirq出中文版. 所以開始在研究CakePHP的i18n跟l10n. 這個link是CakePHP i18n跟l10n的說明. 整體上來講還算簡單. 但是中途還是會遇到一些有的沒的問題. 這邊記錄一下我實驗的過程. 基本上一開始要做的, 就是把ctp檔案裡, 會隨著locale改變的字串照著這個link裡的方式標記. 接著要做的就是到cake console去跑一個shell command把需要localize的字串都找出來. 跑完之後, 會跑出一個po檔. 再來就是自己create一些不同locale的folder. 然後把po檔丟到對的路徑下. 這邊要注意的是, 如果是要處理中文. 目錄名是chi (不能用zho). 另外, 用Poedit修改po檔內容的時候. 有一些CakePHP自己用到的字串不知道為什麼會造成錯誤(Sorry...沒有深入去研究原因). 不過因為用不到. 所以拿掉就OK了. 最後, 就是照著這個link裡的說明. 在程式裡設定locale. 那ctp裡需要localize的字串. 就會動態的換成對的localized的字串. 以上是前兩天實驗的心得. 接下來得真的套到Flirq上. 有別的狀況, 再上來跟大家分享.  

Friday, March 1, 2013

Great introduction about AWS from AWS expert

因為DreamIt的關係, 認識了AWS的一些人. 前一陣子剛好有機會跟其中一個亞洲區的技術支援通過電話. 他介紹了下面這幾篇AWS入門的文章跟連結. 我很快的看了一下, 覺得蠻不錯的. 跟大家分享分享.

Architecting for the AWS Cloud: Best Practices

Web Application Hosting: Best Practices  

EC2 Load Balance Documentation

EC2 Auto Scaling Documentation

Don't limit yourself

最近在看Steve Jobs的傳記. 裡面提到了他用他的"現實扭曲力場", 說服了工作團隊. 在不可能的時限裡做出了他們本來認為不可能的成果. 看完了這些故事, 心有戚戚焉. 因為這跟這幾年來的感悟非常的類似.

書裡的故事, Jobs透過各種威脅利誘加哄騙的方式, 讓工作團隊相信了他們本來覺得不可能的事是可能完成的. 我覺得這跟很多人說的, 做事要有信心, 或是凡事要正向思考都是很類似的事. 這些觀念都是要讓大腦相信你要做的事, 是可能會成功的. 而不是用一個"不可能完成, 不可能成功"的心態去做事. 因為這個樣子, 在還沒拼之前, 我們就已經被我們自己的大腦給限制住了. 

所以, 在創業的你, 要對自己跟自己在做的事有信心. 因為什麼點子都有可能會成功! 不要在意別人的眼光跟意見. 而有朋友在創業的你, 多給你在創業的朋友更多的鼓勵. 他們可能在做一些很多人不看好的事, 所以你的鼓勵, 格外的重要囉! 大家加油!

(Image from flickr's kroszk@, CC license)

 

StartupDigest

去年中準備回美國創業的時候, 開始訂閱起StartupDigest. StartupDigest是一份專門幫創業家收集創業相關活動與訊息的電子報. 發起的主因是因為創辦人到矽谷的時候, 發現矽谷的創業相關活動很多, 但是參差不齊. 所以他決定發起這份電子報來幫矽谷的創業人篩選好的創業活動. 後來這份電子報也慢慢在其他創業風氣正在成長的城市出現. 幫助當地的創業家能夠更有效地掌握所在城市的創業活動. 目前在全美跟全世界很多城市, 都有StartupDigest的各地分報. 

回來台灣前, 就一直在想. 應該在台灣有個類似的機制. 幫創業家掌握創業活動的訊息. 本來在想要不要花點時間自己也來弄一個站. 還好在做下去之前, 發現原來台北也已經了StartupDigest的分報了. 所以試著聯絡了Taipei StartupDigest目前的編輯James Hill. 看看能不能幫上點忙. 很幸運的, 目前的編輯James, 因為是個美國人, 也很歡迎我的加入來幫忙處理中文的部分. 所以龍年起的新工作之一. 就是幫忙編輯Taipei StartupDigest. 希望能夠幫上台灣的創業界一些忙囉. :)

Wednesday, February 27, 2013

Browser Locale Detection

之前在做作的side project, 計劃要有三種語言: 英/西/中. 但是不想要每個語言出一個版本, 所以本來是打算在Android app端抓使用者目前的語言, 然後在發http request的時候一起帶上來. 後來想一想, 這樣還要upgrade目前的已經release的版本. 雖然通知使用者upgrade跟真正進行upgrade這等事Android Market跟Android都處理掉了, 只需要upload新的apk上去就好. 但是我連這件事都有點懶XD. 所以最後用了另一個方法, 就是用PHP的$_SERVER['HTTP_ACCEPT_LANGUAGE']吐出來的結果. 這邊其實有點取巧. 因為這邊收到的資訊理論上是browser prefer的語言, 並不一定是使用者真正在用的語言. 而且這個參數是browser傳上來的. 不過很巧的是, 我目前就是開一個browser連到網頁, 而在我有限的實驗裡, 這個參數剛好也跟Android系統的language參數跑(至少Android Browser是這樣). 所以剛好適合我用. :D 這樣一來, backend改一改之後. 我目前的apps就能夠自動根據使用者手機的語言設定來顯示英文跟西班牙文囉. 希望中文的資料趕快好. 這樣我就可以試著在中文市場promote一下我的side project囉! :)

Startup Labs Taipei

Starup Labs要在台灣辦他們的第一個海外的Startup Labs Program. 昨天去聽了說明會. 覺得挺有趣的. 早上填完了報名表. 看看接下來會發生什麼事囉. :)

Happy Chinese New Year!!

再過幾天就是農曆新年了! 這個blog可能會安靜好幾天. 在這邊先祝大家新年快樂囉! 

Distraction

前一陣子花了不少時間在做side project. 總算快告一段落了. 該收心回來趕快做點正事了. 不過還是希望side project能夠有些好成果囉:)

Git + Github + Linux

今天把這幾天在弄的project, 上到了github上. 但是又忘了Linux裡該做些什麼設定, 才能clone code. 還好很快地找到了這份help. 趕快在這邊自己備份一下. 以免下次又得去Google找囉. :)

Ad location in the page

這幾天在做的project, 讓我開始真正的接觸到了adnetwork, 像是adsense, adBrite等. 之前都只是聽過, 看過, 但是沒有真正整合過. 昨天晚上申請, 拿到了code後, 就開始來試試看怎麼把廣告區域放到我的project裡對的位置. 不過大概是大多人都是放在blog裡. blog裡能放的位置其實有限(因為大多被BSP或是blog theme決定好了). 所以Google到的結果大多是教人怎麼把code放到blog裡. 對我沒啥幫助. 後來總算發現一篇很簡單的教學, 原來也是用<div></div>夾一下ad code. 剩下的就是靠CSS去調位置. 所以code大概就是

<div class"xxxxxx">

ad code 

</div>

要在網頁的什麼位置秀廣告? 就靠自己調整HTML跟CSS囉!

(Image from flickr's shannonkringen under CC license)

PHP get client side's date & time

這幾天在進行的project, 需要知道client的日期. (因為時差的關係, server跟client有時會有+-一天的日期差). 可是因為PHP是server side的language, 沒辦法直接知道client的狀況. 所以只好想了一個dirty hack. 那就是利用javascript去取得client的日期, 然後傳給server. 我目前是寫了一個.html檔, 在header的javascript裡取得日期. 然後再redirect到收日期的php. 下面是野人獻曝的程式片段.

<html>

<head>

<script type="text/javascript">

  var currentTime = new Date();

  var year = currentTime.getFullYear(); 

  var month = currentTime.getMonth() + 1;

  var day = currentTime.getDate();

  window.location = "http://localhost/services/getdate.php?year="+year+"&month="+month+"&day="+day;

</script>    

</head>

</html>

參考參考:)

(Image from flick's Jörg Weingrill under CC license)

AWS Upgrade or Migrate Instance

 

今天終於要來嘗試怎麼upgrade或是migrate既有的AWS instance. 昨天晚上找到了這篇教學. 但是因為還是對AWS command line tool的操作有點"恐懼感". 所以還是選擇了使用GUI的方式來試試看upgrade/migrate AWS instance.

注意:這個方法只適用於用EBS當做root device的instance. 以下是各個步驟

1. 在AWS Management Console選擇你要upgrade/migrate的instance. 然後選擇Instance Actions裡的Create Images. 

2. 在跳出來的對話窗裡, 幫這個image取個名字跟給個簡單的描述

3. 在Navigation的IMAGES->AMIs裡, 應該會看到步驟1, 2執行後所產生的image. 選擇哪個image之後, 點選Launch. 接下來就跟new instance差不多了. 

4. ㄟ...好像就這樣子而已....:p (boot instance, start service, blahblah...就不在這篇的內容討論裡了)

只能說AWS真的是有一套囉! 讓這些事變得如此簡單. 實在令人佩服!!

Wordpress

之前為了flirq的blog, 很快的安裝了一份wordpress在AWS的instance上. 就交給負責marketing的人接手了. 所以一直沒有好好的來體驗一下wordpress的power. 這幾天總算因為要幫忙處理一些wordpress家的blog相關的事, 才有機會來跟wordpress好好親近一番. 

玩了一些不同的themes還有相關的設定, 也試著改了一下相關的php還有css. 真的蠻佩服wordpress的架構跟建立起來的community的. 也感受到用wordpress來建立一個以content為主的website的便利性. 接下來一定要找時間再來多鑽研鑽研.  

(Image from flickr's Phil Oakley under CC license)

AWS Micro Instance


昨天用了AWS的Micro Instance裝好了LAMP環境跟wordpress. 在安裝設定過程中看到有人抱怨說Micro Instance的記憶體可能會不大夠. 今天top看了一下. 果真有這樣的風險XD (剛剛一度看到只剩3x MB) 看起來得加速對於AWS的熟悉程度. 至少得搞熟如果Micro Instance不夠用的時候, 怎麼快速又無痛的upgrade到其他的instance上囉. :Q  

Change AWS ec2-user password


因為一些side projects. 今天又跟AWS奮戰了不久時間. 在安裝完了LAMP的環境後, 開始要來處理怎麼把東西上傳到AWS的instance上. 我的選擇是SFTP. 不過我用的FileZilla好像只能用帳號/密碼來讓我login. 所以只好改動一下AWS instance上的設定. 讓我可以用ec2-user的帳號跟密碼login. 以下是該做的設定.
1. 把/etc/ssh/sshd_config裡的PasswordAuthentication改成yes
2. 重開ssh (sudo /etc/init.d/sshd reload)
3. sudo passwd ec2-user
4. 填入ec2-user密碼
完成!

2012

一轉眼2011就過了. 2011對我來講是個變動很大的一年. 口中嚷著要創業了好幾年, 2011年中終於因為拿到了一個紐約的accelerator program (NYC Seed Start)的offer, 而下定決心自己出來試試. 到了紐約後, 卻因為partner簽證的關係, 才發現沒辦法加入. 但是人生就是這樣, 當一扇門被關起來的時候, 可能有另外一扇窗為了你打開. 七月初到波士頓看國慶煙火時想到的dating website idea. 居然趕得及讓我們(這一次, 連老婆都拉進來了:p) 擠進九月初開始的另一個accelerator program (DreamIt Ventures). 九到十二月的DreamIt Ventures, 則是一段難忘的人生經歷. 在三個月內從想法的修正, 產品的實作, 上線, 找使用者. 短短的三個月, 學到也感受到了很多. 在這計劃趕不上變化的過程中, 新的一年就來了. 創業接下來要走的路有多長, 我也不知道. 只希望能夠趕快做出如圖片中煙火般燦爛的成果! (但是不能像是煙火般稍縱即逝囉! :p)

新的一年, 祝大家新年快樂! 事事如意! 

(Image from flickr's nigelhowe under CC license)

NSDate, NSCalendar, NSDateComponents

Screen_shot_2011-12-28_at_8

這兩天在試著寫一個iPhone的小程式. 基本目標就是要在每天固定時間跳出特定通知. Local notification本身還算簡單. 例子找到了, copy & paste上去幾乎就可以用了. 但是在要設定每天"特定時間"這件事上就遇到了一點小障礙. 因為得用上NSDate, NSCalendar, NSDateComponents這三個classes. 今天花了不少時間跟他們三個奮戰.

心得感想是(不保證完全正確): NSDate代表的是一個"時間點", NSDateComponents是一個時間的container. 可以設定裡面的年/月/日/時/分/秒等值來代表一個時間點或是一段時間的長度. 而NSCalendar則像是用來解釋NSDateComponents內容的一個class. 

滿有趣的一種設計. 不過用起來還沒有很習慣囉. :Q

Gratitude

上上禮拜收到家裡緊急電話說奶奶因為內出血住院了, 趕緊改了機票提前了幾天回來. 回來之後才知道原來外婆也因為膝蓋退化在動刀. 幸好上個禮拜五兩位老人家都順利出院了. 感恩! 在此也希望大家都能注意自己的身體健康, 也祝新的一年裡每個人都能健健康康, 事事如意!

(Image from flickr's aussiegall under CC license)

 

Jetlag

年紀越大, 越難跟時差奮戰. 這一次, 不知道多久才能調整完成. 

(Image from flickr's Sean MacEntee under CC license)

Amish


上禮拜五去參觀了在Lancaster, PA附近的Amish部落. Amish是一批因為宗教信仰的關係而盡量以傳統方式(不用家電, 不開車, etc.) 生活的一群人. 很佩服這一群能夠在這麼多外部的引誘下, 還能堅持自己的信念生活的Amish人.
(Image from Wiki under Wikimedia Common License)

Facebook login

今天連回Flirq. 忽然發現沒辦法login. 嚇了一大跳. 趕快追了一下bug. 發現原來是facebook oauth的機制改了. 之前為了讓新版跟舊版的oauth都能過的javascript吐出了error. 解決了javascript的問題之後, 總算是可以login. 但是卻抓不到facebook使用者的資料. 不過因為是用了一個3rd party的facebook plugin, 趕快升到了最新版, 就可以運作了. 真的是有驚無險. 不過接下來得認真追蹤facebook的各種改版. 以免類似的狀況又出現了.  

Tuesday, February 26, 2013

Google Search Tips

這幾天為了看看有沒有關於Flirq的press, 再次體認了Google的強大. 這次主要是用了Google search結果出現後左側的"Show seach tools"哩的功能. 這邊可以針對"內容的產生時間"去做更仔細的過濾. 不過可能有人會問, 為什麼不直接用Google Alert等著收通知就好了? 因為我發現Google Alert好像會漏東西, 舉例來說, 前幾天明明就有不少Flirq相關的內容, 我一封Google Alert都沒收到. 所以只好自己來filter by date range一下囉. :) 

Flirq @ Business Next

數位時代在翻譯TechCrunch的文章也提到了Flirq. 不過看起來記者並沒有注意到原文裡有提到有台灣人開的公司囉. :p

Google Currents

昨天看到了Google currents的新聞, 馬上裝來玩玩. 目前感覺還不錯. 幾個我自己認為的優缺點: 優點是, 畫面乾淨, 使用界面簡單. 流暢度夠, 還可以連接Google Reader. 缺點是沒辦法連facebook, 然後有兩個按鈕的功能很confusing. (back and home). 不過整體說來還蠻喜歡這個app的. 可能會慢慢用這個來取代我目前手機上的RSS reader囉. 

Press about Flirq

昨天Demo Day完. 今天開始看到了一些相關報導. 雖然不是單獨報導Flirq. 但是還是蠻令人開心的. 目前看到有TechCrunch, TechCocktail, TechnicallyPhilly, TheNextWeb. 看看還會不會有更多的報導囉.:)

(Image from flickr's NS Newsflash under CC license)

We did it!

今天是DreamIt的Demo Day. 前幾天的認真準備, 今天得到了很好的結果. 整個presentation很流暢. 準備的笑點, 底下的聽眾也都有回應. 呼...總算告一段落. 可以好好休息個一兩天. 然後開始下一波的產品調整了!!

Final count down

明天就是Demo Day了. 雖然沒有打算要在明天募資. 但是要用英文在兩百個投資人前present這三個月來的成果. 還是會緊張. 希望一切順利! Fingers crossed!

Good site for icons

這幾天花了不少時間做Demo Day的投影片, 在這過程中用到了一個網站還不錯, 叫Icon Arcive 在這邊跟大家分享一下.

這個網站搜集了很多免費的icon. 對於作投影片或是web/app都很有幫助. 有需要免費icon的朋友可以上去找找囉. :)

Tastycake

剛來Philly的時候, 之前在MIT的老師跟我說可以找看看一個叫TastyCake的牌子的甜點. 算是Philly這邊還算"家喻戶曉"的平價甜點. 今天終於有機會吃到. 還蠻好吃的而且真的很便宜(以美國水準來說). 不過單吃還是甜了一點. 下次來試試配點熱茶或是咖啡.

(Image from flickr's TV19 - DD Meighen under CC license)

Demo day presentation practice

今天在DreamIt partners面前試著present了一次. 給自己打了75分. 在有限的練習時間裡, 這樣的表現還算過得去. 但是還有蠻多進步的空間. DreamIt partners也給了不少很有用的意見. 尤其是同樣的內容, 用不同的說法, 可以給人完全不同的感覺. 這一點我還有得學囉!!

(Image from flickr's o5com under CC license)

Mustly NFL

與友人W合作的Mustly系列第二彈: Mustly-NFL上線! 安裝數緩慢增加中. 還在找適合promote的地方(NFL討論區, Fantasy Football討論區). 希望熱愛Football的美國人, 會喜歡這個App囉!

Demo day is coming!

一轉眼, DreamIt已經快要結束了. 下禮拜三就是Demo Day. 這個禮拜得好好來練習一下presentation. 畢竟我是這一次Demo Day裡唯一一個不是native speaker的presenter. huh~真緊張!!

AWS: Install the auto scaling command line tools

AWS提供了command line tools讓開發者可以透過command對AWS做scaling. 今天花了點時間在我的MBP(OS 10.7.2)上裝了起來. 在這邊記錄一下過程. 以供之後參考. 

主要參考網頁

1. http://docs.amazonwebservices.com/gettingstarted/latest/wah-linux/

2. http://docs.amazonwebservices.com/AutoScaling/latest/DeveloperGuide/index.htm...

3. http://stackoverflow.com/questions/6588390/where-is-java-home-on-osx-lion

其實安裝的步驟在command line tools的README.txt裡寫得蠻清楚的. 所以建議可以先到2裡面的How to Get the Command Line Tool先把zip檔抓回來. 然後照著README.txt裡面步驟作即可. 

Environment Variable的部份, 可以直接改自己目錄裡的.bash_profile, JAVA_HOME 的部份, 我是參考3裡的方法設定.

環境變數設定完後, 得設定AWS user credentials. 我是用AWS Keys的方法(可以連到http://aws.amazon.com/security-credentials查找)

都設定完之後, 可以照README.txt裡的方法. 測試看看是不是都work. (as-describe-auto-scaling-groups --headers一定要試, 因為會測到credentials有沒有設定好) 如果work, 恭喜, 那應該就是安裝好了! :)

 

AWS Study Notes

準備開始多研究研究AWS. 會在這邊記錄一些研究心得. 希望能夠玩出點東西囉. :)

Interesting Thanksgiving phenomenon in Philly

今天是感恩節. 下午跟老婆出門晃晃. 看看費城的感恩節是什麼樣的光景. 最大的感受是, 路上的人少了非常多. 但是有趣的是, 雖然街上的人整體變少了, 在路上走動的亞洲面孔卻變多了. 不知道是不是這些人平常被人潮給"稀釋"了. 而今天因為人潮變少, 所以感覺起來亞洲面孔就變多了? 不過感恩節當天的Philly跟這兩個月中活的Philly, 真的很不一樣囉. :) 

(Image from flickr's Thomas J. Matthews under CC license)

Thanksgiving

明天開始是美國的感恩節假期. 感恩節對美國人來講相當於農曆新年. 是一家人團聚的日子. (聖誕節反而沒有那麼強調要一家團聚) 所以我們住的這棟樓今天開始感覺起來空曠了不少. 不過對我們來講, 這個四天的假期可能沒辦法好好享受, 因為再兩個禮拜就是DreamIt的Demo Day了. 這四天的假期, 得開始準備Demo Day的presentation囉. XD

(Image from flickr's jdolenga under CC license)

Fire Alarm

今天傍晚忽然傳來尖銳的聲響, 一開始還不知道發生了什麼事. 以為是電腦不小心開了什麼奇怪的網頁. 後來才發現原來是大樓的火警警報響了. 我們目前住的這棟大樓的火警警報鈴聲相當稱職. 聲音的頻率跟分貝都非常有驅趕力. 讓人不得不離開房間. 還好我們住在六樓, 所以"逃生“的路程還不算太長. 幸好最後只是虛驚一場. 不過希望不要再發生了. 因為現在外面越來越冷了. 待在外面等警報解除, 實在不是件愉快的事囉. :p

(Image from flickr's mdid under CC license)

User Acquisition

(謎之音:求求你們來用用我們的產品~~)  Flirq上線後, 緊接著面臨的就是找使用者的挑戰. 創業家常常犯的錯誤之一就是認為產品做出來了, 使用者自動就會上門. 雖然我們沒有這麼認為, 但是還是低估了這個挑戰的難度. 不過這個問題本來就常常是決定產品跟公司成功或是失敗的主因. 所以我們也就只能繼續發想跟嘗試. 看看能不能很快地找到解決方案. 找到夠多的使用者, 才有機會從中學習我們目前的產品到底有沒有真的解決使用者的問題. 還是只是我們自己開心的想像. User Acquisition! Fighting!

(Image from flickr's GreyHobbit under CC license)

Unread articles

之前在台灣的時候, 因為上班通勤的時間不算短(單趟至少40分鐘, 而且大多在公車/捷運上), 所以subscribe了不少RSS feed, 趁通勤的時候看. 來回一個多小時的車程, 剛好也就可以把每天所有的新文章消化完畢. 來Philly, 住進現在的地方, 因為離DreamIt提供的辦公室, 通勤時間順利的話15分鐘可以到(不過大概是走路5分鐘, 坐車5分鐘, 再走路5分鐘). 結果之前可以每天順利消化的文章, 就開始慢慢累積了. 這個禮拜因為趕一些功能的緣故, 更沒時間看文章了. 剛剛心血來潮想要消化一下的時候, 發現不小心已經累積太多, 硬吃可能會消化不良. :p 不過轉念一想, 沒看到就算了. 這幾天不也過得好好的? 所以很快地點了幾個mark all as read. 準備來睡覺去囉. :)

(Image from flickr's Bright Meadow under CC license)

HGTV

這次回美國發現了一個很有趣的頻道叫HGTV, 主要就是講一些房地產相關的東西. (沒錯, 一整個頻道都是在播相關的節目) 為什麼有趣呢? 因為可以從這個節目裡看到很多不同地方, 各種形式, 不同價位的房地產. 更可以看到整個產業鏈裡的各種角色(從建商/仲介/買方/賣方/裝修...)之間的互動. 可惜回台灣之後就看不到囉. :(

(Image is from flickr's gardener41 under CC license)