523788 - Component name links need to be bigger for "Browse"

Status: RESOLVED FIXED

(Bugzilla :: User Interface, enhancement, P1)

Description

[Max Kanat-Alexander]

I've been using the Browse interface in 3.5 and I'm really liking it. But I actually keep getting confused or thrown off when I get to describecomponents, because the Assignee's name is actually more prominent than the link to the component.

Comment 1

[Max Kanat-Alexander]

Attachment: v1

I took the opportunity to revamp the describecomponents UI in general.

Unfortunately pyrzak isn't currently available for reviews, so I'm asking LpSolit.

Comment 2

[Max Kanat-Alexander]

Attachment: Screenshot

Here's what it looks like in Dusk. (It looks basically identical in Classic.)

Comment 3

[Frédéric Buclin]

Comment on attachment 407721 [details] [diff] [review]
v1

This gives me a weird UI when a product or component has a short name. Screenshot coming...

Comment 4

[Frédéric Buclin]

Attachment: buggy screenshot

See how "Default Assignee" is close to "Default QA contact", and also the overlap. I intentionally used an ultra-short product name to make the problem more obvious.

Comment 5

[Frédéric Buclin]

(18:24:34) mkanat: LpSolit: I'll put a min-width on one of the columns, that will fix it.
(18:24:41) LpSolit: yeah, I think so
(18:25:19) LpSolit: mkanat: maybe also some padding to avoid too close column headers?

Comment 6

[Max Kanat-Alexander]

Attachment: v2

Okay, thanks to your feedback, I did a bunch of testing with various extremes (short things and long things in almost every column) and I discovered that the layout got weird in various ways depending on what was going on. So this patch adjusts things to make it all "just work" no matter what you do with your product names, component names, and descriptions of everything.

I'll attach two screenshots--one that shows the extreme of everything being huge, and another that shows the extreme of everything being tiny.

The layout required tables to be sensible. I actually managed to get a lot of it working with CSS, but then I needed the "instructions" paragraph to be centered relative to the product description, and that was (as far as I know) impossible with CSS floats. The table layout is way simpler and works 100% of the time, even if the screen gets really really tiny.

Comment 7

[Max Kanat-Alexander]

Attachment: Screenshot: Everything Big

This is what it looks like when you have long names and descriptions for everything.

Comment 8

[Max Kanat-Alexander]

Attachment: Screenshot: Everything Small

Here's what it looks like when everything is tiny.

Comment 9

[Frédéric Buclin]

Comment on attachment 416458 [details] [diff] [review]
v2

>Index: template/en/default/reports/components.html.tmpl

>+<table cellpadding="0" cellspacing="0" id="components_header_table">

I think we should stop using hardcoded cellpadding and cellspacing in templates. This should now be controlled using CSS.


>+<table class="component_table" cellspacing="0" cellpadding="0">

Same here.


>+    <th>&nbsp;</th>

What's the point in having an empty cell? Why not put "Components" here?

And unless I cannot count, the number or cells per row is not the same for the header and for subsequent rows.


When you have long component descriptions but short assignee/QA contact names (which is what we usually have), the assignee and QA contact names are completely misaligned compared to table headers (Default Foo). This really looks wrong.

Comment 10

[Frédéric Buclin]

Comment on attachment 416459 [details]
Screenshot: Everything Big

Note that you can already see what I'm tacking about in this screenshot. Just make the browser wider, and the problem will become even more obvious.

Comment 11

[Max Kanat-Alexander]

(In reply to comment #9)
> >+<table cellpadding="0" cellspacing="0" id="components_header_table">
> 
> I think we should stop using hardcoded cellpadding and cellspacing in
> templates. This should now be controlled using CSS.

  We are. tables have cellpadding and cellspacing by default, and that removes it. In order to fully control padding and spacing with CSS, you have to specify those two things on a table.

> >+    <th>&nbsp;</th>
> 
> What's the point in having an empty cell? Why not put "Components" here?

  The formatting of the page is better with where I put components. I did some experiments with putting Components into that first column, and it just looks better and wastes less space to use the negative margins instead.

> And unless I cannot count, the number or cells per row is not the same for the
> header and for subsequent rows.

  It is the same, but there are rowspan'ed columns.

> When you have long component descriptions but short assignee/QA contact names
> (which is what we usually have), the assignee and QA contact names are
> completely misaligned compared to table headers (Default Foo). This really
> looks wrong.

  Oh, I just forgot to put a text-align for them in the CSS! That can be fixed. :-)

Comment 12

[Max Kanat-Alexander]

Attachment: v3

Okay, this fixes the problem with the header alignment.

Comment 13

[Frédéric Buclin]

Comment on attachment 417023 [details] [diff] [review]
v3

Please fix the filter error on checkin:

not ok 267 - (en/default) template/en/default/reports/components.html.tmpl - filterexceptions.pl has extra members:
#   numcols
# --WARNING

As numcols is used only once, we could as well write colspan="[% Param('useqacontact') ? 2 : 1 %]". r=LpSolit with this fix on checkin

Comment 14

[Max Kanat-Alexander]

I just removed the filterexceptions item on checkin.

Checking in skins/contrib/Dusk/.cvsignore;
/cvsroot/mozilla/webtools/bugzilla/skins/contrib/Dusk/.cvsignore,v  <--  .cvsignore
new revision: 1.5; previous revision: 1.4
done
Checking in skins/standard/IE-fixes.css;
/cvsroot/mozilla/webtools/bugzilla/skins/standard/IE-fixes.css,v  <--  IE-fixes.css
new revision: 1.3; previous revision: 1.2
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/skins/standard/reports.css,v
done
Checking in skins/standard/reports.css;
/cvsroot/mozilla/webtools/bugzilla/skins/standard/reports.css,v  <--  reports.css
initial revision: 1.1
done
Checking in template/en/default/filterexceptions.pl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/filterexceptions.pl,v  <--  filterexceptions.pl
new revision: 1.132; previous revision: 1.131
done
Checking in template/en/default/reports/components.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/reports/components.html.tmpl,v  <--  components.html.tmpl
new revision: 1.16; previous revision: 1.15
done