Publish vs Save UX & Terminology

[RitterKnightCreative]

Is there a UX reason why after pressing Save on a published entry Craft sends you back to the Entries screen?

I am reminded of this again the other day when I received an email from a client that wanted to make changes to a "live" published version of an entry. She did everything right, including pressing the Save button.

However, because that entry was already published, the client thought she had made a mistake since she was now seeing the "export" button on the bottom of the entries window after pressing Save. She apparently had missed the "entry saved" notification on the top. However, the entry was saved and her changes published live.

I know it's always been this way but I've felt it's been somewhat confusing myself. I've been so ingrained on just pressing Cmd/Ctrl-S as somewhat of a workaround and have taught my clients to do the same if they want to save changes to the current document quickly/easily + stay on the same page.

Perhaps this could be a user preference where Cmd-S could keep th the current behavior (save and publish the current working version), always save as a draft (if not already in draft editing mode) or save and publish (but stay on the page).

Save vs Publish Terminology

One other recent nuance here introduced in 3.6 (#5661 IIRC) is if you're working on a draft and press the Publish draft button, this publishes the current draft (much like the Save button does). However it still keeps you on the same editing screen. (IMO this is actually the ideal behavior I'd prefer to see Craft take but I'm sure there's some reason to jump back to the Entries screen at some point?)

I also wonder about changing the "Save" button to "Publish changes" (or Update similar to WordPress) on current / live documents? That would at least make it clear what's going to happen. When you create a new entry, the only way to make that entry live on the web is to Publish it. The only wrinkle here is IIRC that's the only place where "Publish" appears in Craft (except in user permissions). So we're mixing up verbs a little. (FWIW "publish" also seems to imply "make live" as it has its own user permission as well.)

From the old DTP days, Save always meant save. When I went to go Print a document, you press Print. Nowhere does Saving a document ever imply the document is going to be printed.

On the web, let print stand in for publish or "make this version go live." However, when we hit "Save" it does just this—save the version and make it live. I'm not sure there's anything wrong about this per se but there might be a disconnect for some users.

When someone hits "Save" (or Publish) there might also be multiple things happening behind the scenes (cache busting, email triggered for approval, etc.) I think there might be an opportunity to tighten up terminology a bit here. After all, in a larger editorial flow, someone could be allowed to create new entries and save them but not necessarily publish them (make those changes live). However down the road it could be useful to let the organization define rules as to what happens when authors hit that Publish button... for example, maybe in Craft 4 it's Submit for Approval or whatever. (Right now Craft just gives unprivileged, "unpublished" authors the "Save as Draft" button.)

As an aside, I've also seen this pop up where users are inadvertently saving too early because they are so used to using the keyboard shortcut.

Thanks for reading...

[brandonkelly]

Is there a UX reason why after pressing Save on a published entry Craft sends you back to the Entries screen?

It’s consistent with every other Save button in the CMS – they save and then take you back to the parent page in the breadcrumb hierarchy. If we change the behavior for entries, I think we should change it for everything else as well. (Not saying I’m against it; just that there are other implications.)

However, because that entry was already published, the client thought she had made a mistake since she was now seeing the "export" button on the bottom of the entries window after pressing Save. She apparently had missed the "entry saved" notification on the top. However, the entry was saved and her changes published live.

This should be solved when we get around to making some accessibility improvements to the notifications (#7142).

One other recent nuance here introduced in 3.6 (#5661 IIRC) is if you're working on a draft and press the Publish draft button, this publishes the current draft (much like the Save button does). However it still keeps you on the same editing screen.

It’s been that way since 1.0, actually. When you publish a draft, it takes you to the Current revision of the entry, which will now contain the draft’s changes. Which still feels like going back, since you typically get to the draft via the Current revision.

I also wonder about changing the "Save" button to "Publish changes" (or Update similar to WordPress) on current / live documents?

I do like the idea of giving some amount of consistency to the publish-y button labels, across both entries’ Current revisions and their drafts. However:

• It would make the ⌘ S shortcut a bit awkward considering Publish starts with P.
• We’d also need to update some of the Save button’s options:
  • Save and continue editing
  • Save and add another
  • Save as a new entry
• “Publish” is already a bit of an awkward word when you are “publishing” a draft that is set to disabled, and now we’d be doubling down on that, which feels wrong.
• Saving entries isn’t the only thing an author could do that will affect the front end. Editing categories, tags, assets, users, etc. each have effects as well. And “publish” definitely feels like the wrong word choice in those contexts.

So I dunno… I’m open to other ideas, but this isn’t quite it.

[RitterKnightCreative]

@brandonkelly Thanks for the reply. However, since you closed this, can I assume I shouldn't waste my time clarifying some points you made?

[brandonkelly]

@RitterKnightCreative Only closed because I don’t think there’s anything actionable here at this time – but feel free to continue the discussion if you have other thoughts to add!