摘要

TrueLink 這次改版，從桌機畫面利用率、文章分類、跨裝置導覽與多語一致性開始，也檢查了 AI 副駕駛是否真正接上功能。本文說明我們如何區分寬版列表與文章閱讀寬度、規劃固定搜尋及國家／語言選擇，以及透過舊版負控與修後回歸避免只換外觀、功能仍未接好的問題。目前部分修補已完成本地驗證，整體版型與十三語網站仍需逐批完成發布和正式驗收，尚無排名或轉換率提升的實測結論。

從使用者遇到的問題開始

這次調整有幾個具體起點：大螢幕上的內容區偏窄，兩側空白沒有幫助使用者找到文章；首頁、工具與 Blog 的分類和導覽，需要更一致；部分頁面的 AI 副駕駛看得到入口，卻沒有完整掛載對應功能。

多語也帶來另一層問題。同一個頁面若選單、內容、搜尋與登入返回路徑使用不同語言，使用者即使看見語言選單，也可能感到系統沒有對齊。因此，我們把版型、共用模組和語言狀態一起納入驗收，而不是只翻譯首頁標題。

這份紀錄分享的是改善方法與目前證據。未完成正式發布的部分，仍會清楚標示，不把新版示意當成上線畫面。

寬版列表與文章行長，分開處理

我們採取的方向是：列表充分使用螢幕，正文保留適合閱讀的行長。

Blog、工具中心與 Offers 屬於探索型頁面，使用者需要比較多個項目。這類列表可以隨可用寬度調整欄數，讓分類、圖片與摘要一起幫助判斷，避免大螢幕仍沿用狹窄的單欄區塊。

文章正文則不同。我們以約 65–75ch 作為版型設計起點，再依繁中、英文、字型與手機實際閱讀調整。這是本次設計選擇，不是每種語言都適用的固定規則；尤其中文的實際字寬，仍須另外驗證。

響應式設計也不必為每一種裝置尺寸各做一頁。彈性網格、相對尺寸和適當斷點，可以讓內容隨空間調整；當標題被擠得難讀或文字行長過長時，再改變版面配置。參考 MDN 響應式設計：https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/CSS_layout/Responsive_Design

這樣做的優點是大螢幕能呈現更多有用內容，手機仍能逐項閱讀。代價是圖片、長標題、空狀態及分類操作需要更多測試，也不能靠拉伸低解析圖片來填滿畫面。

固定選單與搜尋，讓探索過程不中斷

我們規劃把共用導覽收斂成穩定的入口：品牌、主要分類、搜尋、國家／語言與會員操作，依桌機和手機採用不同呈現。

固定搜尋適合文章與工具較多的平台，使用者捲動後仍能開始下一次搜尋。但固定區塊必須克制，不能遮住標題、表單或鍵盤焦點。手機展開搜尋時，也要有明確關閉方式、可理解的空結果，以及返回後的位置保存。

分類的目的，是縮短找到內容的路徑。文章、工具與優惠可以共用搜尋入口，但應保留各自的結果類型和可見權限，避免把公開介紹與需登入的工作區混成同一種內容。

國家／地區與語言，是兩個偏好

選擇台灣，可以建議繁體中文；選擇日本，可以建議日文。但使用者可能住在日本、偏好英文，也可能在台灣使用其他語言。

因此，我們把國家／地區與語言分開設計：

  • 地區提供建議，明確選定的語言保持優先。
  • 切換語言時，優先回到同一內容的對應版本。
  • 沒有譯文時，清楚說明顯示原文，或提供返回選擇。
  • 不因地區偏好，自動改寫國籍、地址、稅務或服務資格。
  • 登入與返回流程，不應意外覆蓋使用者已選語言。

搜尋引擎的語言標記也必須對應真實頁面。Google 的多語版本指引要求各語言頁面列出自身與對應版本；這些關聯應建立在確實存在的內容上。參考 Google 多語頁面指引：https://developers.google.com/search/docs/specialty/international/localized-versions

十三語的「有入口」與「已完成」，分開報告

我們的網站與 Blog 正朝十三語整合，但語言選單有十三個選項，不等於所有頁面都已有完整譯文。

驗收需要分清楚幾件事：介面是否翻譯、文章是否存在、不同語言是否連到同一主題、搜尋能否理解目前語言，以及頁面是否具備正確的索引與發布狀態。

缺譯時顯示原文，可以保留內容可用性，但必須讓讀者知道目前看到的是什麼。不能用中文 fallback 冒充外語版本，也不應為不存在的譯文建立看似完整的語言關聯。

這種分階段交付較容易看見真實缺口，也能避免單一語言失敗時，影響其他已驗證版本。

AI 副駕駛：入口出現，不代表功能已就緒

本次查核找到一個值得分享的共用模組案例：某頁已出現狀態入口，但頁面沒有完整宣告 AI 功能；另一個備援入口因偵測到它而退讓，形成「看得到入口，功能卻沒有完整接上」的狀態。

本地修補採取兩個原則：

第一，由頁面明確宣告允許的功能。以顧問介紹頁為例，副駕駛只需說明本頁服務，不應因此取得表單或付費工具的使用範圍。

第二，備援應在主要模組真正就緒後才退讓。單純找到一個入口元素，或載入一份程式資產，都不足以證明使用者可以正常操作。

我們也測試了切換工作區和語言時的延遲回應。共用外觀可以一致，但對話不能混入先前情境；換頁後的說明，也必須更新成目前頁面的內容。

用舊版紅控，確認測試真的抓得到問題

這次沒有只檢查修後畫面是否出現。我們把兩個已知缺陷放回舊版作為負控，確認測試會失敗，再驗證修補後通過。

目前與本次模組相關的本地證據包括：

  • 兩個原版缺陷負控如預期失敗，證明測試可抓到這兩個問題。
  • 修後模組回歸 11 項通過；這不等於全站所有 AI 流程通過。
  • 必要本地檢查 20 項通過；正式版本與發布前驗證仍須分開確認。
  • 桌機、375px、360px 的瀏覽器驗證涵蓋深淺色與失敗恢復，使用隔離合成資料，沒有向正式 AI 發送測試訊息。
  • 正式部署驗收尚未完成，不能稱新版已正式修復成功。

目前改善仍在逐批完成發布前驗證。讀者可把這份紀錄當成設計與測試方法，正式上線成果會在完成驗收後另行更新。

優缺點與適用場景

這套方向適合文章、工具與語言版本逐漸增加的平台。共用導覽與模組可以減少重複維護，寬版列表有助探索，情境隔離則讓跨頁操作更清楚。

它也有成本。共用模組的影響面較大，每次調整都要注意不同頁面的初始化和相容性；多語需要驗證內容關聯，不能只看字典數量；固定區塊與動畫，還要考慮鍵盤、文字放大和減少動態偏好。

對只有少量內容的單頁網站，精簡導覽可能更合適。設計應服務內容和使用者任務，不需要為了追求平台感加入所有控制項。

無障礙方面，我們會繼續以內容重排與放大後可操作作為驗收方向。W3C 的 Reflow 說明也強調，內容放大後應避免不必要的雙向捲動；本次手機驗證不能替代完整無障礙符合性檢查。參考 W3C Reflow 說明：https://www.w3.org/WAI/WCAG22/Understanding/reflow.html

下一階段

接下來會逐批完成共用模組、Blog 版型及多語內容的發布前驗證與正式驗收。舊版公開畫面與新版示意會分開標示，不提供虛構的上線前後對照。

若要規劃自己的網站，可以先盤點最常見的使用路徑：讀者從哪裡進入、如何找到內容、切換語言後去哪裡，以及登入或失敗後如何返回。這些路徑清楚了，視覺調整才有可驗證的目標。

延伸了解：TrueLink 官網 https://truelink-group.com/ · TrueLink 顧問服務 https://truelink-group.com/consulting/ · TrueLink 知識庫 https://truelink-group.com/blog/