The Joomla!^® User Experience Portal

All the save options have gotten a bit complex. I'd like to at the very least combine all the save options in to a Save button w/ dropdown in 3.0. I'd also really like to have some sort of Autosave which gets rid of the current Save (formerly Apply). I always thought Save should Save & Close. Thoughts? (we've been discussing on Twitter, bringing it back here)

I think save and close are two clear options. Autosave could be a user setting, of a check box you enable or disable while editing to determine whether you will be a long time or not. At a minimum, detection of 'you have made changes, save ?' would be useful.

Save and close really saves time for the user. A 'Save&Close' button may be handier than apply/save/close. OTOH, it gets wordier. I've seen some kind of 'Quick update' which is save+close combined. That might be a solution ...

Also, one of my all time favorites : a stack of recently changed objects, since we all know you toggle between menu, module, article, form etc. -- also a GREAT timesaver.

@kyle - if we combine the dropdown button idea with a user preference to use save or save&close as a preference ?

You're gonna hear me say this a lot, but I think Joomla has too many damn options and settings.

I'd love to just see these 2 options when editing: Save / Cancel
- Save would actually Save & Close
- Autosave would happen in the bg
- Save would have a dropdown with: "Save & New" and "Save as Copy" (or maybe just "New" and "Copy")

I agree with that. Only, I would use the dropdown on the button to select the meaning of the close :

<div class="btn-group">
<a href="#" class="btn btn-primary"><i class="icon-ok icon-white"></i>Save</a>
<a href="#" data-toggle="dropdown" class="btn btn-primary dropdown-toggle"><span class="caret"></span></a>
<ul class="dropdown-menu">
<li><a href="#"><i class="icon-ok"></i> Always save and close</a></li>
<li><a href="#">Update only</a></li>
<li class="divider"></li>
<li><a href="#"><i class="icon-plus"></i> Save as a copy</a></li>
</ul>
</div>

I don't know if would come into this topic, but...
What about for default an article would not be published.
Then you would have the button, Save, Cancel and a new one in different color and position, Publish.

So when you press Publish, it would have the behavior as Save and close, but it would publish the article to appear for the user.

Just to bring this to the table:

The current 'Save as a Copy' is unclear in what it actually does.
If I open an article and make some changes. Then I want to save it and make a copy of it. To my understanding, you still need to 'Save' first and then click on 'Save as a Copy'.
I have made the mistake a few times of clicking the 'Save as a Copy' expecting the changes to be saved in the original article too... I am probably not the only one.

For me a much more useful functionality would be 'Save & Copy'. I don't really see a situation in which you would not need to save the current article (before copy) first.

Also, the 'Save & Copy' approach fits in with the other 'Save & ...' buttons. So prevents the necessity for the user to have to think!


I am not sure an auto-save feature is really feasible or even desired if the article is already published. That would cause the article to be live adjusted on the frontend... not something you want.
So then you'd need a 'temp' saving article which updates the actual article upon close. But then you get the problem of what happens when you don't close via the button but just close the page via browser... And you get another bunch of issues, like: how do you see what is 'temp' saved and what is actually live? And you need a 'Cancel' button to cancel the auto-saved changes.
So you loose a 'Save' button, but gain a 'Cancel' button

I personally didn't have any problems with Apply, Save, Close.
As we know, that is now Save, Save & Close, Close.
I'm not sure it is wise changing that back to Apply, Save, ...

Here is an idea:
Have a Save button with 4 dropdown options:

• Save & Return (= Apply)
• Save & Close
• Save & Copy
• Save & New

Then have an option to set the action of the main 'Save' button. Default should probably be 'Save & Close'.
Besides the option to set the action to one of those 4, you could also choose to make it 'Remember Last'.
So if I create an article and choose 'Save & New', then with the next article I choose the main 'Save' it will do 'Save & New'... well, you get it.
It can be made clear on what the 'Save' button does by giving it a tooltip and/or placing an asterisk on the dropdown option that is set as action.

As usual, Peter makes a very good point. Actually, more than one. I feel we could write up a UX guide -- apart from the visual elements -- to describe what we feel is semantically 'right' to have as actions.

nonumber wrote:


In a lot of CRM systems, you go from a list view to a detail view and then on to editing -- since most of the time, you are looking up stuff. Not so in the CMS backend : you're mainly there to create or update (level 1) or publish, recategorize (level 2) articles and other items. It makes sense to go to the edit view immediately from a list, and consider the most logical action to be updating aka. save (called SAVE or UPDATE, currently sometimes APPLY) and close (CLOSE or CANCEL -- the latter may be automatic ). To me this suggests as a guideline

• saving your changes
  • UPDATE : signals that you will update the information as others see it
  • SAVE : puts the emphasis on storing, persisting, less on the effect on others
• closing the window
  • CLOSE : suggets that all that will happen is close the view
  • CANCEL : suggests that there are changes you will lose when closing the view

It might make sense to detect any change automatically and change the CLOSE to CANCEL and activate the SAVE button.

Exceptionally, you will want to keep the view open -- typically you want to see the effect of the changes before committing to them. Here's where versioning (or its absence) comes into play. There's no 'temporary' impact or rollback functionality in Joomla. What you save is immediately effective. It's only publishing that affects general visibility. As long as we do not ensure the changes are kept in a temporary item/version, updates are immediate.

Keep in mind that not all objects are articles which typically have multiple iterations of the HTML. In many case, you're looking to update a single flag or property (publish, module position, category, ...) which calls for a change > save and close. Perhaps we need guidelines as to what type of edit action (per semantic item) makes most sense, and have the component select a strategy from a limited set (2-3) of flows and wording to keep the UI simple.


Good point, depends on the typical workflow. I feel it's something that should be explicitly switched on, like a checkbox next to the save button if available.



Great minds, Peter, great minds ...