843862 - support partial social providers

Status: RESOLVED FIXED

(Firefox Graveyard :: SocialAPI, defect)

Description

[Shane Caraveo (:mixedpuppy)]

Social has three (ok, two until bug 818675 lands) primary functionalities: sidebar, toolbar/notifications and share.  Each of these is enabled by a url in the manifest: sidebarURL, workerURL and shareURL.  Social API should work with a given manifest so long as AT LEAST one of these URLs are available in the manifest.

use cases:

- a provider wants to use notifications and panels, but has no need of sidebar panel
- a provider wants the sidebar panel, but has no need of notifications
- a provider only wants to support share

Comment 1

[Mark Hammond [:markh] [:mhammond]]

I'd guess there are UX considerations here, particularly with the sidebar.  Specifically, I think it might be confusing to the user to switch providers and have the sidebar vanish for no obvious reason and with no obvious way to turn it back on.  Then later they re-switch and it re-appears.  Wanting just jewel-style notifications and no other UI seems a non-use-case (at least not one worth supporting for the additional complexity/confusion it may cause)

Given share allows you to specify a provider for that single operation without changing the "default" provider, I'd say we want something like:

* A "full" provider must implement a sidebar and a worker.  Only "full" providers appear in the toolbar dropdown and can be made the default provider.  The worker can be a stub if they desire, but I don't see a good reason to allow it not to exist given that is the only way to leverage other features (eg, the only way to create jewels, or the only way to create chats if the sidebar is closed)

* A "share only" provider can be installed, but the addons manager should highlight it is a "share only" provider and possibly provide wording so the user doesn't expect it to appear in the dropdown.

* The "share" feature always remembers the last provider used for sharing, rather than always default to the "current" provider.  Thus, if a "share only" provider is installed and used regularly, it is likely to be the default provider for the share panel but doesn't appear in any other social UI (apart from the manager obviously)

Comment 2

[Jennifer Morrow [:Boriss] (UX)]

While Mark is right that shifting UI can be visually jarring, it's acceptable for some visual transition to occur when users switch providers.  What's very important for providers is to provide the UI that best suits their tool, whether that's notifications and a sidebar, just notifications, etc.  To force or encourage providers to build unnecessary UI for the sake of transitioning between providers will lead to superfluous UI that clutters the browser without providing useful tools to the user.  Frankly, if a sidebar doesn't add user value, developers shouldn't be encouraged to use it anyway.

The visual transition can be mitigated very much as a visual distraction.  For instance:

- It would only occur when users switch providers.  This would be a use case not even seen by most users, who would have only one provider installed.  Even for multiple-provider users, it would only be visible when switching.  The time spent switching providers is miniscule compared to the time using providers. 

- This would only occur when users are physically using the UI - not in the background.  This means that yes, a visual transition would occur, but only when users are already manipulating the UI via the dropdown and focused on social API. They're making a physical change, and they will thus see a physical change.  This all contributes to making the transition less jarring than one that happened, for instance, in the background without user input.

- We can employ some visual finesse here to make the transitions less awkward.  Rather than suddenly removing the sidebar, for instance, we can smoothly animate it to the side.  Some carefully-deployed animations will make the process of switching providers feel more fluid.

Comment 3

[Shane Caraveo (:mixedpuppy)]

We'll do this as part of landing the share panel.

When we implement this, we need to address 1b in https://bug836452.bugzilla.mozilla.org/attachment.cgi?id=729925