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.

Also see ​Trac tickets tagged with the "design_ux" keyword

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) Fixed in r15129

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).

Ticket #13146 is opened for this.

Add a Cancel button on the submit_row of the change form

If you go to the change form of an object, there is no obvious way to go back to the calling page (e.g. the change list) without saving changes. There are only options for how to save changes.

Big Ideas

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

Consistent typography, sane CSS definitions

From a designer's point of view, the admin interface does not present information in the most clear and streamlined (and thus beautiful) way. This is mostly due to a lack of consistency: There are many different font sizes/weights, various different margins and line heights. Many elements are not aligned or (worse) almost aligned with the surrounding elements. The whole design could really use some cleaning up.

Morever, the current stylesheets are quite messy. Font-families and especially font-sizes are redefined over and over, in many different files and using many different CSS selectors. Apart from being at least partially redundant, this violates the DRY principle and makes customization of the admin interface (for instance, setting a different base font size) almost impossible.

Suggestions:

  • Instead of redefining font-sizes for many special elements (e.g. “dd tags have font size 11px”), there needs the be a basic set of font styles with clear hierarchy.
  • Instead of scattering the definition of margins and paddings wherever they are needed, there needs to be a baseline grid that is strictly adhered to.
  • Instead of explicitly defining specific styles for special elements (e.g. “changelist filter has a bottom border”), there needs to be a clear set of generic module classes.

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) Possibly a "drop down" list or "hide/expand area" would allow for N number of elements to be added to such a "block" or section of the page?

Isn't this solved by the non-CRUD functionality as described below? (AB)

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)

List Filters

List filters should be able to span relationships.

The ability to write custom filterspecs is extremely powerful but largely undocumented and limited in important ways. They currently require editing the model definition which limits their use on 3rd party and contrib apps. They are also tied to a specific field which makes it tricky to use them to filter on reverse relationships.

Changelist

The ability to display columns that span relationships would avoid the need to create model attributes that exist just for the sake of the admin.

Despite the obvious memory/performance issues there are many cases where the ability to sort by non-db fields in the changelist is extremely useful. One drawback is that this will complicate pagination.

The ability for admin users to hide and add columns in the changelist and for those changes to persist per user. The list of all available columns should be specified in the ModelAdmin along with an initial set to display.

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.

Documentation for CSS Elements

There needs to be clear and extensive documentation for existing and proposed CSS Elements; along with guidelines for designers as to how to implement their style changes - at beginner, intermediate and advanced levels.

Valuable external resources

Last modified 14 years ago Last modified on Jan 19, 2011, 4:05:04 AM
Note: See TracWiki for help on using the wiki.
Back to Top