Modernizing the Debug Toolbar UI

[federicobond]

Hi! I am a longtime user of the Django Debug Toolbar and an open-source contributor to several Python packages, including django-openfeature, which implements a custom panel for feature flags powered by OpenFeature.

Over the years, the Debug Toolbar has been an invaluable tool for me. Still, some of its functionality and design choices have not aged as well as others. When I compare it to similar offerings like the Vercel Toolbar or the Astro Dev Toolbar, I can’t help but feel that there’s room for improvement.

Besides working on a more modern look, I’ve noticed a few areas where enhancements could make a big difference. For example:

• Certain panels, like the Cache and Templates panel, could benefit from UI upgrades (I have further ideas on this).
• Others, such as the Headers panel, might be redundant given modern browser tools.
• There’s potential to introduce new panels, such as an Accessibility Audit panel, that could be a valuable addition to the default setup.

I’d like to gauge community interest in exploring updates to the UI and layout of the built-in panels. If there’s enthusiasm for this, I’d love to discuss the best way to approach these changes.

The Django Debug Toolbar is a workhorse of Django app development, and I believe we have a great opportunity to improve the developer experience for the Django community.

[tim-schilling]

I'm in favor of improving the UI. I think an accessibility panel would be neat to include too.

I would recommend whatever is done, that it's done incrementally.

[matthiask]

Thanks! I totally agree with Tim, let's improve things and let's do it incrementally.

That being said, if you have a larger vision feel free to discuss that as well.

[luanfonceca]

Hi folks, in the last couple of days, I've been working on a UI redesign for the DJDT.

TLDR: Here's my POC on a redesign, maintaining the panels but rethinking their structure and layout: https://django-debug-toolbar-redesign.onrender.com

And my thought process was:

1. Pick a sane Typography and UI with just a few components like Buttons, Tables, and headings.
2. Make a POC design system with visuals I was thinking of using: https://play.tailwindcss.com/8Wa17B3E5i
3. The final redesign is not a one-to-one view of the design system, as I'm no designer. So, when I laid out the elements on the page with data, I felt the need to tweak a few of them and even add new ones.

At this point, I tried mocking the DJDT templates with hardcoded/mocked data, but to be honest, it was taking so long that it was easier to copy the entire templates and assets folders from the package, install them locally in a barebone Django project, and start changing them.

This took about 20 hours of my last week, but I'm on a good point for showing this to you all. As that was meant to be a POC, I can't create a whole PR updating the templates and styles.

I aim to validate my ideas, improve some UI aspects, and eventually decide on a feasible plan for this migration.
The UI was done in Tailwind, which I know a lot about. I can steal from plenty of free resources and generative UI prototyping tools, such as Shadcn, Lovable, and v0, that I can steal from, which speed up the UI prototypes even further.

I know this is a lot and kind of out of the blue, but I would appreciate any feedback and ideas about it. Also, let me know if sharing the whole project codebase would be helpful right now. If it's easier, we can keep using the play.tailwindcss.com environment to create more prototypes, change colors, or modify the overall layout.

I will also attach some screenshots just in case you don't really want to poke around the testing app - but I highly recommend you do so if you're interested.

Thanks!

Let me know if there's anything else I can do to help this project progress. Right now, I'm focusing my free time on working on Django open-source packages—usually UI stuff, which I enjoy a lot, and the whole Django ecosystem needs that.

[tim-schilling]

At some point we could ask the accessibility team if anyone has some bandwidth to take a look and help direct some things.

Edit: Sorry, this is an excellent start! I enjoy the improvements on the collapsible, the callout for the warning and the general layout. Thank you for your efforts!

[luanfonceca]

At some point we could ask the accessibility team if anyone has some bandwidth to take a look and help direct some things.

I'm sure there are areas of improvement in color contrast in the dark mode and other places where I haven't had the chance to go further, so I appreciate any help from them.

I'm glad you like that o/

[robhudson]

I wanted to share an idea that could be possible in the near future... that is a Django debug toolbar without "injecting" a toolbar. With the serializable branch plus #2048 it's possible to no longer have to inject any HTML onto the Django app, but go to a separate URL to get to the debug pages.

DjDT already has the /__debug__/ URL, so likely somewhere under that. I can imagine 2 pages:

1. The "index" page -- a list view of the historical requests that have been logged. Basically the history panel we have now.
2. The "detail" page being the toolbar on the current request as it is now.

Maybe the "toolbar" in some form is still there, but clicking it jumps you straight to the detail page for the current request? Could be anything but the serialized data plus the API unlock a lot of potential ways to show the data.

I just wanted to share the idea here in case it impacts the thoughts on your design.

[luanfonceca]

To achieve that, I think we just need a template view and an always-open mode for the panels (where users cannot close the toolbar itself).

Because the toolbar with a panel open already uses the full page dimensions, if we turn off the closing feature, it will work just like an entire page.