23，Blog 新增「發文計畫」與我的思路
2023/11/04更新：24，收回「發文計畫」
前幾天躺在床上，突發奇想，想到一個可以改善我「發文紀律」的有效手段！
從以前到現在，雖然習慣把想寫的主題事先收集起來，但實際上它們究竟會以什麼樣的順序被創作，則非常依賴我當下的心情與喜好。
我並不喜歡這種「今天想到寫什麼才寫什麼」的模式，儘管多數主題都不是臨時起意，但創作本身卻存在很大的不確定性。
這是一種不穩定的狀態。
怎麼改善？沒錯，我想到用 Notion 建立我的發文行事曆，我稱之為「發文計畫」。
現在，你可以在 blog 左上角的選單找到它。
這篇來就介紹我的思路、為什麼選擇 Notion，以及如何規劃版面呈現等議題。
兩大訴求
設計這樣的發文計畫，主要想透過下列兩個面向來有效提升我的寫作紀律。
一、可預見
這裡的「可預見」包括對讀者和我自己，先說說讀者。
對讀者而言
我的 blog 創作方向，大致可以分成三類：
- 程式。
- 筆記軟體與筆記方法。
- 寫作與各種心得。
而這三者的關係——可以說沒有太大關係。
這會帶來一個「困境」：讀者不知道你下一篇寫的，會是哪個方向的主題，但讀者可能只對其中之一有興趣。
這樣的不確定，也會導致讀者訂閱本站文章的意願下降。就像當初《有物報告》停刊的主要理由：
周欽華表示，因為會員成長停滯，反應了產品有根本性的問題，最主要的問題是讀者的產品體驗不一致，造成「有物報告」的品牌不清晰，因此該停就停。
在訪談讀者的時候，讀者的回饋是內容主題太過發散、風格不統一，以至於讀者根本無法確定，今天所收到的電子報到底內容會是什麼？更不知道內容是不是自己想要的？而這種體驗上的不確定，就成了訂閱制的媒體想要成長所會面臨的瓶頸。
雖然訂閱數並非我的主要追求，但我仍希望提高讀者的可預見性，讓讀者更容易知曉我接下來會寫什麼。
對我而言
誠如前述，我對於什麼時候要創作哪個主題，太過隨機與憑藉個人喜好。這對我自己，也是一種不確定。
這樣的不確定帶來的最大困擾是：我可能會因為不清楚「現在」要寫什麼而拖延。
這十分諷刺，畢竟我早已累積了一大堆主題，但我卻不知道要從哪個開始。
有了「發文計畫」，這些不確定有機會被大幅消除，讓我更有效率地進行創作。
二、公開承諾
這點比較容易理解。
以往，在我還沒發文之前，你根本不知道我正在寫什麼，是不是有如期發表——這些都只有我自己知道而已。
好處就是我可以一拖再拖，而壞處往往也是一拖再拖。
公開承諾會強化其中的痛苦，讓我對這樣的拖延感到壓力。
為什麼選擇 Notion
我幾乎第一時間就決定用 Notion。
我知道，這樣的頁面，想要透過目前採用的「靜態部落格」來呈現，非常困難。
我當然可以做一個超級簡易版：只是列一個清單，第一個項目就是最近會發表的文章，然第二個就是再接下來會發表的……等等，以此類推。
但這樣的效果並不好，而且我在編輯上也不順手。同時，可以想見這會是比較需要頻繁變動的內容，對工具的流暢度有一定要求，單純的靜態網頁並不適合。
這種需求你會想到什麼？沒錯——Notion database！
善用 Notion database
顯然，Notion database 非常符合這類情境，更別說它還有多種 view 可以呈現，修改一次資料後，所有的 view 都會跟著變動。
真的太適合了！
雖然它有一個缺點，那就是必須「開新視窗」，讓人有一種離開網站的感覺。但考慮到 Notion database 的強大易用，我還是接受了這個折衷之道。
此外，我也有考慮過 Airtable，因為它可以把 database 嵌入網頁中，不必開新視窗，整體感更好。
但仔細想想，我平常根本沒在用 Airtable！這會需要我「特地」去操作這個工具，徒增使用上的「摩擦力」。但 Notion 不同，它依舊是我的日常。
版面介紹
介紹一下「發文計畫」這個 database。
首先必須強調，database 的整體設計，盡可能遵循了我在〈Notion 資料庫「反複雜」使用指南〉中提到的「我的 Notion 減法」原則：
- 能少則少的欄位——記錄不要太面面俱到，以免淪為「填表機器」。
- 最大程度善用不同的 view——這非常重要。
- 固定架構、不使用進階功能。
這個 database 總共有三個 view，功能各不相同，一一介紹如下。
即將發表
只包括「未發表」的文章。也是整個發文計畫的核心。
使用經典的 table view，記載近期將發表的文章標題、分類，以及預計完成日（也就是 deadline）。
其中最最重要的，當然就是「預計完成日」。
雖然不一定能 100% 遵守——也可能會延後。但原則上，它就是一個 deadline。
我對這個「既定日期」的尊重，將決定我的發文紀律可以得到多大程度的提升。
附帶一提，我以前做 Notion 筆記時，其實很少用 table view，幾乎都是用 list view。但 list view 沒有欄位名稱，不利於公開展示，因此這裡我選用了 table。
此外，為了防止我無止境地往這裡狂塞想到的標題，造成發文池氾濫（畢竟我寫的再快，也沒有「想到文章標題」的速度快），所以這裡最多只會有 10 筆資料。
已完成
只包括「已發表」的文章。
這裡選用了 gallery view，秀出封面圖片，並附上文章連結。
發文行事曆
包括已發表和未發表的文章。
我原本把它放在最左邊第一分頁（也就是打開這個頁面後的預設分頁），因為它在視覺上最直觀。但想想有點佔版面，還是移到了最右邊。
使用 calendar view，這對我來說很關鍵，我必須透過觀察發文日期之間的間隔日數，來確認發文的壓力是否過大、是否過於密集。包括發文日當天、前後一天是否還有別的安排等等。
如果是，就要進行調整，這也是我無法 100% 遵守發文日的原因之一，因為它們可能會有所變動。
整體而言，calendar view 完美地做到了「管理發文行程」這個任務，更不用說還可以透過拖曳來直接移動發文日期，太讚了！
小結
我有預感，這個「發文計畫」的建立，對我來說會是一個重要的里程碑。
原因無它，我屬於「非常排斥」對要做的事進行規劃的人（現在仍是如此），更不喜歡所謂的「時間管理」。
我常常強調自己對「記錄→觀察→反思→調整」的偏好，甚至引以為豪。
但我也不得不承認，記錄有其極限，不是什麼問題都能夠透過記錄來改善。（雖然很多問題都可以！比如天天量體重來節制自己進食的欲望）
所以，「發文計畫」或許將成為我對「記錄」與「規劃」看法的轉捩點。
且讓我們拭目以待。