M3E Canvas and the Problem of Lost Intent
M3E Canvas is a browser editor for sketching Material 3 Expressive screens, linking them, trying their interactions, and turning the result into a prompt for an AI coding tool. The important question is not whether it can draw a convincing screen. It is whether a design can carry enough intent across the distance between a person arranging a layout and a tool expected to build a working application. That question gives this series its focus: how M3E Canvas moves meaning from visual composition to structured data, then uses that structure for both an interactive preview and an editable implementation brief. The practical payoff is a way to judge what a design handoff actually says, what it leaves implicit, and where human review remains necessary.
The gap between a screen and a buildable idea
A screenshot is useful because it freezes appearance. It can show that a title sits above a list, that a button uses a particular color, or that a card has an image. But appearance is only one layer of an application. A screenshot does not, by itself, say which parts are grouped, which item is in front of another, what happens when a person taps a row, which screen opens next, whether a control starts on or off, or whether the design is intended for a phone, a desktop browser, or a tablet. It also cannot distinguish a deliberate overlap from an accidental collision in the image.
That missing information is where many design-to-code handoffs become vague. The receiving developer or coding model has to make guesses. Some guesses are harmless: a small difference in spacing can be adjusted to fit real content. Others change the product: a “Save” button that does nothing, a navigation item with no destination, or a desktop layout that merely scales a phone screen can turn a visual match into a poor application. The problem is therefore not that pixels are unimportant. It is that pixels are an incomplete representation of the decisions that make a screen usable.
M3E Canvas addresses this gap by making the design a document rather than a picture. Its product description names a browser editor, a tap-through preview, and prompt output as parts of one workflow. The repository also describes the application as a static site with no backend and browser-local persistence. Those facts matter together. The project is not presenting a hosted design database that quietly stores a canonical specification; it is giving the author a portable artifact that can be edited, previewed, saved, and handed onward.
The Material 3 Expressive setting supplies a visual vocabulary: buttons, navigation bars, cards, lists, inputs, progress indicators, and other components are rendered with a coordinated system of color, shape, type, and motion. But Material 3 Expressive is not the primary subject here. M3E Canvas is the system that decides how a person can arrange those components, connect them to screens, record their states, and express the result for another tool. Its value lies in the relationship between a design language and a transportable description of a design.
The diagram is intentionally not a straight arrow from screenshot to code. The same design document feeds both the preview and the prompt. The author can inspect the behavior before asking a coding tool to implement it, and can return to the canvas when the preview or prompt exposes a missing decision. That loop is the central idea to carry forward: a good handoff is not just a richer export format; it is a place where intent can be checked before it is translated again.
What M3E Canvas carries across the boundary
The document behind the canvas has several levels. A frame represents a named screen and can carry its dimensions, background, purpose, body placement, and swipe destinations. Groups hold individual parts or connected runs. Items carry the visible choices that a picture would show—labels, icons, variants, sizes, and colors—but they can also carry selected state, toggle behavior, notes, and actions to other screens. The document can therefore say not only “there is a button here,” but also “this is the action that opens the next screen” or “this control begins in this state.”
This structure also gives the editor a common object to share between its subsystems. Spatial operations can move a group without losing the identity of its members. The preview can look up an action by the item or by a particular navigation slot. The prompt generator can describe a connected row, a layered card, or a screen transition without reading a bitmap. A JSON document is a modest technical choice, but it creates a strong architectural boundary: the canvas, preview, file import, share link, and prompt output can all work from the same explicit representation.
That representation does not make every meaning explicit automatically. It has fields for notes and screen descriptions because geometry cannot explain everything. A designer may know that a floating action button opens a new-record form, while its position and icon only suggest that possibility. M3E Canvas gives the author a place to state the behavior. The distinction is important: the system can preserve an authored sentence much more reliably than it can infer an unspoken product rule from visual style.
The document is also more portable than an in-memory editor state. The project can be saved as JSON and opened again after structural checks. Share links carry a sanitized representation in the URL fragment, rather than depending on a server to look up a design. Local image data and rewrite history are excluded from that shareable copy, while an explicitly public image URL can remain. This makes the artifact self-contained in one sense, but it also makes the trade-off visible: a link can become long, browser storage has limits, and a browser-local document is not the same thing as a collaborative service with access control and revision history.
The same principle applies to the optional AI features. The helper can ask a model to write a behavior note or a screen description, but the result is returned as bounded text and kept undoable. A whole-design draft must come back as a document that passes the editor's project-shape checks. The model is an assistant around the document, not an invisible replacement for it. The author still decides whether a suggested behavior is correct, and the editor keeps a prior design available when a new draft arrives.
This is why “design intent” should not be treated as a vague synonym for visual taste. In M3E Canvas, intent has several concrete carriers: a screen name, a group order, a destination, a selected state, a theme role, a note, or a relationship between two parts. Some are explicit fields; some are preserved through grouping and ordering; some are reconstructed later from geometry. The strength of the pipeline depends on knowing which kind of carrier is doing the work.
A useful handoff is still a handoff
M3E Canvas can implement a great deal inside the editor: it can arrange Material 3 Expressive parts, preview authored navigation, let the author choose a platform, and generate a structured prompt in Japanese, English, Chinese, or Korean. It does not, however, become the application described by the sketch. The prompt's own guidance calls the layout a rough sketch rather than a finished specification. It asks a downstream coding tool to supply the normal product features, real data persistence, input validation, and production implementation choices that the sketch does not show.
That boundary is a strength when it is understood. A small canvas should not need to contain every database schema, error policy, permission flow, or domain rule before it can communicate a product idea. The author can concentrate on the screens and interactions that define the experience, while the next stage handles engineering that cannot be settled by a sketch alone. But the boundary becomes a weakness if the generated brief is mistaken for a guarantee. A prompt can request a complete, usable app; it cannot prove that the receiving model chose the right domain behavior or that the resulting code works on a real device.
The repository supports claims about the mechanisms it contains. It shows how the document is shaped, how preview actions are authored, and how the prompt is assembled. It does not provide an independent benchmark of coding-tool output, a user study proving time savings, or a production report establishing broad browser compatibility and accessibility. Those unknowns are not defects that can be filled with enthusiasm. They define the questions a responsible user must ask after the handoff.
A sensible reading of the project is therefore neither “a screenshot generator” nor “an automatic app builder.” It is a controlled translation layer. The author supplies decisions that matter; editor rules regularize common spatial operations; the preview exposes the flow those decisions create; and the prompt turns the resulting structure into language that another implementation system can use. At each step, some information is preserved, some is transformed, and some remains outside the artifact's knowledge.
The next question follows directly from that architecture. If the design is a document, what exactly does it store, and how do screens, parts, groups, states, layers, and actions relate? Answering that question will make the later editing rules easier to understand, because the magnet and Tidy are not magic applied to an image. They are operations on a model whose structure determines what can survive the journey from canvas to code.