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)
Thunderbird
Account Manager
Tracking
(Not tracked)
NEW
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.
Comment 1•15 years ago
|
||
"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).
Comment 2•15 years ago
|
||
> 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
Comment 3•15 years ago
|
||
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.
Updated•14 years ago
|
Keywords: ux-error-prevention
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•