Closed Bug 1076867 Opened 10 years ago Closed 10 years ago

Create UI for allowing users to manage multiple e-mail addresses to their account

Categories

(Participation Infrastructure :: Phonebook, defect, P1)

2015-2.1
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: pierros, Assigned: wbowling)

References

()

Details

Attachments

(5 files)

We need mockups and actual UI coding for managing and displaying multiple email addresses per profile/account
Our UI changes will be on the View Profile template as well as the Create/Edit Profile template. = Some user stories = Managing multiple email addresses - As a user, I want to add additional email addresses to my profile so that Mozillians.org and other Mozilla apps know about my multiple email addresses. - As a user, I want all additional email address I add to my profile to be verified so that Mozillians.org knows I own the email address. - As a user, I want to indicate my primary email address, so that I can choose where Mozillians.org emails and communications from Mozilla are sent. - As a user, I want to be notified if an additional email address I try to add to my profile is associated with another profile, so that I know why I can't add that email address. (See 1076891 for migrating duplicate profiles) - As a user, I want set a privacy level for each email address on my profile, so that I can choose which emails are displayed publicly or to vouched Mozillian. - As a user, I want to remove an email address on my profile (as along as at least 1 email address still exists) so that email address is no longer stored on my profile. Displaying multiple email addresses - As a vouched Mozillian, I want to view all the email addresses for a user on their profile so that I can see their different email addresses. - As a public user, I want to view only the public email addresses on someone's profile, so that I can see their public email addresses.
Presently languages are the only existing example we have on Mozillians.org where a user can have multiple entries and continue to add more options. There are obviously more requirements in the user story William posted in comment #2 but it's a good starting point to build on top of. Here, I've mocked up what it would look like if the language selector was an email selector.
Questions - * will a user be able to log into their mozillians account with any email address they've verified is theirs? * what workflow do we want to send user the story - "As a user, I want all additional email address I add to my profile to be verified so that Mozillians.org knows I own the email address."
Attached image multiple-emails-v2.png
version 2 of language management modified into an email management. Picking permissions per email is a bit unprecedented on the profile in other sections.
(In reply to Matt Brandt [:mbrandt] from comment #3) > * will a user be able to log into their mozillians account with any email > address they've verified is theirs? Yes - this is tracked in bug 1076889 > * what workflow do we want to send user the story - "As a user, I want all > additional email address I add to my profile to be verified so that > Mozillians.org knows I own the email address." We're still figuring out the workflow here. More discussion as a team is needed and ideas are welcome. (In reply to Wray Bowling [:wbowling] from comment #4) > Created attachment 8501791 [details] > multiple-emails-v2.png > > version 2 of language management modified into an email management. Picking > permissions per email is a bit unprecedented on the profile in other > sections. This looks great! A question and a couple comments - What happens when a user clicks 'Set as primary'? Does that trigger an AJAX request that immediately saves that change? Note that we currently do not have any AJAX profile edits saved. We only update a profile when a user clicks the Update Profile button. - The email address field in the Edit Profile is shown as a dropdown box, but a text box is needed to input an email address. - Perhaps another approach is to not have text boxes. Instead, clicking on the Add Email link would as the user to sign into Persona with another email address. I'm not sure if this is feasible. It may cause the user to be signed out of their original email address or cause UX issues.
(In reply to William Reynolds [:williamr] from comment #5) > (In reply to Matt Brandt [:mbrandt] from comment #3) > > * what workflow do we want to send user the story - "As a user, I want all > > additional email address I add to my profile to be verified so that > > Mozillians.org knows I own the email address." > > We're still figuring out the workflow here. More discussion as a team is > needed and ideas are welcome. Can you verify your own email address? That's rather commonplace. Or would someone else need to do it? I've never heard of that before. Perhaps a mechanical turk style system would do the trick. > - What happens when a user clicks 'Set as primary'? > ... > We only update a profile when a user clicks the Update Profile button. That's a superb policy/observation. I worked today on changing it to something that be cancelled if you don't press submit. > - The email address field in the Edit Profile is shown as a dropdown box, > but a text box is needed to input an email address. Just an artifact of using photoshop to mock this up fast. :) > - Perhaps another approach is to not have text boxes. Instead, clicking on > the Add Email link would as the user to sign into Persona with another email > address. I'm not sure if this is feasible. It may cause the user to be > signed out of their original email address or cause UX issues. That's interesting, too. But as you stated before we don't want to save anything unless they press submit. If they are logged out on this action and logged back in then any other changes to their profile would be lost. On sites like StackExchange, there's no real "primary" account. What motivation do we have for setting primary addresses other than sort order on the profile or perhaps selecting which address emails will go to?
Flags: needinfo?(williamr)
Flags: needinfo?(pierros)
The team had a technical discussion today and decided the UI should include: * Email input box for adding another email address * Indicator if an email is verified or unverified * Button to verify an unverified email (verification happens on a separate page) * Button for removing an email address * Button for choosing a primary address * Regular select drop-down Visibility levels for each email address (Privileged, Mozillians, Public) We can either expose this UI on the Edit Profile page or a separate Email Settings page. Let's start working on this and make a PR, so that the back end pieces under development can be connected to the UI. This will help the back end development. If it's helpful, we can break the above into smaller pieces and/or polish the styles in a follow up PR. The main goal is to create an MVP of the email management front end code and iterate from there. Wray, let me know if you have any questions or need any more specs.
Assignee: nobody → wbowling
Flags: needinfo?(williamr)
We also need some text in the UI to explain how we use the primary email address. This could be done as a tool tip. Suggested text: 'Emails from Mozillians.org and messages to vouched Mozillians are sent to your primary email address.'
:wbowling Here [1] is the current development branch for multiple emails support. It's still work in progress but it might be helpful for you in order to start working on the static templates for email editing. [1] https://github.com/johngian/mozillians/tree/alternate-email-dev Some notes after https://bugzilla.mozilla.org/show_bug.cgi?id=1076867#c8. * We need to have a UI/UX design in order to be clear for our users that edit profile page is not for email editing. * We don't need to have an email input since we are going to use browserid for adding new emails. We only need a button to launch the browserid pop-up. * We don't need to have an indication to show if an email is verified since verification is going to be based on browserid and that means that all the emails that user's add are verified by default.
(In reply to John Giannelos [:nemo] from comment #10) > * We need to have a UI/UX design in order to be clear for our users that > edit profile page is not for email editing. Wray, can you suggest a UX in the email section of the the Edit Profile that does these things? - explains that your primary email address will receive communications from Mozilla and Mozillians.org - links people to the Edit Emails page to manage the emails associated with their profile (includes add/remove email and set primary)
Flags: needinfo?(wbowling)
Based on chats we've had in IRC/Vidyo, we will display the user's primary email address and provide a link/button to "Manage e-mail addresses" I pushed up a static placeholder here https://github.com/caktus/mozillians/commit/7042520fb740a436ecbd8a6c71bc0c3ef808b310
Flags: needinfo?(wbowling)
Attached image multiple e-mails UI
Here's the current state of the multiple emails UI
Attached image menu item
...and the menu item that gets you there...
...and the shortcut from "Edit profile"
Commit pushed to master at https://github.com/mozilla/mozillians https://github.com/mozilla/mozillians/commit/e0802b482f7da442edcc3da46aada545d1a8d1cd [Fix bug 1076867][Fix bug 1076865] Add UI and backend for multiple email support. * Add url/view to handle email settings. * Create formset for multiple email addresses. * Create template for email editing. * Moved primary/delete label styles into Less. * Manage emails button added to edit profile page * Simplified UI for email management into actionable buttons. * Add more consistent copy. * Add mailto link in profile email. * Add tests for email editing.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Version: other → next
Verified on stage. Tested: - Created new account - After account creation, navigated to edit, and then navigated to edit emails - Adding new accounts - Changing primary ones
Status: RESOLVED → VERIFIED
Flags: needinfo?(pierros)
Version: next → 2015-2.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: