The save-split-buttons have been a controversial topic over the last months.
The idea of this thread is to discuss a final ™ solution.
Since there are several solutions possible I’d like to discuss first and keep this initial post up to date.
Here is my rundown of the feedback I received over the last months together with an analysis of the impact.
1. Remember the last action
this offers more possible behaviors:
1.1. Remember last action per record
Example: be_user.uc.tx_news.1324.lastAction = SaveAndClose
This needs to be stored somewhere, thus bloating up the user settings too much.
1.2. Remember last action per table
Example: be_user.uc.tx_news.lastAction = SaveAndClose
Same problem as 1.1.1 in case of a lot of record types being available in the system.
1.3. Remember last action for all records in one
Example: be_user.uc.lastAction = SaveAndClose
Conceptual error: What happens if the last action is not available for the given type? Imaging news having “Save and New”, while pages does not have this action.
2. Set a default action
2.1. Set central default action
See 1.3.1, what happens if that action is not available?
2.1. Set a default action per table.
3. Responsive Approach
The current idea is to show all buttons, based on the available screen width. So on a bigger screen all actions are available and once the space is not there anymore, it collapses down to the current splitbutton.
Another feedback we got regarding “auto-learning” buttons was that supporters did not like the idea because that would mean that every system looks different in terms of “Editors call us and they have a different button than I have”.
Revisions (autosaving / revisions / reset to revision)
Preview (not persisted / unpublished data / revisions)
Still the major topic is how to preselect a button.
We introduced the “Split-Button” to make the interface more self explaining and also group options if they are almost identical to reduce the ammount of buttons shown and have more space for descriptions
We decided against a preselected value for each record type because we can not guarantee that every option is available for all records also building that interface that would be nessesary because is also has to include options based on pagets for behaviour changes and userrights all of this may lead more or less to an inconsistency based on setup or just create confusions
We decided against a adapting value because it could lead to unintended actions - instead we preferred consistency
Example of what happens if you just want to preview data and forget about your automation.
I propose a different approche:
maybe the user don’t want to choose between save, save and view, save and close, save and new.
maybe the user would like that we propose him to save when he makes an action (close or view or add or quit), an only when it’s necessary.
here is a little image of what I imagine:
One click action (when you repeat the actions, you loose a lot of time if you have to do 2 click)
Buttons always at same place (having to seach of a button makes you loose time)
Prevent user to do a miss-click (miss-click = loading = loosing time)
Pro of today solution:
User know exacly what they do (for casual user, having only icons is not enough)
Buttons position is fixed
User has less chance to do a miss-click (closing instead of saving)
Cons of today solution:
User don’t see all possibility at first sight
When you want to “Save and new” you have need 2 click
I like Rachel solution.
Instead of “don’t ask again” it would be great to have a checkbox “autosave”. In that case, you can activate “autosave” when you have repeatable actions to do, like “Save and new”
Hello, I also agree with the proposals of pgampe but I fear that it would be very hard to have everything.
so I think that it should be better to concentrate on the shortest list of features possible.
For me, they would be:
decide what should be a “preferred” action (User TS or Group TS) with a fallback to “save” if the action is not available (for me, “save and close”)
“responsive uncollapse” of the buttons on larger screens.
make the button more visible (bigger or with a different color)
Hi, I would suggest to take the unreleased master branch of rx_unrollsavebutton. It has a maximum flexible configuration of reordering buttons. It also has a small bug with save buttons in scheduler tasks, but I’ve fixed it already in my own fork (EXT:unroll)^^.
a usefull thing I discovered recently is opening the save menu on hover. The one click saved feels much better already and the effect is propably most achievable with 3. Responsive Approach as it potentially saves the additional click aswell.
I like the fact that the current implementation forces an active decision what to do when saving/closing. When everything is available at once it’s accessible while still having the active decision.
My concern with Approach 1 and 2 is when they fail, so you still have to be on your toes. On the other hand, working systems that take decisions from the user feel pretty great.
I like your ‘responsive approach’. While I do not like to use Webapplications on Smartphones in general, I understand, that people sometimes wish, they could. And in respect oft that, the responsive solutions feels just ‘right’.
I suggest to keep things simple for users and developers. Therefore, I support approach no. 3 because of the following reasons:
Transparency: All possible actions are visible at once
Ease of use: only one click needed
Consistency: buttons always stay in the same position, so users find them instantly.
Strong defaults for integrators: in 99% of the cases, you don’t have to configure anything
No surprises, no hard-to-understand magic
Low implementation and maintainance cost: Low complexity so nothing needs to be documented and nothing can get broken
The approach should be combined with:
make “save & close” default and move it to the front, maybe highlight it (because buttons look very much alike right now)
a good API, so people who need customization or complex scenarios can still use extensions and extension developers have an easy job
A little off-topic:
I also like Rachel’s Idea regarding the separation of (pre)viewing and saving. Typically, editors want to be in control of the publication process and be able to check their work before actually publishing it. So they expect the following functionalities:
View last-published state of the record (if it exists) in frontend
Preview new record / see modified state of the record in frontend (modifications applied temporarily)
Of course de-coupling the preview from the save functionality has some technical implications but I think we should somehow move towards that. Maybe also the workspace feature, which is powerful yet a little hard to use, can be helpful in this context.
A “copy” or “clone” functionality would be nice for certain records