531099 - Mail Account Setup Wizard need to be flexible

Status: RESOLVED WONTFIX

(Thunderbird :: Account Manager, enhancement)

Description

[mad.engineer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.5) Gecko/20091121 Thunderbird/3.0

The Mail Account Setup Wizard that shows up the very first time a new profile is created to add a new account or when someone installs TB and runs it, is good for people who want to use TB against their Gmail etc accounts as it saves some steps for doing the initial setup like mail server type, address port etc.

On the other hand this wizard is annoying for those who may want to to use TB against their work/corporate email where TB cannot access the setting correctly by just entering the email address and password. I think that instead the following options should be presented to the user the first time TB starts with a new profile:

A window should present the user with 2 choices only: Wizard and Manual setup

a) Ask the user if they want to use the Mail Setup Wizard and take them through the steps of auto-detecting and setup and 

b) Give user the option to manually do the setup. This is for Advanced users who want to do the setup manually.

Now, someone will say that the existing setup do give the user an option to click on Stop button and then click on Manual to do the same, but my experience so far with this flow is that it is very annoying. Even when I select the server type as IMAP, TB server name keep changing it to pop.server.com as an example and when I change the server name in the field, the pull-down for server type goes back to POP. That's why I suggest to keep it simple and let the user decide what route that want to use for setup.

Reproducible: Always

Steps to Reproduce:
1. See above
2.
3.


Expected Results:  
See above

Comment 1

[peter winterflood]

i would like to add to this as recently setup a friend with TH3 on talk talk.
wizard kept insisting on selecting the secure option when validating the connection despite me switching it off (talk talk does not support this)
and then when i bypassed wizard it had munged all the account settings.

had to go in and manually change all of them to get it to work.

had to do this on all 4 windows accounts.

it was really annoying, not what a wizard should be and not in line with the quality of features we usually expect from Mozilla

this is not a wizard its a pain.

please add the TH2 way as a direct option, rather than the fall back.

Comment 2

[David :Bienvenu]

Bryan, what do you think re blocking status? I think the manual setup option could be more obvious, but we don't have manual setup UI that lets you pick imap vs pop, for example (i.e., the account settings UI doesn't let you choose/switch). So we'd need the user to make at least that decision in the wizard before we went to account settings.

(In reply to comment #0)
 
> Now, someone will say that the existing setup do give the user an option to
> click on Stop button and then click on Manual to do the same, but my experience
> so far with this flow is that it is very annoying. Even when I select the
> server type as IMAP, TB server name keep changing it to pop.server.com as an
> example and when I change the server name in the field, the pull-down for
> server type goes back to POP. That's why I suggest to keep it simple and let
> the user decide what route that want to use for setup.

That's a bug that should be fixed, right?

Comment 3

[Charles]

(In reply to comment #2)
> Bryan, what do you think re blocking status? I think the manual setup option
> could be more obvious, but we don't have manual setup UI that lets you pick
> imap vs pop, for example (i.e., the account settings UI doesn't let you
> choose/switch). So we'd need the user to make at least that decision in the
> wizard before we went to account settings.

I also really like the idea of a fully manual option, but I'm confused as to why you couldn't just add an 'Account Type' selector? The account hasn't been created yet, right?

Also, if you do decide to work on this UI, I'd really appreciate it if consideration were given to bug 543827 (use same credentials for outgoing smtp server as for incoming).

> (In reply to comment #0)
> 
>> Even when I select the server type as IMAP, TB server name keep changing
>> it to pop.server.com as an example and when I change the server name in
>> the field, the pull-down for server type goes back to POP. That's why I
>> suggest to keep it simple and let the user decide what route that want
>> to use for setup.

> That's a bug that should be fixed, right?

I don't think the auto-detect will ever be perfect except maybe for well established public servers like gmail, yahoo, hotmail, etc. Corporate servers will very often have 'weirdness' to contend with, and having a manual option for those will be great.

Of course, I'm all for improving the auto-detect code, so a suggestion - maybe you guys could create a formal process whereby anyone whose corporate server doesn't work right with the auto-detect code could 'donate' a test account that you could use to fix whatever isn't working right? I know I'd be happy to do so. For ours, TB won't correctly auto-detect either one - IMAP+SSL on port 993, or smtp+STARTTLS on port 587. Also, it seems to only try port 465, which is not even enabled on m=our server - this is wrong. Since port 465 is deprecated, port 587 should at least always be the preferred/tried first for outbound/smtp server setup.

Comment 4

[Charles]

(In reply to comment #3)
> (In reply to comment #2)
>> but we don't have manual setup UI that lets you pick imap vs pop, for
>> example (i.e., the account settings UI doesn't let you choose/switch).
>> So we'd need the user to make at least that decision in the wizard before
>> we went to account settings.

> I also really like the idea of a fully manual option, but I'm confused as to
> why you couldn't just add an 'Account Type' selector? The account hasn't been
> created yet, right?

Upon re-reading this, I think I see where my confusion was...

I was thinking of just a fully manual mode for the *wizard* - it already *does* have the ability to manually choose POP vs IMAP (I replied to that without actually looking again at the wizard).

So, my suggestion would simply be for clicking the manual setup to put the wizard into manual mode - ie, tell it to stop second guessing me and trying to auto-detect anything, and just test the settings I provide myself.

Also, is there any logic to the order of things tried? Ie, try the submission port (587) with STARTTLS before falling back to the deprecated SMTPS (SSL over port 465)? If not, I'll go open another bug request.

Comment 5

[Bryan Clark (DevTools PM) [:clarkbw]]

Seems like a couple bugs here, I'm not sure what should be tackled in this bug.

1) switch between POP and IMAP is being handled in bug 532590

2) Change of ports on incoming and outgoing servers via comment 3 seems like we should open a separate bug for changing the auto-detect code

3) Better auto-detection of settings provided by users.  I'm not sure how the code handles it now but it seems like it tries your settings and then just loses them if something doesn't pan out.  We should probably just always take the user settings and only auto-change things not edited (falling back to the unedited values if failing) and perhaps offering a "total reset" back to full auto-detection in case the users manual settings are failed.

I feel like this is (3) and we should probably write out more of the situation details to get this started.  This seems like it would block the 3.1 release to me if we knew exactly what is happening now and how we could fix it to better handle this situation.

Comment 6

[Charles]

(In reply to comment #5)
> 3) Better auto-detection of settings provided by users.  I'm not sure
> how the code handles it now but it seems like it tries your settings
> and then just loses them if something doesn't pan out.  We should
> probably just always take the user settings and only auto-change
> things not edited (falling back to the unedited values if failing)
> and perhaps offering a "total reset" back to full auto-detection in
> case the users manual settings are failed.

Why not just make the Wizard start in manual mode, then add an 'AutoDetect Settings' button? This seems more intuitive to me than starting it in AutoDetect mode and having a 'Manual Mode' button (which isn't there currently).

> I feel like this is (3) and we should probably write out more of the
> situation details to get this started.  This seems like it would
> block the 3.1 release to me if we knew exactly what is happening now
> and how we could fix it to better handle this situation.

How about this:

1. Eliminate the initial smaller window that prompts only for 'Name,
   Email address, Password', and let it open straight to the main 'Mail
   Account Setup' window instead. The initial window seems superfluous
   to me, since the exact same info is displayed (but *not* editable*)
   in the main window. I see no reason to complicate the process with
   two different windows and a 'Start Over' button... simpler is best.

2. Provide an 'Auto-Detect Settings' button that *manually* performs the
   auto-detection, and then just inform the user what services and/or
   ports appear to be available based on their email address.

This could be in the form of a separate line for each, selectable via a radio button, or just some text explaining what is available, with some choices available via some buttons, but I haven't thought this out thoroughly. I'm working on a mock-up of what the GUI could look like.

3. *If* both POP & IMAP seem to be available, provide simple tool-tips
   explaining POP/IMAP, with links to more detailed web pages, but
   *only* if both POP *and* IMAP services are available, otherwise it
   could only confuse the user unnecessarily,

4. Have an action button that, as long as the user doesn't manually
   change anything, is labeled 'Accept Recommended Settings', otherwise
   the button changes to just 'Create Account',

4. 'Recommended Settings' should always be in the following priority:

 a) IMAP
   1) port 143 > STARTTLS/SSL
   2) port 993 > STARTTLS/SSL
   3) port 143 > NONE
   4) port 993 > NONE <- should this even be tested for/offered?

 b) POP
   1) port 110 > STARTTLS/SSL
   2) port 995 > STARTTLS/SSL
   3) port 110 > NONE
   4) port 995 > NONE <- should this even be tested for/offered?

 c) SMTP
   1) port 587 > STARTTLS/SSL
   2) port 25  > STARTTLS/SSL
   3) port 25  > NONE
   4) port 587 > NONE <- should this even be tested for/offered?

STARTTLS/SSL means: STARTTLS is preferred, but if it doesn't work, fall back to SSL.

Also, I really believe that a big fat warning should always be displayed whenever insecure settings are the only choices. Also, if the submission port is not available as an option, the user should be informed that they might have trouble sending email behind some firewalls, and if this is a laptop, they will be *very* likely to have trouble sending mail when traveling.

Comment 7

[Bryan Clark (DevTools PM) [:clarkbw]]

Thanks for the detailed reply!

(In reply to comment #6)
> (In reply to comment #5)
> > 3) Better auto-detection of settings provided by users.  I'm not sure
> > how the code handles it now but it seems like it tries your settings
> > and then just loses them if something doesn't pan out.  We should
> > probably just always take the user settings and only auto-change
> > things not edited (falling back to the unedited values if failing)
> > and perhaps offering a "total reset" back to full auto-detection in
> > case the users manual settings are failed.
> 
> Why not just make the Wizard start in manual mode, then add an 'AutoDetect
> Settings' button? This seems more intuitive to me than starting it in
> AutoDetect mode and having a 'Manual Mode' button (which isn't there
> currently).

Unless a person knows that their settings can't be auto-detected (which is very technical knowledge) asking them before trying to auto-detect isn't a fair question.  Right now we require you start the auto-detect before you could jump into manual account creation, I believe it's possible to offer that manual mode before starting auto-detect so you don't have to run it.


> > I feel like this is (3) and we should probably write out more of the
> > situation details to get this started.  This seems like it would
> > block the 3.1 release to me if we knew exactly what is happening now
> > and how we could fix it to better handle this situation.
> 
> How about this:
> 
> 1. Eliminate the initial smaller window that prompts only for 'Name,
>    Email address, Password', and let it open straight to the main 'Mail
>    Account Setup' window instead. The initial window seems superfluous
>    to me, since the exact same info is displayed (but *not* editable*)
>    in the main window. I see no reason to complicate the process with
>    two different windows and a 'Start Over' button... simpler is best.

It would be good to see what you mean by this.  We had this initially but the bottom area was just empty space.

Also if you allow people to edit the password or email address during auto-detection you complicate the detection process.  For example you don't know if you should drop the original detection and start over with the new information.  Plus without a start over button you don't know when they are done typing, you can try to wait and detect a pause in typing or unfocus of the input but those aren't reliable or simple.

> 2. Provide an 'Auto-Detect Settings' button that *manually* performs the
>    auto-detection, and then just inform the user what services and/or
>    ports appear to be available based on their email address.
> 
> This could be in the form of a separate line for each, selectable via a radio
> button, or just some text explaining what is available, with some choices
> available via some buttons, but I haven't thought this out thoroughly. I'm
> working on a mock-up of what the GUI could look like.
> 
> 3. *If* both POP & IMAP seem to be available, provide simple tool-tips
>    explaining POP/IMAP, with links to more detailed web pages, but
>    *only* if both POP *and* IMAP services are available, otherwise it
>    could only confuse the user unnecessarily,

This sounds good but I believe it is all part of bug 532590


> 4. Have an action button that, as long as the user doesn't manually
>    change anything, is labeled 'Accept Recommended Settings', otherwise
>    the button changes to just 'Create Account',

I'm not exactly sure what you mean here so it would be good to see this in the mockups.  Also beware that for accessibility reasons you can't just swap the labels on buttons.  You either need two buttons and likely an action (like pressing another button) that causes one of the buttons to hide.

> 4. 'Recommended Settings' should always be in the following priority:
> 
>  a) IMAP
>    1) port 143 > STARTTLS/SSL
>    2) port 993 > STARTTLS/SSL
>    3) port 143 > NONE
>    4) port 993 > NONE <- should this even be tested for/offered?
> 
>  b) POP
>    1) port 110 > STARTTLS/SSL
>    2) port 995 > STARTTLS/SSL
>    3) port 110 > NONE
>    4) port 995 > NONE <- should this even be tested for/offered?
> 
>  c) SMTP
>    1) port 587 > STARTTLS/SSL
>    2) port 25  > STARTTLS/SSL
>    3) port 25  > NONE
>    4) port 587 > NONE <- should this even be tested for/offered?
> 
> STARTTLS/SSL means: STARTTLS is preferred, but if it doesn't work, fall back to
> SSL.

I'm fairly sure this is what is done, however we should probably open up a new bug for this as the problem is easily scoped and separate from this bug.

> Also, I really believe that a big fat warning should always be displayed
> whenever insecure settings are the only choices. 

We already provide indicator lights beside each line which offer information about the security of the account and then display a large warning for each account that is insecure.

> Also, if the submission port
> is not available as an option, the user should be informed that they might have
> trouble sending email behind some firewalls, and if this is a laptop, they will
> be *very* likely to have trouble sending mail when traveling.

We can provide additional text but most usability studies show that people don't read that text.  We do have a bug somewhere else for helping people connect to a new server when they are sending an email and can't connect to the original server.

Comment 8

[Charles]

(In reply to comment #7)
> Thanks for the detailed reply!

Heh - usually people complain about 'too much information'... ;)

>> Why not just make the Wizard start in manual mode, then add an
>> 'AutoDetect Settings' button? This seems more intuitive to me than
>> starting it in AutoDetect mode and having a 'Manual Mode' button
>> (which isn't there currently).

> Unless a person knows that their settings can't be auto-detected
> (which is very technical knowledge) asking them before trying to
> auto-detect isn't a fair question.

Well, I guess we all agree that the way it is currently implemented is just too confusing... :)

Hopefully this won't freak anyone out (I have a tendency to go a little overboard with things I'm passionate about), but while doing the mockups I've come up with something a little different. It does still use an 'initial' window, but then has two 'cascading' *optional* secondary windows where all of the details are/can be exposed... let me know what you think (3 attachments to follow)...

'Normal' users will almost always be confused by the details shown when auto-detecting, so what I'd prefer is to just hide the details as much as possible in the initial screen, while prompting for and providing enough information to make setting up the new account as easy as possible in most cases, but easily allowing an advanced user to just take charge and 'do it their way'...

> Also if you allow people to edit the password or email address during
> auto-detection you complicate the detection process. For example you
> don't know if you should drop the original detection and start over
> with the new information.

There are (or should be) 2 parts to the auto-detection - detecting what services (POP[S]/[S]IMAP[S]/[S]SMTP[S]) are available on what ports (call this 'validation'), and whether or not the user can successfully authenticate (call this 'authentication') over the selected services/ports. I suggest separating this code out if it isn't already.

> Plus without a start over button you don't know when they are done
> typing, you can try to wait and detect a pause in typing or unfocus
> of the input but those aren't reliable or simple.

Hmmm... I was thinking you could simply detect when the cursor entered *then left* the text box... are you saying you can't do that?

>> 4. 'Recommended Settings' should always be in the following priority:

<snip>

>> STARTTLS/SSL means: STARTTLS is preferred, but if it doesn't work,
>> fall back to SSL.

> I'm fairly sure this is what is done, however we should probably open
> up a new bug for this as the problem is easily scoped and separate
> from this bug.

Is the auto-detect process detailed anywhere? I'd be interested in reading up on it...

Thanks a lot Bryan for listening, and even if you don't like some of my ideas, hopefully some of this will be helpful...

Comment 9

[Charles]

Attachment: Modified initial 'Mail Account Setup' window

First attachment: mockup of modified initial 'Mail Account Settings' window.

I've added enough additional information so that an account that has pre-defined settings available to TBs auto-detect process can be created and validated from this initial window...

Comments:

Personally, I think all 4 check-box options on this window should be checked by default.

The 'Test Settings' button is greyed out until something is entered in the passowrd box.

The 'Create Account' button is greyed out until the 'Test Settings' results in 'Test Successful'.

The 'I don't know - Help Me Choose' choice for the Account Type will pop-up a local help window explaining the pros and cons of each, with a link to a decent web page with a more detailed explanation.

Also, little things like:

 a) if the predefined settings say that a full email address is required,
    the user shouldn't be able to un-check that box.

 b) a fat warning should pop-up if the user tries to un-check 'Use only
    secure settings'

Comment 10

[Charles]

Attachment: Mail Account Settings window - showing Manual Account Settings

Ok, this is the window as it would appear after clicking the 'Manual / Advanced Settings' button.

The 'Test Settings' button, 'Test Settings' results and 'Create Account'  button have been moved down into the Advanced section. The user can now manually define their settings without any interference from the auto-detection process.

Comment 11

[Charles]

Attachment: Mockup of a new 'Auto-Detect' section of the 'Mail Account Settings' window

Ok, here is the last section where the *manual* auto-detect would be used...

I know this one is long, but remember - the auto-detection would also be working behind the scenes on the initial window, the user simply wouldn't see these extra details. As long as the account provider was well defined in TBs database, the auto-detection would 'just work' and the user would never see either of these last two sections...

The detected servers (both Incoming and Outgoing) are simply listed as detected, there is no ability to change any of their settings, unless/until you click the 'Try Me' button, which would then load that choice in the appropriate slot (Incoming or Outgoing) up in the 'Manual / Advanced' section, where the details could then be modified by the user.

Lastly - I removed the 'Manual / Advanced' button on this window, since it wouldn't make sense to be able to collapse it without first collapsing the 'Auto-Detect' section, although I guess it could stay and if clicked it would collapse both sections. The window was pretty long though (like I said, I went a little overboard) so I was trying to find ways to make it smaller...

Ok, well, that's the best I can do... hopefully it will give someone some useful ideas...

Comment 12

[Chris Ramsden]

I'm surprised at the emphasis you guys put on secure connections and IMAP. Here in the UK at least, AFAIK both of these are very much in the minority. Most ISPs deliver via regular, non-secured POP3. (Unless you have data to show otherwise?) I think you'll scare users with your warning; if the server demands TLS or SSL then by all means use it. If the server doesn't support a secured connection, the poor end user doesn't really have any choice and what's the point in frightening them with a warning? Make it "informational" rather than a warning. 

I've seen the distress caused by an ISP losing users' email data; I would only leave my email data on a 3rd party server if I had a cast-iron SLA with them or if the data was trivial and not valuable. I can't agree with you pushing newbie users into using IMAP if there is no guarantee for their data's safety.

Comment 13

[Charles]

(In reply to comment #12)
> I'm surprised at the emphasis you guys put on secure connections and IMAP.

Well, these are 2 totally separate and distinct issues.

Unsecured connections can be sniffed by pretty much anyone - which means that your username/password can easily be stolen. In the modern age with identity theft being so prevalent, anyone using a non-secure email connection is just begging to have their email compromised.

So, in my opinion, a strong warning is warranted whenever someone intentionally uses an insecure connection.

> Here in the UK at least, AFAIK both of these are very much in the minority.

IMAP usage, maybe. Secured connections? Only because this is the default for most mail clients. If the secured option is the default, most people will just use it, and won't ever see the warning.

> Most ISPs deliver via regular, non-secured POP3.

Virtually all ISP's *offer* non-secured connections - yes, but virtually all *also* offer *secured* connections. All I am talking about is making the secured option the default.

> I think you'll scare users with your warning;

That's the intention... ;)

> if the server demands TLS or SSL then by all means use it. If the server
> doesn't support a secured connection, the poor end user doesn't really have
> any choice and what's the point in frightening them with a warning?

False premise. In virtually all cases, it isn't an either/or choice - the server will offer *both*.

and in those rare situations where an ISP *doesn't* offer a secured option, maybe the warning should also urge them to yell at their *incompetently run* ISP to offer secured connections?

As an aside, I think anyone who uses their ISP for their primary email account is not thinking things through. The first thing I always do when changing ISPs is log into the web account and forward all mail to the 'primary account email address' they assigned to me when I signed up, to the gmail account I use for this purpose.

> Make it "informational" rather than a warning. 

No, it needs to be a warning, because non-secure connections can easily be compromised.

> I've seen the distress caused by an ISP losing users' email data;

And I have seen the distress caused by a user losing all of their email due to a hard drive crash and they didn't have any backups, but what does that have to do with it?

> I would only leave my email data on a 3rd party server if I had a cast-iron
> SLA with them or if the data was trivial and not valuable.

My 3rd party email accounts (mostly gmail) all contain essentially trivial data. Not that I'd be ecstatic if it was lost, but it wouldn't be a big problem. But in my opinion, this is a non issue. The number of times a large provider like this has lost all of a users email are far, far fewer than the number of users who have lost their own email due to hard drive failures or just doing something dumb and not having backups.

> I can't agree with you pushing newbie users into using IMAP if there is no
> guarantee for their data's safety.

Well, on this point I'm not completely in disagreement.

But that's why I designed the new account window like I did - to provide a 'learning opportunity' for the user. IMAP rocks, if used properly, and I think users should be made aware of its advantages.

Comment 14

[Chris Ramsden]

It's good to talk.

I just tried setting up a 2nd instance of my primary email account, using shredder 3.0.3pre. 

Maybe my set-up is too unusual?  

My main pop3 account is run by my domain registrar and uses the format [e-mail]

My working email address, using my own domain name, is then [e-mail]. The registrar/email provider provides the dns mapping or whatever is needed for [e-mail] emails to appear in the [e-mail] inbox. For most purposes, the account is referred to as [e-mail]; I need to remember the [e-mail] details only when using webmail or setting up an email client. 

So my working email address, my "real" email address and my username (user1) are three entirely distinct and different entities.

My smtp is handled by my ISP, so that's [e-mail]. 

I am hopeful that your proposed manual setup would work for me, as shredder's wizard fails abysmally with my arrangement. I'm pleased to see that you've provided a separation between username and email address, which currently shredder doesn't seem capable of using. 

Neither of the two servers involved here has responded to SSL/TLS. I remain convinced that unsecured email, sadly, is the norm, at least in the UK. 

Hey, do you know what put me off IMAP? The fact that TB2 was so slow when using it. ;)

Comment 15

[Charles]

(In reply to comment #14)
> I am hopeful that your proposed manual setup would work for me,

Sure it would... as long as you have the info needed. You'd need to know the server names (ie, pop.example1.com and smtp.example3.com) in order to get it working.

> Neither of the two servers involved here has responded to SSL/TLS. I remain
> convinced that unsecured email, sadly, is the norm, at least in the UK. 

Care to share the real domains? I'll bet they do offer secure connections, but if you're right and they don't, you should be yelling at them, and indeed, whenever possible voting with your pocketbook and simply changing to one that does.

> Hey, do you know what put me off IMAP? The fact that TB2 was so slow when
> using it. ;)

It wasn't all that slow, really, but what was so maddening to me was how it would constantly redownload the same large attachments over and over and over again, unless you had set a folder to offline mode. TB3 is soooo much better, really... just a lot of little things and rough edges to polish.

I sincerely hope the devs will focus on performance and stability issues first and foremost, followed by supporting as many IMAP extensions as possible, especially tweaking things to take advantage of dovecots extremely fast server side search capabilities on folders that are not set to offline mode, etc, before making any more major UI changes - aside from ones that are needed, like the New Account Wizard we're discussing here... ;)

Comment 16

[Chris Ramsden]

I've fired off messages to both providers, asking for info on their security provisions. We'll see....

The domains in question are (example1.com) tamba.co.uk (pop3, they haven't 'fessed up to offering IMAP) and (example3.com) cluster1.vfast.co.uk for smtp. 

Thanks for your interest. ;)

Comment 17

[Charles]

Oh, one more thing...

Often the secure options aren't offered on the standard ports, so you'd have to try:

imap: port 993

pop: port 995

smtp: port 587 (or 465, but that is deprecated and should only be used if thats the only option)

Comment 18

[Dan Mosedale (:dmosedale, :dmose)]

I think there's _something_ in this bug that blocks, and whatever it is needs to get in before feature freeze, but there's a ton of context to wade through here to figure out exactly what that is.  Since clarkbw already appears to have most of the context in his head, I'm going to ask for his feedback here.

Comment 19

[Charles]

Dan/Bryan et al...

I did put a little bit of effort into these mock-ups, so would appreciate at least some minimal comments, even if you don't like them (I have very thick skin). It wasn't that much time (an hour or so), and I absolutely don't mind doing it - in fact, since I'm not a programmer, things like this are the only way I can contribute to the process and I'm happy to do so - but I also don't enjoy wasting my time either...

Comment 20

[Chris Ramsden]

I like them; they would appear to give me the manual control I need and the layout and sequencing looks sensible, logical and practical to me. 

If I hadn't previously been using TB2 and therefore had working accounts for TB3 to inherit, I doubt I would be using (or be able to use) TB3 right now. The wizard doesn't work, the manual override doesn't work. There are many dissatisfied would-be users on GS who appear to have had similar problems.

Comment 21

[Dan Mosedale (:dmosedale, :dmose)]

Your effort with mockups is much appreciated, thanks!  Note that both Bryan and I are crazy loaded at the moment, so our response times tend to vary a bunch.  My current theory about this bug is that I'm hoping Bryan will find time to at least provide some input soon.  On the off chance that he can't because he's caught up in other things, it's still got a blocking? flag set, so it won't get lost.

Comment 22

[Bryan Clark (DevTools PM) [:clarkbw]]

(In reply to comment #8)
> (In reply to comment #7)
> Heh - usually people complain about 'too much information'... ;)

Sorry for the slow response, this is usually what people complain about with me :)

> Well, I guess we all agree that the way it is currently implemented is just too
> confusing... :)

Definitely, it's a difficult process to get right.

> Hopefully this won't freak anyone out (I have a tendency to go a little
> overboard with things I'm passionate about), but while doing the mockups I've
> come up with something a little different. It does still use an 'initial'
> window, but then has two 'cascading' *optional* secondary windows where all of
> the details are/can be exposed... let me know what you think (3 attachments to
> follow)...

Thanks for putting this all together, I'll reply inline to each but wanted to say what I think our goals are in general.  An initial, simplified interface that competes with web mail signup; i.e. name, username, password.  Secondary goals are to offer ways for people using less common setups to use a manual + auto-test setup system.


> 'Normal' users will almost always be confused by the details shown when
> auto-detecting, so what I'd prefer is to just hide the details as much as
> possible in the initial screen, while prompting for and providing enough
> information to make setting up the new account as easy as possible in most
> cases, but easily allowing an advanced user to just take charge and 'do it
> their way'...

Agreed, I think the next iteration of this interface will lose the details being show like the host names and ports.  We can probably just go with a simpler interface which shows progress and then offers a choice of POP or IMAP with the settings that have been detected.   It might make sense to then have the manual + auto-test be a different section after our settings.

> There are (or should be) 2 parts to the auto-detection - detecting what
> services (POP[S]/[S]IMAP[S]/[S]SMTP[S]) are available on what ports (call this
> 'validation'), and whether or not the user can successfully authenticate (call
> this 'authentication') over the selected services/ports. I suggest separating
> this code out if it isn't already.

Right, what I'm reading you say is that we have 1 part which is fully automatic and works for the majority of emails.  Then another part which is akin to "sport shifting" for vehicles, aka manual control with automatic help.  If part 1 fails we open up part 2 and we can have an option from the beginning which allows people to access part 2, skipping part 1.
 
> Hmmm... I was thinking you could simply detect when the cursor entered *then
> left* the text box... are you saying you can't do that?

Yes, you can't actually do this successfully.  Sometimes people don't unfocus the entry, especially the last entry of a form.  They enter their password and then grab the mouse and click a button; the password entry was in focus this entire time.  We could try to be really, really clever and detect all the possible situations in which a person might be done but it's complicated and sucks when it's wrong so it's better to just be simple and obvious.
 
> Is the auto-detect process detailed anywhere? I'd be interested in reading up
> on it...

The wiki might have some dated information
https://wiki.mozilla.org/Thunderbird:Autoconfiguration

also the original bug 422814

> Thanks a lot Bryan for listening, and even if you don't like some of my ideas,
> hopefully some of this will be helpful...

Again, sorry for the delays in response don't read into it other than I've been busy and we don't have that cloning machine built yet.

Comment 23

[Charles]

No worries Bryan, I just wish rather than mock-ups I could provide code... anyway, I look forward to your comments...

Comment 24

[Bryan Clark (DevTools PM) [:clarkbw]]

Ok, Charles I put some work into mockups of my own so we can start comparing what's happening in each and see if there is a common ground.  I placed my up on the wiki but you can continue uploading them here or whatever you like if you have further ones you want.

I'm using the Pencil add-on for firefox ( https://addons.mozilla.org/en-US/firefox/addon/8487 ) to build these and if you want my source file just email me.  For some reason the buttons come out black on the Mac, please ignore.

All the files are available on the wiki page here:
https://wiki.mozilla.org/Thunderbird:Autoconfiguration:UI

I'll try to compare and contrast our methods, I'd love to hear your feedback.

== Initial Dialog ==

attachment 427822 [details]
and
https://wiki.mozilla.org/File:Thunderbird-Autoconfiguration-Initial_View.png

I believe the goal here is to give people an obvious path for getting setup.  Our least advanced users shouldn't end up anywhere else other than entering their account information and pressing continue.  (blue circles indicate default buttons - i'm really sorry about that black color; I COULDN'T FIX IT! ARRGG!!)

I placed a link button to "Skip to manual configuration" for those people who know they don't want the auto-config step.  This link would take them to my final page, https://wiki.mozilla.org/File:Thunderbird-Autoconfiguration-Sport_Configuring.png

The major difference here is I want to make sure most people take the main path and only a few take the road less traveled.

== During Configuration ==

https://wiki.mozilla.org/File:Thunderbird-Autoconfiguration-Auto-Configurating.png

I made a quick page to show the intermediate step of finding the configuration.  I've removed all the text that gets flashed by and just have a single progress meter with a ( Cancel ) button.  When finished this changes to the next step.

== After Auto-Configuration ==

attachment 427831 [details]
and
https://wiki.mozilla.org/File:Thunderbird-Autoconfiguration-Auto-Configured.png

Two things I really like that you did were the explanation of choice at the top.  "Your email supports both POP and IMAP" - <a>find out more</a>  Also I really like the [x] Hide insecure options checkbox.  I'm going to try those things on a further revision because I think they have a lot of promise.

In mine I tried to really simplify the choice of IMAP vs. POP and the options available.  I want (most) people to read it in their heads like "IMAP, secure, imap.example.com" and that's about it.  On hover of any of the options I we can create a tooltip that explains more.  We currently have an example of those tooltips when you click on one of the green/orange/red circles.  Your mockup has more of the data readily available but I'm not sure this type of user will be able to make use of it.

I've added the username for both incoming and outgoing.  I want it to look like something that was detected and not just an input until the person decides to edit it.  Essentially people will go ahead and try to edit anything that looks like an input; even if they don't need to.  So it's our responsibility to make sure people don't edit things they don't need to while at the same time making it possible for others to do that.

At this point you can change to manual mode, I think I left it as "skip to manual" but it should probable update to "Change to manual mode".

== Sport Manual Configuration ==

During this phase we don't do any smart detection or probing but only test out the settings as given.  This simplifies the user experience quite a bit as compared to now where we'll use your settings and try others as well.

attachment 427828 [details]
and
https://wiki.mozilla.org/File:Thunderbird-Autoconfiguration-Sport_Configuring.png

I think you have the right idea here where we show all the available inputs and allow them to test the configurations while displaying a plus or minus if it's known to work.  I tried to embody that in mine, the two seem very similar to me other than I kept the IMAP/POP separation and SMTP is still in it's own section.

I'm not sure how to convey correctly that a connection is secure or not, or perhaps even if it matters at this point.

One small note is that I think it makes sense to use a combo box for the ports, an editable list so that people can choose the obvious defaults or enter their own values.

Only from here can you then create an account into the Account options dialog which has even more knobs and buttons available to customize your account as needed.

== Testing ==

There's a final password testing phase we go through and it would be good to have mockups of this.  Before this point Thunderbird has only probed and has not actually tested that it can successfully connect to any account.  However at this point we want to try logging into the incoming and outgoing servers to ensure that we have the correct settings and they work.

Thoughts?

Comment 25

[Charles]

Whew! I'm sorry this got to be so long... but you for my thoughts... ;)

(In reply to comment #24)
> Ok, Charles I put some work into mockups of my own so we can start comparing
> what's happening in each and see if there is a common ground.  I placed my up
> on the wiki but you can continue uploading them here or whatever you like if
> you have further ones you want.

If you don't mind me editing the pages, sure (I already have an account, just almost never use it)... I'll edit the main page so each of ours (and anyone else's if they want to jump in) are in their own section.... but I have a problem...

I just don't know enough about how the auto-detect/pre-configured account system/process stuff works to make any hard decisions about what can and/or should go on these New Account dialogs (and where/which screen). For example, when TB is 'determining account settings', and on your last screen where it says 'We could not find a suitable configuration for your mail' - what does this mean?

I recall reading somewhere many moons ago a reference to some online database of pre-configured account settings for well known/public servers (like gmail, hotmail, yahoo, etc), and when I entered this discussion I tried googling it but came up dry, so I asked for more info at the very bottom of comment 8, but no one responded (I guess it was easy to miss though)...

So... before I can make any more intelligent decisions about what specifically should go on the mock-ups (and where/how it is displayed), I really need to know more about the auto-detect/pre-configured account system/process.

But I'll go ahead and comment as much as I can in general...

> I'm using the Pencil add-on for firefox

I'm using Draw, and most comfortable there... but thanks for the pointer to Pencil, I hadn't seen that one before and it looks like it could come in handy...

> All the files are available on the wiki page here:
> https://wiki.mozilla.org/Thunderbird:Autoconfiguration:UI
> 
> I'll try to compare and contrast our methods, I'd love to hear your feedback.

Careful what you ask for... ;)

> == Initial Dialog ==
> 
> attachment 427822 [details]
> and
> https://wiki.mozilla.org/File:Thunderbird-Autoconfiguration-Initial_View.png
> 
> I believe the goal here is to give people an obvious path for getting setup. 
> Our least advanced users shouldn't end up anywhere else other than entering
> their account information and pressing continue.

Well, I agree that the simpler the better, but I also don't see any reason to cripple things too much for more advanced users, if it can be done in a way that doesn't get in the less advanced users way.

Imo, when adding new 'config-files' (or whatever these are called) to the online database, as well as for accounts that do *not* have a 'config-file' available, the below preferences should always be considered:

(maybe some/most/all of these are already done)

Conceptual/backend items:

1. Always use secure over non-secure,

2. Always give preference to STARTTLS over SSL,

3. For SMTP, always give preference to the submission port (587), then 465/SSL, and only use 25 if neither 587 or 465 are available,

4. If a server has no secure options, a warning should be issued, with a suggestion to complain to the provider,

5. Unless evidence to the contrary exists, default to using the full email address for the username for unknown systems. I think most systems are moving to this, if they aren't already there - of course, once I know more about the auto-detect/pre-configured account system/process.

Next are the only 3 real issues I have with your UI mock-ups... I still believe these should be added, although two of them I have specified that I could live with being implied (hidden from the main/initial account dialog but enabled/active), but still believe they don't add any real complexity, and make the auto-config a little more user friendly for advanced users:

1. Make bug 543827 block this bug, and add the option to 'Use same username/password for sending mail', enabled by default (as shown on my mock-up). I guess this option *could* be implied, but its not that complicated, so I'd prefer it be visible, already checked, with a warning if the user unchecks it explaining the potential consequences,

2. Add an 'Account Name/Label' box in the upper right corner - this could auto-populate itself with the email address, but still be editable so the user can change it, and

3. I still think having the 'Use only secure settings' option (already checked) should be on there (also with a pop-up warning if unchecked) - or, at a minimum it could also just be implied, but its not really that complicate either, at least, not in general - the specifics (SSL vs STARTTLS), yes, but not the general label I've used...

> The major difference here is I want to make sure most people take the main
> path and only a few take the road less traveled.

The only potential problem I have with that concept in general is it can easily be taken too far - dumbing things down *too* much. But I agree I may have gone a bit overboard on my initial version... ;)

So, if you implemented the 3 exceptions described above, I'd be fine with yours...

One other issue that should be discussed further is the idea of pushing IMAP over POP - I really don't think that's a good idea - at least not without forcing some kind of explanatory text on them and making them click a button to acknowledge they've read it and understand the differences - mainly because most people I know have been using POP, even though most don't even know it (eyes glaze over when I ask them). But at the same time, I do only use IMAP, and think there is a great opportunity for making this a learning experience for the user if done right (as my mock-ups hopefully convey) - meaning, give the user an 'easy out' from the learning experience, but try to word the teaser text in such a way that some (lots of) people will click the 'I want to learn the difference between POP and IMAP' button.

> == During Configuration ==
> 
> I made a quick page to show the intermediate step of finding the
> configuration. I've removed all the text that gets flashed by and just
> have a single progress meter with a ( Cancel ) button.  When finished this
> changes to the next step.

Like it, with the numbered exceptions above... :)

> == After Auto-Configuration ==
> 
> Two things I really like that you did were the explanation of choice at the
> top.  "Your email supports both POP and IMAP" - <a>find out more</a>  Also I
> really like the [x] Hide insecure options checkbox.  I'm going to try those
> things on a further revision because I think they have a lot of promise.
> 
> In mine I tried to really simplify the choice of IMAP vs. POP and the options
> available.  I want (most) people to read it in their heads like "IMAP, secure,
> imap.example.com" and that's about it.

Yes, I like what you've done there... I like the gold padlock that hides the STARTTLS/SSL details, which means nothing to the less advanced users anyway.

> On hover of any of the options I we can create a tooltip that explains more.

So I could mouseover the padlock and see what is actually being used (SSL or STARTTLS)... perfect... :)

But, in my experience, while tooltips are good, the less advanced users often don't 'get' them, at least until they are explicitly pointed out (then they say 'oh! cool!'). It may help to have a comment like 'Hover your mouse over any option to get detailed help' at the top of a window, but they often don't see those comments either. One thing I've seen used that helps with some users is a little Help button (sometimes its just a question mark) in the upper right corner (either to the left of the minimize button, or maybe down inside the window, beneath the close button) - users will often see that and click on it, where they won't even try mousing over the option itself otherwise. When they click on (or mouseover) it, a tooltip could simply explain how the tooltips work.

Or maybe we just have extra dumb users... ;)

Incidentally, I'm a lone I.T. guy for a small company (50+ users, mostly Sales Reps), and we have been using Thunderbird (and Firefox) exclusively since about version 0.8, so I have a very good idea of how users will react to certain things. One more way I can contribute would be to call a meeting, go over some proposed UI changes, and get feedback. They hate it when I do that (time is money), so I wouldn't want to do it every day, but if there is interest in 'using my users' for things like this, I can make it happen...

> We currently have an example of those tooltips when you click on one of the
> green/orange/red circles.  Your mockup has more of the data readily available
> but I'm not sure this type of user will be able to make use of it.

Maybe you could add some kind of 'More/Less Details' toggle button somewhere, defaulting to showing Less (so the button would be labeled 'Show More Details')?

> I've added the username for both incoming and outgoing.

Yes, I like it - but again... please, please, please consider the 3 UI issues described above. Most clients today do support using the same credentials for sending as receiving, and this greatly simplifies things, especially for the less advanced users, and the other 2 items I really don't see as complicating the UI too much, but add a lot for the more advanced users.

> I want it to look like something that was detected and not just an input
> until the person decides to edit it.  Essentially people will go ahead and
> try to edit anything that looks like an input; even if they don't need to.
> So it's our responsibility to make sure people don't edit things they don't
> need to while at the same time making it possible for others to do that.

Agree - so maybe just show it greyed out, but add an 'Edit' button next to it that, when clicked, informs the user that editing this may have unintended consequences (or something to that effect), and that unless they know they need to change it, they should probably leave it alone.

> At this point you can change to manual mode, I think I left it as "skip to
> manual" but it should probable update to "Change to manual mode".
> 
> == Sport Manual Configuration ==
> 
> During this phase we don't do any smart detection or probing but only test out
> the settings as given.  This simplifies the user experience quite a bit as
> compared to now where we'll use your settings and try others as well.

Looks fine, again except for the 3 UI issues described above.

> I think you have the right idea here where we show all the available inputs
> and allow them to test the configurations while displaying a plus or minus
> if it's known to work.  I tried to embody that in mine, the two seem very
> similar to me other than I kept the IMAP/POP separation and SMTP is still
> in it's own section.

Agree, yours looks fine to me, except... and dang it, again, not knowing more about the auto-detect process (and this supposed online database of pre-configured settings for known/public servers) makes it very difficult to comment intelligently...

Anyway, except, I do think on the Manual dialog there should be some kind of 'Auto-Detect' button that will test for all possible variations, and present all available options (in the preferred order described above) to the user, with the most preferred defaulted to selected.

> I'm not sure how to convey correctly that a connection is secure or not, or
> perhaps even if it matters at this point.

If I can convince you to add the 3 UI issues described above, then I'd say having the 'Show only secure choices' option (checked by default) is all that would be needed.

> One small note is that I think it makes sense to use a combo box for the
> ports, an editable list so that people can choose the obvious defaults or
> enter their  own values.

Yes, I debated with myself about this... and I have to agree, since *normally* they will be one of the standard ports, and as long as an advanced user can easily change it to whatever they want, that's fine with me.

> Only from here can you then create an account into the Account options dialog
> which has even more knobs and buttons available to customize your account as
> needed.

Question - would the user be able to change the account type (IMAP to POP or vice versa) after they have clicked the 'Create Account' button? It would be really nice to be able to do that, but maybe there are some technical reasons why this is not a good idea (or even easily doable)...

> == Testing ==
> 
> There's a final password testing phase we go through and it would be good to
> have mockups of this. Before this point Thunderbird has only probed and has
> not actually tested that it can successfully connect to any account.  However
> at this point we want to try logging into the incoming and outgoing servers to
> ensure that we have the correct settings and they work.
> 
> Thoughts?

Personally, I think Auth testing should also be available/done on the New Account dialogs (prior to the user clicking 'Create Account'). That was the idea behind the checkmark in the green circle with the 'Test Successful! Your Account...' test result on my mock-up, but the 'Test Account' label probably wasn't informative enough.

On yours, maybe you could add a big 'Test All Account Settings' button to the right of the username field...

The small/individual 'Test' buttons nest to the service/port line just test whether that particular service is available as configured (port/security options), right.

Also, can the SSL certificates also be part of this testing process, so these can be verified - and the security exception confirmed (if self-signed and/or wildcard certs are being used) - prior to account creation? Of course, you wouldn't want to actually store the security exception *permanently* until the user clicks the 'create Account' button, so I guess it would have to be stored temporarily until that button is clicked...

Ok, I guess thats enough for one comment...

I'm modifying my mock-ups now, but still would like to read up on the auto/pre-configured account stuff before posting new versions... but it may not even be necessary, I think we're close to agreeing... :)

Thanks a lot Bryan, I'm really glad this is getting worked on for 3.1...

Comment 26

[Charles]

(In reply to comment #25)
> Whew! I'm sorry this got to be so long... but you for my thoughts... ;)

"... but you *asked* for my thoughts..."

Why can't we edit our comments on here? Leaving typos hanging out there for the world to see like that really bugs me - especially when there is no 'Preview' button to preview a post first (more likely to catch something like this)...

Comment 27

[Charles]

(In reply to comment #25)
> I recall reading somewhere many moons ago a reference to some online database
> of pre-configured account settings for well known/public servers (like gmail,
> hotmail, yahoo, etc), and when I entered this discussion I tried googling it
> but came up dry, so I asked for more info at the very bottom of comment 8, but
> no one responded (I guess it was easy to miss though)...
> 
> So... before I can make any more intelligent decisions about what specifically
> should go on the mock-ups (and where/how it is displayed), I really need to
> know more about the auto-detect/pre-configured account system/process.

Anyone? Am I talking to myself? How many times do I have to ask?

Comment 28

[Bryan Clark (DevTools PM) [:clarkbw]]

(In reply to comment #22)
> (In reply to comment #8)
> > (In reply to comment #7)
> > Is the auto-detect process detailed anywhere? I'd be interested in reading up
> > on it...
> 
> The wiki might have some dated information
> https://wiki.mozilla.org/Thunderbird:Autoconfiguration
> 
> also the original bug 422814

(In reply to comment #27)
> Anyone? Am I talking to myself? How many times do I have to ask?

Yes you are talking to yourself.

The above is the best we have as far as I know, you'll likely have to dig around on your own if you want more than that.  It would be a great help if you collected everything you found somewhere so that others can benefit.

Comment 29

[Charles]

(In reply to comment #28)
> (In reply to comment #22)
>> Is the auto-detect process detailed anywhere? I'd be interested in reading up
>> on it...

> The wiki might have some dated information
> https://wiki.mozilla.org/Thunderbird:Autoconfiguration
> 
> also the original bug 422814

****... how did I miss that... sorry for the noise/rant, it gets confusing reading some of these long comments sometimes...

Comment 30

[Bryan Clark (DevTools PM) [:clarkbw]]

Need to clear this off my plate for a little while as other things are in the way.

In general this bug and other similar bugs will need to be closed down.  Bugs are great for getting specific work items done but this kind of scratch pad of designs and discussion means that this bug will just sit in purgatory as it's hard to know what is happening.

I'd suggest we move this discussion somewhere else, like the newsgroup or a GetSatisfaction idea so we can keep collaborating.  Once we have a handle on exactly what we're going to do we can start filing bugs which make those requirements happen.

Comment 31

[Dan Mosedale (:dmosedale, :dmose)]

Indeed, because it's not a well-defined work-item, it's not a good candidate for the blocker list, so marking as blocking-.  Note that we can and will make some number of critical improvements to the account setup dialog before we ship 3.1, but they're not yet well-enough defined to be tracked with bugs.

I'd suggest that whoever starts moving this discussion forward next pick either GS, as suggested by Bryan, or, instead of a newsgroup, the new tb-planning mailing list.

Comment 32

[Charles]

Well, I'd prefer that you guys (the dev(s) who will be making the decisions) pick their preferred medium, and then just tell us who care to participate where the discussions will be taking place. I'm happy to go wherever you say...

But, there is one specific request that is depicted in my screenshots and has a specific bug opened that no one has commented on, and that should be relatively easy to implement, that I would appreciate a comment on...

What is the likelihood of bug 543827 (use same credentials (username/password) for outgoing (smtp) server as for incoming) being implemented.

It is silly - and a pain - to have to enter your username/password twice, especially when: a) they are the same 90+% of the time, b) you use your full email address for your username (lots of providers do this, and I'd argue that more are every day), and c) use strong passwords (mine is 15 random characters).

Comment 33

[Charles]

(In reply to comment #31)
> Indeed, because it's not a well-defined work-item, it's not a good candidate
> for the blocker list, so marking as blocking-.  Note that we can and will make
> some number of critical improvements to the account setup dialog before we
> ship 3.1, but they're not yet well-enough defined to be tracked with bugs.

Ok, but they will have to become well defined pretty soon, if they are actually going to make it into 3.1, right? So, where do I/we go to participate in that process?

> I'd suggest that whoever starts moving this discussion forward

Well, I would guess that would be the dev responsible for doing the actual work, no? So, is that Bryan?

This also begs the question - why are so many bugs like this marked as 'Nobody Assigned: OK to take it'??

> next pick either GS, as suggested by Bryan, or, instead of a newsgroup, the
> new tb-planning mailing list.

Like I said - I think this should be decided by the one doing the work, and anyone who is interested in participating in discussion will have to go there...

Comment 34

[Tony Billett]

Setting up thunderbird 3.0.3 for my business emails. All I needed to do was copy my existing pop3 settings from my existing thunderbird on my other computer. This was not straight foward as it should be.
The setup wizard insisted on creating an imapi account even though it did not work and gave me yellow traffic lights.
After some fustration I figured out how to create a pop3 account through the wizard. I still got yellow traffic lights this but it worked.
It was not intuative how to persuade the wizard to set up a pop3 account and does not seem possible to change an imapi account to a pop3 account in the settings.

There needs to either be -
1) a traditional manual setup option as requested in the bug or
2) account settings should add ability to change an account from imapi to pop3 type without having to delete and recreate account through wizard

As described company email settings are typically non standard, for instance my mail server required my full email address rather than my actual name for the account.

Comment 35

[Raanan Barzel]

On a brand new Win7 computer, things go so f

Comment 36

[Raanan Barzel]

(In reply to comment #35)
> On a brand new Win7 computer, things go so f
Oops, (things go so fast the comment fired on a typo) 

Restart: On a fast new Win7 computer, the account is set before the wizard can be stopped. At that point, trying to modify the setting is next to impossible. Had to restart half a dozen times to set a pop3 account right.

Start in a manual mode with an Auto button seems a better design choice than having to battle with a wizard.

I also agree with Comment 6 regarding the needless complexity of two windows.

Manual setting of Pop accounts could use a test button to verify that the setting works (see PopTray account setting as an example) before the account is actually created.

Comment 37

[mistoffeles]

The simplest solution would be to have the selection of whether to use the wizard before even starting the automatic test, at the very first dialog for Mail Account Setup where you are expected to enter your name, email address and password. Just a pre-checked box that can be unchecked to completely disable this irritating and often worthless autodetect "wizard". For crying out loud, this whole thing smacks of Microsoft, and that's the last thing I want in a Open Source package.

Having it set to autodetect by default will enable newbies to use this feature, often without even being aware of it until they see it chugging away, while those already riding the cluetrain will be able to flick the annoying **** away easier than the last booger they mined.

Comment 38

[Raanan Barzel]

(In reply to comment #37)
> The simplest solution would be to have the selection of whether to use the
> wizard before even starting the automatic test, at the very first dialog for
> Mail Account Setup where you are expected to enter your name, email address and
> password. Just a pre-checked box that can be unchecked to completely disable
> this irritating and often worthless autodetect "wizard". For crying out loud,
> this whole thing smacks of Microsoft, and that's the last thing I want in a
> Open Source package.
> 
> Having it set to autodetect by default will enable newbies to use this feature,
> often without even being aware of it until they see it chugging away, while
> those already riding the cluetrain will be able to flick the annoying **** away
> easier than the last booger they mined.

Why pre-check the box? rather have it unchecked and let those who want to use it check the box.

The autodetect by default is so wrong for POP accounts that it may turn newbies away from TB altogether.

Comment 39

[Dan Mosedale (:dmosedale, :dmose)]

While it's completely valid to be frustrated by the behavior of Thunderbird, please try and express your frustration in a civil manner that's actually mindful of the feelings of the people reading it.

This statement:

> Just a pre-checked box that can be unchecked to completely disable
> this irritating and often worthless autodetect "wizard". For crying out loud,
> this whole thing smacks of Microsoft, and that's the last thing I want in a
> Open Source package.

is likely to make the folks who have invested many hours of their own lives into the wizard feel pretty crummy.  That doesn't help make Mozilla a fun place to work, nor does it help them productively address any real issues underlying the frustrations you're experiencing.

Please review <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html> for some guidelines about what sorts of behavior are and are not appropriate for Bugzilla.  Thanks.

Comment 40

[PhilipCJames]

Autodetect is too clever by _half_. I.e., it is only half as clever as it needs to be.

If it was heuristic, learning likely correct settings from previous account setups (as corrected/modified by the user) it might be just clever enough (but it doesn't even pick up that my outgoing server has a different DNS domain to my incoming server - something that might be gleaned from the default setting I have selected for the first 20 of my accounts). 

I haven't set up the remaining 24 accounts because I am terminally frustrated with this issue and am, reluctantly, looking around for an alternative e-mail client.

If it is not satisfying the users, please change it to offer the first choice:


[Do you want to set-up manually?] or [do you want to attempt auto-detect?]


I sympathise with both volunteer developers who give up their time but also with the users; though there is NO excuse for abusive or insulting posts, I detect and share a frustration with an apparent lack of understanding or even 'nanny knows best' arrogance expressed SOMETIMES by SOME of the developers who contribute to these and getsatisfaction threads. 

Some responses leave me with the impression it is the users' fault if they do not work in the manner imposed by the software rather than have the software support the user to do what they want to do. As a marketer I recognise this as a major bear-trap.

Please, please, please listen to your users. 

I will not use buzz-phrases such as 'be more professional', or 'be more market-facing', or even 'be more like developers who are paid for their software' because I often detect a failure on the part of commercial software developers  to listen to their users also, which is even more galling.

Please offer the user a first choice between manual and autodetect setup.

Comment 41

[Neville Hillyer]

Is it too late to request a simple means of opting out of initial setup altogether without resorting to setting up a dummy profile to remove later?

I often setup with dummy information. Remove the whole profile and copy across the very few files (including my customised prefs.js) required to initiate a new account or a clone.

With TB 3.1 you can simply cancel the initial setup boxes but this is not as explicit as I would like and the boxes sometimes insist upon opening again.

Perhaps a customisable option to import settings and/or mail from another profile would be useful. Similar to OS X installers.

Comment 42

[Neville Hillyer]

Please see:

https://bugzilla.mozilla.org/show_bug.cgi?id=578503

Comment 43

[Charles]

(In reply to comment #40)
> Please offer the user a first choice between manual and autodetect setup.

Philip, you might be interested in my bug 580216 I just opened to address the problem of Manual Account Creation...

Comment 44

[peter winterflood]

So now we have 3.1 with all the things that 3.0 should have had "EXCEPT THIS"

as per many of the comments , there was nothing wrong with the manual setup method of 2.x and that needs to be a choice before this half wit of a wizard decides that you are going to be using pop3 or some other random choice of protocol.

Comment 45

[Dan Mosedale (:dmosedale, :dmose)]

Peter, it is entirely reasonable to be feel frustrated about changes in Thunderbird.  However, when Bugzilla is used as a place to vent or advocate, it's very demotivating to both volunteer and paid developers and tends to result in bugs taking longer to get fixed, even when they're important.  

If you're looking for a place to discuss your personal opinions and feelings about Thunderbird, please consider <http://getsatisfaction.com/mozilla_messaging/topics/>.  For future Bugzilla use, please review <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html> before posting again.  Thanks!

Comment 46

[Neville Hillyer]

I am afraid I was unaware of https://bugzilla.mozilla.org/page.cgi?id=etiquette.html which is interesting reading. Strictly this comment is a contravention, for which I apologise, but I hope my ignorance of this worthy document did not cause me to break too many rules hitherto. I note that it includes the following rule:

"If you see someone not following these rules, the first step is, as an exception to guideline 1.4, to make them aware of this document by private mail. Flaming people publically in bugs violates guidelines 1.1 and 1.3. In the case of persistent offending you should report the matter to Gerv."

Comment 47

[Wayne Mery (:wsmwk)]

Neville, thanks for that reminder. I can't remember the last time I thought about it. 

It's worth nothing that practice of that exception varies widely depending on the circumstances. In particular and perhaps relevant to comment 45, when there is the potential for educating a large group or assisting in controversial bugs we often find a comment 45 done in public.

Comment 48

[Wayne Mery (:wsmwk)]

...it is worth *noting*...

(and it would help if I had my glasses on)

Comment 50

[peter winterflood]

My comment was no more critical then any of the hundred or so posts before;  pointing out the same so why pick mine out as demotivating. In fact nevil and philips post are in the same context(In reply to comment #47)
> Neville, thanks for that reminder. I can't remember the last time I thought
> about it. 
> 
> It's worth nothing that practice of that exception varies widely depending on
> the circumstances. In particular and perhaps relevant to comment 45, when there
> is the potential for educating a large group or assisting in controversial bugs
> we often find a comment 45 done in public.

Comment 51

[Raanan Barzel]

A reaction to comment #45: user comments should be taken for their contents: if the content is relevant, then it should be considered as such. If it is irrelevant, then it should be ignored. The discussion here simply shows that there is a real problem and not just a bug, and that looking at the issue as simply a bug is not enough. "... bugs taking longer to get fixed, even when they're important" is inappropriate.

Comment 52

[Neville Hillyer]

Further to my earlier comment (41) I request that consideration be given to an initial window with these options:

1 - Automatic setup
2 - Manual setup
3 - No setup at this time

The following link gives an indication of how badly users are affected and the silly workarounds that need to be used;

http://forums.mozillazine.org/viewtopic.php?f=39&t=1948949&p=9655133

Comment 53

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #50)
> My comment was no more critical then any of the hundred or so posts before; 
> pointing out the same so why pick mine out as demotivating. In fact nevil and
> philips post are in the same context(In reply to comment #47)

Note that we (core Thunderbird contributors) are responding to comments of this sort more these days than we used to because we want to make Thunderbird a more hospitable place for contributors beyond just those people who have a very thick skin.
  
I was not intending to single you out; I'm sorry if you felt that way.  I chose that comment to respond to not because it was critical, but because of its tone.  Shouting ("EXCEPT THIS") and referring to something that people on this bug have put many many hours of work into as a "half-wit wizard" are the things that caused me to speak up.

(In reply to comment #51)

> A reaction to comment #45: user comments should be taken for their contents: if
> the content is relevant, then it should be considered as such. If it is
> irrelevant, then it should be ignored. The discussion here simply shows that
> there is a real problem and not just a bug, and that looking at the issue as
> simply a bug is not enough. "... bugs taking longer to get fixed, even when
> they're important" is inappropriate.

Raanen, you're more than welcome to respond to bugs in the way you describe.  However, the way we're trying to use Bugzilla is more closely described by the etiquette document I linked to than by your proposal (for the reasons I described above).

As we've now wandered fairly far off-topic for this bug, this will be my last comment here.  You're welcome to post to tb-planning if you wish to discuss the bug handling in more detail.

Comment 54

[Neville Hillyer]

Am I mistaken or is there a Mozilla bias towards IMAP? I do not say this lightly but have this increasing suspicion after reading several recent posts here and on MozillaZine. If this is so I think it is deplorable and request that all developers do their best to maintain neutrality.

Comment 55

[Charles]

(In reply to comment #54)
> Am I mistaken or is there a Mozilla bias towards IMAP?

No, you are not mistaken...

> I do not say this lightly but have this increasing suspicion

No reason to be suspicious - this is no secret, and I haven't seen any indication that anyone is trying to hide this fact from anyone.

> If this is so I think it is deplorable and request that all developers
> do their best to maintain neutrality.

Why do you think it is 'deplorable'?

I agree that it should not be forced on anyone - and it isn't - and have commented that 'defaulting' to IMAP in the New Account Setup wizard is a bad idea that will only lead to confusion in many cases, but I wouldn't call it 'deplorable'.

The fact is, IMAP, when properly implemented, rocks - and Thunderbird is one of the better IMAP clients out there, and is getting better with every release.

However, I agree that 'tricking' someone into using IMAP - by defaulting to it in the wizard without explanation or warning - when they wouldn't have chosen it had they known the difference between POP and IMAP is a bad idea.

What I'd like to see is once the wizard has determined that both IMAP and POP are available, something along the lines of a blocking pop-up window or some other blocking dialog comes up, explaining the difference between the two in plain english, and asking the user what they would prefer, *without* a default already selected.

However, I don't think this is going to happen, at least anytime soon. It may take some loud/numerous complaints to change this behavior, and who knows - maybe there won't be.

Comment 56

[Mark Banner (:standard8)]

(In reply to comment #55)
> (In reply to comment #54)
> > Am I mistaken or is there a Mozilla bias towards IMAP?
> 
> No, you are not mistaken...

Please folks, this is totally off-topic for this bug. Please take it to one of the news groups or mailing lists. You have already been warned once to keep to the etiquette, please let this bug stay on track from now on.

Comment 57

[Neville Hillyer]

Seeing this pop up in my mailbox caused me to read it again and made me wonder if the etiquette concerns had caused my comment 52 to be overlooked.

Whilst it could be argued that requesting changes to settings or Wizards contravenes etiquette rules in this case I hope all would agree that comment 52 is pertinent to the original bug report.

Comment 58

[Ben Bucksch (:BenB)]

Neville, we have considered that (in fact, that was my original design), and rejected. Pressing "manual config" button after the automatic detection started automatically (pun intended) is no worse than having to press "manual config". 

The current dialog is broken (so that it currently doesn't work like that), we all agree on that, but I fixed that, pending review.

Comment 59

[Neville Hillyer]

You have lost me.

My main point was a request for 'No setup at this time'.

This would make it easier for experienced users to do several things including replacing prefs.js, as an alternative to using wizards or settings panels, without resorting to various devices.

Comment 60

[Ben Bucksch (:BenB)]

"Cancel"?

Comment 62

[Bill Derham]

I like the Tbird 2 new account setup. It is simple and easy to use. If you want to add a new automatic wizard, why take away the simple alternative offered in tbird 2 ??

I am not a tech head but if one of you clever people out there could ADD the old Tbird 2 new account set up process as an alternative, I would upgrade again from Tbird 2 to Tbird 3.

The Microsoft Windows Live email client hooked me up to my POP account automatically in a few seconds but I don't want to use MS. I am sure someone can fix this.

Comment 64

[Neville Hillyer]

What are the rules for making as duplicate? I would have expected the earlier report to take over but I see this does not happen.

Comment 65

[Ludovic Hirlimann [:Usul]]

(In reply to comment #64)
> What are the rules for making as duplicate? I would have expected the earlier
> report to take over but I see this does not happen.

Dup to where the work is happening is the first rule. When no work is being done, oldest/ best description/most duped already is the rule. And that rule is flexible :-)

Comment 66

[Neville Hillyer]

Thank- that is useful to know.

Is there a way to ensure one is automatically put on the mailing list of bugs that 'take over'?

Comment 67

[Wayne Mery (:wsmwk)]

(In reply to comment #66)
> Is there a way to ensure one is automatically put on the mailing list of bugs
> that 'take over'?

no there is not. automatic only happens if you are the reporter of the bug being closed duplicate.

Comment 68

[Ben Bucksch (:BenB)]

NOT a DUP. We considered this, several times, and decided not to do it.

For reasons, please read <http://getsatisfaction.com/mozilla_messaging/topics/new_account_setup_wizard_is_too_aggressive?utm_content=topic_link&utm_medium=email&utm_source=reply_notification>.

Comment 69

[Ben Bucksch (:BenB)]

(and of course the discussion above, e.g. comment 58)

Comment 70

[Wayne Mery (:wsmwk)]

(In reply to comment #67)
> (In reply to comment #66)
> > Is there a way to ensure one is automatically put on the mailing list of bugs
> > that 'take over'?
> 
> no there is not. automatic only happens if you are the reporter of the bug
> being closed duplicate.

the cc issue is covered in Bug 108983 - CCed users on duplicate bug should be CCed on original

Comment 71

[Neville Hillyer]

I am sure many will be disappointed that this has been marked WONTFIX but perhaps we will have to wait and see how the revised setup wizard works.

I don't like wizards and would prefer to simply edit Account Settings after initial startup. Getting to this point without any account settings is not intuitive. Perhaps those who want to do this regularly will have to hack their own TB - pity.

Comment 72

[Ben Bucksch (:BenB)]

> would prefer to simply edit Account Settings after initial startup.

I believe the current wizard already made this easier than 2.0, modulo being riddled by bad bugs. I think the improved implementation will make it even easier, and clear easier than 2.0.

> perhaps we will have to wait and see how the revised setup wizard works.

Thank you!

Comment 73

[Raanan Barzel]

(In reply to comment #72)
> > would prefer to simply edit Account Settings after initial startup.
> 
> I believe the current wizard already made this easier than 2.0, modulo being
> riddled by bad bugs. I think the improved implementation will make it even
> easier, and clear easier than 2.0.
> 
> > perhaps we will have to wait and see how the revised setup wizard works.
> 
> Thank you!

The real question which no one raised/answered is why TB 3 was released with such a buggy wizard. A buggy product is much worse (and/or expensive) than a product with less features (Remember Toyota). This is a project management issue and not a developer issue.

As for the auto/manual, my car (a modest European) has an automatic gearbox with manual override, and it is for the driver to decide which to use. The car industry seems to be on the right track (for this). I really do not see why there is such an insistence on starting the wizard automatically and forcing the user to stop it for manual setting. Take the passion out and be pragmatic - let the user choose.

Comment 74

[Ben Bucksch (:BenB)]

> my car (a modest European) has an automatic gearbox with manual override

Yes. And the automatic is the default. You have to put into "D" (automatic) before you can use 4/3/2 (manual), at least in the cars I saw. The manual is the exception. We do the same.

I see no downside in having to click "Continue" and then "Manual config" directly afterwards vs. clicking "Manual config" before "Continue". The result will be the same. It currently isn't, and that's a plain bug that I fix.

Comment 75

[Raanan Barzel]

(In reply to comment #74)
> > my car (a modest European) has an automatic gearbox with manual override
> 
> Yes. And the automatic is the default. You have to put into "D" (automatic)
> before you can use 4/3/2 (manual), at least in the cars I saw. The manual is
> the exception. We do the same.

That is not so - It is a Fully auto/Fully manual, and I can start where I want. It is true that the selector goes through R, N & D, but the car does not start in R when the selector goes through this position to D or to manual. I decide when to start and in which position.
> 
> I see no downside in having to click "Continue" and then "Manual config"
> directly afterwards vs. clicking "Manual config" before "Continue". The result
> will be the same. It currently isn't, and that's a plain bug that I fix.
If you do away with the "Continue" button and give the user "Auto" and "Manual" buttons you potentially save one click and you do not add any. 
In any case, please remove all automatically selected parameters when the Manual button is clicked.

Comment 76

[Charles]

(In reply to comment #73)
> The real question which no one raised/answered is why TB 3 was released with
> such a buggy wizard.

Please stop beating the dead horse. It is dead. It died a long time ago (the day 3.0 was released, then again the day 3.1 was released).

This is being fixed. Maybe not exactly the way you (or any other individual user) wants, but it will be fixed. Remember, you can't please everyone, thats just reality.

Comment 77

[Neville Hillyer]

On a positive note:

With TB 3.1.2 it is practical for those who want to setup manually to select 'cancel' (twice for a Mac) at the first window and then input their settings at Account Settings.

The only downside I can think of is:

1 - If I recall correctly this was not so easy with earlier versions

2 - It is not intuitive for those new to TB.

Comment 79

[Bill Turner]

"Status:  RESOLVED WONTFIX "

WHY!  It is still broke.  After spending several HOURS trying to configure ONE email address as POP3, I finally typed in some garbage for the username and domain.

MAGIC! The wizard got out of my way, and in 30 seconds I had the account configured the way it needed to be.

I have BALLET Teachers who could configure their email addresses under Thunderbird 2.  Under Thunderbird 3?   Forget it.

Please supply a "manual" button on the first page to bypass "auto" so I don't have to waste time and resources.
  
Thank You.

Comment 80

[Blake Winton (:bwinton) (:☕️)]

There is a "Manual Config" button which appears immediately after you enter the information on the initial window and hit "Continue".

I'm not sure how much time it takes you to enter the information on the initial screen, but that information gets used to fill out the fields in the manual config, so it's not really wasted time.  I suppose the http connection to look for the automatic config could be wasted, but that doesn't seem like a huge amount of resources.

I would be interested in hearing the problems the ballet teachers were running into configuring their email accounts, so that we can try to make the process even easier for them.  (You should probably email those to me directly, at [e-mail], since this bug is already resolved.  And while you're at it, perhaps you could tell me which domain you were having problems with, so that I can look into making it easier, too.)

Thanks,
Blake.

Comment 81

[Raanan Barzel]

The "Manual config" button is effectively present on TB 6.0. It might be useful to specify here when it was introduced so that people with versions of TB which do not have it stop claiming for it...

Having reintroduced this button after a long period of somtimes heated axchanges was a wise decision. But why is the status set as RESOLVED WONTFIX when it should be RESOLVED?

Comment 82

[Neville Hillyer]

(In reply to Raanan Barzel from comment #81)

See comment #63 and comment #64