Jetpack/Roadmap/2013: Difference between revisions
Canuckistani (talk | contribs) No edit summary |
Canuckistani (talk | contribs) No edit summary |
||
| Line 37: | Line 37: | ||
# Land SDK APIs in Firefox | # Land SDK APIs in Firefox | ||
# [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. | 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. | 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. | ||
| Line 48: | Line 48: | ||
===P1 APIs=== | ===P1 APIs=== | ||
# Places API | |||
The Places API will allow developers access to the bookmarks menu, bookmarks tool, and possibly more. This needs more scope. | 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. | 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. | ||
| Line 58: | Line 58: | ||
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. | 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. | 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] | |||
The crypto API will give SDK developers simple key/pair functionality to sign and verify data. | The crypto API will give SDK developers simple key/pair functionality to sign and verify data. | ||
| Line 68: | Line 68: | ||
= Secondary Priorities = | = Secondary Priorities = | ||
# ??? | |||
== P3 APIs == | |||
# ??? | |||
= Persistant Goals = | = Persistant Goals = | ||
Revision as of 04:29, 31 October 2012
 |
Jetpack 2013 Roadmap | |
| Owner: Jeff Griffiths | Updated: 2012-10-31 | |
| The Roadmap for Jetpack in 2013. | ||
|
THIS PAGE IS A WORKING DRAFT | 
|
| 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
If you look at the 2012 roadmap, there are a number of hits and misses, and some of the misses are copied into this document because we believe they are still valid ideas for the product. The main hits are:
- mobile support is nearly complete
- simple-prefs landed
- major enhancements to page-mod
- vastly improved memory usage and greatly reduced performance issues
- broader adoption of Jetpack ( 1000+ add-ons on AMO and climbing )
- SDK re-architecture
The Roadmap
Re-architecture
Stabilization
Division of assets
In 2012 we worked hard towards two notable goals: cfx in JS & landing the SDK apis in Firefox. Now that these goals are a reality,
Top Priorities
- Land SDK APIs in Firefox
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.
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.
P1 APIs
- Places API
The Places API will allow developers access to the bookmarks menu, bookmarks tool, and possibly more. This needs more scope.
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.
The crypto API will give SDK developers simple key/pair functionality to sign and verify data.
Secondary Priorities
- ???
P3 APIs
- ???
Persistant 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.