選項清單按使用者掃描順序排序、不按資料來源預設。 短清單先看完、長清單花更多時間 — 把短清單放前面讓使用者先排除一個維度、再面對長清單。字母排序對「找已知名稱」有效；多選 facet 場景下使用者通常不知道確切選項名、需要 scan，這時候掃描成本主導。

為什麼掃描成本優先於字母排序

商業邏輯

當清單有多個選項供使用者挑選，選項數量影響掃描時間。使用者在 facet UI 的行為不是「找已知 tag」、是「看到有什麼可選、選有興趣的」 — 這是探索式行為、不是查找式行為。

字母排序是資料庫思維（穩定、可預測），掃描成本排序是 UX 思維（縮短決策時間）。Facet 場景幾乎都是後者。

兩條維度收斂的順序

當有多個 facet 維度可選、使用者通常逐維度收斂：先用一個維度砍掉一半結果、再用第二個維度精選。短清單放前面讓「第一刀」決策快速。

這次任務的應用

觀察

Pagefind filter 預設按 filter key 字母排序：tag < type，所以 Tag 先顯示。

實際內容：

判讀

Type 短、Tag 長 — 預期使用者行為是「先按 type 收斂（這是 post 還是 glossary？）、再進 tag 找主題」。Tag 在前等於要使用者先面對 80 個選項，認知成本高。

把順序倒過來：Type 先顯示讓使用者先用 section 收斂、再進 Tag 找。

執行

 1function reorderFilters() {
 2  var blocks = filter.querySelectorAll('.pagefind-ui__filter-block');
 3  var desiredOrder = ['type', 'tag'];
 4  var byKey = {};
 5  blocks.forEach(b => {
 6    var key = b.querySelector('.pagefind-ui__filter-name').textContent.trim().toLowerCase();
 7    byKey[key] = b;
 8  });
 9  desiredOrder.forEach(k => byKey[k] && filter.appendChild(byKey[k]));
10}

內在屬性比較：四種排序策略

選擇順序：有 analytics → 頻率排序；沒有 → 掃描成本排序；都不適用 → 字母排序。

排序原則的延伸應用

同類 facet 內的選項排序

Tag 內部的 80 個 tag 怎麼排？

當前接受 pagefind 的字母排序（成本最低、且 80 個 tag 做計數排序需要額外索引處理）。

選項數量門檻

短清單跟長清單的邊界沒有絕對值，常用啟發：

• ≤ 7 個選項：可一眼掃完、放前面
• 8-20 個：中等、需要結構（縮排、分組）
• 20+ 個：長清單、放後面或加搜尋框

Type 5 個落在「短」、Tag 80 個落在「長」 — 順序明顯。

設計取捨：選項清單的排序策略

四種做法、各自機會成本不同。預設依使用者行為性質選 — 探索式 → A、查找式 → B、有 analytics → C、有子類別 → D。

A：掃描成本排序（短先長後）（探索式 facet 的預設）

• 機制：選項數量少的維度放前面（type 5 個 → 先；tag 80 個 → 後）
• 選 A 的理由：使用者先用短清單收斂一刀、再面對長清單；認知成本低
• 適合：探索式 facet（使用者不知道確切選項名）
• 代價：需要主動覆寫資料來源預設（不能直接用 DB 順序）

B：字母排序

• 機制：按 alphabetical 排
• 跟 A 的取捨：B 對「找已知名稱」高效（二分查找）、A 對「探索式選擇」高效；但 facet 場景幾乎都是探索式
• B 比 A 好的情境：使用者通常知道確切選項名（國家清單、語言清單）

C：使用頻率排序（最常用在前）

• 機制：按 analytics 統計、最高頻選項在前
• 跟 A/B 的取捨：C 比 A 更精準（用真實資料）、但需要 analytics + 冷啟動時無資料
• C 比 A 好的情境：有足夠 analytics、且使用者偏好集中（80/20 分布明顯）

D：語意分組排序

• 機制：把選項分子類別、組內再排
• 跟 A 的取捨：D 對「選項有明顯子類別」更直觀（產品類別 / 功能類別）、A 對純扁平清單夠用
• D 比 A 好的情境：選項有清楚的層級結構（電商 facet：類別 > 子類別 > 選項）

判讀徵兆

核心原則：UI 排序是設計決策、不是技術選擇。預設順序通常反映資料來源結構、不反映使用者行為 — 主動覆寫是常態、不是例外。

跟 #55-#66 Filter × Source 系列 的關係：本卡是「filter UI 的排序」、Filter × Source 系列是「filter 行為的層級」 — 兩個維度互補。設計 filter UI 時兩者都要顧：本卡決定「哪個選項放前面」、#58 決定「篩選的定義域是哪一層」、#59 決定「filter 跟 source 怎麼合成」。

Mode（模式）跟 Facet（多面向篩選）是兩個語意層級、UI 區域必須分開。 Mode 決定「如何搜」、Facet 決定「篩選什麼結果」 — 兩者作用點不同、混在同一 UI 區會讓使用者誤以為是同層的選項、產生「為什麼勾這個結果這麼少」的困惑。

為什麼語意層級要對應視覺分區

商業邏輯

搜尋 UI 包含的控制看起來都是「縮小結果」、語意層級實際不同：

Mode 在「搜尋」之前生效、Facet 在「搜尋」之後生效 — 兩者在 query pipeline 的位置不同。

混在一起的失敗模式

把 mode 跟 facet 放在同一 UI 區域、使用者預設兩者作用相同：

使用者看不出「為什麼結果差異這麼大」 — 因為以為換了一個 facet、實際換了搜尋演算法。

UI 慣例位置

慣例位置反映語意層級 — mode 屬於「query 構造」、facet 屬於「結果處理」。

這次任務的應用

觀察

搜尋頁有兩類控制：

判讀

把 scope 放進 filter 區會讓使用者把它當第三種 facet — 但「全部 / 標題 / 內文」不是篩選現有結果、是換搜尋範圍：

• 勾「標題」：搜尋只跑標題欄位、內文有的字直接 0 結果
• 取消「標題」（切回「全部」）：搜尋範圍擴大、結果集完全不同

如果使用者以為這是 facet、預期「取消會稍微多幾個結果」 — 實際結果集大幅變動會困惑。

執行：分區擺放

兩者視覺上明顯分開、使用者可區分「這是改搜尋方式」vs「這是篩結果」。

內在屬性比較：三種 mode/facet 擺放

優先選「分區 + 視覺暗示」 — 不需要文字說明、靠位置即可辨識。

進階：多個 mode 並存的處理

當有多個 mode（搜尋範圍 + 排序方式 + 語言）：

每個 mode 跟它影響的範圍視覺鄰近 — 影響搜尋範圍的靠 input、影響結果排序的靠結果。

Facet 也可以分多區（type/tag 在 sidebar、價格區間在結果上方）— 但 mode 與 facet 之間永遠保持區域分離。

設計取捨：搜尋控制的擺放策略

四種做法、各自機會成本不同。這個專案選 A（Mode 靠 input + Facet 靠結果）當預設、其他做法在特定情境合理。

A：Mode 緊貼 input + Facet 靠近結果（這個專案的預設）

• 機制：mode 控制（搜尋範圍 / 排序）放 input 旁；facet 控制（type / tag）放結果區或 sidebar
• 選 A 的理由：位置就是契約 — 靠 input 的影響搜尋本身、靠結果的篩選結果；使用者靠位置辨識語意層級、不需文字說明
• 適合：搜尋 UI、有 mode + facet 兩種控制
• 代價：UI 拆兩個區、空間使用多一些

B：所有控制集中 sidebar

• 機制：mode + facet 都放 sidebar 一起
• 跟 A 的取捨：B 集中管理視覺乾淨、A 分區語意清晰；但 B 使用者區分不了哪個影響 query、哪個影響結果
• B 是反模式：mode/facet 混淆是 UX 痛點 — 使用者區分不了哪個影響 query、哪個影響結果

C：所有控制集中 input 旁

• 機制：mode + facet 都靠 input、結果區無控制
• 跟 A 的取捨：C 操作集中、A 按語意分；但 C facet 跟結果脫鉤、視覺暗示錯
• C 比 A 好的情境：facet 數量極少（< 3 個）、放 input 旁不擁擠

D：加文字說明取代位置暗示

• 機制：UI 加「此項目影響搜尋演算法」「此項目篩選結果」說明
• 跟 A 的取捨：D 文字精確、A 靠位置直覺；但 D 增加閱讀負擔、使用者通常跳過說明
• D 比 A 好的情境：複雜搜尋介面（多種 mode、多層 facet）— 純位置暗示不夠

判讀徵兆

核心原則：搜尋 UI 的控制不是同層的「篩選器」 — 語意層級不同、視覺分區也應不同。位置就是契約：靠 input 的影響搜尋本身、靠結果的篩選結果。

跟 #58 篩選類指令的澄清時機 的關係：mode 跟 facet 是兩種不同的「篩選類指令」。Mode（如「title-only / content / both」）通常重塑 query → 對應 #58 三問的「定義域 (c) 重新搜尋」；Facet（如「type=post tag=js」）通常加 filter 條件 → 對應「定義域 (b) 在所有結果裡找」。語意分區是視覺面、定義域選擇是行為面 — 兩者一起設計才完整。