optimize add-on installation flow for quick interaction

RESOLVED FIXED

Status

()

Toolkit
Add-ons Manager
P1
normal
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: designakt, Unassigned)

Tracking

(Depends on: 3 bugs, Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [webextension], URL)

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
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.
(Reporter)

Comment 1

3 years ago
Created attachment 8591672 [details]
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.
(Reporter)

Updated

2 years ago
Depends on: 1187961

Comment 2

2 years ago
By certified, do you mean signed?
(Reporter)

Comment 3

2 years ago
Yes. That is what I meant.
(Reporter)

Updated

2 years ago
OS: Mac OS X → Unspecified
Hardware: x86 → Unspecified
Summary: [UX] optimize add-on installation flow for quick interaction → optimize add-on installation flow for quick interaction
(Reporter)

Comment 4

2 years ago
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.
Flags: needinfo?(dtownsend)
Whiteboard: [webextension]
(Reporter)

Updated

2 years ago
See Also: → bug 1229230
(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?
Flags: needinfo?(dtownsend)
(Reporter)

Comment 6

2 years ago
(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.
Flags: needinfo?(amckay)
(Reporter)

Comment 7

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

Updated

2 years ago
Depends on: 1232664
See Also: → bug 652896

Comment 8

2 years ago
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.
Flags: needinfo?(amckay)

Updated

2 years ago
Component: General → Add-ons Manager
Product: Firefox → Toolkit
(Reporter)

Updated

2 years ago
Depends on: 1153303

Updated

2 years ago
Blocks: 1245993

Updated

2 years ago
Priority: -- → P1

Comment 9

2 years ago
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?
Flags: needinfo?(mjaritz)
(Reporter)

Comment 10

2 years ago
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.)
Flags: needinfo?(mjaritz) → needinfo?(pwalmsley)

Updated

2 years ago
Depends on: 1252478

Comment 11

2 years ago
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

Updated

2 years ago
Blocks: 1252975

Updated

2 years ago
Flags: needinfo?(pwalmsley)

Comment 12

2 years ago
The APIs are exposed up to the disco pane and AMO, I think this is done.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.