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)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.9beta3

People

(Reporter: madhava, Assigned: mossop)

References

Details

Attachments

(3 files, 5 obsolete files)

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.
Attached patch wip (obsolete) — Splinter Review
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"?
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.
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.
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.
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.
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".
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.
Attached image 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?
Assignee: nobody → dtownsend
Attachment #293713 - Attachment is obsolete: true
Status: NEW → ASSIGNED
(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?
> 

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
Summary: Make the countdown-timer warning dialog easier to understand → Make the extension installation dialog easier to understand
Attached patch patch rev 1 (obsolete) — Splinter Review
This is the final patch, checked on all 3 platforms and Madhava has confirmed the look.
Attachment #297181 - Flags: review?(mano)
Whiteboard: [has patch]
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-
Blocks: 386757
Attached patch patch rev 2 (obsolete) — Splinter Review
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)
We should probably make the dialog width localizable.
Attached patch patch rev 3 (obsolete) — Splinter Review
(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)
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.
Attached patch patch rev 4 (obsolete) — Splinter Review
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)
No longer blocks: 386757
Comment on attachment 297603 [details] [diff] [review]
patch rev 4

s/0px/0/

r=mano.
Attachment #297603 - Flags: review?(mano) → review+
Attached patch patch rev 5Splinter Review
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?
Attachment #297612 - Flags: approval1.9? → approval1.9+
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 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.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: