Request for Vote: Admin Keyboard Shortcuts and Command Palette

Django Internals
1

Hi folks,

The proposal to add keyboard shortcuts and command palette in the admin had been accepted as part of GSoC. I need your input to move it forward.

Here’s a summary of previous efforts. Ticket#16521 about keyboard shortcuts was marked as accepted in 2012. A simple patch followed 11 years later, but the author was directed to forum for community discussion. Apparently, there had been slight interest shown and no one opposed the idea. @tom developed an experimental package: django-admin-keyboard-shortcuts with plans to merge into core. The idea was again presented at different occasions: DjangoCon Talk and recently GSoC.

At this stage I believe there is a general consensus in favor, but the community has yet to decide which shortcuts should be set as default. django-admin-keyboard-shortcuts has a list of supported shortcuts. I’d encourage you to propose new shortcuts and/or share feedback about existing ones regarding their usability.

We believe one of the main goals is to quickly search model instances from anywhere across admin. If enough community interest is shown, the search could be extended into a full-fledged command palette similar to kbar.

I’d also want to check with @steering_council whether we require DEP for keyboard shortcuts or command palette.
Additionally, we want a combobox widget (supporting pagination and remote data source) for the search. The select2 library being used by existing autocomplete widget in admin meets those requirements, however it is tightly coupled with jQuery. At this stage we wonder if it would be a good idea to continue writing select2+jQuery code, propose a no-jQuery select2 replacement or use vanilla JS. If you could help decide such dependencies early, we could continue working on instance search and begin migrating core (if required) while waiting for additional feedback.

Thanks

3 Likes
2

Hi @khanxmetu, thanks for raising this.

My only real concern here is whether the command palette is sufficiently stable to get tied to Django’s long-release cycle and stability guarantees? That is, are we confident that we’re not going to need to make numerous/rapid adjustments to it once we get people using it? The answer might be Yes there, but how battle tested is this? (I don’t know, hence asking.)

If we’re not confident then one approach would be to promote the package but still keep it separate, in order to allow continued iteration.

One idea there would be pip extras. This would be new for us, but I think we’ll likely need to do something similar for the db-tasks backend, which faces the same challenge. What goes for one could go for all. In general, it would be nice to have some story here, even if pip extras isn’t it.

Additionally, we want a combobox widget …

Can I point to this: Usage Guide - django-tomselect documentation by @jacklinke

… yet to decide which shortcuts should be set as default …

I’m imagining some config file? :thinking: (TOML or something?)
I’d offer a small set of defaults and a how-to on adding your own.
The jump to model example is probably the most obvious.

But those points are secondary to the stability question.

1 Like
3

Could we approach this more as, do we think this base set is complete where it won’t need to change and that any additions will be easily customizable per project?

I don’t see this doing well as a separate package and would need to be adopted to help shift community opinion.

Regarding pip extras. If we had pip extras, it would more likely be a part of the admin extra. Not on its own.

Maybe the inclusion of this is a good reason for us to revive the experimental DEP?

4

It’s not just about completeness but whether it’s largely bug free. Are there likely to be lots of edge-cases that haven’t been exposed yet, requiring numerous/rapid fixes? (IDK but we’re talking about browsers here right?)

Maybe the inclusion of this is a good reason for us to revive the experimental DEP?

The experimental APIs DEP allowed only changes without deprecation at the next .0 release. (So something introduced in 6.0 could be changed in 7.0.) It’s not experimental in the sense that might be needed here. (Two years to make an API change because we realised it was wrong isn’t going to fly.)

To quote that DEP:

… to have got as far as an experimental feature in the main codebase it should have passed a certain quality threshold and the DEP process and already be somewhat fully-formed.

It’s not a licence to include WIP experiments as part of Django itself.[1]

I don’t see this doing well as a separate package and would need to be adopted to help shift community opinion.

Bar adoption, the only rational given for needing this in core is potential template blocks needed to be added. Well, blocks can be added.

In reference to adoption, this looks like the perfect test case for solving the How do we promote a package without it having to be merged to core? that we bang our head on again and again and again. I’d suggest we take the opportunity to address it, rather than sidestep it. (We need to do so at some point.)

Of course, that whole discussion is conditional on the assumption that the package is essentially not battle tested. The repo has this warning…

…very hacky and really just a proof of concept…

Which implies that it would be a concern.

On the positive side, if it’s a young idea, it wants to be free of the eight-month release cycle and stability policy so that it can evolve. This is something to embrace.

  1. The experimental APIs DEP would be perfect for django-tasks though. We’re pretty sure the API for deferring tasks is correct, but who’s to say we won’t want to bring in a change once real-world usage scales up? ↩︎

1 Like
5

Yes, there will be bugs, but I think it’s unfair to assume that the solution would be unstable to the point of “requiring numerous/rapid fixes”. Code won’t be merged in unless it looks good and appears to be well tested.

This explains our difference of opinions. I’m assuming this will be Django quality at the time of being merged.

6

:waving_hand: we discussed this in today’s accessibility team meeting, here’s our proposed approach:

  • The command palette will be better served with the DEP or new features treatment. It’s a solid concept, has a reasonable case to be a core feature, but requires more maturation of the concept / implementation (see previous messages).
  • Keyboard shortcuts are simple enough as a concept and fundamental enough to meet our accessibility requirements that we think we can proceed with a list of shortcuts + other aspects relevant for implementation.

@sage and I offered to help with that spec, that will be directly inspired by our experience implementing this in Wagtail, and our understanding of related requirements in the WCAG and ATAG standards. We think this is going to be simple in big part because those standards make it clear how and why to get shortcuts.

For anyone wanting to do their own research already, here are the relevant references in W3C standards that help determine which shortcuts to implement, and how to implement shortcuts:

7

Of course the code will look OK. No one is going to merge something that is obviously broken.

New ideas though often (always?) fail to account for whole ranges of use-cases. It’s only when you put them in front of people that those appear.

The whole point about develop it in a third-party package first is that it allows those use-cases to appear.

I contrast this with one of the other GSoC proposals we have, to merge template-partials into core. Template partials has been in a third-party package since Django 4.2. It’s gone a whole LTS cycle, with significant uptake, before we’ve even suggested merging it. Novel use-cases were indeed discovered, and addressed, quickly and quietly. That would not have been possible if instead we’d said this can’t be developed out of core. Of course it could.

My concern, and it’s only that, is that the command palette here is still at proof of concept stage and it has not had the exposure to reveal the things that haven’t been thought of yet.

If Tom wants to tell me, no it has all been thought of, then we can have that conversation. But minus that, we’d be wise to allow for unforeseen problems to reveal themselves.

8

That’s a fair expectation, but just to clarify: who would be responsible for ensuring that this meets “Django quality” at the point of merge?

Not to sound self-important, but in practice, that bar is usually reached with substantial involvement from the Fellows. Even when there is a strong push and commitment, it’s uncommon for a non-Fellow to carry a feature all the way through to that level of quality without significant support. So realistically, if this goes ahead, the task to ensure this meets “Django quality” would likely fall on the Fellows.

There are also practical considerations: this feature is mostly JavaScript (from what I can see in the repo, and this also seems untested so far?), and Fellows are not necessarily proficient in JavaScript. That adds an additional layer of difficulty in reviewing and maintaining it (now and in the mid/long term).

For these reasons, I would encourage to have this as a third party package, and/or go through the usual stages of the “new feature idea” kanban to identify maturity and maintainers.

9

@carltongibson and @nessita, I want to highlight this part of Thibaud’s comment.

The keyboard shortcuts aspect (not the command palette) may be more inline with a bug fix rather than a new feature because it’s attempting to bring Django inline with our accessibility standards.

@nessita I’m purposely ignoring the comment about our pipeline/bottleneck problems. I’m aware of them and I don’t feel like I have anything new to contribute to that discussion and continuing it wouldn’t be beneficial to this thread.

10

These would still be new features. They’ve never been supported right?

Keyboard shortcuts may well be less of a risk though. I think following @thibaudcolas’ suggestion to put this through the new feature pipeline is reasonable. No reason certainly parts of it can’t be advanced if suitably well defined. (Maybe the whole thing can be but it still can be the case that it would be better off iterating rapidly until the corners are worked out.) :person_shrugging:

11

This feature seems to have been paralyzed with feature creep. I think we should just merge the simplest solution that achieves adding shortcuts and iterate on that. I wrote a PR for exactly that years ago.

12

Thanks for the example there @michaelschem — I’d not seen that PR.

I think @thibaudcolas’ points show exactly why it is worth taking the time to specify this properly.

It doesn’t look like much of an ask to get some agreement on a list of shortcuts, and then make sure they’re both functioning cross-platform and accessible before we “just merge” anything. Django is a mature project with a slow release cycle. Taking the short amount of time to actually spec what’s being proposed is always going to be better than releasing something half-baked and then realising that it’s difficult to correct course.

@khanxmetu From my perspective, please write up something on the new-features board — breaking it up however you think best. I agree there’s a broad consensus to do something here, so we can advance it to the idea refinement phase quickly enough.

From there, it sounds like, keyboard shortcuts would be a first target with the full command palette second.

On that last, my question remains: is it a refined enough idea to target core, or should it evolve in a third party package in order to allow it to stabilise? (Note the emphasis.)

1 Like
13

Carlton, thanks for your input.

I think the accessibility team has a better reason aligned with their statement for wanting keyboard shortcuts merged to core than I could give. I think the question is whether such accessibility improvements belong to core or should be promoted as separate packages. I’d imagine most people find shortcuts as nice extras but not something they’d think first to add on their own, making adoption little difficult as @CodenameTim pointed.

I don’t have a strong reason to believe it would need rapid adjustments/fixes once merged. I expect most of the work needed is on client-side and there are many examples of keyboard shortcuts implemented in javascript ecosystem. Sure, the scope (e.g how much configurability is expected) could be made clear beforehand and tests could be written extensively.

For a full command palette, I think it makes sense to consider after keyboard shortcuts are worked. There is a concern of whether adding it would be redundant if shortcuts for the same commands would exist. I’m not entirely sure here myself, which is why I wanted to bring this up for discussion.

Those are just my two cents of course. I’ve opened up a proposal at new-features board for keyboard shortcuts as a next step: [Admin] Keyboard Shortcuts · Issue #34 · django/new-features · GitHub

1 Like
14

Here is the draft accessibility team spec based on the work of @tom and @khanxmetu: GSoC 2025: Keyboard shortcuts specification (still in internal review / drafting). This should fill some gaps in our shared understanding of which actions warrant shortcuts, how to assign keys / modifiers / combinations, and how to document available shortcuts.

I’ve also listed five shortcuts which have already been proposed and seem clearly warranted. They all rely on modifier keys so the implementation is simpler. There is room for more shortcuts though for each it’ll be essential to go through the suggested steps (check it’s warranted, confirm the behavior, decide a key assignment).

And talking about implementation, there is a bit of what I’d personally recommend, but goes well beyond the accessibility team’s remit:

  • A section about high-level decisions to be made
  • Proposed QA and review steps (at what stage to involve whom, what kinds of automated tests to write)

I’d recommend shelving the “command palette in core” concept for now, and any other shortcut concepts that rely on more UI than just a “available shortcuts” dialog. I think it’s very promising, as a core feature, to speed up even more of the admin actions. It also fits very well with how the Django admin is split across pluggable apps. See Nielsen Norman’s Accelerators Maximize Efficiency in User Interfaces for more on the rationale. It’s 10x more front-end code than keyboard shortcuts though. It’s a good challenge to modernize the Django admin and bring it much-needed UX improvements without risking much on backwards compatibility. But for the GSoC project at least – feels simpler to me to focus on keyboard shortcuts.

And if that’s easier than expected, you can work on the command palette either as a package or as a “new feature” proposal or DEP!

3 Likes
15

@carltongibson yea, I’m happy to add tests and make sure to make the necessary changes to meet the quality of a mature project, I just didn’t get much traction from forms so I stopped work on it.

If it’s any help to increase confidence in my PR, it’s been running in 5 fairly large Django projects for 4 years now across windows, mac, and chrome book with no issues. Not to say that we don’t need tests :smile: of course.

16

@khanxmetu An alternitive to Select2 without any dependency to jQuery is Tom Select. I’m using it in my formset library django-formset and never experienced any issues with it. Tom Select is written in modern JavaScript and has TypeScript bindings.

1 Like