中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編寫軟件時，工程師們會用很多不同的方法來關注用戶:例如聽取用戶的反饋，修正bug或添加用戶呼吁的特性。由于基于網絡的服務讓用戶能夠更容易地轉向新的應用，建立和維持用戶的信任就變得更加重要。我們發現了一種雖然確實違反直覺，但極其有效的方法來獲取并保持用戶的信任，那就是讓用戶能容易地帶著他們的數據離開你的產品。這不僅能防止鎖定并獲得信任，還可以迫使你的團隊為獲取技術優勢而不斷創新和競爭。我們管這叫“數據解放”。

鎖定帶來的問題

對軟件工程師來說，從他們使用的服務中導出數據顯然要比一般用戶來得容易的多。如果有可用的API，我們工程師可以隨便拼湊個程序來搞定。就算沒有API，用屏幕截圖工具也能弄到一份數據的副本。不幸的是，對大多數用戶來說這并不可行，他們經常只能疑惑于到底能不能拿到自己的數據。直到最近，用戶在向一個新的互聯網服務中輸入大量的個人數據之前，幾乎都不會問是否能夠把他們的數據快捷地取出來。他們更可能問這些問題：“我的朋友們也在用這個嗎？” “這個可靠嗎？” “提供這項服務的公司半年或一年后還存在的概率是多少？” 然而，隨著用戶們將越來越多的個人數據存儲到無法觸及的網絡服務當中，他們開始意識到如果沒有遷移數據的方法，他們大量的網絡遺產就會有丟失的風險。將用戶鎖定的好處是讓他們難以離開你而轉投你的競爭對手。同樣地，如果你的對手鎖定了他們的用戶，那這些用戶也很難轉向你的產品。盡管如此，將研發精力投入到創新上要比建立壁壘來阻止用戶離開更可取?，F在，讓用戶能更容易地試驗產品會極大地提升他們對你的信任，未來也更有可能回到你的產品線來。

緊迫感

鎖定用戶會讓公司變得并不急于創新。相反，出于商業原因，公司可能會決定延緩你們產品的開發，并把開發資源轉移到其他產品上。這將使你的產品在與其他創新速率更快的公司的競爭中處于弱勢地位。鎖定讓公司得到一個持續成功的表象，但失去了創新的支持，它實際上可能已經在走向夭折了。

如果你不想——或不能——鎖定你的用戶，那么參與競爭的最佳方式就是急速地創新。以Google搜索為例，這是一種無法鎖定用戶的產品：用戶不需要安裝軟件，不需要上傳數據，也不需要簽什么合同; 如果他們想嘗試其他搜索引擎，只要在瀏覽器中輸入地址，就絕塵而去了。

Google的搜索引擎是怎么留住用戶的呢？近乎執迷地專注于持續提升搜索質量。用戶可以輕易地轉移到其他服務這一事實已經向Google的搜索質量和排名團隊灌輸了一種驚人的緊迫感。在Google，我們認為如果讓用戶能夠容易地離開我們的任何產品，對產品改進的失敗就能立即反饋到工程師那里，他們則會開發更好的產品作為回應。

數據解放是什么樣的
在Google，我們的態度是用戶應該能夠控制他們在我們的產品中存儲的數據，這意味著他們能導出自己的數據。這不需要額外的金錢支出，更重要的是，不管數據總量大小，導出數據的工作量應該是一定的。分開下載一打照片不會帶來多大的不便，但如果用戶不得不一張一張地下載5000張照片呢？這得花上兩周的時間。

如果以專有的格式存儲，就算用戶有了數據的副本，依然是被鎖定的。一些15年前的文字處理工具生成的文檔無法用現在的軟件打開，就是因為它們是以專有格式保存的。所以重要的不僅是能夠訪問數據，還要能將其以廣泛接受的標準格式存儲。而且，這個標準應該有合理的許可條款：例如，對實現應當是無版權約束的。對于導出的數據，如果已經存在一種開放的格式（例如對于照片有JPEG或TIFF格式），就應該成為批量下載時的一個選擇。如果產品中的數據還沒有一種工業標準（比如blog就沒有標準的數據格式），那么至少這種格式應該是文檔公開的——要是你的產品能提供一個開源的格式轉換器的參考實現就更好了。

重點在于用戶對他們的數據應該有控制權，這意味著他們需要一種便捷的方式來訪問數據。提供一套API或者一次下載5000張照片的能力并不完全能夠讓一般用戶容易地導入導出數據。從用戶界面的角度看，數據解放對用戶來說就是一組用于導入或導出所有數據的按鈕。

Google通過”數據解放前線”(Data Liberation Front)來解決這個問題，這是一個以簡化Google產品的數據導入導出為目標的研發團隊。數據解放的工作重點是可能阻礙用戶轉移到其他服務或同類產品的數據——即那些用戶創建或導入的數據。這些都是用戶通過直接操作而有意存儲的數據——例如照片，Email，文檔或廣告方案——如果用戶在別的地方開展業務，很可能會需要這些數據的副本。而間接產生的數據（比如日志數據）與鎖定無關，因此不在任務的范圍內。

另外一件數據解放不會去做的事是建立新標準：我們盡可能地讓用戶以現有的格式導出數據，比如在Google Docs中用戶可以用OpenOffice或微軟Office的格式下載文檔。對于有些產品，還沒有一種開放的格式能包含所有必要的信息，我們會提供計算機易讀的格式，比如XML（我們使用Atom處理包含內容和評論的Blogger源），開放它的文檔，并且，可能的話，提供格式轉換器的參考實現（例如Google Blog Converters AppEngine項目）。我們希望提供給用戶的數據格式能易于導入到其他產品中。由于Google Docs所處理的文檔和電子表格始于開放的互聯網興起之前，所以我們提供了幾種不同的導出格式；而對于大多數產品，我們則盡量避免陷入“要支持所有已知格式”的泥沼中。

用戶的考慮

在這幾種情況下，用戶可能想要從你的產品中獲得數據的副本：他們找到了更符合他們需求的產品，想把數據轉移過去；你們宣布停止對他們正在使用的產品的支持；或者更糟的是，你做了一些失信于他們的事。

當然，用戶想要一份數據的副本并不一定意味著他們要放棄你的產品。許多用戶只是覺得在本地保存一份數據的備份會更安全。當我們首先“解放”Blogger時，觀察到了這種情況：許多用戶開始每周導出一次日志，同時還在繼續使用Blogger寫博客。這種情況更多地出于感性而非理性因素。用戶自己電腦中的大多數數據根本沒有備份，但托管的應用為了防范硬件錯誤和自然災害，幾乎都會在多個地點保存多份用戶數據的備份。不論用戶的憂慮是否理性，他們需要感到自己的數據是安全的：讓你的用戶信任你，這很重要。

案例分析：GOOGLE SITES

Google Sites是一款網站制作工具，可以通過瀏覽器進行所見即所得的編輯。在Google內部我們使用它編輯項目的頁面，因為它能方便地創建和整合項目文檔。2009年初我們承擔了為Sites開發數據導入導出功能的工作。

在設計之初，我們需要決定Google Site應該使用什么樣的外部文件格式?？紤]到Sites提供的功能是協作創建網站，我們覺得要實現真正的解放，最適合的格式是XHTML。作為網頁的開發語言，HTML也是網站最輕便的存儲格式：只需要把XHTML頁面放到你自己的網絡服務器上，或者把它們上傳到網絡服務提供商那里。我們希望確保這種形式的數據可移動性能盡可能地簡單，同時盡可能地減少數據損失。

Sites用它內部的數據格式封裝一個網站中存儲的所有數據，包括對所有頁面的修改。解放這些數據的第一步是創建一套Google Data API。一個網站的完整導出由應用Google Sites Data API的開源Java客戶端工具提供，并且將數據轉換為一組XHTML頁面的集合。

與其他Google Data API相同，Google Sites Data API也是基于AtomPub標準開發的。它支持以Atom文檔作為線上傳輸格式對Google Sites進行RPC（遠程過程控制）式的程序化的訪問。數據可以很容易地封裝為Atom的形式，因此在Google Sites的用例中Atom工作得很好。

這是一個Atom條目的范例，封裝了Sites中的一個網頁?？梢杂肅ontent Feed將它還原到Google Sites。

我們用粗體標出了實際被導出的數據，包括一個標識符、以ISO 8601格式表示的最后更新時間、標題、版本號和網頁的實際內容。為了簡化范例，強制認證元素和其他可選的信息被去掉了。一旦API準備就緒，第二步就是實現從一組Atom源到一組可移動的XHTML網頁的轉換。為了防止數據丟失，我們將每個Atom條目的元數據都嵌入到轉換的XHTML中。如果在轉換得到的頁面中沒有這些元數據，就說明在導入過程中出現了問題——無法確定XHTML的元素與原有Atom條目的對應關系。幸運的是，我們不用自己發明元數據嵌入技術；只要用hAtom微格式就行。

以剛才的范例來說明微格式的功能,下面是轉換后的嵌入了hAtom微格式的XHTML：

案例分析：BLOGGER

我們在做數據解放項目時經常遇到的一個問題是如何滿足高級用戶。這是我們最喜愛的用戶。他們喜歡用我們的服務，存入了大量的數據，并且希望能夠方便地隨時導入或導出大量的數據。例如，五年間更新的日志和照片很容易就能達到幾個G的容量，想要一舉移動這么多數據確實很有挑戰性。為了讓導入導出操作對用戶來說盡可能簡單，我們決定實現一種一鍵式的方案，向用戶提供一個Blogger導出文件，其中包括所有的文章、評論、統計頁面，甚至每個Blogger博客的設置。這個文件會被下載到用戶的硬盤里，還可以重新導入到Blogger，或者轉換后遷移到其他博客服務。

我們在建立Blogger的導入導出體驗時犯的一個錯誤是，在一次導入或導出操作時依賴單個HTTP事務。當傳輸的數據量變大時，HTTP連接會變得很脆弱。連接只要中斷就會使操作無效，造成導出不完整或導入時數據丟失。對用戶來說這是很令人沮喪的情況，而不幸的是，對于數據量較大的高級用戶，這種情況更加常見。我們也忽略了部分導出的功能，導致高級用戶在導入時為了獲得更好的效果，有時需要采取笨拙的手段，例如手動分割導出的文件。我們意識到這對用戶來說是糟糕的體驗，我們希望在Blogger未來的版本中改正這個問題。

一個同我們處于競爭地位的博客平臺采用了一種更好的方法，當在基于云的博客服務間遷移大量數據時，不以用戶的硬盤作為中介。提供數據解放的最好方式是API，而提供數據可移動性的最好方式是用這些API實現云對云的遷移。這種遷移方式需要服務間的多個RPC來分散移動數據，每個RPC都可以在失敗時自動重試，而無需用戶的干預。比起單事務的導入操作，這種模型要好的多。它增加了成功率，并且帶給用戶更好的整體體驗。但只有每項云服務都為用戶的所有數據提供用于解放的API時，真正的云對云的數據可移動性才能得到體現。

挑戰

正如你從這些案例中看到的，數據解放之路的第一步就是決定用戶到底需要導出什么。一旦涉及用戶自己創建或導入到你產品中的數據，情況就會變得復雜起來。以Google Docs為例：用戶做導出操作時，顯然對自己創建的文檔具有所有權，但是那些他修改過的由別人創建的文檔呢？他只擁有閱讀權限的文檔又如何？如果考慮到所有可讀的文檔，用戶有閱讀權限的文檔數量會遠遠大于他實際讀寫過的文檔數。最后，你還要考慮到諸如訪問控制列表這樣的元數據文檔。這只是個例子，但適用于任何允許用戶分享或協作處理數據的產品。

另一項需要緊記的挑戰是安全性和授權。當你使用戶可以非?？旖莸貙С鰯祿r，也就大大減少了攻擊者帶著你全部數據逃跑所需的時間。這就是為什么最好在導出敏感數據（例如搜索歷史）前強制用戶進行授權，并且對用戶發送導出操作通知（例如用email通知用戶發生了導出操作）。我們在解放更多產品時，也一直在探索這些機制。

巨大的數據集合會產生另一個挑戰。例如，一組數量很多的照片數據量很容易達到幾個G，在當前大多數家庭的網絡傳輸速度下就會造成一些困難。在這種情況下，我們或者提供一個可以與網絡同步數據的客戶端（例如Picasa），或者依靠已有的協議和API（例如Gmail使用的POP和IMAP協議）來讓用戶逐漸地同步或導出數據。

結論

允許用戶獲取數據的副本只是數據解放征途的第一步：要實現讓用戶可以容易地在互聯網上將數據在各種產品之間遷移的目標，我們還有很長的路要走。我們期待在未來，工程師們可以不用為數據的搬運費心，而更多地專注于開發有趣的產品，以技術優勢來競爭——而非通過綁架用戶的方式。把對數據的控制權交給用戶，對于建立用戶信任來說是很重要的一個部分。我們希望更多的公司能夠認識到，如果想長久地留住用戶，最好的方式是讓他們獲得自由。

來源：http://article.yeeyan.org/view/178353/144453