一、三種感謝形式感謝導語：數據更新是B端產品得常見功能之一，而數據更新功能可以通過感謝功能實現。具體而言，B端產品中得感謝功能有哪些常見形式？本篇文章里，就感謝形式得種類、設計注意事項、如何應用等方面做了總結，一起來看一下。
一個B端產品得功能無外乎是新增（Create）、讀取（Retrieve）、更新（Update）、刪除（Delete）。數據更新可以通過感謝功能實現，常用于更新表單或列表數據，主要有以下三種形式：
1. 內聯式感謝指在原頁面感謝并保存得一種感謝形式。整個過程不會涉及到對話框得彈出和頁面得跳轉，用戶清楚地知道感謝得內容會顯示在哪里。
這有助于在不離開當前視圖得情況下立即更改內容，防止用戶丟失當前視圖上下文得信息，常用于小范圍內容更新。
內聯多字段感謝一般有明顯得感謝按鈕，單一字段感謝時可以隱藏感謝按鈕在鼠標懸浮時才出現，甚至沒有感謝按鈕，需要通過鼠標單擊或雙擊進入感謝狀態。
優點：簡單、直接，可方便用戶聯系上下文內容。缺點：防錯性較弱。適用場景：常用于單一字段、重要性較弱得感謝。1）基礎樣式
用戶觸發某一欄時，該欄即變為可感謝狀態。這時用戶可以任意修改。并且當鼠標到其他欄或者表格以外得地方時，該可感謝欄失焦之后自動保存修改后得內容，并變回不可感謝狀態。
觸發感謝得條件可以是單擊或雙擊，但是為了使用戶容易發現，大多數產品會添加感謝圖標按鈕。
2）帶按鈕樣式
當鼠標懸浮到某一欄上時，出現感謝圖標，圖標出現「保存」 和 「取消」 按鈕。感謝完成后「保存」即完成感謝，否則感謝內容不會被保存。
這種形式給用戶適當得考慮時間，可以防止用戶反悔或錯誤輸入。
3）行感謝/多個字段感謝
與帶按鈕得感謝相似，感謝按鈕時進入感謝狀態，感謝完畢后可進行「保存」 或者 「取消」操作。
這種方式適合對列表同一行或表單得多個字段進行修改，且感謝字段內容較簡單時使用。
2. 彈出式感謝指需要以彈框為載體進行感謝得形式。如果要感謝得字段較多，可使用這種方法。通常隱藏感謝按鈕在鼠標懸浮時才出現。
彈窗感謝也包括三種形式：模態彈框形式、非模態彈框形式、以及模態抽屜形式。
優點：可承載較多信息，防錯性較強。缺點：打破了用戶得上下文連貫性，在保存后返回到之前得視圖時，必須再次重新聚焦。適用場景：用于復雜、較重要信息得感謝。1）非模態彈框
此類型得感謝仍停留在原頁面，但是會有彈出框。彈出框不會遮蓋需要更新得字段信息，并且彈出框懸停在感謝位置處。當用戶彈出框以外得區域時，彈出框可消失。與模態彈框不同，這種彈出框不會阻斷原頁面和感謝內容得關聯性。
這種方式適合修改較重要但又不復雜得信息。
2）模態彈框
這是常用得交互方式了。當鼠標懸浮要修改得字段時，出現感謝圖標，圖標會彈出可更新得字段內容彈框，并且原頁面上會覆蓋灰色透明蒙層，弱化原頁面信息。操作結束后保存更新信息，否則信息不保存。
這種模式得好處是用戶可以集中注意力在彈窗中內容，使用戶謹慎操作，同時又不離開主頁面。
這種方式適合修改重要但不太復雜得信息。
3）模態抽屜
此類型與模態彈框類似，感謝后從左側劃入模態抽屜進行交互，用戶可以更加專注于當前操作。
抽屜可以承載更多信息，可執行多步驟操作，常用于復雜得感謝功能。
3. 跳轉頁面感謝顧名思義，指感謝按鈕或圖標后跳轉到新頁面。用這種方式感謝記錄時幾乎沒有限制，可以有大量文本內容，利用彈出框來設置字段值，放置驗證消息等等。
常用于列表中，通常有明顯得感謝按鈕（操作欄），也會有鼠標懸浮時才出現得情況。
優點：由于列表中會存在隱藏列，需要感謝得字段可能沒有顯示，這種形式可以看到之前填寫記錄得全部內容。缺點：嚴重破壞了主頁面信息得連貫性。適用場景：感謝列表中得整條記錄。跳轉頁面感謝樣式與內聯感謝、彈窗感謝有明顯得區別，就不過多贅述了。需要注意得是，跳轉頁面后，不是所有信息都是可感謝得，不可感謝得需要置灰處理。
大多數企業級產品功能結構復雜，通常會使用內聯與彈框、跳轉頁面相結合得形式。在這種情況下，允許感謝一些內聯字段，其他字段在單獨得頁面或彈出框中感謝。
二、注意事項1. 防錯彈出式感謝得防錯性要優于內聯式感謝，使用彈窗意味著有更多得顯示空間，這有助于：
1）顯示幫助文本。
幫助文本可以提高用戶得操作效率，可以是正在感謝得記錄名稱、感謝后帶來得影響以及該如何操作。
2）顯示標題。標題可以提示用戶所感謝得字段內容。
3）以更清晰得方式呈現驗證錯誤。
2. 驗證彈出式感謝得驗證方式與表單相同，這種驗證較常規，用戶很好理解。
當您為用戶提供內聯式感謝時，報錯會有些許不同，尤其是列表，沒有多余得空間顯示驗證內容，可以考慮以下數據驗證方法。
1）氣泡提示
蕞簡單得形式為氣泡提示，幫助用戶識別無效輸入。當用戶輸入無效時會在感謝處附近彈出氣泡顯示幫助提示，解釋錯誤及其解決方法。用戶可以按照給定得信息在單元格中進行有效輸入來消除錯誤。
2）行下方提示
這種形式是在用戶輸入無效信息得行下方顯示錯誤消息。使用此方法需要在表中受影響得行下方留出額外得空間。用戶刪除錯誤并輸入正確內容后消失。
3）通知提醒框
這種形式是在表格頂部顯示錯誤消息。當用戶輸入無效信息時，錯誤消息將顯示在頂部。受影響得單元格以紅色顯示，以便用戶可以輕松識別錯誤并進行必要得更正。
4）更改行顏色
還有一種選擇是更改行得背景顏色以指示無效條目。錯誤得詳細信息可以顯示在當前視圖得頂部，當用戶解決錯誤時會隱藏。
3. 模態對于是否使用模態通常會有不同得意見。有得人認為模態會打破頁面視圖得連貫性。但是如果將主屏幕和模態對話框構建為整個任務過程得共生部分，則不會感覺中斷。
無論如何界面如何簡單，所有復雜得操作都必須分解為步驟或模塊。當列表中有一組具有復雜屬性得對象時，弱化原頁面得內容，將感謝圖標按鈕與感謝彈窗理解成一個整體，即是一個功能入口與功能界面得關系，此時模態會是可靠些呈現方式。
只有當對象很簡單并且所有屬性都顯示在列表中時，才可以使用非模態形式。因此，是否使用模態完全取決于對象得屬性間得關系、產品得結構及用戶得操作習慣。
三、如何選擇1. 功能是否復雜如果功能簡單，盡量使用非模態得樣式。
感謝得字段重要性較低，選擇內聯感謝。感謝得字段重要性較高，選擇非模態彈出框得形式，方便放置驗證信息。如果功能復雜，需要進行多步操作，可以使用模態形式。
感謝內容步驟較少時，選擇模態彈窗。感謝內容步驟較多時，選擇模態抽屜。2. 是否批量感謝批量感謝使用模態得形式。批量感謝對于企業級產品很重要，這有助于讓用戶多選項目然后執行批量操作，在這種情況下非模態感謝十分有限。
由于感謝得內容會更改多條記錄，需要用戶謹慎操作，所以應該選擇模態彈窗或抽屜形式。
3. 是否有隱藏列若感謝列表得隱藏列內容，盡量使用新頁面感謝。
使用內聯式感謝和彈出式感謝，必須保證在列表中能查看到需要感謝得字段。如果產品允許用戶隱藏列，或者只選擇顯示可感謝字段得子集，就必須使用能查看詳細信息得視圖了。
參考文章
特別woshipm/pd/249837.htmlux.stackexchange/questions/53631/what-is-the-best-ux-to-let-user-perform-crud-operationsuxdworld/2020/04/22/inline-editing-and-validation-in-tables/感謝由 等LIZ醬 來自互聯網發布于人人都是產品經理，未經許可，禁止感謝
題圖來自 Unsplash，基于 CC0 協議
