The editable form in show_bug.cgi is too wide

NEW
Unassigned

Status

()

Bugzilla
User Interface
P1
normal
9 years ago
3 years ago

People

(Reporter: John Elion, Unassigned)

Tracking

Dependency tree / graph
Bug Flags:
blocking3.2 -

Details

(Whiteboard: [blocker will fix])

Attachments

(12 attachments, 1 obsolete attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; InfoPath.1; .NET CLR 1.1.4322; .NET CLR 3.0.04506.30)
Build Identifier: 3.0.3

The default "show bug" form in the 3.0 series (we have 3.0.3) has a very nice new interface over our previous version.  However, it is too wide.

We have a vision-impaired user at our site who is not able to make her browser wide enough to see the bug form without scrolling horizontally; the assignee is off the screen.  This decreases usability.  Even I find that ordinarily the "3-column layout" to have the People box cut off in a way that is annoying.

We also notice that when we print out a bug page, the "People" box is lost completely.

I wish to constructively suggest that the narrower two-column format of this site and in some of the mockups shown on the Mozilla Wiki would be a better format to include in the released version.


Reproducible: Always

Steps to Reproduce:
Using the released version of Bugzilla 3.0.3, and the default "Classic" skin
1.  Choose "My Bugs" (or a query that returns a list with at least 1 bug)
2.  Display the first bug in the list.  
3.  Print the page.  The "People" box does not appear in the printout at all.

Actual Results:  
In step 2, the "People" box is off screen to the right.  (How much is visible will depend on your screen resolution and browser width.)

In step 3, the "People" box was lost from the printout completely.


Expected Results:  
In previous versions of Bugzilla it was only necessary to scroll vertically for reasonable browser widths.  It was generally not necessary to scroll horizontally to see data.

Printouts from previous versions of Bugzilla did not have significant Bug data truncated lost off the right edge of the page.

Note that the bug form in this site (3.0.3+) does not have the layout provided in the released version, and when I printed the page from one of the bugs in the "Hot Bugs" list the printout included all the details.  (Can I please have your bug template?!)


I do realize that every Bugzilla user will have their own idea about what the bug form should look like, and did look up the discussion.  I found some of the mockups from 2006 which featured two-column bug widths and notice that this site (running "3.0.3+" has a narrower top-of-bug-form than what is provided in the released code.

However, I believe both the width issue as it relates to usability and the lost printout information are significant enough to express in an enhancement request, to at least document that these issues were considered.

I believe I will be able to modify our installation source code to move the PEOPLE box to the left, but would hope to see a narrower default format in the future.

Thank you for considering this request.
(Reporter)

Updated

9 years ago
Version: unspecified → 3.0.3

Comment 1

9 years ago
John, please check out: https://landfill.bugzilla.org/bugzilla-tip/

That is the new layout in 3.2 and let us know if this is still an issue for your visually impaired user. Thanks for your lengthy description. I'll look into the printing page being too wide. I've attached an image of the new layout along with a pdf of the printed page.

Looking at the PDF i definitely see text being cut off so I'm going to set this bug as confirmed about the printing page cutting off text.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

9 years ago
Created attachment 306529 [details]
PDF of bug being cutt off (see right side)
(Reporter)

Comment 3

9 years ago
We looked the landfill example in the user's environment - specifically, bug 1234; the user's Firefox browser increases font size and displays light text on dark backgrounds.

The Landfill bug layout still seems awfully wide - we could see part of the second column but not all of it.  At least the "Assigned To" field was in the left column and so readily visible.  The user could only see a few charaters: "Repor"[ted], "Modi"[fied], "Large text"[ box].  Even from my IE6 browser, the longer flags and text boxes were cut off.  The reporter and modifier were both lost in the printout.

The format of THIS Mozilla ("3.0.3+") database was much better than either the 3.0.3 released version or of the Landfill layout (at least for viewing this particular bug 420288).  Both columns were completely visible in the user's browser with no horizontal scrollbar.  Some text was lost in the printout, but all the checkboxes and enough of the reporter's name to be recognizable was present.  Thanks!

Comment 4

9 years ago
Can you please attach screenshots of the images you are talking about. I'd like to fix this for you(usability is very important to bugzilla), but it is hard without a point of reference. It sounds like you're using 800 by 600 resolution but can you confirm this for me? The more info I have about the user's browser the better I can attempt to solve this issue. 

Comment 5

9 years ago
So after some investigation there is a very simple fix to the bug form to make you happy with this layout, just making the target milestone take up two lines instead of one (removing the  ). This then makes the column layout even better than the bugzilla.mozilla.org website! So I'll include this as part of the fix to the print page.

Comment 6

9 years ago
Created attachment 307415 [details]
More recent pdf generation

This is the pdf now, not sure how it got fixed but it looks better now.
Assignee: ui → guy.pyrzak
Status: NEW → ASSIGNED

Comment 7

9 years ago
Created attachment 307416 [details] [diff] [review]
Patch v1

this is to address the user's concerns with the width of the first column on the bug form.
Attachment #307416 - Flags: review?(LpSolit)

Comment 8

9 years ago
Created attachment 307417 [details]
a before an after of the first column after the patch

Comment 9

9 years ago
Created attachment 307422 [details] [diff] [review]
Patch v2

small fix that makes sure that even if there is a big URL it doesn't make the 1st column wider. Everything else should wrap.
Attachment #307416 - Attachment is obsolete: true
Attachment #307422 - Flags: review?(LpSolit)
Attachment #307416 - Flags: review?(LpSolit)

Comment 10

9 years ago
Guy, the format for printing is not the editable bug form, as shown in your two first screenshots, but you attached a patch which alters the editable form. Sounds illogical to me. Also, I don't want to narrow the size of the status whiteboard and of the URL field to 35. 40 is fine and is not the major problem. Removing   from the "Target Milestone" label is a good idea though.

I see three other places where we could spare some space:

1) Decrease the width of custom free text fields and textareas, from 60 to 40 to match the current size used by hardcoded fields (such as the SW and the URL fields).

2) Reduce the value of bz_column_spacer in show_bug.css, maybe from 2em to 1em. It still looks nice IMO.

3) Limit the size of the user nick for flag setters to 15 characters or so.

And while you are on it, fix this ugly thing:

        <label for="component" accesskey="m">
          <b><a href="describecomponents.cgi?product=[% bug.product FILTER url_quote %]">
            Co<u>m</u>ponent</a>
          </b>
        </label>:

When narrowing the window, ":" wraps and you read:

 Component
         :

I think that's all we can do. The "format for printing" page already wraps correctly, and there is nothing to do there. And to reply to the reporter of this bug, if you want to print the bug report, you should use that page, not the editable bug page.

If we wanted as much wrapping as possible, the other solution would be to have fields to wrap *below* the labels. I'm not sure how it would look like though (probably ugly).
OS: Windows XP → All
Hardware: PC → All
Summary: Bug form too wide; data lost in printing → The editable form in show_bug.cgi is too wide
(Reporter)

Comment 11

9 years ago
Created attachment 307473 [details]
User's view of released 3.0.3 bug form

This is the released version of 3.0.3 with Testopia 1.3 and Perforce's P4DTI added.  The user's browser enlarges the font and alters screen colors to light text on dark, and that works pretty well.  The "People" box - in particular the Assigned To - is pretty much lost.
(Reporter)

Comment 12

9 years ago
Created attachment 307476 [details]
Print Preview of released 3.0.3 bug form

Installation includes Testopia 1.3 and Perforce P4DTI 2.4.2-1.
(Reporter)

Comment 13

9 years ago
Created attachment 307478 [details]
User's view of "Landfill" bug form
(Reporter)

Comment 14

9 years ago
Created attachment 307479 [details]
Print Preview of "Landfill" bug form

Our printout didn't look anything like the attachments we saw above.
(Reporter)

Comment 15

9 years ago
Created attachment 307480 [details]
User's view of Mozilla "3.0.3+" bug form

This is the user's view of THIS bug (420288 in this database).  It is the best we've seen.
(Reporter)

Comment 16

9 years ago
Created attachment 307481 [details]
Print Preview of "Mozilla" 3.0.3+ bug form

This is what we see when we print this bug from this database from our printers.
(Reporter)

Comment 17

9 years ago
Created attachment 307484 [details]
User's view of current production bug form (2.20.4)

We are upgrading from this version to 3.0.3 at the end of the month.  Even our current version is wide, but the change that caused the user complaint was that the ASSIGNED TO field was among the fields that stopped being immediately visible and was truncated in printouts.

Comment 18

9 years ago
The page you are printing is not the one you should use, as said above. For this bug, you should print this page:

https://bugzilla.mozilla.org/show_bug.cgi?format=multiple&id=420288

You get it by clicking the "Format for printing" link at the bottom right of the bug report. Problems you may encounter when printing the bug form are not top priority as we have a dedicated page for printing (which you should use).

Comment 19

9 years ago
We're going to implement a few changes to the bug entering for the one you've been printing, but like Frédéric mentioned, you should really try using the "Format For Printing" link for printing. I'm going to continue with the patch that I started to fix the wrapping etc (including the ugly thing which I noticed as well) and am requesting it get added to 3.2 for you guys. 

Thanks a lot for the screen shots, it helped clear up a lot! I think your user will be much happier with fixing we're doing for wrapping, but also make sure to mention the format for printing link. In 3.2 it is in the bottom right hand corner of the screen. 

Now we COULD (i don't like this idea) have a warning that appears only when printing on the bug entering form (this one not the format for printing one) that lets users know that they shouldn't be printing from this page. Let me know what you think.

Comment 20

9 years ago
(In reply to comment #19)
> Now we COULD (i don't like this idea) have a warning that appears only when
> printing on the bug entering form (this one not the format for printing one)
> that lets users know that they shouldn't be printing from this page. Let me
> know what you think.

Not a bad idea, though. It's a simple CSS rule to add in @media print.
(Reporter)

Comment 21

9 years ago
Sorry - I hadn't understood that there was a "Format for Printing" page - I thought that was unique to your installation.  Even knowing to look for it it wasn't easy to spot, but we did alter its location in our 3.0.3 installation.  

In kind of an informal survey here, 16 out of 24 users who responded to a request for a bug printout printed bugs from the edit form.  I will let everybody here know about it.  In 3.2 when the link is more prominent perhaps it will help, but I would guess many users will still just press the print button in their browser rather than scroll to the bottom to find a printer-friendly link.

Even so, I agree that placing a warning on a printout of the edit page is NOT a good idea.

Comment 22

9 years ago
Comment on attachment 307422 [details] [diff] [review]
Patch v2

r- per comment 10.
Attachment #307422 - Flags: review?(LpSolit) → review-

Comment 23

9 years ago
Max, this bug is bothering me for a long time. I don't know which screen resolution you guys have, but custom free text fields are definitely too large (60) and are inconsistent with other hardcoded text fields (40). I always have to scroll horizontally to read the content of custom fields on the far right.

First, this should be a constant (default 40) used by both hardcoded and custom fields, giving us an easy way to control the width of all text fields. This would probably save half of complains made about this issue (I saw this complain on other Bugzillas too, such as RedHat).

Secondly, I think all text fields, both hardcoded and custom ones, should have "(edit)" displayed by default, even if the field is empty. Moreover, the status whiteboard and the keyword fields are the only two hardcoded fields which are always displayed as editable. This wastes *a lot* of horizontal space, even on b.m.o, despite most bugs have only one or two keywords at most, which never reaches 40 characters (or even 20). Even the status whiteboard would be better displayed as readonly text, so that long text would gracefully wrap after 40 characters. And there is no reason for custom free text fields (and textareas) to not be displayed as readonly text by default, again with "(edit)" on their right to edit them.

This is not a hard work, and I loudly ask you to consider to block 3.2 on it.
Flags: blocking3.2?
We updated our text fields to be size=40 which makes it a little more bearable. We have 7 custom fields visible for privileged users so it made the screen rather wide before. having the fields as readonly text unless clicking on an "edit" link may work well for us as well. 

To follow Red Hat discussion on the new UI check out:

https://bugzilla.redhat.com/show_bug.cgi?id=457022

Dave

Comment 25

9 years ago
I won't block 3.2 on it, but it would definitely be nice to have for 3.2.
Flags: blocking3.2? → blocking3.2-
Priority: -- → P1
Target Milestone: --- → Bugzilla 3.2

Updated

9 years ago
Depends on: 455559

Updated

9 years ago
Depends on: 455558

Comment 26

9 years ago
bug 464187 should fix this bug as well.

Updated

9 years ago
Depends on: 464187
Whiteboard: [blocker will fix]

Updated

9 years ago
No longer depends on: 464187

Updated

9 years ago
Depends on: 464187

Updated

8 years ago
Target Milestone: Bugzilla 3.2 → Bugzilla 3.4

Comment 27

8 years ago
pyrzak, is this bug still an issue in 3.5?

Comment 28

8 years ago
That's really a question for john.elion since he is the reporter. The min width of the page on landfill is 1040 without horizontal scroll bar but I'm not sure if that  is ok b/c at 800 you can see all the fields on the page, just some of the custom text fields fall off the edge.  

I think ideally we'd remove the size=40 from all the text fields and replace it with CSS classes so users (like the ones mentioned), could set the width of the fields to whatever they please. As it is they can do it if they play around with the template but messing with CSS seems more reasonable than asking people to touch template code.

Comment 29

7 years ago
Bugzilla 3.4 is now restricted to security bugs. We will retarget this bug (to 3.6 or later) when it's fixed.
Target Milestone: Bugzilla 3.4 → ---

Comment 30

4 years ago
John: is this still an issue in Bugzilla 4.4?
(Reporter)

Comment 31

4 years ago
Created attachment 817179 [details]
User's view in Bugzilla 4.4

Based on the images attached to the original comments, I think this is still a problem in Bugzilla 4.4.  The attached image shows that all of the second column information is still not visible on our user's full-screen monitor.

The user has successfully configured a tool called "Stylish" to narrow the first column so that the second column field values are visible, but "out of the box" Bugzilla shows what is displayed in the attachment.

Printouts from Bugzilla 4.4 were complete and readable, with no fields truncated off the left edge.

Comment 32

4 years ago
What's the width of your screen? If it's smaller than 1024x768, then it's expected to see this behavior.
(Reporter)

Comment 33

4 years ago
Screen resolution is 1680x1050 (monitor is turned sideways, so I guess its effectively 1050x1680 - close to the indicated width limit).  Text is zoomed somewhat, but Firefox option "Zoom text only" is enabled.  Firefox version is 18.0.1.

For me it does appear that the Bugzilla 4.4 display is much improved, but I do see the issues my user has on her screen.  (This user has always been appreciative of the efforts that has been made.)

She did forward me the "CSS Plugin" she wrote to use with "Stylish" that makes things ok for her; she suggested that it might be ok for Bugzilla to maintain something along these lines that was "guaranteed to work" for Bugzilla - i.e., she just wrote CSS that made her page readable, but with no knowledge of Bugzilla innards and which is likely to be broken by a new version.

=== (Stylish CSS plugin to make 2-column display readable ===

@namespace url(http://www.w3.org/1999/xhtml);

@-moz-document domain("pa10-perforce01.gddsi.com") { .bz_alias_short_desc_container {
    margin: 2px 0 !important; 
    padding: 0.1em !important; 
    background-color: rgb(208, 208, 208); 
    font-size: 110% !important; 
    font-weight: bold;
}
.bz_column_spacer {
    width: 0.2em !important;
}
.field_label {
    text-align: right;
    vertical-align: top;
    font-size: 95% !important;
}
.field_value .text_input {
  width: 100%;
  font-weight: bold !important;
  min-width: 15em !important;
}
    pre, code, kbd {
        font-size: 100% !important;
    }
}

Updated

3 years ago
Assignee: guy.pyrzak → ui
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.