Return to fields page on field save

[neotoxic]

After creating or editing a field, the user clicks Save, the field data is saved and the user remains on the same field editing screen. As clicking Save is indicative of the user completing the tasks on that page I would like to suggest that moving the user to the parent 'processwire/setup/field/' page so that they can select the next field the want to work with would improve usability.

[Jim Yost]

I agree, it is a little frustrating when you are adding more than one field in a row.

[Adam Kiss]

Also, you are not first to notice that. Unfortunately, thanks to tiring conversations about this feature, we know that this is 50/50 behavior – some prefer to get back to list of fields (or pages after page save, templates after template save), some prefer to be back at edit.

Some would actually love to be able go straight to new page (again, the same in other data where applies) and view the frontend.

But since it's 50/50, those of us who love to get back to lists have suck it up (at least until somebody doesn't come up with better system with polished details. ahum ahum

[ryan]

I'm one of those people that likes to see my changes reflected after saving, as a confirmation to my mind of what I just did and making sure that's what I wanted to do. It drives me nuts to use software where I'm returned to a list, only to have to wade through the list and go back and edit it again – I won't use a software like that. So this is the planned behavior for the software, and not something I would call an unpolished detail. Actually I think the software is pretty polished relative to it's age (?). That's not to say there isn't plenty of room for improvement, but this is a new project and I'm proud of where we are at this stage. But if there are any details people want to modify, my hope is that they will and submit the change so we can include it in the core.

If you grab the latest commit, you can now configure this behavior for the Process > Fields module. To change the behavior, to to Modules > Process > Fields. Click the box that says "return to list after save". Now whenever you save a Field it will return you to the list. The only exception is the first time you create a field, the second screen is mandatory because it often contains configurable details of the field that aren't on the first 'add' screen.

If this is desirable to people, I'll add the same option to other Process modules.

[apeisa]

I'm one of those people that likes to see my changes reflected after saving, as a confirmation to my mind of what I just did and making sure that's what I wanted to do. ... So this is the planned behavior for the software, and not something I would call an unpolished detail. Actually I think the software is pretty polished relative to it's age (?). That's not to say there isn't plenty of room for improvement, but this is a new project and I'm proud of where we are at this stage.

I myself also prefer to see edited results again, just to be sure that everything is fine. I honestly think that ProcessWire is actually much more polished than most of the open source web apps - and not just young ones, but all apps in general. It is very polished in the outside (lot's of little details thought), but the polish that it has under the hood is amazing. Very solid foundation to build upon! Also - documentation is already in much better shape than most of the open source projects has.  You really should be proud Ryan, and we are very pleased to be part of this in early stages.

If you grab the latest commit, you can now configure this behavior for the Process > Fields module. To change the behavior, to to Modules > Process > Fields. Click the box that says "return to list after save".

I am not speaking about this one, but I think Ryan you should be a little bit dictator on what comes to core features & settings. If everything is easily configurable - it just leads to larger codebase and many ways to achieve same thing. And that is very expensive in the long run: there is no clear best practices and when troubleshooting, we have to always check "what settings you use on your module x?" etc. Also, when we develop modules etc, then it is also harder if there is very little things that we can know for sure to work in certain way.

People always - and I do mean everyone - want to get software in the way they like and have always done. It is understandable. But it's not bad thing to have many conventions over configuration and expect people to learn little bit of those conventions. In many cases it just makes sense.

[ryan]

You really should be proud Ryan, and we are very pleased to be part of this in early stages.

Thanks! I appreciate that!

I am not speaking about this one, but I think Ryan you should be a little bit dictator on what comes to core features & settings.

I definitely agree with what you are saying and that's the strategy I will be taking. The goal is to leave off any features that would be used on only 30% of sites (or by 30% of people). Or, if they are included, then delegate them to optional modules. I'm also thinking that number should become 40% or higher after some time.

This particular feature is part of a module (though not an optional one). I'm much more particular about what goes in the core, where I'd be much less likely to compromise on something like this. In this case, it appears to be a 50/50 preference thing (I think Adam is right on this). And if the other 50% feels as strongly about wanting to go back to the list after editing a field, as I do about not wanting to to that, then I figure it's a worthwhile compromise... It was easy to do, and didn't result any significant amount of additional code. Plus, we're a small group of people here and if this was bothering 3 people, I figure that counts for a lot. I'm just glad I'm not the only one that likes to stay in the editor after saving!

[Adam Kiss]

I'm just glad I'm not the only one that likes to stay in the editor after saving!

With Antti expresing his opinion in favor of returning to editor, that makes two of you already

I believe it ends right there actually

[apeisa]

With Antti expresing his opinion in favor of returning to editor, that makes two of you already

I believe it ends right there actually

We will see! (starts creating fake accounts who all like to stay in editor...)

[Adam Kiss]

We will see! (starts creating fake accounts who all like to stay in editor...)

Unless you wake up without working internet connection one day! MUHAHAHA 8)

[apeisa]

You cut Finland out of the internet? No!!! Evil plan, mr. Adam, evil!

[neotoxic]

It would seem that at the point of completing the form there are two types of actions that a use might legitimately want to choose, and these are common computing terms.

Save. | Save and close.

To provide optimal usability why no show two buttons and allow the user to select the action that suits there workflow.

As a side note, I am becoming a huge fan of ProcessWire and have a great deal of faith in the development philosophy.

[Adam Kiss]

I believe that 'add another button' isn't always the best solution. On a different note, hwo would you distinguish (as in color? size?) between the two? how would you position them.

In this case, those are not easy questions, since it's 50-50 in terms of which do people prefer. You might end up like github with 'comment and close' button leading to closing many questions by novice users.

[ryan]

I think you are both right. Having the two buttons would be great for people that routinely need to do both. But it's also true that it's one more thing to think about. On the page editor, it might be nice to have a collapsed field at the bottom that says "After Save...", and then radio buttons that let you choose:

1. Continue editing

2. View page

3. Return to List

4. Create new sibling page

So you wouldn't see those options unless you clicked on the "After Save..." label to open it up. A checkbox would let it optionally keep your setting.

This is kind of a power-user thing, so this functionality would be in an optional add-on module rather than something built into the core.

Personally I would only use #1 and #4, but it sounds like #2 and #3 would be popular with other people too.

For other types of editors (not page editor) it would be similar, but without option #2 of course.

[benbyf]

I know you guys have already talked about this a lot, but I use wolf CMS and Frog CMS and just started using processwire and I love having both:

save and close (back to list)

save and continue editing

both buttons I use all the time. Not sure how useful a 'save and create child button' would be as I would always want to check that the current page works before creating a child.

Cheers

[ryan]

I think you are right about having both buttons. There are actually several different actions you might want to take after saving a page. These are the ones I could have used at some time or another:

- Save and continue editing (like now)

- Save and close (return to list)

- Save and view

- Save draft and preview

- Save and add another sibling (useful when you need to add a bunch of select options)

I'm thinking we'll keep the default with as few buttons as possible (perhaps only save, to keep things simple), but work towards making the system configurable so that you can control what buttons you have (whether by modules like Adam's, built-in config options, or a collapsed field below the buttons where you can adjust and save your own setting).

[Adam Kiss]

I'm thinking that working towards one configurable module might be the best option. I'm actually looking forward to implement some of these actions in my List After Save plugin, along with some quick link in the menu, so users can switch their setting dynamically without browsing 10 different screens – imagine this situation:

your default setting is viewing content immediately after saving it. But you know you just have to do update of 20+ pages, so you might want to do: click to edit settings, change settings, save, add 20 pages, revert settings.

Actually, I might incorporate some sort of this in the alpha version of the new admin UI.

[abu]

I think what's relevant UX-wise in the field / page creation interface is that it is a two-steps process - set the basic details and then optionally fill in the advanced settings / page contents - necessarily since what's presented in the second step depends upon the type / template chosen.

IMHO this necessity contributes to make it hard to choose the "best" default behaviour, and at the same time it could be used positively to present an UI that enables multiple usage patterns without compromising leanness.

IE, if the basic details for a new field could be submitted dinamically without reloading the page (dunno if it's easy or desiderable to implement), you could then change the "submit" button into a "submitted" text, and show, say, "advanced settings" and "back to list" buttons next to it.

This could retaing the ability to immediately check the details entered while allowing both usage patterns without requiring users to set preferences (it would always cost two clicks instead of possibly one, but it would offer flexibility on the fly in exchange).

Same thing for the page creation interface, and you could have some sort of "more..." dropdown for more exotic power user actions.

Just my 2 cents.