Conversation
|
@terryzfeng UI looks good and Functionality wise it works, but I have a concern about sharing external files and what we should do in this case. Ideally, if the user wants to share their whole project, the data files would be included for free - but this isn't possible in most cases since the data files would be to big to be encoded into fit inside a URL. The current workaround, fetching the data files from a URL, works but currently only one link can be provided. What if the project has two or more data files that the user wants to share? We could let the user just keep adding external links, but then there will probably be a point where the URL gets too long if so. Also, if you want to share a data file, you have to have an accessible link where it's hosted at. It works though but not sure if it should be included if there might be a better way to share full projects. One proposal is to save projects as a .webck file or similar that contains all the metadata for the project. This does defeat the purpose of having a shareable link but the file persists on your drive (in case you forget the link) and you don't have to worry about hosting data files anywhere (you'd have to deal with files in both cases). I think this would be better not just for sharing, but also for saving webchuck-ide projects in general. For the future when we have the live-coding mode, I think saving your live-coding setup to a .webck file instead of a link would be more ideal. Any thoughts? |
|
@Oran2009 Yeah I think this is a long-standing issue with WebChucK IDE because there is no backend server to save files/projects. Technically, the URL feature has always been there, but it's just been a hidden feature used, for example, to share assignments to students, not officially exposed to the end user. If you did want to save your project, you can just "Export to ChucK" which just gives you all the ProjectSystem files as a .zip, then you can upload that to a future session, essentially "persisting" your project. This would be the same as your .webck idea. There has been sorta two philosophies of the IDE, one being a quick online interpreter + runtime, and the other being an online shared project repository (e.g. Google Drive/Docs); we've kind of just leaned towards the former historically. Just the most straightforward, cost-efficient, and simple way to do things. It has its project limitations, but because many users (not all) are developers, the IDE is just a quick middleman alongside other dev tooling. "Share" has been used mostly to share snippets of code, sometimes quick debugging things here and there. And perhaps that's how most people use IDE? But that could change if we're improving the IDE and want it to be a more integral part of how users create their own ChucK projects (e.g., creating larger projects directly in the browser). Depending on user needs, it's a significant development effort, though not impossible :) Is there any front that you feel strongly about, especially as we embark towards WebChuGL and browser-based graphics projects? Sharing a project could mean sharing a link to the IDE, but at the same time, could be more of a "Export" connotation, e.g. to a polished standalone project (like GGRMA, to embed an iframe, etc.). If we want to hide the URL input to avoid confusion, or keep it for power users, I'm ok with either! === Also, a 3rd philosophy (aside from Electron lol) that we considered in 2023-2024...: https://vscode.dev |
|
@terryzfeng It seems there's two things to be discussed. First, the current state of WebChucK IDE regarding general use and project persistence. It seems the current position of the IDE is as a prototyping stage in which exporting to run natively is the expected end result. This can be seen with the existence and/or wording of the Export feature rather than being a Save feature. Similarly, the Share feature extends this: it allows for the quick sharing of code via a URL, and even that is not as persistent -- what happens if you lose/forget the URL? If we say that the majority of users are developers, then I can see at least one advantage of using WebChucK IDE vs. any other non-browser-based IDE. This advantage is that the user would not need to install ChucK on their system. However, if our expectation is that the users will eventually export to run natively, this advantage is lost -- they will eventually have to install ChucK on their system. Since the IDE is already positioned as and looks to be an IDE, users (assuming primarily devs) will inherently set expectations on what the IDE should do. Perhaps they'll expect some kind of Save feature or some other project persistence, since this is standard to any other IDE. We could try to curb these expectations, but I think we've already gone too far. I could say more but I'm also not sure what to do, or if I still agree with what I've stated above. Moving on to the more relevant topic: what to do for this PR lol. I think my reaction that prompted my initial comment was: "why can I only specify one external file? What if I have two .wav files I want to share? Why do I have to host it and input a URL?" It just seemed like there could be a more convenient way for sharing projects. I think I'm leaning towards hiding the URL input for now as we discuss the above. |
|
@Oran2009 Update: Remove URL field for external files. Can chat more IDE at CKC. |
2 participants
New Share UI
What's New
Tested
a11yLet me know if you see anything that can be improved!