Mobile/Archive/Sharing
Contents
Summary
Support easy sharing of certain objects (links, pages, bookmarks, etc.) with social networks and contacts.
The browser should remember things that you've shared, because you've shown that this is an item you are interested in (also, you may well want to share it again). We could use bookmarking as a mechanism for this -- i.e. bookmark everything that you share (possibly tagging the bookmark with "shared" so that the browser can keep track).
Current Status
- Basic front end landed with hard-coded (in-browser only) back-end services.
- Researching back-end implementation details.
Next Steps
- Define the API between back-end and front-end.
- Define the add-on API.
- Write the Android back-end using the ACTION_SEND intent.
- Define the dbus API for Maemo apps.
Related Bugs
- bug 582615 - front end
- bug 582616 - back end (Android)
- bug 582621 - back end (Maemo/MeeGo)
- bug 586780 - sharing from Firefox 4's context menu as well!
Team
- Project Lead: madhava, for now
- Developer: mbrubeck
- QA: tchung
Designs
Back-end software design
Android
Message passing in Android is done with objects called Intents. An intent includes an action (a string representing a verb), an optional URI, optional MIME type, and optional bundle of key-value pairs ("extras"). There are many standard actions defined by the OS, including ACTION_DIAL, ACTION_VIEW, ACTION_EDIT. So to open a web page, you could send an ACTION_VIEW intent with an http: URI.
Intents can be sent within an application, to a specific other application, or broadcast for any application to handle. Each application declares what types of intent it can handle, based on the action, URI, and MIME type. When an intent is broadcast, the OS will launch the user's preferred default app for that intent if there is one, or else will ask the user to choose from a list of available apps (and optionally set a default).
The "Share" command in the stock Android browser sends an ACTION_SEND event with type text/plain and the page address and description in the EXTRA_TEXT property. It uses Intent.createChooser to force the OS to prompt the user for an app, rather than launch the default app.
Fennec could do the same, and the native app chooser UI would appear just as it does in the stock browser. Or we could enumerate the available apps for ACTION_SEND text/plain using the PackageManager queryIntentActivities method, and display our own app chooser UI.
Maemo
Proposal: We will introduce a new URI scheme "share:" (name is subject to change). Any Maemo app that supports sharing should include a .desktop file with "share" in the X-Osso-URI-Actions line, and a [X-Osso-URI-Action Handler share] section.
When the user shares a file, Fennec will query Maemo for apps that support the "share:" scheme, and will use D-Bus to open the selected app with a URI like the following:
share:uri=http://limpet.net/mbrubeck/&title=Matt%20Brubeck
The app is expected to open a sharing UI pre-filled with the link and title. It may also allow the user to enter additional information (description, tags, categories) before saving the link.
For compatibility with existing mail and messaging apps, we will also look for apps that support "mailto:" or "sms:" URIs, and open them with with appropriate URIs.
Web Sites
Users can also share via web sites, without leaving the browser or launching a native app. In Fennec 2.0a1 we have hard-coded support for three sites (Facebook, Twitter, and Google), and we allow Fennec add-ons to extend this list.
Proposal: We should add a way for web sites to extend the sharing list without writing Fennec add-ons. This could work similar to OpenSearch discovery. The site's header would include a link to an XML file (schema TBD) that tells the browser how to share links via that site:
<link rel="share" href="sharing-settings.xml">
Unlike a Fennec add-on, this would be easy for sites to deploy, and could be supported by any browser.
Research
- Primacy of social networking on mobiles
- Teen mobile phone usage (lots of texting)
- How are people sharing:
- [ESP. THIS] Google research on online vs. real world social + sharing behavior
summary of design-actionable findings:
- prioritize SMS - it's becoming the most important mechanism for mobile sharing
- support sharing multiple independent groups of friends
- people have 4-6 groups of 2-10 people each
- most sharing will happen with the same 4-6 contacts; a two level friends list with those 4-6 at the top, and an "everybody else" afterwards would make sense
- can we figure out who these people are awesome-algorithm-style?
Mockups
The sharing task flow will be
- Initiate sharing
- identify item to share
- select sharing as intended action
- choose mechanism for sharing
- choose who to share with (unless broadcast sharing, in which case it's "everybody"
- annotate
- complete/send
The order of 2 and 3 will vary, depending on whether the browser knows about the user's contacts.
Initiating Sharing
Site Menu
Bookmarking panel
A possibility - I like the task-flow association here, in that most thing that are important enough to share are also probably good candidates for bookmarking. In fact, I items that you share through one of the other entry points should probably be automatically bookmarked.
Context actions
Anroid-specific
- Preference seems to be for this approach:
- versus this "quick-launch" UI pattern:
This is the point where the user has to choose either a mechanism for sharing or a person with whom to share, depending on the approach we take.
- in the short term, before the browser can keep track of a user's contacts, we have to rely on the sharing app itself (email, sms) to know who the user's contacts are. This means that the user has to pick a mechanism through which to share in the browser:
- this is the longer-term approach (that I prefer) - letting the user choose who to share with (rather than how to share) in the browser. This lets the browser be clever suggesting likely contacts to share with, and dynamically creating sharing groups based on sharing behavior.
Annotation (for services)
Annotation is a central part of sharing. People don't just send a link to a friend - they say "look at this" or "should I buy this?" or "this is where I am," etc.
Through directed sharing like email or SMS, people can annotate in the email or SMS app (given that we're handing off to these apps for the version of the sharing feature). For broadcast sharing through a service like twitter or facebook, it would be best to just pass the link directly to the service (if the user is logged in). On Android, where the system will know if there's a twitter or facebook app, we may want to pass to it directly. On other platforms, if we can't do this, we'll want to provide a basic annotation step, as in the following:
