結構化內容管理系統的無頭項目策略

這是我希望過去幾年在使用無頭內容管理系統 (CMS) 運行項目時擁有的指南。 我做過開發人員、用戶體驗和技術顧問、項目經理、信息架構師和作家。 不同的帽子讓我意識到，即使我們現在擁有所謂的“無頭”CMS 已有一段時間了，仍然有辦法去思考如何最好地使用它們。

現在，我們中的許多人都依賴 JavaScript 框架進行前端工作，使用由組件和組合組成的設計系統，而不僅僅是實現平面頁面佈局。 在服務器和客戶端上運行的 JAMstack 和同構/通用應用程序有很大的吸引力。 最後一個難題是我們如何管理所有內容。

傳統的 CMS 正在添加 API 以通過網絡請求和 JSON 格式提供內容。 此外，還出現了專門通過 API 提供內容的“無頭”CMS。 不過，我在本文中的論點是，我們應該少花時間談論“無頭”，而多花時間談論“結構化內容” 。 因為這是這些系統的基本品質。 這些系統隱含著對我們的工藝有很多影響，而且在找出我們應該如何處理這些技術的良好模式方面，我們還有很長的路要走。

從人文背景開始從事技術諮詢，我學到了很多關於如何組織和處理採用以內容為中心的方法的 Web 項目的知識——無論是使用基於 API 的較新的還是傳統的 CMS。 我開始欣賞如何儘早開始使用來自 CMS 的實際實時內容； 在跨學科環境中這樣做不僅可以在早期階段發現複雜性，還可以為所有相關人員提供代理權，並提供機會從最廣泛的意義上反思技術和設計的挑戰和可能性。

在本文中，我將建議一些總體策略，並提供一些關於如何考慮使用結構化內容的具體、真實的示例。 在撰寫本文時，我剛剛開始在一家提供此類內容管理服務的 SaaS 公司工作，用於託管通過 API 交付的內容。 我會提到它，既是因為我過去在作為顧問參與的項目中使用它的經驗，也是因為我認為它恰當地說明了我想要表達的觀點。 所以認為這是一種免責聲明。

話雖如此，幾年來我一直在考慮寫這篇文章，並且我努力使它適用於您選擇使用的任何平台。 因此，事不宜遲，讓我們回到二十年前，以便更多地了解我們今天所處的位置。

網絡標準的第一步

在 2000 年代初期，Web 標準運動啟發了一個領域來改變他們的工作方式。 從“佈局優先”的方法來看，他們將我們的注意力引導到如何使用 HTML 對頁面上的內容進行語義標記：網站的菜單不是<table> ，而是<nav> ； 標題不是<b> ，而是<h1> 。 這是思考網絡內容所扮演的不同角色以幫助用戶找到、識別和接受它的重要一步。

網絡標準運動引入了語義標記提高了可訪問性的論點，這也提高了它在谷歌搜索結果中的排名。 這也標誌著我們對網絡內容的看法發生了轉變。 您的網站不再是展示您的內容的唯一場所。 您還必須考慮您的網頁如何在其他視覺環境中呈現，例如在搜索結果或屏幕閱讀器中。 後來，社交媒體和共享鏈接的嵌入式預覽推動了這一點。 思維方式從內容的外觀轉變為內容的含義。 這也恰好是處理結構化內容的關鍵。

隨著連接到互聯網的袖珍設備的採用，網絡突然成為應用程序的有力競爭者。 然而，競爭主要是為了最終用戶的眼球。 許多組織仍然需要在他們的應用程序和不同的網絡存在中分發有關其產品和服務的信息。 同時，Web 日趨成熟，JavaScript 和 AJAX 使得通過 API 連接不同的內容源變得更加容易。 今天，我們擁有 GraphQL 和工具，可以讓內容獲取和狀態管理變得更簡單。 因此，技術難題的各個部分開始到位。

“一次創建，到處發布”

儘管它主要被描述為“技術轉變”，但在 JSON 有效負載中嵌入內容（通過 HTTP 管道傳輸）對我們如何看待數字內容和周圍的工作流程產生了巨大的影響。 在某些方面，它已經有了。 大約十年前，美國國家公共廣播電台 (NPR) 的 Daniel Jacobson 客座博客在programmedweb.com 上發表了關於他們的方法的博客，概括為首字母縮略詞 COPE，代表“一次創建，隨處發布”。 在文章中，他介紹了一個內容管理系統，它通過 API 向多個數字界面提供內容，而不是通過 HTML 渲染機，就像當時（可以說是現在）大多數 CMS 所做的那樣。

NPR 的 COPE“數據管理層”將成為“無頭 CMS”的概念。 在 COPE 的早期，它是通過在 XML 中構建內容來實現的。 今天，JSON 已成為通過 API 傳輸數據的主要數據格式，包括物聯網設備和網絡之外的其他系統。 如果您想與聊天機器人、語音界面甚至可視化原型製作軟件交換內容，您通常會使用 JSON 口音來談論 HTTP。

“Uncoining” 術語“無頭 CMS”

根據谷歌趨勢，直到 2015 年，即 NPR 的 COPE 文章發表六年後，“無頭 CMS”的搜索才開始流行。 “無頭”一詞（至少與數字技術相關，而不是 18 世紀晚期的法國貴族），已經被使用了很長一段時間來談論沒有圖形用戶界面運行的系統。

注意：有人可能會爭辯說，命令行界面確實是“圖形化的”，例如服務器上的軟件或測試環境（但讓我們將其留到另一篇文章中）。

我有兩種想法，稱這些新的 CMS 為“無頭”。 我們也可以稱它們為“多頭的”——它有很多頭。 它們是 CMS 的 Hydras 和 Cerbeuses。 “無頭”也通過它們缺乏的能力（即，用於呈現網頁的模板引擎）來定義這些系統，而不是通過它們的真正優勢來定義它們：使得可以在沒有網絡約束的情況下構建內容。 話雖如此，截至今天，該類別中的許多解決方案也可以稱為“幾乎無頭尼克”。 因為編輯界面仍然與系統緊密耦合。 他們的“無頭”源於他們缺乏模板引擎，即從內容中產生標記的機器。

注意：不過，我幾乎肯定會使用一個名為“Mimsy-Porpington”的 CMS（來自哈利波特世界）。

相反，它們通過 API 提供內容，從而為您提供更多靈活性，讓您可以更靈活地選擇要顯示和使用該內容的方式、內容和位置。 這使它們成為流行的 JavaScript 前端框架（如 React、Angular 和 Vue）的完美伴侶。 儘管聲稱能夠向“網站、應用程序和設備”提供內容，但其中大多數仍然受到網絡內容工作方式的限制。 這在大多數處理富文本的方式中最為明顯——將其存儲為 HTML 或 Markdown。

除了模板渲染系統之外，傳統的 CMS 也開始添加一些通用的 API，並將其稱為“解耦”，以此作為與新競爭對手區分開來的一種方式。 “所有這些，還有 API！”* 是聲明。 當涉及到內容建模時，其中一些 CMS 也非常不可知論。 例如，Craft CMS 在您首次安裝時幾乎不會對您的內容模型做出任何假設。 Wordpress 也在朝著使用 API 進行內容交付的方向發展。 我懷疑 CMS 領域的老玩家和新玩家之間的差距會隨著我們的發展而縮小。

儘管如此，在一個組織的文本、圖像、視頻和媒體都被數字化並暴露給內部和外部用戶和客戶的時代，將內容管理置於 API（而不是 HTML 渲染器）之後是朝著更複雜的工作方式邁出的重要一步。 不過，是時候從定義他們缺乏的前端渲染能力轉向他們真正能為我們做的事情了：給我們一種處理結構化內容的方法。 那麼，我們應該稱它們為“結構化內容管理系統”嗎？ 如，“不，鮑勃，這不是你常用的 CMS。 這是一個 SCMS，相信我，它會成為一件事。”

這不是關於頭腦，而是關於結構化內容

結構化內容管理系統 (SCMS) 帶來的最根本的變化是從根據頁面層次結構安排內容轉變為您可以自由地為任何您認為合適的目的構建內容。 避免重複內容是一個明顯的優勢，因為它提高了可靠性並減少了管理負擔（您不必處理跨多個渠道的重複內容）。 換句話說：創建一次，到處發布。 如果您只需要在一個系統中更新您的產品描述一次，並且它會在您的產品暴露給用戶的任何地方進行更新，那麼這顯然是一個優勢。

儘管 SCMS 供應商經常使用“您的網站和應用程序”來證明對頁面結構的不同思考是合理的，但您不必過河才能從結構化的內容結構中獲益。 隨著 JavaScript 框架的流行，將網站構建為單個組件的組合變得越來越普遍，這些組件可以根據狀態和上下文“填充”不同的內容。 您的產品卡片可能會出現在整個 Web 應用程序的許多不同上下文中。 我們看到現代 Web 開發從設置文檔和頁面轉向根據用戶輸入、算法和自定義的混合組合組件。

這些關於如何製作設計系統的趨勢，以及如何鼓勵我們通過測試、學習和迭代過程在團隊中工作，使得內容管理領域已經成熟，可以採用一些新的思維方式。 一些模式已經出現，但我們還有很多路要走。 因此，根據我在將內容放在首位的團隊和項目中工作的經驗，以及現在作為為其構建服務的團隊的一員（我敦促您注意這裡的任何偏見），我想提出一些我認為會有所幫助的策略，並為進一步討論創造要點。

1. 多學科團隊中的方法內容

我相信，平面設計師可以將陳舊的、像素完美的頁面交給負責“實施”設計的前端開發人員，這已成為過去。 我們現在製作由更小的組件組成的設計系統，這些組件的佈局具有開箱即用的多種可能狀態。 通常，這些組件必須對用戶生成的輸入具有彈性，這意味著您越早將實時內容引入流程越好。 前端開發人員的責任不是重現平面設計師的願景； 它涉及瀏覽器如何呈現 HTML、CSS 和 JavaScript 的複雜領域，確保用戶界面具有響應性、可訪問性和高性能。

在 Netlife（一家專注於用戶體驗的諮詢公司）擔任技術顧問時，我看到開發人員、設計師和用戶研究人員之間的協作正在取得重大進展。 儘管我們的內容編輯從一開始就一直參與到項目中，但他們的貢獻並沒有進入設計工作流程，主要是因為技術摩擦。

瓶頸通常是我們無法觸及的遺留 CMS，或者構建內容結構需要時間，因為它依賴於設計佈局。 這通常導致工作加倍：我們製作了一個 HTML 原型，通常基於從 Markdown 文件中解析的內容，當用戶測試完成時，必須在 CMS 堆棧中重新實現，每個人都非常高興. 這通常是一個昂貴的過程，因為 CMS 中的限制是在過程後期​​發現的。 它還會對所有部分產生壓力，要求“一次就做好”，並為您在設計項目中想要進行的那種實驗留下更少的空間。

多學科工作需要靈活的系統

遷移到 SCMS 需要幾分鐘的時間來編寫內容模型（其中字段和 API 立即準備就緒）使我們的流程發生了翻天覆地的變化——而且變得更好。 我記得在項目開始的第一天，我和新 u4.no 的內容編輯器坐在一起。 談論他們是如何工作的，並希望使用他們的內容。 很快，我們將結論轉換為簡單的 JavaScript 對象，這些對象立即轉換為瀏覽器中的編輯環境。 找出有用的標題和標題描述。 我們討論了他們如何希望可以在不同的頁面和上下文中重複使用的文本片段，他們在內部將其稱為“塊”，然後我們在那裡創建了它。

在項目開發的早期允許進行這種探索——在我們面前製作界面時，內容編輯器和開發人員一起交談——感覺很強大。 知道我們可以在她和她的同事開始處理內容的同時繼續在 React 中設計前端。 而且不用擔心把自己畫到一個角落裡，就像我們經常對 CMS 所做的那樣，其中的結構與您必須如何編寫前端部分的代碼緊密相關。

內容系統應該允許實驗和迭代

除了創意重新設計項目，結構化內容系統還應該允許您繼續改進、測試和迭代您的內容，作為整個設計系統的一部分。 UX 設計師應該能夠使用 Sketch 或 Framer X 等工具快速製作具有真實內容的原型。您應該能夠通過定量測量來增強內容管理，無論是可讀性尺度還是內容在使用時的執行方式。

注意：我在上面使用了“用戶體驗設計師”這個詞，儘管我們認為我們都應該——以某種方式——與創造良好用戶體驗的過程相關聯。 我們都是不同設計領域的用戶體驗設計師。

如果您習慣於直接在網頁佈局上使用所見即所得的內容，那麼使用結構化內容需要稍微適應一下。 然而，它有助於進行更符合數字設計領域發展趨勢的對話。 結構化內容讓設計人員、開發人員、內容編輯人員、用戶研究人員和項目經理組成的團隊共同思考系統應如何工作以支持用戶的需求和戰略目標。 這也需要您以不同的方式思考內容的結構，這將我們帶到下一個策略。

2. 你可能不需要啄食順序

對許多人來說最顯著的變化之一是結構化內容系統面向文檔的集合和列表，而不是反映網站導航結構的類似文件夾的層次結構。 一旦某些內容要在其他環境中使用——無論是聊天機器人、印刷媒體還是其他網站，這些結構就不再有意義。 傳統的 CMS 試圖通過允許可重用的內容塊來緩解這種情況，但它們仍然需要放置在頁面佈局上，並且通過 API 進行推理很麻煩。

每一頁都有自己的

正如核心模型中所述，當您的主要引薦來源之一是 Google 或社交媒體上的分享時，您應該將每個頁面視為登錄頁面。 如果您查看頁面瀏覽量的分佈，您會注意到您的某些頁面比其他頁面更受歡迎。 除非您是新聞網站，否則那些往往不是新聞，而是那些讓用戶實現他們希望在您的網站上實現的目標的新聞。 它們是實際發生業務的地方。

您的數字內容應該服務於您自己的戰略目標和用戶的個人目標的交叉點。 當數字代理 Bengler（sanity.io 的前身）為 oma.eu 製作新網站時，他們並沒有按照精心設計的頁面層次結構來構建內容。 他們製作了反映組織日常現實的內容類型，即在項目、人員和出版物之後。 事實上，OMA 網站在內容層次結構方面幾乎是完全平坦的，首頁是由算法和編輯規則混合生成的。

那麼，該怎麼做呢？ 我相信將您的內容考慮為您的組織的心理模型的反映以及它需要什麼才能對您的用戶需要的任何內容有用。

這是一個基本示例：在構建員工頁面時，您可能應該從名為person的內容類型開始。 一個人可以有姓名、聯繫信息、圖像、不同的組織角色和簡短的傳記。 個人文檔可以在聯繫人列表、文章作者署名、聊天支持界面和構建訪問徽章中重複使用。 也許您已經擁有一個知道這些人是誰並且帶有 API 的內部系統？ 太好了，然後與之同步。

不要迷失在本體兔子洞中

回到谷歌索引網頁的方式以及他們如何嘗試索引世界信息是很有用的。 這就是他們在鏈接數據（RDFa、微格式、JSON-LD）上花費時間和精力的原因。 如果您使用 JSON-LD 元素註釋您的網頁，您將在搜索結果中更顯眼。 當您的信息應該由語音助手說出並顯示在助手 UI 中時，它也很重要。 如果您的內容已經結構化並且可以在 API 中輕鬆使用，那麼您可以相對容易地以這些微格式實現它。

不過，我不確定我是否會建議全神貫注於 schema.org 的本體和各種鏈接數據資源，至少不是出於編輯目的。 你很快就會迷失在一個試圖製作完美的柏拉圖式結構的兔子洞中。

新聞快訊：它永遠不會，因為世界是一個混亂的地方，因為人們對事物的看法不同。

更重要的是在一個系統中構建您的內容，該系統具有直觀意義，並且可以隨著需求的變化而適應。 這就是為什麼在設計和開發過程的早期就開始內容建模很重要——您需要了解如何使用它。

摘自現實，而非 CMS 約定

遵循 CMS 附帶的任何約定可能很誘人。 還記得 Wordpress 是如何為您提供“帖子”和“頁面”的，突然間，所有東西都需要放入這些框中嗎？ 所見即所得的富文本字段很靈活，因為它允許您輸入任何內容，但內容不會結構化且易於調整——它只能靈活一次。 但是您需要一些地方來開始您的內容模型映射。 我的建議是從與人交談開始，即與作者和讀者交談。

人們如何在內部談論內容？ 人們怎麼稱呼不同的東西？ 你可以進行自由列表練習，這是民族志學家用來繪製民間分類法的一種方法。 例如，您可以問：

“說出我們組織中不同類型的內容。”

或者，在更具體的層面上：

“你能說出我們在這個組織中擁有的不同類型的報告嗎？”

這項調查的重點是梳理出人們所攜帶的內在分類法，而不是他們對事物的看法或感受（這往往會破壞設計過程）。 在獲得一份非常詳盡的清單之前，您不必問特別多的問題。 您可能會發現列表的某些部分來自您當前 CMS 中的約定（如果您要進行一些改造，這很好知道）。 現在您應該與您的編輯交談並嘗試確定他們需要內容做什麼。

您可以提出的一些問題可能如下：

• 您是否需要在多個地方使用此內容？ 在哪裡？
• 內容類型之間有什麼不同的關係？
• 我們今天和明天需要在哪裡顯示內容？
• 我們需要以哪些方式對內容進行排序？ 排序可以由用戶通過算法完成，還是必須手動完成？
• 其他系統中是否有我們可以同步的系統或數據庫以防止重複？
• 我們希望規範內容放在哪裡？ SCMS 應該是它的來源，還是只是增加現有內容，例如產品管理系統中產品的營銷副本？

這並不意味著您必須用現在不溫不火的洗澡水來拋棄傳統的信息架構。 如果文章是您組織的內容現實的一部分，那麼將文章作為內容類型仍然是有意義的。 但也許您並不真正需要categories的抽象約定，因為這些文章如何引用其中的服務或產品的類型。 這種關係允許在有意義的情況下查詢這些文章，而不需要某人將“文章類別管理”作為其工作描述的一部分。

這篇文章也是讓內容與表示層完全分離變得困難的原因。 我們習慣於考慮文章的佈局和样式，但是在一個期望您將自己的內容託管在自己的域上，然後將其聯合到諸如 medium.com 之類的平台上的時代，您已經放棄了控制視覺呈現。 這將我們帶到下一個策略。

3. 表示上下文也是內容類型

準備好重新設計

您還希望能夠適應并快速更改網站的導航結構，而無需重建整個內容架構或與嚴格的文件夾式界面作鬥爭。 您還希望能夠擁有一些內容層次結構，因為它有時是有意義的，有時它比兩個層次更深，API 優先 CMS 部門中的大多數接口都無法提供太多幫助。

有趣的是，聊天機器人的內容管理系統傾向於使用類似的層次結構來安排意圖樹和對話流。 這就是說內容層次結構在不同的渠道中扮演不同的角色，但它們通常提供瀏覽內容的方式。 解決此問題的一種方法是創建導航類型，您可以在其中通過引用排列內容，並為網頁、菜單或會話界面的路徑構建路徑。

關係建議

引用（或關係）是使結構化內容系統成為可能的原因，它確實是我們在處理網絡內容時所處理的一切的核心（這就是它首先被比喻稱為網絡的原因）。 能夠在內容位之間進行引用是一件非常強大的事情，但就後端如何寫入和檢索此類數據而言，它也可能代價高昂。 因此，如果您有大量文檔，您可能不得不換一種方式思考，因為規模很少是免費提供的。

還值得考慮的是，您並不總是需要顯式引用來連接數據； 大多數情況下，它可以通過與內容有關的標準來完成，例如“給我這個地理位置內的所有人和所有建築物”。 建築物和人員不需要相互顯式引用，只要它隱含在兩種內容類型的位置字段中即可。

當您不能將其留給表示層中的算法來連接數據時，表示類型和其他內容類型之間的引用很有用。 明確地繪製這些表示類型並組合引用的內容可能看起來有點麻煩，但它可以解決您在 SCMS 中經常遇到的問題：很難知道內容在哪裡被使用。 通過包含導航類型，您將明確地將內容與演示相關聯，而不僅僅是一個。 這使得可以獨立於它們所引導的內容來推理使用導航結構。

例如，在屏幕截圖中，我們將 Google Experiments 與路由類型相關聯，允許添加由內容引用組成的多個頁面，這意味著我們可以運行 A/B 測試而幾乎沒有內容重複。 由於如果我們嘗試刪除其他文檔引用的內容也會收到警告，因此這種結構化方式將阻止我們刪除不應該刪除的內容。

跨內容類型的關係是一把雙刃劍。 它提高了可持續性，是避免重複的關鍵。 另一方面，您可以輕鬆地削減自己，因為您在內容之間建立了依賴關係，這（如果不透明）可能會導致顯示數據的渠道發生意外更改。 例如，如果我們可以在沒有警告的情況下刪除“路由”使用的“頁面”，那將會很糟糕。

這將我們引向下一個策略，該策略（當然！）在今天部分超出了普通用戶的能力，因為它與不同系統的架構方式有關。 不過，還是值得思考的。

4. 不要把富文本放在角落裡

富文本不僅僅是 HTML

我可以理解為什麼 HTML 在數字內容中如此流行，但我知道它也來自某些東西； 它是 SGML 的子集，是一種構造機器可讀文檔的通用方法。 正如 Claire L. Evans 在精彩的著作《寬帶：創造互聯網的女性的不為人知的故事》（2018 年）中指出的那樣，當引入 HTML 時，已經有一個充滿活力的社區在思考鏈接文檔。 Tim Berners-Lee 的提議比當時的許多其他系統要簡單得多，但這可能就是它流行起來並使得——截至目前——開放、免費的網絡成為可能的原因。

當您使用萬維網上的瀏覽器時，HTML 非常棒。 如果您是一位想要發布以簡單 HTML 結尾的內容的作家，那麼 Markdown 非常棒。 如果您希望將富文本內容輕鬆集成到非瀏覽器或流行的 JavaScript 框架中，該框架允許您在復雜組件中使用 JavaScript 增強 HTML（是的，我們正在談論 React 和 Vue.js） ，在您的 API 響應中包含 HTML 開始有點麻煩——尤其是當您需要解析它時。

幾乎每個人都這樣做，即使是街區裡的新孩子：我瀏覽了 headlesscms.org 上的所有供應商並瀏覽了文檔，還為那些沒有提到它的人註冊了。 除了兩個例外，它們都將富文本存儲為 HTML 或 Markdown。 如果您所做的只是使用 Jekyll 來渲染網站，或者如果您喜歡在 React 中使用 dangerouslySetInnerHTML，那很好。 但是，如果您想在不在網絡上的界面中重用您的內容怎麼辦？ 或者，如果您想在富文本編輯器中獲得更多控制和功能？ 或者只是希望在流行的前端框架之一中更輕鬆地呈現富文本，並讓您的組件處理富文本內容的不同部分？ 好吧，您要么必須找到一種聰明的方法來將 Markdown 或 HTML 解析為您需要的內容，或者更方便的是，首先將其存儲得更合理。

例如，如果您想將富文本輸出到語音界面怎麼辦？ 我們知道語音助手越來越受歡迎。 這些助手最流行的平台能夠通過 API 獲取語音內容的文本。 然後你想利用諸如語音合成標記語言之類的東西。 可移植文本系統對富文本採取了一種更加不可知論的方法，它允許您為不同類型的界面調整相同的內容。

推薦閱讀：使用 SpeechSynthesis 接口進行實驗

可移植文本作為不可知的富文本模型

當您主要為網絡製作內容時，可移植文本也很有用。 如果您希望能夠使用數據結構（例如富文本腳註或內聯編輯註釋）嵌套和擴充您的文本，該怎麼辦？ 或者 A/B 測試案例的替代短語或措辭？ Markdown 和 HTML 很快就達不到要求，您將不得不依賴添加特殊短代碼標籤之類的東西，就像 Wordpress 解決了它一樣。 使用可移植文本，您可以對內容結構進行不可知論的表示，而無需結合特定的實現。 Your content ends up being more sustainable and flexible for new redesigns and implementations.

There are also other advantages to portable text, especially if you want to be able to edit content collaboratively and in real time (as you do in Google Docs); you need to store rich text in another structure than HTML. If you do, you'll also be able to take advantage of microservices and bots, such as spaCy, in order to annotate and augment your content without locking the document.

As for now, portable text isn't widely adopted, but we're seeing movements towards it. The specification isn't very complex and can be explored at portabletext.org.

5. Make Sure Your SCMS Is In Service For Your Editors, And Not The Other Way Around

Digital content isn't just used for your organization's online web page leaflets anymore. For most of us, it encapsulates and defines how your organization is understood by the world, both from those within it and those outside: From product copy, micro texts to blog posts, chatbot responses, and strategy documents. We are millions of people that have to log into some CMS every day and navigate interfaces that were imagined twenty years ago with the assumptions of people who have never made much effort to user test or challenge their interfaces. Countless hours have been wasted away trying to fit a modern frontend experience into a page layout machine. Fortunately, this is soon a thing of the past.

As a technology consultant, I had to read through pages of technical specification whenever someone thought it was time to acquire a new CMS for themselves. There were demands from which server architecture it should run on (Windows servers, of course) to their ability to render “carousels” and “being able to edit web pages in place”, despite also requesting a “modular redesign”. When editors had been allowed to contribute to these specifications, they were also often dated to the what the editors had begotten used to. They seemed not aware that they could demand better user experiences, because enterprise software has to be big, lumpy and boring.

This is partly the fault of us making these systems. We tend to communicate technology features and specifications, and less what the everyday situation working with these systems look like. Sure, for a frontend designer, something supporting GraphQL is shorthand for how conveniently she is able to work against the backend, but on a higher level, it's about the systems ability to accommodate for emerging workflows, where a content model could survive visual redesigns and design systems should be resilient to changes of its content.

Questions To Ask Of Your (S)CMS

If we are to embrace design processes, we can't know prior to solving the problem whether the user tasks are best solved by making carousels ( newsflash: most probably not ), or whether A/B-testing makes sense for your case, even though it sounds cool.

Instead, ask questions like this:

• Is it possible, and how exactly will multi-disciplinary teams work with this system?
• How easy is it to change and migrate the content model?
• How does it deal with file and image assets?
• Has the editorial interface been user tested?
• To what extent can the system be configured and customized to special workflows and needs of the editorial team?
• How easy is it to export the content in a moveable format?
• How does the system accommodate for collaboration?
• Can content models be version controlled?
• How easy is it to integrate the system with a larger ecosystem of flowing information?

The goal of these questions is to explore to what degree a content management system allows for a cross-disciplinary team to work effortlessly together, without too many bottle-necks or long deployment cycles. They also push the focus to be more about the content should be doing, and less about how things should look in a given context. Leave that for the design processes, where user testing probably will challenge assumptions one may have when looking into getting a new content system.

There are, of course, many factors in addition to this that probably have to be taken into consideration. The easiest thing to assess is the fiscal cost of software licenses and API-related costs if you are on a hosted service. The invisible cost (in time and attention spent by the team working with the system), is harder to estimate. From my experience, many of the SCMSs in combination with one of the popular frontend frameworks can significantly cut development time and allow for an agile ( there's my coin for the swear jar ) design process. With the caveat that your team is prepared to solve some of the problems that come out of the box with traditional CMSs.

Towards Structured Content

The ways we work with digital content has changed dramatically since the World Wide Web made working with interconnected documents mainstream. Organizations, businesses, and corporations have amassed gigabytes of this content, which now is stuck in rigid page hierarchies, HTML markup, and clunky user interfaces.

Using a Structured Content Management System can be a great way to free your content from a paradigm that begins to feel its age. But it isn't a trivial exercise, and success comes from being able to work multi-disciplinary and put your content model to the test. You need to get rid of some conventions you have grown used to by dealing with CMSs designed to output hierarchical websites. That means that you need to think differently about ordering content, make presentations types in order to make it easier to orchestrate content across multiple channels and to consider how you structure rich text so that it can be used outside of HTML contexts.

This article deals with some of the high-level concerns working with SCMSs. There are, of course, loads of exciting challenges when you start working with this in your team. You have to rethink stuff we've taken for granted for many years, but that's probably a good thing. Because we are forced to evaluate our content, not only from its place on a digital page but from its role in a larger system that works for whatever goals your organization and your users may have.

I believe that we can achieve content models that are more meaningful and easier to sustain in the long run, and that means saving time and expenses. It means more flexibility in terms of inventing new outputs and services, and less tie in with software vendors. Because a well-made Structured Content Management System will make it easy for you to take your content and go elsewhere. And that makes for some interesting competition. Hopefully, all in favor of the users.