管理系統都好爛，如何管理數位專輯？
從一個新聞媒體的角度，內容管理系統是一個非得用的工具。但是許多記者和編輯對內容管理系統的評價都很差——無論是覺得難用、常常壞掉或達不到他們想要的效果。有些記者甚至拒絕用內容管理系統，直接把工作交給編輯或其他比較有數位能力的同事。用過內容管理系統的人應該都能理解這種態度，但如果要成功數位轉型，新聞媒體必須從基礎建立自己的系統，培養所有新聞室裡的人都能有效率地使用系統。
管理系統的挑戰
雖然每家新聞媒體的需求都很類似，實際的細節和需求都差很多，例如需要印刷功能、外稿功能、多語言等。這些細節導致沒有一個現成的系統可以直接套用，如果直接用 Wordpress 或 Drupal 類的系統就會很痛苦。
通常媒體對管理系統有三種解決方式。
第一個解決方式就是剛提到的：直接套用或購買現成的系統。這種狀況通常是因為公司沒有資源或人才，去建立自己的系統，所以能採取的最好方式就是使用別人的服務。
第二種就是規模最大的媒體才有辦法做到的，完全內部開發和發展自己的內容管理系統。紐約時報用的 SCOOP CMS 有超過 100 位工程師、設計和產品經理在開發和維護，普通的媒體根本沒辦法做到這種規模。
最後一種，就是我這篇想討論的：有一點資源和人力來重新打造一套系統，但這系統，只有一部份是自己做的。我們在《天下雜誌》就是用這種模式來開發數位專輯的管理系統。
我的工作內容還是以專題製作為主， CMS 系統是我們用過去兩年的零碎時間打造、並持續優化。新創公司常會用到一個詞「dogfooding」，意思就是自己做的東西、要自己用才了解它的使用情況，我們也是用這種精神來開發。
定義使用流程
我加入《天下雜誌》的時候，每個數位專輯基本上都是一次性製作，每次都耗用很多資源，重複製作一些瑣碎的東西。我從想要優化流程的角度，一邊做題目、一邊把流程系統化。
在《天下雜誌》做數位專輯，我們的作品常常需要用到一些複雜的互動圖表，例如，我們做的「台灣本土疫情」頁面，如果還使用舊的製作方式或流程，會完全做不到。
雖然我這篇的標題講的是內容管理系統，但我的觀點是：內容管理系統最重要的其實不是管理內容，而是要管理流程。
一定要先了解大家的工作內容和工作流程，再系統性地處理一個一個痛點。
老實說，我加入團隊後，第一件事也是私心地導入對程式碼方便的 git，讓自己製作題目的流程能夠比較好管理。你可能不會把 git 想成內容管理系統的一部份，但從我的觀點而言，任何可以幫你管理一個作品的流程，都可以成為內容管理系統的一部份，而且我們後來的管理系統，很多功能都是套用 Github API 。
另外，解決流程上的困擾，不一定是能做出很炫的技術或效果，才叫有幫助。我發現，很多最有用的流程優化，常常就是一些很瑣碎的事情，例如壓縮圖片大小、容易編修文章裡的文字等。
我們應該用工具做事，而不是找事情給工具做。雖然現在的網路上找得到各種不同的數位工具，但一定沒有一個工具，就能完全解決所有需求。
所以當你找到一個有趣的工具想要來試試的時候，要如何衡量這個工具是否可以變成你的流程的一部份？
在《天下雜誌》，我觀察到對數位專輯的一些流程和需求為：
- 讓團隊所有人同步工作。記者、編輯、設計與工程能同步做事，盡量避免因為一個人的進度卡關，影響到其他人。
- 能處理照片、影片、圖表、資料等多媒體素材。《天下》的數位專輯會運用的素材和呈現很多元，必須要有辦法處理各種媒體。
- 能重複使用做過的元件。例如，選舉立委圖，遇到類似的專題，能快速重複使用。
- 提供使用者好的體驗，以及效能、速度等。如果網頁載入速度太慢，讀者容易跳離頁面。
- 研究階段的工具 vs 製作階段的工具。我們做題目的時候通常會分兩個階段：第一個階段的任務包括爬資料、清資料、找其他媒體做過類似的題目、試試看一些圖表的可行性。第二個階段才是製作的階段，把網頁實際的做出來。CMS 工具大都是針對製作的階段，但是有些工具可以讓研究階段更順利。
- 保留很大的彈性來面對特殊狀況。我們很難預測一個題目實際會需要什麼樣的素材，沒辦法把模板規定得太死。必須要有辦法快速跳出模板的規範，做一次性的改變。
各自媒體也許可以用到同樣的工具，或者你們的流程跟我們的完全不一樣，但以下提供一些我們串在一起的工具、以及我們如何使用。
用 ArchieML 管理內容
第一個流程上想要優化的，與文字製作有關。從我寫網頁的經驗而言，純文字的內容不應該直接寫死在 HTML 裡頭，因為這樣程式碼比較難讀，要更新也困難。
ArchieML 是一個《紐約時報》開發出來的一個內容格式。用 ArchieML 和 Google Docs，我們可以把內容跟程式完全切開，讓記者和編輯能夠獨立修改文字。
從製作的角度，ArchieML 的規則很容易了解，寫起來也比其他像 JSON 或 YAML 的檔案還要簡單，很容易讓記者跟編輯直接上手用。我這邊也有寫介紹 ArchieML 的一篇文章。
用 Figma 管理靜態圖
做題目的時候，不是每一張圖表都需要有互動的功能，其實很多用靜態圖解決就好。這樣的靜態圖就不一定需要用 D3 寫，甚至，在時間有限的情況下，設計師也可以一條龍把靜態圖處理掉。
為了達成這個目標，我們在數位專輯的 CMS 裡，增加了 Figma 的 API 。這個流程，讓已經熟悉 Figma 的設計師能很快上手，輸入 Figma 的一個版位的 id ，就可以串接網頁不用再把 Figma 輸出並上傳到 github。如果不使用 Figma 的媒體，也可以考慮使用 ai2html 或一些其他的方式，把靜態圖轉到網頁上。
用 Datasette 管理資料
做題目時，我們花很多力氣去處理資料。團隊的人都有辦法用各種像 Spreadsheet、程式語言等工具來清理和分析資料，但每個人各自處理資料就比較難合作。處理過的資料如果以後要回來看或更新，可能會不知道當初數據做過哪些處理。所以我們建立一個 datasette 的系統，幫忙管理我們做過所有的資料。
我們使用 datasette 的流程，就是把所有的 csv 檔案丟到 github repository 裡，當資料更新，也會同步更新我們的 datasette。這樣就可以用它來做一些基本分析、管理等。更大的好處是，datasette 是一個數據平台，跨組同事都有辦法很容易找到，並下載、再次運用這些資料。
用 Github Actions 管理其他需求
我們還有一些流程希望可以自動化。利用 Github Actions 每個月的免費額度，我們把一些上傳和更新流程都加到 Github Actions 裡頭。基本上，Github Actions 只是一個 CI / CD 的一種，用任何系統都能夠達到類似的效果。
再把它們串成一個 UI
最後，是整個系統的 UI。
雖然很多內容管理系統都會從他們的頁面的 UI 出發，從我們開發自己的管理系統來說，UI 是等到流程比較穩定後才進行開發。然而，我們最後做出來的 UI 雖然功能很多，它也是純粹把以上提到的一些服務用 API 串在一起。
這個頁面找專案的方式，就是直接串 Github 的 API ，避免去維護另一個後端系統。這也是現實考量，我們團隊沒有專門管後端的資源。但是，目前這樣的系統就很夠用，編輯有辦法自由地上線、更新，還能看到所有使用到的檔案跟素材。
沒留下文件就是白做
最後想討論的，就是寫文件的重要性。
很多人討厭寫文件，我以前也是這種人。但是，經歷過不同工作環境和專案，我發現我如果不寫或忘記寫文件，以後回來看、或者要教別人怎麼用，很容易忘記當初為什麼會做一些決定。
寫文件除了可以讓以後的團隊比較了解當初的狀況，把東西寫下來的過程裡，你可能還會想到之前沒想到的一些問題或更好的解決方法。不要以為別人看得懂你寫的程式碼，最好就是當作以後沒人看得懂，所以寫得愈清楚愈好。
同時，我也必須重視跟這套系統的使用者互動和教學。可能的形式是開工作坊，用開課的方式來教大家應該要怎麼用這些工具，並得到他們的反饋。這樣才能繼續這個持續發展和優化的循環，讓系統愈來愈好。
