show_bug.cgi display layout
after.fallout at gmail.com
Mon Jan 15 17:44:49 UTC 2007
Kevin Benton wrote:
> 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.
As far as I know, this was just for the home page screen and it only
involved saved search buglists.
> 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,
Good. Or simply that several less used blocks occupy the same space in
client side tabs.
> 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.
That could quickly become a nightmare for changes we may want to make to
the templates sometime in the future. We would need to tread very
carefully into these waters.
> 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).
Yes, definitely needed.
A small (hidden by default) comment box would be welcome (by me) as
well. Display it when a user clicks on a # symbol (or something like
that) in the gray bug header bar. On that matter, it could be shown when
you click the edit link in the bar. Then again, the bmo is a place to
fix bugs, not a forum. Having the comment box so far down the page does
seem to make it a little less inviting.
> 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.
Providing visual notification of changes would be good too. Is there
some sort of :changed pseudo class for form elements? That would be an
ideal starting point for this, something like:
> To view or change your list settings, click here:
More information about the developers