POS 訂位詳情按鈕順序審計
2026-05-18 · dogfood 5/18 觸發 · 老闆原話:「圖二的那些按鈕應該照時序排列…audit 一下所有的按鈕，排列看看，讓我知道你想怎麼做，最好有示意圖」
狀態:全部 Phase A-F 已 ship (commit pending) · 老闆 confirm「全改、無 emoji」後一次到位實作。Issue A(退還訂金重複按鈕)+ Issue B(藍新文案精準化)併入 Phase E/F 一起完成。
統一排序原則
正向 → 中性 → 破壞性 · 由上而下:
- 主動作 (Primary) — 推進 lifecycle 的「下一步」(綠色,加粗)
- 輔助 / 等待動作 (Secondary) — 中性、不直接拒絕也不立即推進(橘/藍)
- 負向 / 破壞動作 (Destructive) — 拒絕、取消、退款,放最下面(紅色),前面加 Divider 視覺隔離
主動作(綠)
輔助查看(藍)
挽留客人(紫)
柔性負向(橘)
破壞性(紅)
UI 不用任何 emoji — 全部改用 SF Symbols(Apple 系統內建向量 icon)。按鈕文案描述「會發生什麼事」,不只是動詞。
1. pending 待確認 — 老闆截圖中的「圖二」
客人剛送出訂位、老闆還沒同意。實際上是需訂金的案例(豆豆 8 位、訂金 NT$1,600)。
BEFORE
SF確認訂位（需訂金）
SF拒絕訂位
SF取消訂位
三個按鈕語意接近、視覺權重相同。沒分組,「拒絕」跟「取消」在 pending 階段語意重複(都讓訂位失效)。
→
SHIPPED
checkmark
.circle.fill確認訂位（需訂金）
hand
.raised.fill拒絕訂位
xmark
.bin取消訂位
正向動作獨立群組頂部 + 加粗綠色 + 淡綠 background。Divider 隔開後是兩個 destructive。
2. confirmed 已確認
BEFORE
SF標記到達
SF取消訂位
SF標記未到
SF客人申請取消
「取消」插在「到達」跟「未到」中間,順序錯亂。「客人申請取消」根本不該是 boss button(那是客人端 action)。
→
SHIPPED
person
.fill.checkmark標記到達
clock.badge
.exclamationmark標記未到
xmark
.bin取消訂位
時序排:正常 → 過時還沒來 → 主動取消。nextStates 中拿掉 .pendingCancellation(Phase B)。
3. arrived 已到達
→
SHIPPED
chair
.lounge.fill標記入座
xmark
.bin取消訂位
加 Divider 隔離,SF Symbol 換成更貼切的 chair.lounge.fill。
4. pendingCancellation 取消待確認 — 新流程的核心
客人申請取消,老闆要決定:同意退錢 / 同意不退錢 / 拒絕取消。
BEFORE
SF同意取消並退款
SF同意取消不退款
SF拒絕取消(挽留客人)
紅色的「同意並退款」其實是最常見、最該按的動作,反而被當作 destructive 染紅;「拒絕取消」染藍像 primary 但其實是少數情境。
→
SHIPPED
checkmark
.circle.fill同意取消並退款
scalemass
.fill同意取消但不退款
bubble.left
.and.bubble
.right.fill拒絕取消(挽留客人)
主動作改綠色(80% case 就是同意+退錢)。挽留改紫色(主動聯絡客人)。Divider 把「真的取消」vs「挽留」物理隔開。
5. 修改訂位 (modificationSqueezeSection)
5a. 時間變更待確認
→
SHIPPED
checkmark
.circle.fill確認時間修改
xmark
.circle拒絕時間修改
5b. 客人請求手動安排
→
SHIPPED
tablecells
.badge
.ellipsis幫客人手動安排位子
xmark
.circle拒絕並說明理由
5c. 人數變更待確認
SHIPPED
calendar
.badge
.checkmark查看當天時段並核准修改
person.2
.wave.2詢問客人擠一擠
這節原本就只有正向 + 輔助,沒有 destructive 所以不需 Divider。順序維持(綠 → 橘)。
6. Phase E — 移除「退還訂金」重複按鈕 (Issue A)
BEFORE
[cancellationPendingSection - 三按鈕]
SF同意取消並退款
SF同意取消不退款
SF拒絕取消(挽留客人)
[操作 section]
SF退還訂金
「退還訂金」跟「同意取消並退款」是同一個動作的兩個入口 — 老闆截圖反映「為什麼有兩顆?」
→
SHIPPED
[cancellationPendingSection - 三按鈕,重排]
checkmark
.circle.fill同意取消並退款
scalemass
.fill同意取消但不退款
bubble.left
.and.bubble
.right.fill拒絕取消(挽留客人)
取消待確認狀態下「操作」section 整段隱藏(actionsSection 早 return EmptyView)。退還訂金按鈕完全砍掉,沒有重複。
7. Phase F — 「退款待處理」section 文案 (Issue B)
老闆原話:「沒變成已退款是因為沒收到藍新通知嗎？如果是這樣的話是否該寫得更清楚呢？(已向藍新金流申請退款待藍新金流完成刷退動作後會另行通知)」
| 狀態 | UI 文案 | 按鈕 | 視覺 |
|---|
newebpayPending
(取消後 < 24h) |
「已向藍新金流申請退款。藍新完成刷退後系統會自動更新狀態並通知您 — 實際入帳可能需 1-5 個工作天。」 |
不顯示按鈕(避免 boss 在 cron 還在跑時誤按蓋掉真實狀態) |
藍色 hourglass icon + 「藍新退款處理中」(柔性,非紅警示) |
newebpayStuck
(取消後 > 24h 還沒退) |
「已超過 24 小時但藍新尚未完成退款。請至藍新後台確認狀態,或在客人實際收到款項後按下方按鈕手動標記完成。」 |
顯示「已手動退款完成」按鈕(保險) |
紅色 warning + 「退款待處理」 |
manualPending
(銀行匯款) |
「請手動匯款退還 NT$X 至客人帳戶,退款完成後按下方按鈕標記。」 |
顯示「已手動退款完成」按鈕 |
紅色 warning + 「退款待處理」 |
關鍵差異(對老闆 dogfood 體驗的影響):
- newebpay path 預設「藍新處理中」藍色提示(非紅警示),老闆不會以為系統壞了
- 「已手動退款完成」按鈕在 newebpay normal flow 不出現 — 避免老闆誤按蓋掉 cron 結果
- 超過 24 小時才升級為紅警示 + 出按鈕當保險(防 cron 完全 stuck 的 edge case)
實作 commit 對照
| Phase | 內容 | 檔案 |
|---|
| A | actionsSection 排序 + divider + SF Symbols + 顏色語意 | POSReservationListView.swift |
| B | nextStates(.confirmed) 拿掉 .pendingCancellation | Reservation.swift |
| C | cancellationPendingSection 三按鈕 reorder + 色彩翻轉(紅→綠)+ 紫色挽留 | POSReservationListView.swift |
| D | 時間修改 / 手動安排 加 Divider | POSReservationListView.swift |
| E | actionsSection 退還訂金按鈕完全移除(pendingCancellation 整段隱藏) | POSReservationListView.swift |
| F | manualRefundSection refundUIState enum + 動態文案 + button gate | POSReservationListView.swift |
全部 commit pending — push 完後老闆下輪 dogfood 應該看到全部 UI 變化。
ChefsMate Spec · 2026-05-18 dogfood B3 session #9 · 無 emoji 原則