有關作者Blog 架設之路

這次來淺談一下，為什麼你看到這個 Blog，會被我這樣設計？
我在之前的文章，到底埋下了什麼伏筆？

這次一次解答

最核心的功能：可被分群的標籤#

如果你有逛過標籤頁，應該會注意到，標籤其實是樹狀的吧？
我想這類設計，在一般的部落格不太常見吧？

原因很簡單，因為這套分類系統，在技術文件站比較常見。
這類分類方式一般叫做 Taxonomy (分類法)，我這套是階層式的。

標籤系統會這樣設計，有兩個主要原因。

習慣#

這是源自於我從 Notion 跳到 VS Code + GitHub 做筆記的習慣。
你可以看一下 Markdown-Note，會發現我的筆記其實是樹狀的。

到了幾乎是 Blog 前身的地方 Linux-Jump-log，這個習慣也延續了下來。
用 Part 分時代和功能，尤其是 Part 3 底下，還依據套件或功能，來分筆記。

沒錯，這些文章不只是我的個人記錄，同時也承載了筆記的需求。
所以這就導致，找文章對我而言，非常的重要。

(沒錯，這個部落格的本業，其實是我的公開筆記庫)

瀏覽其他 Blog 的痛點#

空有前面的習慣，我可能還不至於如此迫切，設計一個便於分類的標籤系統。

但當時我還很常逛 Ivon 的部落格，那時他還是以分享 Linux 工具為主，我也很常看他的 Linux Desktop 教學文。
然後逛了一段時間後，有時想找他之前寫的文章，我發現很難找。
有些分類並不直觀，有些文章被分到的分類，與我預期的不符，導致文章找不到。

那既然如此，我用標籤找文總可以了吧？

一點開標籤頁，一頁標籤海，而且有的關鍵字還重複，可能這裡有個「Linux 伺服器」，然後旁邊又有個「Linux 伺服器教學」。
(Android 也是重災區，我對 Android 相關標籤印象最深)

也因此，便於歸納的標籤系統，成為了我設計 Blog 非常核心的目的。

我的想法#

先說說標籤重複這件事，這可以透過有意識的確認標籤，避免標籤相似/重複命名。

然而絕大多數 Blog 和佈景主題 (theme)，用的是源自 WordPress 那套，扁平標籤 + 分類，所有文章用歸檔表示。

問題在於扁平化標籤，隨著文章數量的上升，會碰到兩個問題：

1. 數量不可避免的膨脹
2. 有些同一領域，但是不同主題的文章，標籤要怎麼下？

雖然還有分類，但分類是分類 (且大多主題僅有 2 層)，標籤是標籤。
兩者都是找文章的手段，但互不相干。

所以我想到，如果標籤可以被分群，可以把標籤掛在標籤底下，然後找標籤時按需展折，是不是就能緩解搜尋問題？
以目前我的標籤頁為例，Linux 是一個標籤，但是底下可以掛個虛擬化 (KVM/QEMU)，然後虛擬化又可以分成 Virt-manager 和 Proxmox VE 等。

那如果是不知道丟哪，或者替它創立一個群組有點浪費，比如 Systemd。
Systemd 已經是 Linux 的主流 init，像我基本上也不會用 Systemd 以外的 init，那就直接分類在 Linux 底下。

但我也說了，這些全是標籤，所以今天有篇文章，跟 Linux 相關，但可能是我不會深究的主題，或者是我不知道怎麼分類的文章，就可以直接貼到 Linux 這個標籤。

這基本上就是一個樹狀結構，我十分習慣這種模式，會想到這樣分類，也是我常年的筆記習慣導致。
既然是樹狀結構，那製作標籤頁時，這些標籤自然要能收展，才能達到便於搜尋的目的。

所以我的標籤表，有個參數是用來控制預設狀態的，目前我是讓第一層預設展開，第二層子標籤基本上預設不展開。

當然，有些子標籤可能跨越多個領域，比如 EFI，只要是 UEFI 開機，Windows 和 Linux 都需要 EFI 分割區，所以 EFI 會是橫跨兩大系統的標籤。
這類跨主題的標籤也在考慮之內，實作時讓同一個標籤可以同時掛在多個群組底下。

至於標籤可以疊幾層，理想上是無限層，現在確實如此。
但曾經被鎖定到 3 層，這個我之後的開發心得會提到。

核心功能之二：系列文#

接著是系列文，這其實是考慮到學習時，會有個時間線，或者線性發展。
創立 Blog 時，正好是我研究 BTRFS 基礎的末期。
雖然 BTRFS 有的功能應該是要同時學的，但是考慮到不同功能的重要性，以及難易度，所以我認為 BTRFS 是個可以寫成系列文的領域。

但是既然要創 Blog，未來我肯定不只有學 BTRFS，所以我對系列文分類做了設想。

最後在我腦中，浮現一套…又是樹狀結構。
而且跟標籤系統一樣，都是為了避免扁平化，導致系列文在部落格成長後，變得難找的問題。

只是不同的是，我認為系列文的數量，不會像文章和標籤一樣，有爆炸性的需求。
加上我在設計上，系列文走的是總覽路線，所以我只規劃了三層。
這三層是領域 -> 分類 -> 系列，大致長這樣：

├── Domain1
│   ├── Category1
│   │   ├── Series1
│   │   │   ├── post1.md
│   │   │   ├── post2.md
│   │   │   └── ...
│   │   ├── Series2
│   │   └── ...
│   ├── Category2
│   └── ...
├── Domain2
└── ...

不規劃更多層，主要還是互動方式，因為我打算用縮圖 + 標題來分類系列文。
標籤能收折，多幾層還能慢慢展開找；但系列文是一次攤開來看，層數一多就很難找。

然後到了系列這一層級，文章與文章之間的關係，我也用「部分/章節」(Part) 作為分類，用來表示這系列文之間的關係。
比如我的日用 Linux 記錄，就可以用「Ubuntu age」和「CachyOS age」來切割記錄時段。

到了 BTRFS 上，也可以用前置、歷史，或者基礎、進階來切分文章關係。

其他重要的功能#

同樣看重的站內搜尋#

呃…沒錯，又是逛 Ivon 部落格引發的痛點…

接續前面分類 + 標籤的問題，就算分類做得再直覺、標籤也有刻意控制數量，
只要文章數量持續增長，還是會不可避免的增加找文難度。

這時搜尋功能就很重要。
然而像是 Ivon 的部落格，用的卻是 Google 和 DDG 的站外搜尋。

架站之前，有次想找他之前寫過的文章，重溫一下。
結果只記得大概內容，也不記得詳細標題，用了站內的「使用 Google 搜尋」後，居然沒找到文章。
文章不一定好找，如果文章太新，但又剛好不在首頁，搜尋引擎還沒收錄，狀況更糟。
並且這樣做，一定會打開新分頁，打斷瀏覽體驗。

另一種情況，你知道內容跟什麼有關，也大致記得有打什麼標籤，但你就是不記得詳細內文和標題，站外搜尋也會變得極不可靠。

有了這種使用經驗，加上我的部落格，需要承擔知識庫的功能，站內搜尋變得尤為重要。
這也是為什麼，我不止要整合搜尋功能，而且強烈要求是「站內搜尋」。

除了打標題、內文，最好也能根據系列、標籤找文章，這是站外搜尋做不到的。

閱覽文章好用的 TOC#

你如果有去看，我在 GitHub 上的筆記的話，你會發現，我會在文章最前面，放一個 [toc]。
不過這個功能，並不是標準的 Markdown 寫法，而是 HackMD 等，這類筆記平臺的擴充寫法。
Astro 官方的 Blog 模板預設不支援這種寫法，所以不是放個 [toc] 就有導覽可以用。

但好消息是，可以自己做 (同時也獲得更多自由)。
所以我參考了其他網站，TOC 放左放右的都有，我選擇把文章 TOC 放在左邊。
考慮到我有系列文，系列文也可以做導覽，既然文章 TOC 放左邊，那就把系列文清單放右邊。

因此這樣就規劃了「文章 TOC」，以及「系列文 TOC」，分別放置文章左右兩側。

設計哲學的參考#

簡約的基底#

設計哲學嘛…還是 Ivon 的部落格，不過主要是深色模式，以及那簡約的風格。
不是現在修改過的，而是改版前，一看就是 blowfish v2 的味道。
這裡放一個今年 5 月 17 日的副本。

當時深色模式的色調，我也覺得更加舒服，所以這個色調，也是我深色模式參考色之一。

流暢的體驗#

如果說，(當時) Ivon 的部落格主題，影響的是視覺風格。

那這個主題，就是啟發我，做好互動體驗的主題，有請 Koharu 出場。

畢竟在動手之前，還是會挑個好看、好用的主題，至少確認有沒有順手的，或至少順眼的，即使不用，也可以參考。
我是直接在 Astro themes 上逛的，商店會照上架順序放，所以我逛商店物色和參考時，還不知道 Astro Paper 這類熱門主題。

Koharu 是讓我第一次感受到，Blog 瀏覽體驗可以「很流暢」的主題。

比如游標放到導覽列的按鈕上，會有流暢的動畫和回饋。
還有切換頁面時，不是簡單的「白一下」，再來載入內文和主題，而是主題不動，底下內容流暢的過渡。

顏色模式的切換也是，不是按下去，就是直接的黑白切換。
(當時)看到顏色切換，可以像是流水一般，刷過去的切換的時候，讓我意識到，顏色切換也可以用動畫過渡。

但在功能上，Koharu 延續 WordPress 時，CMS 那套扁平標籤，加上分類。
不過在此之上，它還加上了一個東西，叫做「週刊」，有點類似我的系列文系統。
Koharu 放在主頁的精選分類，我也參考了一下，最終讓我在首頁，也有「精選系列」這個設計。

配色的哲學#

但 Koharu 整體是粉藍色調，加上不少功能，並不是我需要的，所以更多還是參考「體驗」這件事。
在配色上，主要還是參考其他地方，以及有自己的想法。

如簡約的基底說過，主要參考 Ivon 的部落格的深色模式。
顏色自然是元素之一，當時是很深的藍色，不是完全的黑底，所以感覺有點個性。
除此之外，我還有參考一個配色，當時我還在用 VS Code，我會用 Markdown Preview Enhanced 這個擴充功能。
它內建一個 github-dark.css，這個 Markdown Preview 的背景，我也覺得挺好看的，所以也納入參考。
(我太久沒用 VS Code，配色檔名可能拼錯，或者沒了)

至於淺色，(改版前的) Ivon 的部落格就是反例了，整片純白。
我不確定是不是 blowfish (v2) 預設就是白色。
同樣是白色，Koharu 因為是粉藍 (尤其大面積粉色)，所以文章區用白色，可以接受，甚至很搭。

我覺得如果要走純色，純白如果圖少能接受，但是如果圖多，至少加點很淺的灰色當底，或者點綴會更好。
對我而言，一片純白主題，上面種上一堆縮圖，也沒其他點綴，就像是文章泡在牛奶浴裡。
(還是以 Ivon 的部落格為例，改版後的主題，因為導覽列不是白的，反而比較舒服)

扯遠了，既然要點綴，先從我喜歡的顏色下手。
我喜歡藍色系，淺色模式那就是淺藍色，像 Minecraft 原版的淺藍色我就很喜歡。
這種藍色，給人一種天空藍，或者清澈淺灘的水色。

最終，我定調淺色模式，使用很淺的水藍、天空藍為主色調。
而深色模式，以很深的藍色，或者是類似星空黑(其實也是很深的藍色)為主色調。

整體的視覺#

顏色最終定調為藍色系後，還有整體的設計語言，這件事沒定調對吧？

先說說主頁，大幅參考 Ivon 的部落格，也就是頭貼 -> 自我介紹 -> 文章。
但是展示文章這塊，參考的是 Koharu 的設計，然後稍加修改與組合。

在文章列表上，不使用同樣源自 WordPress 的歸檔，而是參考被 Ivon 隱藏的所有文章。
同樣是有文章縮圖，和標籤等資訊，但風格的部分，則繼承主頁那套書籤式設計。

在閱讀文章上，則是盡量保持簡潔。
中間是文章，上面是導覽列，左右兩邊如前面所說，分別是文章和系列文的 TOC。

最終，整體的格調就是——

藍色系，以閱讀體驗為主，其餘的美編，服務於個人風格，和細節打磨。

剩下的功能，以及那些放掉的功能與設計#

剩下有做的功能#

既然是建立 Blog，有些功能在其他 Blog 很常見，所以也有做。
像是友站 / 部落滾，或者是留言板。
「關於我 / 本站」算是標配，同樣參考 Ivon，這頁內容不贅述。

被放掉的功能與設計#

但是其他，不是多數部落格會標配的功能，我基本上就沒做。
比如 Blog 音樂，或者是隨機文章等功能。
這些功能我認為，對於瀏覽和閱讀沒有太大幫助，所以沒實作。

也有一些是考慮過，後來沒實作的功能。
比如參考 Ivon 的部落格，我也曾考慮在主頁放橫幅，後來沒放。

比較值得一提的，我曾經考慮過，要做一頁叫做「筆記」，專門放我的公開筆記。
有點類似 Blog 對應 Linux-Jump-log，筆記頁對應 Markdown-Note。
後來發生前面說過的事，我寫完 Snapshot 實作與原理，確立記錄即筆記，寫到別人看得懂。

既然文章本身就能當筆記，筆記頁也就沒必要，之後就沒有實作了。

補充和接下來#

因為期中考和光復連假，讓我現在有機會，可以抽空寫文章，心情真複雜…

原始的 Blog 建立和規劃心得在這裡。
可以看出當初的規劃，與這篇文章差很多。
有些功能是邊開發邊想到，或者寫完這篇才想到。

這篇的續集，我會來說說，我「打造」屬於我的主題的過程，以及開發環境。

Reference#

• Ivon的部落格
• Astro theme - Koharu
• Ivon的部落格 Wayback Machine 20260517
• VS Code Marketplace - Markdown Preview Enhanced

留言