#81 GUI Authoring Tool

Open
opened 2 weeks ago by hz · 10 comments
hz commented 2 weeks ago

Several people have brought up a desire to have some kind of simple GUI-based frontend for creating catsoop content, similar in spirit to edX Studio.

I think this would be a nice thing to have, but, unfortunately, I think it’s actually quite hard. This is one of the places where catsoop’s extreme focus on flexibility bites us, as it makes it difficult to think about how a GUI interacts with the source of a catsoop course.

Maybe we could get away with editing only pages whose content files don’t do any dynamic content (no <python> tags)? That would bring the scope down quite a bit while still keeping things maybe more-or-less useful?

Several people have brought up a desire to have some kind of simple GUI-based frontend for creating catsoop content, similar in spirit to [edX Studio](https://studio.edx.org/). I think this would be a nice thing to have, but, unfortunately, I think it's actually quite hard. This is one of the places where catsoop's extreme focus on flexibility bites us, as it makes it difficult to think about how a GUI interacts with the source of a catsoop course. Maybe we could get away with editing only pages whose content files don't do _any_ dynamic content (no `<python>` tags)? That would bring the scope down quite a bit while still keeping things maybe more-or-less useful?
hz added the
enhancement
label 2 weeks ago
hz added the
help wanted
label 2 weeks ago
hz added the
ui/ux
label 2 weeks ago
edemaine commented 2 weeks ago

Interesting idea. What comes to mind to me is the Github/Gitlab interface for editing text files in a repo. At its simplest level (no preview), it seems like this would work fine on Catsoop (but maybe it’s not gooey/WYSIWYG enough?). It would seem pretty powerful with preview added, which I could see doing via a round-trip to the server. Actually I would find it incredibly useful to test how a page would render before I actually commit it to the repo, which I think wouldn’t be terrible to do?

Interesting idea. What comes to mind to me is the Github/Gitlab interface for editing text files in a repo. At its simplest level (no preview), it seems like this would work fine on Catsoop (but maybe it's not gooey/WYSIWYG enough?). It would seem pretty powerful with preview added, which I could see doing via a round-trip to the server. Actually I would find it incredibly useful to test how a page would render before I actually commit it to the repo, which I think wouldn't be terrible to do?
hz commented 2 weeks ago
Owner

What comes to mind to me is the Github/Gitlab interface for editing text files in a repo. At its simplest level (no preview), it seems like this would work fine on Catsoop (but maybe it’s not gooey/WYSIWYG enough?). It would seem pretty powerful with preview added, which I could see doing via a round-trip to the server.

That’s an interesting idea I hadn’t thought of. I think the other people who had asked are probably hoping for a WYSIWYG kind of thing, but having an interface for editing the files live would be useful, too (either instead or in addition).

A “preview” that asks the server to render the current version of the source could be interesting.

Actually I would find it incredibly useful to test how a page would render before I actually commit it to the repo, which I think wouldn’t be terrible to do?

I always run a local copy of catsoop for this (instructions from 6.009 here), which I think is the best of both worlds in the sense that I get to use my preferred editor but also see how things will render without needing to “git push”.

> What comes to mind to me is the Github/Gitlab interface for editing text files in a repo. At its simplest level (no preview), it seems like this would work fine on Catsoop (but maybe it's not gooey/WYSIWYG enough?). It would seem pretty powerful with preview added, which I could see doing via a round-trip to the server. That's an interesting idea I hadn't thought of. I think the other people who had asked are probably hoping for a WYSIWYG kind of thing, but having an interface for editing the files live would be useful, too (either instead or in addition). A "preview" that asks the server to render the current version of the source could be interesting. > Actually I would find it incredibly useful to test how a page would render before I actually commit it to the repo, which I think wouldn't be terrible to do? I always run a local copy of catsoop for this ([instructions from 6.009 here](https://py.mit.edu/spring20/local_copy)), which I think is the best of both worlds in the sense that I get to use my preferred editor but also see how things will render without needing to "`git push`".
edemaine commented 2 weeks ago

Yeah, I know local copy is the intended way to do this, but I never got local catsoop to work. Trying to follow those instructions again, the issue seems to be that port 6011 is in use on my machine, but I can’t figure out by which process (having tried all of these, I can see it’s in use, but no process is listed). If I recall the last time I looked at this, I believe port 6011 is hard-coded into the code -- perhaps it could be overridable in config or an environment variable.

Even with local working, I feel like the editor with preview feature would be pretty handy, in particular for quick edits where you might not have a local copy handy, but still want to check your work.

Yeah, I know local copy is the intended way to do this, but I never got local catsoop to work. Trying to follow those instructions again, the issue seems to be that port 6011 is in use on my machine, but I can't figure out by which process (having tried [all of these](https://www.cyberciti.biz/faq/what-process-has-open-linux-port/), I can see it's in use, but no process is listed). If I recall the last time I looked at this, I believe port 6011 is hard-coded into the code -- perhaps it could be overridable in config or an environment variable. Even with local working, I feel like the editor with preview feature would be pretty handy, in particular for quick edits where you might not have a local copy handy, but still want to check your work.
hz commented 2 weeks ago
Owner

...I believe port 6011 is hard-coded into the code

Not so! I believe that changing, for example, the following should do the trick:

cs_checker_server_port = 6012
cs_checker_websocket = "ws://localhost:6012"

The first should change the port that the websocket server uses, and the second should change where the client tries to connect.

Even with local working, I feel like the editor with preview feature would be pretty handy...

I agree!

> ...I believe port 6011 is hard-coded into the code Not so! I believe that changing, for example, the following should do the trick: ```python cs_checker_server_port = 6012 cs_checker_websocket = "ws://localhost:6012" ``` The first should change the port that the websocket server uses, and the second should change where the client tries to connect. > Even with local working, I feel like the editor with preview feature would be pretty handy... I agree!
edemaine commented 2 weeks ago

Indeed, that works - maybe you could add it to the documentation? 🙂 Or more usefully, maybe port configuration should be part of catsoop configure?

I guess the next problem is that a local server doesn’t work well when being accessed from another machine. I usually do Catsoop work on a Linux server, not on my desktop filesystem, and things don’t work well when accessing the server from my desktop (given the references to localhost). But maybe this would be better on another thread...

Indeed, that works - maybe you could add it to the documentation? :slightly_smiling_face: Or more usefully, maybe port configuration should be part of `catsoop configure`? I guess the next problem is that a local server doesn't work well when being accessed from another machine. I usually do Catsoop work on a Linux server, not on my desktop filesystem, and things don't work well when accessing the server from my desktop (given the references to `localhost`). But maybe this would be better on another thread...
hz commented 2 weeks ago
Owner

Indeed, that works - maybe you could add it to the documentation? 🙂

That’s the eternal question...

Actually, that part is kind of already addressed in the docs, but it’s hidden under the public-facing server install instructions since I didn’t expect that to be an issue for a local copy. And it’s not very well written anyway...

I guess the next problem is that a local server doesn’t work well when being accessed from another machine. I usually do Catsoop work on a Linux server, not on my desktop filesystem, and things don’t work well when accessing the server from my desktop (given the references to localhost). But maybe this would be better on another thread...

Yeah, maybe a different thread is more appropriate. But there is definitely an answer!

I still haven’t really figured out the right infrastructure for discussing catsoop things that aren’t dev-related. I set up a Discourse forum (as an intended eventual replacement for the catsoop-users@mit.edu mailing list), and I think that might be the best place, ultimately. So maybe the localhost question could be an inaugural post to the forum, or a thread on the mailing list?

> Indeed, that works - maybe you could add it to the documentation? :slightly_smiling_face: That's the eternal question... Actually, that part _is_ kind of already addressed in the docs, but it's hidden under the [public-facing server install instructions](https://catsoop.mit.edu/website/docs/installing/server_configuration) since I didn't expect that to be an issue for a local copy. And it's not very well written anyway... > I guess the next problem is that a local server doesn't work well when being accessed from another machine. I usually do Catsoop work on a Linux server, not on my desktop filesystem, and things don't work well when accessing the server from my desktop (given the references to `localhost`). But maybe this would be better on another thread... Yeah, maybe a different thread is more appropriate. But there is definitely an answer! I still haven't really figured out the right infrastructure for discussing catsoop things that aren't dev-related. I set up a [Discourse forum](https://catsoop.mit.edu/forum/) (as an intended eventual replacement for the [`catsoop-users@mit.edu` mailing list](mailto:catsoop-users@mit.edu)), and I think that might be the best place, ultimately. So maybe the `localhost` question could be an inaugural post to the forum, or a thread on the mailing list?
hz closed this issue 2 weeks ago
hz reopened this issue 2 weeks ago
edemaine commented 2 weeks ago

Back on topic, I happening to be checking out Notion today and saw the following animation, which made me think of this thread (on the gooer side):

Dragging chunks of text around seemed particularly cool...

Back on topic, I happening to be checking out [Notion](https://www.notion.so/educators) today and saw the following animation, which made me think of this thread (on the gooer side): ![](https://www.notion.so/front/educators/features/educators-text-editor-v2.gif) Dragging chunks of text around seemed particularly cool...
hz commented 2 weeks ago
Owner

Wow, that’s beautiful; thanks for sharing! If we could do something like that, I’d be thrilled. One thing that complicates this for catsoop is that the little <python> blocks can have effects that spread over the whole page, and I’m not sure how smart we would want to try to be with those kinds of things in the GUI.

The simple(ish) thing to do might be to have the GUI just straight-up ignore any page with a <python> tag in it. That would be pretty limiting, unfortunately, but maybe it would be a place to start (and with some foresight, maybe it would set us up to be able to gradually introduce ways for the GUI to interact with a limited set of Python stuff (like generating per-student random numbers, for example).

Wow, that's beautiful; thanks for sharing! If we could do something like that, I'd be thrilled. One thing that complicates this for catsoop is that the little `<python>` blocks can have effects that spread over the whole page, and I'm not sure how smart we would want to try to be with those kinds of things in the GUI. The simple(ish) thing to do might be to have the GUI just straight-up ignore any page with a `<python>` tag in it. That would be pretty limiting, unfortunately, but maybe it would be a place to start (and with some foresight, maybe it would set us up to be able to gradually introduce ways for the GUI to interact with a limited set of Python stuff (like generating per-student random numbers, for example).
edemaine commented 2 weeks ago

A kind of in-between would be a two-column layout with source on the left and current rendering on the right (or vice versa), ideally aligned block-by-block (inspired by the Notion example). Some <python> blocks will render as nothing (e.g. when setting up variables but not printing anything); others will render with what they print. But this would quickly give a sense of what various blocks of the page are doing, while also making clear that there are some “invisible” chunks that are presumably doing useful things. (Users should understand that some blocks have side effects, and should be careful about them.)

A kind of in-between would be a two-column layout with source on the left and current rendering on the right (or vice versa), ideally aligned block-by-block (inspired by the Notion example). Some `<python>` blocks will render as nothing (e.g. when setting up variables but not printing anything); others will render with what they print. But this would quickly give a sense of what various blocks of the page are doing, while also making clear that there are some "invisible" chunks that are presumably doing useful things. (Users should understand that some blocks have side effects, and should be careful about them.)
hz commented 2 weeks ago
Owner

Are you imagining the left-hand side being just a bunch of input textareas (or codemirrors, or something), rather than some fancy rendering? That might not be so bad, and we could allow dragging the blocks around if we did things that way.

Another alternative (easier, but less cool) would be just to have a side-by-side preview of the page contents. That’s probably actually a lot easier, because we could probably re-use more of the existing machinery for parsing/displaying pages, rather than needing to write a separate tool to handle the block-level stuff. But maybe I’m overestimating how hard that would be...hmmm...

Regardless, we probably need:

  • a nicer code editor (already on the roadmap)
  • obviously, the interface for rendering the previews
  • links to the page editing interface for admins, on every page
  • a hook for arbitrary post-save behavior (e.g., committing the updated pages to a Git repo)

We probably also want a nice interface for editing __USERS__ files, too, since I imagine that’s something that a lot of people would like an interface for. In it’s simplest form, this could just be another instance of a code editor on the web, but those files might actually be easier to write a focused UI for, since they’re usually a little more canned (less arbitrary Python code beyond just setting options, usually).

Are you imagining the left-hand side being just a bunch of input textareas (or codemirrors, or something), rather than some fancy rendering? That might not be so bad, and we could allow dragging the blocks around if we did things that way. Another alternative (easier, but less cool) would be just to have a side-by-side preview of the page contents. That's probably actually a lot easier, because we could probably re-use more of the existing machinery for parsing/displaying pages, rather than needing to write a separate tool to handle the block-level stuff. But maybe I'm overestimating how hard that would be...hmmm... Regardless, we probably need: * a nicer code editor (already on the roadmap) * obviously, the interface for rendering the previews * links to the page editing interface for admins, on every page * a hook for arbitrary post-save behavior (e.g., committing the updated pages to a Git repo) We probably also want a nice interface for editing `__USERS__` files, too, since I imagine that's something that a lot of people would like an interface for. In it's simplest form, this could just be another instance of a code editor on the web, but those files might actually be easier to write a focused UI for, since they're usually a little more canned (less arbitrary Python code beyond just setting options, usually).
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.