[013] 【狀態】SOS 按鈕為什麼不能藏在選單裡？緊急功能的視覺優先權設計
在資源有限的獨立開發環境中，每一個介面元素的擺放都必須經過深思熟慮。特別是對 FollowMe8 這樣一個旨在「防走失」的工具而言，某些緊急功能，其設計哲學必須跳脫傳統的「整齊收納」思維。今天的問題是：為什麼 SOS 緊急求助按鈕不能像其他次要功能一樣，藏在選單深處？
① 遭遇的問題或衝突：緊急時刻的功能可達性
設想一下，當車隊成員在山區突發狀況、需要緊急呼叫時，他們會處於高度緊張甚至恐慌的狀態。此時，時間就是一切。如果 SOS 按鈕被隱藏在層層選單之後，用戶必須冷靜地導航、點擊「更多選項」或「設定」，再找到「緊急功能」——這在實際壓力情境下幾乎是不可能完成的任務。對一個設計初衷就是「在最危急時刻提供援助」的 App 來說，找不到功能，就形同虛設。
② 考慮過的選項（含被放棄的那個）
我們最初也曾考慮過，為了保持主介面的簡潔，將 SOS 按鈕隱藏在一個通用選單（例如「…」圖示）內，或者只有在特定情況下才浮現。這種做法在許多功能型 App 中很常見，能讓日常操作介面更清爽。
③ 為什麼選了這個，放棄了那個
最終，我們堅定地放棄了將 SOS 按鈕隱藏的方案，轉而選擇讓它在主地圖追蹤介面中保持高可見性。關鍵理由在於「應急」和「直覺」。在危急情況下，人腦處理複雜資訊的能力會顯著下降，肌肉記憶和視覺直覺會取代邏輯判斷。SOS 功能的設計目標是零思考路徑，必須讓用戶一眼看到、一鍵觸發。
然而，高可見性也帶來了誤觸的風險。為此，我們加入了多重防護機制，在不犧牲可達性的前提下確保可靠：
1. 防誤觸：用戶首次點擊 SOS 後，會啟動 3 秒倒數確認。
2. 二次確認：倒數結束後，用戶必須在 30 秒內再次點擊確認，`confirm_deadline = 發起時間 + 30 秒`。若未確認，SOS 請求將自動取消。
3. 自行取消：即使進入 `pending` 狀態，發送者仍可在確認期限內通過 `DELETE /api/v1/activities/:id/sos/:id` 取消請求，將 `sos_alerts` 狀態從 `pending` 轉為 `cancelled`。
這些防呆措施確保了按鈕的顯眼不會導致頻繁的虛假警報，有效平衡了「可及性」與「可靠性」。當 SOS 透過 `POST /api/v1/activities/:id/sos` 發出，API 返回 `{ “sos_id”: 123, “status”: “pending”, “confirm_deadline”: 1733547630 }` 時，系統便已啟動這些嚴謹的流程。
④ 這個決策對用戶的實際影響
這個設計決策，讓 FollowMe8 的用戶在最需要幫助的時候，能夠以最快、最直覺的方式發出求助訊號。領隊和車隊成員可以相信，當意外發生時，SOS 功能不是一個藏匿在選單深處的裝飾品，而是一個隨時待命、關鍵時刻能確保彼此不跟丟的生命線。它讓用戶在戶外活動時多了一層安心保障，真正體現了精簡架構下，省電無感且直覺易用的終極目標。
👉 了解更多關於 FollowMe8 短期活動追蹤定位 App：
https://followme8.ofuyuan.com/