#33728: Tab order should match visual order for admin model forms’ submit
buttons
-------------------------------------+-------------------------------------
Reporter: Thibaud Colas | Owner: Alexander
Type: | Freyr Lúðvíksson
Cleanup/optimization | Status: closed
Component: contrib.admin | Version: dev
Severity: Normal | Resolution: fixed
Keywords: accessibility, | Triage Stage: Ready for
keyboard, ux | checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 1
-------------------------------------+-------------------------------------
Comment (by awiebe):
Replying to [comment:3 Mariusz Felisiak]:
> I agree that it's confusing. The situation is even more complicate on
edit views where we also have a `Delete` button. Moreover we need to
remember about RTL languages. I'd reorder the buttons as follows:
> - LTR: `Save`, `Save and add another`, `Save and continue editing`,
`Delete`,
> - RTL: `Delete`, `Save and continue editing`, `Save and add another`,
`Save`,
> maybe with a small visual space before/after `Delete` (but I'm not a
designer).
I believe this is incorrect, because a delete button should not be in the
position of the confirm button in every other GUI paradigm ever. I am
disappointed as a designer and a programmer in how this was handled.
(1)In LTR Paradigms
1. Cancel is on the **right** if the resulting action could be considered
**detrimental if performed accidentally**
2. Confirm is on the right if this is normally desirable and easy to undo
if performed in error.
3. The ''auxiliary'' and/or ''destructive'' option is absolutely **NEVER
EVER** in the right most slot, i.e. the usual place of the confirm button.
4. The "auxiliary action" is opposite the main actions intentionally this
is why "delete" was on the left, opposite where confirm buttons are in
every program.
5. The save button being the most common action found itself right-most,
if you disagree with this placement, add an option, but don't just change
it on a whim.
(2)An experimental change should not modify a legacy behaviour without the
consent of the end-user. This is more often cited in in APIs but is just
as relevant in UI.
1. If you want to experiment with a new layout then, you should make it an
option first, do not immediately roll it into a release.
2. If the option should be off by default. If in a later version you turn
it on by default because the community generally accepts it as good, you
should still leave it in as an option for legacy customers who do not want
it.
Please remedy the situation by adding something to the effect of
{{{
class ModelAdmin:
class Meta:
action_button_placement="classic" # or "reversed"
#settings.py
DJANGO_ADMIN=
{
"action_button_layout":"classic"
}
}}}
For **reference** I have attached a **google image result for confirm
cancel dialogs**. To show typical orderings, which do not include the one
which was mainlined.
--
Ticket URL: <https://code.djangoproject.com/ticket/33728#comment:10>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/010701898f54db5b-f63eb45a-f28e-4f3e-9181-88bb4406ca67-000000%40eu-central-1.amazonses.com.
