Last Comment Bug 803344 - poor discoverability of the enable/disable menu item for Social API
: poor discoverability of the enable/disable menu item for Social API
Status: VERIFIED FIXED
[fx17]
: late-l10n
Product: Firefox
Classification: Client Software
Component: SocialAPI (show other bugs)
: unspecified
: All All
: -- normal with 2 votes (vote)
: Firefox 19
Assigned To: Jared Wein [:jaws] (please needinfo? me)
:
: Shane Caraveo (:mixedpuppy)
Mentors:
: 804218 804624 805445 (view as bug list)
Depends on: 783928
Blocks: 805217
  Show dependency treegraph
 
Reported: 2012-10-18 16:27 PDT by :Gavin Sharp [email: gavin@gavinsharp.com]
Modified: 2013-12-27 14:33 PST (History)
21 users (show)
ryanvm: in‑testsuite-
anthony.s.hughes: in‑moztrap?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
verified
+
verified
verified


Attachments
Patch to allow content to disable social api (3.89 KB, patch)
2012-10-21 19:17 PDT, Jared Wein [:jaws] (please needinfo? me)
gavin.sharp: review-
Details | Diff | Splinter Review
Patch to add menuitem and confirmation dialog (5.61 KB, patch)
2012-10-21 20:11 PDT, Jared Wein [:jaws] (please needinfo? me)
gavin.sharp: review+
gavin.sharp: approval‑mozilla‑aurora+
gavin.sharp: approval‑mozilla‑beta+
Details | Diff | Splinter Review
Patch with inline confirmation (3 strings) (8.70 KB, patch)
2012-10-23 15:16 PDT, Jared Wein [:jaws] (please needinfo? me)
no flags Details | Diff | Splinter Review

Description :Gavin Sharp [email: gavin@gavinsharp.com] 2012-10-18 16:27:02 PDT
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.
Comment 1 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-10-18 16:30:28 PDT
This will probably require a string, and
Comment 2 Jared Wein [:jaws] (please needinfo? me) 2012-10-21 14:06:12 PDT
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.
Comment 3 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-10-21 19:07:41 PDT
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 :)
Comment 4 Jared Wein [:jaws] (please needinfo? me) 2012-10-21 19:17:39 PDT
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.
Comment 5 Jared Wein [:jaws] (please needinfo? me) 2012-10-21 19:19:40 PDT
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 6 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-10-21 19:22:21 PDT
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.
Comment 7 Jared Wein [:jaws] (please needinfo? me) 2012-10-21 20:11:54 PDT
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).
Comment 8 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-10-22 09:50:58 PDT
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.
Comment 9 Shane Caraveo (:mixedpuppy) 2012-10-22 10:40:34 PDT
*** Bug 804218 has been marked as a duplicate of this bug. ***
Comment 10 Jared Wein [:jaws] (please needinfo? me) 2012-10-22 11:47:56 PDT
*** Bug 804260 has been marked as a duplicate of this bug. ***
Comment 11 Jared Wein [:jaws] (please needinfo? me) 2012-10-22 14:35:56 PDT
This is the old mockup that Boriss made which shows the removal from the menu, https://bug763839.bugzilla.mozilla.org/attachment.cgi?id=632767
Comment 12 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-10-23 09:40:54 PDT
*** Bug 804624 has been marked as a duplicate of this bug. ***
Comment 13 Jared Wein [:jaws] (please needinfo? me) 2012-10-23 15:16:27 PDT
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.
Comment 14 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-10-25 11:39:41 PDT
*** Bug 804235 has been marked as a duplicate of this bug. ***
Comment 15 Jared Wein [:jaws] (please needinfo? me) 2012-10-25 18:03:11 PDT
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.
Comment 16 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-10-26 12:26:51 PDT
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.
Comment 17 Jared Wein [:jaws] (please needinfo? me) 2012-10-26 17:05:51 PDT
Another option, that doesn't do major resizing of the menupopup but keeps the buttons in context, http://screencast.com/t/dVjowLijE6tV
Comment 18 Justin Dolske [:Dolske] 2012-10-27 00:48:31 PDT
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 19 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-10-27 16:35:31 PDT
*** Bug 805445 has been marked as a duplicate of this bug. ***
Comment 20 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-10-27 16:37:36 PDT
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 21 Jared Wein [:jaws] (please needinfo? me) 2012-10-27 17:35:51 PDT
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 22 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-10-29 17:40:29 PDT
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.
Comment 23 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-10-29 23:27:08 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/8a5d0b3a6f1b
Comment 24 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-10-29 23:38:51 PDT
https://hg.mozilla.org/releases/mozilla-beta/rev/0a940d9a4046
Comment 25 Ryan VanderMeulen [:RyanVM] 2012-10-30 08:23:15 PDT
https://hg.mozilla.org/mozilla-central/rev/8a5d0b3a6f1b
Comment 26 Ryan VanderMeulen [:RyanVM] 2012-10-30 11:56:49 PDT
https://hg.mozilla.org/releases/mozilla-aurora/rev/37d4b50d590e
Comment 27 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-10-30 18:52:32 PDT
Thread in dev.l10n about this:
https://groups.google.com/forum/#!topic/mozilla.dev.l10n/_ifE3zkoXZU
Comment 28 Florian Bender 2012-11-02 12:10:03 PDT
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 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-12-04 14:44:34 PST
Is there any QA testing needed here?
Comment 30 Mark Hammond [:markh] 2012-12-04 14:48:48 PST
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 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-12-04 14:55:00 PST
Thanks Mark. Verified fixed. Nominating this for a QA l10n test.

Note You need to log in before you can comment on or make changes to this bug.