53009 - Make Bugzilla pages always fit easily in 1024x768

Status: RESOLVED WORKSFORME

(Bugzilla :: User Interface, enhancement, P2)

Description

[David Krause]

The bugzilla pages are too wide because the CC box is over too far to the edge.
 If I have my sidebar open then I have to scroll in order to see the whole page.
Ideally, the page should be the same width as the mozilla.org banner at the top
of the page which is 600 pixels wide. Yes, I don't have my browser full screen
but it shouldn't have to be.

Comment 1

[David Krause]

Here is a timeless's layout discussed on #mozwebtools:

10:38 <timeless> <a
href=http://bugzilla.mozilla.org/votehelp.html>vote</a>
      for <a
href=http://bugzilla.mozilla.org/showvotes.cgi?voteon=53006>bug
      53006</a>: <a href=http://bugzilla.mozilla.org/showvotes.
      cgi?bug_id=53006>0</a>
10:40 <timeless> that replaces: 'Votes for bug 53006: 0    Vote for this
bug '
10:40 <timeless> and then you can put it above the tree stuff


10:40 <timeless>  /----------+----------\
10:41 <timeless>  |Add CC | Vote for bug x: 0 votes|
10:41 <timeless>  | [x] CC me | tree|
10:41 <timeless>  | CCs | graph|
10:41 <timeless>  | CCs | depends|
10:41 <timeless>  | CCs | blocks|
10:41 <timeless> ...
10:43 <timeless> [x] CC me can be implemented later
10:43 <timeless> actuall
10:43 <timeless>  | [x]CC me| Vote for bug x: 0 votes|
10:43 <timeless>  | Add CC  | tree|
10:43 <timeless> [if we add it]

Comment 2

[Matthew Tuck [:CodeMachine]]

This happens to me too, and it's annoying.

The width depends on the product.  Browser has a very big component selection
widget, and the right column tends to partially go offscreen.  Webtools is OK
for me.

Of course this is all window/font size specific, and I suspect this can't be
fixed in general, but a reduction in space would be nice and should deal with
most situations.

We shouldn't be aiming to reduce the size to anything that is mozilla.org
specific.

Maybe we could move CC elsewhere.  Then move reporter next to the create date
and make it look like a standard comment.

Comment 3

[Zach Lipton [:zach]]

will the 640x480 group please stop complaining? ;)

Comment 4

[Matthew Tuck [:CodeMachine]]

This used to happen to me on a 1024x768 screen until I reduced my font size. 
And it wasn't particularly big.

Comment 5

[Christian Reis]

I had the same problem with my installation: our users rarely browse over 600
pixels wide (and yes, we do have large monitors @ 1600x1280). I've gone and
changed the layout of show_bug.cgi to something a bit different. The added
colour isn't what i'm pointing to: it's the fact that the top panel for
selecting all the bug mumbo jumbo is organized.

See what it's like at http://bugs.async.com.br/show_bug.cgi?id=133

I would like feedback on the organization of the panel, and if people go for it,
I will produce a patch against 2.14 that does what I want, the right way. I will
factor the code into something easier to templatize, too, re bug 86168, too.

Comment 6

[Dave Miller [:justdave]]

I like the look of that.  Patch it :-)

Comment 7

[Dave Miller [:justdave]]

We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.

Comment 8

[Dave Miller [:justdave]]

We need this in during 2.16 in order to keep people happy with bug 11901.

Kiko, you mentioned in an earlier comment you already had a patch for this. 
Where is it?

Comment 9

[Dave Miller [:justdave]]

and he's not even reading here.  Kiko: see previous comment on this bug.

Comment 10

[Gervase Markham [:gerv]]

Fixing this is now a trivial change to the template. But I'm not so sure we
should - we've learnt from experience that some people don't like the layout of
things (e.g. the query page) changing; we should only change it if there's a
really good reason. I'm not sure this alone qualifies. 

Perhaps we should wait for a UI designer to take a look at the whole page?

Gerv

Comment 11

[Christian Reis]

The CC and reporter fields _definitely_ need to change place. Definitely. In the
default installation, too.

MPT: HELP

Why does this block bug 11901?!

Comment 12

[Dave Miller [:justdave]]

Originally it was blocking 11901 because people didn't want horizontal scrolling
in the comments.  The original intention of 11901 was going to let the browser
do the wordwrapping on the receiving side when VIEWING comments.  Gerv objected
because he like the narrow column of comment text.  Someone pointed out he could
just make his browser window narrower, then it was pointed out that making the
window narrower wouldn't work because of the CC widget sticking off the right
side at the top.

11901 is going to do specific column wordwrapping at the server before sending
to the client now, so it's probably not really a blocker on this anymore.  But
this would still be nice I think.

Comment 13

[Myk Melez [:myk] [@mykmelez]]

I agree with Gerv.  This page needs an overall redesign.  I know a designer who
might be interested; I'll look into this further.

Comment 14

[Christian Reis]

Well, for heaven's sake. I had a patch and never saw Dave's comments; sorry
Dave, my bad in not having come back and looked. Ugh. I can try and bother mpt
into doing a real redesign.

Comment 15

[Matthew T (active 1999-2002)]

Now that the query.cgi redesign is done, my second priority is index.cgi, and my
third is show_bug.cgi. Part of show_bug.cgi will be making it narrower, as well
as more consistent with query.cgi.

See also bug 124374 and bug 109266.

Comment 16

[Myk Melez [:myk] [@mykmelez]]

Moving this out to 2.18 (and correcting the severity) since it's a minor
problem, no longer blocks a 2.16 blocker, doesn't have a lot of action, and is
best done as part of an overall redesign of the "show bug" page.

Comment 17

[Dave Miller [:justdave]]

blocker did not fix...  (removing said flag)

Comment 18

[Dave Miller [:justdave]]

*** Bug 141746 has been marked as a duplicate of this bug. ***

Comment 19

[Christian Reis]

Attachment: kiko_v1: modify layout slightly: move CC box into main table, add spacing

I've hacked a patch which I will put into use immediately on bugs.async.com.br.
It does the following:

- Moves the CC box into the right-hand column of bug attributes
- Adds spacing to clarify the grouping, which we are bad at today.

This is against CVS HEAD. I'm requesting ui review from mpt and another senior.

Comment 20

[Christian Reis]

I'd like to make a point here: this form has bad usability at the moment. While
I do think it would be nice to do a real redesign, it will take a long time to
happen. This change makes manipulating the form easier; I will conduct some
basic experiments to see how better people like it at Async (wrt to the default
form).

This isn't really about low resolution, really, but about window size. Not
everybody works with maximized windows, and particularly not those with high-res
monitors.

Comment 21

[Christian Reis]

The URL above exemplifies the new layout. 

Comment 22

[Gervase Markham [:gerv]]

We've found from the query page that people get used to whatever the layout is
quickly, and don't like it changing even if it's a usability improvement.
Therefore, if we do want to make changes, we should make them all at once, to
reduce the moaning to one episode instead of multiple.

Therefore, I still believe that, while sites can customise this on an individual
basis if they like, the Bugzilla trunk shouldn't change the layout until we've
looked at the page as a whole.

Gerv

Comment 23

[Christian Reis]

I am seriously opposed to us keeping things less usable based on the fact that
we have previous installations. Release-note the fact that the layout has
changed, place a warning in checksetup.pl, whatever -- I even volunteer to doing
it, but don't push every layout change off or we won't improve.

If the problem is b.m.o., and the matter is just changing it to use one custom
page for edit, then I don't think its worth it. 

A big review of this page is going to take some time, and this can be checked in
easily and make things better for all our new users - we want new users, right?
Why keep punishing them with a bad layout for the most-viewed page in the system?

Comment 24

[Matthew T (active 1999-2002)]

In this particular instance, I agree with Gerv. When show_bug.cgi is redesigned,
it should be all at once.

Comment 25

[Christian Reis]

There are two points I'd like to make:

a) We have custom templates. If site admins think their user base won't get used
to the changes, they don't *have* to adopt the change if they don't like it. I
am suggesting we take this change for two reasons: first, because new bugzilla
installs will have a better show_bug.cgi. Second, because admins that *want* a
better layout and think the impact is acceptable, can use it.

One solution would be to distribute a contrib/ directory in the template folders
if we are all really going to say no to all UI changes.

b) It is possible we can reuse the new layout of the top section of the bug in
the redesign. In this event, the change would quite probably not be as harsh.

Still haven't seen a technical review of the layout, though, which is what I
hoped for when I attached the patch.

Comment 26

[Dave Miller [:justdave]]

*** Bug 173092 has been marked as a duplicate of this bug. ***

Comment 27

[Peter Lairo]

I see this bug at:
- resolution:         1280x1024
- win98:              small fonts
- mozilla font sizes: proportianal = 20, monospace = 18
- non (but almost) maximised window

I just filed dupe bug 173092. I definetely would not "moan" (comment #22) if
this long-standing annoyance were fixed soon. ;)

Comment 28

[Dave Miller [:justdave]]

Hmm, me too.

And we have precedent for b.m.o using custom templates for a period of time to
ease a transition (the query page redo)

Comment 29

[Diego Biurrun]

While customizing Bugzilla for a client I was asked to redo the layout in Red
Hat style.  I had a look through all relevant layout bugs that seemed relevant
and I must say that I am quite positive about kiko's layout at
http://bugs.async.com.br/show_bug.cgi?id=133

Apart from the two colums I like the idea of giving all dropdown boxes the same
size, that removes a lot of Bugzilla's disorganized look - at least that is the
first impression people not familiar with Bugzilla have.

Please restart the discussion in this bug and conside adopting the proposed
scheme.  b.m.o is the most high profile Bugzilla installation and should not be
afraid of changes so much.  After all Bugzilla gets advertised to the world here
and it should sport the best possible design and layout.

Comment 30

[Diego Biurrun]

Updating URL field with a working URL that shows a good example of what a
narrower and more coherent design might look like.

Comment 31

[Dave Miller [:justdave]]

Sure that URL works?  I get "no such host" from behind Netscape's firewall
(which is obviously just Netscape's DNS sucking), and "connection refused" on my
computer that's not in the VPN.

Comment 32

[Diego Biurrun]

Attachment: narrow and clean layout

Yes, that URL works here from my university's network and from a local
provider's network here in Aachen, Germany.  That must be the firewall's fault.
 I'm attaching a screenshot in any case..

Comment 33

[Diego Biurrun]

Please also notice how the intelligent use of blank space and grouping of the
dropdown boxes greatly improves usability.

Comment 34

[Dave Miller [:justdave]]

OK, I can get at it from both places now.  kiko says on IRC that they had an NFS
glitch and the site was actually down for a little bit.

Looks really pretty, I like it.

Comment 35

[Myk Melez [:myk] [@mykmelez]]

Now that we have flags, this bug needs to take them into account.  Ideas?

Comment 36

[Diego Biurrun]

Kiko could you post the changes you made to get this layout as a patch or attach
your templates, please?  I would be interested in having a look at them.

Comment 37

[Christian Reis]

Attachment: Custom template edit.html.tmpl

I'll attach the custom layout I am using. Async runs a (somewhat old) CVS
version of bugzilla, so it may not adapt completely, but I'm a bit overwhelmed
with work and can't make a better cut here.

One thing to look out for: this does *not* contain the (somewhat recent)
accesskey and label fixes, so those should be merged in.

I think the flag section should be displayed spread horizontally under the
attachment listing, with individual flags stacked one above the other.

Comment 38

[Christian Reis]

We also use a custom navigation header instead of the First Last links at the
top. If you do a query for bugs on on bugs.async.com.br, product IndexedCatalog
and try following the bug nav header at the top.

Comment 39

[Myk Melez [:myk] [@mykmelez]]

>I think the flag section should be displayed spread horizontally under the
>attachment listing, with individual flags stacked one above the other.

Hmm, I'm not understanding this.  If the flags are stacked one above the other,
aren't they spread vertically instead of horizontally?

Comment 40

[Christian Reis]

For bug flags I suggest something like:

| Create a new attachment (patch, testcase, etc)              | View All |
'------------------------------------------------------------------------'
  
  Flags (Help):                                     approval: [  |v] (myk)
                                                 blocking1.0: [  |v] (kiko)

Having the Flags section only show up when there actually *are* flags for that bug.

Comment 41

[Christian Reis]

I'm going to work on this sometime soon, I haven't forgotten it.

Comment 42

[Felix Miata]

I hope so, or maybe myk can do it instead?

Comment 43

[Joel Peshkin]

Kiko on IRC said move to 2.20

Comment 44

[Greg Hendricks]

I think the same should go for the search page. Currently some of the fields go
well beyond 800 pixels even at the narrowest. Especially the bug changes and
email and numbering boxes.

Comment 45

[Dave Miller [:justdave]]

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.

Comment 46

[Frédéric Buclin]

The trunk is now frozen to prepare Bugzilla 2.22. Only bug fixes are accepted, no enhancement bugs. As this bug has a pretty low activity (especially from the assignee), it's retargetted to ---. If you want to work on it and you think you can have it fixed for 2.24, please retarget it accordingly (to 2.24).

Comment 47

[Max Kanat-Alexander]

Nowadays this is pretty WFM. 800x600 isn't really the web standard anymore, as most people have 17" CRTs or 15" LCDs and run at 1024x768 or above.

All the Bugzilla pages that I've used recently fit nicely in 1024x768.

Also, we did redesign the show_bug layout and I think it's a bit less wide, now (though it may even be slightly wider). Either way, it seems to fit in 1024x768 most of the time (unless somebody's realname or username is really long).

Comment 48

[Peter Lairo]

I still get a horizontal scrollbar at 1024x768, an *almost* maximized window, and a sidebar open.

This seems to be caused primarily by the bugzilla fields: "Reported", "Modified", and "Add CC".

I was hoping that bugzilla would adjust to almost *any* size viewing area.

BTW: The new bugzilla layout is a huge improvement!

Comment 49

[John Belmonte]

The idea that everyone has at least a 1024x768 display, or that they run their browser full screen even if they do, is incredibly presumptuous.  Very disappointing.

Comment 50

[KitchM]

This is very bad.  We need to recognize that many people are faced with what should never occur; a horizontal scroll bar.  Making sure all programs are properly resizable to fit the existing screen resolution is indeed part and parcel of the web standards.

I use 800x600 on a 17 inch monitor.  I also use 1024x768 on a 40" wide screen television monitor.  There should never be a horizontal scroll bar, nor should page elements not fix within the screen confines.

I hope that someone will fix this because it sure does not "work for me" and is certainly no resolved as of this date.

Comment 51

[KitchM]

This problem is very annoying and still ongoing.  It is odd that Bugzilla does not conform to Firefox resolutions.  It is the same company for pity sake.

I am attaching my screenshot of this serious problem.

After the recent upgrade, Bugzilla should have had this fixed.

Comment 52

[KitchM]

Attachment: Screenshot - 09112014 - 11:38:01 AM - Bugzilla does not conform to Firefox.png

Shows continuing problem that is not fixed.

Comment 53

[:glob ✱]

[e-mail] isn't a person, and cannot answer needinfo requests.

Comment 54

[KitchM]

Then why is it listed?  I need info.  This does not work for me at that resolution, and it is reproduceable.

Comment 55

[Andre Klapper]

"needinfo" refers to information required to resolve/fix the specific bug report. 
If you have a specific question *how* to write code to fix this bug, just ask it.

Comment 56

[Felix Miata]

Attachment: 96 DPI 1024x768 screenshot of buglist.cgi similar to attachment 8487977 but with context included

$ fc-match sans-serif
DroidSans.ttf: "Droid Sans" "Regular"
It appears browser in attachment 8487977 [details] is using a wider font family for its nominal size, maybe DejaVu Sans, but quite clearly there is considerable horizontal scroll required to reach all bug list page content when using a larger than shipped browser default size.

This bug may be fixed for those using the mozilla.org shipped default font size, or smaller, but it is not for those who've personalized their Gecko with a larger-than-shipped default size, or those who've zoomed to produce similar effect.

Comment 57

[Frédéric Buclin]

If your font size is pretty big as in your screenshots, it's expected to see horizontal scrolling. All the data cannot fit in your window in this case. And wrapping would make the data unreadable.

Comment 58

[KitchM]

The attachement shows the current settings.  Please note that Firefox has not default settings to select.

Please also note that Bugzilla is one of the worst offenders on the whole Internet.

Please also note that wrapping would not actually make things unreadable.  That has to do with proper formatting.

And finally please note that Firefox ships with a choice of fonts by default, including up to 72 point.

Comment 59

[KitchM]

Attachment: Screenshot - 09152014 - 10:54:38 AM - Firefox current font settings.png

Comment 60

[KitchM]

I need information as to how to fix this bug.  Please let me know how to do it.

Comment 61

[Felix Miata]

Attachment: 96 DPI 1024x768 buglist.cgi screenshot using same browser pref settings as attachment 8489086 but with user CSS applied to eliminate horizontal scroll

Note the staggered column headings constitute another difference from attachment 8487977 [details], but they result from a page-provided preference all users are free to select.

(In reply to Frédéric Buclin from comment #57)
> If your font size is pretty big as in your screenshots,

How big is "big"? 20px may be "big" to you, but it's optimal for typical web pages on most of my displays here, and often can be too small on higher density displays. On a OLPC tablet's 7.5" 200 DPI display, 20px is tiny, only 7.2pt, only 36% of the size (physical, not nominal) of the most common size preferred by ordinary users of web pages, 12pt (again, physical, neither nominal, nor CSS specification).

> it's expected to see horizontal scrolling.

Whether that is or ever may have been true is subject to opinion. The page's CSS "suggests" the largest x-height font family commonly installed, Verdana, while it could be specifying a narrow family for the wider than average pages that buglists often are. Now that @font and media queries are ubiquitous among browsers, buglist.cgi could be choosing an optimal font based on viewport size, choosing narrower when content would likely not fit available space, minimizing or eliminating horizontal scroll.

(In reply to KitchM from comment #60)
> I need information as to how to fix this bug.  Please let me know how to do
> it.

If you're talking about fixing it for your own profile, you can do as I did for this attachment. Put the following in your Gecko profile's chrome directory in a file named userContent.css (create it yourself if it doesn't already exist; add it if it does), substituting for <your-font-family-preference> the name of any narrow font family you find installed (if you don't find any narrow font installed, install one.) and prefer on your own computer:

@-moz-document domain(bugzilla.mozilla.org) {

body, dt, dd, p, th, li, input {
        font-family: sans-serif !important;
}

.bz_buglist td {
        font-family: <your-font-family-preference> !important;
}

}

Fixing buglist.cgi for all users could be similarly simple.

Comment 62

[KitchM]

Thanks, Felix.  You have good comments, that also point out the many problems associated with this programming error.

Actually, I want the necessary information to fix the program for all users.

To continue:
As I understand it, Bugzilla is created to conform to W3C standards, or should be.  If it does not, then there is a programming flaw.  Properly done, using a larger font or zooming in should only change the line/word wrap within a given column. Such is not the case here, and that is the only reason that readability might be hurt.  Worse, there appears to be a problem with row height as well, and line wrap within the row.

No one should have to adjust their browser settings unless a problem happens on all web sites.  This is not the case here.  This is a programming flaw with Bugzilla alone.  Every site that uses Bugzilla has a similar problem.  Therefore, this is a Mozilla programming problem.

So I ask again, Andre, how can I fix this with proper code.

Comment 63

[Andre Klapper]

(Please don't needinfo me on some code requests as that's nothing I can provide help with. Thanks.)

Comment 64

[KitchM]

Okay.  But you were the one who offered.

Comment 65

[KitchM]

"Offered what? Where? Quote, please.
Plus how is that related to "I need more information"?

andre"


From your comment #55, I quote:
"If you have a specific question *how* to write code to fix this bug, just ask it."

Obvously needed as "more information" to fix the problem.