Task table status/importance columns should be thinner

[William Grant]

All columns in the bugtask index's task table are now the same width. This makes the status and importance columns far too wide, and the target column sometimes rather too small, resulting in horrors like in the attached screenshot.

[Deryck Hodge (deryck)]

I think whether or not we fix this is dependent on whether or not the basktask table stays as it is or moves up and stretches across the top of the page. The current layout should stay if we return to the bugtask separate from the rest of the page, which was the plan when this was last discussed in the bugs team.

Personally, I quite like the two-section grid bug page and would like to consider how we can make the bugtask table work there -- perhaps applying a fix for this and setting a min-width on the main column so it doesn't collapse?

[Matthew Paul Thomas (mpt)]

I don't understand why it's dependent on that at all. Regardless of how wide the table is, why should its columns ever be the same width? That would make sense if the columns were showing the same type of datum, but in this table they don't -- every single column is of a different sort. (In a couple of minutes I found <http://espn.go.com/nfl/statistics/player/_/stat/passing/sort/quarterbackRating/year/2009/seasontype/2> as another example of this: data can sensibly be compared between rows but not between columns, therefore the columns are different widths.) The only other reason I can think of for fixing column widths at all would be if multiple tables of the same type were ever vertically stacked, so they needed to be consistent with each other -- but that doesn't happen for this table either.

(On the side issue of whether the table should return to spanning both columns, I think that would be worthwhile -- I considered it a design goal of 2.0 that developers doing actual work with Launchpad should be able to use a Launchpad window alongside a terminal window on a standard-size screen, and it would be a shame to completely subvert that. But again, I don't think that's relevant to this bug.)

[Deryck Hodge (deryck)]

Sorry, I thought the cells were always fixed width cells and the change only exposed the problem. I didn't realize we had changed to fixed width cells on the table with this update. Looking closer, I now realize this is the case.

Yes, this should be fixed regardless of what width the table takes up on the page.