1349259 - On first start, show account setup dialog, not account provisioner

Status: RESOLVED FIXED

(Thunderbird :: Account Manager, defect)

Description

[Ben Bucksch (:BenB)]

Reproduction:
* Install Thunderbird (no profile yet) and start it for the first time

Actual result:
A dialog comes up that suggests that you create an new email address with Gandi

Expected result:
A dialog comes up that allows you to configure your existing email address

Rationale:
* That's what most users will need.
* We tried to hook up more ISPs (the system is designed to allow many pay and free ISPs), but Mozilla failed. Offering only Gandi makes no sense.

Comment 1

[Ben Bucksch (:BenB)]

Attachment: 1349259-1.diff

Comment 2

[Ben Bucksch (:BenB)]

The account provisioning dialog will still be accessible from the account setup dialog, with the button "Get new account...". So, no functionality is lost, just the default is turned around. At least for now.

The new patch also changes the account central.

Comment 3

[Ben Bucksch (:BenB)]

Attachment: Use setup dialog on startup and in account central

Comment 4

[Ben Bucksch (:BenB)]

Attachment: Screenshot of first screen after installation

Note that the provisioning dialog is still accessible with the "Get a new account" button.

But I think this new dialog significantly reduces the mental burden on users, by being much simpler. And more likely what they want to do.

Comment 5

[Jorg K (CEST = GMT+2)]

Attachment: Mock-up from TB planning

I think Mike Conley doesn't work on TB any more. I think one reviewer is enough, or else, try Aceman (or myself). We should get UI approval from Richard and general agreement on the feature.

I think there were some mock-ups discussed on TB planning that looked nicer than this, see attached.

Comment 6

[Jorg K (CEST = GMT+2)]

Comment on attachment 8849609 [details] [diff] [review]
Use setup dialog on startup and in account central

Let's clear Mike here and give this to Aceman since Magnus' review queue is overflowing. As I said, if we redo this, we should have a nicer panel.

Comment 7

[Wayne Mery (:wsmwk)]

Don't we first need UI review?

Comment 8

[Ben Bucksch (:BenB)]

There is no new UI here. I am merely putting things back in the state it was before the account provisioner (which is pretty useless as-is today for most users) was put in front of everything. I merely restore things.

Comment 9

[Ben Bucksch (:BenB)]

Comment on attachment 8849995 [details]
Mock-up from TB planning

[mockup]

This is overloaded and goes against the idea of the most simple dialog.

Frankly, I'd rather entirely remove the account provisioning, given its current state with only one provider.

Comment 10

[Matt]

(In reply to Ben Bucksch (:BenB) from comment #9)
> Comment on attachment 8849995 [details]
> Mock-up from TB planning
> 
> [mockup]
> 
> This is overloaded and goes against the idea of the most simple dialog.
> 
> Frankly, I'd rather entirely remove the account provisioning, given its
> current state with only one provider.

You might rather remove it,  but  I think the dialog is the one to be using as it is clear and concise.  It is not overly simplistic,  nor is it misleading.  The user has exactly two choices.  Both are clearly outlined.  If more information is needed then an "in application" link to the relevant KB article is the solution to explain what those two options actually mean.  (another explaining IMAP and POP would also be excellent).

One of our issues with user interface has been a desperation for simplicity.  Our core users want it to just work, and if it does not they want control.  Not dumbed down user interfaces.

Comment 11

[:aceman]

(In reply to Ben Bucksch (:BenB) from comment #9)
> Comment on attachment 8849995 [details]
> Mock-up from TB planning
> 
> [mockup]
> 
> This is overloaded and goes against the idea of the most simple dialog.

Yes this mockup is harder to code with the provider selection already in the dialog. Can you do the middle ground I have proposed and just beef up the button to the existing account provisioner with some description?

Comment 12

[:aceman]

Comment on attachment 8849609 [details] [diff] [review]
Use setup dialog on startup and in account central

(In reply to Ben Bucksch (:BenB) from comment #0)
> Rationale:
> * That's what most users will need.

How do you know? I don't think everybody on the mailing list agreed with this.

I'm open to review patches in this bug, but I don't think just switching the dialogs around helps anything. I think the buttons (about getting new email from provider vs. setting up existing email) are still hard to graps.

I think most neutral would be to at least indicate there are 2 paths forward in a single dialog with descriptions.

Comment 13

[Ben Bucksch (:BenB)]

> How do you know? I don't think everybody on the mailing list agreed with this.

We have as data the number of people who set up existing accounts using this dialog. This is over 100000 per day (!), that's hard data (when we still had reports about this).
We have the accounts that people register at Gandi (that's the only offer) using the account provisioner. That's roughly 1000 per month, at best, as far as I know.
In other words, for every user who registers a new account, there are over 1000 who set up existing accounts.

Comment 14

[Ben Bucksch (:BenB)]

I think given the above numbers, the other suggestions are moot, too. It's very clear what most users need.

The whole idea of the dialog is to have a very simple, straight-forward path for most users. We ask the minimal amount of choices and input, with the minimal amount of widgets. Putting up all choices (with the same weight, even unlikely ones) completely destroys the whole idea.

The account provisioner didn't work. Given the numbers, it should be killed entirely. I am just being conservative, by merely switching the 2 dialogs around in their order. There is no need to invent any new UI.
* The account provisioner offers a new account, and has a button to go to account setup dialog set up an existing account.
* The account setup dialog set up an existing dialog, and has a button to go to account provisioner to register a new account.
* The UI is completely equivalent, you can switch back and forth.
I merely switch around which one we show first. Namely the one that's used 1000 times more often.

Comment 15

[alta88]

Fwiw, Ben is completely correct here and we shouldn't block the change or rework the ui to give equal weight to getting a new email; the button is quite sufficient.

The one point of confusion or lack of clarity is the button wording - the en text might better read "Get a new email address". Using the word "account" conflates getting an external account with a Thunderbird account. And going through that is a totally complex operation, requiring creating a Gandi account, finding a credit card, shopping for it and so forth which contrasts with a very simple flow when creating a Tb account with an existing email address.  To make existing vs. new email address even more clear, the text "Use an existing email address" could appear next to the email field (similar to the name above it).

Comment 16

[:aceman]

Thanks alta88 and that is exactly all that I was proposing.

So for completeness I paste my posting to the mailinglist to this topic here:

Sorry, but the mockup is ambiguous again. How does the user know the
difference between "setup" (the dialog title) and "get a new account"?

We already have enough strange buttons later in the dialog (manual
config, advanced config, etc).

We will need more wording to explain the difference. The bottom half of
this dialog in the picture is unusued, you could expand the "getting a
new account a bit".

I propose 2 similarly sized blocks (e.g. a fieldset), both with
titles/descriptions. The top one can have the 4 fields (and the continue
button), the bottom one would only have the description and a button.

Comment 17

[Ben Bucksch (:BenB)]

Attachment: Screenshot of first dialog after installation

Comment 18

[Ben Bucksch (:BenB)]

Attachment: Fix, v3

Comment 19

[Ben Bucksch (:BenB)]

Attachment: Fix, v4

Comment 20

[alta88]

The en is better as "Register a new email address...".

Comment 21

[Ben Bucksch (:BenB)]

Attachment: Fix, v5 - changed labels

Comment 22

[Ben Bucksch (:BenB)]

Attachment: Screenshot of first dialog after installation

Comment 23

[Ben Bucksch (:BenB)]

Attachment: Fix, v6

Change access key for email to e.

Comment 24

[Ben Bucksch (:BenB)]

Attachment: 1349259-7.diff

Update to trunk.
Use [e-mail] as placeholder.

Comment 25

[:aceman]

Comment on attachment 8852156 [details] [diff] [review]
1349259-7.diff

Review of attachment 8852156 [details] [diff] [review]:
-----------------------------------------------------------------

Wayne, can you review the label changes?

::: mail/locales/en-US/chrome/messenger/accountCreation.dtd
@@ +1,5 @@
>  <!-- This Source Code Form is subject to the terms of the Mozilla Public
>     - License, v. 2.0. If a copy of the MPL was not distributed with this
>     - file, You can obtain one at http://mozilla.org/MPL/2.0/. -->
>  
> +<!ENTITY autoconfigWizard2.title          "Set up existing email account">

Off by 1 space.

@@ +10,5 @@
>  <!ENTITY email.label                     "Email address:">
> +<!ENTITY email.accesskey                 "E">
> +<!-- LOCALIZATION NOTE(email.placeholder): @example.com must stay -->
> +<!ENTITY email.placeholder               "[e-mail]">
> +<!ENTITY email.text                       "Your existing email address">

Off by 1 space.

Comment 26

[Ben Bucksch (:BenB)]

Attachment: Screenshot of first dialog after installation

Comment 27

[Ben Bucksch (:BenB)]

Attachment: Fix, v8

Also changing account central label from "Create a new account" to "Set up an account", to avoid confusion with sign up.

Comment 28

[Jorg K (CEST = GMT+2)]

Can I be very picky: The title is "Set up existing email account" and at the bottom we have "Sign up for new email...". Hmm.
Also, Aceman will tell you to use an ellipsis "…" instead of three dots "...".

Comment 29

[:aceman]

Comment on attachment 8852191 [details] [diff] [review]
Fix, v8

Review of attachment 8852191 [details] [diff] [review]:
-----------------------------------------------------------------

Yes I think this is much better now. Please fix the ellipsis character.
And let's wait for Wayne's native-speaker check.

Comment 30

[alta88]

(In reply to Ben Bucksch (:BenB) from comment #27)
> Created attachment 8852191 [details] [diff] [review]
> Fix, v8
> 
> Also changing account central label from "Create a new account" to "Set up
> an account", to avoid confusion with sign up.

Sorry, this is wrong and should be reverted.  The original wizard dialog, and indeed all other account type creation dialog titles are in the form "Email|Chat|Feed Account Wizard" or simply "Account Wizard".  The mail dialog title should be changed to match, and certainly not the Account Central string.

For the record, I'm the one who implemented the Account Central row of account type links after the original wizard was destroyed as a centralized, unified place for all account type creation in favor of the failed email provisioner UX.

+<!ENTITY open-provisioner.label          "Sign up for new email address...">

This sounds hucksterish and commercial, and is inferior (and ungrammatical; the use of unfriendly cropped, stilted en is not warranted here) to what I suggested in comment 15: "Get a new email address".  

But wait, there's more: locale string decisions are made by native speakers of that locale, quite obviously, and that applies to the reference locale as much an any other.

Comment 31

[Ben Bucksch (:BenB)]

alta88:
> Sorry, this is wrong and should be reverted.

The old string was wrong. "Create an account" generally is understood that I get a new email account and new email address from a provider. NO wonder users are confused, if we say "Create account" in our UI. That very term is used by some ISPs as synonym for "sign up". But we actually mean "Set up inside Thunderbird". That has to be confusing for users. I therefore avoid all terms that could be ambiguous, and try to use unambiguous terms like "Sign up". I used that term, because Yahoo and Outlook use it. But indeed, I refer to wsmwk for final confirmation what sounds right in English. It just needs to be unambiguous, even for a user who doesn't already know what we mean.

Comment 32

[Ben Bucksch (:BenB)]

For the record, I changed Account Central on request by the reviewer aceman. Now you disagree again. I would ask that we all stop bikeshedding here, please?

Comment 33

[alta88]

(In reply to Ben Bucksch (:BenB) from comment #31)
> alta88:
> > Sorry, this is wrong and should be reverted.
> 
> The old string was wrong. "Create an account" generally is understood that I
> get a new email account and new email address from a provider.

No, that is certainly not 'generally understood'. Tb is not a 'provider', like an isp is a provider, with a browser based webmail interface.  And there must be a very high bar to changing wording that has existed for 20+ years.

> NO wonder
> users are confused, if we say "Create account" in our UI. That very term is
> used by some ISPs as synonym for "sign up". But we actually mean "Set up
> inside Thunderbird". That has to be confusing for users.

No, the confusion resulted from using the word "account" in the provisioner button, when what was meant was getting an email address from a 3rd party provider.  That confusion is alleviated by 
1) the "existing email address" string by the email field, 
2) changing the wording of the button label to "Get a new email address".

(In reply to Ben Bucksch (:BenB) from comment #32)
> For the record, I changed Account Central on request by the reviewer aceman.
> Now you disagree again. I would ask that we all stop bikeshedding here,
> please?

I think aceman will agree that titles for all dialogs need to be consistent, and that changing Account Central to match an out of sync title for just email isn't the best solution.  If not, he will correct me and clarify why not.

Comment 34

[Ben Bucksch (:BenB)]

> Tb is not a 'provider'

You know that, but our users don't. It's unquestionable that Outlook and Gmail use these very words "Create account" for signup. Which is not what we mean here. Our users are right to be confused.

> I think aceman will agree that titles for all dialogs need to be consistent,

aceman was the one who proposed this very change of changing the title. And I agree with him, he was right. The change makes it clearer for our users.

Comment 35

[Ben Bucksch (:BenB)]

> Please fix the ellipsis character.

aceman: Will do.

Comment 36

[:aceman]

(In reply to alta88 from comment #33)
> (In reply to Ben Bucksch (:BenB) from comment #32)
> > For the record, I changed Account Central on request by the reviewer aceman.
> > Now you disagree again. I would ask that we all stop bikeshedding here,
> > please?
> 
> I think aceman will agree that titles for all dialogs need to be consistent,
> and that changing Account Central to match an out of sync title for just
> email isn't the best solution.  If not, he will correct me and clarify why
> not.

So some of the other dialogs are titled "* Account Wizard", some are just "Account Wizard". That could use some consistency.

But I do not understand what is out of sync here. For email you click 'Set up' and a 'set up existing email account" pops up. That seems totally in sync. For other types, a Wizard dialog appears using which you set up the account. In that there is again some "create account" wording.

So do you propose changing the titles of all the other wizards?

Comment 37

[alta88]

(In reply to :aceman from comment #36)
> (In reply to alta88 from comment #33)
> > (In reply to Ben Bucksch (:BenB) from comment #32)
> > > For the record, I changed Account Central on request by the reviewer aceman.
> > > Now you disagree again. I would ask that we all stop bikeshedding here,
> > > please?
> > 
> > I think aceman will agree that titles for all dialogs need to be consistent,
> > and that changing Account Central to match an out of sync title for just
> > email isn't the best solution.  If not, he will correct me and clarify why
> > not.
> 
> So some of the other dialogs are titled "* Account Wizard", some are just
> "Account Wizard". That could use some consistency.
> 
Of course, but these 2 (rather than some) are newsgroups and movemail. They both use the old account wizard, shared with SM, and movemail gets strings from an rdf file.  So bringing these into modernity would be a bit more involved (as I know from ripping feeds away from rdf for Tb).

> But I do not understand what is out of sync here. For email you click 'Set
> up' and a 'set up existing email account" pops up. That seems totally in
> sync. For other types, a Wizard dialog appears using which you set up the
> account. In that there is again some "create account" wording.
> 

When I click Email in Account Central, I get the provisioner dialog; when I click "Skip this.." the existing email creation wizard dialog title is "Mail Account Setup".  I don't see any 'set up' anywhere.  I am proposing this should be "Mail Account Wizard" (which is what it is, and which title it used to be, and to match all other account type new account dialog titles), which obviates any need to change the Account Central string.

> So do you propose changing the titles of all the other wizards?

I'm proposing that minimal string and ui changes be made; change the email dialog title as above, change the provisioner button label to be proper en, add the explanatory "existing email address" text next to the field.  If it's felt that more instructional info be provided, it should be in an info button tooltip next to the provisioner button.

Comment 38

[:aceman]

(In reply to alta88 from comment #37)
> When I click Email in Account Central, I get the provisioner dialog; when I
> click "Skip this.." the existing email creation wizard dialog title is "Mail
> Account Setup".  I don't see any 'set up' anywhere.

I can see 'set up' in 'setup' :)

Anyway, that means you are not running with the patch.

Comment 39

[alta88]

(In reply to :aceman from comment #38)
> (In reply to alta88 from comment #37)
> > When I click Email in Account Central, I get the provisioner dialog; when I
> > click "Skip this.." the existing email creation wizard dialog title is "Mail
> > Account Setup".  I don't see any 'set up' anywhere.
> 
> I can see 'set up' in 'setup' :)
> 
your mind is playing tricks on you ;)

> Anyway, that means you are not running with the patch.

And what's more, the file/appmenu New menuitems have been forgotten. I think the fact that the provisioner works so poorly means the "Get new mail account" items should be removed and the provisioner should only be accessed from the mail wizard (although I don't think it should be removed entirely).

Comment 40

[Wayne Mery (:wsmwk)]

Comment on attachment 8852191 [details] [diff] [review]
Fix, v8

Sorry for the delay - it's been a very busy work day.

I just realized you set the flag for ui-review, which I am not empowered to plus nor minus.  That is the purview of Blake and I think also paenglab.  So I am clearing the review request.

Perhaps what you really intended was for me was a feedback request, which I am happy to do. There are two possible answers, and the net of the answers (for me) is a minus. On the question on whether "Set up existing email account" and the other changes in the patch are reasonable English phrases, the answer is yes. However, I offer "no" to the question of whether I agree with all the changes.

I may not be saying this very artfully, but I planned to comment even before benb asked. More in a follow up comment.

Comment 41

[Wayne Mery (:wsmwk)]

(In reply to Ben Bucksch (:BenB) from comment #8)
> There is no new UI here. I am merely putting things back in the state it was
> before the account provisioner (which is pretty useless as-is today for most
> users) was put in front of everything. I merely restore things.

UI review isn't just a matter of wording, placements, and visuals, it also covers the user experience/workflow. And this bug definitely indends to change that. Your point that this bug's goal is revert to UI from X years ago, which presumably was approved at that time or prior, is a non-starter. Conditions and personnel change over time, therefore *current* UI reviewers should be given the opportunity to give their input. I'm not saying this to be stop-energy, it's just the standard that I think everyone should be held to.

As mentioned in comment 40 I'm not a UI reviewer and won't pretend to be, but have thoughts I composed yesterday and early this morning that I think are important, but may not cover everyone's subsequent comments. (And I may even contradict something I said earlier)

Tl;dr is I think we should either do attachment 8849995 [details], or shoot for minimal wording changes and rearrange the existing Mail Account Setup (and perhaps keep that dialog title).


(In reply to Ben Bucksch (:BenB) from comment #9)
> ...
> Comment on attachment 8849995 [details]
> Mock-up from TB planning
>
> [mockup]
>
> This is overloaded and goes against the idea of the most simple dialog.

I totally agree that the vast majority of users have an existing email and don't need the provisioner. But for any first time user - who we should care about just as much as the person who comes with an email, if not more - a) it's not inviting (provisioner starts with "Welcome), b) as was stated in tb-planning or here, the choices simply are not clear.  One approach is  attachment 8849995 [details] (which I was definitely liked to when I first saw it).  The other approach would be to improve the layout of "Mail Account Setup" with an eye to the first time user based on elements of the provioner: 
1. make the dialog smaller (bug 549045 comment 51) - if nothing else it looks unprofessional 
2. add a box in which to put all the "account setup" items including relevant buttons - items not relevant to account setup go outside the box
3. use some of the friendlier wording ideas of provisioner, for example, a button "I'll configure my account later" rather than "cancel" 


> Frankly, I'd rather entirely remove the account provisioning, given its
> current state with only one provider.

But we have contractual obligations. Kent may know something about this. But it's also outside the scope of this bug, and likely a council-level discussion.

-

Many comments have been about wording dialog title and the like.  While the goals of making things clearer for the user are laudable I think some this activity has been distracting. I think it would be better to put energy into the overall workflow and how to better accommodate new users if account provisioner isn't the first item a new user sees.  (eg. bug 634078. There are more - like providing links to KB articles - but I can't put my finger on in just now)  Note also we have, in theory, capability to measure via bug 632639.

I'm out of time, so for now, lastly, I don't believe alt88's comment 30 is bikeshedding - he raised legitimate concerns that go beyond chosing word A vs word B.  I think changing the name of the dialog, if it is to be done at all, needs more thought and is probably better done in a different bug. So thanks alta88.

Comment 42

[Ben Bucksch (:BenB)]

The whole idea here is simplicity. Putting a choice that only less than 0.1% users need in front of them as very first screen goes directly counter to that simplicity. That's why attachment 8849995 [details] - or anything like it - is completely out of question.

If we confuse users, we also destroyed simplicity. That's why I think it's a good idea to make the terms less ambiguous. (That part wasn't my original idea, but came as a result of the review and the discussion, but I think it's a good idea.)

That's all I do here. I try to make a minimal change and only change the order of dialogs. I put the one that 99.9% of users need first, with still keeping the option for the other 0.1%. Arguably, we shouldn't even be doing that, by I try to be conservative to make the change more acceptable.

The current patch version 8 is the result of the discussion and already a compromise. However, I am now faced with 10 different people who all chime in and have directly conflicting views. That puts me in a deadlock.

Comment 43

[:aceman]

Yes, that is why we ideally would have an UX person that could decide between the 10 ideas. Sadly, I think we do not have one appointed. Will all due respect to Paenglab.

Comment 44

[Jorg K (CEST = GMT+2)]

(In reply to Ben Bucksch (:BenB) from comment #42)
> However, I am now faced with 10 different people who all chime
> in and have directly conflicting views. That puts me in a deadlock.
Welcome to making UX changes :-( - Those bugs typically argue to comment number 200 and beyond and at times get nothing done.

Comment 45

[Magnus Melin [:mkmelin]]

(In reply to :aceman from comment #43)
> Yes, that is why we ideally would have an UX person that could decide
> between the 10 ideas. Sadly, I think we do not have one appointed. 

I had discussed this with Richard months ago, but I'd forgot to announce it. Anyay, as of a few minutes ago now we officially have a UX submodule, with Richard and me as co-UX leads.

Comment 46

[Wayne Mery (:wsmwk)]

Attachment: mockup per comment 41

The left side of attached image incorporates the elements I suggested as an alternative to attachment 8849995 [details], namely
1. has most of Benb's last mockup (which is on the right side of the image)
2. riffs on aceman's comment 11
3. has the 3 items I suggested in comment 41

Comment 47

[Ben Bucksch (:BenB)]

I've now received some actual, factual data:
* Over 370000 existing accounts set up per day, with the "existing account" dialog.
* 52 new registrations per day, with the "account provisioner" dialog.

That's a very clear picture. Far more extreme than I guessed in comment 13, actually. The first dialog we present is for only 52 people, to make it easier for them. For the other 370000 people, we require an extra click, and more importantly, they need to read the first dialog, understand it (!), and finding the "existing account" button. That's not reasonable. The case for 370000 should be streamlined, without regard for the 52. These 52 can use the menu.

Kent (the current TB Treasurer) and I both agree we should kill this. I say this as the person who originally suggested the contract with Gandi in the first place, and brought them together.

Comment 48

[:aceman]

370 000 per day? How is that possible? Those aren't new users, so users setting up their accounts anew? How is that data gathered? The hits on the mozilla ISP DB that runs from the new account dialog?

Comment 49

[Ben Bucksch (:BenB)]

> How is that data gathered? The hits on the mozilla ISP DB that runs from the new account dialog?

Yes, exactly. That's the queries on the ISPDB, both hits and misses. So, that's exactly the number of accounts set up using the "set up existing account" dialog. The one that my patch here brings back to the front, where it was before.

The "account provisioner" was simply a last, but failed attempt of Mozilla Messaging to bring in some revenue. A horribly failed attempt.

If you ask people a question, and 99.99% of them say "No", and only 0.01% say "Yes" (even though it's much easier to say "Yes"), you gotta stop asking.

Comment 50

[:aceman]

But are those numbers real? Can't there be any duplicate hits for a single user/account setup?
I find it hard to believe that 2% of our users set up any account every single day.

Of course I agree with bringing the "set up existing account" option to the front.
We do not need to remove the account provisioner, just leave it as a menu item, or a secondary option in the account setup dialog. As your patch does.

Comment 51

[Ben Bucksch (:BenB)]

> I find it hard to believe that 2% of our users set up any account every single day.

Yup, me too. Of course, it would be more like 5% of users set up 2 test accounts once a week, or something like that, but it's still high.

But the numbers are real. The numbers from 2012 (the last ones I got from Mozilla Messaging) and 2017 (which sancus made) vary only in a few 0.1%. That cannot be a coincidence. I'm actually very surprised how much they match. So that gives me very high confidence in them.

If we include bots, the numbers look vastly different, so these are not bots, but actual users. The stats already include only the lookups with a Thunderbird user agent. But let's say half of them are still from other email clients (we had 128000 lookups per day in 2010, when this was still relatively new). That doesn't change the numbers much: 99.98% vs. 0.02% is not significantly different. So, even if there's a certain percentage of noise in the data, it doesn't change much.

To actively offer something (even as a button), you should have in the area of 5% of users who want it. 1% would be an edge case. Here, we have 0.01% of users.

> We do not need to remove the account provisioner, just leave it as a menu item

With this new data, I think that's the right choice.

> or a secondary option in the account setup dialog. As your patch does.

Right.

Comment 52

[Richard Marti (:Paenglab)]

I thought the ISPB is also used by other products. I'm not sure but heard something like this.

Comment 53

[Ben Bucksch (:BenB)]

Yes, it is. But we filter these out for the stats:
> > The stats already include only the lookups with a Thunderbird user agent.

Comment 54

[Matt]

(In reply to Ben Bucksch (:BenB) from comment #51)
> > I find it hard to believe that 2% of our users set up any account every single day.
> 
> Yup, me too. Of course, it would be more like 5% of users set up 2 test
> accounts once a week, or something like that, but it's still high.

Got a problem receiving mail... blow away your account and set it up again,  even more worrying is the numbers of people who use the new account wizard to change anything with the account settings.  Want to change your display name,  blow it away and start again.  Repeat a half a dozen times and then ask in a support forum why the correct information is not appearing in the account that your have now set up 10 times.

Basically our user interface is so poor that removing an account and recreating it is the normal method of changing anything.

As an aside,  most ISP help desks tell the user to remove the account,  even pop accounts and add it again if they are having trouble getting mail.  Not very helpful what the account is pop and the real problem is an anti virus firewall.  But that is the state of ignorance we function in.  We get to overflow of "I lost all my mail" in support forums.  After the ISP has done all the damage possible and suggested the consumer get outlook, at least it is supported by this ISP.

Comment 55

[Jorg K (CEST = GMT+2)]

What is the status here? Observations:

1) The patch still applies.
2) The patch has r+
3) The patch works, I tested it.
4) Ben has data that proves that his new panel is more useful than the old one with a nice
   button at the bottom to get to the "get me a new account".

Can we either accept the patch "as-is" or modify it to look like attachment 8853926 [details]?

Ben, what do you think of that suggestion?

Comment 56

[Ben Bucksch (:BenB)]

Thanks, Jörg, for picking this back up.

I'd like to land the patch as-is.

As for attachment 8853926 [details], I'm not opposed to renaming buttons, but with the Continue button at the bottom right as-is right now, and the other buttons should be much less prominent (e.g. smaller). Our default path should be to set up an existing address (because that's what 99.99% of users do), and the UI should make that path the most obvious and prominent one. That includes button placement.

I agree with making the dialog smaller on the first screen.

Comment 57

[Jorg K (CEST = GMT+2)]

I've looked at Wayne's proposal from attachment 8853926 [details]. Sadly this is not feasible.

In Ben's proposal we have this line of buttons at the bottom:
[Signup for a new email address] [Continue] [Cancel]

As soon at the user clicks "Continue" the panel expands to:
[Signup for a new email address] [Manual config] [Stop] [Continue] [Cancel]
and later
[Signup for a new email address] [Advanced config] [Re-test] [Done] [Cancel]

In other words, it's always the same panel with a changing row of buttons. Wayne's proposal, as nice as the first screen looks, can't do that since the buttons are in two rows.

So in conclusion, I think the solution proposed here is fine and we should land it "as-is". I will do so by the end of COB 3rd of September 2017, unless I hear any objection.

Comment 58

[Jorg K (CEST = GMT+2)]

Comment on attachment 8852191 [details] [diff] [review]
Fix, v8

This works for me and it integrates nicely with existing behaviour.

Comment 59

[Richard Marti (:Paenglab)]

I'm okay with this patch. Better we use this patch, and improve it later when we see it needs changes, than stay with the old behavior.

Comment 60

[:aceman]

Comment on attachment 8852191 [details] [diff] [review]
Fix, v8

I'm no longer sure why this stalled (probably some conflicting ideas appeared in the bug), so let's get confirmation whether this can land or not. Per comment 45...

Comment 61

[Magnus Melin [:mkmelin]]

Comment on attachment 8852191 [details] [diff] [review]
Fix, v8

Review of attachment 8852191 [details] [diff] [review]:
-----------------------------------------------------------------

Yeah I agree this is good to go (with some nits), and we can always improve later. ui-r=mkmelin

::: mail/locales/en-US/chrome/messenger/accountCreation.dtd
@@ +1,5 @@
>  <!-- This Source Code Form is subject to the terms of the Mozilla Public
>     - License, v. 2.0. If a copy of the MPL was not distributed with this
>     - file, You can obtain one at http://mozilla.org/MPL/2.0/. -->
>  
> +<!ENTITY autoconfigWizard2.title         "Set up existing email account">

Dialog titles are usually capitalized. And an "an" missing?

"Set Up An Existing Email Account"

@@ +54,5 @@
>  <!ENTITY half-manual-test.label          "Re-test">
>  <!ENTITY half-manual-test.accesskey      "t">
>  <!ENTITY manual-edit.label               "Manual config">
>  <!ENTITY manual-edit.accesskey           "M">
> +<!ENTITY open-provisioner.label          "Sign up for new email address...">

Capitalize, and use a real ellipsis char. And an "a" missing.

"Sign Up For A New Email Address…"

Comment 62

[Magnus Melin [:mkmelin]]

(In reply to Ben Bucksch (:BenB) from comment #56)
> I agree with making the dialog smaller on the first screen.

Re sizes: I find the changing of dialog size during the flow fairly annoying even as is. Wizards of the old style never did that and I find that more polished somehow.

Comment 63

[Jorg K (CEST = GMT+2)]

Great we all agree. I'm offering to fix the strings if we can agree on them ;-)

Apparently the articles "an" and "a" were left out to make it shorter. As for capitalisation:
The current button reads [Get a new account]. That is being changed to [Sign up for new email address]. I prefer lower case which looks less clunky on the button. Also, the button is wide enough as it is, so I'd omit the article.

I agree that the panel title should be upper-case: "Set up Existing Email Account". I'd leave out the "a" since that wouldn't be capitalised anyway, see
https://en.wikipedia.org/wiki/Capitalization_in_English#Capitalization_of_multi-word_place_names.2C_institutions_and_titles_of_works

So can we settle for:
Title: Set up Existing Email Account
Button: Sign up for new email address…

Going once, going twice, all silent? ... Sold!

Comment 64

[Magnus Melin [:mkmelin]]

Yeah I only meant for the title to be upper case, not the button.

"Sign up for new email address" sounds like really bad English without the "a". In the title, I suppose it's not as bad.

Comment 65

[Jorg K (CEST = GMT+2)]

OK, so:
Title: Set up an Existing Email Account
Button: Sign up for a new email address…

Now, may I suggest to shorten the button text to:
Button: Get a new email address…
as suggested by Alta88, a native English speaker, in comment #15.

Sold?

Comment 66

[Jorg K (CEST = GMT+2)]

Attachment: 1349259.png - screenshot with strings as per comment #65

As you can see, [Get a new email address…] is already quite wide. Having "Sign up for" instead of "Get" makes it too wide, IMHO.

Comment 67

[Magnus Melin [:mkmelin]]

Yeah that works for me. 
Please capitalize Up too.

Comment 68

[Jorg K (CEST = GMT+2)]

Attachment: 1349259-8.diff - Fix, v8 with slightly modified strings.

Sold!

Comment 69

[Jorg K (CEST = GMT+2)]

(In reply to Magnus Melin from comment #67)
> Please capitalize Up too.
Done in the patch. At first I was going to contradict, but then I found:
http://www.quickanddirtytips.com/education/grammar/capitalizing-titles
So "up" is used as part of the verb (look up, set up) not as pure preposition, "up the hill".

I'll get that landed unless anyone insists on the too long "Sign up for".

Comment 70

[Ben Bucksch (:BenB)]

Great. Thanks, all (Jörg, aceman, Magnus, Richard)!

Comment 71

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

If we are already contemplating how to shorten the string in English, I imagine this will be far worse in other languages with longer words. We can certainly land this and see how translators react, but if there is a solution that can accommodate for more width, then let's go with it.

Comment 72

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Please hold checkin pending confirm from Kent that there are no issues in landing this. Thanks!

Comment 73

[Magnus Melin [:mkmelin]]

If you're referring to the contractual arrangements, this is not removing the functionality to get a new account, it's just making it less in your face.

Comment 74

[Ben Bucksch (:BenB)]

Philipp, re contract: I did speak with Kent about this (see comment 47), and he looked at the contract, and he saw no issue. We have no contractual *obligation* to put anything in the product, nor to send any users to the company. It's a commissions-based contract. The contract gives us an option, not an obligation.

Furthermore, we are not removing the feature. Even if we removed the button from the dialog, we would still have the feature accessible elsewhere (notably in the File|New|… menu).

Comment 75

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/8bf47a3f978d
On first start, show account setup dialog, not account provisioner. r=aceman, ui-r=mkmelin,Paenglab

Comment 76

[Jorg K (CEST = GMT+2)]

I landed that now since based on the preceding comments I got the impression that we are under no contractual obligation to show the Gandi dialogue as the first screen. The provisioner is still there for all users wishing to sign up for a new e-mail address.

Should that assessment turn out to be wrong, we can always back this out.

Comment 77

[Ian Neal]

Comment on attachment 8901954 [details] [diff] [review]
1349259-8.diff - Fix, v8 with slightly modified strings.

>+++ b/mailnews/base/content/msgAccountCentral.xul

> #ifdef MOZ_THUNDERBIRD
>           <label class="acctCentralText"
>-                 value="&newAcct.label;"
>+                 value="&setupNewAcct.label;"
>                  chromedir="&locale.dir;"/>
> #else
>           <label class="acctCentralText acctCentralLinkText"
>-                 value="&newAcctLink.label;"
>+                 value="&setupNewAcctLink.label;"
>                  chromedir="&locale.dir;"
>                  onclick="CreateNewAccount();"/>
> #endif
Doesn't this change mean that SeaMonkey needs some string changes too?

Comment 78

[Jorg K (CEST = GMT+2)]

Yes, the author and reviewer missed that, and the sheriff, too :-(
What do you want to do:
1) revert this change
2) change string name for SM
3) change string name and string content, currently: "Create a new account", TB does now: "Set up an account".

The logic is that you then get to "Set Up an Existing Mail Account".

As soon as you let me know, I'll fix it. Sorry about this.

Comment 79

[Frank-Rainer Grahl (:frg)]

> 1) revert this change

No.

> 3) change string name and string content, currently: "Create a new account", TB does now: "Set up an account".

Personally I would use the same string content as TB but this would create some inconsistencies in SeaMonkey.

So just a news string name would be fine but is this even needed? Not seeing SeaMonkey using mail.provider.enabled and the rest of the patch is in mail so couldn't the old string stay?

Comment 80

[Jorg K (CEST = GMT+2)]

Well, the sting is in "account central" - msgAccountCentral.xul.

That's the page I hardly ever see, but it says:

============================
Create new account:
Email Chat Newsgroups Feeds

Create a new calendar
============================

This must show somewhere in SM with the existing string:
setupNewAcctLink.label
<!ENTITY setupNewAcctLink.label "Set up an account">
which unlike TB doesn't have the colon at the end.

Repeating:
1) revert this change.
2) change string name for SM
So suite/locales/en-US/chrome/mailnews/msgAccountCentral.dtd
15 <!ENTITY newAcctLink.label            "Create a new account">
Make that setupNewAcctLink.label
3) change string name and string content, so make that
<!ENTITY setupNewAcctLink.label            "Set up an account">

IMHO 1) makes sense, no change for SM, 2) doesn't make sense since the name wouldn't match the content and you trigger needless re-translation. 3) Makes sense.

Comment 81

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

(In reply to Ben Bucksch (:BenB) from comment #74)
> Philipp, re contract: I did speak with Kent about this (see comment 47), and
> he looked at the contract, and he saw no issue. We have no contractual
> *obligation* to put anything in the product, nor to send any users to the
> company. It's a commissions-based contract. The contract gives us an option,
> not an obligation.
Awesome, thanks for the reminder!

Comment 82

[Frank-Rainer Grahl (:frg)]

Attachment: revert.patch

setupNewAcctLink.label is the new string and I see no use 

TB string is "ifdefed" with  #ifdef MOZ_THUNDERBIRD

so just reverting the string change for SM should be enough unless I miss something (only into the first coffee of the day now :) )

Comment 83

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/e9d97ccc329b
Follow-up: Revert needless string change affecting SM and remove unused string. r=jorgk DONTBUILD

Comment 84

[Jorg K (CEST = GMT+2)]

Comment on attachment 8902645 [details] [diff] [review]
revert.patch

Thanks, looks fine. Sorry again for messing it up.

Comment 85

[Ben Bucksch (:BenB)]

frg, sorry, I didn't realize that SeaMonkey is affected by this change. :-(
Thanks, Jörg and frg, for landing and fixing this!

Comment 86

[Kent James (:rkent)]

I checked the contract again, and what I see is language "Mozilla will make available to Thunderbird consumers the then generally available version of the Gandi Services ...". There are other provisions to follow a mutual marketing plan that would be discussed at a meeting every 3 months (which has not occurred in fact for 5 years). So I think that "make available" is enough without a particular placement in our new account workflow.