Closed
Bug 803344
Opened 12 years ago
Closed 12 years ago
poor discoverability of the enable/disable menu item for Social API
Categories
(Firefox Graveyard :: SocialAPI, defect)
Firefox Graveyard
SocialAPI
Tracking
(firefox17+ verified, firefox18+ verified, firefox19 verified)
VERIFIED
FIXED
Firefox 19
People
(Reporter: Gavin, Assigned: jaws)
References
Details
(Keywords: late-l10n, Whiteboard: [fx17])
Attachments
(1 file, 2 obsolete files)
5.61 KB,
patch
|
Gavin
:
review+
Gavin
:
approval-mozilla-aurora+
Gavin
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
Currently, the only user-exposed way to disable the social API once it has been enabled is by using the menu item that appears in the Tools menu (and app menu on Windows). Discovering that menu item exists is not easy, because it's not clearly associated with the feature after activation (which happens in content). There is a "Show sidebar" menu item in the toolbar button dropdown, and many users are confusing that with a global enable/disable. We used to have a "Remove from Firefox" menu item, but that was removed in bug 783928 because we were concerned about the opposite problem: people removing the feature accidentally and not knowing how to get it back. As a compromise, we could re-add the "Remove from Firefox" menu item, but make it a two-step process that requires confirmation. Boriss has some mockups for how this should work.
Reporter | ||
Comment 1•12 years ago
|
||
This will probably require a string, and
Updated•12 years ago
|
Assignee | ||
Comment 2•12 years ago
|
||
I was talking with Felipe yesterday and had an idea that will require no-l10n changes and also solves one of the usability problems with this potential menuitem. Basically, social providers are already the place where users activate, and so they should have the ability to deactivate as well. On the social providers site, they should be able to dispatch a custom event named "DeactivateSocialFeature" which would turn off the feature. This would allow social providers an easy toggle-switch as well as let them do the localization for this. There's bonus points too since the user can go back to where they enabled it to disable it, which can provide a nice feedback loop for the social provider as well.
Reporter | ||
Comment 3•12 years ago
|
||
I think that's a good idea, but I don't think it solves the whole problem (we'd still be reliant on the providers, not having a clear way *in Firefox* to disable a Firefox feature is still confusing). We'd probably also want a notification for when the disabling happens, for the same reasons we have one on activation, and that would require a string anyways. We should definitely investigate in a new bug, but I don't think it necessarily needs to block 17. The new string requirement here is not a game killer. An un-localized string is not ideal, but it's also not disastrous, and I think the benefits outweigh the costs. So let's do this, ASAP :)
Assignee | ||
Comment 4•12 years ago
|
||
This solution doesn't require any late string changes, and will allow users to deactivate the featureset at the same place where they activated it. Gavin or Felipe, can either of you review this? I flagged both of you just to increase chances of response time.
Assignee: nobody → jaws
Status: NEW → ASSIGNED
Attachment #673746 -
Flags: review?(gavin.sharp)
Attachment #673746 -
Flags: review?(felipc)
Assignee | ||
Comment 5•12 years ago
|
||
I didn't see comment #3 before attaching the patch... I'll work on a string approach too. With that being said, I do think what we have today isn't *horrible*, documentation can help users.
Reporter | ||
Comment 6•12 years ago
|
||
Comment on attachment 673746 [details] [diff] [review] Patch to allow content to disable social api I don't think we want to do this without a notification, but I might be convinced otherwise. More importantly, I don't think this is sufficient to address this problem in 17, per my earlier comment.
Attachment #673746 -
Flags: review?(gavin.sharp) → review-
Assignee | ||
Comment 7•12 years ago
|
||
This patch adds three strings (one for the menuitem and two for the confirmation dialog).
Attachment #673746 -
Attachment is obsolete: true
Attachment #673746 -
Flags: review?(felipc)
Attachment #673749 -
Flags: review?(gavin.sharp)
Attachment #673749 -
Flags: review?(felipc)
Reporter | ||
Comment 8•12 years ago
|
||
The mockups from boriss that I remember had a confirmation right in the menu, rather than a normal prompt. Probably more annoying to implement (and a bit of an unusual interaction for a menu), but it seemed nicer than a modal confirmation prompt, and potentially requires fewer strings.
Assignee | ||
Comment 11•12 years ago
|
||
This is the old mockup that Boriss made which shows the removal from the menu, https://bug763839.bugzilla.mozilla.org/attachment.cgi?id=632767
Assignee | ||
Comment 13•12 years ago
|
||
This patch implements inline confirmation. See http://screencast.com/t/5Wa35C0Fp9uX for a screencast demo.
Attachment #673749 -
Attachment is obsolete: true
Attachment #673749 -
Flags: review?(gavin.sharp)
Attachment #673749 -
Flags: review?(felipc)
Attachment #674405 -
Flags: review?(gavin.sharp)
Attachment #674405 -
Flags: review?(felipc)
Assignee | ||
Comment 15•12 years ago
|
||
This is a screencast that shows the buttons all the time but with them disabled until the user clicks on the menuitem to remove the feature: http://screencast.com/t/TGT0HFxdoN11 This is a screencast that sets the visibility of the buttons to hidden until the menuitem is clicked on: http://screencast.com/t/pmV84YcOD This is a screencast of the confirmation dialog interaction: http://screencast.com/t/LEKPoR0DFy See comment #13 for the fourth option.
Reporter | ||
Comment 16•12 years ago
|
||
Asa/Boriss: we need to make a call here ASAP. Can you comment on Jared's proposed solutions and decide which you think is best, or suggest an alternative? My opinion: the prompt built-in to the menu item is unusual and neither of the options really look very good. Additionally, this is a entirely novel kind of interaction, so getting it right seems tricky. So for Firefox 17, I think we should go with the modal dialog confirmation prompt - it's not ideal, but it's simple to implement, and a well known interaction model. One suggested addition: add a short bit of text to the prompt that explains how to re-activate. Not sure how to best mention this concisely and generically, though.
Assignee | ||
Comment 17•12 years ago
|
||
Another option, that doesn't do major resizing of the menupopup but keeps the buttons in context, http://screencast.com/t/dVjowLijE6tV
Comment 18•12 years ago
|
||
We discussed this a bit on IRC. I'd suggest proceeding with a standard modal prompt, for the reasons gavin already noted. Most people will see this only 0 or 1 times, so IMO simple+familiar wins out over novel UI. And, of course, we can always change it later. I think the 3 of us that chimed in all agreed that horizontally resizing the prompt is too jarring. And so if an alternative to the modal prompt is needed, something like comment 17 is the next-best option of those proposed so far.
Reporter | ||
Comment 20•12 years ago
|
||
Comment on attachment 674405 [details] [diff] [review] Patch with inline confirmation (3 strings) OK, let's do the prompt. Is attachment 673749 [details] [diff] [review] what I should review?
Attachment #674405 -
Flags: review?(gavin.sharp)
Attachment #674405 -
Flags: review?(felipc)
Assignee | ||
Comment 21•12 years ago
|
||
Comment on attachment 673749 [details] [diff] [review] Patch to add menuitem and confirmation dialog Yeah, this is the right patch for the confirmation dialog.
Attachment #673749 -
Flags: review?(gavin.sharp)
Assignee | ||
Updated•12 years ago
|
Attachment #674405 -
Attachment is obsolete: true
Assignee | ||
Updated•12 years ago
|
Attachment #673749 -
Attachment is obsolete: false
Reporter | ||
Updated•12 years ago
|
Whiteboard: [fx17]
Reporter | ||
Updated•12 years ago
|
Attachment #673749 -
Flags: review?(gavin.sharp) → review+
Reporter | ||
Comment 22•12 years ago
|
||
Comment on attachment 673749 [details] [diff] [review] Patch to add menuitem and confirmation dialog [Triage Comment] Let's get this uplifted for Firefox 17/18. We'll need to coordinate with localizers about the late string change.
Attachment #673749 -
Flags: approval-mozilla-beta+
Attachment #673749 -
Flags: approval-mozilla-aurora+
Reporter | ||
Comment 23•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/8a5d0b3a6f1b
Target Milestone: --- → Firefox 19
Reporter | ||
Comment 24•12 years ago
|
||
https://hg.mozilla.org/releases/mozilla-beta/rev/0a940d9a4046
status-firefox17:
--- → fixed
Comment 25•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/8a5d0b3a6f1b
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Comment 26•12 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/37d4b50d590e
status-firefox18:
--- → fixed
status-firefox19:
--- → fixed
Reporter | ||
Comment 27•12 years ago
|
||
Thread in dev.l10n about this: https://groups.google.com/forum/#!topic/mozilla.dev.l10n/_ifE3zkoXZU
Comment 28•12 years ago
|
||
Once XULNotifications / Australis lands, I'd propose to do the same as during installation: Just remove it, and display a notification informing the user that he removed X with the option to undo the change (other option: "OK").
Comment 29•12 years ago
|
||
Is there any QA testing needed here?
Comment 30•12 years ago
|
||
Probably worth verifying that the social toolbar item has a "remove from firefox" (sp?) option, and when selected it displays a confirmation prompt that (a) makes sense and (b) works as expected.
Comment 31•12 years ago
|
||
Thanks Mark. Verified fixed. Nominating this for a QA l10n test.
Status: RESOLVED → VERIFIED
Flags: in-moztrap?
Updated•5 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•