452888 - The status selector is too far from the comment box, leading to a serious usability problem

Status: RESOLVED FIXED

(Bugzilla :: User Interface, defect, P2)

Description

[Max Kanat-Alexander]

The one time that you almost always want to make a comment is when you're changing the status. Although the old knob wasn't a very good UI, it was below the comment box and easily allowed you to do this.

At the very least, both Brendan's workflow and my workflow would be easier if there was an additional "Status" box underneath (or near) the comment box.

I'm OK with the second box only appearing if the user has javascript enabled (since we'd need to use JS to sync the two boxes). We can have the box hidden and disabled in the non-JS UI.

Comment 1

[timeless]

see also bug 452806

from memory, brc sticks the field blob at the bottom instead of the top.

i'm currently using a bunch of prefs <https://bugzilla.mozilla.org/userprefs.cgi> 
skin: [dusk]
Position of the additional comments box: [before comments]
Zoom textareas large when in use (requires JavaScript) : [off]
When viewing a bug, show comments in this order: [newest to oldest]

that give me:
field blob 
comment field 
commit
latest comment 
...
first comment

it's almost tolerable. and so far it's enabled my qa role (mozilla.org: verify+comment) to be done w/o too much pain (it's still painful, ...)

sadly this layout does not work if there are lots of attachments (core) or flags (bugzilla!) because the distance between the comment field and the top of the form is still too big.

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Ideally the common tasks should be either radio buttons as before or buttons; that is:

* a button for RESOLVED/FIXED,
* a button for DUPLICATE with an entry of a bug number,
* a button for reassinging with an email entry (there was something weird about this before, I can't remember what -- I think the bug status ends up in an odd state and you have to do a two-step reassign?), 
* a button for generic resolution.

> I'm OK with the second box only appearing if the user has javascript enabled
> (since we'd need to use JS to sync the two boxes). We can have the box hidden
> and disabled in the non-JS UI.

(Why does anyone care about JS-disabled UI in 2008?)

Also bumping the importance here -- this is a pretty serious usability regression from previous bugzilla versions.

Comment 3

[Frédéric Buclin]

This is not a regression, upstream. If you want a separate bug for b.m.o, file it in the mozilla.org product.

Comment 4

[Frédéric Buclin]

(In reply to comment #2)
> (Why does anyone care about JS-disabled UI in 2008?)

Because many users still have JS disabled, e.g. by installing the Noscript addon.

Comment 5

[Brian Crowder]

(In reply to comment #4)
> Because many users still have JS disabled, e.g. by installing the Noscript
> addon.

I have to say I agree with comment #2:  users running with NoScript (I'm one of them) can easily grant bugzilla a whitelisting.  We shouldn't let the demands of people who don't trust JS from BMO affect the site design.

If it is a matter of protecting people from malicious JS served from attachments, then the Right Fix seems to be serving the attachments from a different domain (so that it can be treated differently by NoScript).

Either that, or we should perhaps consider abandoning this rule for BMO UI development as we move forward, and let those who fear JS work on/maintain an alternative clunky UI for their own purposes.

Comment 6

[Frédéric Buclin]

(In reply to comment #5)
> If it is a matter of protecting people from malicious JS served from
> attachments, then the Right Fix seems to be serving the attachments from a
> different domain

Nothing new here, bug 38862.

Comment 7

[Tony Mechelynck [:tonymec]]

(In reply to comment #5)
[...]
> Either that, or we should perhaps consider abandoning this rule for BMO UI
> development as we move forward, and let those who fear JS work on/maintain an
> alternative clunky UI for their own purposes.

Maybe a separate skin to make the UI "nicer" for javascriptophobes (or ought I to say Iauagrammaphobes? ;-) )? Now that (IIUC) Bugzilla 3.2 makes skinning easier?

Comment 8

[Guy Pyrzak]

We've got a great solution for this:
A. Put a commit button at the top of the page per bug 344559
B. Make an anchor to both the top and bottom commit buttons.
C. Under the comment put a hyperlink to "change the status"
D. It will take you to the top of the page (where the status drop down is) with both the commit and the status in view, and with focus on the status drop down. 

Done. Max and I like this solution for 2 reasons.
1. Less code, keeps the js/template simpler
2. Degrades well for the js-phobes b/c the anchor will still work, just focus won't.

Comment 9

[Brendan Eich [:brendan]]

You've added another click that scrolls the page. It's better than current, but worse than what was there before.

Again, it is bad form as well as unusual, in my 10 years of BMO experience, to resolve a bug without comment. For those 10 years the controls to do both were close. Why mess with this?

I really don't give a damn (and I'm not being "sensitive" about JS here) about reason #2, and reason 1 seems weak. Don't other apps have templates that allow multiple ways to do things? TMTOWTDI.

/be

Comment 10

[Guy Pyrzak]

Ok, so with Brendan's comments taken to heart, I thought and though, and then I realized that I was being too complicated. So, yet another option! This one should make all involved quite happy. Check it out on landfill, feel free to give comments.
https://landfill.bugzilla.org/pyrzak/show_bug.cgi?id=example

Something I will need to improve upon is where the commit button appears. But what is nice about this is it doesn't break any workflows, for commenting on status OR comments, keeps the important information together as a unit and lets people decide where they want things to appear.

For the BMO implementation it would just start in the location that you define in your prefs and jump around later. 

Please note this version is not "review ready" but could be made so, fairly quickly. Things missing are good behavior without js, and remembering where the comment box is on errors or refresh.

Please let me know what you guys think, this is something I'd like to fix for both BMO and Bugzilla.

Comment 11

[Guy Pyrzak]

Frederic pointed out he didn't see any difference. Scroll to the bottom of the comments area, you'll notice a link that says "Add a comment", I'll need to make the link more salient, but try clicking on it.

You'll notice the comment box moves to the bottom of the comments area, with whatever comments you have previous entered! 

If you are wondering why am i doing this, I'll explain. There are 2 work flows we'd like to support. 
1. Change the status (most commonly changed field in most Bugzillas) and other fields, make a comment, commit.
2. Read the comments and add a comment based on other people's comments, commit.

Having 2 selectors would require me to write some kind of data binding, keep everything in sync and also handle the non-js state in either a complex way of checking the old status vs new status etc. I could go through all the JS and perl changes that I would have to make, but basically it is a lot for only moving the most commonly edited field, and ignoring the rest.

The real problem is there are 2 use cases to add comments. So instead of moving status, which is just 1 field you might need to comment on when editing, instead move the comments field, which is the real thing you need to have available to you in these 2 work flows.

I've also moved the comments above the attachments and the groups, neither of which are often edited directly.

As far as usability, I don't think this is the final or perfect direction, but it does allow for the 2 use cases to work without adding complexity to the code base.

Comment 12

[Tony Mechelynck [:tonymec]]

(In reply to comment #11)
[...]
> If you are wondering why am i doing this, I'll explain. There are 2 work flows
> we'd like to support. 
> 1. Change the status (most commonly changed field in most Bugzillas) and other
> fields, make a comment, commit.
> 2. Read the comments and add a comment based on other people's comments,
> commit.

What about:
Read the comments made by other people, change the status (e.g. to INVALID, WONTFIX, DUPLICATE, whatever) based on these comments, add a comment to explain the change, commit.

Wouldn't this workflow (which I don't think is atypical) require a lot of scrolling back and forth?

Comment 13

[Guy Pyrzak]

You're correct, what you described is a combination of the first two work flows.

To test your work flow I just did that motion, I thought it was relatively easy due to anchors at both sides of the page, or scroll back to the top of the page, or use the home/end key. There is a link at the top and the bottom of the page, to the last comment and top of the page respectively. Presumably this is b/c this already happens quite frequently for fields other than status which is the only field the old knob facilitated.

I do think that Bugzilla needs these links, so we should probably add that as a blocker to this bug.

There are lots of times when after reading the whole bug, you want to go back to edit the bug fields, not just status (but it is the most edited field!). I personally would rather have all the bug info at the top of the page, however, some instances have the bug fields at the bottom of the bug to facilitate exactly what you are describing. 

However, if in the end BMO wants the status at the bottom, it can moved there very easily, but then this should be filed to a bmo bug, not a Bugzilla bug.

Comment 14

[Tony Mechelynck [:tonymec]]

In reply to comment #13
Ah, yes, I already knew the "Last comment" link near top right (which, however, goes to the _top_ of the last comment: if it's a long one you'll still have to scroll to get to the textarea) and now I notice a "Top of page" link in small type near bottom right. In addition, my SeaMonkey-trunk browser can scroll to top or bottom in response to the Home and End keys respectively, so, yes, the workflow I described can be made easy enough -- after some training.

I rarely use Bugzilla on other sites than BMO and if their pages are arranged in a less than ideal manner from my point of view it doesn't matter too much for me; but BMO is the only Bugzilla where I took the trouble of _asking_ for editbugs (if I have it elsewhere it's because everyone has it) and I use it regularly (though I admit I still do it "in my free time" and thus less assiduously than some other people). As has been said, the advantage of having status selection at the bottom was that, after reading comments and maybe writing a reply to them, it was immediately obvious whether the present status was "the right one" and which change if any was required. Now we have to go back to the top just to notice that maybe no status change was required (and that we could have hit the bottom "Commit" button). Well, I guess I can live with that but I'd prefer to see this bug escalated to at least "minor" severity.

Of course, the advantage of having the status displayed at the top is that all the "generic" bug info is together in a kind of heading. It might be a good idea though (I'm not sure) to have a status/resolution _display_ at the top and its _changing widget_ (rolldown, radiobutton, whatever) at the bottom, at least it would encourage people to read the comments before changing the status. But I haven't yet thought this thing all the way through.

About other fields: well, yes, some Bugzillas such as Novell/SuSE have a header (readonly) at the top, and, if you're logged in, all the header-info changing widgets at the bottom. I'm not sure whether it's really better than the BMO system where everything is at top except the "Additional Comments" textarea, a Commit button (recently duplicated top _and_ bottom) and (before the 3.2 upgrade) the status changing widgets.

Comment 15

[Brendan Eich [:brendan]]

(In reply to comment #14)
> As has been said, the advantage of having
> status selection at the bottom was that, after reading comments and maybe
> writing a reply to them, it was immediately obvious whether the present status
> was "the right one" and which change if any was required.

Exactly. I hate to "me too", so I'll try to add value below, but your point, well put here, is overriding and it deserves a response.

> Now we have to go
> back to the top just to notice that maybe no status change was required (and
> that we could have hit the bottom "Commit" button). Well, I guess I can live
> with that but I'd prefer to see this bug escalated to at least "minor"
> severity.

I don't want to "live with that". Tools should serve users. There's a ten year tradition here, and it's not arbitrary -- it's exactly the "workflow" (or common sense and courtesy) you describe: people read bugs downward, then write a comment and possibly change status. Not all comments require status changes, but IMHO all status changes deserve comments.

Why shouldn't the status controls be at the bottom as they were?

Answers about JS being disabled or hardships duplicating controls without JS are implementation issues at most, or "don't cares" at the least.

> Of course, the advantage of having the status displayed at the top is that all
> the "generic" bug info is together in a kind of heading.

Except too often flags and such push Commit below the fold (on my MBP). That is worse than before.

> It might be a good
> idea though (I'm not sure) to have a status/resolution _display_ at the top and
> its _changing widget_ (rolldown, radiobutton, whatever) at the bottom, at least
> it would encourage people to read the comments before changing the status. But
> I haven't yet thought this thing all the way through.

That's not a bad idea: changes to status really deserve a comment, so put them at the bottom by default (where the comment textarea goes by default). But show as much (and use more horizontal space if you can! below-the-fold is a bug!) as possible of status up top.

> About other fields: well, yes, some Bugzillas such as Novell/SuSE have a header
> (readonly) at the top, and, if you're logged in, all the header-info changing
> widgets at the bottom. I'm not sure whether it's really better than the BMO
> system where everything is at top except the "Additional Comments" textarea, a
> Commit button (recently duplicated top _and_ bottom) and (before the 3.2
> upgrade) the status changing widgets.

It may be that we need experiments, GreaseMonkey scripts, to find better UX here. But after a week+ I'm having Fitts's law fits! I constantly go down to comment, then back up, then sometimes scroll to get below-the-fold Commit. Argh!

/be

Comment 16

[Guy Pyrzak]

Ok, working on this bug next, stay tuned for the magic data binding version of 2 statuses, perhaps with a revival of the radio button style knob, we'll see. Thanks for all the feedback.

Comment 17

[Frédéric Buclin]

Max, should we block 3.2 on it?

Comment 18

[Max Kanat-Alexander]

Yes, after some serious deliberation with myself, I agree to block 3.2 on this fix. However, if at any point it is our *last* blocker (that is, the only thing actually stopping us from releasing 3.2), I may change my mind.

Comment 19

[Samuel Sidler (old account; do not CC)]

Any status update on this. I'm just now going through bugmail and consistently running into this when resolving bugs and commenting.

Comment 20

[Guy Pyrzak]

working on it, just got a bit distracted with real life and paid work, you know how it is. Finishing this up this week probably.

Comment 21

[Guy Pyrzak]

Attachment: Patch v1

Here you go guys, rip it to shreads! Tested on Firefox, didn't bother testing it on all browsers quite yet, wanted to see what you all thought of the style of the change etc.

Comment 22

[Frédéric Buclin]

Comment on attachment 341116 [details] [diff] [review]
Patch v1

The UI looks good with JS enabled, but both status fields are displayed with JS turned off, in which case the first one always wins, making the one below the comment textarea useless. With JS off, it would probably be better to display a link pointing to the first status field.

Comment 23

[Guy Pyrzak]

Attachment: Patch v2

Comment 24

[Frédéric Buclin]

Comment on attachment 343917 [details] [diff] [review]
Patch v2

patch: **** malformed patch at line 314: @@ -139,7 +165,7 @@

Comment 25

[Guy Pyrzak]

Attachment: Patch v3

Comment 26

[Max Kanat-Alexander]

Looking at the patch, I really think this is just too much change to take on the branch. (bmo is still free to take this as a backport for their 3.2 though) Also, I kind of think we're working around a problem instead of solving the root issue.

In the GNOME Bugzilla, the layout goes: comments, attachments, comment box, edit form. Then the comment box is always close to the relevant parts of the edit form, which solves this whole problem without us having to go through some craziness...

We could take the "simple table" template from Bug 373418, put it at the top, and then generally re-arrange the form entirely (with a link to the editing form and the details from the top). What would people think about that as a solution to the specified problem, instead?

(Those curious can see what the "simple table" looks like [though it doesn't have all the fields here that it will actually have] in attachment 257767 [details]. The "hide the form" parts of that bug would not be carried over.)

Comment 27

[Max Kanat-Alexander]

I'm going to implement what I talked about above, and post a link to an installation where it's working, so that everybody can see what it would be like.

Comment 28

[Max Kanat-Alexander]

Attachment: Move the Edit Form, v1

OK, here's what I was talking about--moving the edit form to the bottom and re-arranging the page. This looks like a lot of code change, because things are moving, but really I just cut-and-pasted a lot of code around.

Comment 29

[Max Kanat-Alexander]

By the way, this is live at: http://landfill.bugzilla.org/mkanat3/show_bug.cgi?id=2323

Comment 30

[Max Kanat-Alexander]

Another option is to float right a box containing the info that's currently in the "simple table" at the top, kind of like GNOME's Bugzilla does now.

Comment 31

[Max Kanat-Alexander]

Attachment: Move the Edit Form, v2

I fixed up a few other things, and I synced up the gray being used for the <th>s with the other tables on show_bug.

Comment 32

[Frédéric Buclin]

Personally, I think this is a HUGE change you want to implement just a few days before RC2. FYI, what you suggest is closer to KDE's Bugzilla than GNOME's one. Anyway, I have a few comments based on the UI only:

- There is a lot of missing information in the readonly table, such as keywords, status whiteboard, dependencies, group restrictions and flag setters; said otherwise: everything that the edit form offers that you omit in your table. We all have different needs and are all looking at different pieces of information. I disagree with your selection as you force everyone to use yours and only yours. I don't know on which data this selection is based, if any, but it certainly doesn't match my workflow better. And I know Firefox folks are going to yell because at least keywords and the status whiteboard are missing.

- The way flags are presented is awful and hard to read.

- Probably several users, such as me, read comments from bugmail, and then know why they access a bug and know what they want to edit there. This means having comments first doesn't help my workflow because I already read them.

- You should blog on this new UI, with screenshots, you should talk about it in developers@, we should talk about this at our meetings, and.... we should wait for feedback! This a huge enough change in the UI/workflow to not be checked in based on a single reviewer's approval. IMO, that's not something for RC2.

- I could agree with this UI if there was a user pref to keep the old UI + pyrzak's implementation. Either that, or make the readonly table more complete.

- Another reason I don't like this table is because data is presented differently from the edit form, i.e. fields are not displayed in the same order, meaning I have another "schema" to "learn". Add to this the form we have when filing bugs, and this makes a third way to display data. Painful!

Comment 33

[Max Kanat-Alexander]

(In reply to comment #32)
> - There is a lot of missing information in the readonly table, such as
> keywords, status whiteboard, dependencies, group restrictions and flag setters;

  Agreed, but I made it extremely hookable, if you look at the code. It will be very easy for local customizers to add new columns and rows in a way that flows smoothly with future upgrades.

> And I know Firefox folks are
> going to yell because at least keywords and the status whiteboard are missing.

  Yep, I fully expect bmo to customize that.

> - The way flags are presented is awful and hard to read.

  For sure! Do you have any suggestions for how to display them better? I used to display the flag setters in bold, but pyrzak and I agreed that that isn't actually very important information--it's much more important that the flag is set than who set it.


> - Probably several users, such as me, read comments from bugmail, and then know
> why they access a bug and know what they want to edit there. This means having
> comments first doesn't help my workflow because I already read them.

  Yes, I thought about that too. That's why there's a link to the edit form and to add a comment near the top of the page.

> - You should blog on this new UI, with screenshots, you should talk about it in
> developers@, we should talk about this at our meetings, and.... we should wait
> for feedback! This a huge enough change in the UI/workflow to not be checked in
> based on a single reviewer's approval. IMO, that's not something for RC2.

  Yeah, I agree--I will ask for a broader review, but I wanted some feedback on the bug first.

> - Another reason I don't like this table is because data is presented
> differently from the edit form, i.e. fields are not displayed in the same
> order, meaning I have another "schema" to "learn". Add to this the form we have
> when filing bugs, and this makes a third way to display data. Painful!

  Hmm, maybe I could re-order the simple table.

Comment 34

[Frédéric Buclin]

(In reply to comment #33)
>   Agreed, but I made it extremely hookable, if you look at the code.

Maybe, but this won't help if I decide I want to see fields which the maintainer doesn't want to add. IMO, you should display all the data, but some rows of your table would have the .bz_default_hidden class (or a name like that; I don't remember it by heart) so that they would be hidden unless I override this class from my chrome/userContent.css own file. Hidding "advanced" fields from newbies is fine as long as it doesn't prevent advanced users from having direct access to the data they need. After all, advanced users are the ones who use Bugzilla daily; not newbies reporting a bug occasionally.


>   For sure! Do you have any suggestions for how to display them better?

Yes, display them vertically aligned, as they are in the edit form, but on the far right, in a single column. You can use rowspan="NNN" so that all flags are displayed in a single cell without breaking the table display. For me, it's still important to know who requests or sets what.


>   Yes, I thought about that too. That's why there's a link to the edit form

This is still one more click to access the edit form. But I suppose I could live with this one.


>   Hmm, maybe I could re-order the simple table.

This would really help, visually.

Comment 35

[Guy Pyrzak]

In terms of UI change, I agree this is HUGE for a release this close, although in terms of code this probably isn't as big of a change as the code I had to write. However, one thing I am almost sure of is that this patch will reveal even more usability issues and will require an RC3, but as long as we're ok with that I say we should try it out and see how people feel about it. 

I do think we should do more with the top section of the page to make it more aesthetically pleasing. I would have gotten to it this weekend but RL got in the way. 

I'll see what I can do in terms of beautification this week. I do think something of this flavor is probably what we need to do, however, having the comments anywhere but the bottom of the page is kinda strange for me, but that's a pref I believe, and just my personal opinion.

Comment 36

[Max Kanat-Alexander]

Attachment: v3

Okay, here is what I think is the final version of this UI (at least, this is all the edits that I think I'm going to make to it at the moment). If you examine the code, you'll notice that the simple table now has many extra elements that are hidden by CSS. This allows admins to easily display them by modifying the skin, or for individuals to show them by modifying their userContent.css, without adding more user preferences to Bugzilla.

Comment 37

[Max Kanat-Alexander]

In terms of what release this goes in, I think the response from Mozilla indicates that we can't release 3.2 with the UI that it currently has, even though it's a huge improvement over 3.0.

So far, all of the initial responses to this new UI have been positive. Though people are at first a bit surprised that things are in different places, they have surprisingly non-negative reactions to the changes.

So I'd like to target this to 3.2. This bug was pretty much the whole reason I was considering having an RC2 anyhow. I suspect that the feedback from RC2 will be enough. 

I agree that it's dangerous to change the UI this much, this close to a release, but given the initial reactions I'm having positive thoughts that we'll come out OK.

Comment 38

[Max Kanat-Alexander]

Two things about the current patch:

1) I'm not happy with how the Summary/Alias items are aligned in the edit form. I'm moving them manually over with CSS, because the two columns in the edit form are actually separate tables and I can't span them. :-( However, I think things are OK.

2) Another option for the simple table is to move it to the right of the page and have it displayed like the GNOME Bugzilla does it, but I think that would make things very difficult for the Assignee row, Reporter row, and any other row that has lots of data in it.

Comment 39

[Max Kanat-Alexander]

Comment on attachment 345668 [details] [diff] [review]
v3

OK, wait. Thanks to a little talk with mconnor, I have a WAY BETTER idea for now about how to fix JUST this regression, and now we don't have to do lots of crazy stuff during the RC phase. I still want to move around the form a lot, and I've filed bug 462488.

We should display a non-editable status in the main form, and an editable status below the comment box. When somebody clicks the "(edit)" link that's next to the non-editable status, the editable status and the non-editable status swap places. We don't need two boxes, we just need one that moves around. That should be much simpler.

Comment 40

[Guy Pyrzak]

(In reply to comment #39)
> We should display a non-editable status in the main form, and an editable
> status below the comment box. When somebody clicks the "(edit)" link that's
> next to the non-editable status, the editable status and the non-editable
> status swap places. We don't need two boxes, we just need one that moves
> around. That should be much simpler.

GAH! Ok, Although I already indicated this idea in a comment (see comment #10), I'll be happy to do this one and finish bug. I think I'm also learning a bit about when people say "this is a horrible idea" what they mean. Thanks for the help mkanat and mconor.

Comment 41

[Guy Pyrzak]

Attachment: Move Status with Edit Patch v1

Comment 42

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #39)
> When somebody clicks the "(edit)" link that's
> next to the non-editable status, the editable status and the non-editable
> status swap places. We don't need two boxes, we just need one that moves
> around.

I feel like we're still overthinking this.  The question seems to be "how can we best incorporate two status selectors" but that presumes we need two status selectors.

Let me ask a different question: when will you (human users) ever change the status of a bug without leaving a comment, or at least reading the existing comments first?  Any time you resolve a bug, you should leave a comment, at least following good bug practices: a checkin comment for FIXED, some sort of explanation or summary of previous comments for INVA/INCO/WONT/WORK.  The only case I don't see an absolute need for a comment is DUPL (though a comment is often still useful), and even there you need to read the comments first.

Similarly, for the NEW/ASSI transition, these often involve comments ("the testcase shows a valid problem; confirming", "Assigning this to $underling to fix", etc.).  Many times the ASSI transition even takes place on the patch screen, where this UI isn't even in play.

It seems to me, then, that in the vast, vast majority of cases where a human is making status/resolution changes to a bug, the person should be leaving a comment when doing so (or needs to read existing comments anyway).  This then argues that we should return the Status line at the top of the bug to read-only and add an editable status field adjacent to the comments box.

That solution also seems to have the advantage of being simple (no magic flying status field), not requiring excess scrolling (except perhaps in very uncommon cases I can't think of) or jumping around in the bug via links, working (better) with JS disabled, and not adding some strange table-view.  (It also happens to duplicate much of Brendan's arguments earlier in the bug, which is bad form, but it just seems like we've lost sight of the simple solution and are trying to over-engineer a more complex solution for a use-case that is unclear whether it exists and which should be discouraged if it does.)

Comment 43

[Guy Pyrzak]

Attachment: Leave It alone patch v1

Here is a patch with smokey's suggestion, I'll let you guys battle it out in IRC. But please don't change the assignee without saying why.

Comment 44

[Max Kanat-Alexander]

(In reply to comment #40)
> GAH! Ok, Although I already indicated this idea in a comment (see comment #10),
> I'll be happy to do this one and finish bug. I think I'm also learning a bit
> about when people say "this is a horrible idea" what they mean. Thanks for the
> help mkanat and mconor.

  Hahahaha. I'm sorry. :-) I've been through the same experience of writing a lot of stuff and then not having it land, I know what it's like.

Comment 45

[Max Kanat-Alexander]

Comment on attachment 345787 [details] [diff] [review]
Leave It alone patch v1

Yeah, looks fine to me. :-) Can we get maybe an "(edit)" anchor that focuses the editable status box, to make it easier on people who happen to be using the form?

Comment 46

[Max Kanat-Alexander]

Comment on attachment 345757 [details] [diff] [review]
Move Status with Edit Patch v1

I'm in favor of Smokey's suggestion.

Comment 47

[Guy Pyrzak]

Attachment: Leave It alone patch v2

Gah, ok, can people please actually read suggestions that I make before ignoring the stupid HCI person. Saying things like, I like the hyperlink that jumps but since I use the bottom status more can we put it down there, is much more productive than people just saying "I WANT IT!". Anyway, please r+ and a+ and we'll get this in and close the big usability snafu of 3.2.

Comment 48

[Max Kanat-Alexander]

Comment on attachment 345837 [details] [diff] [review]
Leave It alone patch v2

Instead of all that bug.user.canedit stuff, though, just check bug.check_can_change_field('bug_status', 0, 1) which works even if people customize check_can_change_field.

Comment 49

[Max Kanat-Alexander]

Comment on attachment 345837 [details] [diff] [review]
Leave It alone patch v2

Oh, wait, though. You used an anchor, which will move the page so that the comment box is hidden, no? I think it'd be better to focus() the status box.

Comment 50

[Guy Pyrzak]

(In reply to comment #49)
> (From update of attachment 345837 [details] [diff] [review])
> Oh, wait, though. You used an anchor, which will move the page so that the
> comment box is hidden, no? I think it'd be better to focus() the status box.

Used that for people who have JS turned off. Do you want it to use focus only, or use focus if JS is turned on?

Comment 51

[Guy Pyrzak]

Attachment: Leave it alone patch v3

here it is with the focus and the anchor if js is turned off.

Comment 52

[Max Kanat-Alexander]

Comment on attachment 346078 [details] [diff] [review]
Leave it alone patch v3

Sweet, yes, that's exactly what I wanted.

By the way, why the "bug_status_top" div?

Comment 53

[Max Kanat-Alexander]

Thank you so much for all your work on this, Guy. :-) You're the man. :-)

Comment 54

[Guy Pyrzak]

(In reply to comment #52)
> (From update of attachment 346078 [details] [diff] [review])
> Sweet, yes, that's exactly what I wanted.
> 
> By the way, why the "bug_status_top" div?

It was from the moving version of the patch, I'll remove it on check-in.

Comment 55

[Guy Pyrzak]

HEAD:
Checking in skins/standard/show_bug.css;
/cvsroot/mozilla/webtools/bugzilla/skins/standard/show_bug.css,v  <--  show_bug.css
new revision: 1.9; previous revision: 1.8
done
Checking in template/en/default/bug/edit.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v  <--  edit.html.tmpl
new revision: 1.137; previous revision: 1.136
done
Checking in template/en/default/bug/knob.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/knob.html.tmpl,v  <--  knob.html.tmpl
new revision: 1.38; previous revision: 1.37
done

3.2 BRANCH:
Checking in skins/standard/show_bug.css;
/cvsroot/mozilla/webtools/bugzilla/skins/standard/show_bug.css,v  <--  show_bug.css
new revision: 1.6.2.2; previous revision: 1.6.2.1
done
Checking in template/en/default/bug/edit.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v  <--  edit.html.tmpl
new revision: 1.125.2.10; previous revision: 1.125.2.9
done
Checking in template/en/default/bug/knob.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/knob.html.tmpl,v  <--  knob.html.tmpl
new revision: 1.36.2.1; previous revision: 1.36
done