国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

本文介紹了產(chǎn)品設計中的3中保存邏輯，包括：手動保存、自動保存、提示保存。

產(chǎn)品經(jīng)理在設計產(chǎn)品的時候要注重打造細節(jié)，在一個小點中做到極致，并適當加入一些小創(chuàng)意，這樣能提升品牌形象和用戶忠誠度。特別在交互設計、視覺體驗上，要做多種情況的產(chǎn)品處理。

隨著 B 端產(chǎn)品的持續(xù)發(fā)展，B 端產(chǎn)品的前端由于直接展示給用戶。

因此往往對于圖片質(zhì)量、頁面配色等都經(jīng)過 UI 的仔細打磨，后臺產(chǎn)品則由于圖片少、文字多；內(nèi)容展示少、表格多而在界面上慘不忍睹。

作為后臺產(chǎn)品經(jīng)理，雖說我們不用對產(chǎn)品界面配色負責，但是產(chǎn)品的每一處細節(jié)都應該仔細雕琢，做到貼合場景、使用方便、效率高等特點。

說到存儲，大家所能想到的功能想必就是[保存]了吧，正如上文，本篇就對保存按鈕來細說下其中的邏輯：

一、手動保存

這是一個非常常見的「編輯 – 保存」頁面，一般來說，這類頁面的邏輯分成兩種：一類是單獨有個保存按鈕進行保存；另一類是修改一項生效一項，無需額外保存。

單獨按鈕保存，常見于后臺管理系統(tǒng)、或者是移動端的資料編輯頁面上。

以 Form 為單位，一次把所有內(nèi)容提交到后臺。單獨設置保存按鈕，我們可以在保存邏輯執(zhí)行前通過彈窗；讓用戶對操作進行確認，通過點擊「保存」或者「取消」，來讓用戶決定是否執(zhí)行保存。

試想，對于一個編輯用戶頁面，如果走的是立即生效的邏輯，很可能我們無意間的一些隨意的修改，就把數(shù)據(jù)改掉了。比如無意間刪除了用戶名字中的一個字，除非我們記得這個字是什么然后手動改回來，我們是無法「撤銷」我們的操作的。

另外，對于一些依賴于其他輸入項的表單驗證行為，我們也需要當用戶修改完所有項目后，統(tǒng)一進行驗證和提交服務器。例如修改密碼頁面。

1. 草稿箱

該不該做草稿箱功能呢？

這里根據(jù)我對不同產(chǎn)品的觀察，總結出來以下兩個維度，可以作為參考衡量。

1）創(chuàng)作復雜度

越是操作越多才能完成的內(nèi)容，就越需要草稿保存的功能，防止用戶誤操作而導致前功盡棄。

這類的例子，很多比如前段時間為女朋友編輯發(fā)個說說花了大半個小時，結果一不小心手抖返回了；而內(nèi)容沒保存，剛剛寫的煽情的話是啥來著。

2）重要程度

什么內(nèi)容重要，這是不太好去定義的，除非給出具體場景。

比如辦公場景，我們用 Word 寫文檔，寫了一天突然斷電，電腦黑屏，整個人瞬間都機靈了一下。

來電的時候，用自己顫顫巍巍的小手，戳一下開機鍵，打開 Word 文檔，彈出一個對話框，”有文檔未正確關閉，是否需要恢復編輯“，倆眼一放光，歘的一聲，點了確定。

看到斷電前寫的文檔，不進感嘆，真香！剛剛這兩個維度，可以幫助我們在工作中要不要考慮幫助用戶做草稿保存的功能。

2. 本地存儲

空間說說中，如果你也注意到，也會發(fā)現(xiàn)有許多地方幫助用戶保存未完成的內(nèi)容。

這里說兩個地方：

1）發(fā)布說說中斷，會提示是否保留此次編輯。如果保留，下次進來會直接使用當前編輯的內(nèi)容，很多內(nèi)容不需要再次編輯。比如選擇圖片，輸入文字等；

2）在空間信息流中，如果你給朋友的某個動態(tài)發(fā)表評論，但寫了一句，沒發(fā)布；繼續(xù)看空間下面別的信息，過一會，回頭如果再點開剛剛那個說說的那一條動態(tài)給評論；你就會發(fā)現(xiàn)剛剛編輯的那句話竟然還在，可以接著編輯。

3. 云端存儲

說起云端存儲就有人會問怎么判斷：某個產(chǎn)品的某些功能中保存類似草稿內(nèi)容是存在用戶端本地呢，還是上傳到平臺服務器端了呢？

這里有一個小方法：換一個終端設備登錄，看看還能不能看到之前編輯的草稿內(nèi)容。

如果能看到，則保存的未完成的內(nèi)容是備份到服務器端的，如果看不到之前的草稿內(nèi)容，則是保存在用戶終端的。

根據(jù)這個小方法測試發(fā)現(xiàn)：印象筆記，在用戶編輯內(nèi)容的時候，會程序化自動周期性備份內(nèi)容到服務器端。QQ的草稿箱，一個是發(fā)布說說草稿，一個是評價好友動態(tài)草稿，均保為本地存儲，換了設備登錄是看不到之前編輯的草稿內(nèi)容。

1.3.1 草稿應不應該上傳云端呢

1）必要程度

弄明白為什么需要用戶草稿箱的具體內(nèi)容，如果不上傳具體草稿箱內(nèi)容是不是可以；如果上傳到平臺上來，下一步能干什么，這些數(shù)據(jù)是不是對產(chǎn)品或運營策略有實際的用途。

比如我們都很熟悉的電商平臺的購物車功能，這就是我們購買產(chǎn)品的草稿箱。而且這些數(shù)據(jù)也確實上傳到了平臺，平臺通過技術手段，結合用戶購物車數(shù)據(jù)，實現(xiàn)個性化營銷。千人千面，進一步完成銷售的目的，那么這是必要的。

再看，像抖音內(nèi)容草稿箱、微信發(fā)布朋友圈草稿等；就算把草稿內(nèi)容上傳到平臺，但對產(chǎn)品運營沒有實際支撐用途，也是沒有必要的。

2）隱私程度

雖然說互聯(lián)網(wǎng)的世界里面沒有隱私，但能做的還是得做。至少平臺本身得去幫助用戶，解決一些不必要的隱私泄露問題。

從隱私的維度看，越是隱私的未發(fā)布的內(nèi)容，就要盡量讓數(shù)據(jù)保留在用戶自己手里。

平臺可以通過技術獲取用戶草稿箱的統(tǒng)計數(shù)據(jù)，或者特征數(shù)據(jù)。宏觀層面的，比如不同用戶一般有多少條草稿內(nèi)容。但，確實是沒必要去獲取用戶草稿具體內(nèi)容的，原因很簡單，用戶沒公開發(fā)布。

要知道在社交平臺用戶注重隱私，多一個存儲位置備份，就多一份風險。

二、自動保存

1. 延遲草稿存儲

目前市面上大部分產(chǎn)品都具備延遲存儲功能，例如：Word、Axure、Xmind、ZBrush、CAD、PohtoShop等等；特點：

• 在工作暫停間隙間自動保存；
• 如果沒有連續(xù)工作沒有暫停，則每隔X分鐘自動保存一次（時間可由用戶設置）；
• 在后臺默默地保存，沒有提示和進度條，不會干擾用戶；

目前在這方面MAC做的比較全面

2. 隨機草稿存儲

特點：

• 每隔幾秒自動保存一次；
• 可以看到上次自動保存的時間，并且可以手動保存；
• 所有自動保存的版本都留著，可以隨時回退到其中的任何一個版本；
• 在WordPress.com上撰寫和編輯帖子和頁面時，所做的更改每隔幾秒鐘會自動保存一次。在在編輯器右上方的發(fā)布模塊，你會看到從通知舉動保存草稿到自動保存到已保存。

以簡書為例：簡書中的編輯器即草稿箱，每次修改都會隨時保存，“發(fā)布文章”按鈕自動變成“保存中…”以提示正在保存。

點擊“發(fā)布文章”按鈕，文章發(fā)布，按鈕變成“已發(fā)布”。

對于“已發(fā)布”的文章，再次編輯時，依然會出現(xiàn)“保存中…”字樣提示正在保存。已發(fā)布的文章自動保存后，按鈕變成如下的“發(fā)布更新”，再次點擊后才會變成“已發(fā)布”。

3. 條件草稿存儲

特點：

• 每隔一段時間或者一個觸發(fā)條件自動保存一次；
• 當用戶手動關閉文檔之后，自動保存的版本會被清空（部分可選擇是否保存歷史記錄）；
• 如果是非正常關閉，如電腦死機或者斷電，異常自動保存的版本會保存在硬盤上；
• 當你打開文件時，如果檢測到一個異常自動保存的文件，它會提示你保存或者打開該文件；

條件存儲顧名思義就是由某個條件觸發(fā)從而達到保存的目的，比如PohtoShop中的歷史記錄功能，就是根據(jù)用戶使用工具后到使用下一個工具前作為觸發(fā)條件進行存儲記錄。不過因為步驟較為繁瑣這些操作存儲都為本地存儲，并未上傳云端。

Microsoft：對表單所做的任何更改將在更改后30秒自動保存。

如果未對表單進行任何更改，則在打開表單時不會自動保存。進行更改后的30秒內(nèi)，將再次開始自動保存。某人當前正在編輯的字段不包括在自動保存中。如果其他人在編輯時更新了同一條記錄，那么當自動保存時，這些更改將被檢索并顯示在表單中。

以簡書為例：簡書編輯是在0.5S左右會自動保存一次，通過抓包可以看到在編輯的時候如圖所示：

可以得知每次編輯之后簡書都會向服務器對應的url發(fā)送數(shù)據(jù)；需要注意的是發(fā)送的方式為put而不是post。

因此不難得出，在實現(xiàn)類似自動保存功能的時候，需要向服務器put方式發(fā)送數(shù)據(jù)，并且在檢測到鼠標沒有輸入之后的0.5S左右自動想服務器put一次數(shù)據(jù)。

簡單地說：通常用于向服務器發(fā)送請求。

• 如果URI不存在，則要求服務器根據(jù)請求創(chuàng)建資源，如果存在，服務器就接受請求內(nèi)容，并修改URI資源的原始版本?！狿UT請求那些封裝在Request-URI的實體。
• 如果Request-URI引用一個已存在的資源，則該封裝實體應該作為原始服務器上的修改版本。
• 如果Request-URI不是指向一個已存在的資源，并且該URI可被請求的用戶代碼定義為新資源，則原始服務器可用此URI創(chuàng)建新的資源。
• 如果新的資源被創(chuàng)建，這個原始服務器就必須通過201（Created）響應通知用戶代理。
• 如果已有資源被修改，則發(fā)送200或者204響應，表示成功完成了該請求。
• 如果Request-URI既沒有創(chuàng)建也沒有修改資源，則應給予適當?shù)腻e誤響應來反映問題本質(zhì)。實體的接受者不能忽略任何不理解或沒有實現(xiàn)的Content-*（如Content-Range）頭部，并且必須返回501響應。
• 如果請求經(jīng)過緩存，并且Request-URI標識出一個或多個當前緩存的實體，則那些實體視為過期了，該方法的響應不會被緩存。POST請求的URI表示處理該封閉實體的資源，該資源可能是個數(shù)據(jù)接收過程、某種協(xié)議的網(wǎng)關、或者接收注解的獨立實體。然而，PUT請求中的URI表示請求中封閉的實體-用戶代理知道URI的目標，并且服務器無法將請求應用到其他資源。
• 如果服務器希望該請求應用到另一個URI，就必須發(fā)送一個301響應；用戶代理可通過自己的判斷來決定是否轉發(fā)該請求。

三、提示保存

Toast提示保存也是我們最常見的提示，提示保存基本用于所有用到內(nèi)容型的產(chǎn)品。

當監(jiān)測到用戶有編輯行為但沒有保存就想跳轉或離開的時候，彈出一個溫馨的提示：您是否需要保存呢？

用戶可以選擇去保存或者直接離開，用提示保存的辦法就可以基本杜絕用戶忘記保存的問題。

四、總結

在做保存功能時候也要注意一些注意事項：

• 有些組件很難定義何時自動保存。比如輸入框里，在編輯一大堆文字的時候，系統(tǒng)很難判斷何時用戶輸入完畢并做保存。
• 每做一步就生效，沒有容錯余地。假想每一個操作執(zhí)行就立即生效不能反悔，那你真的不敢輕易操作表單了。一個閃失造成錯誤或資損那可不是開玩笑的。
• 頻繁保存造成的干擾和系統(tǒng)壓力。每一步操作就保存生效必然帶來每一步保存成功的提醒。頻繁的成功提示真的會很干擾用戶的沉浸操作。另外如此頻繁的調(diào)用保存接口對于系統(tǒng)也有一定壓力。

很多表單組件很可能你會覺得微不足道，但簡單的組件也會有很多體驗細節(jié)。我們在設計時需要結合用戶心智、產(chǎn)品特點、場景、統(tǒng)一性等綜合考慮。

也許你會有設計規(guī)范，但當已有的組件影響到了用戶體驗和業(yè)務目標時，你要去判斷組件是否不合時宜。

本文由 @阿東 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載

題圖來自正版圖庫 圖蟲創(chuàng)意