Why.
Why does an encyclopedia need a share button? I can see the purpose on Commons, but for an article? I just don't see the justification. What do you really need to share with your friends from an reference source. What does a button do that copypaste can't?
There's also the technical problems this would incur. Each of these buttons require yet another HTTP request each, which would make the hard work by RL team moot.
It just doesn't make sense.
On Oct 20, 2011 11:54 PM, jidanni@jidanni.org wrote: Gentlemen, where is the Share button? All other sites have them by now, but on Wikipedia one cannot even find its definition in http://en.wikipedia.org/wiki/Share . At least on ones account preferences there should be a way to "activate sharing with the following websites ... " causing a share button to appear in the navigation menu. If there is an extension, then wikipedia should install it and not depend on browser plugins, etc. OK, I made https://bugzilla.wikimedia.org/show_bug.cgi?id=31853
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
This sounds like something non-technical, like you would discuss at a village pump. Maybe you should do that and then get back to us with a greater variety of user opinions? If you're right and this is a dumb idea, then you'll save us a lot of time by canvassing users. -russ
On Fri, Oct 21, 2011 at 9:27 AM, John Du Hart compwhizii@gmail.com wrote:
Why.
Why does an encyclopedia need a share button? I can see the purpose on Commons, but for an article? I just don't see the justification. What do you really need to share with your friends from an reference source. What does a button do that copypaste can't?
There's also the technical problems this would incur. Each of these buttons require yet another HTTP request each, which would make the hard work by RL team moot.
It just doesn't make sense.
On Oct 20, 2011 11:54 PM, jidanni@jidanni.org wrote: Gentlemen, where is the Share button? All other sites have them by now, but on Wikipedia one cannot even find its definition in http://en.wikipedia.org/wiki/Share . At least on ones account preferences there should be a way to "activate sharing with the following websites ... " causing a share button to appear in the navigation menu. If there is an extension, then wikipedia should install it and not depend on browser plugins, etc. OK, I made https://bugzilla.wikimedia.org/show_bug.cgi?id=31853
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I agree with this, it's really not a technical issue at this point so it doesn't have a place on wikitech-l
On Fri, Oct 21, 2011 at 10:06 AM, Russell Nelson russnelson@gmail.comwrote:
This sounds like something non-technical, like you would discuss at a village pump. Maybe you should do that and then get back to us with a greater variety of user opinions? If you're right and this is a dumb idea, then you'll save us a lot of time by canvassing users. -russ
On Fri, Oct 21, 2011 at 9:27 AM, John Du Hart compwhizii@gmail.com wrote:
Why.
Why does an encyclopedia need a share button? I can see the purpose on Commons, but for an article? I just don't see the justification. What do you really need to share with your friends from an reference source. What
does
a button do that copypaste can't?
There's also the technical problems this would incur. Each of these
buttons
require yet another HTTP request each, which would make the hard work by
RL
team moot.
It just doesn't make sense.
On Oct 20, 2011 11:54 PM, jidanni@jidanni.org wrote: Gentlemen, where is the Share button? All other sites have them by now, but on Wikipedia one cannot even find its definition in http://en.wikipedia.org/wiki/Share . At least on ones account preferences there should be a way to "activate sharing with the following websites ... " causing a share button to appear in the navigation menu. If there is an extension, then wikipedia should install it and not depend on browser plugins, etc. OK, I made https://bugzilla.wikimedia.org/show_bug.cgi?id=31853
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Russell Nelson russnelson@gmail.com writes:
This sounds like something non-technical, like you would discuss at a village pump. Maybe you should do that and then get back to us with a greater variety of user opinions?
Posted this issue at http://hexm.de/8m.
Mark.
On Fri, Oct 21, 2011 at 12:15 PM, Mark A. Hershberger mhershberger@wikimedia.org wrote:
Posted this issue at http://hexm.de/8m.
The above link is to :
http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29#Does_Wik...
URL shorteners are evil in general, and especially so on archived mailing lists.
* Shortened URLs make it difficult to search for link substrings in the list archives * Users cannot tell the true destination of the link without loading it * To load the link, users are forced to share their IP address with the server that does the URL expansion * A random server for the shortened URLs is not likely to be as reliable as Wikipedia in the long term.
- Carl
"Carl (CBM)" cbm.wikipedia@gmail.com writes:
On Fri, Oct 21, 2011 at 12:15 PM, Mark A. Hershberger mhershberger@wikimedia.org wrote:
Posted this issue at http://hexm.de/8m.
The above link is to :
http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29#Does_Wik...
As of this morning, I count 21 "support" and 25 "oppose".
Part of the opposition was how I phrased it. Wikipedia obviously doesn't "need" a share button.
I also didn't make it clear that I didn't think we should or would use any one else's "share" button since that would allow them to track their users through Wikipedia. As a result, I didn't count the one opposition that seemed primarily concerned with the tracking issue.
Someone pointed to http://en.wikipedia.org/wiki/User:TheDJ/Sharebox and I tried it out, but it only worked after disabling the Firefox extension that I use to stop trackers. I'm glad TheDJ has made this available for those that want to use it, but I would like to get something else in place that doesn't share data with any intermediaries (such as AddThis.com) beyond the place that the user actually wants to share the page.
Mark.
On Fri, Oct 21, 2011 at 3:27 PM, John Du Hart compwhizii@gmail.com wrote:
There's also the technical problems this would incur. Each of these buttons require yet another HTTP request each, which would make the hard work by RL team moot.
That depends on whether the icons are hosted offsite or not. If the icons are hosted at WMF, we can use data URI embedding as we normally do for icons, and there would be virtually no additional cost. If the icons are hosted offsite, we would indeed incur one extra HTTP request per icon, but we would also be sharing private data (IP address and Referer header) with a third party, which is forbidden in our own privacy policy. This is the reason why we absolutely cannot have the Facebook Like button: Facebook makes you use an FB-hosted button image (and JS too, I think), collects data from every user that views the Like button even if they don't click it (this is the part that violates the privacy policy), and disallows self-hosting.
Roan
Use a jsMsg or the new version of it, and deliver images as data url in the css. If you use ordinary lmages in a scripted html-tingy it will load a long time after the dom is generated. Most social networks can be accessed with a single url, but it is a lot of sites right now. We have 36 at no.wp and that isn't everyone.
So far as to create the request to the social network to do a posting isn't really difficult. The problem is if you add text and images in the posting and you want the posting to update as the article itself is changed.
John
On Sun, Oct 23, 2011 at 7:03 PM, Roan Kattouw roan.kattouw@gmail.com wrote:
On Fri, Oct 21, 2011 at 3:27 PM, John Du Hart compwhizii@gmail.com wrote:
There's also the technical problems this would incur. Each of these buttons require yet another HTTP request each, which would make the hard work by RL team moot.
That depends on whether the icons are hosted offsite or not. If the icons are hosted at WMF, we can use data URI embedding as we normally do for icons, and there would be virtually no additional cost. If the icons are hosted offsite, we would indeed incur one extra HTTP request per icon, but we would also be sharing private data (IP address and Referer header) with a third party, which is forbidden in our own privacy policy. This is the reason why we absolutely cannot have the Facebook Like button: Facebook makes you use an FB-hosted button image (and JS too, I think), collects data from every user that views the Like button even if they don't click it (this is the part that violates the privacy policy), and disallows self-hosting.
Roan
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi,
On Sun, Oct 23, 2011 at 7:03 PM, Roan Kattouw roan.kattouw@gmail.com wrote:
This is the reason why we absolutely cannot have the Facebook Like button: Facebook makes you use an FB-hosted button image (and JS too, I think), collects data from every user that views the Like button even if they don't click it (this is the part that violates the privacy policy), and disallows self-hosting.
German IT news site heise.de solved the privacy and load-time problem: http://www.heise.de/extras/socialshareprivacy/
Unfortunately it's in German, but the code is easy to understand.
Marco
On Sat, 29 Oct 2011 06:17:43 -0700, Marco Schuster marco@harddisk.is-a-geek.org wrote:
Hi,
On Sun, Oct 23, 2011 at 7:03 PM, Roan Kattouw roan.kattouw@gmail.com wrote:
This is the reason why we absolutely cannot have the Facebook Like button: Facebook makes you use an FB-hosted button image (and JS too, I think), collects data from every user that views the Like button even if they don't click it (this is the part that violates the privacy policy), and disallows self-hosting.
German IT news site heise.de solved the privacy and load-time problem: http://www.heise.de/extras/socialshareprivacy/
Unfortunately it's in German, but the code is easy to understand.
Marco
That's not really all that much of a solution:
- Right now it's pretty stuck in 3 vendors - It doesn't scale very well. If you do try to add more vendors and users do enable most of them, you still end up loading from each enabled vendor slowing things down. - Frankly the UI is pretty bad. - Likely due to FB's terms the FB icon isn't actually the FB icon until you enable it. So there's even a chance that a user won't even know they 'can' share on FB because the FB button doesn't look like a FB button. - Once you enable a vendor we drop right back to a 3rd party script being injected into the page such that it can do malicious things.
Btw, if you're a 3rd party with a script in a page you can go pretty far abusing XHR and history.pushState to make it look to a user like they're browsing the website normally when in reality they're on the same page with the script still running. Oh, and that includes making it look like you're safely visiting the login page when in reality you didn't change pages and the script is still running ready to catch passwords.
On Sat, Oct 29, 2011 at 12:18 PM, Thomas Gries mail@tgries.de wrote:
I don't like a "share" button. Tom
It doesn't think much of you either.
Would you share a "like" button?
On Sat, Oct 29, 2011 at 4:22 PM, Daniel Friesen lists@nadir-seen-fire.com wrote:
- It doesn't scale very well. If you do try to add more vendors and users
do enable most of them, you still end up loading from each enabled vendor slowing things down.
With the exception of the FB Like/Recommend button, everything (even the FB share link) is just an image paired with a HTML link. Maybe other sites allow embedding their logos, so the only image which needs to be loaded externally is the FB one.
- Frankly the UI is pretty bad.
That's the price you have to pay for total privacy, unfortunately.
- Once you enable a vendor we drop right back to a 3rd party script being
injected into the page such that it can do malicious things.
Btw, if you're a 3rd party with a script in a page you can go pretty far abusing XHR and history.pushState to make it look to a user like they're browsing the website normally when in reality they're on the same page with the script still running. Oh, and that includes making it look like you're safely visiting the login page when in reality you didn't change pages and the script is still running ready to catch passwords.
Do you have any links with further info on this?
Marco
On Sun, 30 Oct 2011 01:12:51 -0700, Marco Schuster marco@harddisk.is-a-geek.org wrote:
On Sat, Oct 29, 2011 at 4:22 PM, Daniel Friesen lists@nadir-seen-fire.com wrote:
- It doesn't scale very well. If you do try to add more vendors and
users do enable most of them, you still end up loading from each enabled vendor slowing things down.
With the exception of the FB Like/Recommend button, everything (even the FB share link) is just an image paired with a HTML link. Maybe other sites allow embedding their logos, so the only image which needs to be loaded externally is the FB one.
No, both the Twitter and Google +1 share features in that socialshareprivacy are also embeds, not simple images paired with links. In fact while FB has a static share and Twitter has it's static share and intents, being the newest +1 hasn't implemented a static share feature yet. Likely somewhat related to the separation of +1 and G+ which unlike with the others +1ing something doesn't mean you're using G+.
- Frankly the UI is pretty bad.
That's the price you have to pay for total privacy, unfortunately.
No, there are other potential possibilities that don't include a bad ui.
- Once you enable a vendor we drop right back to a 3rd party script
being injected into the page such that it can do malicious things.
Btw, if you're a 3rd party with a script in a page you can go pretty far abusing XHR and history.pushState to make it look to a user like they're browsing the website normally when in reality they're on the same page with the script still running. Oh, and that includes making it look like you're safely visiting the login page when in reality you didn't change pages and the script is still running ready to catch passwords.
Do you have any links with further info on this?
Marco
I don't know of any specific links you can look at, I realized it myself after looking at pushState. It's probably known elsewhere but I figured it out independently so I don't know of any more detailed articles or posts on it off my head.
wikitech-l@lists.wikimedia.org