809552 - [Email App] shouldn't have to place cursor for username before domain name

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::E-Mail, defect, P3)

Description

[Tony Chung [:tchung]]

Attachment: screenshot

I am finding it quite annoying to have to focus the cursor before the domain name, and have to enter in "user@" before the domain name.   If i'm already trying to setup a Gmail or Hotmail account, i shouldnt have to specify the domain suffix since that's the account type im' planning to setup.

Can we just remove the domain suffix from the text field and just have the user enter in username only?   The code can then handle appending the correct domain to the username.

Repro:
1) 11-6-2012 daily unagi build
2) launch Email app, and enter a hotmail or Gmail account
3) Verify to enter in your username, you have to precisely tap the username field, enter in your name@ before the domain to properly register.

Expected:
- remove the domain suffix, and just have the username be the only thing the user enters

ActuaL;
- precisely enter the name before the suffix with @.

Comment 1

[Dylan Oliver [:doliver]]

Agreed, Andrew & Jim have tossed around some ideas on easy improvements to the setup screens. Casey, it would be great to get input from you on this one.

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

I believe our most recent proposal, conceived of by Jim is to replace all the pre-set buttons and just drop the user right in a typing extravaganza:

[ editable display name]

[ editable username ] @ [ editable domain | V ]

[ editable password ]


Where the "V" for domain is a combo-box looking thing that can then bring up an action menu with a list of domains that basically were what we had on the button list before, and more. So:
hotmail.com, mozilla.com, etc.

I'm not sure if we already have a visual affordance we can reuse from building blocks for this or not.


Given our limited options for canned data for v1, I think we would grab the list of domains from the l10n strings and do a split(',') on it.

Comment 3

[Dylan Oliver [:doliver]]

Triage: blocking-/P4 but this is one we'd really be interested in seeing addressed before release.

Would we consider a half-measure instead where we pull out the Hotmail/Gmail/Other selection screen and just take everyone directly to the "New Mail Account Setup" screen instead? I think that would at least eliminate the confusion about what to put in each field.

Comment 4

[David Walsh :davidwalsh]

I think this would actually be a better option:

1.  Keep the same structure that exists now
2.  Change "gmail.com" to "[e-mail]"
3.  When the address field is focused, highlight "you" so that when the user starts keying in their username, they seamlessly complete the field.

When I opened the Gmail screen, I had no idea what was going on with that field, and I think my idea strikes a good balance of information and functionality.

Comment 5

[Jim Porter (:squib)]

I think we're going to be doing what Dylan suggests in comment 3, since the Gmail/Hotmail buttons confuse people a lot. All they do is pre-fill the domain name, but many people think it's required to hit the Gmail button if they have, say, a Google Apps domain. All that does is force them to delete the "gmail.com" first.

Comment 6

[Dylan Oliver [:doliver]]

Re-nominating for blocking -- we've gotten consistent feedback from the test drivers that the current account setup is confusing. We have a low effort proposal here that would at least eliminate the major source of uncertainty regarding what to type in each field.

Comment 7

[Jim Porter (:squib)]

Taking this.

Comment 8

[Ben Francis [:benfrancis]]

Triage: Please renominate if you get input for UX on the specific changes to make, then the risk/reward can be properly evaluated.

Needs input from Casey.

Comment 9

[ayman maat :maat]

ok, f.y.i. i am currently looking into this form a UX PoV.

Comment 10

[ayman maat :maat]

(In reply to Tony Chung [:tchung] from comment #0)
> 
> I am finding it quite annoying to have to focus the cursor before the domain
> name, and have to enter in "user@" before the domain name.  


Agreed. This is a very poor interaction model.


> If i'm already
> trying to setup a Gmail or Hotmail account, i shouldnt have to specify the
> domain suffix since that's the account type im' planning to setup.
> 
> Can we just remove the domain suffix from the text field and just have the
> user enter in username only?   The code can then handle appending the
> correct domain to the username.


on the surface i agree with this comment. however i have two points to raise:

1) project time: 

I am aware that developers are running red-hot at the moment and timelines are tight. Therefore i am looking for the solution that adds the least amount of pressure to the project, but still provides a reasonable UX

2) handling of top level domains

the removal of the domain suffix and having the users enter only the username does not cover situations where the email provider has different top level domain names. we require scaleability of architecture and flexibility in usage. I would therefore advise that we need to consider email providers that have different top level domain names in the solution we implement.

With point 1) and point 2) in mind i would propose that we simply replace the prefilled text that sits in the email address field (gmail.com or hotmail.com in the cases we are discussing) with instructional copy that is removed as soon as the user starts to enter text into the textfield as what is happening in the name and password fields. 

the instructional text i would suggest is..

gmail: 	[e-mail]
hotmail:	[e-mail]
other:	[e-mail] 

This proposition equalizes the UX of adding an email account to the email apps on iPhone, Andriod and Lumina.

We can investigate and propose a superior UX in a later version when we have more capacity.

What do you think? I am open to discussing further if you wish.

Comment 11

[Casey Yee]

+1 On aymans suggestions:
"simply replace the prefilled text that sits in the email address field (gmail.com or hotmail.com in the cases we are discussing) with instructional copy that is removed as soon as the user starts to enter text into the textfield as what is happening in the name and password fields. "

> the removal of the domain suffix and having the users enter only the
> username does not cover situations where the email provider has different
> top level domain names. we require scaleability of architecture and
> flexibility in usage. I would therefore advise that we need to consider
> email providers that have different top level domain names in the solution
> we implement.

Another case that we need to consider is that many webmail services have an option to host email on other domains as well.  Gmail for sure does this.     For these cases, would it make sense to have a domain field as well?

I've updated the Wireframes to include the latest suggestion from Ayman:
https://www.dropbox.com/s/auamh50itxbbjp5/Mail-setup.pdf

Comment 12

[Andrew Sutherland [:asuth] (he/him)]

I'm going to steal this bug because I'm touching a lot of the code/strings in question with my fixes for bug 816039.  I thought we were going to do something 'mo fancy so I was going to leave this to Jim, but we're not, and so... yoink!

Casey, why don't we just drop the buttons that let you pick a mail provider in the first case, too, then?

Right now, the buttons do 2 things:
- Tell us a domain to prefill, which as noted, has a good chance of being incorrect.
- Tell us whether we need the user to enter their (display) name.  For ActiveSync servers, the server can tell us the user's display name, so we don't need to ask it.


So what I am proposing we do, including changes to the strings in the wire-frames which I think are confusing, is to:

1) Drop the 'pick a service' card.

2) Change the account setup (info) card that currently says things like "Gmail Account Setup" in the wireframe to just say "Account Setup".

3) Have the 3 boxes on the card be labeled: "Your name", "Email address", "Password".  The wireframe currently calls for: "Account name", which is very misleading since that's actually the display name we use for the user when sending e-mails; "Gmail login" which is potentially confusing because what we care about is their e-mail address; and password, which is fine and dandy.

4) Have the only placeholder text be found in the e-mail address box, and have it be "[e-mail]".


Big screen real estate note!  What is currently implemented is just 3 text-boxes which placeholder text of "Name", "Email address" (frequently never seen because we pre-fill that box for everything but the 'other email' option), and "Password".  The wire-frames were changed along the way to include explicit labels for the text boxes, which I think is a general improvement.  However, we are probably going to end up in the situation where the 3 textboxes and their labels will not be able to fit on the screen of the phone at the same time while the keyboard is up.  (The wireframes approximate a larger device, like an 800x480 device.)  The good news is we are moving the "Next" button into the header so that won't be getting lost anymore.

Comment 13

[Jim Porter (:squib)]

(In reply to Andrew Sutherland (:asuth) from comment #12)
> - Tell us whether we need the user to enter their (display) name.  For
> ActiveSync servers, the server can tell us the user's display name, so we
> don't need to ask it.

I should note that now that Hotmail doesn't use Autodiscovery (it uses local Autoconfig files), we *never* know that we can avoid asking the user for their name. If we did hit Autodiscovery, e.g. on some random Exchange server, we could pull in the display name if the user didn't enter anything themselves, but that's the only case that matters now. And, in fact, that's impossible, since the Display Name field is required. Incidentally, I think we should make that field optional, so that privacy-conscious people don't have to enter a random display name for themselves.

Comment 14

[Casey Yee]

There are several reasons why I think keeping the service selections screen makes sense:

1. Much more user friendly than simply displaying a series of input fields.
2. Much clearer to the user which services are supported by our Mail app.  
3. There are going to be differences in fields depending on the services chosen.  My understanding is that activesync/hotmail will require a different set of fields than imap accounts.

To this end, I think all that is required is that we need to change the copy for the fields as per your recommendation so that it is less confusing to the user: "Your Name", "Email address", "Password".

In regards to the screen realestate issue.  I feel that it's definitely better (in general) to have input field labels where possible. I am however going to back-peddle and say that we should stick with the text boxes with placeholder text (the way it is now) to be consistent with what other apps are already doing.

Comment 15

[ayman maat :maat]

(In reply to Casey Yee [:cyee] from comment #14)
> There are several reasons why I think keeping the service selections screen
> makes sense:
> 
> 1. Much more user friendly than simply displaying a series of input fields.
> 2. Much clearer to the user which services are supported by our Mail app.  
> 3. There are going to be differences in fields depending on the services
> chosen.  My understanding is that activesync/hotmail will require a
> different set of fields than imap accounts.

I agree with Casey here. i currently see no value in removing the service selection screen either from a UX or development PoV, which is why i did not suggest it in comment #10. Is there any possibility we could avoid removing it?

Comment 16

[Dylan Oliver [:doliver]]

(In reply to ayman maat :maat from comment #15)
> Is there any possibility we could avoid removing
> it?

Yes, it could be left in place if there is value to the user. The main source of confusion is that we fill the email address field with "gmail.com" or "hotmail.com" if you select those options. If we can settle on the consistent hint text of "Email address" suggested in comment #14 regardless of the option chosen on the first screen that would solve it and is probably the lowest effort as well.

Comment 17

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Casey Yee [:cyee] from comment #14)
> 1. Much more user friendly than simply displaying a series of input fields.

But we need to display those input fields anyways.  If you are concerned about the abruptness of dumping the user into the fields, it seems like having a page with introductory text is more useful than buttons whose only effect is to change the placeholder text on a text field on the next page.

> 2. Much clearer to the user which services are supported by our Mail app.  

So we only support gmail and hotmail?  (Note: The list is hard-coded right now because making the list configurable was out-of-scope for v1.)

> 3. There are going to be differences in fields depending on the services
> chosen.  My understanding is that activesync/hotmail will require a
> different set of fields than imap accounts.

Per Jim's comment 13, we always want the same exact information for autoconfiguration every time.

Comment 18

[Jim Porter (:squib)]

I'd just like to reiterate that the *only* thing the Gmail button does is prefill the domain so that the user has to type fewer characters. Ditto with Hotmail*. People often think that they have to hit the Gmail button for Google Apps domains, or the Hotmail button for @live.com addresses, but they don't. In fact, in both cases, all the user has done is force themselves to remove the prefilled domain before they type in their actual email address.

I think the benefit of saving the user at most 12 characters of typing ("@hotmail.com") is outweighed by the confusion that this UI causes.

* Hotmail also hides the Display Name field, but that's a bug.

Comment 19

[David Walsh :davidwalsh]

I think my comment #4 satisfies all requirements here...

Comment 20

[Casey Yee]

OK Guys,
Let's go with David's suggestion and drop the user directly into the input fields.

Comment 21

[Dylan Oliver [:doliver]]

Casey, I got confused between your comment here and the IRC conversation with asuth a few minutes back. Are you suggesting we go with the proposal from comment #4 or the one from comment #12?

Comment 22

[Andrew Sutherland [:asuth] (he/him)]

Attachment: existing patch, labeled input boxes, no keyboard

Comment 23

[Andrew Sutherland [:asuth] (he/him)]

Attachment: existing patch, abeled input boxes, keyboard visible, name focused

Comment 24

[Andrew Sutherland [:asuth] (he/him)]

Attachment: existing patch, labeled input boxes, keyboard with password focused

These are the images of how we end up with the inputs labeled, hopefully conveying the screen real estate situation.  Note that there was a bug where I had not properly associated the inputs with their l10n strings.  The placeholder for the e-mail address should be showing "[e-mail]" (which I have now fixed in my patch).

Comment 25

[Casey Yee]

regarding attachment 694176 [details]

Let's stick with our existing setup with the labels in the input fields.   

It looks like the input fields are too large as well.  Even reduced in size we will still have a screen real estate problem.

Thanks for the extra effort!

Comment 26

[Dylan Oliver [:doliver]]

Re-noming based on the same reasoning as comment #6 and we now have a UX-approved design to move forward with.

Comment 27

[Joe Cheng [:jcheng] (please needinfo)]

Triage: BB+, P3, C3 - agree on comment 26

Comment 28

[Andrew Sutherland [:asuth] (he/him)]

My understanding from squib is that he's pretty much cool with the patch; I do need to do a little bit of a UI cleanup pass for the last UX feedback about placeholders and to clean up some minor fallout in the compose window from the application of the input field building blocks.  We should be able to land this later today if all goes well, although both squib and I are currently living in areas experiencing weather and power outages.

Comment 29

[Andrew Sutherland [:asuth] (he/him)]

This bug and several others have been fixed by a patch developed on bug 816039 and landed with the authority of bug 809552 (blocking-basecamp).

merged to gaia-email-libs-and-more/master:
https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/99

merged to gaia/master:
https://github.com/mozilla-b2g/gaia/pull/7027

Comment 30

[Axel Hecht [:Pike]]

Can we back this out and fix the strings first, please?

I've given this pull request an r- over in bug 816039.

Comment 31

[Andrew Sutherland [:asuth] (he/him)]

Per your comments in bug 816039, it sounds like the only outstanding problems were the two strings with extra comments added without a change to the l10n id's.  I also did an additional pass through my patch's changes to the properties file and did not find any other semantics changes.  Since the 2 string id's were a trivial thing to fix, I pushed a follow-up patch to gaia:
https://github.com/mozilla-b2g/gaia/pull/7222

Please feel free to reopen and/or issue pull requests directly at me if you see any other problems.

Comment 32

[Angela Hubenya]

Defect is verified as fixed. Using Unagi, build 20121231070201.