Allow saving a draft without editorial workflow

[t1merickson]

- Do you want to request a feature or report a bug?

Feature

- What is the current behavior?

Draft saving (eg. not publishing, but allowing saving to the repo in some way) of an item/post without having the entire Editorial Workflow enabled.

- What is the expected behavior?

Allow saving as a Draft, as shown in the UI mockups for 1.0

Change of terms:

"Draft" is now universal term for the antonym of published
"Working" is now the term for the first state of editorial workflow
"Save" button in editor should be "Save draft"

Additional:
Unpublishing, if made possible, would revert a published item/post to a draft. #727

Tangentially related to this as well: #388

[tech4him1]

How is this actually different from the Editorial Workflow? As far as I understand it, the states in the Editorial Workflow don't actually do anything, they are just there for UI purposes.

[t1merickson]

@tech4him1 It would be available by default, and it wouldn't need to Editorial Workflow interface. It's a simpler answer to a basic question of being able to "unpublish" or not publish in the first place, something that's an unfinished draft. Useful even if you're a solo author of a site.

[pungggi]

absolutely agree with neutyp. the Editorial Workflow could be too much for a lot of users, but the alternative right now is to publish or not to publish, a Draft saving is exactly what is needed. I think technically in the background this can work like in the first step of the workflow (a pull request?)..

[tech4him1]

That makes sense, but would the Editorial Workflow basically just be an extended UI layer on top of this? After all, in the actual implementation an EW post really only has two states -- published and not published. In this case, I think we would just be putting a simpler UI on top of it.

@neutyp Thanks for your explanations on this concept. Am I reading into this correctly, or entirely missing the point? cc/ @erquhart

[t1merickson]

@tech4him1 I have a weakness in that I usually think of things from the UX perspective first, and may not always understand the technical constraints in how the CMS works with Git. So, basically, it seems that yes, this may be the same underlying functionality of the editorial workflow, but presented with a simpler UI, and enabled by default.

[tech4him1]

@neutyp I'm trying to work from the opposite direction to the UX side here, I think :), and I really appreciate all the different viewpoints we are getting, sorry to draw this discussion out so much.

If I'm understanding it correctly, UI-wise, the editorial workflow would just provide an organizational workspace ("Draft" vs "In Progress" vs "Ready") which could later be expanded on, whereas this standard draft workflow would provide the same underlying functionality (save your work without publishing) without the entire conceptual overhead. As long as we get the backend implementation cleaned up, I think this is an awesome idea.

[t1merickson]

@tech4him1 Exactly right. The desire of a simple "draft" is just the ability to save your work without publishing. I view the 'editorial workflow' as a larger thing that may in the future have greater functionality like the ability to assign review to a specific user, etc etc other neat things

[erquhart]

Best prior art here: #464 (comment)

@tech4him1 yes, this boils down to always using editorial workflow behind the scenes. The current "simple" workflow would be replaced with a single state editorial workflow (just draft).

Dropping the kanban board view for this new simple workflow makes sense, but it raises the same issues as dropping the kanban view for the current editorial workflow: users still need to be able to see everything that isn't published across collections. We floated some concepts on how to solve this, but nothing really satisfactory came out of it. We should definitely not have the kanban board for this new simple workflow (and maybe not for editorial workflow either), but we need to solve the resulting unpublished entry visibility problem first.

[erquhart]

Thought: this shouldn't be PR based for Git backends, probably just a branch and optionally a PR (via config)?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.