Doodle field, part 2: maybe no images at all

Following up on the earlier doodle field post — we’d been assuming the drawn answer would end up as a rasterized image (a PNG), submitted and handled the same way an uploaded file is: emailed as an attachment, never stored.

There’s a simpler option we hadn’t considered: capture the drawing as SVG path data instead of pixels. A doodle is just a sequence of points as someone drags their finger or mouse — that’s naturally vector data, not a bitmap. Serialize the strokes into an SVG string as they’re drawn, and skip rasterizing anything at all.

That turns out to sidestep most of what made this feature look complicated:

• It’s tiny. A few kilobytes of path data instead of a rasterized image.
• It doesn’t need to be treated as a file at all. It’s just text, so it can sit in a submission’s answers exactly like any other field — no upload validation, no email-attachment handling, no “never stored” exception carved out for it.
• The background image (the floor plan, the diagram) stays a plain link, referenced by URL — the same approach we just shipped for the image field. Nothing to embed, nothing to store.

The one real tradeoff: showing the doodle in a notification email. Inline SVG doesn’t render reliably across every email client. The workaround is embedding it as a base64 image — data:image/svg+xml;base64,... — which Gmail and most modern clients handle fine, just not with the universal guarantee a plain image attachment would have.

Still just a design on paper — no commitment to build it yet, per the last post. But it’s a noticeably smaller feature than we first sketched out, which changes how we’d weigh building it.