{"id":51919737,"url":"https://github.com/getdave/rsm-editor-prototype","last_synced_at":"2026-07-27T16:31:03.641Z","repository":{"id":359564187,"uuid":"1223569913","full_name":"getdave/rsm-editor-prototype","owner":"getdave","description":"WIP","archived":false,"fork":false,"pushed_at":"2026-06-08T09:31:30.000Z","size":3747,"stargazers_count":3,"open_issues_count":3,"forks_count":0,"subscribers_count":0,"default_branch":"trunk","last_synced_at":"2026-06-09T18:08:36.448Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/getdave.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":"AGENTS.md","dco":null,"cla":null}},"created_at":"2026-04-28T12:56:05.000Z","updated_at":"2026-06-09T10:46:51.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/getdave/rsm-editor-prototype","commit_stats":null,"previous_names":["getdave/rsm-editor-prototype"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/getdave/rsm-editor-prototype","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/getdave%2Frsm-editor-prototype","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/getdave%2Frsm-editor-prototype/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/getdave%2Frsm-editor-prototype/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/getdave%2Frsm-editor-prototype/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/getdave","download_url":"https://codeload.github.com/getdave/rsm-editor-prototype/tar.gz/refs/heads/trunk","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/getdave%2Frsm-editor-prototype/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":35958061,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-07-20T02:08:10.276Z","status":"online","status_checked_at":"2026-07-27T02:00:06.776Z","response_time":101,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-07-27T16:31:03.042Z","updated_at":"2026-07-27T16:31:03.629Z","avatar_url":"https://github.com/getdave.png","language":"JavaScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Create, Not Learn\n\n\u003e A prototype reimagining the WordPress Site Editor around what users want to do — not how WordPress is built.\n\n[![Watch the project video](https://img.youtube.com/vi/TdsQe9oi8mg/maxresdefault.jpg)](https://www.youtube.com/watch?v=TdsQe9oi8mg\u0026feature=youtu.be)\n\n[Watch the project video on YouTube](https://www.youtube.com/watch?v=TdsQe9oi8mg\u0026feature=youtu.be)\n\n\u003c!-- Screenshot: replace the line below with an actual screenshot once one is available --\u003e\n\u003c!-- ![Prototype screenshot showing the simplified Site Editor](./docs/screenshot.png) --\u003e\n\n---\n\n## The problem\n\nWordPress is one of the most powerful website building tools on the planet. But somewhere along the way, the Site Editor started teaching users how WordPress works rather than helping them build their website.\n\nClassic WordPress handled this well. System-level concepts — templates, reading settings, theme structure — lived in the code layer, the concern of developers and theme authors rather than website owners. For everyone else, the Customizer provided a deliberately bounded interface: site name and logo, colours and typography, menus, header and footer. Users never needed to understand how WordPress worked to use it effectively.\n\nThe Site Editor changed that. Far more capable than anything before it, it nonetheless dismantled that insulation without replacing it:\n\n- The Customizer gave way to an interface that exposes the full system model by default\n- Purpose-built interfaces like the Menus screen were replaced by block-based equivalents like the Navigation block, exposing complexity rather than hiding it\n- Developer-level concepts — templates, template parts, patterns, query loops — became primary navigation items presented directly to beginners\n\nThe problem isn't the power of the Site Editor — it's that **system-level concepts have been made first-class user concerns**. This prototype explores how to keep those concepts out of the user's way — not by limiting what the Site Editor can do, but by reimagining how it presents itself.\n\n---\n\n## What this is\n\nAn interactive prototype testing what the Site Editor could look and feel like if it were organised around what users want to do — not how WordPress is structured under the hood.\n\nRather than working inside the Gutenberg plugin codebase, this is built as a simulated editor: clickable, interactive, and designed to feel like the real thing, but running on mock data rather than a live WordPress install. That was a deliberate choice.\n\nWorking directly in Gutenberg means contending with API design, plugin architecture, code review, and merge timelines — the right constraints for production code, but the wrong ones for rapid exploration of UI concepts. Here, a new interface idea can go from thought to working prototype in hours. AI-assisted development accelerates this further. The goal is to move fast, try things, discard what doesn't work, and arrive at validated ideas worth the investment of real implementation.\n\nBecause the prototype is built using real WordPress packages — the same components, design system, and UI primitives used in Gutenberg itself — everything it demonstrates is grounded in what the real editor can actually do. There is no translation gap between what you see here and what is achievable in the real codebase.\n\n## What this is not\n\n**Not a pull request to WordPress Core.** This is a prototype for learning and discussion. The goal is validated signal, not shipped code.\n\n**Not a redesign of WordPress architecture.** Templates, template parts, patterns, and the block system stay entirely intact. This prototype tests changes to entry points, language, and what is visible by default — all within the WordPress architecture that already exists. Nothing breaks; things are reframed.\n\n**Not removing power-user features.** Progressive disclosure means complexity is available — it is just not the first thing every user encounters. Anything simplified for beginners must remain reachable for advanced users.\n\n---\n\n## Who this is for\n\nTwo primary personas, equally weighted.\n\n**The first-time beginner.** Their first website, on any platform. Has no mental model for how a site is built — no concept of templates, template parts, patterns, or blocks. Confidence is fragile: a few minutes of confusion is enough to cause abandonment. Success means reaching a believable first draft without hitting a wall.\n\n**The beginner migrator.** Has built a site before on Wix, Squarespace, or similar. Understands the basics — header, footer, pages, menus, colours, fonts — but nothing WordPress-specific. Will actively try to map familiar mental models onto the editor and be frustrated when nothing aligns.\n\n**Advanced users are a boundary condition, not a primary audience.** Developers, theme authors, and experienced WordPress users are not the target of this prototype — but they define a hard constraint. Anything simplified or hidden for beginners must remain reachable for this group. The goal is progressive disclosure, not removal.\n\n---\n\n## The journey this prototype is optimised for\n\nEvery decision — what is shown, what is hidden, what happens automatically — is grounded in research into how beginners actually build a site. That research spans public educator evidence, internal studies across Automattic's WordPress products, and direct user testing of the prototype itself.\n\n**1 — Orientation.** The user arrives and immediately needs to know: this is my site, and here is what I can do. They don't read before acting — orientation and the first action happen together.\n\n**2 — Site identity.** Before building anything, users want the site to feel like theirs. Site name and logo — nothing else. Every other setting can wait.\n\n**3 — Pages and navigation.** Users carry a single connected model: *I have pages, and some of them are in my menu.* Pages and navigation are one concern, not two separate admin surfaces. Creating a page, giving it a layout, and adding it to the menu all happen in one flow.\n\n**4 — Content editing.** Users go to the homepage first. They edit sections, adjust text and images, and make the site feel real. At no point should they need to know what a template is, or encounter the word \"pattern\" as a primary noun.\n\n**5 — Design.** Once structure and content are in place, users turn to the overall look: colour, typography, layout. Research is consistent — strategy first, aesthetics second. The current Site Editor reverses this order. This prototype corrects it.\n\n**6 — Preview and confidence.** Users want to see their site exactly as a visitor would, and trust that what they see matches what gets published. The gap between editor preview and published output is a first-class problem here, not an edge case.\n\n---\n\n## Design principles\n\nThese are the principles the editor is being designed around — derived from research, not from the prototype approach.\n\n**Progressive disclosure is the governing principle.**\nComplexity is revealed as users need it, based on the tasks they are undertaking. No novice, intermediate, or advanced modes. The editor starts simple and complexity surfaces naturally as actions require it.\n\n**System concepts should power the UI without defining it.**\nWordPress's internal architecture — templates, template parts, patterns, query loops — is powerful and must stay accessible. But these are implementation details, not user goals. They should not be the primary navigation or interaction model.\n\n**The editor is the foundation — not the onboarding.**\nUsers arrive through many routes. All of them end in the editor. If the editor requires onboarding to compensate for its complexity, every onboarding method fails. Onboarding can be added on top; it is not the fix.\n\n**Don't require blocks for site setup tasks.**\nSetting a site name, uploading a logo, creating a page, building a menu — none of these should require block manipulation. Where a simpler path exists, it should be the default.\n\n**Everything is a page.**\nUsers understand pages. They do not understand templates, template parts, or template hierarchy. Content pages (About, Contact, Services) and system pages (Home, 404, Search Results) are presented through a single surface. The underlying implementation is hidden by default.\n\n**Strategy before design.**\nStructure first — what pages exist, how they connect, what the homepage is. Design second — colours, fonts, layout. The current editor reverses this. This prototype corrects it.\n\n---\n\n## Contributing\n\n### Getting started\n\n**Prerequisites:** Node.js 18+\n\n```bash\nnpm install\nnpm run dev\n```\n\nOpen `http://localhost:5173`.\n\n```bash\n# Production build\nnpm run build \u0026\u0026 npm run preview\n```\n\n### Tech stack\n\nBuilt with React and real WordPress UI packages — the same components, design system, and primitives used in Gutenberg itself. This means everything demonstrated here is grounded in what the real editor can do, with no translation needed when ideas move to real implementation.\n\n### Project structure\n\n```\nsrc/\n├── components/\n│   ├── views/        # Main views (PagesView, EditingView, NavigationView, StylesView…)\n│   ├── navigation/   # Navigation menu editor\n│   ├── modals/       # Modal dialogs\n│   └── shared/       # Reusable utility components\n├── layouts/          # RootLayout, SplitViewLayout\n├── router/           # Route definitions\n├── hooks/            # useAppState — global state\n├── data/             # mockData.js — pages, menus, sections, site info\n└── styles/           # CSS organised by view and component\n```\n\n### Workflow\n\n**Branches:** `trunk` is the main branch. Use feature branches per change, merged via PR.\n\n**Commits:** conventional format — `feat:`, `fix:`, `refactor:`, `style:`, `docs:`\n\n**Parallel worktrees:** use git worktrees when you want multiple features or AI agents running at the same time, each with its own checkout and localhost preview.\n\nThere are two setup commands:\n\n- `npm run worktree:setup` only writes `.env.local`, assigns/reuses a stable port, and prints the preview URL.\n- `npm run workspace:setup` runs `npm ci` first, then runs `worktree:setup`. Use this for fresh already-created agent workspaces and worktrees.\n\nFor any fresh already-created agent workspace or worktree, run:\n\n```bash\nnpm run workspace:setup\nnpm run dev\n```\n\n`npm run dev` uses the port written to `.env.local`. Open the printed local preview URL in your browser.\n\nIf the workspace should inherit unmanaged values from the main checkout's `.env.local`, pass the source checkout explicitly. Replace `/path/to/main/checkout` with the absolute path to that checkout:\n\n```bash\nROOT_WORKTREE_PATH=/path/to/main/checkout npm run workspace:setup\nnpm run dev\n```\n\n```bash\nnpm run worktree:create -- feature/my-change\ncd ../rsm-prototyping-feature-my-change\nnpm run dev\n```\n\nThe worktree command creates or reuses the branch, installs dependencies with `npm ci`, writes `.env.local`, and assigns a stable local port from `5174-5973`. The main checkout conventionally stays on `5173`.\n\nThe dev preview URL stays a normal localhost URL, for example `http://localhost:5174/`. In development, the prototype shows a bottom-right icon. Click it to see the branch, port, and full preview URL.\n\nOptional explicit port:\n\n```bash\nnpm run worktree:create -- feature/my-change 5180\n```\n\nWhen you are done, stop that worktree's dev server with `Ctrl-C`, then remove the worktree:\n\n```bash\nnpm run worktree:cleanup -- feature/my-change --delete-branch\n```\n\n### Principles\n\nBefore adding something new, check it against three questions:\n\n- *Can this be reframed rather than replaced?* Work with existing WordPress concepts — templates, template parts, patterns — rather than inventing new ones.\n- *Could this ship in real WordPress?* If it requires a ground-up rebuild or breaks existing architecture, it doesn't belong here.\n- *Does it stand alone?* Changes should be independently useful, not dependent on the rest of the redesign shipping first.\n\n---\n\n## License\n\nGPL-2.0, consistent with WordPress.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgetdave%2Frsm-editor-prototype","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fgetdave%2Frsm-editor-prototype","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgetdave%2Frsm-editor-prototype/lists"}