452957 - show_bug UI should indicate what fields you've changed

Status: NEW

(Bugzilla :: User Interface, enhancement, P3)

Description

[Dave Garrett]

(This is not quite a regression so much as an added problem with new features.)

Now that everything is edited up top and the radio selections are all gone on the bottom, it's not always as obvious what you're editing when you commit. In the old system your primary change to the bug was clearly selected below your comment. In the new system it's up top and looks exactly as unmodified field.

I propose that any fields that have been changed from their previous values be highlighted in some way. (tint them yellow or something) Thus I'd be able to just look at the top and see what's colored to see what my commit button will do. I believe this could help to reduce accidental changes somewhat or at far least make the system more clear to the user as to what they're doing.

Comment 1

[Guy Pyrzak]

Good idea! In fact, I think I'd also like to see a natural text listing of what has changed next to the bottom commit button. What do you all think? Isn't there another bug to add a commit button to the top?

Comment 2

[Tony Mechelynck [:tonymec]]

(In reply to comment #1)
> Good idea! In fact, I think I'd also like to see a natural text listing of what
> has changed next to the bottom commit button. What do you all think? Isn't
> there another bug to add a commit button to the top?

Don't know if there is, but it might be useful. However, the Bugzilla 3.2 blurb says adding skins is going to be less of a pain than before (or something to that effect). How varied are the available skins at BMO going to be? (ATM there are two, but, let's say, how many and how varied a year from now? Still two? Five? Ten? Twenty?) Wouldn't that kind of customization be "of the right kind" for a selectable skin?

Note also that if you have the default pref setting about adding yourself to the CC list, on many bugs the checkbox to add you will be checked, which is a change to the bug if you [ Commit ]. So if this bug gets FIXED, that checkbox and its label should be highlighted, then if you un-check it they should become un-highlighted.

Also, what kind of highlight for the changes? Pale-yellow background? Red text? Green outline? Text at the bottom of the page? Something else? I suppose this shouldn't be debated in the bug itself, but in some newsgroup/mailing list.

Comment 3

[Dave Garrett]

(In reply to comment #2)
> Also, what kind of highlight for the changes? Pale-yellow background? Red text?
> Green outline? Text at the bottom of the page? Something else?

Skin-specific color is fine by me, but it should never be pale-anything. Bright yellow or bright blue or any bright color is the idea. It should be immediately obvious at a glance as to what's been edited.

I also like the pre-commit log idea.

Comment 4

[Max Kanat-Alexander]

Note that this isn't as high-priority for the default Bugzilla UI, where the comment box is not at the bottom of the page.

Comment 5

[Max Kanat-Alexander]

This is not a regression, just something that would be nice.

Comment 6

[Frédéric Buclin]

Almost a dupe of bug 115040, except your request is to see changes *before* committing changes, not after.

Comment 7

[Guy Pyrzak]

also something that might be nice, is being able to undo these changes, as suggested by justdave in IRC. I like undo, i use it a lot, that being said, I'm not sure we SHOULD do it.

Comment 8

[Jill Foley]

Attachment: patch v1

This patch will highlight changed fields in yellow.

Comment 9

[Jill Foley]

I'm submitting a patch.  It will highlight changed fields in bright yellow.  This is defined in a style sheet.

Comment 10

[Max Kanat-Alexander]

Comment on attachment 356845 [details] [diff] [review]
patch v1

I'm kind of opposed to adding an onkeyup to every input element. Could we perhaps instead create a function that does a getElementByTagName for certain ids and attaches the event to them?

Comment 11

[Max Kanat-Alexander]

Hey Jill. I am SO sorry that it has taken me so tremendously long to get to this patch.

I suppose the reason that it's taken me so long is that we have to discuss whether or not we actually want this feature--or, more particularly, whether or not the feature is worth the code complexity. It's a usability improvement, and it does seem to have been requested by a few users, though I don't think anything about it came up in the CMU HCI study.

LpSolit, justdave--do you have any thoughts on it? I'll also post to the developers@ list about it.

Comment 12

[Max Kanat-Alexander]

Comment on attachment 356845 [details] [diff] [review]
patch v1

Okay, I thought about this a bit, and I think it might be something we want to do only after we have all of show_bug.cgi using field.html.tmpl, because then that would make the implementation very centralized and simple, and not something that we'd have to "remember" every time we made some changes to fields.

If you or another NASA engineer could work on making show_bug.cgi use field.html.tmpl everywhere (in a separate bug, possibly in several bugs for each piece), I'd be pretty happy to take this feature, actually, because then it would be really simple. And the architecture improvement would be something that would benefit Bugzilla anyway, so that would be great.

Comment 13

[Max Kanat-Alexander]

That would also let it work on enter_bug.cgi too, so we'd get even more functionality for less code. :-)