1153226 - optimize add-on installation flow for quick interaction

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect, P1)

Description

[Markus Jaritz [:designakt] (UX)]

Currently add-on install is initiated by the user. This starts the download that can last an undefined amount of time. Only after that is finished the user can confirm that they truly want to install the add-on.
Can we optimize the process to only need one interaction for the optimum case?
(as suggested here https://bugzilla.mozilla.org/show_bug.cgi?id=1120996#c36)

e.g. click install and everything is done in the background, unless some problems arise.

Comment 1

[Markus Jaritz [:designakt] (UX)]

Attachment: 150413_Add-on-Process-Vision.gif

Can such a streamlined install process be as simple as shown?
What would it take to make it as simple? 
Only for certified add-ons of course.

Comment 2

[Andy McKay]

By certified, do you mean signed?

Comment 3

[Markus Jaritz [:designakt] (UX)]

Yes. That is what I meant.

Comment 4

[Markus Jaritz [:designakt] (UX)]

Dave, I have been talking to Andy today about improving the install flow for WebExtensions. I remember a conversation we had a view month back where you mentioned that having such a shortened install-process as suggested here would require some different behavior in how the add-on is sent to the browser, or some separation of manifest and add-on... 
Andy and I would love to optimize the install flow for WebExtension, but we are currently unclear on what the best next steps would be to move towards such a simplified install-process. Could you please help us break down this work. Thanks.

Comment 5

[Dave Townsend [:mossop]]

(In reply to Markus Jaritz [:maritz] (UX) from comment #4)
> Dave, I have been talking to Andy today about improving the install flow for
> WebExtensions. I remember a conversation we had a view month back where you
> mentioned that having such a shortened install-process as suggested here
> would require some different behavior in how the add-on is sent to the
> browser, or some separation of manifest and add-on... 
> Andy and I would love to optimize the install flow for WebExtension, but we
> are currently unclear on what the best next steps would be to move towards
> such a simplified install-process. Could you please help us break down this
> work. Thanks.

Currently we have to download the entire file before we can know what kind of add-on it is. To avoid that we would probably need to add to the existing JS API that webpages can use to install add-ons to include whatever information you need. I'm not sure why that would be needed though, what about the new install process would be different between web extensions and old-style extensions?

Comment 6

[Markus Jaritz [:designakt] (UX)]

(In reply to Dave Townsend [:mossop] from comment #5)
> what about the new install process would be different between web extensions 
> and old-style extensions?

If we can optimize the flow for all extensions, it would even be better. I mentioned WebExtensions because they are currently in the making, which made me hope that changes there might be easier.

Andy, did that feedback help. I have no understanding of what such changes to the JS API would be.

Comment 7

[Markus Jaritz [:designakt] (UX)]

Looks like a somewhat similar request has been made years ago. For reference: bug 652896

Comment 8

[Andy McKay]

If this is only for signed add-ons, we'd need to know if the add-on is signed before we start the download and install process. For that we'd need to have some way of signalling that an add-on is signed up to Firefox before we start.

Markus I think what might help here is a flow chart of the non-happy use cases. Some of the things that I can think of are:
* what happens when an add-on claims its signed but isn't?
* what happens to unsigned add-ons?
* what happens if an add-on is not on AMO?
* would this change on the add-on type, for example with a legacy XUL base add-on or web extensions?
* would we want to do anything if the add-on is large (this can affect mobile for example)

I think once we've got a clear flow of the proposition, we can come up with the kind of data we'd like to have in a manifest (assuming we need one) and what sites other than AMO would have to do.

The happy path of removing the install dialog and showing the notification is completely cool for me in the ideal situation. We should just clarify what that is.

Comment 9

[Andy McKay]

This bug was added to the discovery pane tracker because I believe this is part of the UX for the improved discovery flow. For that flow its really only talking about the flow for *addons.mozilla.org* only, there are other bugs for other sites. I think the key changes could be something as simple as:

* If the install starts from addons.mozilla.org, remove the "This site would like to install an add-on: Cancel / Install" dialog, the point being that the request and intent had already been made.
* Change the message after install to instead point to a button added to the toolbar, if one exists and the add-on is restartless.

Those two changes would make the install flow require no user interaction, but would still provide them feedback. 

If anything goes wrong in the install flow, such as the addon can't be downloaded, isn't signed or the stars just are aligned wrong, we'll default to the usual error messages.

Would that work?

Comment 10

[Markus Jaritz [:designakt] (UX)]

Sounds good.
One thing I miss in your summary is the state of the button - indicating if the add-on is already installed or not.

We will also need to define the details of the confirmation message. I do not think we can use the existing one for that.

And for all other messages we need to define where to anchor them to. Themes and buttonless add-ons could be anchored from the menu-button.

pwalm will map out those flows in more detail this week.
(building this for all of AMO instead of only for our set of discovery add-ons broadens the scope somewhat, as all discovery add-ons are restartless and have a button in the toolbar, which omits some edge cases.)

Comment 11

[:shell escalante]

Notes from security discussion.....
UX: https://invis.io/BX69Y1HAC & https://docs.google.com/document/d/1w_PqkIEk-36dyGBBPO_QaHJeL9-I1Oo1-QwcBHOew9s/edit# Under the "Mar 1st" header

Went through security review - main concerns:
~make sure not embedded in another site to not worry about click-jacking.  though we are embedded into oursite - so need to make sure we're using the xframes.
~Only applies for Reviewed add-ons - would need flag to non-reviewed to add extra prompts.  discovery page not an issue - but on AMO there are both types… so how to handle… P2.5 Error if non-reviewed shows up on Discovery page
~if someone navigated to zippy from AMO - need UI from site coming from rather than UI from site serving from. (could make sure doing through javascript API
~make sure web sites use SRI, CSP, and any other secure functions

Comment 12

[Andy McKay]

The APIs are exposed up to the disco pane and AMO, I think this is done.