Confirmed users
764
edits
Labs/Jetpack/JEP/14: Difference between revisions
Jump to navigation
Jump to search
→Proposal: Tightened wording in intro
(→Proposal: Tightened wording in intro) |
|||
| Line 19: | Line 19: | ||
=== Proposal === | === Proposal === | ||
Browser add-ons create two kinds of tensions. There is a tension between the add-on developer and the add-on user. Each has her own interests, and the two conflict. The developer wants unfettered access to the browser to do interesting things, but the user has privacy concerns, wants her browser to be small and speedy, and so on. There is also a tension between usefulness and usability. An add-on with twenty useful features is not so useful if those features are exposed in a poor way. A bad add-on experience can color a user's perception of Firefox itself, especially if she is a novice, and over time she may even forget which functionality is provided by the browser and which by add-ons. | Browser add-ons create two kinds of tensions. There is a tension between the add-on developer and the add-on user. Each has her own interests, and the two conflict. The developer wants unfettered access to the browser to do interesting things, but the user has privacy concerns, wants her browser to be small and speedy, and so on. There is also a tension between usefulness and usability. An add-on with twenty useful features is not so useful if those features are exposed in a poor way, and the more features, the more challenging it is to expose them all in a usable manner. A bad add-on experience can color a user's perception of Firefox itself, especially if she is a novice, and over time she may even forget which functionality is provided by the browser and which by add-ons. | ||
Menus are a good example of how these tensions are exposed. Should Jetpack allow developers to modify any menu within Firefox? Only certain menus? Should Jetpack features be quarantined to submenus? Should it be clear that Jetpack menus are not part of the standard browser | Menus are a good example of how these tensions are exposed. Should Jetpack allow developers to modify any menu within Firefox? Only certain menus? Should Jetpack features be quarantined to submenus? Should it be clear that Jetpack menus are not part of the standard browser? Should Jetpack provide preferences that default to something reasonable but give the user ultimate control? | ||
Given that Jetpack is a prototype and that one of its goals is to maximize developer generativity, this | Given that Jetpack is a prototype and that one of its goals is to maximize developer generativity, this proposal errs on the sides of the developer and usefulness while aiming to make the right things to do the easy things to do. We'll let the Firefox team worry about these questions if and when Jetpack is uplifted. | ||
The menu API lives at <code>jetpack.menu</code>. It provides access to all the menus of the browser's menubar and context menus. | The menu API lives at <code>jetpack.menu</code>. It provides access to all the menus of the browser's menubar and context menus. | ||