Jetpack/Roadmap/2013: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
 
(18 intermediate revisions by 2 users not shown)
Line 6: Line 6:
|pagetitle=Jetpack 2013 Roadmap
|pagetitle=Jetpack 2013 Roadmap
|owner=Jeff Griffiths
|owner=Jeff Griffiths
|updated=Oct 2012
|updated=Dec 2012
|status=Draft
|status=Draft
|description=The Roadmap for Jetpack in 2013.}}<section end=summary />
|description=The Roadmap for Jetpack in 2013.}}<section end=summary />
Line 45: Line 45:
=== Top Priorities ===
=== Top Priorities ===


# [https://github.com/mozilla/addon-sdk/wiki/JEP-SDK-in-Firefox Land SDK APIs in Firefox]
These are the top priorities for the team in 2013.  
# [https://wiki.mozilla.org/Features/Jetpack/Jetpack-Move-Widgets-to-top Move Add-ons to top of browser]. For a while we have talked about moving the widgets and panels the SDK provides to the top of the browser and away from the small add-on bar at the bar. The UX team agrees with this move and has given us some guidance to go ahead and make this move.
# [https://wiki.mozilla.org/Features/Jetpack/Add-on_SDK_as_an_Addon Add-on SDK as an Add-on] We currently ship the Add-on SDK as a zip file or source code through github. This may not be the best way for us to distribute the SDK. First, we have a built-in automated update mechanism with AMO which also provides support for stable and beta distribution channels. Second, if we can get the SDK to package itself we have a chance for SDK developers to "eat their own dogfood" - testing the packaging and perfomance everyday. Finally, possibly building upon the original prototype as well as Alexandre Poirot's work of porting the SDK to an add-on we can start to offload some of the Builder's time-consuming functions to the client while also avoiding difficult dependencies for Add-on SDK users.
# Developer Tools extensibility. In 2012 there has been a steady trickle of add-ons & experiments around extending the Firefox developer tools ( [http://vimeo.com/39627655 LiveScratchpad], [https://github.com/Gozala/scratch-kit/ Scratch Kit], [http://paulrouget.com/e/jsterm/ JSTerm], [https://wiki.mozilla.org/DevTools/Features/GCLI GCLI], etc ). As well, some of the greatest leaps forward for Firefox in popularity in particular with web developers centered around the ability to extend the platform and create developer tools. This project will see the Jetpack team working closely with the Developer Tools team to make it very easy to extend Firefox's developer tools to fit very specific developer needs.


== SDK API Development ==
''Note: As this is a living document, when these priorities change we will update here.''


=== P1 APIs ===
* <del>[https://github.com/mozilla/addon-sdk/wiki/JEP-SDK-in-Firefox Land the SDK's apis in Firefox]</del>
* <del>support per-window private browsing in Firefox 20 ( see [https://bugzilla.mozilla.org/show_bug.cgi?id=748604 bug 748604]  )</del>
* <del>Ensure Builder works for add-on developers in the medium term.</del>
* Awesome Developer tools for add-on developers (for example: debugging)
** [https://bugzilla.mozilla.org/show_bug.cgi?id=899054 Tracking bug]
* Rapid development of Firefox features as add-ons
* UX Work: [Features/Jetpack/Addons_In_Toolbar|Widgets on top] [https://bugzilla.mozilla.org/show_bug.cgi?id=695913 Tracking bug].


What's really important?
== SDK API Development ==
 
=== P2 APIs ===
 
What's a nice to have? What would we like to see from the community?
 
=== APIs from 2012 ===
 
# Places API
 
The Places API will allow developers access to the bookmarks menu, bookmarks tool, and possibly more. This needs more scope.
 
# [https://wiki.mozilla.org/Features/Jetpack/Jetpack-Chrome-mods Chrome-mods]
 
Firefox has always presented itself to developers as a browser that allows customization. While this can often be painful from the point of view of user experience, it also provides great power in extensibility and innovation. Jetpack has always embraced the idea of modification and extension but only for shallow integrators where we felt some responsibility to help direct better user experience guidelines through offering only elements that would lend themseleves to that better experience. While that does a great deal to help keep the experience clean, it also frustrates those who want to integrate more deeply into the browser. With a new focus on Deep Integrators we want to take the modification idea to Firefox Chrome (user interface) in a similar manner in which we answered the modification question with web pages.
 
Chrome mods will allow the developer to easily alter Firefox chrome in a manner that is very similar to page-mods with the exception that the chrome being altered must first be properly identified before the developer can alter that element.
 
# Simpler Ctype API
 
The initial scope of this is to add a utility that will help add-on developers who are working with binaries to be able to automatically scope their binary and include the proper headers, instantly, to their add-on. There may be greater scope once this is complete. In addition, we need to document how binaries can be used with the SDK.


# [https://wiki.mozilla.org/AddonSDKCryptoAPI Crypto API]
When we provide a new high-level api in the SDK, that api must provide a clear benefit to the add-on develop in terms of ease of use while still not impacting Firefox performance.


The crypto API will give SDK developers simple key/pair functionality to sign and verify data.
# <del>Places API. [DONE] [https://bugzilla.mozilla.org/show_bug.cgi?id=545700 Tracking Bug] Bookmarks and history are probably the most interesting stores of data in Firefox and in particular the most interesting to users. Providing performant and usable apis to access this data easily could enable all manner of browser / user innovations.</del>
# Awesomebar API. The awesomebar is *the* primary piece of browser UI, used more than anything else. As experiments like Bryan Clarke's [https://github.com/clarkbw/searchspot/tree/awesomebar searchspot add-on] have shown us, it can be very powerful to inject custom results into the awesomebar.


= Persistant Goals =
= Persistent Goals =


There are goals we shall strive to achieve in the Jetpack project that
There are goals we shall strive to achieve in the Jetpack project that

Latest revision as of 17:11, 29 July 2013


Jetpackicon.png Jetpack 2013 Roadmap
Owner: Jeff Griffiths Updated: 2013-07-29
The Roadmap for Jetpack in 2013.
Draft-template-image.png THIS PAGE IS A WORKING DRAFT Pencil-emoji U270F-gray.png
The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly.
If you have any questions or ideas, please add them as a new topic on the discussion page.

2013 Jetpack Roadmap

The State of Jetpack

By any measure, 2012 was a great year for Jetpack. We saw increasing adoption of Jetpack with 1000+ add-ons on AMO and climbing, and several SDK-based add-ons gathering thousands and in one case millions of users. We also saw major partners such as Yahoo, Springpad and 1Password ship SDK-based add-ons successfully. We grew the team and the contributor base somewhat, and we also delivered on all of our releases on time.

If you look at the 2012 roadmap, there are a number of hits and misses, and some of the misses are copied forward into the 2013 Roadmap because we believe they are still valid ideas for the product. It is also worth looking at the hits, as some of the 2012 achievments directly inform our direction in 2013.

Needed Enhancements

  • localization support.
  • mobile support is nearly complete.
  • simple-prefs.
  • major enhancements to page-mod.

Re-architecture

  • re-organization of the SDK tree to better fit with the Firefox codebase.
  • the CommonJS loader and Promise module shipped with Firefox 16.
  • numerous improvements and additions to the low-level implementation of the SDK in particular to improve the extensibility of the SDK's apis.
  • re-implementation of the cfx tool's packaging functionality in JS.

Stabilization

  • we worked closely with the Memshrink project to significantly improve memory usage and performance issues.
  • we responded quickly to bugs in release versions with point releases.

The Roadmap

In 2012 we worked hard towards two notable goals: cfx in JS & landing the SDK apis in Firefox. These goals are long-term and we expect to reap the benefits in 2013 by removing the complexity and friction involved in developing with the SDK on the desktop, and also reducing the complexity of the Add-on Builder web application.

Top Priorities

These are the top priorities for the team in 2013.

Note: As this is a living document, when these priorities change we will update here.

  • Land the SDK's apis in Firefox
  • support per-window private browsing in Firefox 20 ( see bug 748604 )
  • Ensure Builder works for add-on developers in the medium term.
  • Awesome Developer tools for add-on developers (for example: debugging)
  • Rapid development of Firefox features as add-ons
  • UX Work: [Features/Jetpack/Addons_In_Toolbar|Widgets on top] Tracking bug.

SDK API Development

When we provide a new high-level api in the SDK, that api must provide a clear benefit to the add-on develop in terms of ease of use while still not impacting Firefox performance.

  1. Places API. [DONE] Tracking Bug Bookmarks and history are probably the most interesting stores of data in Firefox and in particular the most interesting to users. Providing performant and usable apis to access this data easily could enable all manner of browser / user innovations.
  2. Awesomebar API. The awesomebar is *the* primary piece of browser UI, used more than anything else. As experiments like Bryan Clarke's searchspot add-on have shown us, it can be very powerful to inject custom results into the awesomebar.

Persistent Goals

There are goals we shall strive to achieve in the Jetpack project that may or may not be explicitly written in this Roadmap or in our Quarterly goals. However, these things will always be goals for the project and any products which we create:

Performance

We must always measure our preformance and be thoughtful of how the Add-on SDK affects the performance of Firefox.

Footprint

We should try to make sure that everything we create is as small as it can be while still providing the functionality we think is necessary.

Security

We must ensure the security of all our users and make sure that we are consistently reviewing, with the help of security experts, our code to be as secure as we can make it.

Simplicity

We should strive to provide the simplest structure to our APIs and tools to make sure the Jetpack experience is easy to use. In addition we should keep the codebase clean and simple to ease and encourage contributions.

Memory Consumption

We should strive to keep memory consumption of an add-on built with our high-level APIs as small as possible.

Stability

We will strive to make the Add-on SDK as stable as possible and respond to issues as quickly as possible to make sure that users can trust the SDK for their development.

Goals

2013 Goals By Quarter

Archive

2011 Roadmap 2012 Roadmap

Retrieved from "https://wiki.allizom.org/index.php?title=Jetpack/Roadmap/2013&oldid=686821"