728877 - Implement new Edit Profile UX changes

Status: VERIFIED FIXED

(Participation Infrastructure :: Phonebook, defect, P1)

Comment 1

[Bram Pitoyo [:bram]]

Attachment: Edit - Profile

Comment 2

[Bram Pitoyo [:bram]]

Attachment: Edit - Groups and Skills

Comment 3

[Bram Pitoyo [:bram]]

Attachment: Edit - Vouces and Invites

Comment 4

[Bram Pitoyo [:bram]]

Attachment: Edit - Account

This merits a larger discussion with the Identity team.

Mozillians.org have a one-to-one correspondence between account and email. One email is only associated with one account.

But BrowserID have a one-to-many relationship. One BrowserID account can be associated with many emails.

This may create potential problems with logging in.

For instance, if the first option in my BrowserID email is the address that I am *not* using for Mozillians, and if I just hit “Next” with that email, Mozillians will create a new account for me rather than log me in.

Comment 5

[Aakash Desai [:aakashd]]

Cc'ing ben and ozten to the bug. Ben and Austin, we're looking to add a way to change a user's primary email address on mozillians. The proposed method can be best seen in the mockup in comment #4. Are there any issues from the browserid side about doing this...maybe soecifically around what may happen after a user has changed their email address and it is not in the same browserid account?

Comment 6

[Owen Coutts [:tallOwen]]

(In reply to Bram Pitoyo [:bram] from comment #2)
> Created attachment 598864 [details]
> Edit - Groups and Skills

Can you explain to me groups as a separate idea from skills?

Comment 7

[Armen [:armenzg]]

Are the concepts of "pending invitations" or "pending vouching" views part of the roadmap? Is that something I could ask for in here?

Comment 8

[Aakash Desai [:aakashd]]

(In reply to Owen Coutts [:tallOwen] from comment #6)
> (In reply to Bram Pitoyo [:bram] from comment #2)
> > Created attachment 598864 [details]
> > Edit - Groups and Skills
> 
> Can you explain to me groups as a separate idea from skills?

Definitely. "Skills" are a capability to do some sort of action. Meanwhile, "Groups" is a collection of people that are put together under some common reason. The former is more of a personal set of tags that explain what you are a capable of performing, while the latter explains what you are interested in. Hence, the reason for the separation.

Comment 9

[Aakash Desai [:aakashd]]

(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #7)
> Are the concepts of "pending invitations" or "pending vouching" views part
> of the roadmap? Is that something I could ask for in here?

They're actually already a part of the app currently, but it sounds like you're confused. Can you follow up with tofumatt, bram and I via e-mail? The request is a bit out of scope for this bug.

Comment 10

[Bram Pitoyo [:bram]]

(In reply to Aakash Desai [:aakashd] from comment #8)
> Definitely. "Skills" are a capability to do some sort of action. Meanwhile,
> "Groups" is a collection of people that are put together under some common
> reason. The former is more of a personal set of tags that explain what you
> are a capable of performing, while the latter explains what you are
> interested in. Hence, the reason for the separation.

I was thinking of implementing some sort of a controlled vocabulary list here (ie. limiting the number of groupss) or at least some preset selections (e.g. 15 most used groups, 15 most used skills), with an blank text box if user wants to insert his own group. It will help limit rogue tags, I think.

Comment 11

[Austin King [:ozten]]

(In reply to Bram Pitoyo [:bram] from comment #4)

> For instance, if the first option in my BrowserID email is the address that I am *not* using 
> for Mozillians, and if I just hit “Next” with that email, Mozillians will create a new 
> account for me rather than log me in.

Great point Bram. A couple features already exist to mitigate this issue.

1) BrowserID will pre-select the last email you've used on a per-domain basis, so an existing user who has logged in before, should be defaulting to their current Mozillians email address.

2) Within the Mozillians codebase - If the user clicks login and uses an unknown email address, there is a "are you sure you want to create a new account as [e-mail]? <choose another email>"

(In reply to Aakash Desai [:aakashd] from comment #5)
> Are there any issues from the browserid side about doing this...maybe soecifically around 
> what may happen after a user has changed their email address and it is not in the same 
> browserid account?

No, there are no issues. Your app can have multiple email addresses, or provide a change email address feature. By using BrowserID to pick the new email address, you get a couple things:

1) It's verified
2) Trains user to continue to use BrowserID
3) New email address will be default from now on

It has at least one deficiency
* action is called Sign in, when really it's "choose email" or "change email"

This problem was discussed http://groups.google.com/group/mozilla.dev.identity/browse_thread/thread/3a4c1b1d28047f44/db3e72ee11484725 and is in our UX bugs.

Please chime in on that thread if you see anything that is missed or new opportunities for improving this flow.

Comment 12

[Bram Pitoyo [:bram]]

(In reply to Austin King [:ozten] from comment #11)

Excellent. Thanks for the clarification, Austin!

> 1) BrowserID will pre-select the last email you've used on a per-domain
> basis, so an existing user who has logged in before, should be defaulting to
> their current Mozillians email address.

Pre-selecting will be a solution that will solve most of this problem. I don’t usually see it on Mozillians. This could be because I usually close the Mozillians tab when I’m done rather than hit “Log Off”. Tonight, I tried properly logging off, and BrowserID did select the URL I just used to sign in

 
> 2) Within the Mozillians codebase - If the user clicks login and uses an
> unknown email address, there is a "are you sure you want to create a new
> account as [e-mail]? <choose another email>"

Today, logging in with an unknown email address leads me directly to the “Complete Your Profile” step, rather than “are you sure”. Giving the user a confirmation would be ideal, especially since it already exists in the codebase.

Comment 13

[Bram Pitoyo [:bram]]

Attachment: Edit - Account

Updated the change password wording to reflect BrowserID name change to Mozilla Persona

Comment 14

[Aakash Desai [:aakashd]]

Looking for someone to pick this up as part of the re-design

Comment 15

[Po-chiang Chao [:bobchao]]

Will we add "Language spoken" and "Location" fields in profile? It would be very helpful once we need to find someone near us (to plan some event in first-life together) or seeking new l10n volunteer.

They both can be added as new groups at the meantime, but would be better if we encourage people add these information.

(Not sure if I should file another bug for this.)

Comment 16

[Owen Coutts [:tallOwen]]

(In reply to Po-chiang Chao [:bobchao] MoCoTW from comment #15)
> Will we add "Language spoken" and "Location" fields in profile? It would be
> very helpful once we need to find someone near us (to plan some event in
> first-life together) or seeking new l10n volunteer.

Locations is being worked on by :tofumatt. There may be a bug for it already somewhere else.

Comment 17

[Aakash Desai [:aakashd]]

* Location: https://bugzilla.mozilla.org/show_bug.cgi?id=657071


There isn't a bug filed for "Languages spoken", so please feel free to file it. For the time being, people are using the groups feature with the text, "speaks:**languagespoken**". For example, "speaks:tagalog" or "speaks:french".

Comment 18

[Bram Pitoyo [:bram]]

Attachment: Edit - Profile

Added languages. Note how the first language field is automatically filled after user selects a location.

For example, if I select anywhere in Indonesia as my location, “Bahasa Indonesia” is going to be auto-filled, “Bengali” if the user is in Kolkata, “English” in London, and so on.

Comment 19

[Aakash Desai [:aakashd]]

(In reply to Bram Pitoyo [:bram] from comment #18)

> Added languages. Note how the first language field is automatically filled
> after user selects a location.
> 
> For example, if I select anywhere in Indonesia as my location, “Bahasa
> Indonesia” is going to be auto-filled, “Bengali” if the user is in Kolkata,
> “English” in London, and so on.

How about we keep this simpler by having a text field that allows folks to comma separate any languages they speak? This'll make it searchable and be an improvement over what we currently have while limiting the amount of work to be done.

Comment 20

[Bram Pitoyo [:bram]]

As with all freely editable box, there’s a concern that a search for “French” and “Français” will bring back different results, even though we know that user wants to find a Mozillian who know how to speak French. Languages and their names might be something we need to add to our search engine synonym list (e.g. when someone searches for “German”, it equals “Deutsch”, and so on.)

Comment 21

[Aakash Desai [:aakashd]]

(In reply to Bram Pitoyo [:bram] from comment #20)
> As with all freely editable box, there’s a concern that a search for
> “French” and “Français” will bring back different results, even though we
> know that user wants to find a Mozillian who know how to speak French.
> Languages and their names might be something we need to add to our search
> engine synonym list (e.g. when someone searches for “German”, it equals
> “Deutsch”, and so on.)

How about we use the same groups architecture for skills and groups, but only show an autocomplete against groups under the "speaks" system hierarchy?

Comment 22

[Bram Pitoyo [:bram]]

(In reply to Aakash Desai [:aakashd] from comment #21)
> How about we use the same groups architecture for skills and groups, but
> only show an autocomplete against groups under the "speaks" system hierarchy?

Good idea. Let’s do that.

Comment 23

[[github robot]]

Commit pushed to master at https://github.com/mozilla/mozillians

https://github.com/mozilla/mozillians/commit/ebc0b6b05752537bfe785a7accdfbc3d9d0d5691
Tabbed edit profile

Rewrote to use a different bootstrap form library, used bootstrap tab
utilities. Fix bug 728877

Comment 24

[[github robot]]

Commits pushed to master at https://github.com/mozilla/mozillians

https://github.com/mozilla/mozillians/commit/b5819c2431ea10c71391a0f2de6d733bd15f7e40
Added skills tag to userprofile

This is a next step that wasn't implemented in the first implementation
of bug 728877. This creates a new skills model. This inherits from a
GroupBase model and so does Group. This allows for more reusable code.

https://github.com/mozilla/mozillians/commit/817d699856980142f1aa6d0f0d5bccdb341663e0
Merge pull request #189 from tallowen/skillz

[bug 728877] Added skills tag to userprofile

Comment 25

[Bram Pitoyo [:bram]]

Attachment: Settings - Vouches and Invites - Overview

Note that non-stewards will not see the secondary navigation items (Overview, Received and Responded), because only the things under Overview are relevant to them.

Also note that, for stewards, we need to come up with a more specific name than simply “Overview”.

Comment 26

[Bram Pitoyo [:bram]]

Attachment: Settings - Vouches and Invites - Received

The Received section is only relevant to Stewards. It will display the list of new Mozillians who had indicated that they were interested in the group that Steward is a part of.

This section will allow stewards to send emails to new Mozillians who are not vouched yet.

Note that we will need to come up with a well written default message to fill the text box.

Comment 27

[Bram Pitoyo [:bram]]

Attachment: Settings - Vouches and Invites - Responded

The Responded section is only relevant to Stewards. It will display the list of new Mozillians who had replied to the email that the Steward have sent from the “Received” section.

This section will allow Stewards to vouch multiple Mozillians.

Comment 28

[Bram Pitoyo [:bram]]

Attachment: Edit - Account

Comment 29

[Matt Brandt [:mbrandt]]

Bumping to verified - this went live long ago. Nicely done all.