josh/electric-cherry
1
0
Fork 0
Code Issues 18 Pull Requests Actions Packages Projects Releases Wiki Activity

Restore campaign terminology across UI and docs

Browse Source
This commit is contained in:
josh
2026-09-19 22:41:33 -04:00
parent 05024c7675
commit 68b21a83ce
19 changed files with 56 additions and 56 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/ui-ux-review.md
+10 -10
View File
@@ -8,7 +8,7 @@ Electric Cherry has a coherent visual foundation and unusually capable operation
## Scope and evidence
This review combines source inspection with a local browser walkthrough. It covers Fleet, server details and diagnostics, Scripts, Configs, Plugins, beta creation and progress, server deployments, blueprints, rollouts, keys, and Leaderboard. Existing design notes and workflow documentation informed the review.
This review combines source inspection with a local browser walkthrough. It covers Fleet, server details and diagnostics, Scripts, Configs, Plugins, beta creation and progress, server deployments, blueprints, campaigns, keys, and Leaderboard. Existing design notes and workflow documentation informed the review.
Browser exploration used an isolated database with Komodo/RCON credentials disabled. Nine top-level pages were examined at 1440×1000 and 390×844. Populated Fleet, server details, and beta scenarios used synthetic API responses. Beta setup, blueprint validation, and the browser accessibility tree were also exercised. Navigation was checked around its responsive breakpoint. Production integrations, actual restarts, and destructive actions were not executed.
@@ -37,7 +37,7 @@ P1 means address first because the issue affects trust, consequential actions, l
| 1 | Label stale player data consistently | P1 | S |
| 2 | Preserve loading-button accessible names | P1 | S |
| 3 | Put beta results and decisions above the event log | P1 | S–M |
| 4 | Preview promotion targets and link the resulting rollout | P1 | M |
| 4 | Preview promotion targets and link the resulting campaign | P1 | M |
| 5 | Make reconciliation scope and partial results explicit | P1 | M |
| 6 | Preserve keys when launch previews refresh | P1 | M |
| 7 | Explain blueprint and test-plan validation locally | P1/P2 | S–M |
@@ -59,9 +59,9 @@ Sources: [Fleet page](../src/routes/+page.svelte), lines 56, 62, 208; [ServerCar
### 2. Review the full impact of promotion — P1 · Source
“Promote” immediately sends a request. The backend expands the tested files to all currently matching scope targets and queues restarts for additional servers. The UI does not show that expansion at the moment of approval. Afterward, it ignores the returned rollout ID.
“Promote” immediately sends a request. The backend expands the tested files to all currently matching scope targets and queues restarts for additional servers. The UI does not show that expansion at the moment of approval. Afterward, it ignores the returned campaign ID.
Add a concise promotion review with exact versions, tested servers, additional eligible servers, and restart behavior. Use a final label such as **Promote to 12 servers**. Explain eligibility, file staging, and activation separately. After submission, show **Promotion created — 9 servers awaiting activation** with **View rollout**. Keep “Promoted version” distinct from “Running everywhere.”
Add a concise promotion review with exact versions, tested servers, additional eligible servers, and restart behavior. Use a final label such as **Promote to 12 servers**. Explain eligibility, file staging, and activation separately. After submission, show **Promotion created — 9 servers awaiting activation** with **View campaign**. Keep “Promoted version” distinct from “Running everywhere.”
Acceptance: an operator who tested one lobby can identify the entire affected set and follow remaining restarts without searching another section.
@@ -75,7 +75,7 @@ Separate **Reconcile selected servers** from **Reconcile entire fleet**. Show a
Acceptance: filtering or selecting one server never leaves the action scope ambiguous. An operator can explain which files will be restored or removed and when servers will restart.
Sources: [Rollouts page](../src/routes/campaigns/+page.svelte), lines 118, 124, 203, 268; [drift API](../src/routes/api/drift/+server.ts), line 28; [drift implementation](../src/lib/server/fleet/drift.ts), line 265.
Sources: [Campaigns page](../src/routes/campaigns/+page.svelte), lines 118, 124, 203, 268; [drift API](../src/routes/api/drift/+server.ts), line 28; [drift implementation](../src/lib/server/fleet/drift.ts), line 265.
### 4. Put beta outcome and next action above activity — P1 · Rendered + Source
@@ -128,11 +128,11 @@ Sources: [DestroyServerModal](../src/lib/ui/components/DestroyServerModal.svelte
Reconciliation returns per-server skipped reasons, but the UI reads aggregate changed-file counts. Errors and success messages also share a blue-toned flash container. Rollback feedback can appear in the drift card far from the row that initiated it.
Use structured completion feedback: **7 servers updated, 2 skipped**, with reasons, relevant retry actions, and a rollout link. Place feedback beside the affected task. Keep success, partial success, and failure visually and programmatically distinct.
Use structured completion feedback: **7 servers updated, 2 skipped**, with reasons, relevant retry actions, and a campaign link. Place feedback beside the affected task. Keep success, partial success, and failure visually and programmatically distinct.
Acceptance: a request that skipped every target cannot look like an uneventful successful run; the operator can find the unresolved servers immediately.
Sources: [Rollouts page](../src/routes/campaigns/+page.svelte), lines 128–138, 181–184, 299, 508; [drift implementation](../src/lib/server/fleet/drift.ts), lines 349, 371, 383–410.
Sources: [Campaigns page](../src/routes/campaigns/+page.svelte), lines 128–138, 181–184, 299, 508; [drift implementation](../src/lib/server/fleet/drift.ts), lines 349, 371, 383–410.
### 9. Explain scope changes and distinguish eligibility from installation — P1 · Source
@@ -152,7 +152,7 @@ Preserve the accessible label during loading and announce meaningful progress se
Acceptance: the same action has a stable accessible name before, during, and after execution; keyboard and touch users can identify which server failed without hovering.
Sources: [Button](../src/lib/ui/components/primitives/Button.svelte), lines 63–71, 155; [Field](../src/lib/ui/components/primitives/Field.svelte), line 25; [rollout mini-pipelines](../src/routes/campaigns/+page.svelte), line 380. These recommendations follow W3C guidance on [Name, Role, Value](https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html) and [Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html).
Sources: [Button](../src/lib/ui/components/primitives/Button.svelte), lines 63–71, 155; [Field](../src/lib/ui/components/primitives/Field.svelte), line 25; [campaign mini-pipelines](../src/routes/campaigns/+page.svelte), line 380. These recommendations follow W3C guidance on [Name, Role, Value](https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html) and [Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html).
### 11. Make server detail lead toward the likely next task — P2 · Rendered + Source
@@ -324,7 +324,7 @@ Sources: [LogPanel](../src/lib/ui/components/LogPanel.svelte); [notification sto
## Suggested layout for operational detail pages
Use the same reading order across beta, rollout, and server-deployment details:
Use the same reading order across beta, campaign, and server-deployment details:
1. **Outcome and next action:** current state, elapsed/remaining time, blocker, primary recovery or completion action.
2. **Affected servers:** progress counts and a failed/waiting-first list with links to relevant diagnostics.
@@ -337,7 +337,7 @@ This gives the existing shared components a consistent purpose without forcing e
**First pass — clarity and trust:** address stale card values, unnamed loading buttons, silent blueprint limits, beta results placement, and misleading/remote action feedback. These are bounded changes with clear reproduction cases.
**Second pass — complete action flows:** add promotion and reconciliation reviews, explicit beta timing/retry semantics, retained launch keys, beta drafts, import completion state, and links from outcomes to their rollout or recovery destination.
**Second pass — complete action flows:** add promotion and reconciliation reviews, explicit beta timing/retry semantics, retained launch keys, beta drafts, import completion state, and links from outcomes to their campaign or recovery destination.
**Third pass — scale and polish:** improve target pickers, library context restoration, mobile density, config composition, setup status, and evidence navigation. Design queued-operation cancellation separately with its backend guarantees.