“培養開放心態,迎接大數據時代:《大數據》作者麥爾荀伯格首度訪台論壇” 與新的 2 篇文章 - Inside 網路趨勢行銷與開發 |
- 培養開放心態,迎接大數據時代:《大數據》作者麥爾荀伯格首度訪台論壇
- 蘋果新貴 Swift 之前世今生
- 本來我以為功能齊全的 app 會比功能少的 app 熱門,但看完這五個例子之後… 我錯了 (特別是 #2)
培養開放心態,迎接大數據時代:《大數據》作者麥爾荀伯格首度訪台論壇 Posted: 12 Jun 2014 07:30 AM PDT 昨日,遠見天下文化出版事業群於新北市政府舉行「大數據論壇」,邀請《大數據》作者之一的麥爾荀伯格教授首度來台演講。 演講一開始,麥爾荀伯格先以著作《大數據》使用的例子作為開場:2009 年,Google 透過比對使用者的關鍵字、搜尋時間和地點,得出流感的發展趨勢預測,幾乎與疾病管制中心的專家們得出的研究結果相同,但是快了兩週!而且還是即時分析。 接著他又舉了 Farecast 這個機票價格預測網站的例子,由於創辦人 Oren Etzioni 教授在某次搭飛機之後發現自己的機票賣貴了,於是他蒐集各大網站的機票價格資料,告訴使用者何時買機票會最便宜,準確度達 70%。 麥爾荀伯格首先從大數據的幾個特性例如資料的數量、相關性重於因果關係等等談起,最後回到「人」的議題,探討大數據時代下「人性」有多重要。我們相當推薦各位讀者閱讀麥爾荀伯格與庫基耶(Kenneth Cukier)和著的《大數據》。 資料的大小根據 Mary Meeker 的 2014 年網路趨勢報告,目前無論是運算、儲存、蒐集資料(例如感應器、頻寬)的成本每年都在以顯著的比例下降,我們處理大數據的能力比起過去要強大的多。 以基因定序工作為例,2000 年時,人類基因組計劃工作草圖完成,耗時多年,所耗用的經費龐大。到了今天,任何一個人如要做自己的基因定序,只需要花二至三天,費用不到 1,000 美金。 資料的數量「變大」後會發生什麼事?麥爾荀伯格以一個很簡單的比喻告訴大家,當資料量變多的時候,會發生什麼事 他說,假如自己要為現場的觀眾拍照,那麼恐怕得決定要將焦距對準前排還是後排的聽眾,而且無論如何一定有一部分觀眾的臉是模糊的,但如果使用光場相機,那麼情形就不一樣了,這台相機可以將所有的「資訊」都記錄下來,「事後」再調整焦距。就好比我們為一匹奔馳中的賽馬拍照,得到的是一張相片;每一分鐘拍一張照片,得到的是一系列的照片;但若在一秒內連續拍攝 16 張,就成了一段短片——我們做的事情不變,就是拍照。 麥爾荀伯格說,使用大數據就跟我們使用光場相機一樣:我們先把所有的資訊收集起來(不管對焦,先拍照),日後將有機會發現原本不知道或是沒有注意到的事(調整焦距)。 What vs. Why接著麥爾荀伯格講的是大數據另一個非常重要的觀念:巨量資料告訴我們的是「什麼」,不是「為什麼」。大量的數據經過分析後,我們得到的是相關性,而不是因果關係。 他舉了 Wlamrt 超市的例子,這家全球零售巨頭了解到,在龍捲風、颶風襲擊前,人們會購買手電筒——這不並意外,只是他們也發現,人們還會買很多的 Pop-Tarts(一種甜食),Wlamrt 不知道為什麼人們這麼做,不過他們曉得要在對的時候將這項產品放在貨架上最顯眼的位置。麥爾荀伯格又舉了一個例子:假如你前一晚去吃大餐而隔天早上拉肚子,很快地你會推論出一定是因為昨晚吃的東西有問題,但說不定真正的原因其實是你跟某人握了手——建立因果關係的機制深深地烙印在我們的腦中。 在大數據面前,我們要注意資料要告訴我們「什麼」而不是「為什麼」,在我們去探究「為什麼」之前,先專注於了解到底「發生什麼事」。當亞馬遜和 Netflix 在推薦使用者內容時,他們並不知道為什麼要推薦這些東西。 麥爾荀伯格又舉了一個例子:翻譯。50 年代電腦科學家試圖透過建立規則的方式,再輸入字典資料告訴電腦該如何翻譯,這個作法以失敗告終,因為例外實在太多了。80 年代晚期,IBM 嘗試了另一個方法:他們使用加拿大國會文件中的 300 萬個句對(英文和法文),統計某個詞最常被翻譯成另一種語言的相對詞彙,使用統計方法,IBM 在機器翻譯上取得了長足的進步,接著他們又想,如果調整演算法,說不定可以讓翻譯效果變得更好,結果卻不盡人意,後來 IBM 便放棄這個計畫。 最後是誰辦到了?大家應該都有猜到:Google。這家搜尋引擎公司認為問題不在於演算法,而是用來訓練電腦的資料。與其輸入辭典、翻譯規則或是 300 萬句的國會翻譯資料,Google 決定餵給電腦整個網際網路:數以十億計的網頁、數兆個詞彙、近億句的英文句子...... 雖然資料雜亂,不如 IBM 先前使用的經過精心翻譯,但是卻能順利地將許多語言完成翻譯,並且具備夠好的品質。「我如果想知道台灣讀者對我寫的書的看法,就會用 Google 翻譯。」麥爾荀伯格說。 解決醫療問題的,可以是電腦科學家大數據的相關性顯示在另外一個例子:早產兒照護。早產兒容易遭受感染,但是常常在醫生發現症狀後會醫治不及。Carplyn McGregor 博士與安大略理工學院和 IBM 的研究人員合作,從早產兒身上每秒讀取 1,200 個資料點。經過數週後他們從許多早產兒身上搜集到許多資料,讓科學家從中找到了一種模式,可以在早產兒出現感染症狀前的 24 小時提出預警。「專業醫師們哪想得到,在爆發嚴重感染前,生命指數卻有一段時間呈現非常穩定的情況呢?」這個案例也顯示:用大數據解決實際問題時,往往這些資料科學家並非該問題的專家,但正因他們能夠找出大數據告訴我們「發生什麼事」,可以協助解決令「知道為什麼」的專家們苦惱的問題。 顛覆傳統科學研究方法我們知道科學家們在研究問題時,會先提出假設,然後進行驗證,但是在大數據的時代,這個流程出現了變化。例如 Google,他們有個理論,但不知道要做什麼假設,所以他們把這項工作交給機器,讓電腦從大量資料中產生假設。 數據再利用,資料即產品過去,人們會針對特定目的蒐集資料,但是在大數據時代,就像前面所舉,可以「先拍照再對焦」的光場相機,很多時候我們不會知道原來資料還有別的用途。 麥爾荀伯格舉了幾個例子,像是新創公司利用全球 SWIFT(Society for Worldwide Interbank Financial Telecommunication,環球銀行金融電信協會)網路資料預測全球經濟;荷蘭電信公司利用基地台數據測量當地的天氣變化,發現自己可以進軍氣象預報事業;勞斯萊斯是汽車公司,但他們同時也是全球第二大的飛機引擎製造商,他們整合自家飛機引擎數據分析後,可以在引擎故障發生前先預測故障的會是哪一具引擎並提早進行檢修。 大數據時代下的「人性」演講最後,麥爾荀伯格再次提醒觀眾,千萬要小心因果關係與相關性的問題,以及大數據的限制。又,他也呼籲大家要重視大數據時代下,蒐集資料會不會侵犯了人們的隱私,以及我們利用大數據預測的事:美國的 Target 百貨曾經利用消費者的購物記錄,在婦女自己還不知道的情形下,預測出她懷孕了。 大數據這項威力強大的技術帶來許多好處,同時也帶來許多挑戰,我們需要學習的事情還很多,誤忘謙卑與人性。「最終,資料只是現實的影子。(The data at the end of the day, is always just the shadow of reality.)」麥爾荀伯格說。 麥爾荀伯格的演講結束後登場的就是這次的大數據論壇。 政治人物應該具備的能力今天新北市場朱立倫在座,他也問了麥爾荀伯格「政治人物該怎麼看待民意調查」這個問題,麥爾荀伯格表示,民意調查可以了解民眾當下的想法,但是無法預測人們未來的行為。他也提醒政治人物應該具備三種能力:
他也提到,政府部門是掌握最多數據的機構,而政府決策影響甚巨,更該好好運用這些數據作為施政方向的基礎。先前紐約市長彭博就請出大數據專家,找出危險程度最高的老舊建築,希望降低火災事故。世界上有愈來愈多國家對資料保持愈來愈開放的態度, 避免資料獨裁,應把資料視為機會雖則麥爾荀伯格非常推崇巨量資料,但是正如「役物而不役於物」,他提醒我們不應全盤信任資料,應該帶著批判的眼光審視資料,否則到頭來反而容易走向另一個極端:對資料失去信任。麥爾荀伯格認為,適當配套的法律與政策架構,可以為巨量資料帶來健康良性的發展。 資料能夠告訴我們社會的變化趨勢,替我們預測未來,至於能否善加利用提前因應,就考驗政府的態度了。這並不表示政府得通通自己來,而是應該解放資料,交由民間力量解構分析。資料開放的威力有多強大,g0v 零時政府等組織已經樹立典範,他們挖出各種公家機關冗贅複雜的資訊,結合眾人力量拆解、重組,轉化為清晰易讀的版本,達成真正揭露資訊的效果。 只是,新北市長朱立倫在會中表示,公務員對於「資料開放」仍存有心理障礙,很怕因此「工作不保」,恐懼民間反彈,「不敢失敗、不敢冒險」的心態依舊很普遍。但朱立倫也承諾,藉著資料開放打造更有效率的新北市政府,並將開放的精神推廣到全國。 培養開放心態,迎接大數據時代在資料導向的新經濟時代,台灣應該如何接招?麥爾荀伯格認為,在天然資源貧乏的地區,更該具備數據分析的能力,比如大學設立巨量資料分析研究所,會有很大的幫助。目前巨量資料專家還不是很多,是值得好好把握的機會。而在專業技能之外,也應該培養開放的心態與冒險犯難的精神,他鼓勵台灣人別只侷限在台灣,應當放眼世界。 其實,麥爾荀伯格自己就是出生於奧地利偏遠山城,但從學生時代就有宏大的野心,身為律師的父親要他繼承衣缽,但他對物理與電腦的興趣更加濃厚。在父親過世前一天,他問兒子「到底想要做什麼」,麥爾荀伯格說「我要到哈佛大學當教授」,父親仍要他好好思考第二選項,不過終究,麥爾荀伯格做到了。他完成父親的遺願,念了哈佛法律並順利當上哈佛法律教授,但後來也遵循自己的意志,探索浩瀚的網路科技,麥爾荀伯格目前擔任牛津大學網路機構(Oxford Internet Institute)教授。 |
Posted: 12 Jun 2014 12:32 AM PDT
2010 年的夏天,Chris Lattner 接到了一個不同尋常的任務:為 OS X 和 iOS 平台開發下一代新的程式語言。那時候賈伯斯還在以帶病之身掌控著龐大的蘋果帝國,他是否參與了這個研發計劃,我們不得而知,不過我想他至少應該知道此事,因為這個計劃是高度機密的,只有極少數人知道,最初的執行者也只有一個人,那就是 Chris Lattner。 從 2010 年的 7 月起,Chris 就開始了無休止的思考、設計、編纂程式和除錯,他用了近一年的時間實現了大部分基礎語言結構,之後另一些語言專家加入進來持續改進。到了 2013 年,該專案成為了蘋果開發工具組的重中之重, Chris 帶領著他的團隊逐步完成了一門全新語言的語法設計、編譯器、運行時、框架、IDE 和文檔等相關工作,並在 2014 年的 WWDC 大會上首次登台亮相便震驚了世界,這門語言的名字叫做:「Swift」。 根據 Chris 個人部落格對 Swift 的描述,這門語言幾乎是他憑藉一己之力完成的。這位著名的 70 後工程師同時還是 LLVM 專案的主要發起人與作者之一、Clang 編譯器的作者,可以說 Swift 語言和 Chris 之前的軟體作品有著千絲萬縷的聯繫。
關於作者Chris 可以說是天才少年和好學生的代名詞,他在 2000 年本科畢業之後,繼續攻讀電腦碩士和博士。但 Chris 並不是宅男,學習之餘他手捧「龍書」遊歷世界,成為德智體美勞全面發展的好學生。之後就是一篇又一篇的發表論文,碩士畢業論文即提出了一套完整的運行時編譯思想,奠定了 LLVM 的發展基礎,就讀博士期間 LLVM 編譯框架在他的領導下得到了長足的發展,已經可以基於 GCC 前端編譯器的語義分析結果進行編譯優化和程式生成,所以 Chris 在 2005 年畢業的時候已經是業界知名的編譯器專家了。
Chris 畢業的時候正是蘋果為了編譯器焦頭爛額的時候,因為蘋果之前的軟體產品都依賴於整條 GCC 編譯鏈,而開源界的擁護者並不買蘋果的帳,他們不願意專門為了蘋果公司的要求優化和改進 GCC 程式,所以蘋果一怒之下將編譯器後端直接替換為 LLVM,並且把 Chris 招入麾下。 Chris 進入了蘋果之後如魚得水,不僅大幅度優化和改進 LLVM 以適應 Objective-C 的語法變革和性能要求,同時發起了 CLang 專案,旨在全面替換 GCC。這個目標目前已經實現了,從 OS X10.9 和 XCode 5 開始,LLVM+GCC 已經被替換成了 LLVM+Clang。 Swift 是 Chris 在 LLVM 和 Clang 之後第三個偉大的專案! 關於語言2007 年之前,Objective-C 一直是蘋果自家院落的小眾語言,但是 iOS 行動裝置的爆發讓這門語言的普及率獲得了火箭一般的竄升速度,截止到今天,Objective-C 在程式語言排行榜上排名第三,江湖人稱三哥,大哥二哥分別是 C 和 Java 這樣的老牌語言。同時,蘋果在 2012 年和 2013 年分別對 Objective-C 進行了大規模的優化和升級改進,增加了各種現代語言的特性,讓編寫 App 更加容易,更多的工程師投入到了 App Store 的生態圈裡…… 在這種情況下,蘋果公司為什麼會發布一門新語言呢? 這個問題沒有標準答案,不過我們可以試著去分析一下,談談蘋果的心路歷程…… Objective-C 是 80 年代初 Brad Cox 和 Tom Love 發明的,1988 年賈伯斯的 Next 公司獲得了這門程式語言語言的授權,並開發出了 Objective-C 的語言庫和 NEXTSTEP 的開發環境。後來 Next 被蘋果收購,Objective-C 陰差陽錯成了蘋果的當家語言。掐指一算,三十年倏忽而過,OC 也成長為爺爺輩的程式語言了。 為了伺候好這位「爺爺」,蘋果煞費苦心,把 GCC 的編譯鏈先替換成 LLVM +GCC,又替換成 LLVM+Clang,做語法簡化、自動引用計數、增加 Blocks 和 GCD 多線程異步處理技術……終於,OC 在 30 年後重新煥發出勃勃生機,並佔據了兵器譜排名第三的位置。但是,蘋果卻有點煩了,OC 改進了這麼多年,怎麼看都像是在修修補補,用 Blocks 去實現一個類似 Python 的 lambda 閉包(closure)功能,看起來總是那麼彆扭。好吧,既然已經全盤掌握了 LLVM 和 Clang,為什麼我們不去基於現在的編譯器設計一門全新的語言呢?一門屬於蘋果的語言!你看,鄰居 Google 家裡叫做 Go 的孩子不是玩耍正酣嗎? 於是 Swift 誕生了…… 當然,事實的真相也可能是行動緩慢的賈伯斯把 Chris 拉到一邊說: 「I want to be swift to……」 「 行了,您別說了,不就是想要 swift 嗎,我這就給您做一個去」 於是 Swift 誕生了…… 語法Swift 是一門博採眾長的現代語言,在設計的過程中, Chris 參考了 Objective-C、Rust、Haskell、Ruby、Python、C# 等優秀語言的特點,最終形成了目前 Swift 的語法特性。我在閱讀了官方教程和做了些程式實驗之後,自我感覺會喜歡上這門語言,在這裡簡單談點感想,更深入的內容需要你們自己去深入學習。 1. Swift 是針對 Cocoa 和 Cocoa Touch 的程式語言、編譯型語言,生產環境的程式都需要 LLVM 編譯成本地程式才能執行,但是 Swift 又具備很多動態語言的語法特性和互動方式。 2. Swift 是一門類型安全的語言,可以幫助開發者清楚的掌控程式片段中的值類型。如果你期望輸入的是字符串,類型安全的特性會阻止開發者錯誤地為其傳遞一個整數。這一切使得開發者能夠更早的發現和修復錯誤。 3. 支援各種高級語言特性,包括閉包、泛型、物件導向、多返回值、類型接口、元組、集合等。 4. Swift 能與 Objective-C 進行混合程式,但程式分屬不同的文件。 5. 全面的 Unicode 支持,你甚至可以用一隻「狗」作為變量名,實現以下操作:
控制台會輸出「大狗菠蘿」四個字。 6. 程式語句取消了大部分語言使用的「;」分隔符,只有一行寫多條語句時才需要分號。 7. 很多人簡單閱讀了 Swift 的數據類型,就認為 Swift 沒有類似 Set、List 這樣的數據結構,其實 Swift 提供了兩種 Collection 的數據類型:Array 和 Dictionary,兩個數據類型的表達式都用中括號標識。其中數組可以存儲任意類型的變量,也可以強制聲明存儲同一種類型的變量。同時數組提供了類似 Set 功能,你可以修改、追加、替換和刪除數據的元素。另外,Swift 還提供了 Tuple 的功能支援函數多返回值。 8. Swift 沒有提供顯式的指針,參數傳遞根據數據類型的不同分為值類型和引用類型,值傳遞進行內存拷貝,引用傳遞最終傳遞的是一個指向原有對象的指針。這一點和 Java 的參數傳遞是類似的。需要注意的一點是,Swift 裡的數組和字典雖然都是結構體(struct),但在參數傳遞過程中處理方式卻不一樣,默認 Array 是引用傳遞,Dictionary 是值傳遞。而在 Java 中,由於數組和 Map 都是對象,所以傳遞的都是指針。 在 Swift 中,如果你不想傳遞數組引用,可以用 copy() 方法先複製一份出來,另外,也可以用 unshare() 表示,本變量不傳遞指針。 9. 閉包,Swift 終於提供了一種優雅的閉包解決方案,比如在排序函數 sort 中進行函數傳遞:
事實上更簡單的寫法是:
10. 可選變量(Optional)的引入主要是為了應對一個變量可能存在也可能是 nil 的情況,這種情況在很多高級語言裡都存在。比如你想使用 String 的 toInt 方法將 String 轉化為 Int 類型,但是你並不知道這個轉化是否正常,這時候系統會返回一個可選變量,如果轉換成功就返回正常值,轉換失敗就返回 nil,如下:
這是 nn 就是可選變量,想得到 nn 的值,可以通過 if 進行判斷並藉著追加驚歎號獲取變量值,如下:
可選變量的引入解決了大部分需要顯式處理的異常,這部分工作也扔給編譯器去做了。想了解更多可選變量的用法,請閱讀蘋果的官方文檔。 11. Swift 中的 nil 和 Objective-C 中的 nil 不同。在 Objective-C 中,nil 是指向不存在對象的指針,而在 Swift 裡,nil 不是指針,它表示特定類型的值不存在。所有類型的可選值都可以被設置為 nil,不只是對像類型。 12. Swift 沒有從語言層面支持異步(Asynchronous)和多核,不過可以直接在 Swift 中復用 GCD 的 API 實踐異步功能。另外沒看到 Swift 的異常處理機制,可能有了可選變量,異常的使用會非常少吧。 關於語法相關的內容,先寫這麼幾點吧。 給大家推荐一篇王巍 (@onevcat) 寫的「行走於 Swift 的世界中」,深入閱讀必有收穫。 基本上,Swift 絕對不是玩具語言,而是一門可以被大眾接受的工業級程式語言。相信假以時日,Swift 必將在 App 開發領域大放異彩。 性能Swift 在 WWDC 上展示出來的性能還是讓人非常吃驚的,在進行複雜對象排序時,OC 的性能是 Python 的 2.8 倍,Swift 是 Python 的 3.9 倍;在實現 RC4 加密算法的時候,OC 的性能是 Python 的 127 倍,Swift 是 Python 的 220 倍。總之 Python 在某一個深坑里膝蓋中箭了,OC 也沒好到哪去,而 Swift,就是快啊就是快! 對於這一點我並不是很理解,首先是 WWDC 上展示的語言層面的基準測試過於簡單了,另外,OC 和 Swift 都是被 LLVM 編譯成本地程式執行的,理論上針對 Swift 的優化同樣可以應用於 OC,但是 Swift 居然比 OC 快那麼一點點,難道 LLVM 單獨針對 Swift 做了優化嗎?我表示不明覺厲(編按:中國網路用語,「雖然不是很明白,但是好像很厲害的樣子」縮寫)。 當然,還有更較真的工程師,他在第一時間針對於循環、遞增、數組、字符串拼接等功能進行了測試,發現 Swift 的性能比 OC 還是差那麼一點點的。 無論這些測試數據是否準確,我覺得性能是我們最不需要擔心的問題,蘋果已經全盤掌握了這個語言的方方面面,從底層編譯框架到編譯器再到語言設計,優化之路才剛剛開始,我們只要給這門新語言一點耐心就可以了。 所碼即所得(Playground)對於開發者來說,Playground 是本次 WWDC 最大的亮點。能夠在編輯程式的同時實時預覽輸出結果是每個開發人員的夢想,這一次蘋果為大家提供了這樣的福利。 Playground 不僅實現了很多腳本語言支持的互動式程式,而且提供控制台輸出、實時圖形圖像、時間線(timeline)變量追蹤等功能,開發者除了可以看到程式的實時運行結果,還能根據時間線閱讀某個變量在程式片段中值的變化。這真是太棒了! 最初看到這個功能的時候我甚至以為每個 Swift 文件都可以基於 Playground 進行實時程式變化預覽,仔細閱讀文檔後發現,只能在 XCode 提供的 Playground 文件中實現以上功能。看來 Playground 顧名思義,目前還只是為開發者提供了一個玩耍程式的地方。 當然不只是玩耍,我們可以基於 Playground 做這些事情:
對於 Playground,設計者 Chris 是這樣描述的:Playground 功能傾注了我個人很多心血和激情,我希望新的程式語言具備更好互動性,更友好和有趣……我們希望通過這門語言重新定義「如何教授電腦科學!」 開始使用 Swift作為一門新語言,Swift 定位非常明確,就是吸引更多的開發者加入蘋果的軟體生態圈,為 iOS 和 OS X 開發出更為豐富的 App,如果你是 App Store 的開發者,推薦儘早學習和掌握這門蘋果力推的新語言。對於大部分新事物來說,越早介入,獲利越多。如果你是一名 Web 相關的開發者,與其等待 Swift 增加 Web 開發的相關特性,還不如去學習一下 Go 語言 Web 程式。 如何開始 Swift 呢?
可以說 Swift 是我所見過關注度最高的新語言,一經推出即萬眾矚目,媒體和開發者在數天之內對 Swift 進行了長篇累牘的報導和討論,英文手冊迅速被翻譯成中文,即使是江湖上的另一位大佬谷歌 2009 年推出 Go 語言時也沒有如此浩大的聲勢。當然,這和 Go 語言的定位有關,作為一門系統級的伺服器端語言,開發者的可選餘地太大了,如果 Google 推出 Go 是用來取代 Java 開發 Android App,那可能情況就完全不一樣了。 經過 WWDC2014,蘋果已經完全體現出了一個軟體公司的創新能力和技術底蘊,無論是操作系統,程式語言,還是應用開發,蘋果都已經準備好了,凝神靜氣,蓄勢待發。作為開發者,我們要做的就是:Write the code, Change the world,然後期待下一個收穫的季節! |
本來我以為功能齊全的 app 會比功能少的 app 熱門,但看完這五個例子之後… 我錯了 (特別是 #2) Posted: 11 Jun 2014 05:52 PM PDT
很明顯這個標題是模仿最近很紅的「反差標題引人點擊法」,如我本來不覺得我的日常生活可以更便利,但是看完這 19 個跨時代的產品之後…我錯了。 (原標題: 19 個超棒的日常生活發明) 而如果我自己來下這一篇的標題的話,我會下...,「單一目的 app 的時代」 前陣子網路女王 Mary Meeker 發表了她對於網路趨勢的分析簡報,其中提到了一點很重要的要素,是 app 開發者可以仔細思考的,引用 Inside 這篇文章中對她簡報的翻譯:
過去當 app 剛崛起時,開發者和使用者都不知道正確的 app 使用模式、頻率到底長什麼樣子,因此在網路科技領域的前輩們 (大網站的擁有者),如 Google、Facebook、Yahoo 紛紛推出屬於自己品牌的 app(國內的話就是一些現在還是九宮格進版畫面的 app)。他們花了很多心力將自己本身擁有的網站內容作進小小的 app 裡,但他們後來發現,這樣的作法是錯誤的。 網站和 app 的不同,一、進入方式網站和 app 不同,網站就像是樹立在原野中的城堡與城鎮,各地的人因為某種機緣巧合的原因,進到了這個城鎮的某個角落。這些原因可能是: 被 Google 大神引導、朋友的推薦、從某個傳送門 (其他網站連結) 忽然跳過去。如果他跳過去的那個角落夠吸引人,那麼他可能就會花時間慢慢逛,認識這個城鎮,然後發現這個地方應有盡有,到處都可以玩。最後他便會愛上這個城鎮,時常來這邊玩耍,成為忠實使用者。 而 app 呢? app 像是在櫥窗前面擺著的傳送門,每道門上寫著:「這通往 xxx」,例如: 這通往 Yahoo。而打開這扇門後,複雜的 app 會要你做出一連串的選擇 (想像把城鎮裡面的店家都折疊起來放在門後,要你進門之後選擇要去哪家,你要看相簿還是看新聞),選擇完一個之後它會要你選擇你想作什麼 (你要發文還是閱讀文章? 你要看運動新聞還是娛樂新聞?) 這一連串像是迷宮一樣的選擇,會把使用者的耐性磨光。 app 的本質是 sequential 的,使用者必須遵循單一固定流程才能完成自己想做的事情,若這個流程我必須天天作,那我就會覺得前面那些無聊的選擇過程讓人厭煩。(如果每天早上起床要先從列隊在前方的二十道門裡面選擇「洗手間」,然後再在排列整齊的二十樣盥洗用具中選擇「牙刷」 和「牙膏」 的話,就算這個過程很無腦,使用者還是會覺得煩。而且這樣的煩會潛意識的讓人不想打開這個 app,因為達到目標的過程是痛苦的) 由於這樣進入方式的不同,「單一目的 app」的存在就變得必要,如果現在有人想要看一下最近的新聞,而他站在櫥窗前,發現一個傳送門上寫著「XX 新聞」,另一個傳送門上面寫著「Yahoo!」,你覺得他會選擇那一個傳送門呢? --- 即使這個「XX 新聞」 可能是「Yahoo!」的子集,但大多數的人還是會選擇前者。 也因此,Yahoo! 的 app 從網站思維慢慢的演進為 app 思維,從城堡變為散裝的 app,早期的 app 包含了 Search、Mail、News 功能,大家可以看看他們的 Dev log: 版本 2.0.0 (2011 年 7 月 27 日)
版本 1.1 (2009 年 5 月 18 日)
而這是現在的 Yahoo app 們: 網站和 app 的不同,二、逛街與選擇過去大家說上網會說「瀏覽網站」(Browsing the Internet),但現在不會有人說打開 app 使用是「瀏覽 app」。原因是網路的本質是互通的,但 app 不是。在網路上人的行為就像是在逛街,很可能會因緣際會下就逛進某家店,並因此成為忠實用戶。因此如果要設計一個網站,策略應該是讓通往它的道路越多越好,一種方式是建立許多內容進去,讓大家都想要建道路通到你身上,另外一種方式是提供只有你有的服務,就像是迪士尼樂園,熱愛這個網站的人便會千里迢迢的來使用這個服務。 但 app 不是,app 彼此之間本質上是沒有連接的 (除非你是同一個品牌去作刻意連接,如 Yahoo、Line、Facebook 他們自己的衛星 app 彼此有互相連接)。app 必須躺在螢幕上面,讓使用者想到它、選擇它、使用它。 也就是說,「想到」與「選擇」會變成 app 設計的重點元素。Yahoo、Facebook、Google 之所以要把 app 拆開來,便是因為這個原因。使用者會每天想到要看新聞 -> 打開新聞 app,想看天氣 -> 打開天氣 app,但使用者不會想到天氣,然後便想要打開 Yahoo 或 Google app,因為它不是專門用來作這個的啊,使用者聯想不到。 在「選擇」這個前提之下,讓大家「想到」(或想像) 這個 app 是符合某特定需求的就很重要。假設現在有三個 app,一個是「世界樂譜大全」,另兩個是「吉他譜大全」和「鋼琴譜大全」,後兩者的內容是前者的子集合,而且三個 app 長的幾乎一模一樣 (Icon 設計、流程等等...),但「世界樂譜大全」 除了鋼琴、吉他以外還加了烏克麗麗,大家覺得三個的下載量會差不多還是後兩者加起來會跟前者差不多? 答案是 --- 後兩者的個別下載量可能會遠遠的超過前者。因為對彈鋼琴的人來說,一個門上寫著「鋼琴譜大全」的傳送門,看起來比較能保證自己可以得到最專業的琴譜,更何況,其他的譜我這輩子也用不到,為什麼要下載下來增加我的負擔呢? 在這邊提供一個「目前看起來正確的」例子,造成這結果的原因除了功能定位之外,歷史因素也佔挺重的 (台北等公車的歷史最久,台灣等公車是後來才發行的): 台北等公車 百萬下載 台中等公車 十萬到五十萬下載 台灣等公車 五到十萬下載 所以單一功能的 app 才是王道?是,也不是。如果你是一個大公司,那麼在 app 的世代,你要把既有功能分解、包裝成一個個 app,如 Google 和 Facebook。 (Facebook 旗下除了這些 app 以外還有 Paper 和 Instagram,由於它相對來說較晚茁壯並且核心功能單一,因此沒有太多東西可以拆。) 有知名度、有行銷預算的公司,可以用各種方式讓大家「認識」自己的 app,例如剛剛講的世界樂譜大全、鋼琴樂譜大全,如果 2 個 app 都是沒有品牌、沒有行銷預算的公司做的,那麼「鋼琴樂譜大全」是比較容易被大量下載的。但如果「世界樂譜大全」是由一家世界知名的樂譜公司做的,在行內的人都知道這家公司,那麼即使它定位較廣,也能藉著品牌形象讓使用者選擇去下載它。 app 只有「單一功能」這件事情,其實只是一個概念,它是小公司、無名人士的利器,它讓使用者以為,這個 app 只有這個功能 --- 並且是專為他設計的。藉此引導使用者選擇下載、每天使用打開這扇任意門,最後不知不覺黏著在上面。此時 app 可以加上其他一兩個延伸性功能,讓這個 app「轉型」、「更有價值」。Line 是一個很好的例子,一開始它只有單一的聊天功能,後來加上了「動態時報」、「貼圖小鋪」等延伸功能,這些功能不會是大家打開這個 app 的原因,卻可以增加使用者的停留時間、黏著度。 換句話說,一個 app 可以有 3 到 5 個主要功能,但概念上,它要只做一件事情 (或說只有一個目的),否則它很容易被遺忘在手機裡,再也不被打開。 而這「只做一件事情」的先決條件,讓平民也可以和大企業競爭,這也是 app 創業潮這麼熱的原因 ( 商周: 跨國直擊!最強「100 美元創業團隊」小蜜蜂創業潮)。 mobile first (app) = 從小蜜蜂長到巨型怪獸一個小團隊,可以營造一個單一功能的 app,作個漂亮的門面、明確的功能目的,就有機會讓百萬或千萬的人下載使用 --- 而這只是第一步。 只要在這 app 中的人 * 時間的基數是夠大的,在 app 中就能慢慢加入其他功能,讓裡頭的人去玩、去試用、去探索、去產生對 app 有幫助的內容。就像 Line 和 WeChat 一開始只有聊天功能,但漸漸的,裡面加入了社群、購物、個人銀行、商城、遊戲城的功能,不知不覺,它們已經成為巨獸。 又例如大陸的「 大姨吗月经期助手」,一開始它只是一個「單一目的的工具」,但後期它加入了社群,然後... 就勢不可擋了。 友乐活女性经期管理应用「大姨吗」dayima.us 获得数百万美元投资!
從單一功能的 app 逐漸發展到社群,是這世代低資本創業的一個好方式,而目前我與朋友正在開發經營的 app --- 愛食記,未來也會朝這個方向去發展。這也是為何它沒有從它的前身「台北食記」分身成「台中食記」、「高雄食記」的原因。 結語所以標題說的五個例子和 #2 指的到底是什麼....,我想其實大家看完文章應該早就忘記有這個標題了吧。 人就是這麼健忘,而那標題除了吸引別人點進來之外,實在是一點意義都沒有。這樣的標題殺人法就像是露事業線的照片一樣,會驅使行動不經大腦的人點下去,雖然不是人人都會中招 --- 不是你也不是我,但世界上就是會有 80% 以上的人被勾引進去。 希望這篇文章不像網路上使用同樣標題的文章一樣速食沒營養,Cheers~ |
You are subscribed to email updates from Inside 硬塞的網路趨勢觀察
To stop receiving these emails, you may unsubscribe now. |
Email delivery powered by Google |
Google Inc., 20 West Kinzie, Chicago IL USA 60610 |
留言列表