[Enhancement] Save/Update forms persistent Save & Edit, Save & New, Save & Close

[OwenMelbz]

UX Improvements to add/edit form - fixes #73

[tabacitu]

Nice! This, coupled with placing the focus on the first field, will make adding entries very VERY fast :-)

A few mentions:

1. On EDIT, both options redirect me to url() instead of where they say they would;
2. On CREATE, I think the default should be either "go to table view" or "add another item". Because, theoretically, there should be no need for the user to go to the /edit/ after adding an entry - he's done. We shouldn't promote skepticism :-)
3. On EDIT, I think the default value should be "go to table view". Because, again, there should be no need to "check that the modifications have been made" after editing.

So, for consistency, I'd set them both to "go to table view". That way:

• you can expect both create & edit forms to work the same;
• there is no change in behaviour for those that update;

In the future, we could add a method to the CrudController to set the default behaviour. Say... $this->crud->redirectAfterSave($option), where $option could be 'table', 'create', 'edit'.

But that's a problem for future us :-)

Cheers!

[OwenMelbz]

1. I'll have a look at the edit, Im sure that was working!
2. Personally I hate it when you click "Save" and it takes you away from the item your editing, Imagine if you saved your PHP file, and your IDE closed it each time. From content writers perspective its also annoying when tuning your content and refreshing the front page - which is why Wordpress doesnt return you back.
3. As above

But for the user, once they pick "remain here" then it persists so its not much of an issue, but thats an explanation as to why I personally feel forcing the user away from the item they're using is bad UX.

[tabacitu]

Hm... I think it's apples and oranges - web development is based on trial-and-error edits, so keeping the window open makes sense. CRUD apps should not be trial-and-error, otherwise we did a bad job building them :-)

I understand what you're saying, but it sounds to me more like a personal preference, rather than the most probable scenario a user would follow. If we were to choose by this metric (what would the user most likely want to do next, after the action), I'd say "review the info" is pretty far down the list. I think from this point of view the content writer:

• after CREATE - would probably want to create another one
• after UPDATE - would probably want to update another one (list view)

Right?

[OwenMelbz]

As the session persists, the default option will only ever appear once anyway, so doesn't overly matter, but users who "save as they go" would get redirected.

Additionally on CREATE its typically only when bulk inserting is that a user journey, most people would be adding 1 item every so often, like blog posts, or products etc. I think it's only during a bulk content population phase is the "back to list" or "create a new" options are any use.

As it happens we just have 3 buttons typically

Save | Save and back | Back

But either way, its easy enough for the user to change once to their prefered option

[AurelDragut]

Just an idea about what i think you're talking about here: what do you think about three buttons ("Save", "Save and Close" and "Save and New")? i remember i saw this button group in magento...

[tabacitu]

@AurelDragut I like that the they would take up less space than now (just one line) and would be intuitive, but I don't know how we could remember a "prefered usage" using buttons and not radios; and this "prefered usage" is really a killer feature - it speeds up data entry a lot.

[OwenMelbz]

@tabacitu Pish thats just what I said :P

Our old CMS has

You dont need to remember what the last usage was, they just click what they want to do, its actually a step less than radios!

[AurelDragut]

It would be one click less also. Just like Owen said... And in this case i guess that "prefered usage" would still be necesary if the user can and want to submit the form by hitting the Enter key, ofcourse without hitting additional tabs to get to the proper button...

[tabacitu]

@OwenMelbz I know, what you're both saying is very similar. @AurelDragut only mentioned adding the "Save and New" button :-)

@AurelDragut - That's exactly what I was referring to. One of those buttons has to be the "default", triggered when content writers hit Enter/Ctrl+S/Cmd+S.

You may be right, having buttons instead of radios:

• would save one click or one Tab press;
• takes up less space;

So maybe we should find a way to do it with buttons. But I'd still like to include the persistent saving functionality. Now that I've tried it, I can't get enough of it. This + autofocus makes it a breeze to insert a lot of content - something content writers always do when the projects get started.

However, the only way I see it possible is something like this:

Which is pretty cluttered. It makes the user "think" and that's not good.

Let's sleep on it - maybe we'll find a better solution.

[tabacitu]

Maybe something like this would be easier to understand, but wouldn't save that one click?

And using an option from the dropdown would automatically make that the default one. So if you choose "Save and add new item", the next time you open a "create" form, your green button says "Save and add new item" and "Save and exit" is now in the dropdown.

I don't know :-) Food for thought.

[AurelDragut]

Yeah, i like the idea of the dropdown on the submit button. So if i choose one of the dropdown options it will remain as default until i choose something else from the dropdown? I guess that would mean an extra setting to keep this stored (or just a cookie).

[OwenMelbz]

This PR adds the users choice into the session so it can persist across the session, so can continue to use that.

However doesn't that drop down method add a 3rd click to the user journey?

1. Open dropdown
2. select the option
3. Click the button?

[AurelDragut]

Yes, that's right, Owen, but that happens only when the user changes the option.
Also, when it comes to the three buttons solution, you can use the tabIndex attribute to change the order in which the buttons are accessed by the tab key. It's just that now i can't figure out the best way to do that (i mean to change and store the tabindex order based on the last button that was clicked).

[tabacitu]

@OwenMelbz it adds 2 clicks, not 3. You don't need to select a dropdown option then click the button, you'd just click the option and the form submits - check out boostrap split button dropdowns here. But it's still 2 clicks away, yeah... Can't say I like that too much either :-) I do think it's a better UX than having 4 buttons and needing to decide between them, though. As a user, that's pretty scarry.

Hmm... Tough call :-)

Sideissue 1:
I remembered why I opted to make this a radio, instead of multiple buttons. In some languages you can't translate the buttons in such a short space. So the buttons would be pretty large. Example:

• English - [Save and exit] [Save and edit] [Save and add new] [Cancel]
• Romanian - [Salveaza apoi iesi] [Salveaza apoi editeaza] [Salveaza apoi adauga o noua intrare] [Anuleaza]
• French - [Ajouter et sortie] [Ajouter et editer] [Ajouter et insérer un nouvel élément] [Annuler]

(not 100% sure about this, my French is very rusty)
Keep this in mind too when thinking about this.

Sideissue 2:
Not to digress too much from the issue at hand (the interface), but question - would it be more intuitive to:

• "remember" the save option for all CRUDs, not just the current one;

• show an "info" notification bubble along the "success" one, saying

  'Save and add another item' is now default on Add forms.
  You can change this by picking another option in the Save dropdown next time you add an entry.

• "remember" the option for a long time, by storing it in a cookie;

? Or would it be exactly the opposite and confuse people (too persistent)?

[AurelDragut]

On Sideissue 1 you made them too long:

English - [Save] [Save and Edit] [Save and New] [Cancel]
Romanian - [Salveaza] [Salveaza si Editeaza] [Salveaza si Adauga] [Anuleaza]
French - [Ajouter et sortie] [Ajouter et editer] [Ajouter et insérer] [Annuler]

phrase "new/o noua intrare/un nouvel élément" seems to me quite obvious... Don't you agree?

Sideissue 2 sounds good... i think.

[OwenMelbz]

@tabacitu had any more thoughts on this? I've got a week off this week so got some spare time to dig through some of these issues

[tabacitu]

I still think the best option here is this one:

I believe this fixes all the issues we've rased, if we also:

• have a config option in the config file, say:

  "default_redirect_after_save" => 'save_and_exit' // options: save_and_exit, save_and_edit, save_and_add

• after something else is chosen in the dropdown button, when the session is updated, we also trigger a notification bubble (info) telling the user something like:

Save button updated.
Add/edit forms will now "Save and exit" by default.

I think this is an option everyone can get onboard with, right?

Cheers!

[OwenMelbz]

@tabacitu I've updated the last lot of changes, it got a little more advance than expecting with the fact its no longer simple checkboxes, so I've added a new trait to handle this so users can customise it easier if they like in their controllers, I dont think its completely backwards compatible change, but it should be fine for most use cases!

Give it a whirl! (I tried using the old translations, but they didnt suite the new wording, so i've added new ones, either way, let me know!

[OwenMelbz]

@tabacitu I'm gonna poke you for this one as our MD actually asked when this was going to be implemented :P

[tabacitu]

Ok, making this a priority. It'll be done today or this weekend.

Cheers!

[OwenMelbz]

How happy with this solution you think?

[tabacitu]

I'' very happy with the solution :-) I'm having trouble with the fact that it's a breaking change, though. For every breaking change, we need to

• bump the minor version
• write an upgrade guide
• notify everyone to update their apps, if they want the feature.

And that's a drag for everyone, to update. I think it makes sense to bundle this feature and all other braking changes in the next major release, in a few weeks, which will come with multilanguage cruds.

It will seem less work to do it all at once, more people will upgrade because they want one feature or the other and it would certainly make the package seem more stable.

What do you think? Makes sense?

[OwenMelbz]

Yup good with me :)

[tabacitu]

Great to hear that! I've made a new branch, 3.2, and I've pulled this in. Any new features we need to put in 3.2, we can.

Cheers!