Closed Bug 586066 Opened 14 years ago Closed 13 years ago

[meta] Changing Add-ons Manager Look & Feel

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: jboriss, Assigned: Unfocused)

References

Details

(Keywords: meta, Whiteboard: [needs 601022])

Attachments

(5 files, 1 obsolete file)

Attached image Mockup: Detail View (obsolete) —
Meta bug for implementing new interface for the add-ons manager.  This requires
platform-specific graphics as well as new interactions and behaviors for
add-ons.

The new add-ons manager interface will consist primarily of variations on three
separate interfaces:

1. List View (bug 585950)
  - Each category of add-ons (except Themes/Backgrounds) displays at its top
level a list of all the add-ons it contains
  - Information included in each entry is:
       * Add-on name
       * Add-on icon
       * Add-on author (links to AMO profile)
       * Add-on description (curtailed after one line)
       * Date add-on was last updated
  - Buttons included in each entry are:
        * Disable/enable toggle button
        * Preferences link (launches in separate window)
        * "More" link (launches Detail View of add-on)
  - Clicking an add-on selects that entry; multi-select is enabled
  - Selected add-ons display an X in the top right corner for deletion
  - Notifications for an add-on appear above the add-on's title in its entry
  - Searching for an add-on produces a variation on List View, with the
added option to search for add-ons available to download as well as ones which
are currently installed

2. Themes and Backgrounds View (bug 520124)
  - Themes are displayed first, backgrounds second - both groups are
collapsible
  - Each entry includes:
       * Add-on name
       * Add-on preview
       * Add-on author (links to AMO profile)
  - Clicking an add-on selects that entry; multi-select is enabled
  - When an add-on is selected, it displays:
       * An X in the top right corner for deletion
       * A "more" link (launches Detail View of add-on)
       * A link to wear that add-on
- If only backgrounds are installed, no themes display (and vice
versa)

3. Detail View (Bug 562902)
- Gives further information about a single add-on
- Displays:
       * Add-on name
       * Add-on author (links to AMO profile)
       * Full add-on description
       * A contribution link if the author has opted into donations
       * Specific information such as compatibility, rating, last updated
       * Allows the user to switch between manual and automatic updates
Attached image Mockup: List View
Assignee: nobody → jboriss
(discussion moved here from bug 550048.  Please see attachment for mockups of the following)

(In reply to comment #5)
> (In reply to comment #1)
> >   - Selected add-ons display an X in the top right corner for deletion
> 
> Hmm, this is almost completely undiscoverable, I'm sure not finding that will
> confuse a good number of users. Also, this is not visible in your mockups.

It's true in that in the attached List View mockup, there is no visible way to remove an add-on without interacting with the page content.  An X becomes visible in the top right of an entry on hover and on selection.  However, I'd still argue that placing the close button on mouseover and selection is discoverable, for a few reasons:

- Close buttons in top right are a standard in nearly all major operating systems
- There is precedence for showing a close button on selection within Firefox
- There is precedence for showing a close button on hover within Windows
- There are fully three ways to delete an add-on, all of which are standards in software:
   1. X appearing on hover and selection
   2. Selecting an add-on and then pressing delete
   3. Pressing "remove" within an add-on's detail view

That said, the X is subtle while being discoverable, so alternatives offered will happily be considered.
(In reply to comment #3)
> However, I'd still argue that placing the close button on mouseover
> and selection is discoverable, for a few reasons:
> 
> - Close buttons in top right are a standard in nearly all major operating
> systems
> - There is precedence for showing a close button on selection within Firefox
> - There is precedence for showing a close button on hover within Windows
> - There are fully three ways to delete an add-on, all of which are standards in
> software:
>    1. X appearing on hover and selection

This is mixing the concepts of close and uninstall. They're not the same thing. I don't think to "close" something to uninstall it; it's not an automatic assumption. I don't think these concepts should be mixed like this.

>    2. Selecting an add-on and then pressing delete
>    3. Pressing "remove" within an add-on's detail view
> 
> That said, the X is subtle while being discoverable, so alternatives offered
> will happily be considered.

What was wrong with the good 'ol fashioned uninstall button? It was standard in the manager for quite some time, for good reason. There's three main reasons why a user would need to interact with their Addon Manager: 1) configure an addon, 2) disable/enable an addon, 3) get rid of an addon. Thus, I don't see why all three shouldn't still have buttons in the list. There's plenty of room available here.

Also, while the subject is up, I object to the renaming of "uninstall" to "remove". These words do not mean exactly the same thing. "Remove" only implies removal from the list, whereas "uninstall" is explicitly defined to remove from the system. (in the event that uninstallation is impossible for an addon, however, then of course in that instance "remove" would make sense) This renaming feels to me like an unneeded dumbing down.
Attached image Mockup: Detail View
Attachment #464543 - Attachment is obsolete: true
Attachment #464573 - Attachment description: Mockup: Reply to Comment 5 on bug 550048, regarding add-on removal from List View → Reply to Comment 5 on bug 550048, regarding add-on removal from List View
(In reply to comment #4)

> What was wrong with the good 'ol fashioned uninstall button? It was standard in
> the manager for quite some time, for good reason. There's three main reasons
> why a user would need to interact with their Addon Manager: 1) configure an
> addon, 2) disable/enable an addon, 3) get rid of an addon. Thus, I don't see
> why all three shouldn't still have buttons in the list. There's plenty of room
> available here.

The problem with a remove button is primarily one of space.  Laying the buttons out horizontally takes about 215px away from the description of the add-on, while stacking them makes the design heavy and cluttered.  Any more than two buttons gives the right side of the mockup lots of visual weight, but restyling the buttons produces an inconsistent look to the rest of the browser.  It's possible that this may be the right tack if the "X" is too subtle for users (some testing could show either way), but it'll be a tradeoff of space vs recognition.

> Also, while the subject is up, I object to the renaming of "uninstall" to
> "remove". These words do not mean exactly the same thing. "Remove" only implies
> removal from the list, whereas "uninstall" is explicitly defined to remove from
> the system. (in the event that uninstallation is impossible for an addon,
> however, then of course in that instance "remove" would make sense) This
> renaming feels to me like an unneeded dumbing down.

The reason "remove" is being used is not to dumb down the language, but to make it more explicit.  When a user gets rid of an add-on, what's relevant is that it's gone: no longer in this list, no longer a part of Firefox.  The problem with the term "uninstall" is that it implies the install is un-happening.  It's the equivalent of saying someone leaving a party has un-arrived, or that a departing plane has un-landed.  It's true that the word uninstall is used prevalently throughout Windows, but I believe this is to the detriment of clarity.
In reply to comment #7: if you want to be explicit, "remove" is not the opposite of "install" but of "add"; so here it is ill-chosen, unless you want to replace everywhere "Install this add-on" by "add this add-on" which I would feel _less_ explicit - an an awkward repetition. If the opposite of "install" is not "uninstall" (which, however, has a long track record already), then maybe "deinstall"?
In reply to comment #7:

"Uninstall" is not a word I would think many people using a computer wouldn't know or at least be able to figure out. If it actually is a problem to enough, "delete" would convey the same rough concept in a potentially more understandable way. Average users delete things all the time. (re: comment 7: "deinstall" is a word I've heard used before, but it's not natural sounding, in my opinion)

I should point out, however, that software is really generally un-installed as you analogize, in that a log of the installation process is in essence run in reverse. (though not literally) Addons frequently don't do anything special on uninstall, but extensions are capable of doing so and a few do.

If you're particularly worried about space, here's a space saving idea: icons that expand on hover. Just have lightswitch and a trashcan icons for each entry and upon mouseover of an icon expand its button to show the label. If you're worried about having too many icons making it busy then have the icons dimmed/semi-transparent until mouseover. Simple and clean, and would take up less space then the enable button as-is.
(In reply to comment #8)
> In reply to comment #7: if you want to be explicit, "remove" is not the
> opposite of "install" but of "add"; so here it is ill-chosen, unless you want
> to replace everywhere "Install this add-on" by "add this add-on" which I would
> feel _less_ explicit - an an awkward repetition. If the opposite of "install"
> is not "uninstall" (which, however, has a long track record already), then
> maybe "deinstall"?

The goal isn't to make these words equivalent semantically, but for each to describe what function they perform.  "Install" actually begins the process of installation, and in especially in the case of add-ons that require restart it is not sufficient to fully add an extension to Firefox.
What happened to the breadcrumbs? I remember it being in an older mockup, however it's not in any of these. I really liked that idea and think it should at least used for the details view. It would also be helpful to have it in some form for consistency's sake as AMO uses breadcrumbs all over the place.
For one thing, AMO says "Add to Firefox", so "remove" actually fits that. Still, I think making Enable/Disable into a checkbox or some equivalent or possibly making "Preferences" a link of some sort (or, say, put it at the left while disable/remove are on the right) could possibly make up for the heavy weight of three buttons - which I agree with, by the way.
I filly see the design reasoning behind boriss' mockups and I fully agree it looks slick, but I really fear that users will be confused about uninstalling and the X icon. Some actual testing with people not involved in UI and app design might really be worthwhile there, would that be possible?
(In reply to comment #11)
> What happened to the breadcrumbs? I remember it being in an older mockup,
> however it's not in any of these. I really liked that idea and think it should
> at least used for the details view. It would also be helpful to have it in some
> form for consistency's sake as AMO uses breadcrumbs all over the place.

The plan is definitely to have them in the add-ons manager eventually.  The problem is that while the add-ons manager is not yet a part of preferences, there's really only two levels - list and backgrounds/themes view at the top level, and detail view below that.  That's it, and just using the navigation links on the left allow you to go up one level.  So that's why the breadcrumbs are taken out - there simply aren't enough levels (at least three) to make it useful.
Depends on: 590130
Depends on: 562935
I've filled Bug 599566 (Confusing "Disable" button in add-ons manager) but i realized that maybe i should have posted directly here
Depends on: 554097
Assignee: jboriss → bmcbride
Status: NEW → ASSIGNED
Depends on: 601022
Whiteboard: [needs 601022]
Hardware: x86 → All
Version: unspecified → Trunk
Depends on: 614838
No longer depends on: 614838
Depends on: 614865
No longer depends on: 614865
Blocks: 623199
No longer blocks: 623199
Don't think its useful to keep this open anymore.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Flags: in-testsuite-
Flags: in-litmus-
Resolution: --- → FIXED
Agreed on. That was a Firefox 4 project.
Status: RESOLVED → VERIFIED
No longer depends on: 520124
You need to log in before you can comment on or make changes to this bug.