Explore a standalone Playground Workbench mockup#3658
Draft
adamziel wants to merge 11 commits into
Draft
Conversation
1dbbcfb to
7a646e4
Compare
a2a14b7 to
73842c7
Compare
Collaborator
Author
|
Uploaded a new no-sidebar Workbench direction responding to the sidebar/button-sprawl critique. Commit: 604b6a3 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What it does
Replaces the prior Workbench-centered mockup with a standalone browser/tools model for Playground under
packages/playground/website/design-explorations/. It does not change the production Playground app.Open it directly:
Useful states are
runtime,files,current,share, andcommand.Rationale
The direction keeps the parts users like: Playground stays full-page, the address bar remains central, and Playground UI stays outside the WordPress canvas. The UI now uses a much simpler WordPress/Gutenberg-like system instead of a decorative mockup language: white surfaces, WordPress grays, blue only for primary actions, and amber only for recovery state. Borders are used deliberately for structure—runtime fields, tool categories, and the long Playgrounds table—instead of being removed entirely.
The broader feature surface is no longer treated as “the command palette will solve it.” The Tools entry now promotes five common tasks—Runtime, Files, Import, Your Playgrounds, and Save/share—and demotes less frequent tools into short chips. Search is present, but secondary. This keeps the feature surface discoverable without a wall of similar actions.
The current-site card now clearly opens Your Playgrounds. That panel is designed for a realistic 30-item library with filtering, Saved/Recovery/Local tabs, metadata columns, a scrollable list, and quick create/import actions.
Runtime and save/recovery state remain visible before any click. Clicking Environment opens a focused sheet with the two primary operations:
Save this PlaygroundandChange runtime. Files still opens as a bottom recovery drawer with usable editor width.Implementation
The mockup is static HTML/CSS/JS so it can be reviewed without wiring unfinished UX into React components.
This replaces the old 100-iteration scorecard with a lightweight browser/environment validator:
The validator writes screenshots and a manifest to
.context/workbench-browser-environment-checks/and checks address visibility, Environment visibility, WordPress canvas ownership, expected labels/actions, bounded transient surfaces, intentional structural-border budgets, Playground-vs-WordPress separation, and Files editor readability.Testing instructions
Latest local checks:
Results: 24 screenshots across 6 states and 4 desktop breakpoints, 0 failures. I also checked the Playgrounds library and Tools browser in Chrome at 1440×900; the address bar remains visible and the console is clean.