588508 - Simple sharing implementation

Status: RESOLVED WONTFIX

(Firefox :: General, defect)

Description

[Alex Limi (:limi) — Firefox UX Team]

Goal: Improve the Sharing menu with minimal infrastructure investment and code requirements for Firefox 4. Do the simplest thing possible to make it easier to share pages/links with friends. Opportunistic project, but would be a great improvement to the current setup.

* There's an entry “Sharing” in the main Firefox menu, as well as an entry in the context menu on a page.

* There's no UI for the sharing itself, we just send them to the respective web sites using the official query string used for these types of interactions.

* The menu entries are filtered based on which sites you have saved passwords for + sites that are present in your history. They are sorted by frecency. If icons are stored with the history entry, we should use that.

* We ship with the top N social networks / sharing services by number of users, but the menu only surfaces the ones that you have visited or saved passwords for.

* Version 2 of the sharing menu could expose an API for adding a site, but we want to do the simplest thing that can possibly work this late in the cycle.

Comment 1

[Alex Limi (:limi) — Firefox UX Team]

Attachment: Simple mock-up with some details on the implementation

Comment 2

[Justin Dolske [:Dolske]]

AIUI from beltzner, this is indeed wanted but needs to be balanced again taking resources from blocker work.

If we're going to proceed, I think the first cut of this needs to be pared back to just the base bones:
 * Share Link menu item
 * email + ~3 top social sites
 * No places / password manager checking

I presume this needs to be localizable, too, so that different locales can specify the sites popular in their regions? Though as a first pass just a static list of globally-popular sites would be ok, but we'd need to know what the Fx4 end-point must be.

I also presume we would need Kev's (?) assistance in making sure these sites are OK with us shipping this to 400M users, and any paperwork that might entail?

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

That's correct; it would be nice to replace "Send Link..." in the context menu with something that was a little less 1990s, and aware of the fact that a lot of people send links via social networking sites.

Requirements:
 - localizable (so we can tailor services per locale)
 - extensible (via Jetpack, ideally)
 - uses existing published APIs (no hacks, please!)
 - done in partnership with sites (so we're kept up to date with API changes)
 - can be implemented in a day or so of focused hacking

I think the other parts of the spec are non-goals for a first implementation.

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

Facebook API: http://www.facebook.com/share/
Twitter API: http://dev.twitter.com/pages/tweet_button
MySpace API: http://wiki.developer.myspace.com/index.php?title=Category:RESTful_API

Those might be useful for skunkworks testing.

Comment 5

[:Margaret Leibovic]

Attachment: wip

Here's a wip patch that adds email, twitter, buzz, and facebook options to a file->share menu.

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

Margaret: if you end up doing this (because, I dunno, you run out of blockers) you may find that most APIs make the "put the UI in a panel instead of an additional tab" pretty easy; Facebook and Twitter sure do, they seem like they're optimized to be put in popup windows (which we could just do in a panel). Let us know what you find. That's a better user experience, and I was downplaying it (as I suspect were Dolske and Limi) because we feared it'd be more work, but it might end up being easier.

Comment 7

[:Margaret Leibovic]

I just went for the easiest approach first ;)

I agree that a panel would provide a better experience than a tab, but what should that look like? It's not immediately clear to me where it should go. Is there something we already do that I could imitate?

Comment 8

[Ragavan S [:rags]]

(In reply to comment #3)
> That's correct; it would be nice to replace "Send Link..." in the context menu
> with something that was a little less 1990s, and aware of the fact that a lot
> of people send links via social networking sites.
> 
> Requirements:
>  - localizable (so we can tailor services per locale)
>  - extensible (via Jetpack, ideally)
>  - uses existing published APIs (no hacks, please!)
>  - done in partnership with sites (so we're kept up to date with API changes)

>  - can be implemented in a day or so of focused hacking

That's not a product requirement, right? :) 

> 
> I think the other parts of the spec are non-goals for a first implementation.

I think storing a local copy of what's been shared is also a requirement.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #8)
> I think storing a local copy of what's been shared is also a requirement.

No, indeed it is not.

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: facebook share in a <panel>

Margaret - kinda like this, where the Facebook content would be in a <panel> overtop of the window

(really quick cut n' paste mockup)

Comment 11

[Ragavan S [:rags]]

(In reply to comment #9)
> (In reply to comment #8)
> > I think storing a local copy of what's been shared is also a requirement.
> 
> No, indeed it is not.

Why not? It feels weird to allow people to share something from the browser, but us not being able to make it easy for them to see their "Shared Items" list easily. Or making that data available to others via sane APIs.

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

Because we have zero time to build the UI to view the information, and inserting the extra information into Places adds risk. As expressed in earlier comments, this is the simplest possible implementation to improve the sharing experience from only exposing "mailto:"

Other issues, like the one you mention, can be addressed in follow-up bugs, but will merely distract this effort, and reduce the liklihood of us doing anything in time for Firefox 4.

Thus: not a requirement; a nice-to-have, most certainly. If this gets in, we can make followup bugs. (In fact, you can file them now, set them to depend on this one)

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

Margaret: thought better of it, split the <panel> request off into a new bug, depending on this one. Let's just do the simple thing, first.

Comment 14

[Ragavan S [:rags]]

(In reply to comment #12)

> 
> Thus: not a requirement; a nice-to-have, most certainly. If this gets in, we
> can make followup bugs. (In fact, you can file them now, set them to depend on
> this one)

Filed: https://bugzilla.mozilla.org/show_bug.cgi?id=588628

I understand the "do the simplest thing first" approach and that makes a lot of sense especially given timelines. Just noting a concern that if we do get the simplest thing into Firefox 4, and it's a hit (yay!), then we've made it difficult to help users to look at what they've shared.

Comment 15

[Alex Limi (:limi) — Firefox UX Team]

(In reply to comment #14)
> I understand the "do the simplest thing first" approach and that makes a lot of
> sense especially given timelines. Just noting a concern that if we do get the
> simplest thing into Firefox 4, and it's a hit (yay!), then we've made it
> difficult to help users to look at what they've shared.

They already have this functionality, so nothing is made worse, only better. :)

(And this is with the understanding that faaborg and myself are big fans of adding it to a list so you can find it later, be it a special category in history or an automatically populated "Shared" bookmarks folder :)

Comment 16

[:Margaret Leibovic]

Attachment: patch

This adds a hardcoded set of share options to file->share and context menus. I got rid of all (I think) "Send Link..." references. In the context menu I kept the idea of the separate sendLink/sendPage options, but just switched them to shareLink/sharePage. I labeled them both "Share" since they were both "Send Link..." before, but maybe we can change that to make it clearer what's going on.

Comment 17

[Mike Beltzner [:beltzner, not reading bugmail]]

Can you attach a quick screenshot of how that plays out?

Comment 18

[:Margaret Leibovic]

Attachment: menubar-share

Comment 19

[:Margaret Leibovic]

Attachment: context menu share

Comment 20

[:Margaret Leibovic]

Attachment: context menu share (activated from link)

Comment 21

[Michael Hanson]

Just a pointer - I've updated bug 588629 with links to the OExchange spec, which is provides a common API for the "share" verb and a discovery mechanism.  Not a lot of support yet, but bitly has it in their enterprise version.

Comment 22

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #21)
> Just a pointer - I've updated bug 588629 with links to the OExchange spec,

Yup; we're leaving that as a separate issue for now. If we can get to it before ship, so be it, if not, it'll come after. :)

Comment 23

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #19)
> Created attachment 467792 [details]
>   --> https://bugzilla.mozilla.org/attachment.cgi?id=467792
> context menu share

I think we'll want to differentiate between "page" and "link" in the context menu. So, if we're pulling window.location, use "Share Page" and if we're pulling it from a link beneath the mouse "Share Link"

Eventually we'll also want to "Share Image" and "Share Video" and stuff, but let's (once again) leave that for a follow-up.

Comment 24

[:Margaret Leibovic]

Attachment: patch-v2

Updated to distinguish between "Share Page" and "Share Link"

Comment 25

[:Margaret Leibovic]

Attachment: context menu -> share link

Comment 26

[:Margaret Leibovic]

Attachment: context menu -> share page

Comment 27

[:Margaret Leibovic]

Attachment: file menu -> share page

Comment 28

[:Margaret Leibovic]

shorlander, welcome to this bug! I want your opinion: 

I'm going to start work to incorporate icons into the share menu as seen in limi's mockup (attachment 467084 [details]). I can use the favicons from the various services' websites for most of them, but what icon do you think I should use for the share->email option?

Comment 29

[Stephen Horlander [:shorlander]]

Attachment: OS X Mail Icon

We have mail icons already for Windows and Linux:

chrome://browser/skin/preferences/mail.png

But oddly the Mac version never made it in so I am attaching it.

Comment 30

[LegNeato]

Not sure if we are close to the tango style on Linux, but here are some icons that are public domain: https://launchpad.net/breakdance (view at http://cubestuff.wordpress.com/)

Comment 31

[:Margaret Leibovic]

Attachment: patch-v3

Added icons.

Comment 32

[:Margaret Leibovic]

Attachment: file menu -> share page

Comment 33

[:Margaret Leibovic]

Attachment: context menu -> share link

Comment 34

[:Margaret Leibovic]

Attachment: context menu -> share page

Comment 35

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Is there a reason not to use Twitter's share page, rather than the full home/status page that the patch currently uses? The share page is much more lightweight, and is specifically designed for this use. 

URL format is: http://twitter.com/share?text=TEXT&url=URL

Comment 36

[:Margaret Leibovic]

Blair, thanks for noticing that! The reason for using the full home/status page is that I must have done a very cursory web search for which URL to use, so I missed that Twitter had a share page :) I will update the patch to use the share URL!

Comment 37

[Justin Dolske [:Dolske]]

Comment on attachment 467966 [details] [diff] [review]
patch-v3

Just a few nits, and since you're attaching a new patch anyway for the last comment...

>+++ b/browser/base/content/browser-context.inc
...
>+          <menuitem id="context-sharebuzz"
>+                    label="&shareBuzzCmd.label;"
>+                    accesskey="&shareBuzzCmd.accesskey;"
>+                    class="menuitem-iconic"
>+                    image="data:image/png;base64,iVBORw0KGgoAAAANBRRRRZZZZZZZZZ..."

I think the images here should be moved into files, if for no other reason than avoiding having giant blobs in the XUL.

And then there's the wonderful issue of where to put the images, since they're owned by others. They probably ought to live in /other-licenses/, with some make/package -fu to use them when MOZ_OFFICIAL_BUILD (or is just whatever --enable-official-branding sets?), and otherwise a blank/transparent icon. Or just remove the iconic menu class? Not sure which is easier to implement.

>+                    oncommand="gContextMenu.shareLink('Buzz');"/>

Could eventually make this generic by having:

  <menuitem url="http://foo/%URL%/blah/%TITLE%"
            oncommand="gContextMenu.shareLink(this)"/>

with a shareLink() that grabs the attribute and replaces strings. But what you've got here is fine, since this feature is still taking form.
            

>+function sharePage(aService, aWindow, aURL) {
>+  let url = aWindow ? aWindow.location.href : aURL;
>+  let title = aWindow ? aWindow.document.title : aURL;

Just make this sharePage(aURL, aTitle), and have the callers pass in the right values. [Allowing aTitle to be null for when it's not needed/known, with |title = aTitle || aURL| if needed here


>+      openUILinkIn("http://twitter.com/home?status=" +
>+                   encodeURIComponent(title) + " " + 
>+                   encodeURIComponent(url), "tab");

encodeURIComponent(title + " " + url) ?

Comment 38

[Justin Dolske [:Dolske]]

Oops, forgot to add:

Now that the new appmenu has landed (bug 583386), you should update the appmenu_sendLink to be Share Link. Ick, that's 4 places with this submenu, guess we really ought to find a way to share a single submenu implementation.

And that also reminds be, the IDs should be unique on the submenu items. Maybe it's easiest to just make them class=, since the ID isn't actually used.

Comment 39

[:Margaret Leibovic]

Attachment: patch-v4

Addressed issues from comment 35, comment 37 and comment 38.

Comment 40

[Axel Hecht [:Pike]]

I don't think this is going to fly in Germany as is. Both Google and Facebook are under *heavy* flak for their privacy and user-choice decisions over here, so I'd consider bug 589998 to be a requirement (making the sharing services localizable).

And I can't promise that we can lift bug 589998 from the l10n side, tbh, that's not just an en-US code problem.

Comment 41

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #40)
> so I'd consider bug 589998 to be a requirement (making the sharing services
> localizable).

Comment 3 dictates that making the services localizable is a requirement to entry, yes.

> And I can't promise that we can lift bug 589998 from the l10n side, tbh, that's
> not just an en-US code problem.

Of course not; but I'm pretty confident that within a few months we can get a set of locale-specific services for this. In cases where we don't, we'll still have the ability to share by email, right? Let's talk about it over in that bug, not here.

Comment 42

[Axel Hecht [:Pike]]

Sure, my comment was mostly focused on getting this into Fx4, and it was unclear which of the split off bugs was a blocker and what was a "good to have if we do this".

With a few months time, we'll be totally fine to handle localizing this.

PS: 'g' is probably the wrong accesskey for 'Buzz'?

Comment 43

[Justin Dolske [:Dolske]]

Comment on attachment 468531 [details] [diff] [review]
patch-v4

Canceling review, since this is no longer targeting Firefox 4. Will pick it back up for Firefox.next, but we'll probably do a different implementation any (eg, pull user's likely sites from Places or something like that).

Comment 44

[:Margaret Leibovic]

This bug was about an attempt at squeezing a simple feature into Firefox 4, which has come and gone. AIUI, the F1 people are still working on making a more robust sharing feature for us to eventually include in Firefox, so I'm marking this as a WONTFIX.