Mobile/BostonBrainstorm/Add-Ons
From MozillaWiki
< Mobile | BostonBrainstorm
Contents
Do add-ons drive ADI growth?
- Popular add-ons drive adoption, because people will choose a browser that supports add-ons that they know and love from their desktop browser.
- Add-ons improve user retention, because they let people customize their browser in ways that aren't possible on other browsers.
Increase the number of add-ons
- Finish porting Jetpack to Android Firefox
- This will make it very easy for new add-ons to support both mobile and desktop.
- We should prioritize; we can stub out less-needed APIs for a first release.
- Tools to develop on desktop (using the Add-on Builder?), run on mobile.
- Jetpack team has already done some work on this.
- Improve documentation.
- Need more complete docs, tutorials.
- More examples.
- Remove outdated docs.
- Donate Android devices to add-on developers.
- and/or make emulation easier/faster (Android/x86 builds?)
- Evangelize/support/contribute to ports of more high-profile add-ons.
- But note that the best desktop add-ons may not be the best mobile add-ons.
New capabilities and APIs
- Define UI customization designs and APIs.
- Should play well with Jetpack and Australis.
- Allow add-ons to include Java code?
- Deliver add-ons through the Google Play app store?
- Touch/gesture APIs.
Increase discoverability and user adoption
- Add "also on mobile!" cross-promotion to desktop AMO page when an add-on has a mobile version.
- Over-the-air installation from desktop web site to phone.
- Better "install add-ons" call to action in the first-run UX (e.g. about:home).
- Bundle some add-ons (disabled by default?)
- Create our own, or use popular add-ons.
- Make features like Reading Mode into add-ons and ship them that way?
- Good for dogfooding our APIs, also for teaching users about using add-ons.
- Make AMO link in Add-on Manager more discoverable (add a text label to the icon?)
- Make the "empty" Add-on Manager UX better (when no extensions are installed).