Now that Collaborative Editing has been changed to be enabled-by-default, we’re immediately seeing a lot of people in Post Approval complaining about “losing” their scripts, or not being able to publish (4 at the moment of writing, this has only been enabled for 1 day). There were also 5 other people in Post Approval confused about this workflow 2 months before it was made enabled-by-default.
The first few replies to this topic are some of these mistaken bug reports merged in from Post Approval.
This usability issue is also coming up in support topics:
There is a significant usability issue with the Collaborative Editing feature when trying to work together or publish a place with uncommitted script changes.
Users do not understand that they need to commit their changes now, they do not understand the Drafts window is what’s used to commit script changes, and don’t know to open it when they’re stopped from publishing. The Drafts widget initially magically appears with no visible buttons or obvious required actions when you edit a script. Users will either leave the widget there, or more likely close it and forget about it because it’s invasive and disrupts their layout. The widget reports that their work is “saved”, so users likely see no problem with just closing it.
The popup dialog when attempting to publish is a partial solution to users not realizing they need to commit their changes. Currently, it does not suggest that users can commit changes via the Drafts widget, and users don’t tend to click on the Learn More link to discover information that has been left out in the popup dialog. Further, the anchor link on the DevHub does not seem to work in Chrome, so this information has to be scrolled to - all the way at the bottom of the page.
Because they’ve likely closed the Drafts widget, and/or because the concept of “committing” is invisible in the Drafts widget UI (context menu only), this causes users to mistakenly believe they’re receiving an error about a problem they cannot fix themselves when they try to publish. The dialog message does not clearly offer the solution.
Further, there is no way for developers to discover what any of this means apart from this dialog box. Two unaware developers can make edits to the same script and then become confused when their respective versions become out of sync.
Firstly, to help mitigate the issue with users not understanding the dialog, I think the Drafts widget needs to be mentioned in the popup text (at minimum). This would at least be a clue linking the idea of “Committing” to the widget. Clever users might be able to put the puzzle together and discover naturally how this workflow works (without using the Learn More link) if the dialog text was changed to something like:
There are uncommitted script changes that will not be published with the place. Do you want to cancel and commit these changes with the Drafts widget, or publish anyway? Learn more
If possible, opening the Drafts widget (if closed) when the user clicks Cancel would also help them discover things naturally.
I’ve brought up similar usability concerns and suggestions on the announcement.
