MZMcBride, I agree with you, but let me split out one thing:
On 20 August 2014 04:09, MZMcBride wrote:
the one complaint I _never_ hear is that Wikipedia has a readership problem.
Then you'll hear it from me.
First, let's make one thing clear: the reader doesn't exist; it's just a rhetorical trick, and a very dangerous one. For more: https://meta.wikimedia.org/wiki/Stupidity_of_the_reader
Page views, however brute a concept, exist; and I think they're telling us we do have a readership problem. For it.wiki, in the last year I see a suspiciously similar decrease in desktop pageviews and editing activity (possibly around –20 %). It would *seem* that every user converted to the mobile site is a step towards extinction of the wiki. Long story: https://meta.wikimedia.org/wiki/Research:The_sudden_decline_of_Italian_Wikipedia The page above is just a collection of pointers that I probably won't be able to pursue in the coming months, to study an unprecedented collapse of editing activity and active editors on it.wiki. However, there /are/ several things worth looking into and we do have a huge problem (or several). Can anything be done about it? I don't know. In its brief history, WMF software development has always been irrelevant for the increase of editing activity and reach. Let's hope for a counterexample.
Nemo
P.s.: Yes, this message is focused on one small thing only. That's just about what we are/were already doing, while most opportunities lie in what we're not doing, see the sister projects and [[strategy:List of things that need to be free]]; we like to think otherwise, but our free culture projects are still very marginal.
2014-08-21 9:30 GMT+03:00 Federico Leva (Nemo) nemowiki@gmail.com: It would *seem* that every user
converted to the mobile site is a step towards extinction of the wiki.
That is an excellent point Frederico. In addition to the inherent difficulties of editing on small screen, especially large articles and the "we know better approach" discussed in detail in the last weeks, there is also the problem of navigating between articles - the mobile website arbitrarily skips some elements visible on desktop, such as navboxes and significantly alter some infoboxes because "it doesn't look good". This makes it difficult to just browse the Wikipedia (thus finding mistakes that you might want to correct) and encourages searching for the information, which means going right on target
Hopefully the future announced at Wikimania, "no more mobile team, but mobile in every team" will solve some of these problems. It's just a matter of when will this future be.
Strainu
On 21 August 2014 10:31, Strainu strainu10@gmail.com wrote:
the mobile website arbitrarily skips some elements visible on desktop, such as navboxes
I've noticed this; and other deficiencies (such as no "did you know" on main page, not even as a link to a subpage).
and significantly alter some infoboxes because "it doesn't look good".
I'd not noticed this; can you give examples, please?
On 21 Aug 2014, at 13:03, Andy Mabbett andy@pigsonthewing.org.uk wrote:
On 21 August 2014 10:31, Strainu strainu10@gmail.com wrote:
the mobile website arbitrarily skips some elements visible on desktop, such as navboxes
I've noticed this; and other deficiencies (such as no "did you know" on main page, not even as a link to a subpage).
I thought this was set in the source code for the main page, see: https://www.mediawiki.org/wiki/Extension:MobileFrontend#Configuring_the_main... which would mean that this could easily be fixed if there was consensus. However, that documentation may be out of date, since I can't spot any mf- ID's in the enwp main page?
Thanks, Mike
2014-08-21 15:03 GMT+03:00 Andy Mabbett andy@pigsonthewing.org.uk:
On 21 August 2014 10:31, Strainu strainu10@gmail.com wrote:
and significantly alter some infoboxes because "it doesn't look good".
I'd not noticed this; can you give examples, please?
It seems this is not the case at en.wp, but take a look at how infoboxes (and especially coordinates) are displayed at ro.wp and fr.wp for [[:ro:București]]/[[:fr:Bucarest]]. There might be some underlying HTML problem that causes the box to move left, but what's the deal with the decimal coordinates? I thought we were trying to save bandwitdh?
2014-08-21 22:56 GMT+03:00 Michael Peel email@mikepeel.net:
I thought this was set in the source code for the main page, see: https://www.mediawiki.org/wiki/Extension:MobileFrontend#Configuring_the_main... which would mean that this could easily be fixed if there was consensus. However, that documentation may be out of date, since I can't spot any mf- ID's in the enwp main page?
Last edit to the main page on the subject is 31 May 2013. I haven't tried, but I would guess it's out of date.
2014-08-21 16:24 GMT+03:00 Risker risker.wp@gmail.com:
So - we know there is a definite cost to having all these "navigation aids" in articles. We need to justify their use, instead of simply adding them by reflex. So here is where analytics teams can really be useful: tell us whether or not these navboxes are actually being used to go to other articles. If they're widely used to leap to the next article, then we need
You mean on the desktop? Risker, why not talk to Erik Zachte directly and see if he can do anything withing the privacy policy's boundaries?
For me the conclusion would be not that we should drop them altogether in the mobile version (most of them are useful navigation means after all) but that the mobile version should be improved to parse them and to present them as a piece of plain text, not as a template.
Many of these templates have over 100 links in them; a surprisingly large number have "subtemplates" built into them.
You both have a point. I'm sure there are some ways that the HTML code can get semantic information in order to determine the main links from such a box and display them.
I'm glad Frederico brought this up (even if it might not have been his original point, and I apologize for hijacking his thread). If people agree that the mobile version needs to be "smarter" in deciding what to parse from the page, we can log some enhancements and push on the wikitech list to have them at least considered, if not prioritized.
Thanks, Strainu
On 21 August 2014 05:31, Strainu strainu10@gmail.com wrote:
2014-08-21 9:30 GMT+03:00 Federico Leva (Nemo) nemowiki@gmail.com: It would *seem* that every user
converted to the mobile site is a step towards extinction of the wiki.
That is an excellent point Frederico. In addition to the inherent difficulties of editing on small screen, especially large articles and the "we know better approach" discussed in detail in the last weeks, there is also the problem of navigating between articles - the mobile website arbitrarily skips some elements visible on desktop, such as navboxes and significantly alter some infoboxes because "it doesn't look good". This makes it difficult to just browse the Wikipedia (thus finding mistakes that you might want to correct) and encourages searching for the information, which means going right on target
Hopefully the future announced at Wikimania, "no more mobile team, but mobile in every team" will solve some of these problems. It's just a matter of when will this future be.
Well, now. Here's a classic example of what is sometimes called a "first world problem". I know that, even on desktops, the more infoboxes and navboxes and succession boxes on an article (regardless of article length), the longer it takes to load. On a slower desktop collection, some really large, complex articles sometimes time out.
I went to look at some of those same articles using my smartphone with the "desktop" option turned on. Many of them timed out without fully loading; others took several minutes. There was a very, very noticeable difference in load time between the mobile view and the desktop view. And that was in North America with fast, very good connection on an up-to-date phone. Many of our editors and readers don't have this kind of infrastructure available to them.
So - we know there is a definite cost to having all these "navigation aids" in articles. We need to justify their use, instead of simply adding them by reflex. So here is where analytics teams can really be useful: tell us whether or not these navboxes are actually being used to go to other articles. If they're widely used to leap to the next article, then we need to find ways to make them more efficient so that they're suitable for mobile devices. If they're hardly ever being used, we need to reconsider their existence. Perhaps this becomes some sort of "meta data" tab from articles. The current format isn't sustainable, though.
Risker/Anne
Editing via the mobile view is made more painful by the use of navboxes, tables and complex templates of any kind. Even the {{cite}} template can occupy several lines of the display on a mobile device making it hard to discern the text. Maybe Wikidata will solve some of this by shifting the creation of navigation links (for example) out of article editing and into metadata maintenance. I've not tried working on Wikidata via a mobile device so can't comment on its accessibility
Neil
---- Risker wrote ----
On 21 August 2014 05:31, Strainu strainu10@gmail.com wrote:
2014-08-21 9:30 GMT+03:00 Federico Leva (Nemo) nemowiki@gmail.com: It would *seem* that every user
converted to the mobile site is a step towards extinction of the wiki.
That is an excellent point Frederico. In addition to the inherent difficulties of editing on small screen, especially large articles and the "we know better approach" discussed in detail in the last weeks, there is also the problem of navigating between articles - the mobile website arbitrarily skips some elements visible on desktop, such as navboxes and significantly alter some infoboxes because "it doesn't look good". This makes it difficult to just browse the Wikipedia (thus finding mistakes that you might want to correct) and encourages searching for the information, which means going right on target
Hopefully the future announced at Wikimania, "no more mobile team, but mobile in every team" will solve some of these problems. It's just a matter of when will this future be.
Well, now. Here's a classic example of what is sometimes called a "first world problem". I know that, even on desktops, the more infoboxes and navboxes and succession boxes on an article (regardless of article length), the longer it takes to load. On a slower desktop collection, some really large, complex articles sometimes time out.
I went to look at some of those same articles using my smartphone with the "desktop" option turned on. Many of them timed out without fully loading; others took several minutes. There was a very, very noticeable difference in load time between the mobile view and the desktop view. And that was in North America with fast, very good connection on an up-to-date phone. Many of our editors and readers don't have this kind of infrastructure available to them.
So - we know there is a definite cost to having all these "navigation aids" in articles. We need to justify their use, instead of simply adding them by reflex. So here is where analytics teams can really be useful: tell us whether or not these navboxes are actually being used to go to other articles. If they're widely used to leap to the next article, then we need to find ways to make them more efficient so that they're suitable for mobile devices. If they're hardly ever being used, we need to reconsider their existence. Perhaps this becomes some sort of "meta data" tab from articles. The current format isn't sustainable, though.
Risker/Anne _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 21.08.2014 14:26, Risker wrote:
On 21 August 2014 05:31, Strainu strainu10@gmail.com wrote:
...
I went to look at some of those same articles using my smartphone with the "desktop" option turned on. Many of them timed out without fully loading; others took several minutes. There was a very, very noticeable difference in load time between the mobile view and the desktop view. And that was in North America with fast, very good connection on an up-to-date phone. Many of our editors and readers don't have this kind of infrastructure available to them.
So - we know there is a definite cost to having all these "navigation aids" in articles. We need to justify their use, instead of simply adding them by reflex. So here is where analytics teams can really be useful: tell us whether or not these navboxes are actually being used to go to other articles. If they're widely used to leap to the next article, then we need to find ways to make them more efficient so that they're suitable for mobile devices. If they're hardly ever being used, we need to reconsider their existence. Perhaps this becomes some sort of "meta data" tab from articles. The current format isn't sustainable, though.
Risker/Anne _______________________________________________
For me the conclusion would be not that we should drop them altogether in the mobile version (most of them are useful navigation means after all) but that the mobile version should be improved to parse them and to present them as a piece of plain text, not as a template.
Cheers Yaroslav
On 21 August 2014 09:18, Yaroslav M. Blanter putevod@mccme.ru wrote:
On 21.08.2014 14:26, Risker wrote:
On 21 August 2014 05:31, Strainu strainu10@gmail.com wrote:
...
I went to look at some of those same articles using my smartphone with the "desktop" option turned on. Many of them timed out without fully loading; others took several minutes. There was a very, very noticeable difference in load time between the mobile view and the desktop view. And that was in North America with fast, very good connection on an up-to-date phone. Many of our editors and readers don't have this kind of infrastructure available to them.
So - we know there is a definite cost to having all these "navigation aids" in articles. We need to justify their use, instead of simply adding them by reflex. So here is where analytics teams can really be useful: tell us whether or not these navboxes are actually being used to go to other articles. If they're widely used to leap to the next article, then we need to find ways to make them more efficient so that they're suitable for mobile devices. If they're hardly ever being used, we need to reconsider their existence. Perhaps this becomes some sort of "meta data" tab from articles. The current format isn't sustainable, though.
Risker/Anne _______________________________________________
For me the conclusion would be not that we should drop them altogether in the mobile version (most of them are useful navigation means after all) but that the mobile version should be improved to parse them and to present them as a piece of plain text, not as a template.
Many of these templates have over 100 links in them; a surprisingly large number have "subtemplates" built into them. I'm having a hard time seeing how adding all those links at the bottom of an article is actually going to help that much. Unless we have some evidence to confirm this information is actually useful to readers -seriously, this is a community-designed feature targeted at readers as opposed to editors - it's probably time to rethink what indirectly related information on our article pages is made routinely available. We want people to use our information, not give up because it takes too long to load.
Risker/Anne
On 21.08.2014 15:24, Risker wrote:
On 21 August 2014 09:18, Yaroslav M. Blanter putevod@mccme.ru wrote:
On 21.08.2014 14:26, Risker wrote:
On 21 August 2014 05:31, Strainu strainu10@gmail.com wrote:
...
Many of these templates have over 100 links in them; a surprisingly large number have "subtemplates" built into them. I'm having a hard time seeing how adding all those links at the bottom of an article is actually going to help that much. Unless we have some evidence to confirm this information is actually useful to readers -seriously, this is a community-designed feature targeted at readers as opposed to editors - it's probably time to rethink what indirectly related information on our article pages is made routinely available. We want people to use our information, not give up because it takes too long to load.
Risker/Anne
Right, and if the feature is not useful for readers (and I do not see how it is useful for editors, except for making the pages looking nicer) it possibly should not be there at all. But I do not think that just ignoring it in the mobile version without any relation to the "desktop" version is a good direction to follow.
Cheers Yaroslav
I find navboxes useful as an editor, and frequently use them to keep track of the related articles I edit. I would prefer to keep the functionality, but would not have a problem with it being opt-in. Cheers, Peter
-----Original Message----- From: wikimedia-l-bounces@lists.wikimedia.org [mailto:wikimedia-l-bounces@lists.wikimedia.org] On Behalf Of Yaroslav M. Blanter Sent: 21 August 2014 03:29 PM To: Wikimedia Mailing List Subject: Re: [Wikimedia-l] The reader, who doesn't exist
On 21.08.2014 15:24, Risker wrote:
On 21 August 2014 09:18, Yaroslav M. Blanter putevod@mccme.ru wrote:
On 21.08.2014 14:26, Risker wrote:
On 21 August 2014 05:31, Strainu strainu10@gmail.com wrote:
...
Many of these templates have over 100 links in them; a surprisingly large number have "subtemplates" built into them. I'm having a hard time seeing how adding all those links at the bottom of an article is actually going to help that much. Unless we have some evidence to confirm this information is actually useful to readers -seriously, this is a community-designed feature targeted at readers as opposed to editors - it's probably time to rethink what indirectly related information on our article pages is made routinely available. We want people to use our information, not give up because it takes too long to load.
Risker/Anne
Right, and if the feature is not useful for readers (and I do not see how it is useful for editors, except for making the pages looking nicer) it possibly should not be there at all. But I do not think that just ignoring it in the mobile version without any relation to the "desktop" version is a good direction to follow.
Cheers Yaroslav
_______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4745 / Virus Database: 4007/8073 - Release Date: 08/21/14
On 21/08/14 13:24, Risker wrote:
On 21 August 2014 09:18, Yaroslav M. Blanter putevod@mccme.ru wrote:
For me the conclusion would be not that we should drop them altogether in the mobile version (most of them are useful navigation means after all) but that the mobile version should be improved to parse them and to present them as a piece of plain text, not as a template.
Many of these templates have over 100 links in them; a surprisingly large number have "subtemplates" built into them. I'm having a hard time seeing how adding all those links at the bottom of an article is actually going to help that much. Unless we have some evidence to confirm this information is actually useful to readers -seriously, this is a community-designed feature targeted at readers as opposed to editors - it's probably time to rethink what indirectly related information on our article pages is made routinely available. We want people to use our information, not give up because it takes too long to load.
Risker/Anne
Man, I forgot how over the top some projects get with their navigation templates. But what Yaroslav said might actually provide a good guideline - if they CAN be reasonably simplified, then the templates themselves are probably reasonable. If not, they need to be fixed.
Just hiding them isn't the solution - the templates themselves need to be made more realistic, because while they may be a bit overwhelming on the desktop (I mean, I looked at [[red]] and was overwhelmed by the bottom of the page), the issues they present on mobile devices should be a real incentive. But if you just hide them, that removes the incentive to fix them up. That doesn't make much sense to me.
-I
On 21 August 2014 17:08, Isarra Yos zhorishna@gmail.com wrote:
Man, I forgot how over the top some projects get with their navigation templates.
Perhaps the answer is to refactor them as separate pages to which mobile (and even desktop) pages can use a single link?
Or, have them filled from Wikidata. Then, {{Infobox}} would be all the wikitext you need. This could also help to "abstract" infoboxes to load a placeholder/hint on mobile, then loading the box on request (click).
Well, one can dream...
Magnus
On Thu, Aug 21, 2014 at 6:45 PM, Andy Mabbett andy@pigsonthewing.org.uk wrote:
On 21 August 2014 17:08, Isarra Yos zhorishna@gmail.com wrote:
Man, I forgot how over the top some projects get with their navigation templates.
Perhaps the answer is to refactor them as separate pages to which mobile (and even desktop) pages can use a single link?
-- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Thu, Aug 21, 2014 at 11:04 AM, Magnus Manske <magnusmanske@googlemail.com
wrote:
Or, have them filled from Wikidata. Then, {{Infobox}} would be all the wikitext you need. This could also help to "abstract" infoboxes to load a placeholder/hint on mobile, then loading the box on request (click).
Well, one can dream...
This would be ideal I think, since it would allow for more responsive styling without resorting to ugly hacks specific to infobox markup.
So far as I can tell though, there is one major blocker to this: edibility. People need to be able to update the infobox data without leaving Wikipedia and being sent to Yet Another Wiki. This is potentially doable in VisualEditor I think, but is hard or maybe impossible to do with any elegance in wikitext.
On 21.08.2014 21:17, Steven Walling wrote:
On Thu, Aug 21, 2014 at 11:04 AM, Magnus Manske <magnusmanske@googlemail.com
wrote:
Or, have them filled from Wikidata. Then, {{Infobox}} would be all the wikitext you need. This could also help to "abstract" infoboxes to load a placeholder/hint on mobile, then loading the box on request (click).
Well, one can dream...
This would be ideal I think, since it would allow for more responsive styling without resorting to ugly hacks specific to infobox markup.
So far as I can tell though, there is one major blocker to this: edibility. People need to be able to update the infobox data without leaving Wikipedia and being sent to Yet Another Wiki. This is potentially doable in VisualEditor I think, but is hard or maybe impossible to do with any elegance in wikitext. _______________________________________________
Another problem, at least for the time being, is that connection to Wikidata is still slow (I feel it even with very good Internet access), and eventually will impede slow mobile connections. I hope this is curable though.
Cheers Yaroslav
I was talking about navboxes, not infoboxes.
On 21 August 2014 19:04, Magnus Manske magnusmanske@googlemail.com wrote:
Or, have them filled from Wikidata. Then, {{Infobox}} would be all the wikitext you need. This could also help to "abstract" infoboxes to load a placeholder/hint on mobile, then loading the box on request (click).
Well, one can dream...
Magnus
On Thu, Aug 21, 2014 at 6:45 PM, Andy Mabbett andy@pigsonthewing.org.uk wrote:
On 21 August 2014 17:08, Isarra Yos zhorishna@gmail.com wrote:
Man, I forgot how over the top some projects get with their navigation templates.
Perhaps the answer is to refactor them as separate pages to which mobile (and even desktop) pages can use a single link?
-- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Thu, Aug 21, 2014 at 7:26 PM, Risker risker.wp@gmail.com wrote:
On 21 August 2014 05:31, Strainu strainu10@gmail.com wrote:
2014-08-21 9:30 GMT+03:00 Federico Leva (Nemo) nemowiki@gmail.com: It would *seem* that every user
converted to the mobile site is a step towards extinction of the wiki.
That is an excellent point Frederico. In addition to the inherent difficulties of editing on small screen, especially large articles and the "we know better approach" discussed in detail in the last weeks, there is also the problem of navigating between articles - the mobile website arbitrarily skips some elements visible on desktop, such as navboxes and significantly alter some infoboxes because "it doesn't look good". This makes it difficult to just browse the Wikipedia (thus finding mistakes that you might want to correct) and encourages searching for the information, which means going right on target
Hopefully the future announced at Wikimania, "no more mobile team, but mobile in every team" will solve some of these problems. It's just a matter of when will this future be.
Well, now. Here's a classic example of what is sometimes called a "first world problem". I know that, even on desktops, the more infoboxes and navboxes and succession boxes on an article (regardless of article length), the longer it takes to load. On a slower desktop collection, some really large, complex articles sometimes time out.
I went to look at some of those same articles using my smartphone with the "desktop" option turned on. Many of them timed out without fully loading; others took several minutes. There was a very, very noticeable difference in load time between the mobile view and the desktop view. And that was in North America with fast, very good connection on an up-to-date phone. Many of our editors and readers don't have this kind of infrastructure available to them.
So - we know there is a definite cost to having all these "navigation aids" in articles. We need to justify their use, instead of simply adding them by reflex. So here is where analytics teams can really be useful: tell us whether or not these navboxes are actually being used to go to other articles. If they're widely used to leap to the next article, then we need to find ways to make them more efficient so that they're suitable for mobile devices. If they're hardly ever being used, we need to reconsider their existence. Perhaps this becomes some sort of "meta data" tab from articles. The current format isn't sustainable, though.
If we're talking about navboxes, they are navigational and I agree the software should replace them with something else, or drop them entirely, if it helps rendering performance or the UI design.
I'd be interested to hear of examples of infoboxes that are being altered by the mobile view. I expect it being done for overly complex parts of some infoboxes.
While we're talking about the first world problem, I have first hand experience that the MediaViewer is a backwards step for people on dialup (e.g. people in regional Australia who rarely get the telco promised maximum of 28.8kbit/s) or on crappy mobile connections (which is most of Indonesia, fwiw, where many people use a _desktop_ or old laptop connected to the internet via 3G modem or their mobile phone).
Sure "they" can disable it with their preferences, but to get to that they need to download the MediaViewer software and *while* the image is downloading at a much higher res than it would have previously, figure out to scroll down, and press the 'Disable Media Viewer' link.
*But*, that only works on the normal website. On the mobile website, I cant figure out how to disable the Media Viewer. To check I wasnt missing something, I asked someone at the Wikimedia Indonesia office (https://en.wikipedia.org/wiki/Special:CentralAuth/Beeyan) to try to disable it on his phone, and he couldnt work it out either.
Go to: https://en.m.wikipedia.org/wiki/Horse_Protection_Act_of_1970
Scroll down to the "Tennessee Walking Horse" photo and click on it. As far as I can see it has downloaded the 200+KB photo, and I may either close the MediaViewer or go to the page on Commons. There are no other options. We can't figure out how to disable this. Even after logging in on the mobile site, there is no preference to disable it in the Settings.
If you click the Details button to return to go to Commons, only a 70KB photo is shown, which is what used to occur.
On Thu, Aug 21, 2014 at 6:29 AM, John Mark Vandenberg jayvdb@gmail.com wrote:
*But*, that only works on the normal website. On the mobile website, I cant figure out how to disable the Media Viewer. To check I wasnt missing something, I asked someone at the Wikimedia Indonesia office (https://en.wikipedia.org/wiki/Special:CentralAuth/Beeyan) to try to disable it on his phone, and he couldnt work it out either.
Go to: https://en.m.wikipedia.org/wiki/Horse_Protection_Act_of_1970
Scroll down to the "Tennessee Walking Horse" photo and click on it. As far as I can see it has downloaded the 200+KB photo, and I may either close the MediaViewer or go to the page on Commons. There are no other options. We can't figure out how to disable this. Even after logging in on the mobile site, there is no preference to disable it in the Settings.
If you click the Details button to return to go to Commons, only a 70KB photo is shown, which is what used to occur.
Hi all,
A few points of clarification on MediaViewer and mobile. The Mobile Web team built a custom image-viewing experience for users accessing Wikimedia projects on phones and tablets; we're not actually using desktop MediaViewer. The mobile implementation loads a size of the image adapted for the viewport (which may be larger than the screen size due to retina support). It does not load the full-size image unless that image is very small. Users accessing the mobile site via Wikipedia Zero or from lower-end no-JS phones/browsers go straight to the file page.
Performance and bandwidth are definitely things we think about a lot. The Zero team is currently experimenting with different thumbnail compression ratios for mobile users who access the site via Wikipedia Zero carriers, in order to keep bandwidth impact minimal. Based on the outcome, we're considering using extra compression in the mobile media viewing experience for all users, though we'll need to study the caching implications, because it could potentially make performance worse but bandwidth better.
Making sure the default experience works well for both high-end and low-end device users is a much higher priority on mobile than creating layers of opt-in/out preferences, because people use mobile differently from laptops/computers and complex preference screens are difficult to navigate on a smaller device. We do already have a preference to turn images off entirely on the mobile site for users who want to save bandwidth; adding more granular options to this is not something we're considering at this time, though it's entirely possible that we may revisit this in the future.
Federico Leva (Nemo) wrote:
First, let's make one thing clear: the reader doesn't exist; it's just a rhetorical trick, and a very dangerous one. For more: https://meta.wikimedia.org/wiki/Stupidity_of_the_reader
This essay looks fascinating. I hope to read it soon.
Page views, however brute a concept, exist; and I think they're telling us we do have a readership problem. For it.wiki, in the last year I see a suspiciously similar decrease in desktop pageviews and editing activity (possibly around –20 %). It would *seem* that every user converted to the mobile site is a step towards extinction of the wiki. Long story: https://meta.wikimedia.org/wiki/Special:Permalink/9380388 The page above is just a collection of pointers that I probably won't be able to pursue in the coming months, to study an unprecedented collapse of editing activity and active editors on it.wiki. However, there /are/ several things worth looking into and we do have a huge problem (or several).
I don't know enough about the Italian Wikipedia to comment on it specifically. But generally I think it's important to re-emphasize that correlation and causation are distinct, as are readership and editorship rates. The two items of each set can be interrelated or connected sometimes, of course, but we need to make sure we're drawing accurate and appropriate conclusions.
At https://bugzilla.wikimedia.org/show_bug.cgi?id=62811#c10 Jared Zimmerman writes, "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." There's substantial discussion in the subsequent comments.
Let's temporarily accept the premise that pageviews suddenly drop from 20 billion per month to 1 billion per month. The easy argument is that we'd save a lot of money on hosting. But unlike most of the Internet, Wikipedia doesn't rely on advertising. Why does it matter how popular we are? Does it affect donation rates? Does it affect editorship rates? I'm not sure how much of this we know. It's increasingly clear that much of the rest of the Internet _is_ different: it doesn't require much thought of participants, it's user-focused, and it's built on the idea of selling (to) people. This difference in how we want to treat users, as collaborators and colleagues, rather than as clients or customers, will permeate the site design and user experience and that's okay.
If the number of pageviews suddenly drops, for whatever reason, what happens next? The most likely "worst case" scenario seems to be a reduction in annual donations, which results in a smaller staff size (sometimes referred to as "trimming the fat" or "optimizing"). There's a lot of talk lately about the imperiled future, but we could end up with a smaller, more decentralized Wikimedia Foundation staff in what some would consider one of the least desirable outcomes. Eh.
MZMcBride
Given the mission is sharing information, I'd suggest that if we have a 95% drop in readership, we're failing the mission. Donations are only a means to an end.
Risker/Anne
On 24 August 2014 22:57, MZMcBride z@mzmcbride.com wrote:
Federico Leva (Nemo) wrote:
First, let's make one thing clear: the reader doesn't exist; it's just a rhetorical trick, and a very dangerous one. For more: https://meta.wikimedia.org/wiki/Stupidity_of_the_reader
This essay looks fascinating. I hope to read it soon.
Page views, however brute a concept, exist; and I think they're telling us we do have a readership problem. For it.wiki, in the last year I see a suspiciously similar decrease in desktop pageviews and editing activity (possibly around –20 %). It would *seem* that every user converted to the mobile site is a step towards extinction of the wiki. Long story: https://meta.wikimedia.org/wiki/Special:Permalink/9380388 The page above is just a collection of pointers that I probably
won't
be able to pursue in the coming months, to study an unprecedented collapse of editing activity and active editors on it.wiki. However, there /are/ several things worth looking into and we do have a huge problem (or several).
I don't know enough about the Italian Wikipedia to comment on it specifically. But generally I think it's important to re-emphasize that correlation and causation are distinct, as are readership and editorship rates. The two items of each set can be interrelated or connected sometimes, of course, but we need to make sure we're drawing accurate and appropriate conclusions.
At https://bugzilla.wikimedia.org/show_bug.cgi?id=62811#c10 Jared Zimmerman writes, "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." There's substantial discussion in the subsequent comments.
Let's temporarily accept the premise that pageviews suddenly drop from 20 billion per month to 1 billion per month. The easy argument is that we'd save a lot of money on hosting. But unlike most of the Internet, Wikipedia doesn't rely on advertising. Why does it matter how popular we are? Does it affect donation rates? Does it affect editorship rates? I'm not sure how much of this we know. It's increasingly clear that much of the rest of the Internet _is_ different: it doesn't require much thought of participants, it's user-focused, and it's built on the idea of selling (to) people. This difference in how we want to treat users, as collaborators and colleagues, rather than as clients or customers, will permeate the site design and user experience and that's okay.
If the number of pageviews suddenly drops, for whatever reason, what happens next? The most likely "worst case" scenario seems to be a reduction in annual donations, which results in a smaller staff size (sometimes referred to as "trimming the fat" or "optimizing"). There's a lot of talk lately about the imperiled future, but we could end up with a smaller, more decentralized Wikimedia Foundation staff in what some would consider one of the least desirable outcomes. Eh.
MZMcBride
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Risker wrote:
Given the mission is sharing information, I'd suggest that if we have a 95% drop in readership, we're failing the mission. Donations are only a means to an end.
I think this assumes a direct correlation between pageviews and sharing information and I'm not sure such a direct correlation exists.
When you do a Google search for "abraham lincoln", there's now an infobox on the search results page with content from Wikipedia. This could easily result in a drop in the number of Wikipedia pageviews, but does that mean that Wikipedia is failing its mission? The goal is a world in which we freely share in the sum of all human knowledge. If third parties are picking up and re-using our free content (and they are), I think we're certainly not losing. We may even be winning(!).
We offer bulk-download options for our content, as well as the ability to directly query for article content on-demand via the MediaWIki API. Both of these access methods very likely result in 0 pageviews being registered (XML dump downloads and api.php hits aren't considered pageviews, as far as I'm aware), but we're directly sharing content.
As a metric, pageviews are probably not very meaningful. One way we can observe whether we're fulfilling our mission is to see how ubiquitous our content has become. An even better metric might be the quality of the articles we have. Anecdotal evidence suggests that higher article quality is not really tied to the readership rate, though perhaps article size is.
MZMcBride
Yes, we could look at Google's infoboxes as doing us a favor because they decrease the load on our servers. We would need to account for those views in some way if we are interested in quantifying success in the sense of total views of our content regardless of where it is reproduced.
However, I think Analytics said in a WMF Metrics Meeting presentation that the number of Google search referrals was not going down enough to explain the drop in pageviews. I'm copying this email to Analytics in the hope that they'll comment about the probable causes of the pageview decreases.
Pine
On Sun, Aug 24, 2014 at 6:06 PM, MZMcBride z@mzmcbride.com wrote:
Risker wrote:
Given the mission is sharing information, I'd suggest that if we have a 95% drop in readership, we're failing the mission. Donations are only a means to an end.
I think this assumes a direct correlation between pageviews and sharing information and I'm not sure such a direct correlation exists.
When you do a Google search for "abraham lincoln", there's now an infobox on the search results page with content from Wikipedia. This could easily result in a drop in the number of Wikipedia pageviews, but does that mean that Wikipedia is failing its mission? The goal is a world in which we freely share in the sum of all human knowledge. If third parties are picking up and re-using our free content (and they are), I think we're certainly not losing. We may even be winning(!).
We offer bulk-download options for our content, as well as the ability to directly query for article content on-demand via the MediaWIki API. Both of these access methods very likely result in 0 pageviews being registered (XML dump downloads and api.php hits aren't considered pageviews, as far as I'm aware), but we're directly sharing content.
As a metric, pageviews are probably not very meaningful. One way we can observe whether we're fulfilling our mission is to see how ubiquitous our content has become. An even better metric might be the quality of the articles we have. Anecdotal evidence suggests that higher article quality is not really tied to the readership rate, though perhaps article size is.
MZMcBride
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 8/25/14, 3:06 AM, MZMcBride wrote:
As a metric, pageviews are probably not very meaningful. One way we can observe whether we're fulfilling our mission is to see how ubiquitous our content has become. An even better metric might be the quality of the articles we have. Anecdotal evidence suggests that higher article quality is not really tied to the readership rate, though perhaps article size is.
Yes, I'd ideally like some better measure of how much people get out of articles. Some types of analytics do track page view duration, although that can be considered intrusive.
I've done a little spot-checking within specific areas (e.g. archaeological sites) of our view counts, and they are largely dominated by spikes around transient news events: something is in the news and 5,000 or 50,000 people load an article that normally gets 50 or 100 hits a day. Providing that kind of quick background knowledge to people googling for an item they saw on the news is a valuable service, to be sure. But I'm not sure it's *as* big a proportion of the value Wikipedia provides as the raw pageload numbers would say.
-Mark
MZMcBride, 24/08/2014 23:57:
Federico Leva (Nemo) wrote:
First, let's make one thing clear: the reader doesn't exist; it's just a rhetorical trick, and a very dangerous one. For more: https://meta.wikimedia.org/wiki/Stupidity_of_the_reader
This essay looks fascinating. I hope to read it soon.
Heh.
Why does it matter how popular we are? Does it affect donation rates? Does it affect editorship rates? I'm not sure how much of this we know.
I think evidence points to an important role that (desktop) visits trends had in the editing activity trends. There are some research papers proving this locally, which I still have to reference in the page above; but I agree we need much more research to understand this globally.
It's increasingly clear that much of the rest of the Internet _is_ different: it doesn't require much thought of participants, it's user-focused, and it's built on the idea of selling (to) people. This difference in how we want to treat users, as collaborators and colleagues, rather than as clients or customers, will permeate the site design and user experience and that's okay.
This is closer to the point I was trying to make. The internet is different, the environment is not favourable and is probably getting worse (pageview trends may be the tip of the iceberg: a useful warning).
No matter how well we try and how many good things get done which were worth doing, it's entirely possible for some things bigger than us (like worldwide shifts in consumer electronics and telecommunication) to undefeatably beat us and make the Wikimedia projects fail (e.g. 27 or 28 in http://meatballwiki.org/wiki/WikiLifeCycle ). Sure, that would not be the end of the story, because we try to get something done which will be relevant for centuries to come.
But denial doesn't help anything.
If the number of pageviews suddenly drops, for whatever reason, what happens next? The most likely "worst case" scenario seems to be a reduction in annual donations, which results in a smaller staff size (sometimes referred to as "trimming the fat" or "optimizing"). There's a lot of talk lately about the imperiled future, but we could end up with a smaller, more decentralized Wikimedia Foundation staff in what some would consider one of the least desirable outcomes. Eh.
The number of WMF staff has had practically zero consequences on the success of Wikimedia projects, so I don't consider it a particularly interesting topic for this decade. I'm more interested in discussing the stuff you can't easily read on a balance sheet.
Nemo
wikimedia-l@lists.wikimedia.org