Extension Manager:Projects:Improve Add-on Installation: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
(18 intermediate revisions by 7 users not shown)
Line 1: Line 1:
<section begin="status" />
{{FeatureStatus
|Feature name=Improve Add-on Installation
|Feature stage=Design
|Feature status=In progress
|Feature health=OK
|Feature status note=Finalizing plan for initial improvements in Firefox 7, beginning to scope out further research for future Firefox.
}}
{{FeatureTeam
|Feature product manager=Asa Dotzler
|Feature feature manager=Jennifer Boriss
|Feature security lead=Jesse Ruderman, Curtis Koenig
|Feature qa lead=Henrik Skupin
|Feature ux lead=Jennifer Boriss
}}
{{FeaturePageBody
|Feature open issues and risks=* How can different trust levels of add-ons can be both determined and messaged to users appropriately?
|Feature overview=The process of installing Firefox add-ons is currently fraught with user experience issues. The process involves differently-styled windows, unnecessary amounts of user interaction, and delays which users find confusing and annoying.


{| class="fullwidth-table"
Our goal is to make the process of installing add-ons more efficient and smoother while (at the least) not effecting and (at the best) improving security.  
|-
| style="font-weight: bold; background: #DDD;" | Feature
| style="font-weight: bold; background: #DDD;" | Status
| style="font-weight: bold; background: #DDD;" | ETA
| style="font-weight: bold; background: #DDD;" | Owner
|-
| [[Extension Manager:Projects:Improve Add-on Installation]]
| {{StatusHealthy|status=Finalizing plan for initial improvements in Firefox 6, beginning to scope out further research for future Firefox.}}
| 2011-05-19
| Jennifer Boriss
<section end="status" />
 
|}
 
== Summary  ==


The process of installing Firefox add-ons is currently fraught with user experience issues. The process involves differently-styled windows, unnecessary amounts of user interaction, and delays which users find confusing and annoying.  
This feature falls primarily in the '''Experience''' category (from the "Discover, Experience, and Connect" vision statement.)  
 
Our goal is to make the process of installing add-ons more efficient and smoother while (at the least) not effecting and (at the best) improving security.


While general improvements in efficiently and consistency are the goal, several specific issues fall under this category.  
While general improvements in efficiently and consistency are the goal, several specific issues fall under this category.  
Line 26: Line 25:
'''Priority 1:'''  
'''Priority 1:'''  


*Not switching windows styles during installation, and removing all modal dialogs. Currently, the verified add-on information confirmation notification is modal, while the download notification window at the beginning of the process and confirmation/restart notification at the end of the process are in the arrow panel notification style.&nbsp; All notifications should be moved into the arrow-panel notification style, with subtle animated resizes where needed.<br>
*Not switching windows styles during installation, and removing all modal dialogs. Currently, the verified add-on information confirmation notification is modal, while the download notification window at the beginning of the process and confirmation/restart notification at the end of the process are in the arrow panel notification style.&nbsp; All notifications should be moved into the arrow-panel notification style, with subtle animated resizes where needed.


<br>
[[Image:Modalvsnot123412.png|665x243px|Modalvsnot123412.png]]


<br>
*Reducing the timer wait time from 3 seconds to 1, and subtly fading the install button from disabled to active state rather than displaying a countdown
<center>[[Image:Modalvsnot123412.png|665x243px|Modalvsnot123412.png]]</center>
<br> <br>


*Reducing the timer wait time from 3 seconds to 1, and subtly fading the install button from disabled to active state rather than displaying a countdown<br>
[[Image:Timerdelay.png|656x332px|Timerdelay.png]]


<br>
*Not giving the implication that AMO and AMO's reviewed code are untrusted, specifically by:


<br>
1) Removing "author not verified" messaging for trusted authors
<center>[[Image:Timerdelay.png|656x332px|Timerdelay.png]] </center>
<br> <br>


*Not giving the implication that AMO and AMO's reviewed code are untrusted, specifically by: <br>
[[Image:Trusted messaging3242342342.png|648x84px|Trusted messaging3242342342.png]]


<br>
2) Messaging reviewed add-ons differently to unreviewed add-ons and relaying the different meaningfully to users


&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1. Removing "author not verified" messaging for trusted authors<br>
[[Image:Authornotverifiedfail234444.png|639x81px|Authornotverifiedfail234444.png]]


<br>
'''Priority 2''':


<br>
*Changing the installation flow order from download-then-ask-permission to ask-permission-then-download.&nbsp; We currently download an add-on's .xpi file before the user is asked permission to install it.&nbsp; While it's roughly understandable enough for users to navigate through, the order is backwards compared to the vast majority of similar installation flows. Installing a file before asking both flies in the face of user expectation, and gives the impression at first that we will be installing an add-on without asking permission at all. This may cause users to prematurely cancel an insatllation.&nbsp; If we can ask the user's permission first - even with imperfect add-on data - and then download the file, we'll be following a very well expected and utilized model.
<center>[[Image:Trusted messaging3242342342.png|648x84px|Trusted messaging3242342342.png]]<br> </center>
<br> <br>


&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2. Messaging reviewed add-ons differently to unreviewed add-ons and relaying the different meaningfully to users<br>
'''Download-then-ask-permission (current model)''':


<br>
[[Image:Backwards addon installation case.png|54x72px|Backwards addon installation case.png]]
<center>[[Image:Authornotverifiedfail234444.png|639x81px|Authornotverifiedfail234444.png]] </center>
'''Priority 2''':<br>


*Changing the installation flow order from download-then-ask-permission to ask-permission-then-download.&nbsp; We currently download an add-on's .xpi file before the user is asked permission to install it.&nbsp; While it's roughly understandable enough for users to navigate through, the order is backwards compared to the vast majority of similar installation flows. Installing a file before asking both flies in the face of user expectation, and gives the impression at first that we will be installing an add-on without asking permission at all. This may cause users to prematurely cancel an insatllation.&nbsp; If we can ask the user's permission first - even with imperfect add-on data - and then download the file, we'll be following a very well expected and utilized model.<br>
'''Ask-permission-then-download (goal)''':


<br>
[[Image:Not backwards addon case.png|45x76px|Not backwards addon case.png]]
|Feature users and use cases=*Installing human-reviewed add-ons from AMO
*Installing automated security review sandbox add-ons from AMO
*Installing add-ons not from AMO (default buyer beware)
*(possibly) Installing trusted add-ons not on AMO (e.g. AdblockPlus)
|Feature requirements=Several user experience improvements detailed in {{bug|646602}}.
|Feature ux design===== Ask permission, then download installation (ideal order)  ====


'''&nbsp;&nbsp;&nbsp; Download-then-ask-permission (current model)''':<br>
The diagram below shows how the add-on installation would feel if we were able to ask the user's permission, with whatever add-on information was available, before downloading the .xpi file. This is far more consistent with user's expectations of giving permission before the action that they gave permission for. Obviously the information we have at the beginning of a download may be imperfect, but we should show the best information we have available and only throw a flag if there is a problem. At least on AMO, the information we display should be correct.
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[[Image:Backwards addon installation case.png|54x72px|Backwards addon installation case.png]]<br>
'''&nbsp;&nbsp;&nbsp;&nbsp; Ask-permission-then-download (goal)''':<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[[Image:Not backwards addon case.png|45x76px|Not backwards addon case.png]]


== Team  ==
[[Image:Not backwards addon case.png|202x340px|Mockup]]


Who's working on this?
==== Download, then ask permission second installation (current but not ideal order) ====


*'''Feature Manager''': Jennifer Boriss
This is the order of our current add-on download installation. While it's roughly understandable enough for users to navigate through, the order is backwards compared to the vast majority of similar installation flows. Installing a file before asking both flies in the face of user expectation, and gives the impression at first that we will be installing an add-on without asking permission at all. This may cause users to prematurely cancel an instllation.
*'''Lead Developer''':
*'''Product Manager''':
*'''QA''': Henrik Skupin
*'''UX''': Jennifer Boriss
*'''Security''': Jesse Ruderman


== Release Requirements  ==
[[Image:Backwards addon installation case.png|218x289px|Mockup]]


Several user experience improvements detailed in {{bug|646602}}.
(also see {{bug|646602}})
 
|Feature security review=* [https://wiki.mozilla.org/Security/Reviews/Firefox6/ReviewNotes/AddOns Security Discussions/Reviews]
== Next Steps  ==
|Feature implementation notes=Likely:  
 
Review security issues involved in changes, find developers with free cycles for implementation<br>
 
== Open Issues  ==
 
- How can different trust levels of add-ons can be both determined and messaged to users appropriately?
 
== Related Bugs &amp; Dependencies  ==
 
Likely:  


*{{bug|416605}} - Reduce security dialog delay from 2 seconds  
*{{bug|416605}} - Reduce security dialog delay from 2 seconds  
Line 109: Line 88:
*{{bug|588266}} - <strike>Firefox add-on installation dialog should use doorhanger notification </strike>  
*{{bug|588266}} - <strike>Firefox add-on installation dialog should use doorhanger notification </strike>  
*{{bug|616100}} - <strike>Remove redundant install delay (undo fix for Bug 162020) [for non-AMO sites] </strike>
*{{bug|616100}} - <strike>Remove redundant install delay (undo fix for Bug 162020) [for non-AMO sites] </strike>
 
}}
== Security Discussion Notes  ==
{{FeatureInfo
 
|Feature priority=P2
*possible changes to add-on dialogs and their impact
|Feature roadmap=Add-ons
*goal improve add-on installation for users
|Feature list=Desktop
**lengthy steps seem in consistent to users, ex: countdown, and UI differences
|Feature engineering team=Desktop front-end
**perception on AMO that even AMO is not trusted even when add-on comes from Moz
}}
**implication is this should not be trusted even if linked to by trusted spaces.
{{FeatureTeamStatus
*streamline process, make easier, less clicks, possibly reduce or remove countdown
|Feature security health=OK
 
|Feature security notes=[[Security/Reviews/Firefox6/ReviewNotes/AddOns|Notes]]
Q: What are the risks entailed in installation and is AMO less risk than other sites?
}}
 
*Should be clear that AMO is a website that is part of the app, but what if AMO is hacked? Does this neccessarily help?
*If you go to AMO as a website then this is a preferred experience, like the bits in FX
**Desire: AMO having a different status
**Dialoge is needed as click-jacking is still prevalent/possible on AMO
**A site cannot frame the add-on tab, where as getting a click attack on AMO is somewhat trivial
 
*Need clear dialog for AMO sandbox
 
mockup: https://people.mozilla.com/%7Ejboriss/dump/flow_chart_for_addon_download2.pdf
 
suggestions:
 
*We could lower the delay from 2 noisy seconds to 1 quiet second
*We could show the user-intent-verification first, before the download finishes. Then there aren't 2 separate "waiting" steps as long as the download is fast<br>&nbsp;
**this would require AMO to supply the stuff that's supposed to appear in the dialog, as part of the installtrigger call, but it would make the UI much better.
*We could make it so any link to addons.mozilla.org opens in a new tab, and use browser-side defenses against clickjacking on that tab
*We could deny InstallTrigger if clicked within 1 second of selecting the tab/window, to make clickjacking AMO harder
*Rather than author information, which is never verified, could show AMO status
**(not on AMO; sandboxed; full review; old version)
**popularity
**average review score
 
Unresolved Questions:
 
*AMO warnings (slows down firefox? has privacy policy?)
 
== Designs  ==
 
=== '''Ask permission, then download installation (ideal order)'''<br>  ===
 
The diagram below shows how the add-on installation would feel if we were able to ask the user's permission, with whatever add-on information was available, before downloading the .xpi file. This is far more consistent with user's expectations of giving permission before the action that they gave permission for. Obviously the information we have at the beginning of a download may be imperfect, but we should show the best information we have available and only throw a flag if there is a problem. At least on AMO, the information we display should be correct.<br>
 
<br>
 
[[Image:Not backwards addon case.png|202x340px|Mockup]]
 
<br>
 
<br>
 
=== '''Download, then ask permission second installation (current but not ideal order)'''<br>  ===
 
This is the order of our current add-on download installation. While it's roughly understandable enough for users to navigate through, the order is backwards compared to the vast majority of similar installation flows. Installing a file before asking both flies in the face of user expectation, and gives the impression at first that we will be installing an add-on without asking permission at all. This may cause users to prematurely cancel an instllation.<br>
 
<br>
 
[[Image:Backwards addon installation case.png|218x289px|Mockup]]
 
<br> (also see {{bug|646602}})
 
== Use Cases  ==
 
*Installing human-reviewed add-ons from AMO
*Installing automated security review sandbox add-ons from AMO
*Installing add-ons not from AMO (default buyer beware)
*(possibly) Installing trusted add-ons not on AMO (e.g. AdblockPlus)
 
== Test Plans  ==
 
None so far.
 
== Goals  ==
 
Make add-on installation a more efficient, more consistent, and more secure experience
 
== Non-Goals  ==
 
__NOTOC__
 
<br>
 
[[Category:Features]] [[Category:Firefox]]

Latest revision as of 19:29, 1 February 2012

Please use "Edit with form" above to edit this page.

Status

Improve Add-on Installation
Stage Design
Status In progress
Release target `
Health OK
Status note Finalizing plan for initial improvements in Firefox 7, beginning to scope out further research for future Firefox.

Team

Product manager Asa Dotzler
Directly Responsible Individual Jennifer Boriss
Lead engineer `
Security lead Jesse Ruderman, Curtis Koenig
Privacy lead `
Localization lead `
Accessibility lead `
QA lead Henrik Skupin
UX lead Jennifer Boriss
Product marketing lead `
Operations lead `
Additional members `

Open issues/risks

  • How can different trust levels of add-ons can be both determined and messaged to users appropriately?

Stage 1: Definition

1. Feature overview

The process of installing Firefox add-ons is currently fraught with user experience issues. The process involves differently-styled windows, unnecessary amounts of user interaction, and delays which users find confusing and annoying.

Our goal is to make the process of installing add-ons more efficient and smoother while (at the least) not effecting and (at the best) improving security.

This feature falls primarily in the Experience category (from the "Discover, Experience, and Connect" vision statement.)

While general improvements in efficiently and consistency are the goal, several specific issues fall under this category.

Priority 1:

  • Not switching windows styles during installation, and removing all modal dialogs. Currently, the verified add-on information confirmation notification is modal, while the download notification window at the beginning of the process and confirmation/restart notification at the end of the process are in the arrow panel notification style.  All notifications should be moved into the arrow-panel notification style, with subtle animated resizes where needed.

Modalvsnot123412.png

  • Reducing the timer wait time from 3 seconds to 1, and subtly fading the install button from disabled to active state rather than displaying a countdown

Timerdelay.png

  • Not giving the implication that AMO and AMO's reviewed code are untrusted, specifically by:

1) Removing "author not verified" messaging for trusted authors

Trusted messaging3242342342.png

2) Messaging reviewed add-ons differently to unreviewed add-ons and relaying the different meaningfully to users

Authornotverifiedfail234444.png

Priority 2:

  • Changing the installation flow order from download-then-ask-permission to ask-permission-then-download.  We currently download an add-on's .xpi file before the user is asked permission to install it.  While it's roughly understandable enough for users to navigate through, the order is backwards compared to the vast majority of similar installation flows. Installing a file before asking both flies in the face of user expectation, and gives the impression at first that we will be installing an add-on without asking permission at all. This may cause users to prematurely cancel an insatllation.  If we can ask the user's permission first - even with imperfect add-on data - and then download the file, we'll be following a very well expected and utilized model.

Download-then-ask-permission (current model):

Backwards addon installation case.png

Ask-permission-then-download (goal):

Not backwards addon case.png

2. Users & use cases

  • Installing human-reviewed add-ons from AMO
  • Installing automated security review sandbox add-ons from AMO
  • Installing add-ons not from AMO (default buyer beware)
  • (possibly) Installing trusted add-ons not on AMO (e.g. AdblockPlus)

3. Dependencies

`

4. Requirements

Several user experience improvements detailed in bug 646602.

Non-goals

`

Stage 2: Design

5. Functional specification

`

6. User experience design

Ask permission, then download installation (ideal order)

The diagram below shows how the add-on installation would feel if we were able to ask the user's permission, with whatever add-on information was available, before downloading the .xpi file. This is far more consistent with user's expectations of giving permission before the action that they gave permission for. Obviously the information we have at the beginning of a download may be imperfect, but we should show the best information we have available and only throw a flag if there is a problem. At least on AMO, the information we display should be correct.

Mockup

Download, then ask permission second installation (current but not ideal order)

This is the order of our current add-on download installation. While it's roughly understandable enough for users to navigate through, the order is backwards compared to the vast majority of similar installation flows. Installing a file before asking both flies in the face of user expectation, and gives the impression at first that we will be installing an add-on without asking permission at all. This may cause users to prematurely cancel an instllation.

Mockup

(also see bug 646602)

Stage 3: Planning

7. Implementation plan

`

8. Reviews

Security review

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

Likely:

  • bug 416605 - Reduce security dialog delay from 2 seconds
  • bug 643020 - Implement the new install UI in the content area
  • bug 652896 - Allow AMO to show extension install dialog before downloading XPI

Possible:

  • bug 646602 - Installing add-ons from AMO should not invoke the security prompt

Wontfix:

  • bug 561177 - Remove countdown from add-on install dialog(wontfix - we're reducing, not removing, the delay)
  • bug 588266 - Firefox add-on installation dialog should use doorhanger notification
  • bug 616100 - Remove redundant install delay (undo fix for Bug 162020) [for non-AMO sites]

Stage 5: Release

10. Landing criteria

`


Feature details

Priority P2
Rank 999
Theme / Goal `
Roadmap Add-ons
Secondary roadmap `
Feature list Desktop
Project `
Engineering team Desktop front-end

Team status notes

  status notes
Products ` `
Engineering ` `
Security ` Notes
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance ` `
User experience ` `
Product marketing ` `
Operations ` `


Retrieved from "https://dev.wikimo.nonprod.webservices.mozgcp.net/index.php?title=Extension_Manager:Projects:Improve_Add-on_Installation&oldid=393071"