Closed Bug 532590 Opened 10 years ago Closed 10 years ago

Quick Account Setup (add radiobox {POP, IMAP} )

Categories

(Thunderbird :: Account Manager, defect, trivial)

defect
Not set
trivial

Tracking

(blocking-thunderbird3.1 beta2+, thunderbird3.1 beta2-fixed)

RESOLVED FIXED
Tracking Status
blocking-thunderbird3.1 --- beta2+
thunderbird3.1 --- beta2-fixed

People

(Reporter: sbastig, Assigned: BenB)

References

()

Details

(Whiteboard: [UXprio] [gs])

Attachments

(8 files, 5 obsolete files)

2.62 KB, patch
bwinton
: review+
Details | Diff | Splinter Review
47.75 KB, image/png
Details
21.03 KB, image/png
Details
52.64 KB, image/png
Details
25.06 KB, image/png
Details
7.09 KB, patch
Bienvenu
: review+
clarkbw
: ui-review+
Details | Diff | Splinter Review
10.84 KB, patch
mkmelin
: review+
Details | Diff | Splinter Review
10.88 KB, patch
Details | Diff | Splinter Review
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091109 Ubuntu/9.10 (karmic) Firefox/3.5.5
Build Identifier: Thunderbird 3.0 RC 2

I suggest to add a radio box in the quick account setup (the one that initially opens when you have just installed Thunderbird, or also in the general add account dialogue, if they are not the same?).
This radio box should offer two choices:
0 POP (default; recommended) and O IMAP
with an optional notice telling the user that IMAP might not be available for all providers.
# One more minor issue I found when editing the automatically gathered settings. It chooses POP by default (e.g. pop.gmx.net) but when you choose IMAP then the input field still shows pop.gmx.net and you have to click the retest button first to get it updated. This might confuse users, maybe choosing IMAP from the dropdown should directly change POP to IMAP. I know this is only a cosmetic issue since when the re-test button is pressed the settings get adjusted anyway. But it guess it could confuse users, maybe.

Reproducible: Always




Of course it is possible to choose IMAP when you click on edit after the auto configure finished but with a radio button it would look a bit more neat. Anyway the Mail Account Setup looks a bit empty with only its three input fields and one check box.
Component: Installer → Account Manager
QA Contact: installer → account-manager
This is pointed to from the 3.1 UX priorities list at <https://developer.mozilla.org/en/Thunderbird/Thunderbird_MozMill_Testing>, but it's not clear to me whether we would hold for this if it were the last bug standing.  I don't feel like I have a good understanding of when people are likely to want something other than the default, and what the bad consequences of getting it wrong are.

sbastig: can you elaborate on why you think POP should be the default & recommended?

clarkbw: would you make the call on whether this should block 3.1 and (possibly separately and later) comment on the proposed on UX?
Status: UNCONFIRMED → NEW
blocking-thunderbird3.1: --- → ?
Ever confirmed: true
I get the very strong impression from GS that our auto detection is picking IMAP when it does not work, i.e., we can connect on the imap port, so we pick imap. verify logon then fails, but we don't fall back to pop3 from there.

At the very least, we need to make it obvious how to stop the probing, and switch from IMAP to POP3. I would block on this, since it is an extremely common complaint on GS. Roland can correct me if I'm wrong...
(In reply to comment #2)
> I get the very strong impression from GS that our auto detection is picking
> IMAP when it does not work, i.e., we can connect on the imap port, so we pick
> imap. verify logon then fails, but we don't fall back to pop3 from there.
> 
> At the very least, we need to make it obvious how to stop the probing, and
> switch from IMAP to POP3. I would block on this, since it is an extremely
> common complaint on GS. Roland can correct me if I'm wrong...

3.0 picks IMAP if there is no auto-config file. GMX appears to have a config file that's defaulting to POP

Based on Get Satisfaction user feedback, 3.1 should block on the "auto-config defaulting to IMAP and extremely difficult to change to POP" bug (which I have to find)  which I believe Blake is working on! I have verified that the GS users are right; it is very difficult to change IMAP to POP in the auto-config new account wizard
Roland, it sounds to me like you're saying that there's a separate bug that needs to be blocking, and that this bug might actually be a DUP of it.  Is that correct?  Doing a few quick searches hasn't turned anything up that I can see.
Do you mean bug 533680?
Hmmm, to me bug 533680 seems related but different.
Whiteboard: [UXprio]
Whiteboard: [UXprio] → [UXprio][needs input clarkbw]
Something like this is blocking, though I'm not clear what piece.

Roland, can you link to the most prominent GS issues so we can look them over?

I feel like there are two separate issues here that might need separate bugs.

1) Is comment 2 where we provide a choice that doesn't work and then don't give a decent fallback

2) Is what I've heard before where it's not obvious that there is an easy choice between POP or IMAP in the configuration dialog.

This bug feels more like trying to solve (2) than anything else.

I had thought that we might offer POP and IMAP as separate lines in the config dialog where we offer them in the same space now which doesn't appear to offer a choice.

Something like this:

Incoming:
(o) IMAP: imap.example.com 143 STARTTLS
( ) POP : pop.example.com  110 STARTTLS

Instead of just offering a single incoming line.  We still default to IMAP which is often the best choice for people who aren't aware of the difference but we can make the fact that there is a choice more clear to people who are expecting to choose something other than IMAP.
blocking-thunderbird3.1: ? → needed
Whiteboard: [UXprio][needs input clarkbw] → [UXprio]
(In reply to comment #7)
> Incoming:
> (o) IMAP: imap.example.com 143 STARTTLS
> ( ) POP : pop.example.com  110 STARTTLS

My other thought was wrt option would be to also provide tooltip or extra text as to what IMAP and POP actually are and how they affect the user.
First - the hostname doesn't really matter when it comes to which account type is used. I can use pop.example.com for an imap account, and vice versa. Lots of places use mail.example.com for imap, pop *and* smtp services (so they only need one SSL cert).

I see nothing wrong with testing for the existence of these different hostnames - ie, if the user selects POP for the account type, sure, *test* for the existence of pop.example.com, but please don't just automatically switch to it.

The biggest problem is with the auto-detect code and 'non-standard' servers - ie, corporate servers and/or home-grown servers. Get the auto-detect code working flawlessly for as many of the public services out there (gmail, hotmail, etc), provide a web page where end-users can submit a config for their own servers (make sure the one doing the submitting is responsible for their domain/DNS), and then just add a 'Manual Mode' button on the new account wizard for the corner cases - or those of us who prefer to just do it manually.
(In reply to comment #7)
> Something like this is blocking, though I'm not clear what piece.
> 
> Roland, can you link to the most prominent GS issues so we can look them over?
> 

I don't have a canonical list of topics but we get 1 or 2 a day like this:
http://gsfn.us/t/r48u
http://gsfn.us/t/ofaf

There are 3 problems: 1. can't easily change from IMAP to POP 2. Stop button doesn't work 3. Users don't understand why IMAP is the default. Perhaps POP should be the default for unknown server or perhaps we shouldn't even try auto-config for mail providers that ispdb doesn't know about
So Roland, just to clarify, if #2 was fixed, and the stop button worked, would #1 also be fixed?  (Because then you could hit stop, change IMAP to POP, hit re-test config, and it should all work.)

(And I don't think we want to change the behaviour for #3, but perhaps there is some documentation we could point people to, or write ourselves, which would convince them why IMAP is the default.  What do you think?)

Thanks,
Blake.
If anyone is interested, I just posted three 'mockups' of my suggestions for modifying the 'Mail Account Settings' setup windows.

The first one should satisfy the requirements of this bug request nicely:

https://bugzilla.mozilla.org/show_bug.cgi?id=531099#c9
in replay to Dan Mosedale on Feb. 10th:

I think that POP should be the recommended default because I feel this is the choice people usually expect. At least I know most people that are not IT-related seldom know what IMAP is anyway, yet most people have at least heared POP somewhere before. So even though I like IMAP more (and use it as my default with SSL (993) I still think it might be better to keep POP and additionally display a note to the user and explain what POP and IMAP is about, but remind the user that IMAP is not available for certian providers.

For example GMX (German Mail Exchange) only offers IMAP for their "pro mail" accounts, but most providers do have POP (except Hotmail).

Regards
Sebastian
(In reply to comment #13)
> in replay to Dan Mosedale on Feb. 10th:
> 
> I think that POP should be the recommended default because I feel this is the
> choice people usually expect.

I'm not sure I agree - I'm seriously wondering if *either* should be 'recommended'. I think the user should be required to choose, and I think we should make it easy for them to learn the difference between the two.

See my mockups referenced in my last comment for a GUI example...

> At least I know most people that are not IT-related seldom know what IMAP is
> anyway, yet most people have at least heared POP somewhere before.

True, but they still don't know what it is.

I see this as an opportunity to educate people, and as long as the explanatory  text is written to be easily understandable (I'm pretty good at writing stuff like that), most people should respond to it.

But I guess in the end, we still need a 'I'm stupid, please choose for me' default...
(In reply to comment #14)
> (In reply to comment #13)
> > in replay to Dan Mosedale on Feb. 10th:
> > 

> I'm not sure I agree - I'm seriously wondering if *either* should be
> 'recommended'. I think the user should be required to choose, and I think we
> should make it easy for them to learn the difference between the two.

Right, maybe recommending something is not even necessary if we have the "I dont know, help me choose" Button, which I think is a good idea because it gives users confidence and the feeling that they are not doing anything wrong if they choose either pop or imap. Then we could me this button the default and people can still choose pop or imap if they know what either of it is.

I think the mockups are very very good, and definitely much better than the current 3.0 account setup. But I would recommend to put a short help text that is _always_ visible beside the imap/pop selection. It could say something like this:

"POP downloads your mail from the server and only stores the mail on your local computer, you may choose to keep a copy of your incomming mail on the server.
IMAP synchronizes all mail including incomming mail, outgoing mail and folders with the server. A complete copy of all your mail is kept both on the server and your computer and you can also use other computers to check your mail. However IMAP may not be supported by all mail providers."

Cheers Sebastian
Assignee: nobody → bwinton
blocking-thunderbird3.1: needed → beta2+
Here's a version of a new auto-config mockup that I've been working on for a better auto-config experience.
https://wiki.mozilla.org/File:Thunderbird-Autoconfiguration-Auto-Configured.png

This shows a POP and IMAP choice, both of which have been found by autoconfig after it's probing / downloading.  There are several more related mockups in bug 531099 comment 24 and further.

Talking to blake earlier it seems like it would be easier code wise if the POP/IMAP choice were asked before the probing stage however it might make for some awkward experiences if a user asks for IMAP but only POP is available.  Something to look into and work on however.
(In reply to comment #11)
> So Roland, just to clarify, if #2 was fixed, and the stop button worked, would
> #1 also be fixed?  (Because then you could hit stop, change IMAP to POP, hit
> re-test config, and it should all work.)
> 
Sorry for the late reply!
Yes this would work, my only concern would be that I think "re-test config" doesn't always seem to work reliably in 3.0.x
> (And I don't think we want to change the behaviour for #3, but perhaps there is
> some documentation we could point people to, or write ourselves, which would
> convince them why IMAP is the default.  What do you think?)
> 
no problem with writing SuMoMo documentation for this
> Thanks,
> Blake.
Please drop this from 3.1. We are not set up to do this from the ISPDB standpoint, because that delivers only POP or IMAP, not both, and we don't even have the POP info for most ISPs.

Also, I would recommend to let the user select between "download mail" and "keep mail on the email provider's server", not "POP" and "IMAP". For 2 reasons: First, it is more understandable for users who don't know what POP or IMAP is and implies, which I think is the majority. Second, this is the actual thing that users are concerned about, not POP or IMAP specifically. It is very possible and would make a lot of sense to download (and delete) messages via IMAP, if that's it what the user wants - I did this for a long time myself. We'd need to make quite some changes to Thunderbird, and and ensure the user knows what he does (delete stuff from server), but it would make sense, because we'd need only one set of ISP settings, and IMAP can be more efficient (e.g. IDLE instead of full poll).
(In reply to comment #18)
> Please drop this from 3.1. We are not set up to do this from the ISPDB
> standpoint, because that delivers only POP or IMAP, not both, and we don't
> even have the POP info for most ISPs.

Why not have a web page where regular users can submit their ISP info for approval, to build the DB? Also - is this DB documented anywhere?

> Also, I would recommend to let the user select between "download mail" and
> "keep mail on the email provider's server", not "POP" and "IMAP". For 2
> reasons: First, it is more understandable for users who don't know what POP or
> IMAP is and implies, which I think is the majority. Second, this is the actual
> thing that users are concerned about, not POP or IMAP specifically.

True, but I dislike the idea of 'hiding' things from users. Example:

The very first thing I do when setting up a new Windows workstation is disable the stupid 'Hide extensions for known file types' option.

I actually like the description you suggested though, but some (many?) people will still probably confuse the second choice with a POP account that is configured to 'leave messages on the server', so how about this:

"let the user select between "download mail" (aka POP) and "access your email messages and folders directly from the email provider's server" (aka IMAP)"

This way, they might actually get a little more understanding of the difference between the two.

> It is very possible and would make a lot of sense to download (and delete)
> messages via IMAP, if that's it what the user wants - I did this for a long
> time myself. We'd need to make quite some changes to Thunderbird, and and
> ensure the user knows what he does (delete stuff from server), but it would
> make sense, because we'd need only one set of ISP settings, and IMAP can be
> more efficient (e.g. IDLE instead of full poll).

I'm not sure what you mean here. The only way I can  think of to do this would be to *copy* messages to Local Folders. If that's not what you mean, maybe you could elaborate?

But I am totally against protecting users from their own ignorance. That's the Microsoft way, and I hope that's not what you are suggesting.
tanstaafl, the point is that I want the freedom to use IMAP only technically, even if the user wants to have his mail locally. There's no reason for the user to insist on POP specifically (both go to the same mailbox), but there's a reason for us: IMAP is superior with polling etc., and more importantly we need to have all ISP configs twice.
It is a few bytes of information. Just collect the data and use the appropriate pieces. It makes no sense to me to *force* users to us an IMAP connection then perform some kind of 'trickery' to make it act like - and make the user think they are using - POP.

POP is POP. IMAP is IMAP.

Whatever, I just hope your idea isn't implemented, it sounds really bad to me.
Why not allow a manual configuration option?
Surely it's not that hard to code, it was always there in the past?
The automatic logging on is provided mainly for ignorance, and those who are ignorant will not want to manually configure. A year or two ago we had to ask our providers for the data and then configure all clients manually, which was scary for some, but 'do-able'. A data base could be built up as suggested. It is definitely not good to try and herd people into what the experts think is best for them. Persuade, but don't compel. That is why I switched to both Mozilla and Open Office products and projects, and their infuence on the market has been fantastic! Please do not go down the route of trying to force people into what you want them to do.
Dear Ben,

I am not sure if I understand your reasons about dropping this and what you
mean with:

> We are not set up to do this from the ISPDB
> standpoint, because that delivers only POP or IMAP, not both, and we don't even
> have the POP info for most ISPs.

Have you had a look at the mockups that have been posted on this bug report.
Maybe you have misunderstood it, but I don't think we are forcing the users
into anything and we clearly don't want to hide something from them. At least
in the most recent mockups that I have seen so far the choice explicitly reads
IMAP and POP.

Basically the original idea, why I started this post was to make the auto
configuration dialoge more userfriendly and usable. But of course the
possibility to do the configuration manually would not be removed, it just
makes configuration easier for those who dont know the settings by guessing
them.

>I don't have a canonical list of topics but we get 1 or 2 a day like this:
>http://gsfn.us/t/r48u
>http://gsfn.us/t/ofaf
However when looking at these links I agree that we definitely need to make the
choice clear for the user. So when the user chooses POP it will be pop and when
the user chooses IMAP it will be imap and if he clicks on the "I dont know help
me choose button" it will be either of them not both.

@Bryan, you made the mockups, could you comment on whether there has been any
progress and whether any help is needed with this?
Also I think as discussed above it would be useful to add a third radio box to
the POP/IMAP choice that reads:
[ ] "Help me choose" and brings the user to a help page with explanations or
evokes some other action that still needs to be defined.

Cheers
Sebastian
> Why not allow a manual configuration option?

We already do.
<http://support.mozillamessaging.com/en-US/kb/Configure+an+Account>

> Have you had a look at the mockups that have been posted on this bug report.

Yes. it says "We have found a configuration for your mail ...
(o) IMAP
( ) POP"

The problem is that we don't *have* a configuration for POP, for most ISPs, in the ISPDB. We only know IMAP configs. (And not knowing a POP config, we'd be left to guessing.)

Please see https://wiki.mozilla.org/Thunderbird:Autoconfiguration for details how this works in general.

Again, I see a reason for users to want to either have mail locally or on the server. That's what they care about, and that's what we should ask. Protocol is irrelevant.
>The problem is that we don't *have* a configuration for POP, for most ISPs, in
>the ISPDB. We only know IMAP configs. (And not knowing a POP config, we'd be
>left to guessing.)

So why is this a problem? Just take an approach like this:
1. User enters Name, Address, Password
2. We scan for available options (via db and/or by guessing / scanning of ports, etc.)
3. We display a choice of IMAP or POP, with friendly descriptions for either plus some sort of "Dont know, help me choose option".
Now the next step would depend on what the user choses and what our scan results are:
If we have valid options for both we can offer the user all three choises of step 3. if either pop or imap is missing we could preselect the other one but give the user a hint that he can still configure it manually if he really needs the other one.
4. Finally we test settings again

Depending on the actual implementation and what kind of information we have we might need to change the order of the steps or scan several times.

We could for example offer a choice from the database first, and then scan/guess if the user tries to chose something thats not in the database. If all this is not successful we can still ask the user to configure manually.

And of course we can still make the description to look somewhat like this:
( ) Keep mail on the server (IMAP)
( ) Always download mail (POP)
( ) Help me choose (Starts help assistant)

This way the user sees what he/she cares about, and the technical user still see whats going to happen.

Cheers
Sebastian
> So why is this a problem?

If we don't *know* the POP3 server (hostname, SSL/STARTTLS, encrypted passwords supported etc.), we can't configure it. Simple as that. For most ISPs, we (the DB) simply don't *know* it yet.

> then scan/guess if the user tries to chose something that's not in the database

Sure, but I want by all means avoid to guess configurations.

I'm not opposed to this bug, in the sense of "download mail locally" vs. "server-based mail", so I don't know why you're arguing.
I had assume the plan would be that if we don't have an option for POP or IMAP that we would either remove that option entirely from the screen [1] or perhaps leave the option there with a button/link to "Manually configure this" which brings the person to [2]

However I haven't detailed that in the mockups yet. I'll try to get something up so it's clearer what I'm talking about.

I don't want to try renaming the POP or IMAP options into "friendlier" names.  There is plenty of documentation searchable for POP or IMAP choice and most configurations would reference it.  I do like the idea (mentioned in another bug) to add a help text along the lines of "We've found multiple configurations, here's how to choose..." which would open a KB article on choosing POP or IMAP.

re: comment 18 it seems like we should be able to ask ISDB for both by doing 2 calls.  Perhaps in the future we could optimize that into a single call.

[1] https://wiki.mozilla.org/File:Thunderbird-Autoconfiguration-Auto-Configured.png
[2] https://wiki.mozilla.org/File:Thunderbird-Autoconfiguration-Sport_Configuring.png
(In reply to comment #24)
>> Why not allow a manual configuration option?

> We already do.
> <http://support.mozillamessaging.com/en-US/kb/Configure+an+Account>

And it is obviously very confusing and needs to be changed.

Have you even looked at the mockups?

> > Have you had a look at the mockups that have been posted on this bug report.
> 
> Yes. it says "We have found a configuration for your mail ...
> (o) IMAP
> ( ) POP"
> 
> The problem is that we don't *have* a configuration for POP, for most ISPs, in
> the ISPDB. We only know IMAP configs. (And not knowing a POP config, we'd be
> left to guessing.)

and

> If we don't *know* the POP3 server (hostname, SSL/STARTTLS, encrypted
> passwords supported etc.), we can't configure it. Simple as that. For most
> ISPs, we (the DB) simply don't *know* it yet.

So, how about not hiding the ISPDB? When a config is unknown, *tell* the users about the ISPDB. It's still very new, so provide some kind of help text that informs users of what is happening, and that you could use their help in populating the ISPDB to make auto-config work better for everyone. Obviously, users would have to be told that private/corporate server settings are not candidates for the ISPDB, and any/all anonymous additions would have to be verified by someone (that they are correct, and that they are not private, etc), but you could ask for volunteers for this kind of thing - hell, I'd be *happy* to do something like that - a way to contribute that doesn't require programming skills.

Incidentally, this ISPDB is what I was referring to much earlier when I said I had read something about the auto-config process but then couldn't find it.

> Please see https://wiki.mozilla.org/Thunderbird:Autoconfiguration for details
> how this works in general.
> 
> Again, I see a reason for users to want to either have mail locally or on the
> server. That's what they care about, and that's what we should ask. Protocol
> is irrelevant.

On the contrary... it is absolutely relevant. Yes, many people are ignorant of the differences, so educate them, don't contribute to their ignorance.

I prefer that the protocol come first, so better would be:

(o) IMAP (Keep messages/folders on the internet server)
( ) POP (Keep messages/folders on your computer)
( ) Help me choose (Starts help assistant)

(In reply to comment #24)
> I had assume the plan would be that if we don't have an option for POP or
> IMAP that we would either remove that option entirely from the screen [1]
> or perhaps leave the option there with a button/link to "Manually configure
> this" which brings the person to [2]

And in a situation like this, see above - take the opportunity to prompt the user to contribute their manual settings to the ISPDB, explaining how/why it would benefit everyone in the long run...
(In reply to comment #24)
>> Have you had a look at the mockups that have been posted on this bug report.

> Yes. it says "We have found a configuration for your mail ...
> (o) IMAP
> ( ) POP"

The mock-ups say a lot more than that. I'm disappointed in the total lack of comments on my mock-ups, and won't be wasting any more of my time on things like this for people who are just ging to ignore them.
> I had assume the plan would be that if we don't have an option for POP or IMAP
> that we would either remove that option entirely from the screen [1] or perhaps
> leave the option there with a button/link to "Manually configure this" which
> brings the person to [2]

That works for me.

>  it seems like we should be able to ask ISDB for both by doing 2 calls.

No, the configs are simply not there, for most ISPs.

We can extend the format and the DB to allow both server types in one config file, but we still need to re-gather all the info for all ISPs.
> > > Why not allow a manual configuration option?
> > We already do.
> > <http://support.mozillamessaging.com/en-US/kb/Configure+an+Account>
> And it is obviously very confusing and needs to be changed.

I agree, and I plan to do that (make the manual config option more accessible and usable), in another bug. Manual config is currently indeed poor and has to be improved a lot, but that has nothing to do with this bug.

> *tell* the users about the ISPDB

Planned, and described on subpages of <https://wiki.mozilla.org/Thunderbird:Autoconfiguration>.

> I'd be *happy* to do something like that

Great. You can start right now at <https://wiki.mozilla.org/Thunderbird/TopMissingDomains>, or add whatever other ISPs you know.
I have been reading through this discussion, and it seems that most posters are badly missing the point.
First, ASSUMING that a server supports IMAP is a BAD IDEA, and assuming that if it supports both IMAP and POP3, that the user's account is configured for IMAP is pretty sure to cause trouble.  When I try to use autoconfiguration (TB3.1b1), it assumes IMAP, which, my server MIGHT offer, but is NOT what I use, and getting it set up to use POP3 is impossible, as far as I have been able to determine.  I might be able to get it done, but I have over 40 years IT experience, and 15 years on Windows computers.  I am certain that a new user, freshly come from OE, say, would just do exactly what I did, uninstall TB3.1b1.  
Simply, if you can't make this work for EVERYONE, TAKE IT OUT!  It is a negative, with no mitigation.  
And assuming IMAP, is a bad idea.  IMAP requires dedicating terabytes of storage for users data, and most large ISPs are not going to do that for personal use accounts.  It's too expensive.
Refusing to offer POP because of a philosophical belief in IMAP seems to me clearly a non-starter.  The economics around each protocol for both the user and the ISP are different to the point where these protocols are not fungible.
We need to continue to offer both.

(In reply to comment #30)
> >  it seems like we should be able to ask ISDB for both by doing 2 calls.
> 
> No, the configs are simply not there, for most ISPs.
>
> We can extend the format and the DB to allow both server types in one config
> file, but we still need to re-gather all the info for all ISPs.

Why couldn't we simply keep the existing config files and augment them with extra information when it arrives?  I.e. make the extended fields for the ISPs optional?

Alternately, what about the possibility of allowing multiple files per ISP?
(In reply to comment #32)


> I have been reading through this discussion, and it seems that most posters are
> badly missing the point...
> ...When I try to use autoconfiguration
> (TB3.1b1), it assumes IMAP, which, my server MIGHT offer, but is NOT what I
> use, and getting it set up to use POP3 is impossible, as far as I have been
> able to determine.  I might be able to get it done, but I have over 40 years IT
> experience, and 15 years on Windows computers.  I am certain that a new user,
> freshly come from OE, say, would just do exactly what I did, uninstall TB3.1b1...
I am a fan of TB, but do not have the will to fight the computer.

Thanks to everyone for the many contructive comments made here.
Depends on: 531267
Maybe, to cover the cases that people seem to be asking for, the dialogue should be more like:

(o) IMAP (Keep messages/folders on the internet server)
( ) POP (Keep messages/folders on your computer, delete them from internet server)
( ) POP (Keep messages/folders on your computer and also on internet server)
( ) Help me choose (Starts help assistant)


Also, after the help assistant has probed (and such probing should probably include trying out the supplied password / username), the user should be given a clear list of what is available, with a recommended choice.

The user should also be allowed to probe again - especially if it turns out that the password / login failed.


Just wondering... is there a way to distinguish between "was no response to the login request"  (TLS/StartThingy/whatever not supported) and "login failed" (password / username wrong / you forgot to add or remove the @domain.name)?
(In reply to comment #35)
> ( ) POP (Keep messages/folders on your computer and also on internet server)

Personally I dislike the idea of promoting this aspect of POP - it is and always has been a kludge at best, and should *not* be encouraged. If someone wants to keep messages on the server, they should be using IMAP.

> Also, after the help assistant has probed (and such probing should probably
> include trying out the supplied password / username), the user should be given
> a clear list of what is available, with a recommended choice.

Did you see my mock-ups? There are three, here's the first one...

https://bugzilla.mozilla.org/show_bug.cgi?id=531099#c9

I'm about done with changes to make the last one much smaller and will upload modified versions later today...

> The user should also be allowed to probe again - especially if it turns out
> that the password / login failed.

Also in my mock-ups.

> Just wondering... is there a way to distinguish between "was no response to
> the login request"  (TLS/StartThingy/whatever not supported) and "login
> failed" (password / username wrong / you forgot to add or remove the
> @domain.name)?

It would be nice if failures could be *reliably* detected at that level, but I think it will vary a lot from server to server (or maybe I'm wrong)...

As for the last part - again I think the default should be to use the full email address for the username - most systems are already using it or allow for both while transitioning to use it, but I think soon enough all will do this.
(My understanding is that the autoconfig stuff doesn't need sr, cause only Thunderbird uses it, but I thought I'ld ask anyways.)

I'ld also really like it if this could land in 3.0.next, but I don't want to request approval until after this patch has gotten a once-over.

Thanks,
Blake.
Attachment #433643 - Flags: superreview?(bugzilla)
Attachment #433643 - Flags: review?(bienvenu)
> My understanding is that the autoconfig stuff doesn't need sr

Per dmose on IRC (I asked a few days ago), that's correct.

r=BenB on the patch, FWIW.

In the test, you added the IMAP config as first one, which means the test will now draw the IMAP instead of POP config. That may well be intended by you, in which case it's fine, I just want to note it.
Comment on attachment 433643 [details] [diff] [review]
[checked-in] A patch to allow us to have multiple incoming servers in the config xml without errors in the client.

(Setting r=BenB, cause I'm pretty sure he qualifies as a reviewer of autoconfig code, and removing the sr request, cause we don't need it for autoconfig.)
Attachment #433643 - Flags: superreview?(bugzilla)
Attachment #433643 - Flags: review?(bienvenu)
Attachment #433643 - Flags: review+
Comment on attachment 433643 [details] [diff] [review]
[checked-in] A patch to allow us to have multiple incoming servers in the config xml without errors in the client.

(In reply to comment #38)
> In the test, you added the IMAP config as first one, which means the test will
> now draw the IMAP instead of POP config. That may well be intended by you, in
> which case it's fine, I just want to note it.

Yeah, I thought that we would want the tested XML to be as close to the ideal as possible, and since we want other people to put IMAP before POP, that's what I did in the test.  ;)

(As a side note, I think the 3.0.4 boat has sailed, which is why I'm asking for approval for 3.0.5.  But, if we can slide this change in to 3.0.4, I would prefer that.)

Thanks,
Blake.
Attachment #433643 - Attachment description: A patch to allow us to have multiple incoming servers in the config xml without errors in the client. → [checked-in] A patch to allow us to have multiple incoming servers in the config xml without errors in the client.
Attachment #433643 - Flags: approval-thunderbird3.0.5?
(In reply to comment #40)
> and since we want other people to put IMAP before POP, that's what
> I did in the test.  ;)

I will restate my opposition to promoting IMAP over POP. This is contrary to what 90+% of people use and will expect, and is just asking trouble, as evidenced by the numerous complaints and bug reports wrt being forced to use IMAP over POP.

I am fully in favor of educating people about the differences and explaining why IMAP is superior for certain use cases (like people who access their email from multiple locations/clients).

But...

On more than one occasion I have had devs tell me that the focus of TB is more to the individual user rather than the enterprise user (generally in response to posts asking for .msi installer and full GPO management support), so your comment is in direct opposition to that - it is *enterprise* users who will be more likely to want/need IMAP. Home users will most likely want POP (mainly because that's what they have always used).
> my opposition to promoting IMAP over POP

Bugzilla is not the forum for discussions like this. People have told you that before. Please use the newsgroup for that.
Blake, can you hold back on this change?
It's fairly big, you need to change:
- XML file format (you patch, but needs to be specced)
- UI
  (will conflict with bug 549045 and have to be entirely redone there)
- guess code
  (will conflict with bug 549040 and have to be entirely redone there)
- ISPDB server side
- central AccountConfig interface (I'm not sure yet about the best
  representation - I surely don't want to hack this in or bolt it on)

Can we drop this from beta2 and wait for bug 549045, please? I intend to include it there. I intended to get working on that bug very soon.
beta2=? - asking to reconsider
blocking-thunderbird3.1: beta2+ → ?
(In reply to comment #43)
> Blake, can you hold back on this change?
> It's fairly big, you need to change:
> - XML file format (you patch, but needs to be specced)
> - UI
>   (will conflict with bug 549045 and have to be entirely redone there)
> - guess code
>   (will conflict with bug 549040 and have to be entirely redone there)
> - ISPDB server side
> - central AccountConfig interface (I'm not sure yet about the best
>   representation - I surely don't want to hack this in or bolt it on)
> 
> Can we drop this from beta2 and wait for bug 549045, please? I intend to
> include it there. I intended to get working on that bug very soon.

Well, I think this is kind of important based on the number of comments we get, so I'm going to see what I can do in the short time I have remaining.  If I can get something reasonably self-contained that doesn't mess with bug 549045 too much, then it might be a win to just include it for this release.

(For instance, we don't need to change the ISPDB in this bug; I don't have to modify the guess code if we only offer the choice for ISPs that are in our database; the UI change should be fairly small; the AccountConfig interface will grow a single extra attribute, if I understand correctly.)

And maybe I won't get anything working and reviewed by the deadline, in which case you don't need to worry.  ;)

Finally, if it looks like you're going to get bug 549045 in, then I will have no problems dropping my patch in favour of that one.

The only final complaint you could have is that I might be wasting my effort, but since I don't think bug 549045 is specced out enough for people to work on it yet, and since I don't want to step on your toes, I don't think there's a lot I can do to push that bug forward in the next two days.

Thanks,
Blake.
Status: NEW → ASSIGNED
My msg was mainly to drivers to reevaluate the beta2 nomination, because I don't understand the sudden urgency and think that the problems with manual config are more severe and also cause more complaints from what I saw.
If you have no problem with double work, and promise me to be quick with the reviews of the mentioned bugs (the patches will be big), I have no problem with you working on this here in parallel.
> I have no problem with you working on this here in parallel.

And, FWIW, I'll assist with reviews as well, where I can :).
(In reply to comment #40)
> (From update of attachment 433643 [details] [diff] [review])
> (In reply to comment #38)
> (As a side note, I think the 3.0.4 boat has sailed, which is why I'm asking for
> approval for 3.0.5.  But, if we can slide this change in to 3.0.4, I would
> prefer that.)

So I didn't actually get to comment on the patch. One of the things that concerns me is how you're going to support older versions thank 3.0.5. For instance, even though 3.0.3 is out now, we've still got somewhere around 20% of users on older 3.0.x versions.
Here's the new piece of UI, with wording from Bryan.

Patch coming soon.
Urgs, I feel really bad with this. This is *way* too prominent.
The whole idea of the dialog was to keep the widgets and questions to a minimum, and remove all technical questions.

For the concrete wording: Could we please, for IMAP, get in the fact that mails are stored on the server? That's an important factor for consideration, because it's about privacy, backup etc..
For the same reason, I would refrain from explicitly recommending IMAP. I'd just make it the default.
Looking at the example, I still feel like this whole issue of which email type is better is missing the point.  How many users will be setting up email for a type BEFORE they have their email set up on one or the other at their ISP?  And at that point, what effect will any recommendation from Mozilla developers have?  It's rather like arguing on whether the baby should be a boy or girl, AFTER it is already born!  Amazing!
The goal, the only goal, is to get the user set up to USE what he HAS, not direct him to something his service may not even offer.
Ben:
Please feel free to suggest alternate wording.  I'm happy to change it to whatever Bryan is happy with.  ;)

Ronald:
If the email service doesn't offer one or the other, we won't show this screen at all, and just present the user with the working configuration.

This screen only pops up if both are available, and we want the user to choose one.  (And even then, the configuration the ISP recommends will be pre-selected, so all the user has to do is hit enter, or click the default button, and she'll get whatever her email service feels is best.)

Thanks,
Blake.
Unfortunately, this is not how it currently works.  At least through 3.0.3.  It tried to configure my email account as IMAP, which it is NOT.  It failed to get a working configuration, then it was just about impossible to get it set up as POP.  I would MUCH rather have an option to just provide that bit of information.
It's not like I can easily change to IMAP, even if Charter offers it...
(In reply to comment #49)
> Created an attachment (id=435033) [details]
> A picture showing where the new option fits in.
> 
> Here's the new piece of UI, with wording from Bryan.
> 
> Patch coming soon.

How about adding links to both imap and pop word.

http://en.wikipedia.org/wiki/Post_Office_Protocol
http://en.wikipedia.org/wiki/IMAP

So curious people who want to know can check for themselves ?
_Tsk_, great idea.
Blake: Part of the problem is the UI space it takes. (My proposal <https://bug549045.bugzilla.mozilla.org/attachment.cgi?id=434079> wasn't much better in this respect.)
So, how about this: Just one line, with:
(o) IMAP (keep mail on server) (o) POP (store locally)
or even shorter:
(o) IMAP (server storage) (o) POP (local)
And IMAP and POP would be linked, but maybe not blue or underlined, just get a "?" mouse cursor, to avoid a highlighting / attention drawing effect.
Ronald Hunter, "It failed to get a working configuration". That would be a bug in the autodetection, not the UI, and that would be a different bug. We shouldn't even offer IMAP when it's not working. Please file it separately.
Attached image Shorter IMAP/POP (obsolete) —
Here's a screenshot of my proposal, with bug 549045.
Attachment #435121 - Flags: ui-review?(clarkbw)
Alternatively, we could just make the "IMAP" label in the result line (with server hostname) in my screenshot a dropdown (and have no explanation).
Attached image Dropdown
Same dialog (still bug 549045) with dropdown.
Duplicate of this bug: 553899
Attached image The following dialog.
(In reply to comment #54)
> How about adding links to both imap and pop word.
> http://en.wikipedia.org/wiki/Post_Office_Protocol
> http://en.wikipedia.org/wiki/IMAP
> So curious people who want to know can check for themselves ?

I agree that that's a neat idea, but since that text is coming from a xul radio label, it's a little too hard to add for this first revision.

Ben: Get Bryan to agree to different wording and layout, and I'll be happy.
But.  You can see from my screenshot how much space that dialog will take.  (It's being put in the same spot as the dialog that follows is, and so will be the same size.)  So, being concerned about how small it is isn't really a productive use of time.  ;) 

Thanks,
Blake.
Attached patch The patch to implement the UI. (obsolete) — Splinter Review
Hey, it's been a while since I've tried to stick Philor with a review request…  Let's see if this one takes, or if he punts it off to Bienvenu.  :)

Thanks,
Blake.
Attachment #435161 - Flags: ui-review?(clarkbw)
Attachment #435161 - Flags: review?(philringnalda)
> being concerned about how small it is

...is mainly a matter of size = prominence
Comment on attachment 435161 [details] [diff] [review]
The patch to implement the UI.

I'd like to discuss the API of the central AccountConfig interface and the XML format with you first.
Also, that <alternatives> is incompatible with my patch in bug 531267.
Attachment #435161 - Flags: review?(philringnalda) → review-
Comment on attachment 435161 [details] [diff] [review]
The patch to implement the UI.

Yup, it will.

To be clear, I don't think that this patch should land unless we get down to the wire and your changes aren't ready.

But if that happens, we should have this patch ready to go as a backup.

(Or, if this patch does land, I will r+ the bit of your followup patch that un-does these changes.  ;)

Also, re: the <alternatives>, I did that so that we didn't have to bump the format.  If we do decide to bump the format, that's a much larger change, and not one I want to put into this intentionally-minimal patch.

Ping me in #ispdb when you want to chat about the API/XML, and hopefully we can come to a consensus about what modifiations I should make to this patch.

Thanks,
Blake.
Attachment #435161 - Flags: review?(philringnalda)
A couple comments while I'm on the road. I'll try to get more down later when I'm on a real computer.

As Blake said we default to POP when the ispdb recommends that default.  Otherwise we do default to IMAP as the choice.  I believe that IMAP is the correct default and recommendation.

We can't use terms like 'server' or 'local' to differentiate, they are too technical.  In asking a few non-tech users about the diff of each type as they saw it after setting each account up was _folders_.  IMAP had their folders and POP didn't.  Plus you have POP with email on the server only or IMAP with all the messages downloaded locally.  Linking to the KB pages for each service makes a lot of sense so people can find out more.

The text 'TB recommends IMAP' might be wrong in the situation where the ISP has set POP as the default because the conflict might confuse people. Otherwise it's just the truth of the matter and can help people who are unsure about the choice, especially if they are choosing POP just because that's what they were using and maybe were not aware of the choice.
> We can't use terms like 'server' or 'local' to differentiate

How about
(o) IMAP (remote folders) ( ) POP (store mails on my computer)
? (That's unfortunately already longer again)

Blake, as for 'radio labels can't be links': we could make the part in brackets a link. An article on support.momo.com makes more sense than Wikipedia, too.

> 'TB recommends IMAP'

We do that implicitly with the default. Explicitly stating it makes it stronger, which I am not so sure we should do, given the privacy and data sovereignty implications.
Rather than trying to come up with a concise and elegant explanation of POP vs IMAP that everyone can understand, instead just have "POP" and "IMAP", but have tooltips that give a few sentences of explanation? In trying to come up with something that fits on the dialog, there's a risk of overloading people with info they don't necessarily need while still not really explaining things to the people who DO need the info.

This would also let you put the radio button right next to the relevant configuration settings, which makes more sense to me (and would be easier to extend if someone added more protocols, like Exchange).
Folks, from a just plain user, I think the default to IMAP is a mistake (unless what you mean is that there will be two choices in the selection popup, with IMAP pre-selected).  I have multiple email accounts, all capable of both, three out of four I run as POP.  I would be glad to explain why, but I don't think that's material.  What is needed to solve the types of problems I submitted my bug for is choice - up front.  If the ISP has both capabilities.  If not, default to what is available.

Peter
Here's what I have in bug 549045
Attachment #435121 - Attachment is obsolete: true
Attachment #435354 - Flags: ui-review?(clarkbw)
Attachment #435121 - Flags: ui-review?(clarkbw)
Something in this space has to block 3.1, and I believe this the right thing.
I've just marked bug 549045 blocking-, as the scope of that bug is just way too big.  Marking this bug blocking+ again.
blocking-thunderbird3.1: ? → beta2+
Depends on: 556140
Attachment #435161 - Flags: review?(philringnalda) → review?(bienvenu)
Comment on attachment 435161 [details] [diff] [review]
The patch to implement the UI.

Yeah, sorry, you guess right about my general level of uselessness.
Depends on: 556729
Comment on attachment 435161 [details] [diff] [review]
The patch to implement the UI.

ugh, sorry, this appears to have bit-rotted. Can I get a non-bitrotted version?
(In reply to comment #73)
> (From update of attachment 435161 [details] [diff] [review])
> ugh, sorry, this appears to have bit-rotted. Can I get a non-bitrotted version?

Yeah, I kind of expected that.  :)

Here you go.

Thanks,
Blake.
Attachment #435161 - Attachment is obsolete: true
Attachment #436717 - Flags: ui-review?(clarkbw)
Attachment #436717 - Flags: review?(bienvenu)
Attachment #435161 - Flags: ui-review?(clarkbw)
Attachment #435161 - Flags: review?(bienvenu)
+      this._currentConfig.incomingAlternatives.push(this._currentConfig.incoming);

You want to put it at the top, using Array.unshift().

Compare onResultIMAPOrPOP3() in my branch:
https://hg.mozilla.org/users/mozilla.BenB_bucksch.org/tb-autoconfig-ui-1/file/856f91ad8981/mailnews/base/prefs/content/accountcreation/emailWizard.js#l817
if (config.incomingAlternatives.length > 0) {

Here you want to filter for those with the other server type. There may well be 2 POP servers and no IMAP (or vice versa).
I tried running this patch against my dreamhost account which supports both imap and pop3, and was only given the choice of imap. Does auto probing not support both server types?
> Does auto probing not support both server types?

No, not yet.
However, if we implemented that in guessConfig.js, this patch would automatically use it.
ah, ok, how can I test this, then? Do we have an isp config file that will cause this UI to pop up? Do I need to point to a different isp db?
If you set the mailnews.auto_config_url to http://bwinton.latte.ca/Work/ you can then use an email address in the (invalid) latte.com domain, and you should see both POP (default), and IMAP choices.

And now that we've got the v1.1 cutover on the server, we can hopefully start adding multiple incoming servers to some of our actual domains.  :)

Thanks,
Blake.
You can also test with foo@bucksch.name.
You should either see IMAP server correct.bucksch.name or POP3 server pop.bucksch.name. If you see server fallback.bucksch.name, you ran into a bug.
> And now that we've got the v1.1 cutover on the server, we can hopefully start
> adding multiple incoming servers to some of our actual domains.  :)

Once you reviewed bug 556729 and bug 556140, we're set :).
OK, thx, I tried both your test configs, and it seemed to do the right thing. Blake, yours came up with pop3 as the default selected radio button, even though we have the text that says "Shredder recommends imap". Ben's defaulted to IMAP. Is the default controlled by the ISP? If so, it's a little odd to say that we recommend IMAP but have pop3 come up selected...that text makes more sense if there's no "default" from the ISP, or we discovered both possibilities through probing. Anyway, more of a question for Bryan...
Blake, do you have a response to Ben's comments about the code, #c75 and #c76 ?
(In reply to comment #83)
> it's a little odd to say
> that we recommend IMAP but have pop3 come up selected...that text makes more
> sense if there's no "default" from the ISP, or we discovered both possibilities
> through probing. Anyway, more of a question for Bryan...

Right, that's the case I'm concerned about - see comment #66 - if we made something like that text only show up when a default hasn't been recommended then I think it would make a lot more sense.
Ah, yes, if we know what the ISP has recommended, then we shouldn't put that text up.
I'm still very concerned that this is way too prominent in the UI.
Not only does it take up a lot of space, which alone makes it very prominent. But it's now even a forced, explicit choice, by overlaying the result and the user having to click specifically through this selection.

This totally breaks this "it's all easy, just enter these 3 things". With 3.1 shipping like this, I'll be highly embarrassed, because it's breaks the whole story.

Can't we just do it with 2 smaller radio buttons, like shown on
<https://bug532590.bugzilla.mozilla.org/attachment.cgi?id=435354>? (Ignore the server description, I mean just the radio boxen.) It's basically the same as now, just with a lot less text. People who don't know what to choose will just ignore it and take the default. There is a brief, but clear explanation. People who wanted POP can choose it.
I'll happily provide a patch (with the other 2 code problems I mentioned fixed, too).

Ben
In order:
> Blake, do you have a response to Ben's comments about the code, #c75 and #c76 ?

Yup, they're bugs.  I'll post a new patch that fixes them, hopefully tomorrow.

> if we made
> something like that text only show up when a default hasn't been recommended
> then I think it would make a lot more sense.

I believe I'll be removing that text.  The ISP always implicitly recommends
something by listing it first in the XML config.  And we always implicitly
recommend IMAP by listing it first in the dialog.  ;)

> I'm still very concerned that this is way too prominent in the UI.
[snip…]
> This totally breaks this "it's all easy, just enter these 3 things". With 3.1
> shipping like this, I'll be highly embarrassed, because it's breaks the whole
> story.
[snip…]
> Can't we just do it with 2 smaller radio buttons?
[snip…]
> I'll happily provide a patch (with the other 2 code problems I mentioned
> fixed, too).

I think you've got another bug, that I'm still hoping to get landed, which will remove the need for this patch entirely.  Please, please, please work on that instead of getting distracted by this.  ;)

Thanks,
Blake.
> I'm still hoping to get landed [bug 549045]

OK, great! (I'd be happy to hear feedback on the patch there.)
Okay, the recommendation text is removed, and Ben's comments have been fixed, with manual (for now) test cases.

I've switched the set of files at http://bwinton.latte.ca/Work/ so as to test the cases in a more obvious way.  The files are now:
2pop.latte.ca
imap.latte.ca
imappop.latte.ca
pop.latte.ca
popimap.latte.ca
popimappop.latte.ca

2pop has two pop servers, imap has one imap server, imappop has an imap then a pop server, etc.

The results should be:
2pop: No dialog displayed, the server should be "pop.latte.ca"
imap: No dialog displayed, the server should be "imap.latte.ca"
imappop: Dialog displayed, the default should be IMAP.
  Choose imap: The server should be "imap.latte.ca"
  Choose pop: The server should be "pop.latte.ca"
pop: No dialog displayed, the server should be "pop.latte.ca"
popimap: Dialog displayed, the default should be POP.
  Choose imap: The server should be "imap.latte.ca"
  Choose pop: The server should be "pop.latte.ca"
popimappop: Dialog displayed, the default should be POP.
  Choose imap: The server should be "imap.latte.ca"
  Choose pop: The server should be "pop.latte.ca"

You should never see "pop-2.latte.ca", as that's the second server, which we shouldn't use.

Thanks,
Blake.
Attachment #436717 - Attachment is obsolete: true
Attachment #437290 - Flags: ui-review?(clarkbw)
Attachment #437290 - Flags: review?(bienvenu)
Attachment #436717 - Flags: ui-review?(clarkbw)
Attachment #436717 - Flags: review?(bienvenu)
(In reply to comment #90)
> Created an attachment (id=437290) [details]

> The results should be:

actual results interspersed below:

> 2pop: No dialog displayed, the server should be "pop.latte.ca"
it was pop3.latte.com
> imap: No dialog displayed, the server should be "imap.latte.ca"
check
> imappop: Dialog displayed, the default should be IMAP.
>   Choose imap: The server should be "imap.latte.ca"
it was latte.ca
>   Choose pop: The server should be "pop.latte.ca"
it was also latte.ca

> pop: No dialog displayed, the server should be "pop.latte.ca"
check.

> popimap: Dialog displayed, the default should be POP.
check
>   Choose imap: The server should be "imap.latte.ca"
it was latte.ca
>   Choose pop: The server should be "pop.latte.ca"
it was latte.ca
> popimappop: Dialog displayed, the default should be POP.
>   Choose imap: The server should be "imap.latte.ca"
it was latte.ca
>   Choose pop: The server should be "pop.latte.ca"
it was pop3.latte.ca
The patch looks OK, but the results I got were pretty different from what I was led to expect, so I'd like confirmation before r+ 'ing :-)
bienvenu, did you set pref "mailnews.auto_config_url" to "http://bwinton.latte.ca/Work/" ?
(In reply to comment #93)
> bienvenu, did you set pref "mailnews.auto_config_url" to
> "http://bwinton.latte.ca/Work/" ?

Yes, I did.
(In reply to comment #91)
> > The results should be:
> actual results interspersed below:
>
> > 2pop: No dialog displayed, the server should be "pop.latte.ca"
> it was pop3.latte.com
> > imappop: Dialog displayed, the default should be IMAP.
> >   Choose imap: The server should be "imap.latte.ca"
> it was latte.ca
> >   Choose pop: The server should be "pop.latte.ca"
> it was also latte.ca
> >   Choose imap: The server should be "imap.latte.ca"
> it was latte.ca
> >   Choose pop: The server should be "pop.latte.ca"
> it was latte.ca
> > popimappop: Dialog displayed, the default should be POP.
> >   Choose imap: The server should be "imap.latte.ca"
> it was latte.ca
> >   Choose pop: The server should be "pop.latte.ca"
> it was pop3.latte.ca

All the actual results look okay to me, but I've updated the config files on my server to match what I thought the results should be, so if you want to re-test, then the actual results should match the proposed results at this point.

Thank you, and I'm sorry about that,
Blake.
Duplicate of this bug: 556243
Comment on attachment 437290 [details] [diff] [review]
The patch with Ben's and Bienvenu's comments implemented.

spot checked a couple results, and they look like they match the expected results now.

FWIW, I think the bigger GS issue was autoprobing preferring IMAP when both were available, so I think we need to fix that to really say we've satisfied the GS issue.
Attachment #437290 - Flags: review?(bienvenu) → review+
Comment on attachment 437290 [details] [diff] [review]
The patch with Ben's and Bienvenu's comments implemented.

Looks good, thanks.
Attachment #437290 - Flags: ui-review?(clarkbw) → ui-review+
Talked with Bryan earlier today, and he's OK with the following changes, which I proposed:
- Put a "(recommended)" at the end of the imap choice, instead of the current long label above it
- Hide the "recommended", if the config file prefers POP (his suggestion,
  see also comment 85)
- Remove the explicit click-through and put the radio buttons on the next
  screen, above the server fields, and make their content change when the user
  switches between IMAP and POP. He thought that'd be hard to implement and
  that was the reason why we didn't do it.
I said I'd try to make a patch with the above, if we can't get bug 549045 done in time for beta2. So, can we hold this bug until then, please? Thanks.
> I'd try to make a patch with the above, if we can't get bug 549045 done
> in time for beta2

My bug 549045 just got sacked for 3.1, so I'll update the patch here.
Attached patch Fix, v6 (obsolete) — Splinter Review
This implements what I suggested above.

It also fixes a few bugs, e.g. when you go into manual edit after getting a config with both IMAP and POP3, and fixes an unrelated bug with a missing string.
Attachment #437290 - Attachment is obsolete: true
Attachment #438591 - Flags: ui-review?(clarkbw)
Attachment #438591 - Flags: review?(bwinton)
Attachment #438591 - Attachment description: Fix, v5 → Fix, v6
Attached patch Fix, v7 (obsolete) — Splinter Review
Attachment #438591 - Attachment is obsolete: true
Attachment #438595 - Flags: ui-review?(clarkbw)
Attachment #438595 - Flags: review?(bwinton)
Attachment #438591 - Flags: ui-review?(clarkbw)
Attachment #438591 - Flags: review?(bwinton)
Attachment #433643 - Flags: approval-thunderbird3.0.5? → approval-thunderbird3.0.5-
Comment on attachment 433643 [details] [diff] [review]
[checked-in] A patch to allow us to have multiple incoming servers in the config xml without errors in the client.

From discussion with Blake over irc, this isn't needed for 3.0.5 now.
Attachment #437290 - Attachment is obsolete: false
(I originally allowed to select both per radio and dropdown)
<clarkbw> so you're going to remove the dropdown choice, right?
<clarkbw> i think we just want one place [the radio] to make the change
(I changed that, it's in Fix v7)
<clarkbw> otherwise it looks ok
Whiteboard: [UXprio] [gs] → [UXprio] [gs] [patch ready to land, alternate option being investigated]
Comment on attachment 438595 [details] [diff] [review]
Fix, v7

I looked over this with Ben via IRC and screenshots but I'm planning on doing a more in depth review today or tomorrow.
Please do *not* land the previous patch.

Bryan: thanks.

I made try server builds for you, Mac is ready at
http://build.mozillamessaging.com/buildbot/try/builders/Try%20server%20comm-central%20mac%20hg%20builder/builds/459
other platforms are still building.
Whiteboard: [UXprio] [gs] [patch ready to land, alternate option being investigated] → [UXprio] [gs] [patch ready to land, review for new patch needed]
Comment on attachment 438595 [details] [diff] [review]
Fix, v7

Things looks pretty good with a few exceptions, noted below.

* Switching between POP and IMAP in the radio button doesn't change the Incoming server values

* There is some odd sizing issues when choosing "Start Over" either the dialog will have empty space at the bottom or will not grow to accommodate enough space.  This is easily reproducible.
Attachment #438595 - Flags: ui-review?(clarkbw) → ui-review-
> * Switching between POP and IMAP in the radio button doesn't change the
> Incoming server values

Ah, that was a misplayed "_" in the patch I used for the try server.
It should work with the attached patch. I'll make a new try server build. Sorry.

> * There is some odd sizing issues when choosing "Start Over" either the dialog
> will have empty space at the bottom or will not grow to accommodate enough
> space.  This is easily reproducible.

Ah, yes. Reproduction:
- "start over" doesn't shrink dialog.
- When you first get a config which has only one server time, then
   "start over" and use "foo@bucksch.name" and get both server types.
   Dialog is cut off.
I have a window.sizeToContent() in both cases, so it should work, but indeed it doesn't, and I don't know why. Need to try more.
Attached patch Fix, v9Splinter Review
This works for me now, fixes both issues.
Attachment #438885 - Flags: ui-review?(clarkbw)
Attachment #438885 - Flags: review?(bwinton)
No longer depends on: 533680
Ping: reviews
Attachment #438885 - Flags: review?(bwinton) → review?(neil)
Attachment #438885 - Flags: review?(neil) → review?(mkmelin+mozilla)
FWIW, I like the new behaviour, except for the mis-aligned word "(recommended)" when the ISP suggests IMAP, and that's what we choose.  If you remove that, you get a (worthless) ui-r+ from me.  ;)

Later,
Blake.
(In reply to comment #112)
> FWIW, I like the new behaviour, except for the mis-aligned word "(recommended)"
> when the ISP suggests IMAP, and that's what we choose.  If you remove that, you
> get a (worthless) ui-r+ from me.  ;)

You need align="center" for the hbox around the radio and the label so they can line up and it's ui-r+ for me.
Comment on attachment 438885 [details] [diff] [review]
Fix, v9

> <!ENTITY imap.label                      "IMAP">
> <!ENTITY pop.label                       "POP">
> <!ENTITY smtp.label                      "SMTP">
>+<!ENTITY imap.description                "IMAP - Access folders and messages from multiple computers.">

Maybe "messages and folders" instead. And no full stop at the end.

>+<!ENTITY pop.description                 "POP - Download all messages onto this computer, folders are local only.">

No full stop at the end. 

>+<!ENTITY recommended-appendix.label      "(recommended)">

I'd question if this recommended stuff is needed.

>+  // IMAP vs. POP3 radio (not *dropdown*) changed
>+  setIncomingProtocolRadio : function()
>+  {
>+    let newTypeSelected = document.getElementById("popimap_radiogroup")
>+        .selectedItem.value;

Align so that dots line up.

>     } catch(ex) {
>       gEmailWizardLogger.error("missing string for " + msgName);
>+      logException(new Exception("missing string"));

I'm not sure this is needed, but if you want it, add the name of the missing string to the message.

r=mkmelin with those nits fixed
Attachment #438885 - Flags: review?(mkmelin+mozilla) → review+
> You need align="center"

I already have an align="baseline", which - per spec - should line up the text, and they do for me?
They don't for you on Mac?
Assuming that, I change it for align="center" for now, but I think "baseline" is correct.

> >+<!ENTITY recommended-appendix.label      "(recommended)">

> I'd question if this recommended stuff is needed.

So do I, but apparently it was important to Bryan, so I'll keep it.

Fixed the nits.
Review nits fixed.
Commited as <http://hg.mozilla.org/comm-central/rev/45ed10550048>

Thanks a lot, mkmelin, for the quick review, and Bryan!
Assignee: bwinton → ben.bucksch
Attachment #438595 - Attachment is obsolete: true
Attachment #438595 - Flags: review?(bwinton)
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [UXprio] [gs] [patch ready to land, review for new patch needed] → [UXprio] [gs]
Depends on: 560051
Note that you will only see the effects, if:
- you enter foo@bucksch.name as email address
- for ISP configs, bug 556729 is fixed
- for guessing, bug 560051 is fixed
Attachment #438885 - Flags: ui-review?(clarkbw)
Attachment #435354 - Flags: ui-review?(clarkbw)
> - for ISP configs, bug 556729 is fixed

I commited this, so you should now be seeing the IMAP/POP3 radio box that was implemented here, for many big ISPs, e.g. GMail (just enter foo@gmail.com).
This is still not fixed in 3.1.. It's impossible for me to create a pop account if I enter an e-mail address to a server that responds on the Imap port!!!
(In reply to comment #119)
> This is still not fixed in 3.1.. It's impossible for me to create a pop account
> if I enter an e-mail address to a server that responds on the Imap port!!!

It _should_ be fixed.  Please open a new bug, assign it to me, and include the email address you're seeing the problem with.

Thank you,
Blake.
I'm sorry.  In my frustrated nerd rage this morning, I managed to completely overlook the "Edit" button.  I will offer these observations and suggestions:

1. Manual Setup button doesn't do anything until all the information in the new account dialogue is in place (either through auto-detection or manual editing), which makes that button completely redundant.  Manual set-up should instead swap functions with the current edit Button.

2.  It would be great if, when manaully configuring information in the new mail account dialogue, if the port number would once again automatically change to a sensible default when changing the server/auth type.
(In reply to comment #120)
> (In reply to comment #119)
> > This is still not fixed in 3.1.. It's impossible for me to create a pop account
> > if I enter an e-mail address to a server that responds on the Imap port!!!
> 
> It _should_ be fixed.  Please open a new bug, assign it to me, and include the
> email address you're seeing the problem with.
> 
> Thank you,
> Blake.

Blake, I've reproduced the problem I was seeing and filed a new bug report.  However, I am unable to assign it to you.  See bug: 575418
> 1. Manual Setup button doesn't do anything

Bug 549045

> 2. ... if the port number would once again automatically change to a
> sensible default

Also bug 549045.
(In reply to comment #122)
> Blake, I've reproduced the problem I was seeing and filed a new bug report. 
> However, I am unable to assign it to you.  See bug: 575418

@rashkae
Please don't add a colon to the bug number... when you do you can't click on it from here... example:

bug: 575418

bug 575418
Well I am not sure of the proceedure here, but I cannot whatever I try to do, create a POP3 Account that works.  Either the wrong port is auto selected and unable to deselect or the configuration test just sits there for hours on end!! 

Forget even trying to remove IMAP!!! 

I don't know whose great idea it was to auto configure everything, but from a users point of view...nightmare...having to use Endora whilst you guys sort out this issue. And it is an issue!!!!
(In reply to comment #125)
> Well I am not sure of the procedure here, but I cannot whatever I try to do,
> create a POP3 Account that works.  Either the wrong port is auto selected and
> unable to deselect or the configuration test just sits there for hours on
> end!! 

? Sure you can - just click the 'Manual Setup' button, then go to the account details in the Account Settings configuration and manually set it up.

I'll agree that this is *not* intuitive *at* *all*, but it does work.

> Forget even trying to remove IMAP!!! 
> 
> I don't know whose great idea it was to auto configure everything, but from a
> users point of view...nightmare...having to use Endora whilst you guys sort
> out this issue. And it is an issue!!!!

It needs to be made more intuitive, yes. When you click  the 'Manual Setup' button, it should create the account, then *take* *you* *there*. Currently, it seems to just park itself at some random account, rather than the new one you just created.

What *should* happen is, you should stay on the same window (the 'auto-detect' window), but it should go into a manual mode - meaning, allow you to put whatever you want in the boxes, and click the 'Create Account' button.

I'll go open a bug for this...
Done - see bug 580216
You need to log in before you can comment on or make changes to this bug.