Reorganize the header and modules on modal bug UI
Categories
(bugzilla.mozilla.org :: User Interface, enhancement, P2)
Tracking
()
People
(Reporter: emceeaich, Assigned: kohei)
References
(Blocks 2 open bugs, Regressed 1 open bug)
Details
(Keywords: bmo-ux, ux-natural-mapping, Whiteboard: [modal-enhancements])
Attachments
(4 files, 2 obsolete files)
Reporter | ||
Updated•8 years ago
|
Reporter | ||
Updated•8 years ago
|
Assignee | ||
Comment 1•6 years ago
|
||
We’re adding Type, Regressions and Regressed by shortly. It’s time to reorganize the modules and fields. My information architecture homework.
See Also: The Details tab on BzDeck
Assignee | ||
Comment 3•6 years ago
•
|
||
Here’s a draft:
(Header)
- [ID] [Alias]
- Summary
- [Open/Closed] [Reported] [Updated/Resolved]
Triage — set and corrected by a triage owner
- Product
- Component
- Version
- Platform: Hardware + OS
- Type
- Importance: Priority + Severity + Rank
- Points
Tracking — what’s happening now and next
- Status & Resolution
- Milestone (currently Target)
- Iteration
- Due Date
- Project & Tracking Flags
People
- [Reporter]
- [Triage Owner]
- Assignee
- Mentors
- QA Contact
- NeedInfo
- Subscribers (currently CC)
References — internal and external links
- Depends on
- Blocks
- Regressions
- Regressed by
- [Duplicates]
- URL
- See Also
Details — other aspects
- Alias
- Keywords
- Whiteboard
- QA Whiteboard
- Votes
- Other Flags
- Has Regression Range
- Has STR
Crash Data
- Signature
- Stats
Security
User Story
Phablicator Requests
Attachments
Reporter | ||
Comment 5•6 years ago
|
||
Thanks, I like this.
I'm wondering about the order of the Triage and Tracking modules and if we want to define which order they are in depending on the user. I can get that answered in interviews.
Assignee | ||
Comment 6•6 years ago
|
||
Maybe we could allow everyone to reorder these modules. There is a separate bug Emma filed 2 years ago 😁
Reporter | ||
Comment 7•6 years ago
|
||
By default, let's keep all the sections, people & below, collapsed.
Assignee | ||
Comment 8•6 years ago
|
||
(In reply to Emma Humphries, Bugmaster ☕️🎸🧞♀️✨ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #7)
By default, let's keep all the sections, people & below, collapsed.
+1
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 9•6 years ago
|
||
Since Crash Data now comes with a big table, I’ve moved the signature and stats to a separate module like this.
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 10•5 years ago
|
||
Reporter | ||
Comment 11•5 years ago
|
||
What's the status of this work?
Also, I don't see severity and priority in the sample attachment? Is that because those are at defaults?
Comment 12•5 years ago
|
||
(In reply to Emma Humphries, Bugmaster ☕️🎸🧞♀️✨ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #11)
What's the status of this work?
Also, I don't see severity and priority in the sample attachment? Is that because those are at defaults?
It is next up in my review queue.
Assignee | ||
Comment 13•5 years ago
|
||
(In reply to Emma Humphries, Bugmaster ☕️🎸🧞♀️✨ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #11)
Also, I don't see severity and priority in the sample attachment? Is that because those are at defaults?
Yes. It will be visible when Priority != -- OR Severity != normal, as well as in the Edit mode of course. Bug 1548506 has a screenshot for this.
Comment 14•5 years ago
|
||
Actually I would like glob to also review this as the original author of the modal page. glob thoughts on screenshot in comment 3?
Reporter | ||
Comment 15•5 years ago
|
||
(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #13)
(In reply to Emma Humphries, Bugmaster ☕️🎸🧞♀️✨ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #11)
Also, I don't see severity and priority in the sample attachment? Is that because those are at defaults?
Yes. It will be visible when Priority != -- OR Severity != normal, as well as in the Edit mode of course. Bug 1548506 has a screenshot for this.
Since our policy is that an open bug is not considered triaged when it's priority is --
then I think we should display Priority regardless.
Assignee | ||
Comment 16•5 years ago
|
||
(In reply to David Lawrence [:dkl] from comment #14)
Actually I would like glob to also review this as the original author of the modal page. glob thoughts on screenshot in comment 3?
Note that the page layout will be changed soon once we move to a 2-column layout on desktop.
(In reply to Emma Humphries, Bugmaster ☕️🎸🧞♀️✨ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #15)
Since our policy is that an open bug is not considered triaged when it's priority is
--
then I think we should display Priority regardless.
How about showing a label like Not set like the Assignee field’s Unassigned because --
is unclear and can be easily overlooked.
Reporter | ||
Comment 17•5 years ago
|
||
(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #16)
How about showing a label like Not set like the Assignee field’s Unassigned because
--
is unclear and can be easily overlooked.
Yes, that's a great idea.
Assignee | ||
Comment 18•5 years ago
|
||
Updated PR to always show the Priority field.
Assignee | ||
Comment 19•5 years ago
|
||
Reporter | ||
Comment 20•5 years ago
|
||
What happens on bugs which have Program/Project flags as well as status and tracking flags?
Assignee | ||
Comment 21•5 years ago
|
||
Both are displayed in the same Tracking section like this.
Comment 22•5 years ago
|
||
(In reply to David Lawrence [:dkl] from comment #14)
Actually I would like glob to also review this as the original author of the modal page. glob thoughts on screenshot in comment 3?
Most of these look great.
Triage
Triage is the act of assigning an order of treatment, bugzilla tracks the outcomes of the triage. While it's true that field in that section generally contain the results of triage it doesn't make sense for the fields to be labelled as such. None of the other section headers are verbs; "Triage" really stands out as out of place.
This section should be renamed.
Reporter | ||
Comment 23•5 years ago
|
||
(In reply to Byron Jones ‹:glob› 🎈 from comment #22)
Triage is the act of assigning an order of treatment, bugzilla tracks the outcomes of the triage. While it's true that field in that section generally contain the results of triage it doesn't make sense for the fields to be labelled as such. None of the other section headers are verbs; "Triage" really stands out as out of place.
This section should be renamed.
"Next Actions" or "Decisions Made"?
Comment 24•5 years ago
•
|
||
How about "Categories"? or "Status"?
I really see that section as "Descriptive Metadata" but that's a horrible name.
Assignee | ||
Comment 25•5 years ago
|
||
Classification is the right term in this case but we are already using it. If possible, I’d like to change the current Classification label to (Product) Category, and use Classification here. But probably we can’t do it.
So just Categories (= Triage Categories) maybe.
Assignee | ||
Comment 26•5 years ago
•
|
||
So I’ve renamed the Triage section to Categories (thanks :glob for the input!) Plus, (can’t be seen in this screenshot but) the read-only Duplicates field is now displayed even in the Edit mode, as requested by :adw in Bug 1539277.
Comment 27•5 years ago
|
||
This change has been deployed to https://bugzilla-dev.allizom.org for testing and feedback. Please take a look.
Comment 28•5 years ago
|
||
https://bugzilla-dev.allizom.org/show_bug.cgi?id=39 has an empty Details section (both when logged in and when logged out).
You can expand it but there's no visible fields within it until you switch to edit mode.
Comment 29•5 years ago
|
||
The only thing I find a little strange is that the Alias is set in the Details section but displayed in the bug header. I'd have expected it to be edited and displayed in the header since it relates to overriding the bug number.
Assignee | ||
Comment 30•5 years ago
|
||
(In reply to Byron Jones ‹:glob› 🎈 from comment #28)
https://bugzilla-dev.allizom.org/show_bug.cgi?id=39 has an empty Details section (both when logged in and when logged out).
You can expand it but there's no visible fields within it until you switch to edit mode.
It’s a known issue, and it seems a bit hard to solve it due to the current static way to hide the section. Most bugs have the Vote field so it won’t be empty. Will figure out how to solve it later.
(In reply to Mark Banner (:standard8) (afk 9 - 18 Aug) from comment #29)
The only thing I find a little strange is that the Alias is set in the Details section but displayed in the bug header. I'd have expected it to be edited and displayed in the header since it relates to overriding the bug number.
Most bugs don’t have an alias, and it’s like a keyword when it’s used, that’s why I’ve moved to the minor field to the Details section. But yeah, it may confuse some existing users.
Comment 31•5 years ago
|
||
I notice that the "Tracking flags", which is called "Firefox tracking flags" in the current production BMO, is no longer a heading and thus more difficult to find for a screen reader user among all the information modules. I also notice that it is now a link. Was that an intentional change to get rid of the heading assignment?
Assignee | ||
Comment 32•5 years ago
|
||
Yes, that’s an intentional change. All status/tracking information is now grouped in the same module for convenience, and this also solves Bug 1347009. I know each field name is not a header at this time, which will be solved soon in Bug 1350424.
Comment 33•5 years ago
|
||
From a quick look, it would make more sense to me if the "has regression range" field was in the "Tracking" section, as it's usually used together with the relevant branch flags that are also there. (I'm assuming we're intending to move away from the regression
/regressionwindow-wanted
keywords in favour of the newer field at some point in the near-ish future.) Does that sound sensible?
Assignee | ||
Comment 34•5 years ago
|
||
(In reply to :Gijs (he/him) from comment #33)
From a quick look, it would make more sense to me if the "has regression range" field was in the "Tracking" section, as it's usually used together with the relevant branch flags that are also there. (I'm assuming we're intending to move away from the
regression
/regressionwindow-wanted
keywords in favour of the newer field at some point in the near-ish future.) Does that sound sensible?
We can revisit that once the new Is Regression field is added. It won’t be a blocker for this, and for now we may want to keep the Has Regression Range in the Details section as it’s often used together with the regression
or regressionwindow-wanted
keyword.
Assignee | ||
Comment 35•5 years ago
|
||
Merged to master. Feel free to file a new bug if something seems wrong.
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Description
•