RFC: Publish improvements

[asolove]

This issue is intended for a quick discussion of proposed changes to the UI for publishing files from CPO.

I am especially interested in feedback from instructors and trainers who have had trouble with using publish as a mechanism for:

• instructors to distribute assignments, tests, or helpers
• students to submit their work

Problems

• People don't understand that they need to go back to publish and click "update" so that their saved changes will be visible to people with the publish link. (Publishing UI -- what do "close" and "update" mean? #302) This is especially confusing on the first publish, when you've just explicitly allowed it to be published, but the text and button for updating the published version are still visible.
• The UI for sharing is confusing (Published link UI is confusing #301) because the inputs are sized oddly, the choice between url/import is hard to understand, and there's not an obvious way to copy the link.

Proposal

My proposed set of changes are restricted to keeping the current behavior, but making it clearer in the UI.

• On first publishing a file, it should be clearer that it is only the current version being shared

  • Make clear that the file will need to be re-published for changes to be visible to others.
  • And, fix the issue where the first modal disappears for a while and seconds to minutes later the second modal appears. Leave a modal open with a spinner and a place to report timeouts and errors.

• After publishing, the publish state should be easier to understand

  • In the CPO editor top bar, the "Publish" button should have a separate visual state when the file has already been published and should indicate if the published version matches the currently-displayed source.
  • The publish dialog UI should be changed to make clearer that it has two separate functions:
    • Understand what version is currently published and to update it with the current code
    • Get the URL/code for sharing the published version with others
      • Make clear this URL/code is evergreen, so the contents will change on future publishes
      • Show the URL prominently with an obvious "copy to clipboard" button
      • Show the import code less prominently, possibly requires manually clicking a disclosure arrow

• Make sure we're timing out, handling errors, and logging issues with any requests that could break or spin

  • Publish button sometimes seems unresponsive #95 might be too old to reproduce directly, but could still be happening

Alternatives / extensions

• Make it possible to publish multiple versions of a file, with URLs/imports that continue to point to the old version even when a new one is published. This could be useful for canonical libraries that want to have version numbers. Or for students working on a large project to publish at the end of each class period so an instructor can go back and see the archive of day-by-day progress.
• Add separate publishing permissions/types to shared files. This would enable instructors to publish private tests or implementations that students can run but not see the source of. (This would need to be surface-level protection: students who know DevTools will still be able to see the source, but we could at least make it harder.) (I saw this requested somewhere on GitHub but can't find it now. Would appreciate a link.)

Current state

When you publish a file for the first time, you are greeted with:

After accepting that warning, the modal closes for several seconds and it's easy to miss the bottom-right message saying something is happening. Then the full Publish modal opens up on its own again. Importantly, this modal has yet another Publish button, which is actually distracting and has no visible side-effect, because the code is already published and hasn't yet been changed.

The full publish modal, seen on subsequent clicks, looks like:

[schanzer]

Awesome to see this getting some TLC! :)

A few thoughts...

1. In the first dialog students see, the blue button should say "OK" or "Proceed" instead of "Publish", since clicking that doesn't actually publish it! Rather, it's proceeding after being warned.
2. In the second dialog (share or update), the blue button should say "Publish", since that communicates the action that started a user down this path.
3. The text at the bottom should be removed. Better button titles should make this unnecessary. But if we must keep it, let's at least change the reference to the "close" button, which no longer exists.
4. Would be nice to add the copy-to-clipboard icon to the right of these input elements
5. Can we have more vertical space between these two links, and maybe some indication of which text goes with which? Even changing the periods in the first two sentences to colons would add some clarity, but I could even see a tag or something being useful here to make it clear what goes with what.

[asolove]

@schanzer Are you sure about 1? I am fairly sure it is published, and the link works, after clicking the first button.

[schanzer]

If it does, then the buttons on second dialog box are misleading. An operation can't be cancelled if it was already completed.

[asolove]

Yeah but I think that is true. Every modal had that button automatically, and it is already known that it didn’t make sense in other places. So yeah it needs to change one way or the other.

…

On Mon, May 31, 2021 at 8:22 PM Emmanuel Schanzer ***@***.***> wrote: If it does, then the buttons on second dialog box are misleading. An operation can't be cancelled if it was already completed. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#380 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAACCL6HETEJCW7XZI5XCDDTQN5QJANCNFSM452JU46Q> .

[asolove]

Further discussion in #414.