案例剖析|編輯器，還真不是這麼簡單！

原創： Kevin改變世界的點滴 Kevin改變世界的點滴

今天

你們好，我是 Kevin。這是我2019第36篇原創

編輯器模塊是涉及到UGC與內容管理的必備模塊。在這樣一個很是常見的組件，不少產品新人一看就是：無非是知足輸入功能便可。

但仔細挖掘編輯器的背後你會發現涉及到有交互問題、編輯器擴展功能問題、編輯器與業務關聯，3個問題。

交互問題

編輯器是用戶鼠標、鍵盤落地的模塊，要考慮鼠標有的狀態：點擊、滑動、懸浮；鍵盤的狀態：快捷鍵、蘋果鍵盤、win的鍵盤。

編輯器擴展問題

編輯器究竟是文本編輯器、仍是富文本編輯器，這是2個不一樣的產品。

文本編輯器則是對文本的格式、排版進行處理。因此你能夠看到加粗、協體、左中右居中便可

富文本編輯器則增長了字體的大小、圖片、視頻、超連接等。

編輯器與業務關聯

在編輯器中咱們要產生內容，對於客服人員來講內容是客服回答話術、對於銷售人員來講內容是產品介紹與銷售話術。

針對編輯器，本質上選擇產品的使用場景。若在文本消息的通知公告編輯器上，文本消息就足夠。但對於文章、回答等場景，富文本則是剛需，儘量的知足用戶內容產生的方便

4個編輯器案例

知乎爲例的編輯器

知乎的編輯器也更新了大概幾個版次，從基礎的輸入內容體驗到業務內容。好比支持函數、公式，另外編輯器可支持拖拽圖片至任意位置上傳；增長上傳的佔位和狀態提示，幫助知友們更明晰地瞭解上傳位置和進度；也能夠選中圖片進行調整尺寸大小，或用「圖片註釋」功能優雅地解釋圖片的背後故事。

簡書編輯器

相比知乎，簡書以給予做者提供專欄的方向，在編輯器的設計上就增長了專欄關聯。每一篇文章均可以插入到對應專欄中。其次發佈文章會要求上傳相冊、廣告過濾後纔可發佈。這一舉措下降了內容缺失致使內容質量降低問題，但卻有時候增長了上傳的門檻。

掘金的編輯器

掘金做爲前端社區的黑馬。在編輯器上支持markdown，一樣給予沉浸式的編輯體驗。用戶編輯好內容後必須填寫標籤纔可發佈。

編輯器會跟隨內容的增長，進行下層交互，保證做者能夠隨時調整格式與排版。

頭條編輯器

頭條編輯器提供的一樣是富文本，但給出了漢子的限制。顯然編輯器產生的內容覆蓋了各種用戶羣體，系統中的篩選與過濾機制是以上幾個編輯器最多的。

相似增長髮文規範、系統自動去超鏈、二維碼檢測。

第三方插件

目前上面幾個社區編輯器中，除了簡書、掘金沒有獲得第三方插件支持。主流內容平臺已經獲得新媒體管家、壹伴的兼容支持，能夠幫助做者提供更多文章格式、動態效果與自動化排版等。

編輯器5個難點

編輯器的測試首先是一個難點，針對編輯器涵蓋若干個小功能點。每一個功能點的邊界測試、以及新功能上線後都須要迴歸測試所需耗費的時間較長的。

第二個難點是就各種內容進行測試，好比視頻類、音頻、圖文類不一樣格式的內容進行上傳測試，經過上傳不一樣邊界值尺寸的內容測試編輯器的穩定性

第三個編輯器1.0能夠不用考慮草稿箱。在1.0的重點是冷啓動社區，內容仍是大部分在外部或轉載，因此原創做者的需求相對較少。

第四個難點，編輯器在web中的交互、瀏覽器兼容問題。編輯器由於與系統的關聯性有大緣由，因此針對蘋果、win的系統要作不一樣的兼容處理。

尤爲在微信瀏覽器中、蘋果瀏覽器、谷歌瀏覽器中是否有編輯器功能失效等，都須要驗證測試。

第五個提供業務內容分發，這一點最難的是由於不少編輯器都停留在上面。當內容有特定的業務內容好比知乎的live、掘金的開源代碼，編輯器如何高效的產品業務內容並幫助分發是產品經理須要考慮的。

好啦，今天的原創就在這裏。我會每週更新2篇case

推薦閱讀

堅持一年體驗報告，招募500個產品經理

個人第一本書，給產品從業者