Proposing some social features for Firefox

[Mike Hanson]

Hi everybody - I wanted to sum up some recent thinking about "Social in Firefox" and ask for feedback on some concrete implementation ideas.

Let's keep followups in dev-apps-firefox unless there is a stricly platform issue. Mounir's right, forking is bad for human brains.

As context for all this, I'll offer that social activity is, for many of our users, the main reason they use a browser. Facebook, Tumblr, Pinterest, Twitter, LinkedIn, GooglePlus, and sites like them are the hubs and spokes of many user's online lives - and yet, unlike search, we don't offer our users any tools to help navigate and manage relationships with them.

We'd like to provide an opt-in way for users to use Firefox to have a more active, "always visible" relationship with these services. If users don't want any of this, they never see it. But if they switch it on, we'd like to make a set of social interactions more pleasant, easy, and engaging. We propose to do this in-content - rather than by tying into server-provided APIs - but with content that is drawn in different places, with different life cycles, than typical web-navigation content.

The basic set of interactions we'd like to support are:

* To manage a list of social services (discover, install, delete)
* To display to the user which social services they are currently signed in to
* To easily sign in and out of a service, and to switch which service the user is interacting with, or to switch off social interaction
* To recommend the current page to their friends on a network - either as a standalone URL or with a comment.
* To see which of a user's contacts are online
* To initiate real-time communication with a contact through chat, voice, or video
* To see updates from contacts and to be notified when new updates are available
* To receive, at the user's discretion, ambient or immediate notification when interesting events have occurred

The new APIs are fairly small and focused but they would have implications for resource consumption and the interactions with the browser window. They would not be available to vanilla webpages - only to pages loaded into "special" browser elements. Specifically, I propose that Firefox would:

1. Manage a list of social service providers.

Much like the list of search engines, this would be a list of ( icon + name + some URLs ) tuples. They could be discovered from markup, installed from JavaScript, or handled in a more secure (e.g. more like add-ons) way. This list could be visible in a pref pane, top-level menu, or popup panel visible from the navigation bar.


2. Run a long-running worker, per provider, with the ability to maintain a network pipe to the server

I propose that we could do this with a hidden background page, running a JavaScript file from the service provider, which is run in a sandbox that has access to only WebSockets, XMLHttpRequest, IndexedDB, btoa, atob, Notification, setTimeout/setInterval/clearTimeout/clearInterval. It would run as unprivileged content from the service provider's domain.

We've made a prototype where we essentially do this:

1. Make an iframe on the hidden window
2. Set the src of the iframe to the URL of some "worker.js" (read from the provider's metadata)
3. When the JS has loaded, make a Sandbox whose prototype is linked to the provider's principal
4. Import the WebSocket, indexedDB, XMLHttpRequest,
atob/btoa, and timeout/interval functions from the iframe's window into the Sandbox
5. eval the text content of the frame in the Sandbox
6. as connections to the worker are made, invoke an "onconnect" handler in the Sandbox
(which is the provider's responsibility to implement), passing in a bidrectional MessagePort.

It's not a full Worker, as it's just running on the main thread - but the API would be designed to be asynchronous and ready to run inside a worker. It can respond to messages from content and receive both WebSocket-pushed and XMLHttpRequest-long-poll-based I/O. To a developer it feels like a Shared Worker so we have a small delta if we go down that path in the future. Managing resource consumption on this worker, which is hidden, is obviously a concern, and ideas are really welcome. The new global compartment checking will help for sure.

In addition to the window API described in #5, I propose that we also expose the IdleService to this worker. This would make chat and presence applications much easier to get right.


3. Offer a portion of browser window visual space to the service provider for content.

This could take the form of a sidebar, or a chunk of the navigation bar. We have prototyped an element that can zoom between a small rectangular element to the right of the search box and a full-height sidebar which includes the navbar and content region. When "minimized" the element can be used for "who am I signed in as" and notification/badge content ("you have X new messages"). The URLs for this content would be retrieved from the service provider metadata. On mobile, this could take the form of a sideswipe bar. A navigation-bar toolbar button would be made available to switch between the user's installed providers on a per-window basis.

A new API would be made available to content running in this sidebar to get a reference to the long-running worker, if any, from which postMessage and onMessage communication could run. This API would not be made available to normal service provider content; only content running in the "provider" context would see it.


4. Offer an always-on "recommend/share this" button in the navigation/location bar, or on a swipe/gesture.

(Nomenclature note - we're distinguishing between the "single bit" action, which we call "recommend" and the more involved action, which we call "share". A Like, comment-free-Digg, or +1 is a recommend; a tweet with some explanatory text is a share.)

In the current prototypes for Share, this button goes in the URL bar next to the bookmark, frecency, and reload glyphs. It could obviously also have a keyboard shortcut, etc.

We've talked about a lot of possible interactions for this - one of the simplest is that, for whatever the currently selected service provider is, we pull a 16x16 icon from the metadata (or in response to a message fired at the worker), and style the button with that. A click on the button dispatches an event to the worker, with the URL of the current page. We could do a second click for "add a comment" (converting a "recommend" into a "share"), or we could do a click-and-hold, or we could do a doorhanger panel on the first click with the understanding that if there is no further interaction it was just a recommend.

5. Offer an API to create a service-pinned window

Chat, voice, and video interactions are a poor match for page-scoped data - they tend to have their own lifespan which is longer, or shorter, than a typical page view. I propose that we offer an API to create a new window (browser, that is - it may or may not be a new ChromeWindow) that is "pinned" to a service provider, with the intent that it would be primarily used for these communications.

The window would have access to the Worker (as described in #3); it could offer minimal navigation chrome since the URL isn't relevant; perhaps we display the domain name and some way of getting at the certificate and that's it. Any attempt to navigate away from the service provider's domain would be intercepted and directed back at a tabbedbrowser in another window. "Deactivating" the service provider would close all the service-pinned windows.

The browser element created this way could float in a window, or be pinned to a ChromeWindow, perhaps by stacking along the bottom. Creative ideas for how to handle this in mobile?


That's the basics. Now, some more speculative ideas...

6. Interact with WebContacts to pull contacts from the provider.

The WebContacts system (see bug #674720) could use a postMessage-based protocol to get contact data directly from the service provider without any adapters or glue.

7. Offer the Notifications API to service provider content

The Notification constructor (see bug #573588 and recent dev-webapps and b2g threads) could be exposed directly to the Worker, allowing providers that are not currently visible a way to indicate to the user that interesting data is available. The notifications need not be delivered to the OS right away - they could easily be queued, in a service-provider keyed way, until the user indicates a desire to see them. The B2G team has lots of creative possibilities here.

If you want to chat realtime, we're hanging out in #socialdev on IRC.

Thanks -

Mike & the social hacking team

[Jeff Hammel]

Hi,

I'm not sure how "most people" use the web, just me, but one thing that
is vitally important to me would be to post a "status update" to
multiple sites. I would use social media more often if I could
write-once/send-many such things. As it is, I usually put status
updates in a single site (my blog) that no one reads anyway.

Not sure if this is OT or not. I'm not a big social media user
precisely for the reason that I can't federate my intent (except manually).

Jeff Hammel

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Gervase Markham]

On 22/03/12 22:44, Jeff Hammel wrote:
> I'm not sure how "most people" use the web, just me, but one thing that
> is vitally important to me would be to post a "status update" to
> multiple sites. I would use social media more often if I could
> write-once/send-many such things.

To expand further: how can we build this in a way which encourages
diversity in the social site space ("choice and innovation" :-), rather
than entrenching the leads of the current big players?

That could involve e.g.:

- Making it very easy to add new sites, or for sites to prompt to add
themselves
- Making it possible to post content to multiple sites at once
- Providing aggregate views of incoming data across sites

Gerv

[Asa Dotzler]

I think we should think of the Social API like OpenSearch. You plug a
service in and that service has a presence in the browser. I think we
should make it easy to move between different service but I don't think
co-mingling services is enough value for enough people to make that a
requirement for this feature.

Making it easy to add services and switch between them is totally on
mission for choice and control.

Also, that would require a lot of code and UX work on our part when I
think we would prefer that the service just hand us a few URLs and we
basically iframe those into a few very simple UI elements (sidebars,
toolbars, etc.) Having to sort our dates and ordering and distinguishing
different services is a lot of complexity for, IMO, not a lot of gain.

Yes, there are some power users that track three or four different
social networks at the same time, but that's definitely not the common
case and, IMO, not worth the complexity.

- A

[Gervase Markham]

On 23/03/12 16:45, Asa Dotzler wrote:
> I think we should think of the Social API like OpenSearch. You plug a
> service in and that service has a presence in the browser. I think we
> should make it easy to move between different service but I don't think
> co-mingling services is enough value for enough people to make that a
> requirement for this feature.

A reasonable argument; although I seem to remember that co-mingling
search results was a seriously-considered feature at one point. (I have
no idea whether our search contracts would have any bearing on such a
feature...)

> Yes, there are some power users that track three or four different
> social networks at the same time, but that's definitely not the common
> case and, IMO, not worth the complexity.

If you are defining both Facebook and Twitter as social networks, then I
think it's not that uncommon. Also, if the market is to diversify, we
want it to become more common... Few people are going to leave e.g.
Facebook entirely one day for some other network; they'll want to
migrate gradually.

Gerv

[Asa Dotzler]

On 3/26/2012 7:08 AM, Gervase Markham wrote:
> On 23/03/12 16:45, Asa Dotzler wrote:
>> I think we should think of the Social API like OpenSearch. You plug a
>> service in and that service has a presence in the browser. I think we
>> should make it easy to move between different service but I don't think
>> co-mingling services is enough value for enough people to make that a
>> requirement for this feature.
>
> A reasonable argument; although I seem to remember that co-mingling
> search results was a seriously-considered feature at one point. (I have
> no idea whether our search contracts would have any bearing on such a
> feature...)

Yes, we had some co-mingling features in the early Mozilla days but it
turned out to be less useful than we would have liked and today I'm sure
that search services are totally opposed to having any modifications
made to their search results. I haven't taken a look at the contract
lately, but I'm gonna guess that messing with their results is a no.

>> Yes, there are some power users that track three or four different
>> social networks at the same time, but that's definitely not the common
>> case and, IMO, not worth the complexity.
>
> If you are defining both Facebook and Twitter as social networks, then I
> think it's not that uncommon. Also, if the market is to diversify, we
> want it to become more common... Few people are going to leave e.g.
> Facebook entirely one day for some other network; they'll want to
> migrate gradually.

While I would love to see this feature help diversify the market, its
primary focus is user benefit. If, as a side effect, we make it easier
for users to discover and experience new services, that's great. But
that is not the goal here. This is a lot like search. We know people
want and need it and we think we can help them have a better experience
by building some of it into Firefox itself.

- A

[Alex Keybl]

Hi Mike,

Very interesting read. I'm really glad you've started scoping this
work. One quick comment - how we implement a persistent UI like:

> 3. Offer a portion of browser window visual space to the service provider for content.
>
> This could take the form of a sidebar, or a chunk of the navigation bar. We have prototyped an element that can zoom between a small rectangular element to the right of the search box and a full-height sidebar which includes the navbar and content region.

could lead to new user experiences outside of social . We should
discuss other persistent UIs and services that could benefit from such
a feature. I've previously filed bugs (see [1]) about consuming/
controlling media without going back to a specific tab, which we may
be able to cover with this work.

-Alex

[1] https://bugzilla.mozilla.org/buglist.cgi?quicksearch=692871%2C692873