Active
Project:
Drupal core
Version:
main
Component:
base system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
28 Mar 2008 at 10:56 UTC
Updated:
11 Jun 2018 at 12:13 UTC
Jump to comment: Most recent
Another thing that came up from formal usability testing was form redirects.
For example. Check what happens when you submit the following forms:
node/add
admin/user/user/create
admin/content/taxonomy/1/add/term
- any other form which adds or edits stuff
Some show you what you just added, some take you back to the form to add another one.
Testing was inconclusive about which is preferred. One person adding a user wasn't sure they'd actually created the user. One person adding three taxonomy terms was really happy they could add another term straight after submitting the first one.
Either way, we should probably try to standardise this a bit. Views 1 has a "save and edit" button, which I tend to use a lot (although probably won't need now there's live previews in views 2), I've also seen "save and add another" buttons somewhere. Another CMS I've had to use has separate "save" and "publish" buttons, which is a whole different issue, but we need something that's both predictable and can also be extended.
Overall, I'd much rather less clicks for repetitive tasks (even if it means an extra button), than the "save, find in a list, click a link just to edit a typo" approach, but otherwise I don't have many ideas on this. If I get time later, I'll have a look through core to see what the various behaviours are.
Comments
Comment #1
Bojhan commentedCatch, are there any guesses on how many users repeat a task (contextually)? We could just display the changes, and get a related link up there (wordpress does that slightly).
Comment #2
catchNot as far as I know. When you say "just display the changes" do you mean redirect back to the form, but have the changes in a drupal_set_message?
Another thing to consider - the modules, blocks and IP address forms also go back to themselves, in this case the settings and the form are the same page.
Comment #3
Bojhan commentedI do mean redirect back to the form, but have the changes in a drupal_set_message.
If the usual behaviour in Drupal is to go back to the form we should consider approaching it as a standard. However in context, when you create a page, usually you don't intend to create another page and want to see the page you created. So I think you should approach this standard with quite some context.
Comment #4
catchSince node creation is a 'non-admin' task, I think we could make an exception. Similarly, editing nodes and user account information might want to go to the view page after submission too. Better DSMs, maybe with links to stuff that's been created (i.e. add user form), ought to cover the feedback aspect. So I guess what's left is working out which forms currently redirect to where.
Comment #5
Bojhan commentedI just went trough quite a lot, I put a * to where I found the feedback aspect confusing (ie not going to the item in the list, or the feedback line not saying what changed - no feedback) or the interaction having weird workflow.
View page after submission, pretty much means either going to the actual created node(if this applies) or the admin list view for taxonomy for example.
I put Drupal Set Message, where you get redirected to the form.
Content Management
Content Type > View page after submission
Post Settings > Drupal Set Message*
RSS publishing > Drupal Set Message*
Taxonomy
Add vocabulary > View page after submission
Edit vocabulary > View page after submission*
Add term > Drupal Set Message*
Site Building
Blocks
Add Blocks > View page after submission*
Edit Block > View page after submission*
Menus
Add Menu >View page after submission (not Menus but the added menu)*
Add item > View page after submission (not Menus but the added menu)
Edit Menu > View page after submission (not Menus but the added menu)*
Themes
Configure > View page after submission*
User Management
Acces Rules
Add Rule > View page after submission
Check Rules > Drupal set message*
Roles (Completely other interface pattern?)
Add Role > Drupal set message*
Edit Role > Drupal set message*
User Settings > Drupal set message
This is as far as I got for today.
Comment #6
catch@Bojhan - it looks like you're going through Drupal 6. For a start, access rules was removed from core a few weeks ago, and some other administration may already have changed too, so would be better to do this with D7.
Comment #7
Bojhan commentedI will cross check. Most forms seem to supply no actual feedback, only say stuff as : it has changed, not saying what has changed.
Comment #8
kika commentedComment #9
alexanderpas commentedi think the solution is multiple buttons, depending on the situation...
"save and return to overview" will take you back to the overview after saving the current input.
"save and view item" will take you to the view of the item.
"save and add another" will take you back to the form after saving the current input.
ofcourse, every option gives a (green) message confirming the action succeeded
Comment #10
Bojhan commentedAlexander Pas, although adding this function obviously might seem the best way to handle this issue. It might be more considerate to avoid anything that adds functions to a form unless its really necessary. Because almost all the buttons you suggested are highly situational(especially the last one). Giving people this options, breaks with conventions in normal form use and gives them another choice, if we make the choice for them with the best intend in mind I think the forms will do just fine. Because for most of the forms we are working with we can guess whether they want to see the item or return to overview.
Comment #11
alexanderpas commentedexactly those points that are problematic require that solution...
the points that have an obvious destination don't need this functionality...
remember... usability IS important!
however... the core solution is to ALWAYS give FEEDBACK after submitting a form... (drupal_set_message)
maybe that needs to have an additional state... confirmation!
Comment #12
Bojhan commentedWe found this in Baltimore as well, however it wasn't conciderd a really big problem.
Comment #13
Tor Arne Thune commentedStill a valid issue after the release of 7.0. Moving to 8.x.
Comment #14
jhedstrom#210974: Add a new node link after submitting a node seems related. The approach there would strike a compromise between redirecting to new content, or back to the add new content page.
Comment #20
pieterdcSo many years later, these inconsistencies still exist.
While some consider this non critical, there's no denying in that it's very confusing for anyone using the UI.
These are a bunch of different form destinations I noticed while quickly testing current Drupal 8.6.x:
Go back to overview
Go back to parent overview
Stay on the edit form
Go back to creating another entity of the same type
Go to frontend view of entity
So the question from this issue remains:
This issue would benefit from someone reading through all the comments, summarize and add feedback to that.
Comment #21
catch