Last Comment Bug 875062 - Social sharing for MDN pages
: Social sharing for MDN pages
Status: RESOLVED FIXED
[specification][type:feature]
:
Product: Mozilla Developer Network
Classification: Other
Component: General (show other bugs)
: unspecified
: All Other
-- normal with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors: Luke Crouch [:groovecoder]
Depends on: 1145630 1162998 1182210 1200659
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-22 13:16 PDT by Janet Swisher
Modified: 2016-06-07 09:46 PDT (History)
12 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
NewSocial.jpg (9.02 KB, image/jpeg)
2014-03-26 08:38 PDT, David Walsh :davidwalsh
no flags Details
Screen Shot 2015-03-12 at 15.01.32.png (194.42 KB, image/png)
2015-03-12 15:04 PDT, Stephanie Hobson [:shobson]
no flags Details
share_mock.png (306.16 KB, image/png)
2015-03-19 11:40 PDT, Justin Crawford [:hoosteeno] [:jcrawford]
no flags Details

Description User image Janet Swisher 2013-05-22 13:16:43 PDT
What problems would this solve?
===============================
Promote awareness, generate pageviews and inbound links, and increase prestige of MDN members externally to MDN.

Who would use this?
===================
Anonymous and logged-in users could share any page. Logged-in users could share pages after saving updates.

What would users see?
=====================
"Share this article" option on any page.

After clicking "Save Changes", users would see a "Share your changes" option.

What would users do? What would happen as a result?
===================================================
Choosing the option would give the opportunity to share the URL on some set of social networks. 

Default text for the "Share your changes" option would be something like "I just updated [link,title] on MDN". After the appropriate authentication dance, the message would be posted on the selected social network.

Is there anything else we should know?
======================================
There may already be a bug for this, but probably not for the "share your changes" idea.
Comment 1 User image Janet Swisher 2014-03-19 13:40:46 PDT
Kate is a good person to talk to about tools to use for social sharing.
Comment 2 User image Katherine Naszradi [:knaszradi] 2014-03-19 13:48:04 PDT
Just let me know how I can help :) I'm not sure of any tool that specifically addresses this need that we're currently using but I am exploring, with the User Engagement Team, the possibility of utilizing Social Raid (http://socialraid.com/) or getting a contract Expion (http://www.expion.com/) in Q3. In addition, our program's landing page is implementing a Twitter feed so visitors to the site can see real-time updates. As far as being able to share directly from a site, I believe this would need to involve the Privacy team as I'm not sure what kind of data will be shared with the platform they are sharing on. CC'ing Michaela above who also has a breadth of knowledge on this subject.
Comment 3 User image Luke Crouch [:groovecoder] 2014-03-24 15:02:49 PDT
Looks like we could use https://github.com/mozilla/SocialShare/ like we do on Hacks for the first "Share this article" feature.

As for sharing changes, that might need something else/more.

:davidwalsh - what do you think here?
Comment 4 User image David Walsh :davidwalsh 2014-03-26 08:38:30 PDT
Created attachment 8397121 [details]
NewSocial.jpg

This is what I'd like to do for my site.  No tracking and very simple.  Thoughts?
Comment 5 User image Luke Crouch [:groovecoder] 2014-03-26 10:08:35 PDT
Cool. Until this is prioritized, I'll make it a mentored bug in case someone wants to take it on.
Comment 6 User image pupunmajumder 2014-04-05 08:39:23 PDT
Is this still under development?
Comment 7 User image Luke Crouch [:groovecoder] 2014-04-05 15:09:20 PDT
It's still a good idea, but we haven't decided *how* to add it to the pages. 

Might need a quick review from :habber on :davidwalsh's https://bugzilla.mozilla.org/show_bug.cgi?id=875062#c4.
Comment 8 User image Holly Habstritt Gaal [:Habber] 2014-04-06 16:15:13 PDT
This is a great idea and I definitely support doing it in the 2 places that Janet mentioned. On the articles themselves and for editors after making an update. 

On Mozilla.org we use our "Share This" widget. I'm unsure if we can make it look like David's example in #c4 since it requires the user to click on a "Share this" link before exposing the social channels.

See a post on the mozilla blogs to see how it works. (screenshot - http://cl.ly/image/3Y3A2e0R1e3P)  
https://blog.mozilla.org/webdev/2014/04/02/enabling-communities-iterating-on-the-get-involved-page/

This is what has been vetted with the privacy team. Craig would know more about the extent that we can modify this. 

(In reply to Luke Crouch [:groovecoder] from comment #7)
> It's still a good idea, but we haven't decided *how* to add it to the pages. 
> 
> Might need a quick review from :habber on :davidwalsh's
> https://bugzilla.mozilla.org/show_bug.cgi?id=875062#c4.
Comment 9 User image Craig Cook (:craigcook) 2014-04-07 14:26:36 PDT
The sharing widget uses the standard JavaScript-embedded buttons provided by Twitter, Facebook, and Google+. Any customization of the buttons will be dependent on the options their respective APIs provide. I'm not sure the treatment in David's screenshot is possible in a privacy-respecting way, but I could be wrong. It would entail some way to hook into all three remote APIs that a) complies with their API usage requirements, b) respects user privacy, and c) gives us complete control over the appearance of those buttons.

Getting the count of how many times a URL has been shared means telling Twitter/Facebook/Google what the URL is, and if that happens on pageload I assume the request is sending other identifiable information as well (it certainly does with the standard buttons). The sharing widget just avoids sending the request until the user makes a deliberate action (opening the menu), rather than sending the request automatically on pageload.

We have very little control over the appearance of the standard buttons. We're just linking to a script hosted by the third parties, and each script in turn renders the button, usually in an iframe with all kinds of ugly markup around it, so we can't do much to change their appearance with CSS on our end.
Comment 10 User image David Walsh :davidwalsh 2014-04-07 14:28:58 PDT
FWIW, my screenshot and what I will be using on my site are simple window.open links, not an official widget of any service.
Comment 11 User image Craig Cook (:craigcook) 2014-04-07 15:15:12 PDT
(In reply to David Walsh :davidwalsh from comment #10)
> FWIW, my screenshot and what I will be using on my site are simple
> window.open links, not an official widget of any service.

How are you getting the share counts? Is that data available from their APIs without loading a widget?

Facebook did have a passive sharing form that accepted a link with a query string but it was deprecated. With Twitter I believe you can still link to twitter.com with a query string to pre-compose the tweet, but they discourage that (and may have officially deprecated it by now, I could be wrong). I don't know about G+. I admit I haven't read up on any of these sharing APIs lately so maybe they all offer more methods of getting data without leaking user info back to the mothership.
Comment 12 User image David Walsh :davidwalsh 2014-04-07 15:17:14 PDT
Getting them all via JSONP, and I know that the Twitter API is deprecated.  IMO, the counts are vanity metrics which don't need to be there.
Comment 13 User image Craig Cook (:craigcook) 2014-04-07 15:24:34 PDT
(In reply to David Walsh :davidwalsh from comment #12)
> Getting them all via JSONP, and I know that the Twitter API is deprecated. 
> IMO, the counts are vanity metrics which don't need to be there.

Oh they're absolutely vanity metrics and serve no real purpose (one could say they encourage more sharing because they indicate a page's popularity maybe, but that's grasping). 

If we can make links that share passively without loading anything from a third party (or just fetch third party data without sending any user data) then we can do whatever we want, stylewise.
Comment 14 User image Janet Swisher 2014-04-07 20:37:13 PDT
Does it make any difference in privacy if the counts are collected but not displayed to users? I think it would be useful to have metrics about what pages are shared most often on what services. But I don't see that as an essential part of the user-facing functionality.
Comment 15 User image Luke Crouch [:groovecoder] 2014-04-08 09:22:15 PDT
Making any client-side request to twitter.com or facebook.com allows the 3rd-party site to track the user on our page. So, we hide those requests behind a user intention to share the page on social media.

If we hit their API's or endpoints from the backend we don't need to send any user data to the 3rd-party services to get the counts. But I don't see any API doc's that explain how to get that data via backend, and hacking something up probably violates API terms of use.

We could try an A/B test to learn if displaying the counts actually increases sharing activity.
Comment 16 User image David Walsh :davidwalsh 2014-05-29 12:31:56 PDT
Any idea how/where we want to present this now?  It will be easy to implement and has a big upside!
Comment 17 User image David Bruant 2014-05-29 13:07:29 PDT
(In reply to Janet Swisher from comment #14)
> I think it would be useful to have metrics about what
> pages are shared most often on what services.
At least Facebook and Twitter have ways to gather these metrics.
For instance, to know how many time the page https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Proxy was shared on Facebook and Twitter, go to 
* Facebook : https://graph.facebook.com/?id=https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Proxy (it's currently 4 apparently).
* Twitter : http://urls.api.twitter.com/1/urls/count.json?url=https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Proxy (14 now)

Not sure about how reliable these APIs are in the long term (at least the Twitter doesn't seem to be an official API).

Super worst-case scenario, it's always possible to get this data with a Casper.js script or equivalent.
Comment 18 User image Luke Crouch [:groovecoder] 2014-05-29 15:02:03 PDT
(In reply to David Walsh :davidwalsh from comment #16)
> Any idea how/where we want to present this now?  It will be easy to
> implement and has a big upside!

Maybe this is something good for our new MDN developer/designer staffer to take on?
Comment 19 User image Florian Scholz [:fscholz] (MDN) 2014-08-06 05:54:57 PDT
I like those numbers. Might also be another indicator for localizers to see which page is trending and therefore makes sense to translate. But sure we don't want to track anyone.

So, anyone wants to take this? If someone outlines some starting points, I can have a look, too.
Comment 20 User image Luke Crouch [:groovecoder] 2014-08-06 07:49:05 PDT
Next step - :davidwalsh needs to decide: SocialShare [1] or simple window.open [2] links

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=875062#c3
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=875062#c10
Comment 21 User image David Walsh :davidwalsh 2014-08-06 08:15:44 PDT
1000% window.open
Comment 22 User image Stephanie Hobson [:shobson] 2014-10-14 11:13:23 PDT
I would like to see goals set for these before we implement them with a commitment to remove them if they are not being sufficiently used. (Something like, if they are used by less than 0.3% of users we remove them or if we get less than 2,000 visitors a month through shared links). 

Related: in an ideal world we append campaign tracking variables to the links before they are shared so we know how many users have arrived via shared links.
Comment 23 User image Stephanie Hobson [:shobson] 2014-10-14 11:15:54 PDT
When discussing whether or not to include numbers keep in mind most of the time the number will be zero. I'd rather not display them, just have them available some other way.
Comment 24 User image Janet Swisher 2015-03-12 14:21:12 PDT
I've written up a requirements doc: https://docs.google.com/a/mozilla.com/document/d/1NgAl1uBpkzb4ZDqvNmy_oKqN0Mtg1uHUMh-9oJbK8kw/edit#

To KISS, I've omitted both the display of the tweet count and explicit sharing of edits.
Comment 25 User image Stephanie Hobson [:shobson] 2015-03-12 15:04:04 PDT
Created attachment 8576941 [details]
Screen Shot 2015-03-12 at 15.01.32.png

The requirements are great Janet :) Nice to see a narrow scope to begin with. There isn't anything in there I disagree with. 

I've attached a mockup of where we might position the buttons on an article and what they might look like. This is just a start, we should A/B test the crap out of this ;)
Comment 26 User image Stephanie Hobson [:shobson] 2015-03-12 15:05:19 PDT
David if I create a branch with the HTML and CSS could you add the JS to it since we'll mostly be re-using what's on your site already?
Comment 27 User image Stephanie Hobson [:shobson] 2015-03-12 15:09:53 PDT
Luke, could you have a look at deliverable #2 and think about how you'd like to track this in Google Analytics?
Comment 28 User image Luke Crouch [:groovecoder] 2015-03-12 16:15:43 PDT
It may depend on implementation. If JavaScript, we can use trackEvent [1], like so:

mdn.analytics.trackEvent{
  category: 'Share',
  action: 'click'
}

The event is recorded in GA with the page, so we'll know which page was shared.

If we use plain HTML links that open new windows to twitter.com, we are already recording those outbound links in GA. [2]

In either case, though, it's impossible for us to measure the "Share" clicks on twitter.com. :/ So we'll have to just measure our own clicks, and then potentially compare to periodic spot-checks on twitter.com.

[1] https://github.com/mozilla/kuma/blob/cef467b56701d0b0c321ee55eacd0ca94c63285b/media/redesign/js/analytics.js#L9-L51
[2] https://github.com/mozilla/kuma/blob/cef467b56701d0b0c321ee55eacd0ca94c63285b/media/redesign/js/analytics.js#L56-L88
Comment 29 User image Justin Crawford [:hoosteeno] [:jcrawford] 2015-03-13 08:54:38 PDT
The specs on this are looking good. Opening it up to contributors who have energy/time to work on it. Leaving productwanted on it until it lands on a roadmap.
Comment 30 User image Stephanie Hobson [:shobson] 2015-03-17 08:47:21 PDT
There is now a PR that includes everything except URL click tracking :)

MDN has bit.ly integration but the functions are currently generating bit.ly URLs not mzl.la URLs. To get this done quickly we could:
1) not shorten URLs, and not track them
2) use bit.ly URLs

Any preferences? Any strong desire to put this off 2 months until someone has the time to look into mzl.la shortening?
Comment 31 User image Stephanie Hobson [:shobson] 2015-03-17 08:48:46 PDT
Right now the suggested share is the article <title> plus URL. Example:
> <canvas> - HTML (HyperText Markup Language) | MDN https://developer-local.allizom.org/en-US/docs/Web/HTML/Element/canvas

I think we want to try to make this a little friendlier. To start the discussion I suggest:
> I found this article about <canvas> on MDN: https://developer-local.allizom.org/en-US/docs/Web/HTML/Element/canvas
Comment 32 User image Stephanie Hobson [:shobson] 2015-03-17 08:48:58 PDT
How important is localization for this first trial period?
Comment 33 User image Stephanie Hobson [:shobson] 2015-03-17 09:03:58 PDT
I take Comment 30 back! The mzl.la shortening is working on production, the API just doesn't like to do it in our local dev environments :D
Comment 34 User image Justin Crawford [:hoosteeno] [:jcrawford] 2015-03-17 14:33:21 PDT
> > I found this article about <canvas> on MDN: https://developer-local.allizom.org/en-US/docs/Web/HTML/Element/canvas

I would like to make it even more encouraging: "I learned about <canvas> from this article on MDN:..."
Comment 36 User image Luke Crouch [:groovecoder] 2015-03-18 12:56:16 PDT
This feature is enabled on production for super-user testing.

:jms, :hoosteeno - want to try it out?
Comment 37 User image Eric Shepherd [:sheppy] 2015-03-19 09:17:37 PDT
I'm playing with this some and have thoughts...

First, I wonder if we could just go with the logos of each of the services instead of the logo plus text in each button. I don't know if that's better or worse, but the buttons as they are feel very bold to me. That's possibly just me.

Second, I do think it's worth considering looking for a way to have those available at the top of the page somewhere. Maybe smaller buttons right under the title? That seems like a good possibility: just little icon-only buttons there, and then maybe stick with the existing style at the bottom of the page.

Third, and possibly most importantly, I'm not a fan of the current default text. I think it should be made more focused on the recipient than the sender. Something like "Learn about X on MDN!" That way, it doesn't risk denigrating the knowledge level of the sender, but invites others in to join us in knowledge.
Comment 38 User image Justin Crawford [:hoosteeno] [:jcrawford] 2015-03-19 11:40:23 PDT
Created attachment 8580192 [details]
share_mock.png


> :jms, :hoosteeno - want to try it out?

I think the functionality looks good. 

There is something visually jarring about the buttons (echoes of comment 37) to me. They don't seem coordinated with our theme -- e.g. the only red thing on a very blue page is a Google+ button. I think the sharing button on the fellowship page[0] is closer (but not perfect) to matching our theme.

Regarding the default text and the placement on the page: These are optimizations better made with data. But I think we will get more data if we put the share buttons higher to start. What about a more tightly coordinated set of buttons under the right sidebar? I attach a mockup -- very rough, not great.

I apologize for not seeing the earlier mockup in time to suggest this earlier.

[0] https://developer.mozilla.org/en-US/fellowship
Comment 39 User image Justin Crawford [:hoosteeno] [:jcrawford] 2015-03-19 11:44:41 PDT
A second comment: Regarding the effectiveness of share buttons, we have a bit of data now from the fellowship page. 0.4% of visitors to the page have clicked that button. The content is different, so it's not a perfect experiment. But...
* It's 10x our current (organic sharing) and
* It's .5x the 1% target in the spec

If we were aiming for that 1% target on the fellowship page (we're not) I would say we need to look for ways to make that button more effective -- probably starting with pushing it higher.
Comment 40 User image Luke Crouch [:groovecoder] 2015-03-19 13:16:46 PDT
IIRC, we have issues when trying to put things (:openjck - the edit button?) in the sidebar because some pages don't have a TOC.
Comment 41 User image John Karahalis [:openjck] 2015-03-19 13:50:41 PDT
We could put the buttons in the sidebar, but it would take more work. Bug 1124199 was rolled back when some problems were discovered in the implementation.
Comment 42 User image Stephanie Hobson [:shobson] 2015-03-19 14:18:27 PDT
Under the left side bar is complicated. IN the left side bar might be more possible.
Comment 43 User image Stephanie Hobson [:shobson] 2015-03-19 14:45:21 PDT
I think that our next step should be outlining 3 A/B tests we can run for placement and 3 A/B tests we can run for button design:

For location I suggest:
1) Top of the page under the title
2) Inside the right column TOC, at the bottom, if there is one on the page
3) End of the article (where they are now)

For button design I suggest:
1) Current design
2) Logo only, with no heading
3) A derivative of the fellowship design

I have concerns about what the current language says about the sharer's skill level but I disagree that the language should target the readers, I think making a tweet promotional rather than personal will cause fewer people to click through. I don't know how we test the language of the share text. I think we have to go live with something and see what kind of edits people are making to it.
Comment 44 User image Justin Crawford [:hoosteeno] [:jcrawford] 2015-03-20 08:20:44 PDT
I uplifted comment 43 to bug 1145630, which now blocks this one. Excited to see progress on this!
Comment 45 User image Eric Shepherd [:sheppy] 2015-03-20 08:24:27 PDT
(In reply to Stephanie Hobson [:shobson] from comment #43)

> I have concerns about what the current language says about the sharer's
> skill level but I disagree that the language should target the readers, I
> think making a tweet promotional rather than personal will cause fewer
> people to click through. I don't know how we test the language of the share
> text. I think we have to go live with something and see what kind of edits
> people are making to it.

That's fair. I'm not sure what language will be most effective either. Just gut feelings, I guess.
Comment 46 User image Janet Swisher 2015-03-20 11:27:04 PDT
Since "TIL" (today I learned) seems to be a common idiom in netspeak, my contribution to the bikeshed is: "Today I learned about <blah> on #MDN: <link>". People can shorten than to "TIL" if they want.
Comment 47 User image Justin Crawford [:hoosteeno] [:jcrawford] 2015-04-22 08:25:10 PDT
:groovecoder, can you share preliminary data on this with us?
Comment 48 User image Luke Crouch [:groovecoder] 2015-04-22 08:41:50 PDT
The first data coming back, from Apr 16 to Apr 22:

158 clicks to share; 47% Facebook, 29% Google+, 23% Twitter [1]

Top 10 shared pages [2]:

1.	
/en-US/docs/Security/Weak_Signature_Algorithm
14(8.86%)
	
2.	
/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/Array/concat
6(3.80%)
	
3.	
/en-US/docs/Mozilla/Projects/Rhino
5(3.16%)
	
4.	
/en-US/docs/Tools/Remote_Debugging/Debugging_Firefox_for_Android_with_WebIDE
5(3.16%)
	
5.	
/en-US/docs/Tools/Scratchpad
4(2.53%)
	
6.	
/en-US/docs/Web/CSS/border-radius
4(2.53%)
	
7.	
/en-US/docs/Web/Guide/API/WebRTC
4(2.53%)
	
8.	
/en-US/docs/Mozilla/Mobile/Viewport_meta_tag
3(1.90%)
	
9.	
/en-US/docs/Tools/Remote_Debugging
3(1.90%)
	
10.	
/en-US/docs/Web/HTML/Element/textarea	
3(1.90%)

14  (8.9% conversion) sessions came frame the 158 clicks to share. [3]

Sessions from social shares are good sessions too: 7 pages/session (vs. 1.79 avg) and 5:56 session duration (vs. 2:13 avg), 14.29% bounce rate (vs. 69.86%). Interesting to note that only 12% of sessions from social shares are new sessions (vs. 42% avg.). So, to date, the feature is working more as a referral -> retention feature than a referral -> acquisition feature?

[1] https://www.google.com/analytics/web/?authuser=1#report/content-event-events/a36116321w64965862p66726481/%3F_u.date00%3D20150416%26_u.date01%3D20150422%26explorer-segmentExplorer.segmentId%3Danalytics.eventAction%26_r.drilldown%3Danalytics.eventCategory%3ASocial Share%26explorer-table.plotKeys%3D[]/

[2] https://www.google.com/analytics/web/?authuser=1#report/content-event-events/a36116321w64965862p66726481/%3F_u.date00%3D20150416%26_u.date01%3D20150422%26explorer-segmentExplorer.segmentId%3Danalytics.pagePath%26_r.drilldown%3Danalytics.eventCategory%3ASocial Share%26explorer-table.plotKeys%3D[]/

[3] https://www.google.com/analytics/web/?authuser=1#report/trafficsources-campaigns/a36116321w64965862p66726481/%3F_u.date00%3D20150416%26_u.date01%3D20150422%26explorer-table.plotKeys%3D[]%26_r.drilldown%3Danalytics.campaign%3Ashare/
Comment 49 User image Florian Scholz [:fscholz] (MDN) 2015-05-08 08:25:04 PDT
Given http://moovweb.com/blog/anyone-use-social-sharing-buttons-mobile/ (tl;dr 0.6% of users use social media buttons on desktop and only 0.2% on mobile.), I wonder how much energy to put into this.

Do we have more data as of now? What is success of this feature?
Comment 50 User image Luke Crouch [:groovecoder] 2015-05-08 13:42:39 PDT
No more data since https://bugzilla.mozilla.org/show_bug.cgi?id=875062#c48 because we disabled the feature until we sort out bit.ly/mzl.la account limits.
Comment 51 User image Justin Crawford [:hoosteeno] [:jcrawford] 2015-05-08 13:48:33 PDT
(In reply to Florian Scholz [:fscholz] (MDN) from comment #49)
> Given http://moovweb.com/blog/anyone-use-social-sharing-buttons-mobile/
> (tl;dr 0.6% of users use social media buttons on desktop and only 0.2% on
> mobile.), I wonder how much energy to put into this.

While we don't have more data, we also don't have much more work. The work remaining is to figure out bit.ly and then enable the most effective of the A/B test candidates, and then we can see how our own audience uses it (it may not be the same as the e-commerce audience Moovweb studied).
Comment 52 User image Stephanie Hobson [:shobson] 2015-05-08 19:05:46 PDT
(In reply to Florian Scholz [:fscholz] (MDN) from comment #49)
> Given http://moovweb.com/blog/anyone-use-social-sharing-buttons-mobile/
> (tl;dr 0.6% of users use social media buttons on desktop and only 0.2% on
> mobile.), I wonder how much energy to put into this.
> 
> Do we have more data as of now? What is success of this feature?

Comment 24 has a link to the requirements which includes success metrics (0.1%). It also includes goals for measuring if they increase the traffic MDN gets from social media. I am super curious to see our own results, in the very early findings of the A/B tests some of the combinations were out performing our goal. 

We are also measuring to make sure that it does not effect user's engagement with the articles and have made sure to avoid some of the common problems with social sharing (privacy violations and slower load times).

And, as Justin says, once the bit.ly problems are sorted out all we have to do is toggle a waffle flag.
Comment 53 User image Justin Crawford [:hoosteeno] [:jcrawford] 2015-11-05 15:51:06 PST
After working at this code for a while, it's clear that using short links substantially increases the complexity of the feature. Briefly...
* We can't generate them for every request due to API rate limits; we need to store them in the database
* We can't generate the at request time and store them at that point, also due to API rate limits; we need to schedule generation and generate in the background
* We have to generate them for tens of thousands of documents at the start, and be prepared to generate them for large numbers of documents in the case of a move
* We can't generate short URLs for legacy documents in one big bang, due to API rate limits; we need to trickle out our generation of them in the background process
* We have to generate and store multiple links -- at least one per locale, since the slugs of articles are not consistent across locales
* Etc.

But surely all this engineering overhead is worth it? 

Actually, that's not assured. Threads on internal lists and questions in external forums have failed to surface a single compelling justification for using short links. Of course some social networks (Twitter) arbitrarily limit the length of social posts, but those networks apply their own URL shorteners to long URLs. And URL shorteners offer some analytical power, but we use Google Analytics and it works great. Yes, 2011 crowd wisdom says short links are better, but evidence of this is scant.[0] 

Conversely, there are reasonable arguments against using shortened links -- many feel they break the web in fundamental ways, and all would agree they obfuscate the destination of the URL. 

Considering all this, I would like to ship the social sharing feature without shortened links. It's a good feature; it's ready to ship; shipping it will immediately help MDN. We should not spend more cycles discussing or overengineering this feature to accommodate all the confounding factors.

I will close other bugs related to URL shortening and encourage the engineering team to release this feature with full-length URLs.

[0] http://webmasters.stackexchange.com/questions/85732/do-shorter-urls-really-outperform-longer-urls
Comment 54 User image MDN Team (:mdn-dev) 2015-12-14 10:26:53 PST
Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/13937d1e099b98564bfcd7f74154e2ed5164eefd
Bug 875062: Move share links to footer.

https://github.com/mozilla/kuma/commit/30a4eb4fe042e7eef1c1eb4b0ca11f68c6e406e3
Merge pull request #3697 from stephaniehobson/875062-share

Bug 875062: Move share links to end of article
Comment 55 User image Stephanie Hobson [:shobson] 2016-04-21 13:20:20 PDT
We haven't seen the usage for these links that we need to meet our success targets. I consulted with Kadir and will be removing them.

The success targets in the requirements document from comment 24 was "shares per visit". I wasn't able to figure out how the initial number (0.05%) was calculated so I calculated it again so the comparison would be fair. I used the number of tweets with links to MDN from some records Florian has been keeping (thanks!) and divided them by the number of visitors Google Analytics reported in the same time period.

Oct   | Jan   | Goal
0.04% | 0.05% | 0.10% 

Some fun stats:
- Twitter was the most popular of the buttons
- 19 users per day arrive from links posted via our share buttons
- Share buttons are clicked 163 times per day
Comment 56 User image MDN Team (:mdn-dev) 2016-06-07 09:46:40 PDT
Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/0e39a59cd6bebdae194ffce3e750fecdea3811be
Fix Bug 875062 - remove social sharing

https://github.com/mozilla/kuma/commit/ba14ff0ef4ed249f9208c3260119e4cc7e3e53ed
Merge pull request #3872 from mozilla/875062-social-share

Fix Bug 875062 - remove social sharing r=schalkneethling

Note You need to log in before you can comment on or make changes to this bug.