Code

Opened 3 years ago

Closed 20 months ago

#15987 closed New feature (wontfix)

Add auto focus field select to admin class on add and change forms

Reported by: dom@… Owned by: nobody
Component: contrib.admin Version: 1.4
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX: yes

Description

Would be useful if the first item in the contrib.admin.templates.change_form.html would have the first item "focus()ed" by default.

Attachments (0)

Change History (8)

comment:1 Changed 3 years ago by aaugustin

  • Component changed from contrib.webdesign to contrib.admin
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to wontfix
  • Status changed from new to closed
  • Triage Stage changed from Unreviewed to Accepted

There is already some code that gives focus to the first field when appropriate:

http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/templates/admin/change_form.html#L66

This happens when creating a new item, but not when editing an existing item, which sounds reasonable.

comment:2 Changed 3 years ago by anonymous

ok :-/ I'm a little bit surprised though because I use the admin way more to change existing models than to create new ones. I feel like the auto-focus would make that process easier without any bad consequences. Can you elaborate a little bit on why it would be unreasonable to have an auto-focus on edit? (Especially since there's one for the new?) Thanks.

comment:3 Changed 3 years ago by aaugustin

  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Triage Stage changed from Accepted to Design decision needed

OK, maybe I've been too fast on this one. I'll mark it as DDN to let someone more qualified make a decision.

There is some code that clearly shows that someone thought about this problem. However, I wasn't there, so I don't how much thought was given, and I'm just guessing the intention.

I think the reason for auto-focusing only on new objects is that you are generally going to fill the fields from the beginning to the end when on new objects, but you are rather going to edit some random fields on existing objects.

comment:4 Changed 3 years ago by julien

  • Resolution set to wontfix
  • Status changed from reopened to closed

The purpose of auto-focusing on a field in a form is at least two-fold: to draw the user's attention to the task they have to accomplish (i.e. enter some data) and to save them time (no need to think about where to click or even touch the mouse). One typical example is on a login page, where it is clear that the main purpose is for the user to enter their credentials.

The Django admin being a generic tool for entering data, it is not possible for it to predict what the user is exactly supposed to do in every situation. The reason why there is an auto-focus in the add form is because it brings to the user's attention that the purpose of this page is to *enter* some data. In particular, the first field is auto-focused because there is a high chance that this field will be required. But this is still just a guess, which is assumed to be convenient in the great majority of cases.

However, the change form may have multiple purposes. It is sometimes used to *view* an item's detailed information, and often to modify *some* of its information (i.e. not necessarily the first one). Systematically auto-focusing on the first field would actually be confusing for the user, as it would draw their attention to the first field when what they might actually want to do is either view or modify *other* fields.

So, Django can't be smart enough to do this. If in your use case it makes sense to auto-focus on a given field in the change form, then you can easily do it by inserting a bit of javascript in a custom template.

comment:5 follow-up: Changed 3 years ago by anonymous

Thanks for the explanation. I don't totally agree about the "Focusing the first item would confuse users" but I do understand the thought behind it. However, I might add a suggestion: When going on the edit page, [tab] goes directly to the top right "documentation", then "change password", then "Log out".. which is why I felt like focusing the first item would make more sens as it will automatically make the [tab] smarter. i.e. first item is focused, [tab], second one is focused.

comment:6 in reply to: ↑ 5 Changed 3 years ago by julien

Replying to anonymous:

I might add a suggestion: When going on the edit page, [tab] goes directly to the top right "documentation", then "change password", then "Log out".. which is why I felt like focusing the first item would make more sens as it will automatically make the [tab] smarter. i.e. first item is focused, [tab], second one is focused.

Yes, this sounds like an accessibility issue. It's worth opening a new ticket specifically for this. To build your case, it'd be useful if you could review all admin pages (general dashboard, app dashboard, change form, etc) and make suggestions on how the TAB key should behave on each page.

comment:7 Changed 20 months ago by pkenjora@…

  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Summary changed from Auto focus on first item in admin view to Add auto focus field select to admin class on add and change forms
  • Triage Stage changed from Design decision needed to Unreviewed
  • UI/UX set
  • Version changed from 1.3 to 1.4

Why not add a programatic way of choosing the focus in the admin class, especially dynamic.

Use case: I want to take a user to an admin form and highlight the field to edit from another part of the admin. I have a long form with collapsed fields and instead of re-creating a view want to simply highlight the one field I want them to edit. Following the DRY principle. This would be extremely useful and make admin much more flexible without adding significant overhead to the code.

Re-Open as feature request?

comment:8 Changed 20 months ago by aaugustin

  • Resolution set to wontfix
  • Status changed from reopened to closed

Per our contributing guidelines, the preferred way to make a feature request is to write to the django-developers mailing list.

If your idea receives some support, then please open a new ticket (possibly with a link to this one).

To keep Trac manageable, we ask that you don't reopen tickets closed as wontfix by a core developer. Thanks for your understanding!

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.