化解編輯與工程師間的尷尬：紐時新聞工具 ArchieML 介紹
（數位專題上線前一天）
編輯A：「S，專題有幾個錯字要改，可以幫我改一下嗎？」
工程師S：「沒問題！哪裡要改？」
編輯A：「就是 … 感恩！」
（更改後一小時）
編輯A：「S～那個 … 我剛剛又發現有個地方的句號應該換成逗號比較好，麻煩再幫我改一下～」
工程師S：「好 … 再麻煩你傳 Slack 跟我說是哪一段的哪一句。」
編輯A：「沒問題～感恩！」
（下班前三分鐘，S準備為今日的工作收尾，提交了最後一次 commit）
編輯A：「S 不好意思 ><！那個第一段的情境圖阿，我後來覺得用原來那張比較 … 」
工程師S：
上述情境在製作數位專題／特製頁面時應該屢見不鮮，在反覆修改的過程中，工程師可能會逐漸失去耐心，編輯／記者也可能會覺得不好意思（？），為了讓下一次專題有更良好的合作關係，你需要的是化解彼此尷尬的神器－ArchieML！
ArchieML 是什麼？
ArchieML (Archie Markup Language) 是《紐約時報》於 2015 年所開源的新聞室工具，一種為「無程式背景使用者與工程師」所發明的標記語言，主要目的是利用 ArchieML 特有的標籤將一般文字轉換成結構化資料。
OK，大家有懂上面的介紹在說些什麼嗎？我是沒有很懂啦！所以先讓我們直接以工程師的視角來看看網頁「背後」是長什麼樣子。
就像下圖一樣，我們在網頁中所看到的所有物件（文字、圖片、顏色 … 等），背後都是搭配著相對應的網頁程式碼所組成的。
前端工程師在製作專題頁面時，通常會把編輯／記者所提供的內容複製貼上至專題相對應的程式碼檔案中（上圖左側），這些內容可能存在於 word、Slack、Line、Google Docs … 等文字編輯／溝通軟體中，所以可以試想一下本文一開始的情境，如果需要對文字內容進行微調時，需要執行以下步驟：
記者編輯產生更改需求 -> 通知工程師哪裡需要更改 -> 工程師打開程式檔案進行更改文字 -> 工程師更新程式檔案至伺服器上 -> 更改完成
以上流程已經較為簡化，更嚴謹一點中間還可能需要紀錄「更改了哪裡」、「誰提出的更改」，更改一次所需花費的時間也許不多，但如果要對內容進行多次編修，工程師的表情絕對會逐漸母湯，但我們又不能因此去限制記者編輯們的編修次數。
ArchieML 所能做的就像前面所提及「利用特有的標籤將一般文字轉換成結構化資料」，這項特點能幫助我們在流程中進行「編（編輯）工（工程）分離」，簡單來說記者編輯可以在想對內容進行修改的時候，愛怎麼改就怎麼改，與此同時，工程師也不需要去更動程式碼檔案，只需更新產出的結構化資料，就可直接完成專題更新，這對雙方來說絕對好處多多，因此當記者編輯有更改需求時，流程可能會變成：
記者編輯直接於 Google Docs 中進行更改 -> 修改完成後通知工程師更新結構化資料 -> 更改完成
實務中如何使用 ArchieML？
在 ArchieML 的介紹網站中，有說明一系列適用於網路程式語言的資料標記方式，也可以直接利用官方網站所提供的沙盒模擬器來測試 ArchieML 的各種標記在結構化資料中會長成什麼樣子，好讓工程師去決定各種標籤要如何命名、設計。
講了那麼多，實務上 ArchieML 加入後，一整套流程會長什麼樣子呢？這邊先分享我自己在關鍵的實作方式給大家參考。
（1）在 Google Docs 中使用 ArchieML 語法將內容上稿
這個步驟可能需要在專題製作到中期時，與工程師一起討論各種 ArchieML 標籤的使用方式，像是在我們的愛滋病問答專題中，我會先幫編輯設計好各個題組的標籤及標籤名稱該長什麼樣子，編輯只要於標籤後填寫前端程式需要的內容就好，如果未來需要更改其中的內容，可以直接在Google Docs 中修改，如果編輯想要新增題數，只需向下複製貼上這個模板重新填寫即可！
使用 Google Docs 當作文字編輯器有幾個好處：
- 多人協作
- 用不同顏色、文字大小進行註解都不會影響 ArchieML 的解析
- 可以直接於某段文字上進行註解
當然使用 Google Docs 也是有缺點的，那就是你必須把這份文件開啟分享權限，才能讓 ArchieML 套件中所提供的 API 直接從 Google Docs 中解析，如果內容中有須多機敏資訊，就比較不適合這種做法，但這並不代表不能使用 ArchieML，只要是任何的文字內容中有 ArchieML 語法，都可以餵給 ArchieML 去做解析轉換成結構化資料，你可以使用任何文字編輯器去編寫 ArchieML 文件。
（2）使用 ArchieML 對文件進行解析產生結構化資料（JSON）
ArchieML 有提供許多不同程式語言的版本，工程師可以挑選自己熟悉的程式語言去做使用，像我自己就偏好 R 的 rchie 套件去將 Google Docs 與 rchie 做串接產出給前端的內容 JSON 檔案。
（3）將 JSON 餵給 Web App
其實第二步和第三步應該是一起的流程，但這段我想寫給常常做專題頁面的工程師看，如果使用 ArchieML 後，我們的 code 會長成什麼樣子。
以前面提到選舉制度介紹的段落當作例子，在檔案中我們只會看到資料嵌入在我們的 code 中（不同框架寫法可能不太一樣，這邊我是使用 Svelte，推坑！），就算編輯在 Google Docs 中變更任何內容，都不太會影響 code 的內容，唯一的小小缺點就是工程師可能需要多花一點點時間去思考，在不同內容中資料的架構要如何搭配 ArchieML 語法去做設計，但我覺得多花這點時間與頻繁地去更動 code 中內容相比，絕對非常值得！
在介紹完基本的流程後，不知道大家有沒有發現，這一整條流程基本上就是個非常簡易的 CMS，雖然簡易，但它可以給內容及工程產製者非常彈性的創作空間。
這段最後分享一下踩坑的經驗，順便提醒一下想使用 ArchieML 的工程師，就是千萬別在 Client Side 直接與 Google Docs 做對接，因為 Google Docs 的 API 在某種情況下（不確定是哪種情況 XD 推測可能是 api 打太多次）很可能會把整份文件 Ban 掉，這在像是開票頁面這種流量大的網站非常危險，一但網站掛掉，老闆可能就沒有那麼開心了。
除了編工分離外，ArchieML 還有什麼好處？
ArchieML 除了編工分離外，在製作功能型頁面的模板也非常方便，像關鍵最新上線的世界愛滋日問答頁面，就是與 ArchieML 搭配產生的模板頁面，如果下次有其他內容的主題想要以問答的形式來呈現，只要內容準備好，整個網站也許不到三分鐘就可以產生，幾乎不用改動到原本已經寫好的程式碼。
我們也與設計師配了幾種不同色調的模板，編輯只需要在 Google Docs 中填上喜愛的模板編號，顏色就可以立即做替換。
這份文件展示了部分我們在這個頁面中的 ArchieML 文件，有興趣的話可以與問答遊戲對照看看。
所以 ArchieML 與前端搭配的彈性其實是幾乎無上限的，減少重工、模組化常用的元件應該是工程師的天命之一（？），所以彈性要開到多大（能更改的東西有多多），這必須要在專題製作的前中期時，專題製作團隊一起好好討論！
後記
這篇是標準的 ArchieML 推坑文！會想寫這篇主要是覺得其實在 2015 年 ArchieML 就已經發表了，但似乎看到台灣媒體很少人有在用（目前應該只有看到天下和關鍵有在使用），雖然中央社的前輩之前有分享過使用 Google Spreedsheet 達到類似目的的作法，但我自己以半記者半工程師的角度來看，ArchieML 能夠給予工程師以及記者編輯更彈性的空間。
特此感謝前關鍵工程師D引進這套工具，不然我不知道什麼時候才會發現它的存在。
最後，因為我覺得要引入這套工具還是要靠各家的工程師大大才行，所以我在文章中用了一些可能工程師比較能看得懂的術語以及範例，這點還請各位多多包涵！（看不懂直接把這篇丟給工程師就對了！）
如果你覺得這篇文章對你有幫助，歡迎幫我們拍拍手！謝謝！
