GOV.UK 提案頁面
目的
使用真實的 GOV.UK 設計系統樣式與一個小型可重複使用元件庫，製作一份自包含的單一 HTML 頁面，用以論證某個方向、解釋某個想法或推銷某項變革。
核心原則：展示內容，而非敘述內容。 一個團隊擁有的項目清單會變成卡片網格。一組步驟會變成流程圖。一份比較會變成一份標示出差異的表格。散文是元件之間的連接組織，而非資訊的主要承載方式。
描述內容即可；此技能負責處理外觀。
輸出為一個 HTML 檔案
使用此技能建立的頁面以檔案形式分享，通常上傳到 SharePoint 或類似的文件庫並從那裡連結。所以：
- 所有內容都存在一個
.html檔案中。 CSS、字型與圖片都嵌入在內（字型與圖片以 base64 data URI 形式嵌入）。無外部樣式表、腳本、字型或圖片。 - 頁面在關閉 JavaScript 的情況下必須能正確閱讀。 有些文件庫在預覽時會移除或封鎖腳本。互動式元件（例如檢視切換器）是增強功能：在沒有 JavaScript 的情況下顯示的預設狀態必須能獨立自圓其說。
- 讀者無需建置步驟。 檔案直接在瀏覽器中開啟。
檔案
page-starter.html是一個空白頁面：內含 GOV.UK Frontend CSS、以 base64 嵌入的 GDS Transport 字型、完整的元件 CSS、狀態橫幅、英雄區以及包含變更記錄的頁尾。每個新頁面都從複製此檔案開始。GDS Transport 僅授權用於 GOV.UK；在 GOV.UK 之外，請將其替換為其他字型（請參閱NOTICE.md）。docs/index.html是此技能的說明文件頁面，並且是使用此技能建立的。其「元件」章節是視覺參考：每個元件都有名稱和標籤，說明何時使用、何時避免，並附有即時範例。從gx-specimen__demo區塊複製元件標記。請不要複製gx-類別；它們只作用於說明文件頁面。它使用與入門檔案相同的元件 CSS，因此複製的標記無需修改即可使用。
文件結構
在選擇元件之前，先釐清論證。大多數提案遵循此順序；可以刪除不需要的章節。
| 章節 | 功能 | 常用的元件 |
|---|---|---|
| 狀態與英雄區 | 說明文件是什麼以及要傳達的一項重點 | 狀態橫幅，英雄區 |
| 這是什麼 | 如果受眾可能不了解，則解釋這個想法 | 分類，扇形展開，層次，程式碼配對 |
| 它能帶來什麼 | 為在場的每個人帶來的好處 | 效益網格，寬卡片 |
| 為何現在 | 當前面臨的問題與證據 | 孤島，統計數據，比較表，多對一，研究引述 |
| 如何運作 | 提出的方法 | 流程，前後對比，中樞與輻條，扇形匯聚，實際範例 |
| 誰負責什麼 | 責任歸屬 | 責任區分，面板 |
| 從哪裡開始 | 範圍與順序 | 階段，時間軸 |
| 風險 | 可能出錯的地方 | 風險 |
| 待解決問題 | 你需要從讀者那裡得到的資訊 | 待解決問題 |
| 成功標準 | 你如何知道它成功了 | 成功衡量指標，結果 |
| 頁尾 | 版本與變更記錄 | 變更記錄 |
只有當讀者已經了解解決方案空間時，才將「為何現在」放在最前面（請參閱「編輯原則」）。
元件目錄
每個元件都有一個名稱。使用此技能的人可以按名稱要求元件（「使用扇形匯聚來顯示應用程式的來源」），你也應該在建議時使用相同的名稱。docs/index.html 的「元件」章節會即時顯示每個元件，包括其類別、使用時機與避免時機。從那裡複製標記。
頁面裝飾
| 名稱 | 類別 | 使用時機 |
|---|---|---|
| 狀態橫幅 | pt-topbanner | 每個頁面。顯示版本與一行關於文件內容的說明。 |
| 英雄區 | pt-hero | 每個頁面。一個眉毛標籤、標題以及文件中一句最精闢的句子。 |
| 補充說明 | pt-note | 在圖表、表格或統計數據組下方的元資訊：來源、注意事項、「僅供說明」。 |
| 變更記錄 | pt-footer | 每個頁面的頁尾。最新記錄在最上方。 |
卡片
| 名稱 | 類別 | 使用時機 |
|---|---|---|
| 效益網格 | pt-owns-grid | 交付、擁有或獲得的 3 或 4 項事物。 |
| 寬卡片 | pt-owns-card--wide | 某個項目需要比同級項目更多空間，或避免單一卡片獨佔一行。 |
| 原則 | pt-works-grid | 三個原則或工作方式。 |
| 分類 | pt-categories | 事物的類型，每個類型帶有一個小型視覺元素以顯示類別。 |
| 面板 | pt-card | 一個需要比網格卡片更多空間的要點，樣式與其他所有卡片相同。 |
| 風險 | govuk-inset-text pt-card pt-card--warning | 需要防範的風險，以經驗為基礎，直白陳述。 |
| 結果 | pt-card pt-card--success | 如果成功會變成什麼。 |
數字
| 名稱 | 類別 | 使用時機 |
|---|---|---|
| 統計數據 | pt-baseline-grid | 最重要的數字。每個數字都有一個簡明的標籤，如果可能，這組數字加總應等於一個宣告的總數。 |
圖表
| 名稱 | 類別 | 使用時機 |
|---|---|---|
| 扇形展開 | pt-fanout | 一個來源產生多個輸出。 |
| 扇形匯聚 | pt-fanin | 多個來源匯聚成一個事物：決策的輸入、輸入一個記錄的資料、貢獻於一個服務的團隊。最佳效果為 3 到 5 個輸入。範例繪製四條曲線，起點分別在 y 12.5, 37.5, 62.5 及 87.5；如果是不同數量的輸入，將每條曲線的起點設在其輸入的中心（三個輸入：16.7, 50 及 83.3）。 |
| 中樞與輻條 | pt-hub | 一個中心事物，最多有四個部分與其連接。 |
| 孤島 | pt-silos | 同一事物在多處被分開持有，彼此之間沒有連接。標示出內容不同的副本。 |
| 多對一 | pt-many-to-one | 多個名稱或路徑指向同一事物：重複項目、別名、重疊的工作。 |
| 前後對比 | pt-before-after | 同一事物在今日與提案中的樣貌，並排顯示。 |
| 層次 | pt-layers | 互相堆疊的層級，以帶標籤的箭頭連接。連接器標籤使用常規字重。 |
| 流程 | pt-flow | 帶有編號步驟與最終狀態的過程。將未確定的目標標記為開放，並加上「方法待確認」標籤。 |
| 階段 | pt-phases | 按實際順序排列的工作階段。當前階段為實心填充。 |
| 時間軸 | pt-timeline | 標註日期的里程碑。過去的里程碑為實心填充，未來的為空心。 |
| 光譜 | pt-spectrum | 事物在兩個端點之間範圍的位置：成熟度、努力程度、風險。 |
| 團隊 | pt-squads | 團隊之間的關係，特別是在重組時。將狀態變更的團隊標記為虛線。 |
表格與清單
| 名稱 | 類別 | 使用時機 |
|---|---|---|
| 比較表 | pt-compare | 多個選項或地方並排比較。對行進行分組，並在整個儲存格中突顯異常值。 |
| 責任區分 | pt-split | 誰負責什麼，兩個群組並排。 |
| 待解決問題 | pt-questions | 你想得到解答的問題，每個問題都附有負責對象的標籤。 |
| 成功衡量指標 | pt-check-list | 五到六個可勾選的結果。 |
範例與證據
| 名稱 | 類別 | 使用時機 |
|---|---|---|
| 實際範例 | pt-example | 具體案例：一個視覺，然後說明每個地方目前如何處理。 |
| 研究引述 | pt-quote | 使用者、同事或利害關係人實際說過的話，並附上誰說的。 |
| 程式碼配對 | pt-code-pair | 資料、程式碼或設定，單獨或並排顯示。將簡化的片段標記為「僅供說明」。 |
| 色點 | pt-swatch | 在行內、表格或句子中顯示的顏色或狀態。始終與文字標籤配對使用。 |
互動元件
| 名稱 | 類別 | 使用時機 |
|---|---|---|
| 檢視切換器 | pt-views | 在兩個狀態之間切換圖表，例如「今日」與「提案」。非必要，需要 JavaScript。 |
如果內容不符合上述任何一種，則撰寫一個簡短段落（適度使用可以）或新增一個元件（請參閱「擴充元件庫」）。
編輯原則
結構
- 一份文件，一條主線。 每個元件都應服務於核心論證。如果某件事有趣但不承擔關鍵功能，就刪掉它。
- 在為想法辯護之前先解釋它，當受眾可能不了解這個想法時。問題優先的方法只有在人們已經了解解決方案空間時才有效。當他們不了解時，問題章節讀起來就像一串沒有出路的抱怨。請參閱「文件結構」了解預設順序。
- 及早提出好處。 讀者會在前一兩個畫面內決定是否在意。
- 用第一個範例展示完整範圍。 如果第一個範例範圍狹窄，讀者會假設整個提案都很狹窄。當想法適用範圍廣泛時，用一個能暗示其廣度的範例開場，然後用狹窄的案例作為證據。
- 刪除不需要的章節。 如果某個章節是關於另一個對話的決定，就把它省略。
語言
- 在使用一個術語之前先介紹它。 這包括標題、標籤和表格群組。如果術語在解釋之前出現，請改用簡單的描述。
- 給每個術語分配一個任務。 如果兩個相似的詞同時出現（例如「決定」用於單一選擇，「方法」用於整個方式），在整份文件中保持每個詞各自的意思。
- 將某個方法描述為「一種常見的方式」，而不是「唯一的方式」，除非它真的是唯一的方式。這樣更準確，並能促進討論。
- 使用描述性而非責備性的詞語。 「在某些地方有定義，在其他地方沒有」描述了情境。「缺口」或「缺少」則暗示某人失職。
- 當作者提供了措辭時，請按原文使用。 只修正語法，並說明你做了什麼修改。
證據
- 使用來自來源的真實資料（系統、試算表、匯出檔），而不是回憶或估算的數字。說明數字來源。
- 標示任何從螢幕截圖或摘要讀取的內容，以便在頁面分享前進行檢查。
- 不要誇大狀態。 如果某件事反應不錯但尚未正式同意，請精確說明，或省略狀態。
- 將未確定的選擇標記為未確定。 在選項上標記「方法待確認」比將猜測呈現為決定要好。
面對混合受眾的語氣
- 保持公正。 在展示涉及多個團隊或地方的問題時，顯示每個團隊或地方的角色。單獨指出某個群體的頁面，會讓該群體產生防衛心。
- 為在場的每個群體設定共同利益。 用每個群體自己的語言描述他們獲得的好處。不要在文件中提及群體之間的摩擦，即使這是真正的動機。好處可以在不描述摩擦的情況下解決它。
內部風格指南
預設的內部風格指南，可根據需要調整：
- 英式英語，句子式標題，牛津逗號
- 不使用破折號；改用逗號、冒號、分號或句號重新組織句子
- 不使用「它不是 X，它是 Y」的結構
- 不使用軍事或戰鬥隱喻
- 「政府」一詞除非是名稱的一部分，否則使用小寫
- 直白、直接、自信；每個字都有其作用，引言不重複結論
視覺規則
- 所有卡片使用同一種處理方式。 卡片為白色，帶有 1px 灰色邊框、4px 藍色頂部邊框、可選圖示、小標題 (
govuk-heading-s) 和小型內文 (govuk-body-s)。不要發明一次性的卡片樣式；將新內容重新設計以符合規範。 - 網格中不留孤兒。 如果網格會讓一張卡片獨佔一行，則將那張卡片設為寬卡片或更改欄數。
- 色票為圓形，與 GOV.UK 設計系統色彩頁面一致。
- 比較表會突顯整個儲存格，而不是文字後方的行內背景，這樣每個欄位的數值才能對齊。每個儲存格和群組標題的左緣都相同。
- 圖表中的連接器標籤使用常規字重。 粗體用於標題和正在指向的物件。
- 補充說明 (
pt-note)：使用次要文字顏色 (#505a5f) 的 16px 小型內文。用於圖表、表格或統計數據組下方的元資訊：注意事項、來源、「僅供說明」標籤。 - 並排的程式碼區塊高度相同。
- 圖表使用
box-sizing: border-box（在元件 CSS 中設定），這樣內邊距和邊框永遠不會將元件推出其盒子。 - 英雄標籤保持在一行。 GOV.UK 標籤預設最大寬度為 160px；元件 CSS 為英雄區和橫幅移除了此限制。
- 自訂字型或圖片必須嵌入，且僅在其許可證允許的情況下。請先檢查許可證。自訂字型通常需要手動垂直置中：測量渲染後文字並調整內邊距。
- 無障礙性： 為圖表提供文字替代方案（
role="img"搭配aria-label，說明圖表顯示的內容），在互動控制項上保留可見的焦點狀態，並且不要僅依賴顏色來顯示差異（突顯的儲存格同時也是粗體）。
互動元件
檢視切換器 (pt-views) 允許讀者在圖表狀態之間切換，例如「今日」與「提案」，或「亮色」與「暗色」。它並非必要：
- 預設狀態必須是沒有 JavaScript 時也能自圓其說的狀態。
- 使用真實的
<button>元素並搭配aria-pressed。 - 保持腳本行內且極簡；入門檔案中包含一個可重複使用的腳本。
建立工作流程
- 先收集內容：論證、證據、目標對象以及你希望他們做什麼。在內容清晰之前就選擇元件，會產出外表華麗但內容空洞的頁面。
- 使用「文件結構」規劃章節，並從目錄中按名稱挑選元件。如果對方要求特定的元件，請使用那些。
- 將
page-starter.html複製為一個新檔案。填入橫幅、英雄區和頁尾。 - 從
docs/index.html的「元件」章節複製每個元件的標記，並取代佔位文字。切勿在頁面中留下佔位文字。 - 如果頁面使用了檢視切換器，則保留入門檔案末尾的腳本；否則刪除它。
- 在瀏覽器中檢查頁面。