Closed
Bug 408869
Opened 17 years ago
Closed 17 years ago
Make the extension installation dialog easier to understand
Categories
(Core Graveyard :: Installer: XPInstall Engine, enhancement)
Core Graveyard
Installer: XPInstall Engine
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.9beta3
People
(Reporter: madhava, Assigned: mossop)
References
Details
Attachments
(3 files, 5 obsolete files)
47.65 KB,
image/png
|
Details | |
162.94 KB,
image/png
|
Details | |
10.02 KB,
patch
|
mossop
:
review+
mtschrep
:
approval1.9+
|
Details | Diff | Splinter Review |
Mockup and notes:
http://wiki.mozilla.org/Firefox:Add-ons_Manager_UI#Scary_Confirmation
The redesign is an attempt to do the following:
- remove redundant and confusing messages from the dialog
- elevate the warning, rather than the list of add-ons, to primacy in the dialog. The point of the dialog, after all, is the warning -- the list of add-ons is just to give some context for the warning
- make the "Signed" or "Unsigned" status, currently expressed in those terms and red lettering, something that is more user-understandable.
Comment 1•17 years ago
|
||
Comment 2•17 years ago
|
||
In the mockup, "Install add-ons only from sources you trust" looks like a title, not a warning. In the current dialog, it's just bold (not huge) and near the bottom, where I think it's more likely to catch users' attention.
Any particular reason you removed "Malicious software can damage your computer or violate your privacy"?
Comment 3•17 years ago
|
||
In the current dialog "Unsigned" is in red to scare people. you have absolutely no clue who wrote this thing, and neither does anyone else.
Didn't work, practically no one bothers to sign theirs anyway. At least we managed to substitute hashes to regain some of the "tamper-evident wrapper" aspects of signing, but that only works on AMO when the files are served by the AMO server. Signing is a property of the package itself regardless of where it's copied to. Then again, having something signed by some random person you've never heard of isn't worth a whole lot, but at least you know the package is as they intended it to be.
The signer's name alone really isn't that great, the ultimate goal was to provide a way to look at the certificate itself (by making the name a link?) so you can see who they are and who's vouching for it.
Comment 4•17 years ago
|
||
For SSL Larry uses the terms "Location Verified" and "Identity Unknown" (I think I would have preferred 'unverified'). Would it be better to use "unverified" to echo the identity messaging?
Can we say "Author" rather than "Source"? people are going to think of the website where they got it as the "source" and that's not what the signature on an install package asserts.
So "(Author Unknown)" or "(Author unverified)" would get my vote. In this context I prefer unknown, I'd only suggest 'unverified' to match Larry if we changed the Larry wording.
Assignee | ||
Comment 5•17 years ago
|
||
I agree that we need to keep the warning about malicious software, I've seen at least a few people shocked when I suggested that extensions could be harmful if they wished and they asked why we didn't warn them about it. That line is what I usually have to point them to.
Maybe we change the title to something more title-like then have the real warning in bold underneath that?
Also tend to agree about using the same terms as Larry for consistency, and I don't see why on a known source the text couldn't be a link or something that pops up those more details.
I wonder if we also want to be highlighting the fact that the xpi is going to be checked against a hash in the unsigned case. It is some added assurance that the xpi is the one you chose from the website.
Reporter | ||
Comment 6•17 years ago
|
||
To respond to a couple of these comments...
Comment #2:
If they read anything on the dialog, users are going to tend to be drawn to the boldest (whether by size, contrast, or weight) text that's near the colourful graphic. In the case of the current dialog, that's the list of add-ons -- we want it, instead, to be a short statement of the decision they have to make: "Do you trust this?" Making the important text less central (lower down the dialog) and smaller means that fewer people will pay attention.
As for removing "Malicious software can damage your computer or violate your privacy" -- I've got nothing against it, really. The reason to remove it was just that, of everything on the dialog, it seems like the least actionable piece of information, and, in a dialog where everything is competing for the user's attention, everything inessential that we remove is a benefit.
That said, I'm certainly willing to believe that that statement may be more helpful in explaining to the user why they must make this decision than the "Add-ons have the same access..." Do you think that's the case?
Comment #3:
Agreed -- that's exactly why it's not red anymore. Given that so few add-ons are signed, the message is always red, and users habituate to it. On top of that, when it's always red, it doesn't really help anybody make a decision while still making them vaguely anxious.
Comment #4:
I agree with using "Author" rather than "Source" for the reason given. A lot of addons will be coming from AMO, which will make saying "Source Unknown" kind of odd. Oh, and "unknown" seems fine too - it's simpler than "unconfirmed," certainly.
Comment 7•17 years ago
|
||
Yes, I think "Malicious software can damage your computer or violate your privacy" is more helpful than "Add-ons have the same access to your computer as Firefox itself".
Reporter | ||
Comment 8•17 years ago
|
||
I'd be happy to have the subtitle be the "Malicious software can damage your computer or violate your privacy."
The main message should be "Only install add-ons from authors whom you trust." to stress author rather than source.
Assignee | ||
Comment 9•17 years ago
|
||
This is the current work in progress with the updated text suggested by Madhava. Unless there is any further discussion needed I can get this ready for review.
Just need to add the icon overlays on the puzzle icon, I presume it is warning symbol for unsigned and nothing for normal?
Assignee: nobody → dtownsend
Attachment #293713 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Reporter | ||
Comment 10•17 years ago
|
||
(In reply to comment #9)
Looking at this again, the little warning overlays are actually kind of redundant, given the large ones again. Even when the author is known, it doesn't mean we're recommending that that trust them, so having the overlays or not, on that basis, doesn't make much sense. I think we can dispense with them.
Generally, I think it's ready to go (assuming that the text over the list of add-ons pluralizes properly when appropriate).
I do have some minor spacing adjustments to recommened -- I'll attach a diagram with explanation.
> Created an attachment (id=296324) [details]
> current wip
>
> This is the current work in progress with the updated text suggested by
> Madhava. Unless there is any further discussion needed I can get this ready for
> review.
>
> Just need to add the icon overlays on the puzzle icon, I presume it is warning
> symbol for unsigned and nothing for normal?
>
Reporter | ||
Comment 11•17 years ago
|
||
The attachment outlines some layout/spacing adjustments. The letters in the graphic correspond to the following notes.
a - more space here
b - less space here
c - indent more
d - less space
e - less height
Updated•17 years ago
|
Summary: Make the countdown-timer warning dialog easier to understand → Make the extension installation dialog easier to understand
Assignee | ||
Comment 12•17 years ago
|
||
This is the final patch, checked on all 3 platforms and Madhava has confirmed the look.
Attachment #297181 -
Flags: review?(mano)
Assignee | ||
Updated•17 years ago
|
Whiteboard: [has patch]
Comment 13•17 years ago
|
||
Comment on attachment 297181 [details] [diff] [review]
patch rev 1
>@@ -77,7 +77,7 @@ XPInstallConfirm.init = function ()
> if (icon != "")
> installItem.icon = icon;
> var cert = this._param.GetString(++i);
>- installItem.cert = cert || bundle.getString("Unsigned");
>+ installItem.cert = "(" + (cert || bundle.getString("unsigned")) + ")";
The parentheses ought to live in the properties file.
>
>+.alert-icon {
>+ width: 48px;
>+ height: 48px;
>+ margin: 0px 20px 6px 6px !important;
Please use -moz-margin-start/end and margin-top/bottom. Why is !important needed?
>+ height: 14em;
>+}
>+
>+#itemWarningIntro {
>+ margin-left: 8px;
-moz-margin-start
>+ margin: 2px 5px 1px 6px;
..
>+#itemWarningIntro {
>+ margin-left: 8px;
> }
>
ditto, in the two other themes as well.
Attachment #297181 -
Flags: review?(mano) → review-
Assignee | ||
Comment 14•17 years ago
|
||
This address the margin and locale changes.
As for why !important is needed, this is splitting the alert-icon global styling out from its current definition which also has !important in its margin rule so I would prefer to leave this in place rather than potentially affect use of this elsewhere.
Note that the alert icon is changing this globally because it will fix bug 386757.
Attachment #297181 -
Attachment is obsolete: true
Attachment #297443 -
Flags: review?(mano)
Comment 15•17 years ago
|
||
We should probably make the dialog width localizable.
Assignee | ||
Comment 16•17 years ago
|
||
(In reply to comment #15)
> We should probably make the dialog width localizable.
Done
Attachment #297443 -
Attachment is obsolete: true
Attachment #297550 -
Flags: review?(mano)
Attachment #297443 -
Flags: review?(mano)
Comment 17•17 years ago
|
||
Now, the only problem is that we'll use this generic alert-icon in chrome alerts too, I'm pretty sure Alex didn't realize that when commenting on bug 386757.
Assignee | ||
Comment 18•17 years ago
|
||
Ok this drops the global style change for the alert icon and just adjusts it in the single dialog.
Attachment #297550 -
Attachment is obsolete: true
Attachment #297603 -
Flags: review?(mano)
Attachment #297550 -
Flags: review?(mano)
Comment 19•17 years ago
|
||
Comment on attachment 297603 [details] [diff] [review]
patch rev 4
s/0px/0/
r=mano.
Attachment #297603 -
Flags: review?(mano) → review+
Assignee | ||
Comment 20•17 years ago
|
||
Final patch for check in. Requesting approval, this is a change to the UI of the installation dialog only as requested by the UX team, the look has been checked on all 3 platforms.
Attachment #297603 -
Attachment is obsolete: true
Attachment #297612 -
Flags: review+
Attachment #297612 -
Flags: approval1.9?
Updated•17 years ago
|
Attachment #297612 -
Flags: approval1.9? → approval1.9+
Assignee | ||
Comment 21•17 years ago
|
||
Checking in toolkit/locales/en-US/chrome/mozapps/xpinstall/xpinstallConfirm.dtd;
/cvsroot/mozilla/toolkit/locales/en-US/chrome/mozapps/xpinstall/xpinstallConfirm.dtd,v <-- xpinstallConfirm.dtd
new revision: 1.3; previous revision: 1.2
done
Checking in toolkit/locales/en-US/chrome/mozapps/xpinstall/xpinstallConfirm.properties;
/cvsroot/mozilla/toolkit/locales/en-US/chrome/mozapps/xpinstall/xpinstallConfirm.properties,v <-- xpinstallConfirm.properties
new revision: 1.5; previous revision: 1.4
done
Checking in toolkit/mozapps/xpinstall/content/xpinstallConfirm.js;
/cvsroot/mozilla/toolkit/mozapps/xpinstall/content/xpinstallConfirm.js,v <-- xpinstallConfirm.js
new revision: 1.10; previous revision: 1.9
done
Checking in toolkit/mozapps/xpinstall/content/xpinstallConfirm.xul;
/cvsroot/mozilla/toolkit/mozapps/xpinstall/content/xpinstallConfirm.xul,v <-- xpinstallConfirm.xul
new revision: 1.4; previous revision: 1.3
done
Checking in toolkit/mozapps/xpinstall/content/xpinstallItem.xml;
/cvsroot/mozilla/toolkit/mozapps/xpinstall/content/xpinstallItem.xml,v <-- xpinstallItem.xml
new revision: 1.2; previous revision: 1.1
done
Checking in toolkit/themes/pinstripe/mozapps/xpinstall/xpinstallConfirm.css;
/cvsroot/mozilla/toolkit/themes/pinstripe/mozapps/xpinstall/xpinstallConfirm.css,v <-- xpinstallConfirm.css
new revision: 1.3; previous revision: 1.2
done
Checking in toolkit/themes/winstripe/mozapps/xpinstall/xpinstallConfirm.css;
/cvsroot/mozilla/toolkit/themes/winstripe/mozapps/xpinstall/xpinstallConfirm.css,v <-- xpinstallConfirm.css
new revision: 1.7; previous revision: 1.6
done
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: [has patch]
Target Milestone: --- → mozilla1.9 M11
Comment 22•17 years ago
|
||
Comment on attachment 297612 [details] [diff] [review]
patch rev 5
>+<!ENTITY dialog.style "width: 45em">
Hmm, we should specify widths of dialogs (and elements) in ch units, not em units, as em is relative to font height, and ch is the one relative to character widths, actually.
Updated•9 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•