|Version 24 (modified by jezdez, 6 years ago) (diff)|
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.
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
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).
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)
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) Isn't this solved by the non-CRUD functionality as described below? (AB)
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)
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 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.
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.
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.