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?
This is what I'd like to do for my site. No tracking and very simple. Thoughts?
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.
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)
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.
Any idea how/where we want to present this now? It will be easy to implement and has a big upside!
(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?
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  or simple window.open  links  https://bugzilla.mozilla.org/show_bug.cgi?id=875062#c3  https://bugzilla.mozilla.org/show_bug.cgi?id=875062#c10
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.
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?
Luke, could you have a look at deliverable #2 and think about how you'd like to track this in Google Analytics?
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?
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
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:..."
Commits pushed to master at https://github.com/mozilla/kuma https://github.com/mozilla/kuma/commit/b277758c42ef311cc55dd60f13e3f0121fdd879c bug 875062 - Add initial framework for social sharing on MDN https://github.com/mozilla/kuma/commit/0db7a5177b6b0593bad4df1edab3e4c0af18c0dd Bug 875062: Social Share - add styles https://github.com/mozilla/kuma/commit/a5c240295e4a8b9031f5505ea8645b09f8433856 Bug 875062: Add URL shortening https://github.com/mozilla/kuma/commit/77cb75c84479e3e3aabf0a114ff29e81160a1486 Bug 875062: resolving error with rebase https://github.com/mozilla/kuma/commit/c8067e1aef2a6e92971b385a6a487b66ebe4a44d Bug 875062: Updated wording for share text. https://github.com/mozilla/kuma/commit/03b711a937a79899cded2787c8164df38216ec70 bug 875062 - move and update tests https://github.com/mozilla/kuma/commit/1b87788115ba03ea965fdc331f0909e636db46d2 bug 875062 - gettext wrap the share_text in view https://github.com/mozilla/kuma/commit/89455ed44eaff43f2449a2aba51a275d26150acb bug 875062 - change medium to 'doc share link' https://github.com/mozilla/kuma/commit/7de757d1710c770c831ba9be47705b28e3db3458 Merge pull request #3124 from groovecoder/social-share-875062 bug 875062 - Add initial doc sharing
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.
> :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 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.  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.
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.
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.
(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.
Whiteboard: [specification][type:feature][patchwelcome] → [specification][type:feature]
:groovecoder, can you share preliminary data on this with us?
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. 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.  http://webmasters.stackexchange.com/questions/85732/do-shorter-urls-really-outperform-longer-urls
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: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.