Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo Reporter
	Description • 7 years ago

This bug is the development work needed to replace the current HTML header on bugzilla.mozilla.org

The mock-up of the new header is described in bug 1363889 and included here as an attachment.

	Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo Reporter
	Comment 1 • 7 years ago

In this iteration we will not do auto-completion from the search box, but link to search results from a search entered into the box. 

The "://" is no longer a valid logo so it will be replaced with the "m" as described in https://mozilla.ninja. 

The HTML header is a template with several conditionals so there are opportunities to simplify this code, but the goal of this work is to get the new header in place.

We will not put this behind a feature flag or A/B to keep the size of the change small.

	Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo Reporter
	Comment 2 • 7 years ago

A solution for bug 1330451 would be a nice to have, but should not block this. If the header is not static in the first iteration, we can make it static later.

	Kohei Yoshino [:kohei] Assignee
	Comment 3 • 7 years ago

Attaching a newer mockup.

	Kohei Yoshino [:kohei] Assignee
	Comment 4 • 7 years ago

Global Navigation Analysis: https://kyoshino.github.io/bugzilla-ux/global-navigation-analysis/

	Kohei Yoshino [:kohei] Assignee
	Comment 6 • 7 years ago

Some preliminary clean-up work is being done in the dependencies.

	David E. Ross
	Comment 7 • 7 years ago

This RFE was cited as justification for closing bug #1368263.  To quote that citation:  "The profile button containing the logout link will always be displayed on the screen".  However, Attachment 8881824 [details] here does not display a logout link.  It still becomes necessary for the user to know which header icon is the "Account menu item" and also to know that selecting that icon will then expose the logout link.  That is poor design for a user interface.

	Kohei Yoshino [:kohei] Assignee
	Comment 8 • 7 years ago

Why do you think so? That's a common user experience in many applications these days, including but not limited to: Google, YouTube, Twitter, Facebook, LinkedIn, Slack, GitHub, Stack Overflow, Medium, Tumblr, WordPress, Discourse. Because most people don't sign out from an app every time, the Sign Out button is just a noise on the UI.

	Kohei Yoshino [:kohei] Assignee
	Comment 9 • 7 years ago

Try using the "Clear history when Firefox closes" option in Firefox to sign out from all sites when closing the browser: https://support.mozilla.org/en-US/kb/how-clear-firefox-cache#w_automatically-clear-the-cache

	Kohei Yoshino [:kohei] Assignee
	Comment 10 • 7 years ago

Hopefully this first round of the redesign could be implemented before All Hands in Austin. I can't make it but people there will be a bit surprised.

	David E. Ross
	Comment 11 • 7 years ago

(In reply to Kohei Yoshino [:kohei] from comment #8)
> Why do you think so? That's a common user experience in many applications
> these days, including but not limited to: Google, YouTube, Twitter,
> Facebook, LinkedIn, Slack, GitHub, Stack Overflow, Medium, Tumblr,
> WordPress, Discourse. Because most people don't sign out from an app every
> time, the Sign Out button is just a noise on the UI.

Good user interface design means users should not have to hunt for the logout link.  Given the effort already expended on security for bugzilla.mozilla.org, it would be strange to facilitate leaving users logged-on when they no longer are active on that Web site.  The justification quoted in this comment is commonly characterized as a "lemming defense", relying on the poor design of other applications and Web sites to support a poor decision here.

	Gérard Talbot
	Comment 13 • 6 years ago

(In reply to Kohei Yoshino [:kohei] from comment #8)
> That's a common user experience in many applications
> these days, 

Kohei,

I logged in 
https://bugs.webkit.org/
and there is no tracking cookie listed or active for that site. So, I could block every possible tracking cookie with Ghostery - and I am - over there, and every aspects of those webpages would still work as expected.

I logged in
https://bugs.chromium.org/
and there is 1 tracking cookie active for that site: Google Analytics ... which I am filtering, blocking with Ghostery. And every aspects of those webpages, including the sign out link, continue to work, just as expected.

I logged in 
https://bugs.kde.org/
and there is no tracking cookie listed or active for that site. So, I could block every possible tracking cookie with Ghostery - and I am - over there, and every aspects of those webpages would still work as expected.

I finally logged in 

https://www.w3.org/Bugs/Public/

https://bugzilla.gnome.org/

https://bugs.documentfoundation.org/

and there is no tracking cookie listed or active for those 3 sites. So, I could block every possible tracking cookie with Ghostery - and I am - over there, and every aspects of those webpages would still work as expected.

Except for bugs.chromium.org, all those sites are using bugzilla software as a bug tracking system.

	Gérard Talbot
	Comment 14 • 6 years ago

> Attachment 8881824 [details] here does not display a logout link.  
> It still becomes necessary for the user to know which header icon 
> is the "Account menu item" and also to know that 
> selecting that icon will then expose the logout link.

> That's a common user experience in many applications these days, 
> including but not limited to: Google, YouTube, Twitter, Facebook, 
> LinkedIn, Slack, GitHub, Stack Overflow, Medium, Tumblr, 
> WordPress, Discourse.

Each and all 6 bug tracking systems I mentionned before display a logout link without having to select or click any icon or avatar or a gravatar to expose the logout link. The email address (which I partly erased for spam-related reasons) is also clearly viewable, visible and serves to indicate logged in status.

Attached here is Google Chromium Bug tracking system , 1191px wide by 138px tall, 32 Kilo-bytes

	Kohei Yoshino [:kohei] Assignee
	Comment 15 • 6 years ago

Gérard, please ask Ghostery for why the Gravatar image is blocked when you block Gravatar cookies. It's off-topic here.

	Kohei Yoshino [:kohei] Assignee
	Comment 16 • 6 years ago

To clarify, other Bugzilla instances are older versions, having an extremely old UI partially due to technical limitations at that time. Bugzilla has not been given enough UX love for 10 years. Chromium's bug tracking system also looks outdated; they have a plan to adopt Material Design. It makes no sense to compare the latest Bugzilla (BMO) with those ancient sites.

	Gérard Talbot
	Comment 17 • 6 years ago

> ask Ghostery for why the Gravatar image is blocked when you block Gravatar cookies.
Shouldn't you be the one to inquire Ghostery that issue... since the new design requires gravatar?

I do not trust 3rd party tracking cookies - like gravatar - at all. Bugzilla.mozilla.org should not either.

In the past, before this new design, none of this (3rd party tracking cookie gravatar versus Ghostery) was having an impact on basic navigation like login status and log out link.

> older versions, having an extremely old UI

bugs.webkit.org is probably the most usable, clean and clear design for me. Whether you consider it  old and with an extremely old UI does not change my experience of that site.

> Bugzilla has not been given enough UX love for 10 years.

What is wrong (or flawed or incorrect) with the old system? What required to be improved (why and how)? And then, how do you measure, verify that improvements are real and achieved with the new design? 

People behind bugzilla.mozilla.org should be listening to volunteers who have used bugzilla during 5 years (and even much more) to file bug reports, do triaging, QA work, create reduce tests, etc.. rather than labelling comments they dislike or disagree with as offtopic, advocacy and abuse. Long time BMO volunteers may know what could be improved and even how.

The sites under the control of mozilla should match the user-preferred font size for unstyled body text, should not use absolute font size units (to insure scalable design) and should use sufficient color contrast for obvious readability reasons.

	Kohei Yoshino [:kohei] Assignee
	Comment 18 • 6 years ago

I've been using BMO for more than 12 years as a volunteer, contractor and employee, and currently working on Bugzilla UX as a volunteer. Your comments here are obviously off-topic, hence tagged.

	Gérard Talbot
	Comment 19 • 6 years ago

You are the one referring to old versions, extremely old UI, UX love, outdated looks, etc... And I replied to all this. 

I have to set minimum font size to 16px (which is the default font size value in all browsers, including Firefox) just to read the comments in bugzilla.mozilla.org. Otherwise bugzilla.mozilla.org serves me 13px (absolute unit) font size, regardless of my Firefox preference. 
Font size in absolute units is not recommendable by a very wide majority of accessibility groups. 
Same thing with gray text on light gray background.

> It makes no sense to compare the latest Bugzilla (BMO) with those ancient sites.

It does make sense! Those bug tracking system sites work. They achieve bug tracking related functions and goals they are pursuing. They are simple to use and not-too-complex; they do not use anything fancy or "good looking" or avatar dependencies or "bells and whistles" or finely detailed settings. But they nevertheless serve well the goals involved.