Last modified: 2014-08-25 14:45:32 UTC
Created attachment 14857 [details] No Preview when a user shares a Wikipedia article on Twitter. Currently, dropping a wikipedia link in twitter does not generate any type of summary card. A preview helps understand what the link is about and affects engagement. Certainly there might be some legacy reasons here, but can we address this? Twitter is an important knowledge graph.
Related Twitter Links - https://dev.twitter.com/docs/cards/large-image-summary-card
Would be great if someone could explain the legacy (Surely it hasn't been done for a reason) Does that reason still hold good?
I've shared links on Facebook and Twitter and other services in the past and have noticed that these do not render nicely at all. It should be really trivial to fix this but yes I'd also be interested to hear if there are any good reasons why it hasn't been done...
(In reply to Jon from comment #3) > I've shared links on Facebook and Twitter and other services in the past and > have noticed that these do not render nicely at all. It should be really > trivial to fix this but yes I'd also be interested to hear if there are any > good reasons why it hasn't been done... Looking at <https://dev.twitter.com/docs/cards/large-image-summary-card>, it seems this is implemented via meta tags. This bug report is probably fairly similar to bug 30113, which Jared just linked as a see also. In my opinion, it feels a bit icky to litter the head of the HTML output of every page with proprietary (and arguably faddish) meta tags. Setting up generic meta tags or some other means of programmatically transferring this data might be a worthwhile goal. It isn't unprecedented for MediaWiki to include features similar to this as configuration options (the Apple Icon config variable comes to mind off-hand).
Oh dear at that bug report.. :) Yeh, the proprietary meta tags are nasty on closer inspection. I'm surprised no standardisation here has happened yet :( I'm torn -bringing in new readers by drawing them in with pretty images and interesting descriptions is a good thing. I wonder if there is some way to achieve the same goal without the og: metatags.
Note that [[mw:Extension:TwitterCards]] exists
@Kunal, is the extension done?
Is there a performance hit if we add open graph tags to the HTML header?
It's not really about performance - it's about including a bunch of non-standard HTML markup specific to Twitter / Facebook. It then raises a big question of when do we support meta tags? What if another big social network site also has their own meta tags? Eventually we'd have a ton of meta tags... we should be careful if we do this that we clarify what the criteria is for us to support sharing on that site... I can imagine some objections to these from hardcore community members but they could be potentially enabled on a project basis by request via enabling the TwitterCards extension (which currently looks to be experimental but could go through the necessary hurdles to be made standard)
Wanted to read over everyones point of view here before responding. I'll try to address everyone's concerns… We have a reader decline, its backed by hard numbers, any creative solution for bringing more readers and contributors into the project should be seriously discussed without being dismissed out of hand. Calling twitter a passing fad is dismissive to others who do hard work on that project (let's not be negative people) their user base is 2/3s, or equal to wikipedias depending on the metric you uses, so its not insignificant by any means. We already do plenty of platform or use case specific code for IE compatibility so this is nothing new. The Twitter Card tags are very lightweight as I'm sure other developers have pressured them to be so. The benefits far outweigh any cruft to the pages in my mind, it also gives us far more control over the look and feel of how are content is displayed on 3rd party services which is crucial to maintaining the standard we have for displaying license and rights related to our content when used outside our sites. Next Steps: I'm having Ori look over Harsh's extension for any performance issues, and Dario is taking a look in order to see if there are any changes that can or should be made to help us better measure the effects of a change like this on traffic from referring sites. If it gets the blessing of Ori, my recommendation is to go forward with enabling the extension on WMF sites for now, measure the effect on traffic and evaluate in a few months.
Jared I agreed with you, I just wanted to make sure we consider this and I think the reasoning you give above is spot on and I would struggle to argue against it. This sounds like a great first step. Looking forward to seeing this go through. Kunal are you able to help push this forward? Happy to help in any code reviews to do so...
Here are twitter stats on DAU's/ MAU's http://www.statisticbrain.com/twitter-statistics/ Anyone have numbers for twitter referral traffic to Wikipedia?
(In reply to Jared Zimmerman (WMF) from comment #10) > We have a reader decline, its backed by hard numbers, any creative solution > for bringing more readers and contributors into the project should be > seriously discussed without being dismissed out of hand. What reader decline are you referring to? Wikimedia wikis get about 21 billion pageviews per month, according to <http://reportcard.wmflabs.org/>. As I understand it, the combined traffic of Wikimedia wikis puts us in the top ten of all Web sites on the Internet. We have no issue reaching hundreds of millions of readers every month. > We already do plenty of platform or use case specific code for IE > compatibility so this is nothing new. Lack of browser support is considered a bug. Lack of completely optional meta tags is considered a feature request. Let's be clear here, please. > I'm having Ori look over Harsh's extension for any performance issues, and > Dario is taking a look in order to see if there are any changes that can or > should be made to help us better measure the effects of a change like this > on traffic from referring sites. > > If it gets the blessing of Ori, my recommendation is to go forward with > enabling the extension on WMF sites for now, measure the effect on traffic > and evaluate in a few months. This talk of "effect on traffic" is kind of laughable. At twenty-one billion pageviews a month, I'm not really sure what kind of bump you're hoping for by adding a few proprietary meta elements to the head of every page.
Max, I'm still a little unclear on your argument against this small change which gives us a lot more control over how our content appears on 3rd party sites in ways that better suit our licensing and TOS. If your issue is performance surely the evaluation by Ori can confirm or deny that that will be an issue. if your issue is some personal thing against twitter, fine, noted. But that doesn't really have much bearing on the bug. What i'm proposing is that we make a small change, measure, and evaluate. Do you have an issue with that plan?
MZ to play devils advocate would such a chance drop traffic? Even if the increase is miniscle on English Wikipedia dont underestimate it on a smaller project...
(In reply to Jared Zimmerman (WMF) from comment #14) > If your issue is performance surely the evaluation by Ori can confirm or > deny that that will be an issue. Yes, I think you're missing the point. The only people to have repeatedly mentioned performance concerns are yourself (comment 10 and bug 62845) and Vibha (comment 8). Jon specifically stated in comment 9 that this isn't about performance. Meanwhile, in addition to inserting performance concerns into this discussion, you (Jared) are also arguably spreading fear, uncertainty, and doubt by arguing that there's a reader decline that must be addressed (comment 10). > if your issue is some personal thing against twitter, fine, noted. But that > doesn't really have much bearing on the bug. In my mind, this isn't a technical issue, it's a social issue. The technical side of this is pretty simple (insert a few extra tags into the <head> of every page). What steps have you, Vibha, or anyone else on the design team taken to gauge whether the Wikimedia community wants to add these tags? It's certainly possible that most people either won't care or will prefer to have the tags, but I'd suggest finding out first. If you've already had these discussions, please include links. :-) > Do you have an issue with that plan? Yes, as explained in the preceding paragraph.
I ask again, what is the argument against this in your mind, "social issue" is too vague for me to understand.
Adding meta tags specific for Twitter would anger many Wiki(p|m)edians because it would be seen as favoring Twitter over [insert favorite social network here]. [[Wikipedia:PERENNIAL#Share_pages_on_Facebook.2C_Twitter_etc.]] is the basic argument against any form of catering to specifically one site.
(In reply to Jared Zimmerman (WMF) from comment #17) > I ask again, what is the argument against this in your mind, "social issue" > is too vague for me to understand. I believe MZ is suggesting that this is the kind of change that ought to be 'floated' onwiki first. It has a very good chance of being supported - we'd all like the world to see more content from wikimedia - especially if a trial-run convinces more people to click-through to our sites. However, changing our html output for the benefit of a single site is not a common occurance (afaik), especially for a commercial site (no matter how unbelievable it is that anyone ever clicks ads!). As Jon notes in #c5, these are somewhat ungood proprietary meta tags... Editors would worry about: A) a well-defined endpoint to the trial-run, if it isn't a fairly clear "success" (metrics need to be defined, and whether we can measure the difference quantitatively needs to be verified), B) slippery slope outcomes - eg would we also then consider metadata output especially for Indenti.ca and Google+ and Facebook and IMDB and etc. (or conversely, do we already do this for some sites, and this would fill a gap? Extension:OpenGraphMeta exists, but isn't installed on Enwiki. I'm not sure what we already do.) C) technical reversability and criteria for removal - it's nice to have assurances that if/when Twitter enters its Myspace decline, we can cleanly remove this extension, and that it will be done willingly. Further notes are in https://wikimania2013.wikimedia.org/wiki/Submissions/How_sitewide_preferences_get_changed HTH. (In reply to Kunal Mehta (Legoktm) from comment #18) > Adding meta tags specific for Twitter would anger many Wiki(p|m)edians > because it would be seen as favoring Twitter over [insert favorite social > network here]. > > [[Wikipedia:PERENNIAL#Share_pages_on_Facebook.2C_Twitter_etc.]] is the basic > argument against any form of catering to specifically one site. Indeed. Although, if approached in the right way, and *oh dear god* without those site's icons being thrust in our faces constantly (either well hidden, or plaintext only), then it might be nice to re-address this one some day. Getting more eyeballs on our brilliant prose and fabulous images, might be worth a single "share" link. (But that's a separate discussion)
Quiddity, that sounds like a reasonable proposal. The discussion on social media share buttons doesn't strike me as particularly relevant here, as the present proposal is about content distribution, not about making changes that affect the user experience. However, the concerns about adding cruft are legitimate and it would definitely be helpful to see a more articulated proposal about what a trial-run would look like and how we could go about testing its impact. Wikimedia sites already have provisions "for the benefit of single sites" or 3rd party partners: carriers participating in Wikipedia Zero or Pediapress are the most obvious examples that come to my mind: these are the relevant use cases that should be compared to the present proposal as they all involve distribution of content. I personally think that – unlike other cases of intermediaries on which Wikimedia literally has no control (Google Knowledge Panel) or only the ability to opt out (Google QuickView for mobile search) – a test on content distribution on which we retain full control is welcome. A summary of the most recent analysis of traffic trends (which identified a declining trend in 2013 in desktop pageviews and a very high exposure to search engines for incoming traffic compared to other top web properties) was presented at Monthly Metrics last month. [1] [1] https://commons.wikimedia.org/wiki/File:2013_Wikimedia_traffic_trends.pdf
(In reply to Jared Zimmerman (WMF) from comment #17) > I ask again, what is the argument against this in your mind, "social issue" > is too vague for me to understand. It's about time you familiarise with the concept then, especially as it's the WMF way to call something that the community calls with a more aggressive term. Thanks Legoktm and Quiddity for providing training. (In reply to Dario Taraborelli from comment #20) > Wikimedia sites already have provisions "for the benefit of single sites" or > 3rd party partners: carriers participating in Wikipedia Zero or Pediapress > are the most obvious examples that come to my mind None of these is in MediaWiki core and both are very different situations from what proposed here (though they have their issues): * Wikipedia Zero is a history of partnerships but from MediaWiki perspective is comparable to action=print (neutral technology), * Collection extension links/linked PediaPress as a component of the infrastracture relied on them and they are the authors of the extension. Anyway, moving this to Extension requests until there is evidence of this being considered appropriate for core. I'm rather disappointed that time is being wasted by us here on surreal conversations when there is a simple ten lines patch that allegedly improves the situation for everyone (without special consideration for specific players): https://gerrit.wikimedia.org/r/#/c/108221/8/includes/Skin.php,cm
So… is this bug "please enable [[mw:Extension:TwitterCards]] on WMF wikis"? If so, this should be a site request…
(In reply to James Forrester from comment #22) > So… is this bug "please enable [[mw:Extension:TwitterCards]] on WMF wikis"? > If so, this should be a site request… Question seconded. Requesting users can test on one of the 3 wikis where we know it's installed: https://wikiapiary.com/wiki/Extension:TwitterCards
@Nemo, Thank you for that suggestion, however the 3 wikis that are supposedly using the extension, either are not using it, have it misconfigured, or no longer exist. It is therefore not possible to use them to test. I think moving this to be an extension (enablement) request makes sense, thanks for doing that. I don't know that anyone proposed or cared if this was explicitly in core, only the outcome that it work was the issue.
My recommendation here is to: * set this feature up on a beta wiki for poking and testing; * find someone to audit and improve the code, particularly with regard to support for file description pages (i.e., /wiki/File:Foo.png); and * open a discussion with the Wikimedia Commons community about whether there would be any objection to enabling the TwitterCards extension. Perhaps not in that order, depending on the level of technical investment you're willing to make for an uncertain outcome. I'm proposing this series of steps because there's an open request from Commons at bug 61487 and the Commoners are notoriously more mellow than, say, English Wikipedians. ---- I continue to think that implementing a more generic approach to programmatically transferring metadata from our content would be dramatically wiser (e.g., implementing generic meta elements or looking into Daniel F.'s suggestion about ARIA labels). However, as noted in this bug report, adding Twitter-specific meta elements, even to MediaWiki core, isn't really particularly egregious, in my opinion. Especially in comparison to other vendor-specific code we have. I'll stay neutral on whether to enable the TwitterCards extension on Wikimedia wikis; it personally feels icky, but whatever. Anyone interested in seeing the TwitterCards extension enabled on a Wikimedia wiki should check with a few Wikimedia communities to see if this neutrality is shared. As also noted in this bug report, there's general opposition to catering to sites such as Twitter on some Wikimedia wikis, while other Wikimedia wikis such as the English Wikinews include share icons and are more receptive to social media sites.
Thanks, MZMcBride, thats very helpful.
Great recommendation there MZ. That seems like a great way forward of achieving the goal of testing the impact of such a change.
Do we have someone who wants to volenteer for step 1? "set this(extension) up on beta.wiki for poking and testing"
Anyone doing this (writing the extension) should be familiar with the context of the various (competing) metadata standards. I'm willing to elaborate as I have decent (recent) experience: I was the technical lead of the LRMI project, which wrote the "Education" extension to Schema.org, through my work at Creative Commons. RDFa, Schema.org microdata, FB opengraph, twitter cards, etc etc need to be carefully thought about in tandem. See also: https://www.mediawiki.org/wiki/Extension:HTML_Tags That extension was written to implement Schema.org metadata (Full disclosure: I funded Max Klein to lead the effort, who subcontracted out to Yaron to write the extension, again, through my work at Creative Commons). It can probably be extended to fit multiple use-cases including twittercards, fb fauxpen graph, etc, if wanted.
(Previous comment mostly with just my personal Greg Grossmeier hat on.) With my Release Manager hat on, see also: https://www.mediawiki.org/wiki/Review_queue
(Sorry for the spam, I'm badly multitasking right now...) At a minimum, a security review is needed to move forward/put on Beta Cluster. HTML Tags has this bug for the security review and deploy to dewiki (no movement for a long time, not much impetus): https://bugzilla.wikimedia.org/show_bug.cgi?id=47566
If Security review is the pending action, I've assigned to Chris Steipp. Chris, feel free to reassign if you can't do this, or think someone else should.
Security review is certainly not the pending action. There are 8 items before it and you still lack point 10 too: (In reply to Greg Grossmeier from comment #30) > With my Release Manager hat on, see also: > https://www.mediawiki.org/wiki/Review_queue
Nemo: So which of those 8 items before security review is not fulfiled yet?
(In reply to Andre Klapper from comment #34) > Nemo: So which of those 8 items before security review is not fulfiled yet? Which *is* fulfilled? Proposers should probably give evidence. :)
Please let Vibha, Jared, and whoever else is interested in contributing to this feature, work on the points of the checklist at https://www.mediawiki.org/wiki/Review_queue . They are not supposed to be a linear sequence, aren't they? (maybe those # should be *, but I digress). Greg is the gatekeeper for deployments to Wikimedia projects, and it turns out that he is also someone with first hand knowledge about the problem this feature request is trying to address.
I submitted I8e22a7a13aada2fb3b446923cec13b8496b9bc7a, which is a major re-write of the extension. You can test it on <http://legoktm.wmflabs.org/>. I also did some more research into the topic. According to <https://dev.twitter.com/docs/cards/markup-reference>, many of the twitter meta fields will try to fallback upon their opengraph equivalents, which would theoretically let us handle Facebook, Google+ (<https://developers.google.com/+/web/snippet/>), and Twitter with one set of meta tags. More input from people (greg-g) who actually know about the various meta tags and their histories/adoption would be helpful. My initial thoughts are to just have a general OpenGraph extension, and have a config flag to enable extra twitter cards functionality.
My preference: 1) Implement Schema.org support. It's the biggest de facto metadata standard since Google, Bing, and Yahoo support it in their search results. 2) After 1, implement bits of OpenGraph/TwitterMarkup as/where needed. You really don't want to get in the business of maintaining compat with 3 metadata standards in their completeness; go with the smallest subset that works for the use case. Of course, looking at the TwitterCards "standard", they don't play nicely at all. *grumble site-specific metadata standards* <insert oprah winfrey joke here>
(In reply to Greg Grossmeier from comment #38) > Of course, looking at the TwitterCards "standard", they don't play nicely at > all. *grumble site-specific metadata standards* <insert oprah winfrey joke > here> More thinking post coffee... With my "I used to be in the metadata standards industry" hat on (same with above comment, just FYI): sure, whatever, ugly up our html source with every new site specific tags we want. It's ugly from a standards and developer maintenance perspective but I have no other sensible solutions if we want to actually have any support at all (other than, you know, all those site specific 'standards' to go away and we all just use Dublin Core as $deity intended ;) ). With my RelManager hat on: I defer to the ubiquitous checklist of things that need to be done to be deployed (reviews etc).
Thanks Greg, I reviewed the Schemea.org documentaion, and it doesn't acutally clearly state anything that would make me think it would cover this bug, I had a hard time even finding refernces to it improving support for twitter cards (maybe this is what you were saying with your second comment) Either way since this is an extension do you really feel that it will "ugly up our html source" isn't that the point of an extension to keep this kind of thing separate from core?
(the "I used to be in the metadata standards industry" hat back on) (In reply to Jared Zimmerman (WMF) from comment #40) > Thanks Greg, I reviewed the Schemea.org documentaion, and it doesn't > acutally clearly state anything that would make me think it would cover this > bug, I had a hard time even finding refernces to it improving support for > twitter cards (maybe this is what you were saying with your second comment) Right: Schema.org is a general purpose metadata standard and as such is used in many more places online and has better coverage. TwitterCards are Twitter specific and they don't play nice with other metadata standards out there. > Either way since this is an extension do you really feel that it will "ugly > up our html source" isn't that the point of an extension to keep this kind > of thing separate from core? It (the extension) will modify the HTML <HEAD> to include a ton of TwitterCard specific metadata. It's not about Core vs non-Core, it's about our <HEAD> (which is in our HTML) ;) See, eg, this from the wordpress.com site: --------------- <!-- Facebook --> <meta xmlns:fb="//www.facebook.com/2008/fbml" property="fb:page_id" content="134098913979"> <meta xmlns:fb="//www.facebook.com/2008/fbml" property="fb:app_id" content="249643311490"> <meta property="article:publisher" content="https://www.facebook.com/WordPresscom" /> <!-- Jetpack Open Graph Tags --> <meta property="og:type" content="blog"> <meta property="og:title" content="WordPress.com"> <meta property="og:description" content="Start a WordPress blog or create a free website in seconds. Choose from over 200 free, customizable themes. Free support from awesome humans."> <meta property="og:url" content="http://wordpress.com/"> <meta property="og:site_name" content="WordPress.com"> <meta property="og:image" content="http://0.gravatar.com/blavatar/653166773dc88127bd3afe0b6dfe5ea7?s=200"> <!-- Twitter --> <meta name="twitter:card" content="summary" /> <meta name="twitter:site" content="@wordpressdotcom" /> <meta name="twitter:creator" content="@wordpressdotcom" /> <meta name="twitter:app:name:iphone" content="WordPress" /> <meta name="twitter:app:id:iphone" content="335703880" /> <meta name="twitter:app:name:ipad" content="WordPress" /> <meta name="twitter:app:id:ipad" content="335703880" /> <meta name="twitter:app:name:googleplay" content="WordPress" /> <meta name="twitter:app:id:googleplay" content="org.wordpress.android" /> --------------- Summary: Adding more and more stuff to <HEAD> is annoying but doable and fine. It just sucks from the perspective of someone who cares about web metadata standards and is anti-proliferation/redundancy.
== Checklist == === DONE === # Create a tracking bug: This here bug. # Create Extension: mediawiki.org page: [[mw:Extension:TwitterCards]] # Request a component in [[Bugzilla]]: Done. # Get the extension code in [[Gerrit]]: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/TwitterCards # Request a [[WMF Project Design Review Process|design review]], if applicable: Not applicable (just <HEAD> additions) === Not Done === # Request (and respond to) a product review: I assume Jared is acting PM on this? # Request (and respond to) a performance review: bug 62845 (not done) # Request (and respond to) a security review: bug 64967 (not done) # Show community support/desire for the extension to be deployed: not done.
@greg, I certainly see the need to "Show community support/desire for the extension to be deployed" for a full deployment, but that seems like a lot of legwork if all we want to do it determine if it even has an effect on traffic… https://bugzilla.wikimedia.org/show_bug.cgi?id=64930 if there is no appreciable effect on inbound traffic from twitter then we'd better know how to prioritize a full rollout.
Its a catch-22 of sorts. Which wikis would this make the most noticeable impact? Probably enwiki and other big ones. Definitely not the test wikis, as cool as Page390 is (https://test.wikipedia.org/wiki/Page390) ;) I'll defer to others regarding the proposed 1 month test period (with review/consultation afterwards, I assume) to assess impact (and whether or not more traffic is a trump card. I think Quiddity's comment above (https://bugzilla.wikimedia.org/show_bug.cgi?id=62811#c19) is a good re-read (as are all of his comments, generally).
