Labs/Ubiquity/0.2 Design: UI and Security Extensibility: Difference between revisions
(Framed UI extensibility in terms of the architectural diagram) |
(Added explanation of feed plugins) |
||
| Line 41: | Line 41: | ||
The main idea here is to decouple Ubiquity's user interface from its implementation so that it's easier to experiment with more secure implementations. Another benefit of this is that it'll be easier to unify Ubiquity's UI with other pre-existing forms of web extensibility, like Bookmarklets and Greasemonkey scripts. | The main idea here is to decouple Ubiquity's user interface from its implementation so that it's easier to experiment with more secure implementations. Another benefit of this is that it'll be easier to unify Ubiquity's UI with other pre-existing forms of web extensibility, like Bookmarklets and Greasemonkey scripts. | ||
In Ubiquity 0.1, command authors create a command feed by inserting an tag of the following form in the <tt><nowiki><HEAD></nowiki></tt> element of an HTML document: | |||
<tt><nowiki><LINK REL="commands" HREF="my_commands.js" TYPE="application/x-javascript" /></nowiki></tt> | |||
In Ubiquity 0.2, the values of the <tt>REL</tt> and <tt>TYPE</tt> attributes will be used to locate an appropriate '''Feed Plugin''' for the feed. Once found, the Feed Plugin will serve the following roles: | |||
* The Feed Plugin will control the user experience from the moment they click the "Subscribe..." button in the notification box to subscribe to the feed, presenting any necessary information the user may need to know before subscribing (e.g., security warnings). It will also be responsible for communicating with the Feed Manager to actually subscribe to the feed, since it's possible that the user may ultimately choose not to subscribe. | |||
* The Feed Plugin will be responsible for actually loading the feed and providing its functionality—generally in the form of commands and pageload functions—to Ubiquity using well-defined interfaces. | |||
Revision as of 19:39, 16 December 2008
Introduction
As per the first Ubiquity planning meeting, our goals for 0.2 are to:
- make Ubiquity easier for experimental new UIs to leverage, and
- make Ubiquity more secure.
The implementation of (1) will involve providing a well-documented API for external UIs to plug into. The implementation of (2) will involve providing a "feed plugin" mechanism through which new types of Ubiquity feeds can be created that use entirely different security models than Ubiquity's default.
Both of these solutions invite community members to create and implement new ideas to further the conversation about using the browser to connect web services together in a safe, humane way.
Before reading the rest of this document, it may be helpful for readers to understand the Ubiquity 0.1.3 Architecture.
Proposed Architecture
Below is the proposed architectural diagram for 0.2. Its individual parts are explained in the following sections of this document.
UI Extensibility
All UI components will interact with the UI Manager depicted in the proposed architectural diagram, which essentially serves as a facade to Ubiquity's functionality.
Given a selection, clients of the UI Manager should be able to:
- Determine what commands are apropos to operate on it. For instance, if I select a street address, one of the first commands that it matches should be "map".
- Implementation note: Look at the CommandManager's noun-first-suggestions code.
- Get a list of all commands that can apply to the selection.
- Implementation note: Look at CommandSource's method to get all commands.
Given a command, clients of the UI Manager should be able to:
- Figure out what objects the command takes.
- Implementation note: Once we unify Verbs and Commands, this will be trivial.
- Call the command.
- Implementation note: see above.
Security Extensibility
The main idea here is to decouple Ubiquity's user interface from its implementation so that it's easier to experiment with more secure implementations. Another benefit of this is that it'll be easier to unify Ubiquity's UI with other pre-existing forms of web extensibility, like Bookmarklets and Greasemonkey scripts.
In Ubiquity 0.1, command authors create a command feed by inserting an tag of the following form in the <HEAD> element of an HTML document:
<LINK REL="commands" HREF="my_commands.js" TYPE="application/x-javascript" />
In Ubiquity 0.2, the values of the REL and TYPE attributes will be used to locate an appropriate Feed Plugin for the feed. Once found, the Feed Plugin will serve the following roles:
- The Feed Plugin will control the user experience from the moment they click the "Subscribe..." button in the notification box to subscribe to the feed, presenting any necessary information the user may need to know before subscribing (e.g., security warnings). It will also be responsible for communicating with the Feed Manager to actually subscribe to the feed, since it's possible that the user may ultimately choose not to subscribe.
- The Feed Plugin will be responsible for actually loading the feed and providing its functionality—generally in the form of commands and pageload functions—to Ubiquity using well-defined interfaces.