> It was pointed out in Bug 162020 that a two-click solution was sufficient. I'm pretty sure you haven't read all of bug 162020. Requiring two clicks on different parts of the screen might be sufficient for mouse-only input, but you also have to consider touch-screen input and mouse+keyboard input. Might as well have a delay; I think we can make it short enough that most mouse-only users won't notice. > It is also what all competing web browsers use, including those like Google > Chrome that have just as high a security rating. Chrome uses a delay too. But instead of disabling a button, it uses an animation (on Mac) or just acts slow (on Windows). Tested using the official Chrome extensions gallery, which by the way does not ensure the two clicks are on different parts of the screen. Chrome's "show the dialog slowly" strategy seems worse than Firefox's "show the dialog quickly but don't allow immediate clicks" strategy. It actually forces users to wait longer than a minimal Firefox-style delay. We plan to shorten the delay from 2s to 1s, reduce its visual impact, and reduce its performance impact by letting the download happen concurrently. I hope most users will find this preferable to Chrome's (intentional??) slowness. I'll post links to our plans, including bug numbers tomorrow.
First off, I assumed the keyboard problem was already dealt with: input should not be accepted until the user has had time to perceive the dialog, which gives you a good 250 ms or so. Furthermore, being able to steal focus from a text box like that seems to be a bug in and of itself. Once a user is in a text box, they tend to not like being taken out of it unless they have left it explicitly by pressing TAB, ENTER, or clicking out. Second, a slide in animation is not considered a delay to the user (and in fact, the actual delay was not perceived by this user until you told me it was there). The user expects the dialog not to be available until it is safe to click on. Once you display something, it's assumed to be active. That's why the current Firefox dialog box has to be so obvious about the delay, and, as we both know, the user noticing the delay is what creates the problem, not the delay itself. When I refer to removing the delay, I mean to remove the perception of a delay. I believe the average user does not notice the delay in Chrome because its animation is an expected part of the UI. It is my understanding that Firefox is also going to be adding a lot of animation. A fade in on the first extension doorhanger (if not doorhangers in general) would almost certainly fit in perfectly. But that's not the only solution. Another would be to simply create a minimum amount of time between the start of the download and the install dialog. The animation would just be the progress bar in the download doorhanger, which can be artificially slowed if necessary. The user expects a download to take a little bit of time. I'm not sure how the above would work if you allow downloading in the background, so that may not be that good an idea. But whatever you do, displaying a full dialog that you cannot immediately use does not seem to be a good choice. It is contrary to almost every UI I have ever seen, and we are trying to be consistent with the OS and its main applications. I will also continue to say that any delay on AMO seems silly, and is probably why my (extremely simple) addon for removing the delay is as popular as it is. Anyone who tries out a lot of extensions is likely annoyed by the slow process. Installing addons in Chrome definitely seems faster from official sources--many don't even have a dialog box. It's quite similar to how installing an addon from the Addon dialog works. But, anyways, thank you for addressing this annoyance, and thank you for explaining what you are doing. I also appreciate including the appropriate bugs, as the only one I found in search was the one I mentioned in the initial report.
The overall project and plan are now being documented at https://wiki.mozilla.org/Extension_Manager:Projects:Improve_Add-on_Installation We'll keep in mind the possibility of replacing the security delay with an animation (for users who have animations enabled). It's a rare case of actual speed and perceived speed being at odds with each other. Let's see how unhappy users are after we merge the dialog and download waits (bug 652896) and reduce the delay to 1 second (bug 416605).
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.