Closed Bug 875062 Opened 12 years ago Closed 8 years ago

Social sharing for MDN pages

Categories

(developer.mozilla.org Graveyard :: General, defect)

Product:
developer.mozilla.org Graveyard
Component:
General
Platform:
All
Other
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jswisher, Unassigned, Mentored)

References

Details

(Whiteboard: [specification][type:feature])

Attachments

(3 files)

NewSocial.jpg
9.02 KB, image/jpeg
Details
Screen Shot 2015-03-12 at 15.01.32.png
194.42 KB, image/png
Details
share_mock.png
306.16 KB, image/png
Details
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.
Kate is a good person to talk to about tools to use for social sharing.
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.
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?
Flags: needinfo?(dwalsh)
Attached image NewSocial.jpg —
This is what I'd like to do for my site. No tracking and very simple. Thoughts?
Flags: needinfo?(dwalsh)
Cool. Until this is prioritized, I'll make it a mentored bug in case someone wants to take it on.
Whiteboard: [specification][type:feature] → [specification][type:feature][mentor=groovecoder]
Is this still under development?
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.
Flags: needinfo?(hhabstritt.bugzilla)
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.
Flags: needinfo?(hhabstritt.bugzilla) → needinfo?(craigcook.bugz)
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.
Flags: needinfo?(craigcook.bugz)
FWIW, my screenshot and what I will be using on my site are simple window.open links, not an official widget of any service.
(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.
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.
(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.
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.
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.
Any idea how/where we want to present this now? It will be easy to implement and has a big upside!
(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.
(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?
Mentor: lcrouch
Whiteboard: [specification][type:feature][mentor=groovecoder] → [specification][type:feature]
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.
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
Flags: needinfo?(dwalsh)
1000% window.open
Flags: needinfo?(dwalsh)
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.
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.
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.
Keywords: productwanted
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 ;)
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?
Flags: needinfo?(dwalsh)
Luke, could you have a look at deliverable #2 and think about how you'd like to track this in Google Analytics?
Flags: needinfo?(lcrouch)
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
Flags: needinfo?(lcrouch)
Whiteboard: [specification][type:feature] → [specification][type:feature][patchwelcome]
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.
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?
Flags: needinfo?(dwalsh)
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
Flags: needinfo?(jswisher)
How important is localization for this first trial period?
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
> > 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:..."
This feature is enabled on production for super-user testing. :jms, :hoosteeno - want to try it out?
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.
Attached image 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
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.
IIRC, we have issues when trying to put things (:openjck - the edit button?) in the sidebar because some pages don't have a TOC.
Flags: needinfo?(jkarahalis)
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.
Flags: needinfo?(jkarahalis)
Under the left side bar is complicated. IN the left side bar might be more possible.
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.
I uplifted comment 43 to bug 1145630, which now blocks this one. Excited to see progress on this!
(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.
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.
Flags: needinfo?(jswisher)
Keywords: productwanted
Whiteboard: [specification][type:feature][patchwelcome] → [specification][type:feature]
:groovecoder, can you share preliminary data on this with us?
Flags: needinfo?(lcrouch)
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/
Flags: needinfo?(lcrouch)
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?
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.
(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).
(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.
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
See Also: → 1229884
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
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
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
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: