Web app behaviour closer to a code playground

[pierremtb]

This ticket will serve as a meta-issue to outline a path towards a more sensible scope for the web app and url.zoo.dev links.

Context

There currently isn't a clear line drawn between what the web version of Zoo Design Studio should accomplish for us and for our users, versus the more complete and more capable desktop version. A Slack conversation started about whether or not url.zoo.dev links should overwrite the current buffer in the web app, or if they should use the new temporary buffer instead. This brought up in question the current implementation for links with the model contained in the URL and the related known issues eg. #6200.

The current implementation of the web app for code storage uses the browser localStorage, which means we're able to keep some user data across multiple sessions, but only on the same machine and on the browser and browser profile, and we don't support multiple instances at the same time. This has led to confusion even among us, and the running assumption is that nobody is using the web app for anything meaningful today.

Path forward

The conversation landed on a cross-team effort to make the divide clearer between the web app and the desktop app, but more importantly make the user experience more aligned with typical SaaS product expectations.

The end goal would be as such:

1. The web app acts more like a fully-featured code playground, meant as a place to experiment with our technology on relatively small and contained test models. Essentially JSFiddle but KCL. This includes Text-to-CAD, manual modeling, and exports, but not local file tracking with Git or other OS integrations as those would understandably be limited to the desktop app.
2. Each web app session is tied to a "fiddle", public by default and accessible via a link: new sessions are attributed a new ID, while existing "fiddles" are opened by the equivalent of our url.zoo.dev links today. This means users are able to open their "fiddles" on multiple machines and browsers and expect to continue their testing, as well as sharing with others.
3. The KCL model code is automatically saved to the "fiddle" database instead of localStorage. This means url.zoo.dev links aren't a frozen copy anymore, but pointers to a piece of KCL in a database that may change over time
4. Opening a "fiddle" in the desktop app creates a local copy of the KCL code, that the user can make changes to just like any other local project, but has the option to update the original "fiddle" at will
5. The Share Link button in the app continues to generate a link with the KCL code as payload, but the code is saved in a Zoo db instead of in the URL, creating a new "fiddle".

Stretch goals:

1. The "fiddles" support multiple files in the web as well
2. A limited subset of features is accessible without signing in, eg. read-only orbiting of the model scene. This likely requires new forms of caching so we can keep the toll on infra to a minimum. But this is assumed to have a huge pull on frictionless sharing and the type of "Check out what the AI created for me!" virality we could be looking for.

Note: @KittyCAD/frontend team, this is a first draft, feel free to edit!

[pierremtb]

For reference this is the Codepen experience, which I find to be spot on:

• You sign up and start a pen
• Everything you do isn't saved (refresh kills it) until you hit Save. At which point you get an ID in the URL
• Subsequent saves preserve the URL, that can be opened by anyone
• There's a toggle to make it private, only on Pro plans
• There's an auto save toggle

https://codepen.io/Pierre-Jacquier/pen/azOwwLQ

[Irev-Dev]

Eventually the web app should be parity with the desktop app, but would require a cloud FS or similar, which is probably not worth our attention atm, so Id like the idea of fiddle and making the clear to the user.

Though recently I have been thinking we should support multiple files in the web app (but probably not nested dirs, or multiple projects). Because if we have multiple files then the only things that the web app doesn't have is 1) projects, and 2) import meshes etc.

But not having multi-file is hurting showing off imports and therefore assemblies, and by extension hurting TTC since it's going to want to create multiple files depending on the prompt.

I'm just saying this because you mentioned multiple files above and I second it for sure.

[nadr0]

I think we can do multiple files in the current state of the web application to enable more workflows. No nested dirs, everything is in the same folders.

I think the technical idea of a fiddle makes sense. I honestly hate every single fiddle/code pen UI I've ever used in my life. I honestly do not think anyone who made fiddles has ever used an IDE.

I don't know how someone when from an IDE experience to 4 boxes that are awful to view and click into and write real code.

[pierremtb]

Linking post conversion: this was my response in the og issue: #7607 (comment)

[pierremtb]

@nadr0 I can definitely relate to that second part of your message. Not suggesting the UI changes for us as a "fiddle," simply the way we store and access files (aka moving from link store to file store)

[jacebrowning]

We might consider an interface like Web Intents to model the possible interactions between: Website ("Embedded" TTC), TTC Generator, ZDS Web, and ZDS Desktop. Even without following the formal specification, documenting all query parameters on a single page could also be helpful, like these examples:

• https://developers.facebook.com/docs/threads/threads-web-intents/
• https://developer.x.com/en/docs/x-for-websites/web-intents/overview