Remove buttons are difficult to discover in list view

VERIFIED FIXED in mozilla2.0b7

Status

()

Toolkit
Add-ons Manager
VERIFIED FIXED
7 years ago
7 years ago

People

(Reporter: whimboo, Assigned: Paolo)

Tracking

({regression})

Trunk
mozilla2.0b7
regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -
in-litmus -

Firefox Tracking Flags

(blocking2.0 beta7+)

Details

(Whiteboard: [good first bug][strings])

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

7 years ago
Created attachment 468706 [details]
screenshot

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b5pre) Gecko/20100824 Minefield/4.0b5pre

With the fix on bug 585950 all the "Remove" buttons aren't visible anymore in the extensions and themes pane. The only way to remove addons is via the details pane.
(Reporter)

Updated

7 years ago
blocking2.0: --- → ?
The remove buttons are the things that look suspiciously like tab close buttons in the upper-right of each entry.
Status: NEW → RESOLVED
blocking2.0: ? → ---
Last Resolved: 7 years ago
Resolution: --- → INVALID
(Reporter)

Comment 2

7 years ago
Wow, those buttons are really hard to discover. I haven't seen them in any of the mockups before. When happened the discussion that we do not want to show a usual button anymore?
I forget when exactly, but its been in the mockups for a while and many people aren't particularly happy about them. I think we need to revisit this, if our lead QA tester can't find them then what hope do users have?
Status: RESOLVED → REOPENED
Keywords: uiwanted
Resolution: INVALID → ---
Summary: Cannot uninstall extensions and themes in the list view → Uninstall buttons are difficult to discover
The reason why it was changed it's because it would take too much space against add-on's description.
(Reporter)

Comment 5

7 years ago
(In reply to comment #3)
> I forget when exactly, but its been in the mockups for a while and many people
> aren't particularly happy about them. I think we need to revisit this, if our
> lead QA tester can't find them then what hope do users have?

When I had the first look at the UI I really haven't seen those buttons. Probably I haven't expected those. Could also be a reason of the lower contrast. But having an 'x' as an ui element to remove an extensions doesn't seem to be the right idea. I would never have expected the underlying action until you pointed me to those buttons and I have seen the tooltip.

My proposal would be: I like the idea of smaller buttons. And I agree with the last comment. But can we have something like a trash bin instead? IMO it would make it much more discoverable because users are comfortable with such an image.
Status: REOPENED → NEW
blocking2.0: --- → ?
(In reply to comment #5)
> But can we have something like a trash bin instead?

+1
(Reporter)

Updated

7 years ago
Summary: Uninstall buttons are difficult to discover → Remove buttons are difficult to discover in list view
(Reporter)

Updated

7 years ago
Duplicate of this bug: 590270
(In reply to comment #5)
> When I had the first look at the UI I really haven't seen those buttons.
> Probably I haven't expected those. Could also be a reason of the lower
> contrast. But having an 'x' as an ui element to remove an extensions doesn't
> seem to be the right idea. I would never have expected the underlying action
> until you pointed me to those buttons and I have seen the tooltip.
> 
> My proposal would be: I like the idea of smaller buttons. And I agree with the
> last comment. But can we have something like a trash bin instead? IMO it would
> make it much more discoverable because users are comfortable with such an
> image.

I think this is a good idea and I'm happy to move forward with it.  It's a bit strange to have a deletion icon in the upper right of an item, but I think it's preferable to the overloaded button model and will have clearer meaning than an "X."

Henrik, I don't think this has landed yet, but such a remove button should be visible both on mouseover and selection.  Selecting multiple add-ons = multiple close buttons visible.
Simple icon switch doesn't need beta feedback.
blocking2.0: ? → final+
Created attachment 470044 [details]
Mockup: remove button that appears on mouseover and selection

The problem with just replacing the close "X" with a trash can is that there is very little space in the current design for a pictographic icon in the upper right of a list view entry.

I played around with other locations for the close icon, but always it appeared a bit tacked on.

Here's a suggestion: for add-ons that are moused over or selected, we include an actual remove button on the right.  It diminishes slightly the amount of room given for the description of the add-on.  Attach mock shows what this could look like.
(Reporter)

Comment 11

7 years ago
(In reply to comment #10)
> Here's a suggestion: for add-ons that are moused over or selected, we include
> an actual remove button on the right.  It diminishes slightly the amount of
> room given for the description of the add-on.  Attach mock shows what this
> could look like.

How will this behave with other addons installed who put their own buttons at the left side of the button bar, i.e. the ACR? I would assume we will have a drastic moving of buttons when the list entry is moused over?
I really don't like the idea of there being no visible way to uninstall an add-on until you mouse over it. Seems like we should just go back to having a fixed remove button there.
blocking2.0: final+ → beta6+
Whiteboard: [good first bug]
Blocks: 591033
(In reply to comment #12)
> I really don't like the idea of there being no visible way to uninstall an
> add-on until you mouse over it. Seems like we should just go back to having a
> fixed remove button there.

Agreed.
(In reply to comment #13)
> (In reply to comment #12)
> > I really don't like the idea of there being no visible way to uninstall an
> > add-on until you mouse over it. Seems like we should just go back to having a
> > fixed remove button there.
> 
> Agreed.

While I can't say I am extremely fond of the repeating button noise I don't see that adding/keeping the static Remove button would make it significantly more noisy than just having Preferences and/or Disable and it would remove any ambiguity.
Whiteboard: [good first bug] → [good first bug][strings]

Comment 15

7 years ago
What about a split menu button with "Details" in the button area and Options, Disable/Enable, Remove (and Compatibility) in the drop-down?

Comment 16

7 years ago
Only wanted to emphasize again that the current button is really bad. I actually clicked on it to see what this strange button does and it uninstalled my addon :( And as the Undo option that was in there at some point doesn't seem to exist anymore I had to reinstall.
(Assignee)

Comment 17

7 years ago
I think I can help with this in the next few days. My idea too is, for this
version, to just restore the Remove button as it was in a previous build.

A drop-down menu is a nice idea, but in my opinion is not indicated for now,
since it would become more difficult to invoke some commands like Disable
rapidly on multiple addons, which is sometime recommended in the procedures
for troubleshooting. If the list becomes multiple-selection with right-click
menu commands on multiple items, then collapsing Disable under a drop-down
Remove button, or similar variants, might be an option. Such a dropdown
button may appear like it does in the new Download Manager Panel UI
(see bug 564934 attachment 466688 [details]).
(In reply to comment #15)
> What about a split menu button with "Details" in the button area and Options,
> Disable/Enable, Remove (and Compatibility) in the drop-down?

I don't think there are enough buttons to warrant that just yet. Especially since all the buttons are primary functionality (enable/disable, remove, preferences). In the future, when there may be secondary functions added (like compatibility reporting - see bug 565930), then I think it would make sense to explore using a menu button.
(Assignee)

Comment 19

7 years ago
Created attachment 471964 [details] [diff] [review]
The patch

Actually, this required no string changes, as the Remove label is already used
in the details view, like the Disable label. For reference, the Remove button
was turned into an icon in changeset 76559e9039e2, bug 585950.
Assignee: nobody → paolo.02.prg
Attachment #471964 - Flags: review?(dtownsend)
(Assignee)

Comment 20

7 years ago
B the way, the change required no modifications to tests. I tested it with:

TEST_PATH=toolkit/mozapps/extensions/test/browser make mochitest-browser-chrome
Comment on attachment 471964 [details] [diff] [review]
The patch

Drive-by: I think there are styles for remove-container to remove too.
Attachment #471964 - Flags: review?(dtownsend) → review?(bmcbride)
(Assignee)

Comment 22

7 years ago
Created attachment 471979 [details] [diff] [review]
The patch
Attachment #471964 - Attachment is obsolete: true
Attachment #471979 - Flags: review?(dtownsend)
Attachment #471964 - Flags: review?(bmcbride)
(Assignee)

Updated

7 years ago
Attachment #471979 - Flags: review?(dtownsend) → review?(bmcbride)
Comment on attachment 471979 [details] [diff] [review]
The patch

Looks good.
Attachment #471979 - Flags: review?(bmcbride) → review+
https://hg.mozilla.org/mozilla-central/rev/cda6a4cf9839
Status: NEW → RESOLVED
Last Resolved: 7 years ago7 years ago
Flags: in-testsuite-
Flags: in-litmus-
Keywords: uiwanted
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b6
(Reporter)

Comment 25

7 years ago
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b6pre) Gecko/20100911 Firefox/4.0b6pre
Status: RESOLVED → VERIFIED
(Reporter)

Updated

7 years ago
Blocks: 562954
You need to log in before you can comment on or make changes to this bug.