Introduction

We have a lot of Ui's where we list objects. these can be divided into two listings:

Lists of objects for configuration; For example themes or blocks. Normally the amount of objects is limited and will not grow.
Lists of objects for presentation; For example nodes, comments or users. Normally the amount of objects will expand or is too large to fit on a single page.

Configuration lists

It needs no additional browsing, sorting and filtering interfaces, other than optional local tasks (tabs). The list should be subdivided if it gets bigger then X by these local tasks into logical areas. No more then Y of these tabs may be defined.
The list should be subdivided into small sections by headers (bold) to group logical groups, if the amount of rows exceeds Z.
TASK 1: Define X, Y and Z.
Only one action must be possible per object (row), typically this will be “edit” or “ configure”.
TASK2.Define which of these two must be used, throughout Drupal.
The list itself is never a form; and thus contains no form elements.

Object lists

An object is rather abstract, but I cannot find any better words, I use it for things like “users” , “nodes” or “comments”. for core Drupal, these three will suffice, but modules can add more.

A list of such objects needs additional interfaces, because of the (possible) length of that list:

• Filter
• Sort
• Browse

Additional these lists must be a form, to perform batch operations on the objects.

Filter

Investigating the mayor audio (management) applications brings us the conclusion that the itunes/Juk/rhythmbox system is best suited for filtering lists of metadata objects. Metadata can be the the artist or band that made an audio-track, or a genre, but can off course be the author of a comment, or the taxonomy a node is in. Thus such an itunes interface translates very well to Drupal lists.

The three boxes, for nodes, will contain, from left to right:

• Status (promoted, queued etc)
• Node type
• Taxonomy (category)

The three boxes, for comments will contains, from left to right:

• Status (spam, published, etc)
• Parent node type (?)
• Parent node taxonomy (?)

The three boxes, for comments will contain, from left to right:

• Profile data (should we do this?)
• Role
• Status

We decided that the roadmap for such a interface should be as follows:
TASK 3.compile and discuss all the options: Javascript, AJAX, page loads, etc.
TASK 4.implement it in a module..
TASK 5.test that module..
TASK 6.implement the interfaces in core..

Sorting

After the three filter-options are used the user might still have a very big list. Thus all columns must be sortable.
TASK 7.Develop a proper sorting mechanism, that detects unsortable data; .

The columns presented for nodes are:

The columns presented for comments are:

The columns presented for users are:

TASK 8.All columns must be ordered better
TASK 9.Column width lust be defined
TASK 10.Content should be made fitting into a cell, by chopping and concenating it with '...'

Browse

After filtering and ordering, a user is able to browse to the row(s) she wants;
browsing is achieved trough the default Drupal pager
TASK 11.Make table paging work with sorting and filtering (remember previous post/get data)