Mode 與 Facet 是不同語意層級、UI 區域分開擺放
核心原則
Mode（模式）跟 Facet（多面向篩選）是兩個語意層級、UI 區域必須分開。 Mode 決定「如何搜」、Facet 決定「篩選什麼結果」 — 兩者作用點不同、混在同一 UI 區會讓使用者誤以為是同層的選項、產生「為什麼勾這個結果這麼少」的困惑。
為什麼語意層級要對應視覺分區
商業邏輯
搜尋 UI 包含的控制看起來都是「縮小結果」、語意層級實際不同：
| 控制類型 | 作用對象 | 改變的東西 |
|---|---|---|
| Mode | 搜尋演算法本身 | 「如何搜」（範圍、方法） |
| Facet | 已搜結果集 | 「篩什麼結果」 |
Mode 在「搜尋」之前生效、Facet 在「搜尋」之後生效 — 兩者在 query pipeline 的位置不同。
混在一起的失敗模式
把 mode 跟 facet 放在同一 UI 區域、使用者預設兩者作用相同：
| 使用者誤判 | 實際發生 |
|---|---|
| 勾「標題」是過濾標題欄位（facet） | Mode 改變搜尋範圍（標題不含的字會直接 0 結果） |
| 取消勾「標題」會擴大結果 | 取消等於切回「全部」mode、搜尋邏輯整個換 |
使用者看不出「為什麼結果差異這麼大」 — 因為以為換了一個 facet、實際換了搜尋演算法。
UI 慣例位置
| 控制類型 | UI 慣例位置 | 視覺暗示 |
|---|---|---|
| Mode | 緊貼輸入框（旁邊或下方） | 「跟搜尋本身綁在一起」 |
| Facet | 結果區附近 / sidebar | 「在結果上做的事」 |
慣例位置反映語意層級 — mode 屬於「query 構造」、facet 屬於「結果處理」。
這次任務的應用
觀察
搜尋頁有兩類控制：
| 控制 | 類型 | 原本位置 |
|---|---|---|
| 搜尋範圍：全部 / 標題 / 內文 | Mode（影響 regex 比對範圍） | 一開始想塞進 filter 區 |
| Filter：Type / Tag | Facet（在已搜結果上篩選） | Pagefind 預設 sidebar / drawer |
判讀
把 scope 放進 filter 區會讓使用者把它當第三種 facet — 但「全部 / 標題 / 內文」不是篩選現有結果、是換搜尋範圍：
- 勾「標題」：搜尋只跑標題欄位、內文有的字直接 0 結果
- 取消「標題」（切回「全部」）：搜尋範圍擴大、結果集完全不同
如果使用者以為這是 facet、預期「取消會稍微多幾個結果」 — 實際結果集大幅變動會困惑。
執行：分區擺放
| 控制 | 最終位置 | 視覺距離 |
|---|---|---|
| Scope（mode） | 搜尋輸入框正下方 | 緊鄰 — 跟 input 視覺綁在一起 |
| Filter（facet） | 左側 sidebar（≥ 1400px）或 pagefind drawer（< 1400px） | 跟結果區一起 |
兩者視覺上明顯分開、使用者可區分「這是改搜尋方式」vs「這是篩結果」。
內在屬性比較：三種 mode/facet 擺放
| 擺放策略 | 使用者誤判風險 | 實作成本 |
|---|---|---|
| 全部塞同一區（filter） | 高 — mode 被誤當 facet | 低 — 不分區 |
| Mode 在 input 旁、Facet 在 sidebar | 低 — 視覺暗示明確 | 中 — 兩個 slot |
| Mode 在 input 旁、Facet 在 sidebar、加說明文字 | 最低 — 雙重提示 | 中 — 多文字 |
優先選「分區 + 視覺暗示」 — 不需要文字說明、靠位置即可辨識。
進階：多個 mode 並存的處理
當有多個 mode（搜尋範圍 + 排序方式 + 語言）：
| Mode 類型 | 慣例位置 |
|---|---|
| 搜尋範圍 | input 下方 |
| 排序方式（相關度 / 日期） | 結果區頂端 |
| 語言切換 | 全站 header（最高層級） |
每個 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）— 純位置暗示不夠
判讀徵兆
| 訊號 | 對應問題 | 修正動作 |
|---|---|---|
| 使用者問「為什麼這個結果出現了」 | mode/facet 混淆 | 確認控制類型、分區擺放 |
| 取消某個篩選、結果集大幅變動 | 該控制是 mode 不是 facet | 移到 input 旁、視覺區隔 |
| 控制集中在 sidebar、有些影響搜尋有些篩結果 | 全部塞 filter 區 | 拆出 mode 區、靠 input |
| 新增搜尋功能不知道該放哪 | 沒有分區慣例 | 先判斷 mode/facet、再決定位置 |
核心原則：搜尋 UI 的控制不是同層的「篩選器」 — 語意層級不同、視覺分區也應不同。位置就是契約：靠 input 的影響搜尋本身、靠結果的篩選結果。
跟 #58 篩選類指令的澄清時機 的關係：mode 跟 facet 是兩種不同的「篩選類指令」。Mode（如「title-only / content / both」）通常重塑 query → 對應 #58 三問的「定義域 (c) 重新搜尋」；Facet（如「type=post tag=js」）通常加 filter 條件 → 對應「定義域 (b) 在所有結果裡找」。語意分區是視覺面、定義域選擇是行為面 — 兩者一起設計才完整。