Django Design

This page is a stub for collecting ideas and proposals for design-related changes to Django, specifically in the admin interface. Whenever possible, try to explain the practical benefits or a real-world use case for any proposals. If the idea relates to a Trac ticket that is already open, provide a reference the ticket.

Quick Hits

Small, focused changes that require some design work, but can be implemented within the existing admin design.

Collapse filters in changelist sidebar

Filter options take of a lot of vertical space in the changelist sidebar. This makes it difficult to use fields with lots of options as filters, or to use more than a few fields as filters. This could be solved by adding an option to display filters with more than a specified number of options as a select element instead of in a list. (WM)

Clarify the "select all" button in the batch change changelist UI

Currently, when you check the "select all" checkbox in a changelist view, it only selects all items on that page, not all instances of the model in question. This is very confusing, and also results in there being no possible way to apply an admin action to ALL model instances in one fell-swoop. At the very least, we need to make it clear that this doesn't do what you think it does, and I'd assert we should actually make it do what you think it does. (JC) Fixed in r12298 (jezdez)

UI elements that appear in new windows, but shouldn't

See ticket #11700. Basically, there are a handful of UI elements that are available when you're selecting a related item that shouldn't be. Having them there when they don't actually work in this context is definitely a confusing UI. (JC)

Better UI for raw keys

Raw Foreign Keys and Raw m2m widgets work, but provide poor UI feedback. Ticket #7028 proposes to fix this, and has a draft patch. #9976 also contains a patch.

Remove hardcoded stuff

There´s lots of unnecessary hardcoded elements with the Admin which makes it hard to customize. Some examples:
​http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/widgets.py#L126 (hardcoded image)
​http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/widgets.py#L95 (template/widget instead)
​http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/options.py#L650 (move to template)
​http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/widgets.py#L238 (hardcoded image, including width and height, this should go to CSS)
IMO, getting rid of almost all hardcoded elements is the base for a more extensible, customizable and easier to change/adapt interface (PK).

Big Ideas

Larger proposals that would require major changes to the current admin design, but could be considered for integration in an overall redesign.

Better UI for relationships

When selecting or creating related objects in the admin UI, you're often forced to open new windows, and if you need to create successive new items, you can quickly have four or five windows open at once. I know we can all agree this is a poor experience. I'm not proposing any solutions at this time, but there's definitely an issue, here. (JC)

Better UI for Generic relationships

Simply, there has to be a friendlier way to select an object through a generic relation. Even with Grappelli's auto-search, it's still entering numbers at random, or going a few views over to find the ID you're looking for. A possible solution is to populate a select box dynamically (in the same vein as Grappelli's auto-search?). (BV)

Dashboard "Placeholders"

Grappelli sets a very interesting precedent with regards to adding the concept of "bookmarks", etc. to the admin's index page. I've seen and used numerous projects (such as bartTC's ​django-memcached-status) that add elements to that page. Currently, they place themselves at the top of the app list. Given a few of these, the situation gets ugly fairly quickly. Even if Grappelli's concepts, like bookmarks, never make it to the admin, a block reserved for these types of widgets should be reserved. (BV)

Non-CRUD functionality

Apps should be able to register functionality outside of the typical "CRUD," for example status widgets, information displays, tasks that can be executed, etc. Somehow, apps should be able to extend the admin's functionality. (JC)

HTML/CSS Framework

In order to make the admin-interface customizable, flexible and extensible, a set of predefined HTML-blocks and styles are important. The HTML-structure should be defined horizontally (by using a grid as well as some flexible items) and vertically (by defining a set of nested items with a certain hierarchy). (PK)

Tool Changes

Changes to the tool set that Django provides that would make life easier as a Django-based designer, such as changes to the template language.

Valuable external resources

• ​Issues in Django identified (and partly solved) by the Grappelli project