Extension Manager UI: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
m (Reverted edit of Hznn, changed back to last version by RyanJones)
 
(14 intermediate revisions by 4 users not shown)
Line 1: Line 1:
Work is happening in [https://bugzilla.mozilla.org/show_bug.cgi?id=329045 bug 329045]
''Please comment in the Talk page (use the Discussion tab above)''


==Current Issues==
Tracked by: [https://bugzilla.mozilla.org/show_bug.cgi?id=329045 bug 329045]
* There are multiple informational messages all sharing the same UI space (e.g. description, update check, update available, extension dependencies, extension blocklisting, incompatiblility, etc.).
* The update now button doesn't scroll the related addon into view when tabbing.
* Often used commands (e.g. actions) for managing a selected item are not easily discoverable.
* The UI is type specific (e.g. Extensions and Themes) which prevents us from checking and installing updates for addons of different types in one window.
* The UI is not task driven in that we show commands for performing actions that have no relation to the current operation at hand.
* Due to limited UI space in the command bar there is a mix of commands for a selected item and for all items (e.g. options, uninstall, and find updates) and this space would be better utilized for commands that apply to all items.
* There is no UI for managing the two new nsIUpdateItem types of locale and plugin. These were created for Firefox 1.5 but the existing UI was never modified to support them.
* Most if not all of the bugs that block [https://bugzilla.mozilla.org/show_bug.cgi?id=329045 bug 329045] can be fixed with the approach or while implementing the approach I propose below.
* more to follow


==Possible Solution==
= Goals & Objectives =
* Expand a selected item and place buttons for the often used actions in the expanded space
Primary:
* Use a badge placed on top of and aligned along the bottom of addon's icon (e.g. the same as the current update notification badge) to signify that there is additional information regarding the item. Use of a different badge for each type of information will assist those that would like at a glance status and the significance of the badge will be apparent upon selecting the item.
* Improved discoverability
* Add new elements to be used for update available, addon dependencies, addon blocklisting, incompatibility, etc. status messages.
** common actions for an addon are only available via the context menu.
* Only allow actions that apply to all addons in the command bar at the bottom.
* Task driven UI as appropriate
* Display a checking for updates view that will check for all installed addons.
** when performing a task the ui should only present actions associated with the task (e.g. checking for updates should present ui associated with checking for updates, when showing the user available updates the ui should present ui associated with installing the updates, etc.
* Display an install / upgrade view that will provide installation status for all addons being installed / upgraded. This view will not allow any actions that have nothing to do with installing / upgrading addons until after the current operation is finished at which time a new view can be selected.
** There is no clear separation between actions that apply to all addons displayed and an individual addon - this is in reference to the buttons along the bottom of the user interface two of which apply to a selected addon and one which applies to all addons.
* more to follow
* Consistent / complete status messages
** we use one element to provide all status messages. This prevents us from displaying multiple status messages when appropriate (e.g. an addon has an update and is blocklisted as well as several other combinations).
* Accessibility
** for example, we display an update now button for addons with updates within the list which allows tabbing to addons that are not displayed. This is to specifically call out that accessibility must be taken into account when designing the user interface.
* Add support for addon types that are already defined but not supported by the user interface
** specifically, locales and plug-ins were added for 1.5 though the user interface does not support displaying these types.
* Improved theme support
** the element used for status when viewing themes does not resize with the window unlike with extensions which prevents being able to read the complete theme's description and status message in several cases.
Secondary:
* Extensibility
** provide the ability for extension developers to add new views.


The following two screenshots are both very rough and works in progress. They should provide a general idea of the proposed solution and provide a basis for discussion.
== Planned Milestones ==
{| border="0" cellpadding="3" width="100%"
|-
! align=right valign=top width="15%" | pre-Alpha 2
| Design documented and there is buy in
|-
! align=right valign=top width="15%" | Alpha 2
| code complete and landed
|-
|}


Note: the enable / disable and uninstall / cancel uninstall buttons only display as applicable in the same way the context menu only displays applicable commands. This is why the uninstall button is so wide.
= Overview =


[https://bugzilla.mozilla.org/attachment.cgi?id=214237 Screenshot] of Extensions and of Themes.
== Background ==
The Extension Manager user interface has not been updated significantly to keep up with new features and functionality that has been added since its initial inception. Besides adding capabilities to be leveraged by new features / functionality there are also usability enhancements that should be addressed with the primary one being discoverability.


[https://bugzilla.mozilla.org/attachment.cgi?id=213854 Screenshot] of an extension that has an update.
== Use Cases ==
* New user (e.g. discoverability)
* Application and extension locale management
* Extension Blocklisted, Extension Dependency, etc. status messages


[https://bugzilla.mozilla.org/attachment.cgi?id=213855 Screenshot] of an extension that has an update and is also blocklisted.
== Functional Requirements ==
* common actions / tasks should be clearly presented and discoverable
* ability to present multiple status messages (e.g. operation, blocklisted, update available, dependency, etc.)


==TBD / Questions==
== Plans & Design Documents ==
* Should the managers only have one menu item in the Tools menu and if so what should it be named (e.g. Addons and Addon Manager for the Window Title)? Would it be acceptable to just name it Extensions with a Window Title of Extension Manager? See screenshot where the window title is Extensions and we have Show: [ Extensions ] for an example of how this could cause confusion.
* [[Extension_Manager_UI:User_Interface|User Interface Design]]
* Is there a better place to put the badges (e.g. notification icons)? I've tried down the right side as well as other places and so far this looks the best to me.
* There will be a documentation requirement if the secondary goal to be able to add views from extensions is completed.
* Is there a way to make it apparent that there are additional commands only available in the context menu (e.g. About Extension and Visit Home Page)?
 
* The move commands are no longer necessary and have been removed since this automatically sorts. Will there be an uprising with people yelling, <i>"off with his head"</i>?
== API Changes Required ==
* more to follow
No API changes should be required though additional methods will be required.
 
== Impact ==
The current design impacts the following areas of development
* Application / extension locale management (see [https://bugzilla.mozilla.org/show_bug.cgi?id=285848 bug 285848]) which in turn impacts inline spell check (see [https://bugzilla.mozilla.org/show_bug.cgi?id=329668 bug 329668]) for Firefox 2.0.
* Extension Blocklisting (see [https://bugzilla.mozilla.org/show_bug.cgi?id=318338 bug 318338]).
* Extension Dependencies (see [https://bugzilla.mozilla.org/show_bug.cgi?id=298497 bug 298497]) which in turn impacts Application / extension locale management.
 
=== Extensions ===
* this will make it much simpler to provide the correct status messages and thereby simplify adding new features to the Extension Manager that require status messages.
 
=== Localization ===
* String changes / additions will be required
 
=== Update ===
* No impact
 
=== See Also ===
* N/A
 
= Discussion & Implications =
 
== Caveats / What We've Tried Before ==
 
== Security Implications ==
* Improved status messages will more clearly display status messages involving security.
 
== Privacy Considerations ==
* N/A - nothing will be added by this project that should affect privacy

Latest revision as of 10:46, 25 November 2006

Please comment in the Talk page (use the Discussion tab above)

Tracked by: bug 329045

Goals & Objectives

Primary:

  • Improved discoverability
    • common actions for an addon are only available via the context menu.
  • Task driven UI as appropriate
    • when performing a task the ui should only present actions associated with the task (e.g. checking for updates should present ui associated with checking for updates, when showing the user available updates the ui should present ui associated with installing the updates, etc.
    • There is no clear separation between actions that apply to all addons displayed and an individual addon - this is in reference to the buttons along the bottom of the user interface two of which apply to a selected addon and one which applies to all addons.
  • Consistent / complete status messages
    • we use one element to provide all status messages. This prevents us from displaying multiple status messages when appropriate (e.g. an addon has an update and is blocklisted as well as several other combinations).
  • Accessibility
    • for example, we display an update now button for addons with updates within the list which allows tabbing to addons that are not displayed. This is to specifically call out that accessibility must be taken into account when designing the user interface.
  • Add support for addon types that are already defined but not supported by the user interface
    • specifically, locales and plug-ins were added for 1.5 though the user interface does not support displaying these types.
  • Improved theme support
    • the element used for status when viewing themes does not resize with the window unlike with extensions which prevents being able to read the complete theme's description and status message in several cases.

Secondary:

  • Extensibility
    • provide the ability for extension developers to add new views.

Planned Milestones

pre-Alpha 2 Design documented and there is buy in
Alpha 2 code complete and landed

Overview

Background

The Extension Manager user interface has not been updated significantly to keep up with new features and functionality that has been added since its initial inception. Besides adding capabilities to be leveraged by new features / functionality there are also usability enhancements that should be addressed with the primary one being discoverability.

Use Cases

  • New user (e.g. discoverability)
  • Application and extension locale management
  • Extension Blocklisted, Extension Dependency, etc. status messages

Functional Requirements

  • common actions / tasks should be clearly presented and discoverable
  • ability to present multiple status messages (e.g. operation, blocklisted, update available, dependency, etc.)

Plans & Design Documents

  • User Interface Design
  • There will be a documentation requirement if the secondary goal to be able to add views from extensions is completed.

API Changes Required

No API changes should be required though additional methods will be required.

Impact

The current design impacts the following areas of development

  • Application / extension locale management (see bug 285848) which in turn impacts inline spell check (see bug 329668) for Firefox 2.0.
  • Extension Blocklisting (see bug 318338).
  • Extension Dependencies (see bug 298497) which in turn impacts Application / extension locale management.

Extensions

  • this will make it much simpler to provide the correct status messages and thereby simplify adding new features to the Extension Manager that require status messages.

Localization

  • String changes / additions will be required

Update

  • No impact

See Also

  • N/A

Discussion & Implications

Caveats / What We've Tried Before

Security Implications

  • Improved status messages will more clearly display status messages involving security.

Privacy Considerations

  • N/A - nothing will be added by this project that should affect privacy