知名科技媒體《VentureBeat》 記者趕在 Facebook 工程主管 Jocelyn Goldfein 前往紐約與該公司工程師團隊談話之際，在紐約圖書館事先採訪了她，主要聊了 Facebook 做行動產品時所犯的錯誤與心得。以下是 Jocelyn Goldfein 的觀點摘編。
Goldfein 認為，Facebook 一開始的錯誤在於它把行動產應用當成了一個單純的 Web 終端，把所有現成功能一股腦塞進手機裏，希望通過 HTLM 5 的方式做行動產 App。正確的方式應該是在借鑒行動產端優勢，由行動產端從頭做起。
是給原有產品增加一個新功能，還是重新開發一款獨立的產品？
Goldfein 認為獨立的 App 會有更大的風險，它也許會打破之前的產品假設，人們會以不同的方式看這個產品，比如她認為 Facebook 應用中的 IM 功能表現得仍很像聊天，但用戶表示他們不確定消息是否及時發得到，他們覺得這跟發訊息並不一樣，對方可能在登錄時才看得到。
獨立產品帶來新體驗更有說服力的例子當屬最近才推出的
Paper，該產品 UI 出眾，通過算法和編輯從用戶的訊息流中摘取重要內容推薦給用戶。將個人狀態、興趣內容等訊息放在一個管道下並不是最好的做法，Paper 提供了消費訊息的另一種選擇，而且 Goldfein 認為還有很多不同的方法抽取 News Feed 的數據和圖片。
說到未來的發展，Goldfein 認為隨著平板的興起，Facebook 會推出更多基於平板的體驗。
目前該團隊還在努力探索 Facebook Home 符合市場的產品形式，這種深入 Android 平台的方式是 iOS 無法比擬的。
穿戴式科技也在興起，這裏也將有 Facebook 的身影。她認為微軟的 Windows Phone 平台也將占據更多的市佔率。Facebook 還將保持對亞洲、非洲和南美等新興市場的重視，除了越來越多的智慧型手機用戶外，許多功能機用戶也是 Facebook 所看重的。
延伸閱讀：
今年一定要訂行動策略，但是該做 App 還是 Responsive Design 的網頁？
如果你是一個創業家、公司的開發者，在行動化的大趨勢下你一定會面臨到一個問題：我到底要不要為我的產品開發一個 App ？
但如果我告訴你，有一種技術，你單單用它就可以在智慧型手機、平板、Web 端「一次」把你網頁的內容全部優化到最好，會吸引你使用嗎？
好，接著你必須想再進階一點的問題：那我要開發一個 Native App ，還是用「響應式設計」呢？再釐清兩個問題前，我們必須了解「Native App」和「響應式設計」的不同。
Native App 原生語言程式是為了特定的操作系統而編碼，用的也是特定操作系統的開發套件（Platform SDK）, 如 Apple iOS。因此它的性能和工具一向比 Hybrid App 優越。手機原生的功能：GPS 定位、掃描、相機等等，都必須要用 Native 語言開發才做的到。
響應式網頁（Responsive Design ，以下簡稱 RD），又稱回應式網頁設計，是一種用同一種方式開發出的網頁，卻能在任何一個裝置上（智慧型手機、平板、PC）完美「適應」螢幕的解析度、大小與網路速度，自動調整最佳的內容呈現方式。讓開發者更方便快速能提供使用者更好的體驗。
（下圖是 Google 對 Responsive Web Design 和行動版的介紹）
知名程式設計學校 Treehouse 對 Responsive Design 的詮釋（很清楚）
- 用 Native App還是Responsive Design來設計產品比較好？
1. 成本
RD 的開發成本當然比請一個會開發 iOS 、Android 的開發者來的便宜許多，同時也快許多。另外，如果要開發行動版，其實製作過程很快，可能幾小時就完成了，但 RD 因為要對不同解析度做優化，自然花掉許多時間。
開發成本比一比：Native App > RD > 行動版網頁。
2. 流暢度、速度
Native 一定大勝，許多在操作的轉場、Loading 的速度，Native 比 RD 順暢非常多。另外，RD 有個缺點，就是需要大量 Jacascript、CSS 的載入，這對網路速度不快的台灣，絕對是一個拖累你使用者體驗的因素。
3. 行動端專屬的界面操作
如果你在行動端的產品上想做像是 Facebook Paper 的手勢操作（右滑、左滑、上移、下移……），RD 也辦不到，只能用 Native 開發 。
4. 審核
別忘了 Native App 後面還有 App Store 和 Google Play 要審核過你的 App 才能上架，在這過程中也必然會消耗你一定開發資源、成本和時間。
總結以上四點，我們可以說在 Native App 與 RD 開發間方式的選擇，就看你產品性質對行動端專屬的功能依賴深不深、口袋深不深、時間多不多來抉擇了。
但另外值得一提的是，在行動端的風潮已成主流後，你的網站「應該原本就是」響應式設計了，這不是一個選擇，這是必然需要優化的趨勢。
開發 App 用 Native 語言還是 Hybrid 好？Coder 你怎麼看？
正當大家興致勃勃地開始設計手機應用程式時，可能會遇到每個 Developers 和策略者都感到爭議的問題：「我應該利用原生語言（Native App)，還是混合模式 (Hybrid App）來開發我的手機程式呢？」
Native App：原生語言程式是為了特定的操作系統而編碼，用的也是特定操作系統的開發套件 (Platform SDK), 如 Apple iOS。因此它的性能和工具一向比 Hybrid App 優越。
Hybrid App： 混合語言程式的部份代碼會以 Web 技術編寫，如 HTML5, CSS 和 JavaScript。這些程式都是被包裹在原生容器 (Native Container) 和透過手機上的瀏覽器引擎來呈現 HTML 和執行 JavaScript。 Hybrid App 的優點是一個編碼程式能夠跨越不同的作業平台，不需要為每個操作系統編寫特定的編碼。
該選哪種語言好？
Developers 也因此常徘徊於該選用擁有優越性能和工具的 Native App，還是單碼跨平台的 Hybrid App 的頭痛抉擇裏。究竟有沒有明確的答案顯示哪一個開發語言程式才是最強最佳的代表呢？
其實，隨著手機操作系統不斷的更新，如近期的新版本的 iOS 和 Andriod, 都令手機的 Javascript 運行速度改善了不少。
這種改進令到 Hybrid App 的性能得到相當的提升，而它們的工具設備也日漸成熟了。現在已經有許多成熟又吸引的工具方案，如原生用戶介面 (Native UI) 和裝置應用程式介面 (Device API)，甚至有模擬器 （Simulators）、開發套件管理 (SDK Management)、裝置調試 (on-device debugging) 等等。
看來，人們對 Hybrid App 的開發已認真起來了。
當然， Hybrid App 的方案並不是完美萬能的，Native App 還有些地方是不能被取代，但現在 Hybrid 開發已經證明了它已經不遜於 Native 開發了。
要建造優良的 Hyrbrid App 是需要精心的策劃和考慮到裝置上的網絡平台獨特功能。在你準備向下個 Hybrid App 的大冒險前進時，有幾點是值得留意的：
1 . 關鍵特性，如 App 的性能
2. 把 Native 當做指引，從中學習
3. 選擇適當的開發工具，縮短與 Native App 的差距
Hybrid 和 Native 的爭論，就好像比較着蘋果和橙子哪樣較好，都是沒有贏家的。
就拿開發 Apple iOS Native App 來打過比例，你毋須思索都會自動想到用 IDE (XCode)，一系列的程式庫和 Object-C 編碼程式設計工具 (CocoaTouch, CoreGraphics, CoreData 等) 的開發工具來編寫 iOS Native App。
如果我們把這些豐富的資源去和 Hybrid 用的 HTML, JavaScript 和 CSS 來作比較，這根本就是一件不公道的事！你還沒有把 Hybrid 的跨平台這種優點包括在內呢！
Hybrid 除了能夠單碼跨平台外，還能夠讓你自由地選擇你喜歡的應用程式組合，如整合開發環境 (IDEs), 程式框架 (Frameworks), 程式工具 （tools) 和應用程式服務 (Services)。比起只支援單一平台 Native App，Hybrid App 無疑是更自由和更有彈性的首選。
程式的性能對所有的 Apps 來說是非常重要的一環，可是 Developers 常常把這部份留到最後。就是先把整個應用程式做好再慢慢調整它的性能。對一般的桌上電腦還可以接受，可是在資源和電能都有限的行動裝置上調整性能就會非常困難了。
如何解決這問題呢？答案就是將性能引入初步設計策劃裏，而不是留到最後才開始慢慢調整。
例如你在編碼前已預先計劃了你的 App 將會以 60fps (Frames per second) 運行，那麼你大概需要 17 milliseconds per frame 去執行程式碼和更新用戶界面 (UI)。這樣的時間根本不能提供流暢的運行，還很可能會令你的幀 （Frame） 出現問題呢。為求 Hybrid App 有更好的穩定性，建議採用 30 或 40fps 比較自然的運行速度。
另一個影響 Apps 性能的因素就是用戶界面設計。
影子效果，漸變色層，仿真的修飾設計是可以提高用戶界面仿真度，但也會同時消耗了很多裝置的資源啊。所以在設計用戶界面前先問問自己，這些資源消耗量大的仿真設計是必要的嗎？或是可以用消耗量較少的平面設計呢？
想拉近和你對手的距離，就要向他學習和熟悉他的招數。
設計 Hybrid Apps 也應如此的向 Native Apps 學習，嘗試熟悉 Native SDK 的環境反應和模擬它的設定。就拿 Apple iPhone 的滾動屏幕做例子，當你用手指頭在屏幕上下滾動，屏幕上的東西也隨著手指滾動的方向快速地移動。這樣的高性能和反應速度是怎樣做到的呢？就是用 iOS 的 UITableView, 它能夠重複地使用被移出屏幕的單元格 (Table cell)，載入新的資料，然後再次在屏幕的另一邊出現。
這種不斷重複利用單元格的技術叫做 『用戶界面虛擬化』。這種技術給使用者在一個在龐大的資料庫中滾動的假象，其實真正用到資料單元格是很少的。因為用到的單元格不多，所以這種技術能令 App 的運行速度更快速和更節省電力。
你能從上面學到什麼關鍵能用在 Hybrid 上嗎？很多呢！當中就是 UITableView 的單元格滾動技術。把 UITableView 變成 HTML DOM 的元素，用這方法去仿效 UITableView 來用在 Hybrid App 上，那麼 Developers 就能以類似的方式來重複使用或把 DOM 虛擬化來改進 Hybrid App 的滾動體驗了。
Hybrid 的開發是非常吸引的，因為能夠採用你熟悉的網頁技術來建造你的 App。可是這同時也是一個陷阱呢！記住不要把 Hybrid App 當成一個迷你和獨立的網頁來設計啊。建造理想 Hybrid App 的最佳守則就是細心研究和觀察 Native 平台和 SDK 的設計，學以致用再 Hybrid Apps 的開發上。
雖然開發 Hybrid Apps 的程式設計工具有很多，但一個優良的工具是會把網頁平台和 Native SDK 之間的的功能差距拉近。這樣子你就不需要擔心性能的問題了，因為這類的工具會在建設 Hybrid App 時把程式的性能元素包括在內。所以利用優良的工具能夠得到與 Native 模式相同的好處。
當然，你也可以自由地選擇適合你的開發工具並成功地建造你的 Hybrid App, 但當跨平台式和 App 的出品時間為你的首要條件時，你就應該選擇更優良開發工具來建造你的 Apps。
一個好的 Hybrid App 是不會在無意間產生的。就如同 Native App 一樣，建造優良的 Hybrid Apps 是需要把設計焦點放在性能和手機獨特的設計模式上。隨著手機網頁技術在近期不斷的提升，現已有很多很棒的跨平台開發工具。只要有稍微的性能設計和有合適的工具，要打造一個華麗的跨平台式 Hybrid App 已是一件輕而易舉的事了。
