Closed Bug 1051877 Opened 10 years ago Closed 10 years ago

Clicking the service icons next to "Sign in with" should start the login process for that service

Categories

(developer.mozilla.org Graveyard :: Sign-in, defect)

All
Other
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: sheppy, Unassigned)

References

Details

(Whiteboard: [specification][type:change])

What feature should be changed? Please provide the URL of the feature if possible.
==================================================================================
While the drop-down menu is probably necessary for the purpose of various responsive design issues, and clarity (by offering labeled buttons in the menu), the UX as it stands looks like clicking on the GitHub or Persona icon should start the login process for the respective service. We should make that so.

What problems would this solve?
===============================
This would fix UX confusion that I'm pretty sure will arise.

Who would use this?
===================
Most users that log in.

What would users see?
=====================
No visual changes.

What would users do? What would happen as a result?
===================================================
The GitHub and Persona icons at the top of the page would each directly take you to a login page when clicked.

Is there anything else we should know?
======================================
Component: General → Login
Severity: normal → minor
This is a change in the way this widget was intended to work. Adding this functionality is not without its problems:

1) people will have to modify their behavior twice (once when now, once when we remove these icons later)
2) people will complain when we remove this functionality (the icons will have to go away once there is a 3rd service)
3) we'll be writing code we intend to remove later
4) potential confusion for keyboard and touch users

The other option is to make the icons not look like click-able buttons.

But given that not-clickable icons will also be less visible and that we are trying to raise the profile of our new login option I think it is worth it to do it for now, if it is going to be relatively easy.

:davidwalsh 
- is having interactive elements inside an interactive element going to be problematic? 
- is it possible to suppress the clickable icon functionality for touch and focus users? (I'm not sure I want to yet, I need to sleep on the UX for this but, in theory, is it possible and/or a pain?)
Blocks: 1046775
No longer blocks: 1049958
Flags: needinfo?(shobson)
Flags: needinfo?(dwalsh)
Blocks: 1055708
Talked with David about this on IRC and the plan is:

- icons are clickable 
- users on touch devices cannot tap them, they will have to pick out of the drop down (this is to avoid user errors since they're so small)
- users cannot focus on them (this is so keyboard users only have to tab past these links once, they can pick the service they want by tabbing to the drop down)

There is low level dissatisfaction with this widget but I think it will have to be entirely re-designed to address all the concerns and we're a little late in this process for that :/ 

Once we add a third service the icons will not appear outside of the drop down menu and that will make managing the functionality around this easier.
Flags: needinfo?(shobson)
Clearing needinfo -- there's a big PR in and discussion on that should be moved there.
Flags: needinfo?(dwalsh)
Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/862e8da3a985b39af8ce34989289cef8832e0326
fix bug 1051877 - Launch signin windows/links when icons within header login when clicked

https://github.com/mozilla/kuma/commit/42c5332b576c35b8c9c598fe03f136333f532499
Merge pull request #2680 from darkwing/service-icons-1051877-reflogged

fix bug 1051877 - Launch signin windows/links when icons within header login when clicked
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.