M3E Canvas: Sketch Material 3 Expressive Screens and Export a Coding Prompt

The gap M3E Canvas fills between a sketch and a prompt

Most design tools stop at the picture. Most AI coding tools start at the prompt. The handoff between them is usually a screenshot and a paragraph of prose the model has to guess its way through. M3E Canvas targets that handoff directly: you place Material 3 Expressive parts on a canvas, wire screens together, and the tool writes the brief for you in Japanese, English, Chinese or Korean. The README frames the workflow as sketch, link, tap through, copy a prompt. The intended user is someone who already has an AI coding tool open in another window and wants the layout decided before generation starts. It is not a Figma replacement and does not claim to be. The parts list is opinionated: buttons, icon buttons, FABs, split buttons, FAB menus, chips, app bars, navigation bars, floating toolbars, tabs, search bars, cards, lists, dialogs, snackbars, text fields, dropdowns, switches, checkboxes, radio buttons, sliders, text, images, camera and map placeholders, badges, boxes and dividers. That is a component palette, not a vector editor. If your screen needs a custom illustration or a chart, this is the wrong tool, and the README never suggests otherwise. The output side is equally narrow: a prompt, or a PNG of a screen. There is no code generation inside the app, no design token export, and no handoff file format beyond the prompt text itself.

How the canvas, magnetic connections and prompt generation work

The architecture is visible in the repository layout: a Next.js app under app/, components/ and lib/, with no server-side data store. The README states the backend is none and everything is saved in localStorage. That single fact explains most of the tool's behaviour. Designs are client-side objects; the prompt is a serialization of those objects into natural language; the optional AI helper sends requests straight from the browser to OpenAI, Claude, Gemini or DeepSeek with a key the user supplies, and the README says the key stays in your browser with no server in between. Two mechanisms change what the prompt can express. Magnetic connections: bring two buttons or list items close and they fuse into a connected group, with corners softening as they meet, and the prompt describes the group. Layers and groups: the prompt describes overlaps and side-by-side rows explicitly so the generated layout keeps them. Screen sizing is also encoded into the output. A screen switches between a 412x892 phone and a 1280x800 desktop from its label, bars stretch, the navigation bar becomes a rail, and same-named screens are written into the prompt as one screen at two widths. That is the most interesting design decision in the project: responsive intent is captured at sketch time rather than described in prose. Navigation is captured the same way. Any tappable part, app bar icon or navigation bar destination can carry a target screen or a back action plus a transition (slide from any of the four sides, fade, expand or none), and a screen can open another on a swipe. The preview lets you tap through the flow, and back plays the transition in reverse. The loading indicators are ported from material-components-android according to the README, which is a concrete provenance claim rather than a vague fidelity claim.

Installing M3E Canvas and producing your first prompt

There are two ways in. The README points to a hosted demo at lnkiai.github.io/m3e-canvas, which needs no install at all. For a local copy, package.json defines the scripts. Node is pinned by the engines field to ^22.12.0, ^24.0.0 or >=26.0.0, so check your version before starting. Clone the repository, install dependencies, then run the dev server.

Building and serving the static output

The build script is next build, and the start script is unusual: it does not run a Next.js server, it runs npx serve out. That tells you the app is exported as static files into an out/ directory and served by a plain static file server. If you deploy it yourself, you are deploying a static bundle, not a Node process. The package also exposes typecheck and test scripts, which is a reasonable signal that the maintainers expect contributors to run both before opening a pull request.

Where M3E Canvas breaks down: localStorage, phones and the AI helper

The no-backend design is the project's biggest constraint, not just its selling point. Everything is saved in localStorage, which means clearing site data, switching browsers or switching devices loses the design. There is no account, no cloud sync and no server-side backup, so a shared link is the only way to move a design between people, and the README labels share links and AI drafts as beta. The phone experience is deliberately reduced. On a phone you get one fixed screen and a buttons-only editor: tap the plus to add a button, tap a button to move it, and edit its text, icon and style in a bottom sheet. The README states plainly that the full multi-screen editor is for desktop browsers. If your team reviews designs on tablets or phones, that is a real limitation. The optional AI helper is bring-your-own-key, and while the README says the key stays in the browser and the request goes straight to the provider, that is a claim about request routing you should confirm against your own security requirements before pasting a production key into any browser tool. Finally, the prompt is natural language. Its quality depends on the target model, and nothing in the repository guarantees a generated app will match the sketch pixel for pixel.

M3E Canvas compared with a general design tool plus a manual prompt

The obvious alternative is sketching in a general-purpose design tool such as Figma and writing the prompt yourself. The difference in approach is where the structure lives. In a general design tool, the layout is a set of absolute positions and styles that a model has to infer from an image or from your prose. In M3E Canvas, the layout is a constrained set of Material 3 Expressive parts with explicit relationships (connected groups, overlaps, side-by-side rows, named screens at two widths) that the tool serializes into sentences. You trade drawing freedom for machine-readable structure. A second alternative is going straight to an AI coding tool with a text description and no sketch at all. That is faster for a single screen and worse for anything with navigation, because the transitions and screen graph have to be described in words anyway. M3E Canvas exists precisely to move that description out of your head and into a canvas you can tap through. The cost is the palette: you cannot draw an arbitrary shape, so anything outside the listed parts has to be approximated or handled after generation.

Licence, maintenance and upgrade cost

The project is MIT licensed, with a NOTICE file at the top level alongside LICENSE, which is worth reading if you redistribute the app rather than just use it. MIT is permissive: you can use, modify and ship it, provided the copyright notice and permission notice are kept. That is a description of the licence text, not legal advice; check it against your own distribution model. On maintenance, the last push to the default branch was on 2026-09-16, so the repository is current rather than dormant. The dependency set is small and modern: Next.js 16.3.4, React 19.2.8, motion 13.1.1, html-to-image 1.11.13, with Tailwind 4 and TypeScript 7 on the dev side. That small surface keeps upgrade cost low, but it also means the project tracks fast-moving majors. The engines field pins Node to ^22.12.0, ^24.0.0 or >=26.0.0, so a Node upgrade on your machine can break the dev server before the app code does. There are no retrieved releases, so versioning is effectively the 0.1.0 in package.json and the commit history.

Editorial conclusion

Adopt M3E Canvas if you already drive an AI coding tool such as Claude Code, Codex, Gemini CLI or Cursor and you want the layout decided before the prompt is written, on Android or the web, with a phone in the loop. Skip it if you need collaborative editing, a hosted backend, or a full multi-screen editor on a phone, because the README states the full editor is for desktop browsers and everything lives in localStorage. Before committing, verify three things yourself: that the prompt output in your target language reads the way your coding tool expects, that localStorage persistence survives the browser and device you actually use, and that the optional AI helper's provider key handling matches your own policy.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. lnkiai/m3e-canvas on GitHub
4. Project website
5. README