I do not see in the redesign plan how the issue queue will be changed, but I would like to see it changed.

as an example I would choose this bug tracker for the comparison
http://www.phpbb.com/bugs/phpbb3/

Our table is too wide, I think the "Category" and "Priority" column could use small pictures. The "Assigned to" and "Last updates" could be displayed within the summary column. These 4 columns take the half of the space in the table. Some texts could use a smaller font size.

I think the change is really easy now with Views 2 template files.. The change should go to the new d.o theme but I do not know which project is that..

Comments

Project:Project issue tracking» Drupal.org infrastructure
Version:6.x-1.x-dev»
Component:User interface» Drupal.org theme

Try running this code in firebug on an issue page:

var trim = function(str) {
  return str.replace(/^\s+|\s+$/, '');
};
$('tr').each(function() {
  if ($(this).parent().is('tbody')) {
    var t = $(this)
      .find('.views-field-title')
      .append('<br /><small>Last updated ' + trim($(this).find(".views-field-last-comment-timestamp em").text()) + ' ago. Replies: '+ trim($(this).find('.views-field-comment-count').html()) +'</small>'),
      tr = trim($(this).find('.views-field-name').text());
    if (tr != '') {
      t.append('<small> (Assigned to: '+ tr + ')</small>');
    }
  }
  $(this).find('.views-field-last-comment-timestamp').remove()
  $(this).find('.views-field-comment-count').remove()
  $(this).find('.views-field-name').remove();
});

Is that the look you were intending?

StatusFileSize
new16.33 KB

yes, that would be it

Then you can't choose to sort by last updated time (the default), or the # of replies (people have said they were very happy to be able to do that now), or who it's assigned to, etc. I'm not totally opposed to using icons for category and priority, although I'm not sure what those icons should look like to be completely self-evident. Also, the goal is to make those more flexible (i.e. configurable as cck fields, not hard-coded) in which case assigning them icons becomes more complicated.

StatusFileSize
new48.47 KB

you don't need to have the field in a separate column to sort by that field. A little change in the template and you can sort the table by anything. see an example of the sort functionality on the attached picture (it's not Drupal, but it can be done easily with views 2).

the icons would be for drupal.org only (not for the project_issue module), the categories and priorities are quite fixed on d.o and I think some nice icons could be self explanatory. I do not want icons for statuses, because that would be hard to explain with a picture..

@dww: Pasqualle is a Views 2 guru, so I bet he'd sign up for some implementation given some direction/agreement on what looks to implement.

As we discussed with Mark Boulton today, it's not clear that we yet have agreement on the direction this needs to go. Mark agreed that clicking the table headers to sort is such a completely self-evident and obvious UI that it's worth keeping. However, it's clearly still a ton of data. So, this definitely needs input, proposals, mockups, etc. Ideally, we'd get some default views and/or view template files which implement the various proposals and we could test them out on d6.d.o or something.

Damien and I were discussing this and came to the following conclusion: many of the columns don't make any sense to order by at all. Lots of them could be "group by" fields, if we a) could implement that in views and b) had a reasonable UI for how to express that. For example, on the site-wide issue queue we have the following:

Project: group
Summary: nothing (makes no sense to do any operations on this field, only display it)
Status: group (although sort could make sense, especially if it took into account the admin-defined weights for each status)
Priority: sort
Category: group
Replies: sort
Last updated: sort (default)
Assigned to: group

So, In theory, we only *need* 4 columns: Last updated, replies, priority, everything else. In practice, I think that's going to be way too much data in the summary column, so we should still split some of them out, but we could definitely make the rows wider and the table narrower.

On the per-project issue queue we lose the "Project" column (since it's implied with the title of the page (and the URL), and gain these two:

Version: sort (only present if the project has releases at all)
Component: group (although you *might* want to sort by this, too)

So, we only *need* 5 columns for this one.

The main downside of this approach is you get less issues per screen this way, and we'd probably want to page every 25 issues instead of 50 or something. That would be a drag, since it's nice to have the issues pretty dense on the page so you can get a better sense of the queue at a glance...

just a proof of concept that the sort works. Attached template file for the project_issue_project view.

notes:
Only the sortable fields are listed under "Sort by".
Nid, Status and Category fields have own columns, everything else is under Summary.
The pager is displayed above the table also.

Issue tags:+design

In addition to usability, this also needs a design review.

FWIW, I really like the queues how they are now and find the examples listed in this issue harder to read. I'm no usability expert... Just a maintainer that uses them, so I know my opinion doesn't really count, but thought I'd throw it out there anyway.

Michelle

Project:Drupal.org infrastructure»
Component:Drupal.org theme» User interface
Issue tags:-drupal.org redesign

Moving to the Drupal.org Redesign project

Component:User interface» Everything Else
Status:Active» Postponed
Issue tags:+drupal.org redesign

Change to new component.
Will be addressed after initial redesign is launched.

Status:Postponed» Closed (duplicate)

This is one of *many* issues re :the look and feel of the issue queue: http://drupal.org/node/1080550

Marking as 'duplicate' since we've got many newer issues based on post-redesign improvements, And I would like to see efforts focused on the newer ones.