Mobile/Archive/Sharing
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
(Need to document how to discover and invoke Maemo apps through .desktop files and dbus.)
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:
