Open Bug 503631 Opened 15 years ago Updated 2 years ago

Fix enableURL for autoconfig in a way that will pass ui-r

Categories

(Thunderbird :: Account Manager, defect)

defect

Tracking

(Not tracked)

People

(Reporter: philor, Unassigned)

References

Details

(Keywords: ux-error-prevention)

When it lived in its own repo, autoconfig had a feature to include an enableURL in a config file which would then be presented to the user, the canonical example being the URL to enable IMAP for Gmail. However (see bug 422814 comment 162), the way it was implemented as a "I don't care whether or not you already know that you do not need to visit this URL, I'm not letting you proceed until you click this link" did not pass ui-r. We need to reimplement it in a way that trusts the user a bit more, perhaps by only offering (not requiring) it when we try to log in and fail.
"only offering (not requiring) it when we try to log in and fail."

First, it's bad to try and fail. We should remove problems which we know can or will exist instead of knowingly running into the problem.

Second, catching the "fail" doesn't work, because we cannot reliably detect the failure.
* In many cases, the ISP servers simply do not answer when you're not in the right network (connected to the ISP, or not, depending on what they want), and TB just sits there and waits, for 2 minutes (which most users don't wait for). We tried hard to decrease the timeout, but failed so far.
* There were other reasons, which I don't remember, why things acted up.


There ISPs create so many strange customs, we *must* have the ability to give the user a ISP-specific message, instructions and actions before he proceeds.

> I don't care whether or not you already know that you do not need to
> visit this URL, I'm not letting you proceed until you click this link"

That was my original idea, but it's trivial to remove the "you must", and only show the text and links (and which ones you have visited now), and allowing the user to ignore them.

You cannot reasonable object to just showing them, because when we use this feature, they will be critical for a working configuration (e.g. you must have the POP checkbox in GMail web frontend checked, otherwise it simply doesn't work). It saves a lot of hair-tearing "why doesn't it work?", for reasons he can't know (because they are specific to this ISPs), so somebody needs to tell them at least once.

If the user has already done that, fine. But he must at least be aware of it, and showing it to him during configuration (which he usually does very rarely) is not overdue harassment, but called for. There's a difference between a dialog that comes up whenever I write "attachment" in an email (3 times per day), or one that only comes up during initial configuration (2 times per year).

So, the proposal is: If there is something that needs to be done by the user before the POP/IMPA/SMTP config can work, or something that will cause the config to fail in common situations, then show the text and link. But allow him to proceed without clicking the link (that's the compromise - I think think we should force it).
> There ISPs create so many

d/There/

FWIW, when I said "simply does not answer", I don't mean TCP connection refusals (which I think we catch), but either firewall rules of the ISP which simply DROP the IP packages, or where the POP server answered on the TCP level, but then stopped communicating.
Summary: Reimplement enableURL for autoconfig in a way that will pass ui-r → Fix enableURL for autoconfig in a way that will pass ui-r
AND it's not uncommon: When creating the configs, I had massive problems with at almost 50% of the ISPs, even with a valid server configuration, due to these and similar things. And if I tear my hairs, I don't want to be a Joe User.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.