|
|
| Line 1: |
Line 1: |
| = Overview = | | = Overview = |
| When browsing the web, the user's primary interest is the requested content as rendered in the browser. There is often interesting content which is not directly rendered and which could be of interest to the user. In addition, the browser (or extensions) may wish to alert the user of changes in status of some user-requested action or monitor. | | ==User Problem== |
| | When browsing the web, the user's primary interest is to be able to consume the requested content as rendered by the browser. Sometimes a page can contain content (or links to content) that can not be displayed as images or text. This content may be interesting to the user, but it can be hard for them to get access to it. For example: |
| | * [http://microformats.org/about/ microformats] |
| | * microsummary definitions |
| | * links to multimedia files |
| | * documents |
| | * <link rel> tags that point to things like RSS files |
| | * things we can't predict |
|
| |
|
| Presently several extensions compete for space in the Status Bar in order to provide subtle indication of additional information. There is no way to manage these competing requests for space, leaving that task up to extension authors.
| | ==Solution: Notification Area Framework== |
| | A framework will be provided that provides a mechanism for creating an area used to notify the user when a certain type of content is detected in a page. This notification area will be interactive, allowing a user to instruct the browser to handle or process this content appropriately. |
|
| |
|
| = Use cases = | | = Sample Use Case = |
| 1. An extension adds icons, buttons, or other XUL widgets to the notification area. (ex: a theme switcher or a weather display widget)
| | A user has installed an extension that detects the hCard microsummary. When the user browses to a page with this type of content, an icon will appear with a tooltip that displays the number of hCard microsummaries found on the page. Clicking on the icon will import the resource and pass it to the system address book. |
|
| |
|
| * ''do we really need the notification area to handle this use-case? I put it in here since it's a common use of the status bar, but I'm not sure we want to support general XUL widgetry right in the API.'' [[User:Beltzner|Beltzner]]
| | Similary, hCal micosummary events could trigger a calendar icon. |
|
| |
|
| 2. An extension or the browser sends a notification message to the user, possibly with a message or dialog box to be shown when the user attends to the notification. (ex: an application update is available, a timer has expired)
| | A mockup of this example is below: |
|
| |
|
| 3. The browser detects content in the page which the user may wish to act upon, but which is not rendered in the content area (ex: a microformat or reference to a media file)
| | [[Image:Notification-area-icons.png]] |
| | |
| Cases 1 and 2 are globally relevant, and case 3 is relevant only to the currently loaded page.
| |
|
| |
|
| = Design Specification = | | = Design Specification = |
| The notification area provides a default UI that can be controbuted to via an API. The block of UI controls would be docked to the Status Bar by default, but could be moved by a theme or other extension. | | The framework should provide an API that can be used to specify: |
| | | * the element to be rendered when the content is discovered |
| == User Interface Design ==
| | * the location for the element to be rendered (URL bar or Status Bar) |
| The notification area should be made up of two sections: an area for contributed widgets, buttons and icons, and an area that can open on top of the content area to display additional information. The initial location of the notification area will be the status bar.
| | * when to change the state of the element |
| | | * the function to be called when the user interacts with the element |
| The contributed widgets and buttons should be able to change state, and should be able to open the additional notification area through a mouse-click or on hover.
| |
| | |
| By default, the notification area should have a single icon that will indicate when there is something for the user to attend to. Extensions and services that pass a message to the notification area but do not specify their own indicator icon will use this default notification icon.
| |
| | |
| == API Design ==
| |
| The following methods will be needed
| |
| | |
| * send a message to the notification service with callback that will be used to populate the additional information area with content
| |
| | |
| * register a notification icon/target with the notification service
| |