<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Bill Barry wrote:
<blockquote cite="mid45ABB077.60100@gmail.com" type="cite">Frédéric
Buclin wrote:
  <br>
  <blockquote type="cite">
    <blockquote type="cite">is great for reporters and people looking
for bugs, I think it is worse for the people actually fixing the bugs.
In a bug you now scroll all the way to the bottom to read the last
couple comments, then scroll back to the top to change some aspect of
the bug, and then back to the bottom to add a comment or reassign it.
      <br>
    </blockquote>
    <br>
That's one of the reasons some of us dislike the UI on b.m.o. For
triagers and QA people who don't need to comment, but only to change
some fields, it's a pain to scroll up and down all the time.
    <br>
    <br>
Another question of debate is the place where the keywords, status
whiteboard and URL fields are. Probably they shouldn't be so high in
the page, as most(?) of us probably don't use or need them. The
assignee and target milestone seem more important. But this is really a
question of taste, and as long as there is no consensus, we will
probably keep the current UI which is by far not perfect, but much
better than the one we currently have in 2.22.
    <br>
  </blockquote>
In our bugzilla (stellarfinancial) most of the users use keywords,
status whiteboard, and assignee. The url field is not important,
neither is target milestone, hardware or OS. We will be implementing a
custom type field (<a class="moz-txt-link-freetext" href="https://bugzilla.mozilla.org/show_bug.cgi?id=9412">https://bugzilla.mozilla.org/show_bug.cgi?id=9412</a>)
or waiting for it to be implemented in cvs and this field will be
important to us.
  <br>
  <br>
I have experimented with creating two separate bug pages (edit-bug and
view-bug) to try to resolve this issue, but I don't feel like I have
gotten positive feedback on it
(<a class="moz-txt-link-freetext" href="https://bugzilla.mozilla.org/show_bug.cgi?id=345674">https://bugzilla.mozilla.org/show_bug.cgi?id=345674</a>, ignore colors; I
am colorblind, they wont stay, they are just there to help identify
sections on the page). The eventual idea would be to have a user pref
about which to initially display on a bug and then allow a user to
switch between the two.
  <br>
  <blockquote type="cite"><br>
One part of the UI which will be ported upstream for 3.0 is the
attachment table (the patch is currently under review) as there is a
good consensus about it.
    <br>
  </blockquote>
What bug is this? Have we looked at considering the darwin bugzilla's
extra features on their attachment tables (highlight row when mouseover
for example)?
  <br>
  <blockquote type="cite"><br>
LpSolit
    <br>
    <br>
  </blockquote>
  <br>
</blockquote>
<font face="Helvetica, Arial, sans-serif">If I remember correctly,
there was a very nice AJAX solution that allowed users to move parts of
the bug display around changing the basic layout to suit their needs. 
I don't know if it makes sense to consider something similar here,
though I don't think it's fair to ask that it would land in 3.0.  My
suggestion is that we allow certain blocks to 1) be collapsible, and 2)
be shiftable - meaning that the sequence can be changed.  For example,
some want the comment entry block at the bottom.  Some want it below
the fields listing.  Some don't want to see certain parts of the bug
display (flags for example).  By allowing blocks to be collapsible and
shiftable, users can move what they need to see first to the top of a
bug.  I agree with the other commenter that mentioned that they thought
there ought to be a commit button near the top of the bug (I think it
was LpSolit).<br>
<br>
In any case, I think we ought to also implement Javascript that checks
to see if any field on the form has been changed before allowing users
to hit their back button or click on one of the page's links.  That
way, users can't leave a page without being given the opportunity to
submit the changes first.  I don't know if this has already been done
in 3.0 yet, though I think it's becoming more and more critical as our
user interface becomes more user-friendly.  Many applications now
auto-submit so users don't have to click on a submit button, making it
more likely that users will forget to click a submit button so their
changes aren't lost.<br>
<br>
Kevin<br>
</font><br>
<div class="moz-signature">-- <br>
<img src="cid:part1.03040701.04020800@amd.com" border="0"></div>
</body>
</html>