M3E Canvas: Architectural Review & Getting-Started Guide

1. What it is

M3E Canvas is a browser-only design tool. You sketch phone app screens out of real Material 3 Expressive (M3E) components, wire them together with navigation, and then collapse the whole design (or just one screen) into a natural-language brief that an AI coding agent can build from.

It doesn't generate code itself. The output is prose, not a component tree or a JSON schema.

It's a very young project. It appeared on GitHub on September 2, 2026 and picked up several hundred stars in its first two days.

Star and fork counts on a repo this new move fast enough that any number printed here will be stale soon, so check the repo directly rather than trust a snapshot.

2. Architecture

Stack

Next.js 16 (React 19.2, TypeScript), Tailwind CSS 4 for styling, motion (the Framer Motion successor library) for the canvas and preview animations, html-to-image for PNG export, and Vitest for tests. Node ^22.12 / ^24 / ≥26 is required.

No backend, anywhere

The app builds as a static Next.js export (next build → ./out), with no server component and no API route in sight. A GitHub Actions workflow (.github/workflows/deploy.yml) rebuilds and republishes out/ to GitHub Pages on every push to main.

Since a GitHub Pages project site is served from a sub-path, the build needs NEXT_PUBLIC_BASE_PATH set; the workflow handles that automatically, but it's the thing to remember if you fork the repo and point CI somewhere else.

Persistence is entirely client-side

Every screen, part, note and theme setting lives in the browser's localStorage. There's no account system and nothing to sign into.

That's also the app's single biggest structural risk: clear your site data and the design is gone. Your only real backup is whatever you deliberately export: a copied prompt or a saved PNG.

Repo layout

Fairly conventional Next.js App Router shape: app/ for routes, components/ for the parts panel, canvas, theme panel and preview, lib/ presumably holding the state model, prompt-generation logic and the M3 color-role math, and public/ for static assets.

There are also root-level AGENTS.md and CLAUDE.md files instructing AI coding agents that contribute to the codebase, which fits neatly given what the tool itself is for.

Design-system fidelity

Rather than drawing lookalike buttons and chips, the shape-morphing loading indicator is ported from Google's own material-components-android (via an intermediate port, Aler1x/m3-loading-indicator) and credited under Apache-2.0 in the repo's NOTICE file. Icons come from Material Symbols.

That attention to sourcing real component behavior, not just real-looking components, is what backs up the claim that its "magnetic connections" (two buttons fusing into a pill group with softened facing corners when dragged close) are genuine M3 Expressive behavior and not just a drawing of it.

The core bet: prompt as artifact

The whole design treats the prompt as the deliverable, not code. That has real trade-offs.

In its favor: a plain-language brief isn't tied to any framework or model, and it's cheap to regenerate since you edit the canvas instead of generated files. It can also spell out layout that's genuinely ambiguous (which two elements sit side by side versus overlapping) more reliably than a lot of coding agents can infer from a screenshot alone.

Against it: nothing here compiles or type-checks, so the tool can't catch its own ambiguity. Whether "floating toolbar above the navigation bar" gets built as two separate elements or one collapsed one is still entirely up to whichever agent reads the brief.

Testing

Vitest is in the devDependencies. For a two-week-old project, treat any test coverage as a starting point, not a maturity signal.

Implementation target

The README points at a sibling project, matraic/m3e (Material 3 Expressive as Lit web components, MIT-licensed, with React bindings and an icon package), calling it "a good home for the screens you sketch here."

So M3E Canvas plans the screen but doesn't presume to build it, and it names a specific place downstream where the parts you sketched actually exist as code.

3. Getting started

Fastest path: no install

Open the hosted app and start dragging parts onto a phone-sized canvas. Nothing to configure, nothing to sign into.

Running it locally

git clone https://github.com/lnkiai/m3e-canvas.git
cd m3e-canvas
npm install
npm run dev        # http://localhost:3000

Other scripts worth knowing:

npm run build       # static export to ./out
npm start            # serves ./out with `npx serve`
npm run typecheck    # tsc --noEmit
npm run test         # vitest run

The basic workflow

1. Drag parts onto a screen. The parts panel covers buttons, icon buttons, FABs, split buttons, FAB menus, chips, top app bars, navigation bars, floating toolbars, tabs, search bars, cards, list items, dialogs, snackbars, text fields, switches, checkboxes, radio buttons, sliders, badges, dividers, plus plain text, images and boxes.

2. Add more screens as needed, name them, and set a background per screen.

3. Wire up navigation. Any tappable part can point at another screen or at "back," with a transition: slide from any of the four edges, fade, expand, or none. Screens can also respond to swipes, and arrows on the canvas show the resulting flow.

4. Set the theme before you export anything. The theme panel controls four axes at once: color (seven presets, or a seed color expanded into a full Material 3 role palette, with light/dark, three contrast levels, and a dynamic-color toggle), corner shape (square / rounded / full), typeface (Roboto, Roboto Flex, Roboto Serif, or system font), and motion (standard vs. expressive spring, which also drives the preview's animation feel).

   • This matters in practice: regenerate a screen's prompt with a different seed color later, and the agent you hand it to will tend to rewrite your theme file on every pass.

5. Write notes on parts as you place them. Notes carry through into the exported brief verbatim, and "this opens the filter sheet" saves the agent from guessing badly.

6. Preview it. Hit P to tap through the linked screens live before anything gets built.

7. Export one screen at a time, not the whole design at once, then paste it into whatever coding agent you're using. The repo names Claude Code, Codex, Gemini CLI and Cursor, though the output is plain text and isn't tied to any of them.

   • A twelve-screen brief handed over in one shot tends to get the broad strokes right and quietly invent the rest, so exporting screen by screen, checking each, and iterating is the more reliable loop.

   • The README documents Japanese and English as export languages, with Japanese as the default; some third-party coverage also mentions a Chinese option, which wasn't independently confirmed here.

8. You can also save any screen as a PNG if you just need a picture rather than a prompt.

Keyboard shortcuts

On a phone

The mobile build is deliberately cut down: one fixed screen, buttons only, added via a plus button and edited through a bottom sheet. Multi-screen editing, navigation links and the layers panel need a desktop browser.

4. Honest assessment

Strengths

• Real M3 Expressive component behavior, not an approximation of it, with the sourcing credited rather than silently reused.

• Navigation is treated as a first-class, testable thing (tap-through preview, arrows on canvas), which targets the actual failure mode of AI-generated UIs: ambiguous flow. That matters more than getting corner radii right.

• Zero friction: no install, no account, and the output is a portable prompt that isn't locked to one model or vendor.

• The phone mode is a genuine, reduced-scope companion, not a cramped squeeze of the desktop app.

Limitations

• localStorage-only persistence means no sync across devices and no recovery if site data gets cleared. Anything you'd be annoyed to lose needs an exported prompt or PNG as backup.

• The screen-by-screen export discipline it recommends works around a real limit of current coding agents; it's not something the tool alone can fix. A large brief will still get partially invented no matter how precisely it's written.

• It's two weeks old, so expect the API, the prompt format and the component set to keep changing, along with rough edges a longer-running project would have sanded down by now.

• The tool plans the screen but doesn't close the loop to running code itself. It hands off to a separate project (matraic/m3e) as the suggested implementation target, so getting from sketch to shipped screen is still at least two tools plus a coding agent.

Sources

• github.com/lnkiai/m3e-canvas: README, package.json, repo structure

• lnkiai.github.io/m3e-canvas: live app

• moclaw.ai/blog/what-is-m3e-canvas: third-party coverage, Sept 10, 2026

• github.com/material-components/material-components-android

• github.com/matraic/m3e