The admin sidebar was built with a lot of compromises. I am still not very happy that it can be disabled, but that’s another forum post. One thing that bothers me still is that we ended up not adding it to the site index and app index pages. From my unreliable memory this is because it would just duplicate what the index does. I think this is a good thing. Having multiple options to move around a site (nav bar, body links, breadcrumbs, site map, etc.) is very useful (and an accessibility criterion). It’s also not redundant on the app index because it also shows models not in the current app.
I think there is a bit of work involved to do this, especially to make sure all models are in the sidebar on the app list page, but I think nothing too difficult.
Not having this has led to tickets like 34044, which to me feels like more of a hack than a feature. I personally don’t really like having the filter work one way for some pages, but a totally different way for other pages, because of (what I believe is) a bad decision that I agreed to at the time and accept my own contribution to.
When I say “almost” in the title, we of course shouldn’t have it for pages where you’re not logged in
Not necessarily, though I can say that any modernised admin would have the sidebar on every page.
One thing I also forgot to mention is that having the sidebar on the index page in particular frees up the main content of the page to have other info on it. Perhaps some metrics. Something user-defined most likely but just having the ability to do that without breaking your navigation or having to compromise by having both nav and whatever else you need there would make life easier when doing something like this.
I’m in favor of this idea. For the index page’s main content, besides metrics (where would this come from?), we could include the existing “recent actions” list.
What would be the plan for the Add/Change links? The index page has both, while the sidebar has only Add. As a Django (admin) user, I gotta confess that I haven’t used those . Considering that the Change pencil-link takes the user to the same page as clicking on the model’s name, I think it’s OK to drop it.
(As a side note, I think that a “Change” action next to a model name should take the user to a page to change model details (which does not exist, I know), not to a model instances list page.)
I am the one currently working on ticket 34044 I also think this is a good idea. I had the concern of redundancy at index page but seeing main content put to other good use is great.
Perhaps I was a bit unclear, I don’t think we should do anything here ourselves but rather document a user overriding the main area of the page and adding context to do whatever they want.
Indeed the change link on the index is redundant, that’s why it was removed from the navbar, to save space.
For now we probably need to keep the model list on those pages as well as the sidebar can still be disabled. In the future, who knows.
OH I was very excited about the idea of having some default content in the main area, even if minimal. I would suggest adding (by default, but overrideable) a (perhaps) extended view of the “recent actions” and maybe a list of app names only? While the sidebar does list the apps, if an app has a long list of models, and/or there is a lot of apps, many apps names are not visible, so I think that a list of apps could be handy in the admin landing page.
I see Carlton cc-ed me and I never replied – Yes please! Yes, I think this would be an excellent change independently of other ways to modernise the admin. For the accessibility reasons you mentioned Tom (see SC 3.2.3 Consistent Navigation, SC 2.4.5 Multiple Ways). And just general UX - consistency of where navigation elements are placed.
As far as the index, I like this idea of an extended “recent actions” list. Could just start with the current list but have a datetime / relative time for each. I think the sidebar move will be valuable in its own right without also having to rework those index views, but afterwards they’d be great places to add different means of navigation.
I really like all the discussions that have taken place here.
I also don’t understand why the sidebar is offered as an optional feature.
If the sidebar were to fully replace the functions of the index and app index pages, we could make those pages hold more diverse information.
Personally, I’m curious to see what it would look like if the metrics Tom mentioned were actually implemented. Of course, since features like metrics would likely require a lot of code, they still feel somewhat far off.
Anyway, while using the Django admin, I often felt that the index and app index pages were rather empty. Of course, this depends on how much the user customizes them, but I’ve always thought it would be nice if these pages were modernized.
Perhaps this work could serve as the foundation for that modernization.
So I do think it looks strange in the admin site index page that the content is essentially duplicated (other than we gain a search bar).
That folks can override the content area is a fair point but the admin sidebar is not visible at all on mobile. If folks were to override the add index content area, they would find that they loose all ability to navigate on mobile.
This might get addressed by #36529 (Improvement of the filter and model selection sidebar on the admin changelist page for mobile screens.) – Django, but I would almost say that that needs to be fixed before we can progress with this.
Fix the current situation on mobile. Probably this is by just not being able to see any content while the navbar is open and having it take the full width. Not sure how easy this is.
(I’m not sure about how it’s properly named but) Turn it into a slide-over navbar rather than a pushy navbar. This is better for some reasons, we could remove the code for holding the state in local storage for example. However it’s probably worse for some people that are used to how it works. But if I was to rewrite it this is probably what I’d do.
A hybrid approach might be better - pushy on desktop, collapses to hamburger (or so) on mobile, can be clicked to display over the content. I think this covers most people’s needs. But the technical lift might be a bit harder (again, not really looked into it in a long time).
Work isn’t finished yet, but in PR I chose the first approach.
I think it’s good to remember the state of the navigation bar, as we do now.
On small screens like mobile, I feel it’s cleaner to cover the entire content rather than just part of it.
(I don’t think there’s a definitive answer, as it depends on personal preference.)
Additionally, I would like to design the side navigation bar like this.
(Claude side navigation bar)
I expect that the data in the header will probably need to be moved, but since this is part of a separate modernization effort, I’m not sure if it will be accepted.
However, if design improvements can also be made, it feels like a task that will need to be addressed at some point.
(This is unrelated to this discussion, but I wanted to mention it.)