Sue前面分享的兩篇文章，介紹了內容管理系統（CMS）關于內容生產和內容過濾的部分。那么被生產出來并通過過濾的內容，如何呈現給我們的內容消費者呢？

我們都知道，在客戶端上的開發實現，版本一旦發布了出去，如果有東西需要調整，那就要再修改代碼，就算是再小的改動，都需要經過測試后再更新，而每一次的更新本身又存在可能出現各種各樣問題的風險。

如果我們能提供動態可配置的能力，通過模板化來實現內容的呈現，那就可以減少開發的成本，同時也能夠更高效地進行不同產品/運營方案的對比試驗。

由此可知，頁面動態配置是內容管理系統（CMS）關于如何更靈活地呈現內容的解決方案。

1.?頁面拆解&組成部分

在這個“潮流眼鏡專場”頁面，Sue截了三張圖，我們來一一拆解，看看這個頁面都有什么：

• 一個帶著黑超的王俊凱（圖片）
• 一堆優惠券（優惠券領取/限定店鋪優惠券使用入口模塊）
• “超級大牌”（知名品牌的店鋪入口模塊）
• “必買清單”（熱銷/推薦商品的購買入口模塊）
• ……

像這樣一個動態化的頁面，我們可以按以下3層次來拆分：頁面——卡片——組件。

• 頁面，指的是整體可滑動頁面實體
• 卡片，指的是頁面內可按行劃分的一個一個獨立區塊（又稱為”樓層”）
• 組件，指的是卡片內部一個獨立的、業務級別的單元

三者之間的層級關系見下圖：

2.?實現原理

弄清楚了動態頁面的組成部分，那他們仨是如何聯合起來工作的，最終呈現出我們所看到的頁面內容呢？

當用戶訪問某頁面，到最后呈現出完整的頁面內容，主要是通過以下三步完成的：

• 一系列的初始化（包括初始化卡片庫和組件庫、數據解析器、布局框架）
• 數據的解析（包括解析卡片和組件的類型，解析卡片和組件的基本樣式）
• 對頁面進行渲染（根據卡片提供的布局信息進行布局、根據組件提供的組件信息獲取組件內容）

概括的說，就是：首先按照布局去解析出各組件位置，然后再去解析組件的內容（樣式、圖片、背景、鏈接等），最終解析出對應的自定義頁面內容。

3. 要點說明

在聊動態化頁面具體的配置流程之前，想和大家再多聊聊，Sue在學習和工作的過程中，總結和整理一些要點，然后通過這些來加深對整體的理解。

3.1 組件

它不是指顯示的一行小字、一個明顯扎眼的按鈕，也不是一張帥哥美女的明星圖片。它是需要提前定義好，并寫入到框架（代碼）中的。而組件定義的標準就是業務化，要求是能承擔一定業務能力的最小復合單元。

這也基本可以說是作為PM定義需求的一大通用原則。

每個組件都需要單獨設計，定義其規則和樣式。

組件的基本樣式：組件背景、組件外邊距/內邊距、組件的寬高比，除此之外還可能有額外的自定義樣式如：字體顏色、字體大小、組件間的空隙，對應的跳轉鏈接等等。

不同的組件有不同的功能，表示不同類型的內容。

組件的常見種類：搜索欄、公告、列表導航、富文本、標題欄、按鈕組圖文、按鈕組文字、單張圖片、圖片輪播、優惠券等等。

3.2 卡片

卡片負責對組件進行布局?？ㄆ恍枰季帜０?，只需要描述卡片的類型即可，卡片的類型也是注冊在框架里的。

• 對卡片的描述，可分成：標題、布局和樣式等。其中最重要的部分是：布局，因為它包含了內嵌的組件模型，卡片的布局就是對包含的組件來布局。
• 常見的布局方式：流式布局、瀑布流布局、吸頂布局、懸浮布局、輪播布局等。
• 卡片的布局描述也是聲明式的，但只聲明布局方式，不提供布局細節的描述。
• 卡片的基本樣式：卡片背景、卡片外邊距/內邊距、卡片內組件間距、列數。

3.3 頁面

動態化頁面指的是布局動態化，是通過布局嵌套組件的形式搭建整個頁面。一個頁面內嵌套了多個卡片，一個卡片又嵌套了多個組件。

4. 步驟概要

明確了頁面動態化的實現原理，那我們如果需要配置這么一個頁面，需要提前準備什么，做什么？

這里分前、中、后三個環節，來跟大家聊聊配置工作所涉及到的流程。

4.1 開始配置前

1）明確目的和重點

• 要配置的這個頁面，運營目的是什么？
• 通過頁面，想呈現的內容是哪些？
• 內容不同，要重點突出的信息是什么？

2）確認已有設計和是否需要補充

• 已有的布局樣式和組件，是否可以滿足配置需求，進而達到運營目的？
• 卡片庫（布局樣式）和組件庫有無需要補充新增的？

4.2 進行配置時

1）選擇/創建頁面

總體來說，頁面需要支持動態化配置的情況有兩種：

• 一是，對固有的頁面進行選擇性的配置（選擇的標準會在文章最后和大家具體探討）。
• 二是，依據具體運營目的，通常是活動或專題類的運營需求，創建一個新的頁面，對頁面進行自定義（不需要單獨為了這個新頁面去開發）。

2）選擇卡片、然后選擇組件進行布局排版

根據頁面想呈現的內容和內容想突出的信息，在已有的卡片庫（布局樣式）和組件庫，選擇合適的布局樣式和組件。

3）組件配置（定義樣式、配置信息）

• 這一步會涉及到一系列的樣式和細節的配置，大到頁面呈現的氛圍，小到組件之間的間距等等。
• 具體的樣式和信息的配置項，要依據具體的需求來定義（有興趣的小伙伴可以深入地對具體的行業和產品、內容類型去學習了解，推薦“電商行業的店鋪裝修”）
• 切忌盲目地追求配置的靈活性，細分出過多的、非必要的配置項，這會導致研發的成本變高，同時導致配置工作變繁瑣，應盡量控制配置項的數量，盡量做到自動獲取信息，提供系統的操作性。

4.3 完成配置后

1）效果預覽——確認發布

2）預覽提交——審核發布

預覽，是必須要有的一個步驟。Sue在這一步說的預覽，是指在頁面配置完成后最終效果的預覽，還可能會涉及到時間維度（比如對雙十一零點活動頁面提前設置定時發布的預覽）。另外還有一種預覽，是指在配置過程中的邊配邊看，主要是針對樣式細調的效果預覽（比如組件換不同的背景顏色）。

讓操作人員在完成配置后，在進行發布前，對頁面的配置效果先進行預覽，以確保最終呈現的頁面滿足需求和符合要求。

預覽完效果后，進行提交，等待審核發布，則可以依據公司/團隊具體的情況，進行步驟細化。

通常，初創型公司由于運營團隊的組建較為精簡，常見的流程是：運營人員完成配置后，預覽一下效果，確認沒問題就操作發布了。沒有中間審核的這一步，預覽到發布，通常是同一個人。

但在對內容管理有明確的流程和規范，并且人員配備完善的公司，流程通常是第2）種。

這中間涉及到多個不同的角色，以及角色背后的權限細分。有的人負責配置，預覽后提交審核，對呈現效果負責。有的人負責審核，最終確認發布，對整體進行把控。

所以具體的流程是：效果預覽——提交審核——進行審核——確認發布。

附：整體的配置步驟說明圖

5. 需求提取

明確了頁面動態化的實現原理，以及配置頁面的工作流程，那接下來就是PM最熟悉的內容了：提取需求，完成產品設計。

產品設計和后期不斷迭代優化，都應該始終圍繞以下幾個方向：

• 如何使工作更高效
• 如何使協作更順暢
• 如何使管理更智能
• 如何使權責更明確
• 如何使風險更可控
• 支持快速試驗，用數據來指導決策

基于實現原理、配置流程和產品設計方向，Sue提煉出了以下6大需求點：

（1）管理

• 組件庫管理：不支持直接創建一個新的組件，只能在系統已有的組件庫里面選擇。
• 卡片庫管理：（同組件庫）不支持直接創建但可直接調用。除此之外，還有一個很重要的功能：需支持一鍵上下線卡片（在出現問題時立即可做線上的緊急處理）。
• 頁面管理：需支持一鍵上下線頁面（同樣是應急處理的功能支持）、版本通配（可解決新版本發布時的配置效率）。
• 權限管理：對應組織結構或業務線，做頁面、操作和數據等的權限細分。
• 變更記錄：讓每次變更都有記錄可查，防止線上數據被隨意更改。

（2）編輯（配置）

在配置不同類型的頁面時，提供對應的配置功能：

1）對固有頁面的配置

• 選擇頁面
• 選擇卡片、定義卡片樣式、配置卡片內容（選擇組件）
• 選擇組件、定義組件樣式、配置組件內容
• 配置更多頁面信息：定義生效時間、失效時間、頁面名稱

2）對創建頁面的配置

• 創建頁面
• 選擇卡片、定義卡片樣式、配置卡片內容（選擇組件）
• 選擇組件、定義組件樣式、配置組件內容
• 配置更多頁面信息：定義生效時間、失效時間、頁面名稱

3）除此之外，還應該提供復制創建等滿足高效配置的功能

• 可批量復制地創建頁面
• 可批量復制地創建卡片

（3）預覽

配置預覽：對應的是配置過程中的效果查看，主流的交互是拖動到相應位置，設置內容后實時預覽。

白名單預覽：對應的是預發布狀態，在此狀態下，可通過白名單預覽，提前查看效果。

時間機器預覽：

• 通過時間機器調整時間，可預覽對應在將來某個時間的效果。
• 因為不同的時間點，生效的數據不一樣，確保配置符合要求和需求。

（4）審核

這個過程和一般的申請審核大致相同，需要支持和滿足的需求點應包含但不僅限：

• 待審核記錄的處理通知
• 待審核記錄的呈現
• 審核操作（效果、內容的展現、功能的使用等——預覽功能）
• 審核記錄
• 審核記錄：通過、不通過（原因告知、修改指導）

（5）發布

通常完成配置后，不建議直接發布，以免存在問題的配置，直接影響到線上用戶。

到了發布階段，有以下兩個發布功能是應當去滿足的：

• 預發布：增加預發布狀態下，是為了進一步檢查和確認配置效果，降低出現問題的風險。
• 定時發布：支持設置所配置的頁面僅在特定時間生效。由此，可提前完成相關的配置、審核等工作。臨時配置容易導致問題出現，這同樣也是為了使風險更可控。

（6）ABtest

俞軍老師在書中分享過：由于信息的不完備性，所以所有自以為經過審慎考察做出的判斷和行為，客觀上說都是在試錯。

同樣我們所設計的內容管理系統（CMS），也應該具備這樣的試錯能力。

• 支持頁面、卡片級別的ABtest能力。
• 可將每一次的配置變更做成實驗變更，進行ABtest。
• 在小范圍內先試驗變更的效果，最后根據數據來做決策。

（Sue前段時間剛好梳理和搭建了所在項目的ABtest系統，有專門深入去學習和做了一些總結。后面也想和大家來聊聊，在這里就算先預告一下下）

附需求點梳理腦圖（但還是那句話：需要結合具體情況去定義，設計出來的產品才符合需求）

6. 思路&理念

最后來總結一下，內容管理系統（CMS）通過動態化頁面對內容進行呈現的基本思路和設計理念。

基本思路：

內容管理系統（CMS）通過動態化頁面對內容進行呈現的基本思路：分離內容的管理和頁面的設計。頁面設計存儲在模板里，而內容存儲在數據庫中。當用戶請求頁面時，各部分聯合動態生成一個標準的頁面。

設計理念：

• 內容管理系統（CMS）通過動態化頁面對內容進行呈現的設計理念：具備足夠的靈活性。
• 只有足夠的靈活，才能滿足運營日常的各種需求。

而靈活性則體現在：

• 布局能力動態變化，定義清楚最少要有多少種布局樣式內置在框架里；
• 動態能力粗粒度化，定義清楚有多少組件要注冊到框架里；
• 組件業務化，組件要求是能承擔一定業務能力的最小復用單元；
• 組件可復用，需要對同類型的組件具備回收復用的能力。

7.?產品思考

我們都明白頁面動態化配置對運營、營銷等方面重要意義，一方面確確實實是在減少重復性、不必要的開發工作，避免了開發資源的爭奪和漫長的排期等待。但另一方面，也靈活的配置方案、便捷的配置工具，對技術的要求就相對較高了。如何在這兩個方面更好地平衡，就是產品需要思考的問題了。

• 有必要所有的頁面都支持動態配置嗎？
• 哪些頁面需要支持？哪些頁面無需支持？哪些頁面不宜支持？
• 判斷的標準和依據是什么呢？

關于這幾個問題，Sue思考的答案是：并不是所有的頁面都需要支持動態配置，沒這個必要。

符合以下條件的頁面需要支持動態化配置：

• 用戶流量集中的頁面（例如首頁）
• 用戶停留時間越長的頁面（例如首頁）
• 用戶頻繁使用的頁面（例如搜索頁）
• 營銷空間和價值大的頁面（例如專題活動頁）

符合以下條件的頁面無需支持動態化配置：

• 不是交易流程必經的頁面流（例如分類頁；需要說明一下：交易不特指下單付費，對內容的消費本質上也算一個交易）
• 不是用戶頻繁使用（例如幫助頁、設置頁）

符合以下條件的頁面不宜支持動態化配置：

• 一般有固定的格式展示信息（例如個人中心頁）
• 關鍵信息對頁面轉化有直接影響，用戶只關注關鍵信息，故需突出且固定位置展示，培養用戶習慣，不能隨意變動（例如詳情頁）

以上，就是Sue對于內容管理系統CMS在內容呈現環節的總結與分享。

真正到開展對應工作的時候，要思考的遠不止本文所分享的這一些，希望Sue所分享的內容能起到一個拋磚引玉的作用。

堅持更文分享個人一些思考與想法，使自己保持輸入轉化、總結輸出的學習習慣。如有不成熟、不正確的地方，希望有小伙伴指點賜教。歡迎討論，共同進步。

本文由 @素小白 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議