"Publishing" a private paper on social paper?
I have a private paper on social paper. To save it, I have to press "publish." That seems a little counterintuitive. I had to do a double take to make sure that the paper was indeed private.
#1 Updated by Boone Gorges almost 4 years ago
- Assignee set to Samantha Raddatz
- Target version set to 1.10
Thanks, Raffi. I agree that it's not clear.
WordPress doesn't have this problem because 'private' and 'draft' are both "post statuses", and thus are mutually exclusive. For SP, we've separated privacy out, so that you can have drafts of papers that are marked private.
What's happening here is that a paper in Draft is only available to the author, while a "published" private paper can be seen by anyone (readers, members of associated groups) with permission to see the paper.
Sam, do you have any ideas about how to codify this workflow with some clever button text?
#2 Updated by Samantha Raddatz almost 4 years ago
This one is tricky for sure, and something we grappled with before the release too. Thanks for bringing it to our attention, Raffi.
I propose a two-fold solution for this:
1) Consolidate the privacy and draft settings in to a single location (see attached mockup) so that the difference between draft and private is spelled out. Remove the 'Save Draft' button as well, so that there's no way to mark a paper 'private' and then click save draft. Basically, papers are either draft, public, or private, no combination of those is possible in the interface.
2) Either: a) Make the 'Publish' button text dynamic to reflect the settings choice for the paper ('Publish Publicly', 'Publish Privately', or 'Save Draft); or b) Use the space where the 'Save Draft' button used to be to indicate the status of the paper ('Public', 'Private', 'Draft') and the button always says 'Save Changes' or something along those lines.
#5 Updated by Paige Dupont almost 4 years ago
Incorporating this ticket with some of the usability issues we had during the Social Paper testing, I've added to this ticket by modifying the mockup. We can address the issues of the editable URL box along with the viewing settings together. We had recommended, after compiling our testing data the following:
- Combine all editable fields and settings into one area rather than separating the Title, URL, Description, etc. into separate and differently-styled areas.
Being that the URL box currently lives as a URL editing field, I propose we place it underneath the description box and explain its purpose since it is unclear that it is an editable field. This coupled with the "draft" settings adds more clarity overall for our users.