Save and Publish - how should that look?

Topics: Feature requests, General
Coordinator
Mar 1, 2012 at 2:11 PM
Edited Mar 1, 2012 at 2:15 PM

Here is a short "concept mock" showing one way to introduce a Save and Publish button in the UI.

http://www.screenr.com/Dus8

Save and Publish is the feature request with the most votes, so we are looking into implementing it - so give us your feedback now :)

Coordinator
Mar 1, 2012 at 5:13 PM

On http://www.screenr.com/Dus8 @HurricaneJs wrote

I think I'd prefer the action to be default click on the button saves and if you choose to open the drop down and select "Save and Publish" it just does it. No need to click a second time. I doubt that would cause much accidental clicking.

The state of the button would be "sticky" in that your last selection is preset in the future, so you would only need to switch once. Next time you begin editing a page or other publishable content, the button will give you one-click publishing (if that is what you last selected).

Today you can do a save and publish with two mouse clicks already, I'm hoping to get this down to one.

An important premise here is that a user typically want to do either one or the other. For users who 50% of the time wish to save only and save and publish in other situations, nothing is gained by a "sticky button". But for users who don't want to bother with publishing workflow clicks, this is a cure.

Mar 2, 2012 at 7:58 AM

Hi,

Why not just two buttons, i.e. one for 'save' only (easier to address user rights) and one for 'save & publish'.

mzZzl,
JamBo 

Coordinator
Mar 2, 2012 at 9:59 AM

If we add a new button, we would end up with 3 buttons in the UI which 'cross paths'. The "Save" button and the toolbar "Publish" button we have today and then the new "Save and Publish" button. This could cause some confusion in a fairly central and often used area.

The sweet thing about the "Save and Publish" button is that, once you start using it, you will be rid of both the "Save" (it's hidden) and the "Publish" buttons. So people using this feature will have less buttons to click than they have today. Users who like to have "intermediary saves" will have the same experience as they have today.

Coordinator
Mar 2, 2012 at 10:02 AM

@HurrinaceJs I like the idea that "selecting the drop down and clicking the other button" fires the event immediately - I guess there is no reason to wait for a third click. But I'd still like to have the state "sticky" and reused for new edit sessions.

Mar 6, 2012 at 3:31 PM

I would assume that if a user doesn't have publish rights, this choice wouldn't show up at all ( not even greyed out ). If that's the case, I like it as developers can (and probably should) have a work flow that does not allow content writers to publish anyhow. This functionality is really mostly useful for content publishers and admins. 

Nicely done. I might recommend a check mark (or some other indicator) to the left of the currently selected option in the drop down. It gives the user instant feedback that the drop down is essentially an option box.

Coordinator
Mar 7, 2012 at 11:26 AM
Edited Mar 7, 2012 at 12:31 PM

Yes, the "Save and Publish" button is only in the UI if user has publish access.

On the check mark - in my last comment above I kind of changes my mind based on feedback from @HurricaneJs - opening the drop down and clicking an option will both select it and execute it. So two clicks instead of three. I can see this making sense. That the second click is "executing" make the drop down less of a selector, so the check mark may confuse here.

An alternative is that the drop down simply contains "the other option" only. We will try to see what feels best.

 

We are planning the CRTL+S like this: if "Save and Publish" is the active button, CTRL + S will do a Save and Publish.

Coordinator
Mar 23, 2012 at 12:38 PM

The "Save and Publish" feature has been completed and is available in version 3.2 (change set 13747).

We are pretty ecstatic about this little thing. Besides from closing the current top voted community request, the implementation uses a "sticky selection" approach which means you can switch from a "give me the workflow" to a "skip all workflow" simply by toggling the "Save" button to "Save and Publish" (or vice versa). You can easily change model for a single page. Also CTRL+S will adhere to your selection.

To try it out now download the latest sources and it a spin.

Video intro: http://www.screenr.com/n428

Mar 23, 2012 at 2:33 PM

you're still not possible to localize it? 

<ui:menuitem id="saveandpublish" label="Save and Publish" image="${icon:saveandpublish}" image-disabled="${icon:save-disabled}" observes="broadcasterCanSave" oncommand="this.dispatchAction(EditorPageBinding.ACTION_SAVE_AND_PUBLISH);" />

the label is still hardcoded, bad squishy!

Developer
Mar 23, 2012 at 4:43 PM
Edited Mar 23, 2012 at 4:43 PM
burningice wrote:

you're still not possible to localize it? 

  


The issue has been reported. For now, I can suggest this temporary solution:

  1. Add <string key="Website.App.LabelSaveAndPublish" value="Save and Publish" /> in ~/Composite/localization/Composite.Management.en-us.xml
  2. Add the same string with proper translation in ~/App_Data/Composite/LanguagePacks/<YOUR_LANG_CODE>/Composite.Management.<YOUR_LANG_CODE>.xml
  3. Replace label="Save and Publish" with label="${string:Website.App.LabelSaveAndPublish}" in ~/Composite/controls/FormsControls/FormUiControlTemplates/Buttons/SaveButton.ascx
  4. And restart the server, clear the browser cache, and F5

 

Apr 11, 2012 at 7:20 PM
Edited Apr 11, 2012 at 7:23 PM

Great work on the Save and Publish. Just checked out the video on YouTube.

One question... while watching that demo, it looked like you had a separate preview window open for the page. How did you get that?!!! Is that a 3.2 feature as well?

Apr 11, 2012 at 7:45 PM

do you mean the right-clicking on a page (in the tree) and choose View Published or View Unpublished?

Apr 11, 2012 at 7:53 PM

Yes! Why have i never used that! I must have seen that menu item many times, yet it never clicked in my brain.

Hmmm... I wonder if "Preview Published" would be a better fit for that menu option. "Preview" is a trigger keyword with a specific meaning.

View is more generic. I think, in my head, I saw View Published and never associated it with a preview of that page, but rather as a list of some sort of published or unpublished pages/items/etc.

Maybe I'm the only one who has never clued in to that, though.

Apr 11, 2012 at 7:56 PM

well, technically its not a preview... its an in-console browser that supports one neat trick: it keeps the focus of page-item in the tree in sync when you browse the site. Otherwise, there is no difference on viewing a page using this, or in a dedicated tab/browser.

The real preview is on the "preview" tab, where you can see changes in content without having to save first :)

Apr 11, 2012 at 8:03 PM

Yes, I know you're right... I'm just trying to figure out why I never made the connection. Even after I watched the video... I right-clicked and looked for an option that would view the page but never saw anything. Maybe adding "page" to the menu, I don't know.

"View Published Page"
"View Unpublished Page" (though I guess you could call viewing an unpublished page a preview of what the published page will look like)

I know it's slight more verbose and may seem redundant given that the menu is context-sensitive... but hmmm... I'm just thinking out loud here... because I'm flabbergasted that I didn't see it.

Apr 11, 2012 at 8:10 PM

no worries :) my only problem with naming the command something with preview, is that it will ambiguate the meaning of the existing "Preview" tab, since this tab does something different then the "Preview" when right-clicking a page then would do.

Coordinator
Apr 12, 2012 at 7:13 PM

Sounds like we should change how the "View Published" and "View Unpublished" actions are presented - that @oneproton did not find it intuitive indicate we have a problem :)

How about these changes:

  • Action labels are changed
    • Browse Saved Page
    • Browse Published Page
  • Have "Browse Saved Page" in both the top toolbar and the context menu
    • The "Browse Published Page" is only in the context menu

Any improvements I'm missing?

Coordinator
Apr 13, 2012 at 12:02 AM
Edited Apr 13, 2012 at 12:03 AM

Also we should change the iconography to something like this:

Browse Saved Page   Browse Published Page

Browse Saved Page will always be visible in the toolbar.

Apr 13, 2012 at 9:23 PM

I really like the  icons. I think they do well to represent the concepts well. 

Thinking about this more, I think having "page" on there is the important part, whether it says "view" or "browse" matters less, in my opinion. The idea of "browse" does intimate a browser, but it can also mean looking through a listing of objects. 

I'm not sure on the wording "Saved Page" though. "Published" and "Unpublished" very explicitly says it's the page that is not yet published. My idea behind using the word "Preview" was only to keep it short while adding meaning.

Maybe it's just a case of it being: View Unpublished Page and View Published Page with those new icons?

One thing I also noticed is that you can't open both up at the same time in separate tabs. A reviewer may want to open up both to see what changes were made and how they will affect the currently published page. Just an idea.

Coordinator
Apr 16, 2012 at 8:34 AM

Using "Browse" make sense since this is tied to the existing "Page Browser" command available on the "Tools" button.

On the "Saved" vs. "Unpublished" I'm leaning towards "Saved" for a number of reasons.One reason is the fact that "Unpublished" actually does not really mean 'not yet public' when browsing a page which has not been edited since last publication. So "View Published" and "View Unpublished" can show the same - which is a bit weird.

The concept here is "content that is not yet published, and if no such content exist, the published version" which is rather tricky to convey in a single word. Using the word "Unpublished" is not really 'technically correct' since the command may very well show published content, if there is no pending edits awaiting publication. Using the term "Saved" (as in 'last saved') is technically correct and probably easier to explain to a user. Like "The most recently saved version of the page" and "The most recently published version of the page". And the combo "The most recently saved version of the page may very well be the move recently published version also". Personally I can't find equivalent sentences using "Unpublished" and "Published" which describe things so simple as "Saved" and "Published" does.

Also "Saved" is good in the way it explains the user that it is different from the "Preview" feature, which will show unsaved changes.

> One thing I also noticed is that you can't open both up at the same time in separate tabs.

Are you sure? If I execute a "View Published" and a "View Unpublished" on the same page I get a tab for each page (inside the browser's main tab though). If you do not, please describe your setup.

Apr 16, 2012 at 8:38 AM

what about just removing the "Unpublished" command, if there is no unpublished content.

Coordinator
Apr 16, 2012 at 8:53 AM

It's not possible for us to determine if there is unpublished content or not - the page may show content from other pages (like items in the navigation menu) or page folder data etc.

Apr 16, 2012 at 8:59 AM
Edited Apr 16, 2012 at 9:05 AM

good point! no further comments :)

Apr 16, 2012 at 4:49 PM
Edited Apr 16, 2012 at 4:49 PM

Here too! You guys have put a lot of thought into this. Makes me feel all warm and fuzzy. :-)