我們改善了聯絡表單的送出體驗
我們改善了聯絡表單的送出體驗 — 編譯摘要
濃縮
- 靜態網站的表單處理依賴第三方服務：Codotx 官網為靜態網站，使用 FormSubmit 作為表單代收服務，無需自架伺服器即可將表單內容轉寄至指定信箱。
- 從整頁跳轉到 AJAX 背景送出：原本表單送出採用傳統的 form action 跳轉，改為 AJAX（背景送出）後，使用者全程留在網站上，體驗從「離開座位去櫃台」變成「按桌上按鈕」。
- FormSubmit 的新收件人驗證機制是觸發改善的導火線：新增副本信箱後，因 FormSubmit 要求新收件人先驗證啟用，驗證前不會自動導回原網站，導致表單卡在第三方頁面。AJAX 方式繞過了這個問題。
關鍵證據：改善後按鈕顯示「處理中…」狀態回饋；成功後自動跳轉至自訂感謝頁面；信箱即時收到包含完整表單內容的通知。
質疑
- 前提假設：假設使用者會因為短暫的頁面跳轉而感到困惑，但多數使用者對表單送出後的短暫載入已有預期，這個體驗問題的嚴重程度可能被高估。
- 邊界條件：AJAX 送出繞過了 FormSubmit 的跳轉機制，但若 FormSubmit 的 API 端點變更或加入 CORS 限制，AJAX 方式可能失效，屆時需要另尋解法。
- 反例：許多高流量靜態網站選擇使用 Netlify Forms、Vercel Functions 或自建 Serverless Function 來處理表單，這些方案本身就不存在跳轉問題，且對第三方服務的依賴更低。
- 安全性考量：AJAX 送出後，表單的錯誤處理（網路中斷、服務端錯誤）需要在前端妥善處理，否則使用者可能看到「處理中…」後沒有任何回饋。
對標
- [[靜態網站表單處理]]：靜態網站（SSG）缺乏後端的限制，催生了 FormSubmit、Formspree、Netlify Forms 等 Form-as-a-Service 產品類別，這是 Jamstack 架構的典型權衡。
- [[AJAX 與使用者體驗]]：從整頁跳轉到 AJAX 的演進，是 Web 開發中最經典的 UX 改善模式之一，Gmail（2004）的成功很大程度上就建立在這個技術轉變上。
- [[漸進增強]]：這次改善的觸發點是「新增功能（副本信箱）導致舊方案失效」，體現了技術債的典型觸發模式——不是主動重構，而是被迫改善。
- [[第三方服務依賴風險]]：FormSubmit 的驗證機制變更直接影響了網站行為，與 [[LINE Messaging API]] 的政策風險屬同一類別的供應商依賴問題。
關聯概念
[[靜態網站表單處理]]、[[AJAX 與使用者體驗]]、[[漸進增強]]、[[第三方服務依賴風險]]、[[Jamstack]]、[[FormSubmit]]