My Proposal [GSoC '09 Admin UI Improvements]

[Zain Memon]

Hello,

As you might know, I'm one of the Django GSoC students this year. My mentor is (the) Jacob Kaplan-Moss, and he's already started corrupting my innocent mind.

This summer, I'm implementing a collection of ideas with the goal to improve the general usability of the admin. The ideas are grouped as follows:

Foreign Key Handling

1. An inline search/autocomplete for the FK field on the model detail page (possibly replacing or supplementing raw id admin)
2. A simple method to edit a FK, either in-line or similar to adding one from the model detail page (e.g. an edit button next to the "+" icon that pops up a new window)

Inlines on the model detail page

1. Adding and removing tabular inlines with Javascript (Wilson created a great mock-up of this functionality attached to ticket #13)
2. A tighter interface for stacked inlines (also has a mockup)
3. Reorder inlines by dragging & dropping (most likely requires a refactoring of the ordering APIs, according to this django-dev thread)
4. Pagination of inlines (currently, having many inlines make the page way too long)
5. Possibly a search/filter for the inlines if it can be added without cluttering the UI

A better Javascript calendar date picker

1. The ability to highlight a specific date for an empty field (e.g. an unfilled birthdate field should pop up with a sensible default date a few years ago, not with "today")
2. Disable selecting dates before or after a certain date
3. Better navigation for multiple years (most likely next/previous year arrows)

Various Others

1. An autocomplete widget
2. Multi-select for filtering on the list display page (ticket #1873)
3. If I have extra time at the end, there is a grab-bag of admin UI tickets I could dig into (e.g. #4065, #5273, #4926)

During the interim period between now and the end of May, I'm tackling a few 1.1 tickets. I'm starting with #10516, and I'll pick up #9743 and #10632 if they're still open when I'm done.

To make searching easy, I'll append "[GSoC '09 Admin UI Improvements]" to the subjects of my weekly updates to this list.

Regards,

Zain

[Jeremy Dunck]

On Fri, Apr 24, 2009 at 6:19 PM, Zain Memon <za...@inzain.net> wrote:
> Hello,
> As you might know, I'm one of the Django GSoC students this year. My mentor
> is (the) Jacob Kaplan-Moss, and he's already started corrupting my innocent
> mind.
> This summer, I'm implementing a collection of ideas with the goal to improve
> the general usability of the admin. The ideas are grouped as follows:
>

+1 in general.
...

> Reorder inlines by dragging & dropping (most likely requires a refactoring
> of the ordering APIs, according to this django-dev thread)

I'm not sure what this means. Inline order is defined by the
underlying queryset, isn't it? What would reordering them on the
client do in the DB?

[Alex Gaynor]

The idea is you have an "order field" some an integer to track the order, relative to some other object.  And the JS ordering would update this field appropriately(a hidden field in the HTML I guess).
 

Alex

--
"I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire
"The people's good is the highest law."--Cicero

[Jacob Kaplan-Moss]

2009/4/24 Jeremy Dunck <jdu...@gmail.com>:

> I'm not sure what this means.  Inline order is defined by the
> underlying queryset, isn't it?  What would reordering them on the
> client do in the DB?

This is a return of and a cleaning up of the old order_with_respect_to
(which still sorta works, but the admin feature depended on a
GPL-licensed JS lib, so we couldn't and didn't include it, and the
feature basically died).

Jacob

[Jerome Leclanche]

> # Disable selecting dates before or after a certain date
This sounds like it should be general behaviour (adding min_date and
max_date to DateField or something similar - I thought this was
already in?).

I've got a couple more comments on admin UI in general, if you want to
take a bite at them.
For one it's kind of annoying the FKey/m2m/etc don't link either to
the corresponding object's admin or site page if either are available
(checking for admin first, then for site?). The fix should be very
simple, just thought I'd add some FFT.

I also filed ticket 10871 <http://code.djangoproject.com/ticket/10871
Add input support to admin actions (with patch)> a few days ago. I
haven't had time to do anything recently but I'm curious what the
general opinion on the design would be. Using an intermediate page as
proposed in c2 sounds unnecessarily complicated if you just want
something simple, to be honest.

(Hope I'm not hijacking or something, saw this was on admin UI, hopped on it.)

--
Adys

[Zain Memon]

On Fri, Apr 24, 2009 at 9:13 PM, Jerome Leclanche <ady...@gmail.com> wrote:

For one it's kind of annoying the FKey/m2m/etc don't link either to
the corresponding object's admin or site page if either are available
(checking for admin first, then for site?). The fix should be very
simple, just thought I'd add some FFT.

I'll be implementing a link to the object's admin (#2 under FK Handling in my proposal). Could you expand a little further on what you mean by linking to it's site page?

[Alex Gaynor]

I'm a little considered with the UI considerations of using one mechanism in multiple ways.  We looked at having admin actions that could support all objects and specifically rejected it since it overloaded that UI element in a way that was confusing to users, in place we decided to do a gmail style "select all" type thing, which is more intuitive.  For this reason I think adding a text field would be in poor UI form as it, again, overloads a single mechanism for multiple purposes in a way that isn't intuitive to the user.

[Jerome Leclanche]

What I'm doing locally is just a small hack with get_absolute_url, but
ideally, if the object doesn't have an admin page, it would be the
same link as the "View on site" link on the admin page (if available).

--
Adys

[Jerome Leclanche]

On Sat, Apr 25, 2009 at 7:40 AM, Alex Gaynor <alex....@gmail.com> wrote:
>
> I'm a little considered with the UI considerations of using one mechanism in
> multiple ways.  We looked at having admin actions that could support all
> objects and specifically rejected it since it overloaded that UI element in
> a way that was confusing to users, in place we decided to do a gmail style
> "select all" type thing, which is more intuitive.  For this reason I think
> adding a text field would be in poor UI form as it, again, overloads a
> single mechanism for multiple purposes in a way that isn't intuitive to the
> user.
>
> Alex

Yah, my original idea was not showing the text input if there is no
takes_input action, and disabling/hiding it if the currently selected
one doesn't take any input. This, in my opinion, is a decent
trade-off; totally invisible if you don't need an input.

*shrugs*

--
Adys