如果沒有瀏覽態

　　對於一個使用者可以修改的頁面，最傳統、最可靠的方式：瀏覽態+編輯態

　　在瀏覽態的頁面上點擊“修改”按鈕，進入編輯狀態。

　　這樣可以用瀏覽態很清晰的告訴使用者當前儲存的表單內容是什麼樣的。在編輯態修改好之後，儲存，回到瀏覽態。

　　這種方式有自己的問題：如果原本只是要修改某一項內容，也需要點“修改”按鈕，進入編輯態，再重新找到那項，修改。內容很多的時候，在編輯態頁面中再找一遍，找到剛才看好要修改的那項，還是挺吃力的。

　　在實際的應用中經常會只有編輯態。

　　很多設定檔頁、設定頁通常都只有編輯態。只有編輯態的好處是所見即可修改。看到了某項內容，想修改，直接就可以改。輸入框、單選、複選…這些表單元件都可以既展示又修改。

　　只有編輯態的方式也存在一些問題：“當前頁面中有沒有修改?”“是否需要儲存?”“我忘記了剛才的修改有沒有儲存過，再按一次儲存?”“確實儲存了嗎?咋和沒點儲存按鈕之前完全一樣?”

　　“瀏覽態+編輯態”的設計模式是原始的，是技術局限下的產物。

　　“所見即所得 (WYSIWYG)”是被廣泛應用的一個設計原則，設計師們不管用得上用不上，只要能靠上點兒邊兒都願意往這個原則上靠。

　　前面描述的那種只有編輯態的方式不是“所見即所得 (WYSIWYG)”好的範例。我們來看看 MS word：

　　當前看到的樣子就是這份文檔實際的樣子，隨時可以編輯。

　　寫一篇blog的時候是怎樣的?發表、編輯是一個介面，實際瀏覽的時候是另外一個介面，兩個介面的差別還是不小的。是的，blog是“瀏覽態+編輯態”的設計模式。

　　顯然word更好。blog的展示有很高的要求，排版布局、圖片位置、字型樣式、行距…如果能做到像word一樣，估計頁面就打不開了。

　　有沒有更好的方案?

　　並不是所有的允許使用者修改內容的頁面對顯示都有那麼高的要求，前面提到的那些設定頁面、設定檔之類的頁面使用者更改的只是內容，那麼，這類產品的設計有沒有可能突破只是編輯態的困惑，又避免瀏覽態+編輯態帶來的麻煩呢?

　　“編輯態+瀏覽態”的缺陷是：看到了不能直接改。

　　“只有編輯態”的缺陷是：當前是否做了修改，說明的不夠清楚。

　　我們來嘗試沒有瀏覽態的最佳化方案：

　　這個方案是在編輯態的基礎上添加一個狀態說明，始終提示是否有修改。避免了原先只有編輯態的狀態不清問題。因為是在編輯態的基礎的最佳化，所以顯然“瀏覽態+編輯態”模式的缺陷也不存在。

　　對排版要求不那麼高的google notebook、google doc的設計實際上就是這個方案。只是在這個方案的基礎上再加入了自動儲存的功能。

　　我們順著這個方案再往下想：

　　如果頁面中的那些輸入框、下拉選擇框…在未操作的時候使用一種樣式能顯示的不那麼搶眼，而在使用者觸發操作時使用系統的標準樣式，這樣，頁面平時看上去就很接近瀏覽態了。那麼，無修改的時候也可以不再提示…

　　沒有修改，只是瀏覽時，不需要再特意的提示“內容無修改，不需儲存。”而是用近似於瀏覽態的樣式給使用者暗示可修改。雖然看上去像是瀏覽態，但使用者卻可以隨時修改…

　　當使用者修改了其中的內容時：

　　嗯，就是這麼個方案。實際上這個方案是將編輯態隱藏了起來，使用者觸發編輯操作時自動切換到編輯態。

　　“只有編輯態”是不夠清晰的，“編輯態+瀏覽態”也不是萬能藥。

　　減少頁面，減少認知成本;隨時可編輯;足夠的狀態提示，基於目前的技術，這些是最佳化的目標，還有其他更好的方案嗎?

　　文章來源：臭魚的互動設計 轉載請註明出處連結。