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.
This will probably require a string, and
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.
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 :)
Created attachment 673746 [details] [diff] [review] Patch to allow content to disable social api 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.
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.
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.
Created attachment 673749 [details] [diff] [review] Patch to add menuitem and confirmation dialog This patch adds three strings (one for the menuitem and two for the confirmation dialog).
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.
This is the old mockup that Boriss made which shows the removal from the menu, https://bug763839.bugzilla.mozilla.org/attachment.cgi?id=632767
Created attachment 674405 [details] [diff] [review] Patch with inline confirmation (3 strings) This patch implements inline confirmation. See http://screencast.com/t/5Wa35C0Fp9uX for a screencast demo.
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.
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.
Another option, that doesn't do major resizing of the menupopup but keeps the buttons in context, http://screencast.com/t/dVjowLijE6tV
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.
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?
Comment on attachment 673749 [details] [diff] [review] Patch to add menuitem and confirmation dialog Yeah, this is the right patch for the confirmation dialog.
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.
Thread in dev.l10n about this: https://groups.google.com/forum/#!topic/mozilla.dev.l10n/_ifE3zkoXZU
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").
Is there any QA testing needed here?
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.
Thanks Mark. Verified fixed. Nominating this for a QA l10n test.