[Wikimedia-l] The reader, who doesn't exist

2014-08-21 Thread Federico Leva (Nemo)
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.

___
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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] The reader, who doesn't exist

2014-08-21 Thread Strainu
2014-08-21 9:30 GMT+03:00 Federico Leva (Nemo) nemow...@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

___
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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] The reader, who doesn't exist

2014-08-21 Thread Andy Mabbett
On 21 August 2014 10:31, Strainu strain...@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?



-- 
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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] The reader, who doesn't exist

2014-08-21 Thread Risker
On 21 August 2014 05:31, Strainu strain...@gmail.com wrote:

 2014-08-21 9:30 GMT+03:00 Federico Leva (Nemo) nemow...@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-requ...@lists.wikimedia.org?subject=unsubscribe

[Wikimedia-l] Specifying office action in edit summary?

2014-08-21 Thread svetlana

Hi all.

I understand the Engineering folks used superprotect instead of /undoing/ the 
edit and adding 'This is a WMF action.' in edit summary. Could I please be 
enlightened on the reasoning behind that?

I suppose people could go and try editing other JS pages and cause havoc, but 
that's still possible where superprotect only affects a single page and not a 
namespace. Or can entire namespaces be protected and this new user right was 
intended to be able to prevent that easily?

Svetlana.

___
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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] The reader, who doesn't exist

2014-08-21 Thread Neil Babbage
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 strain...@gmail.com wrote:

 2014-08-21 9:30 GMT+03:00 Federico Leva (Nemo) nemow...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] The reader, who doesn't exist

2014-08-21 Thread Yaroslav M. Blanter

On 21.08.2014 14:26, Risker wrote:

On 21 August 2014 05:31, Strainu strain...@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

___
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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] The reader, who doesn't exist

2014-08-21 Thread Risker
On 21 August 2014 09:18, Yaroslav M. Blanter pute...@mccme.ru wrote:

 On 21.08.2014 14:26, Risker wrote:

 On 21 August 2014 05:31, Strainu strain...@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
___
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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] The reader, who doesn't exist

2014-08-21 Thread John Mark Vandenberg
On Thu, Aug 21, 2014 at 7:26 PM, Risker risker...@gmail.com wrote:
 On 21 August 2014 05:31, Strainu strain...@gmail.com wrote:

 2014-08-21 9:30 GMT+03:00 Federico Leva (Nemo) nemow...@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.

-- 
John Vandenberg

___
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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] The reader, who doesn't exist

2014-08-21 Thread Yaroslav M. Blanter

On 21.08.2014 15:24, Risker wrote:

On 21 August 2014 09:18, Yaroslav M. Blanter pute...@mccme.ru wrote:


On 21.08.2014 14:26, Risker wrote:


On 21 August 2014 05:31, Strainu strain...@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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Compare person data

2014-08-21 Thread WereSpielChequers
re the birth anomalies, we have been running a process for several years now 
that looks for people alive according to certain wikipedias and dead according 
to up to 80 others. The format works well and has been broadened to various 
other anomalies such as being dead but not born.

https://meta.wikimedia.org/wiki/Death_anomalies_table

The key thing to remember is that when Wikipedias differ you need reliable 
source to settle the difference.

Wikidata may or may not make this sort of thing easier, but my suspicion is 
that resolving anomalies will improve Wikidata as well as Wikipedia.

Regards

Jonathan (WereSpielChequers)



 On 19 Aug 2014, at 22:05, wikimedia-l-requ...@lists.wikimedia.org wrote
 
 Message: 1
 Date: Tue, 19 Aug 2014 09:04:17 -0400
 From: MZMcBride z...@mzmcbride.com
 To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org
 Subject: Re: [Wikimedia-l] Compare person data
 Message-ID: d018c23a.422b...@mzmcbride.com
 Content-Type: text/plain;charset=UTF-8
 
 Gerard Meijssen wrote:
 What is needed is a report that looks good enough for now and a public ie
 visible place to put it.
 
 Neat idea!
 
 There's https://www.wikidata.org/wiki/Wikidata:Database_reports, of
 course. In my experience, users don't really care what the report is
 titled or how it looks; they're much more concerned with accurate and
 up-to-date (read: actionable) report data.
 
 One of the benefits of using a wiki page is that wiki pages have pre-built
 notification structures (watchlists, RSS feeds, IRC feed, and e-mail).
 
 To this end, depending on who the relevant audience is of this report,
 updating multiple pages on local wikis may be a lot more fruitful.
 
 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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] The reader, who doesn't exist

2014-08-21 Thread Peter Southwood
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-boun...@lists.wikimedia.org 
[mailto:wikimedia-l-boun...@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 pute...@mccme.ru wrote:
 
 On 21.08.2014 14:26, Risker wrote:
 
 On 21 August 2014 05:31, Strainu strain...@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-requ...@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


___
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-requ...@lists.wikimedia.org?subject=unsubscribe

[Wikimedia-l] New movement org?

2014-08-21 Thread Richard Symonds
Hi all,

I note that a new Wikimedia organisation has been setup in Michigan, called
the Wikipedia Editors Foundation Inc, as of about a week or two ago.

It seems (by the filings) to be a nice nonprofit org set up by sensible
people who care about the movement.

That said - is this a new chapter, or something similar? To whom should we
address information?

Richard Symonds
Wikimedia UK
0207 065 0992

Wikimedia UK is a Company Limited by Guarantee registered in England and
Wales, Registered No. 6741827. Registered Charity No.1144513. Registered
Office 4th Floor, Development House, 56-64 Leonard Street, London EC2A 4LT.
United Kingdom. Wikimedia UK is the UK chapter of a global Wikimedia
movement. The Wikimedia projects are run by the Wikimedia Foundation (who
operate Wikipedia, amongst other projects).

*Wikimedia UK is an independent non-profit charity with no legal control
over Wikipedia nor responsibility for its contents.*
___
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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] The reader, who doesn't exist

2014-08-21 Thread Isarra Yos

On 21/08/14 13:24, Risker wrote:

On 21 August 2014 09:18, Yaroslav M. Blanter pute...@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

___
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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] New movement org?

2014-08-21 Thread Nathan
Hi Richard, any links to where you found this information?


On Thu, Aug 21, 2014 at 12:01 PM, Richard Symonds 
richard.symo...@wikimedia.org.uk wrote:

 Hi all,

 I note that a new Wikimedia organisation has been setup in Michigan, called
 the Wikipedia Editors Foundation Inc, as of about a week or two ago.

 It seems (by the filings) to be a nice nonprofit org set up by sensible
 people who care about the movement.

 That said - is this a new chapter, or something similar? To whom should we
 address information?

 Richard Symonds
 Wikimedia UK
 0207 065 0992

 Wikimedia UK is a Company Limited by Guarantee registered in England and
 Wales, Registered No. 6741827. Registered Charity No.1144513. Registered
 Office 4th Floor, Development House, 56-64 Leonard Street, London EC2A 4LT.
 United Kingdom. Wikimedia UK is the UK chapter of a global Wikimedia
 movement. The Wikimedia projects are run by the Wikimedia Foundation (who
 operate Wikipedia, amongst other projects).

 *Wikimedia UK is an independent non-profit charity with no legal control
 over Wikipedia nor responsibility for its contents.*
 ___
 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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] New movement org?

2014-08-21 Thread Gregory Varnum
I would also like that information.

I can confirm that the Affiliations Committee does not have an active (or
past) application from them for affiliation. I am checking if anyone on the
AffCom heard about it from other channels.

-greg aka varnent
Vice Chair, Wikimedia Affiliations Committee


On Thu, Aug 21, 2014 at 12:13 PM, Nathan nawr...@gmail.com wrote:

 Hi Richard, any links to where you found this information?


 On Thu, Aug 21, 2014 at 12:01 PM, Richard Symonds 
 richard.symo...@wikimedia.org.uk wrote:

  Hi all,
 
  I note that a new Wikimedia organisation has been setup in Michigan,
 called
  the Wikipedia Editors Foundation Inc, as of about a week or two ago.
 
  It seems (by the filings) to be a nice nonprofit org set up by sensible
  people who care about the movement.
 
  That said - is this a new chapter, or something similar? To whom should
 we
  address information?
 
  Richard Symonds
  Wikimedia UK
  0207 065 0992
 
  Wikimedia UK is a Company Limited by Guarantee registered in England and
  Wales, Registered No. 6741827. Registered Charity No.1144513. Registered
  Office 4th Floor, Development House, 56-64 Leonard Street, London EC2A
 4LT.
  United Kingdom. Wikimedia UK is the UK chapter of a global Wikimedia
  movement. The Wikimedia projects are run by the Wikimedia Foundation (who
  operate Wikipedia, amongst other projects).
 
  *Wikimedia UK is an independent non-profit charity with no legal control
  over Wikipedia nor responsibility for its contents.*
  ___
  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-requ...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] New movement org?

2014-08-21 Thread Nathan
On Thu, Aug 21, 2014 at 12:21 PM, James Forrester jdforres...@gmail.com
wrote:

 On 21 August 2014 09:13, Nathan nawr...@gmail.com wrote:

  Hi Richard, any links to where you found this information?
 


 ​The ever-excellent OpenCorporates has its entry:

 https://opencorporates.com/companies/us_mi/71656Y

 … leading to the official US state of Michigan's entry:

 http://www.dleg.state.mi.us/bcs_corp/dt_corp.asp?id_nbr=71656Y

 No information about the officers, sadly, just a filing office.


Actually, the documents are available, but the names don't ring a bell. It
uses the same address as Saline Plumbing  Heating.

http://www.dleg.state.mi.us/bcs_corp/image.asp?FILE_TYPE=ELFFILE_NAME=D201408\2014224\E0091608.TIF
___
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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] New movement org?

2014-08-21 Thread Risker
On 21 August 2014 12:21, James Forrester jdforres...@gmail.com wrote:

 On 21 August 2014 09:13, Nathan nawr...@gmail.com wrote:

  Hi Richard, any links to where you found this information?
 


 ​The ever-excellent OpenCorporates has its entry:

 https://opencorporates.com/companies/us_mi/71656Y

 … leading to the official US state of Michigan's entry:

 http://www.dleg.state.mi.us/bcs_corp/dt_corp.asp?id_nbr=71656Y

 No information about the officers, sadly, just a filing office.


Incorporation documents here:
http://www.dleg.state.mi.us/bcs_corp/image.asp?FILE_TYPE=ELFFILE_NAME=D201408\2014224\E0091608.TIF

President:  Scott Perry
Vice President:  Ann Perry
Secretary:  Danielle Lewis

Someone else can figure out how to copy/paste.

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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] New movement org?

2014-08-21 Thread Richard Symonds
Thanks all!

I have passed this over to WMF legal to deal with as it's a trademark issue.

Richard Symonds
Wikimedia UK
0207 065 0992

Wikimedia UK is a Company Limited by Guarantee registered in England and
Wales, Registered No. 6741827. Registered Charity No.1144513. Registered
Office 4th Floor, Development House, 56-64 Leonard Street, London EC2A 4LT.
United Kingdom. Wikimedia UK is the UK chapter of a global Wikimedia
movement. The Wikimedia projects are run by the Wikimedia Foundation (who
operate Wikipedia, amongst other projects).

*Wikimedia UK is an independent non-profit charity with no legal control
over Wikipedia nor responsibility for its contents.*


On 21 August 2014 17:31, Risker risker...@gmail.com wrote:

 On 21 August 2014 12:21, James Forrester jdforres...@gmail.com wrote:

  On 21 August 2014 09:13, Nathan nawr...@gmail.com wrote:
 
   Hi Richard, any links to where you found this information?
  
 
 
  ​The ever-excellent OpenCorporates has its entry:
 
  https://opencorporates.com/companies/us_mi/71656Y
 
  … leading to the official US state of Michigan's entry:
 
  http://www.dleg.state.mi.us/bcs_corp/dt_corp.asp?id_nbr=71656Y
 
  No information about the officers, sadly, just a filing office.
 
 
 Incorporation documents here:

 http://www.dleg.state.mi.us/bcs_corp/image.asp?FILE_TYPE=ELFFILE_NAME=D201408\2014224\E0091608.TIF

 President:  Scott Perry
 Vice President:  Ann Perry
 Secretary:  Danielle Lewis

 Someone else can figure out how to copy/paste.

 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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] New movement org?

2014-08-21 Thread Gregory Varnum
Thank you Richard for bringing this to everyone's attention.

So folks know, WMF Legal and the Affiliations Committee are investigating
and will be reaching out to the group soon.

Thanks!
-greg aka varnent
Wikimedia Affiliations Committee Vice Chair


On Thu, Aug 21, 2014 at 1:13 PM, Richard Symonds 
richard.symo...@wikimedia.org.uk wrote:

 Thanks all!

 I have passed this over to WMF legal to deal with as it's a trademark
 issue.

 Richard Symonds
 Wikimedia UK
 0207 065 0992

 Wikimedia UK is a Company Limited by Guarantee registered in England and
 Wales, Registered No. 6741827. Registered Charity No.1144513. Registered
 Office 4th Floor, Development House, 56-64 Leonard Street, London EC2A 4LT.
 United Kingdom. Wikimedia UK is the UK chapter of a global Wikimedia
 movement. The Wikimedia projects are run by the Wikimedia Foundation (who
 operate Wikipedia, amongst other projects).

 *Wikimedia UK is an independent non-profit charity with no legal control
 over Wikipedia nor responsibility for its contents.*


 On 21 August 2014 17:31, Risker risker...@gmail.com wrote:

  On 21 August 2014 12:21, James Forrester jdforres...@gmail.com wrote:
 
   On 21 August 2014 09:13, Nathan nawr...@gmail.com wrote:
  
Hi Richard, any links to where you found this information?
   
  
  
   ​The ever-excellent OpenCorporates has its entry:
  
   https://opencorporates.com/companies/us_mi/71656Y
  
   … leading to the official US state of Michigan's entry:
  
   http://www.dleg.state.mi.us/bcs_corp/dt_corp.asp?id_nbr=71656Y
  
   No information about the officers, sadly, just a filing office.
  
  
  Incorporation documents here:
 
 
 http://www.dleg.state.mi.us/bcs_corp/image.asp?FILE_TYPE=ELFFILE_NAME=D201408\2014224\E0091608.TIF
 
  President:  Scott Perry
  Vice President:  Ann Perry
  Secretary:  Danielle Lewis
 
  Someone else can figure out how to copy/paste.
 
  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-requ...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] The reader, who doesn't exist

2014-08-21 Thread Andy Mabbett
On 21 August 2014 17:08, Isarra Yos zhoris...@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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] The reader, who doesn't exist

2014-08-21 Thread Steven Walling
On Thu, Aug 21, 2014 at 11:04 AM, Magnus Manske magnusman...@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.
___
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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] The reader, who doesn't exist

2014-08-21 Thread Yaroslav M. Blanter

On 21.08.2014 21:17, Steven Walling wrote:
On Thu, Aug 21, 2014 at 11:04 AM, Magnus Manske 
magnusman...@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

___
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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] The reader, who doesn't exist

2014-08-21 Thread Michael Peel

On 21 Aug 2014, at 13:03, Andy Mabbett a...@pigsonthewing.org.uk wrote:

 On 21 August 2014 10:31, Strainu strain...@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_page
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


___
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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] The reader, who doesn't exist

2014-08-21 Thread Andy Mabbett
I was talking about navboxes, not infoboxes.

On 21 August 2014 19:04, Magnus Manske magnusman...@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 a...@pigsonthewing.org.uk
 wrote:

 On 21 August 2014 17:08, Isarra Yos zhoris...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe



-- 
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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] The reader, who doesn't exist

2014-08-21 Thread Strainu
2014-08-21 15:03 GMT+03:00 Andy Mabbett a...@pigsonthewing.org.uk:
 On 21 August 2014 10:31, Strainu strain...@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 em...@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_page
 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...@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

___
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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] The reader, who doesn't exist

2014-08-21 Thread Maryana Pinchuk
On Thu, Aug 21, 2014 at 6:29 AM, John Mark Vandenberg jay...@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.

-- 
Maryana Pinchuk
Product Manager, Wikimedia Foundation
wikimediafoundation.org
___
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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Options for the German Wikipedia

2014-08-21 Thread svetlana
On Mon, 11 Aug 2014, at 12:12, MZMcBride wrote:
 Hi.
 
 The German Wikipedia has evaluated and decided against the default use of
 MediaViewer on its project (preferring opt-in, rather than opt-out). Erik
 has made it his mission to impose MediaViewer on the German Wikipedia
 using Wikimedia Foundation staff coercion (cf.
 https://gerrit.wikimedia.org/r/153302 and
 https://gerrit.wikimedia.org/r/153345). Both changes have been pushed
 through hastily and have had negative repercussions as a result (missing
 translations, disrupted workflows, etc.). From a recent Bugzilla comment
 about the latter change, it's clear this change was a kneejerk reaction
 without a lot of thought as to the effects.
 
 The security of the entire MediaWiki infrastructure, which in turn is the
 security of a large portion of Wikimedia wikis, heavily relies on the idea
 that local administrators can be trusted. With his provocative actions,
 Erik has declared war on the German Wikipedia.
 
 Given this, there are options for the German Wikipedians. This is a
 non-exhaustive list and may not reflect the latest waste of developer and
 system administrator resources coerced by Erik.

Write an extension which removes superprotect from the wiki. Get local 
consencus on installing that.

svetlana

___
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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Options for the German Wikipedia

2014-08-21 Thread svetlana
BTW you should all love this idea:
https://meta.wikimedia.org/wiki/Community_Engagement_%28Product%29/Process_ideas#Get_local_consencus_for_your_changes

svetlana

___
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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

2014-08-21 Thread Erik Moeller
On Wed, Aug 20, 2014 at 12:32 AM, Pine W wiki.p...@gmail.com wrote:
 I am curious to hear your thoughts about the proposed Technology Committee.
 That idea has some community support and had been discussed at some length
 on the WMF Board Noticeboard.

I think it has merits if it's mostly used as a dispute resolution
body. I think we need to have conflict resolution and escalation
protocols for technology issues. Ideally WMF and a group of community
members (whether in all cases truly representative or not) who are in
conflict about a certain issue or outcome should be able to come to a
consensus _between each other_. But when that's not possible, a group
that is designed to be accountable to both WMF's mission and the
community's consensus may need to be called upon to make a final call
that is binding. In the current governance structure, that could be a
group like the stewards. But it could be something new created for
that purpose, if the community supports it.

This all presupposes that we collectively sign up for this whole
shared power idea. It's a Board creation, a guiding principle, and
all that. But that doesn't mean the community of people who've spent
much of their lives building Wikimedia's projects as volunteers do
believe in it. Maybe we should ask them, as a group, offering the pros
and cons of that approach. It's very different futures -- a WMF that
exists purely to do what communities ask it to, or a WMF that exists -
in part - to look forward, close gaps, and help anticipate where we
want to be 3, 5, 10 years from now. Irrespective of what my own take
might be, both approaches do truly have their merits.

If we sign up collectively for shared power, then today, we lack the
mechanisms to implement that principle effectively, which is why we
have conflicts over power which is not shared.  And a community
elected committee (perhaps with some additional representation of
external expertise) might be one such mechanism, but if we don't have
agreement on the basic idea, no mechanism will work. If we do agree on
the principle, we can try and play with different implementations.

Erik

-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

___
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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

2014-08-21 Thread rupert THURNER
Am 22.08.2014 04:18 schrieb Erik Moeller e...@wikimedia.org:

 On Wed, Aug 20, 2014 at 12:32 AM, Pine W wiki.p...@gmail.com wrote:
  I am curious to hear your thoughts about the proposed Technology
Committee.
  That idea has some community support and had been discussed at some
length
  on the WMF Board Noticeboard.

 I think it has merits if it's mostly used as a dispute resolution
 body. I think we need to have conflict resolution and escalation
 protocols for technology issues. Ideally WMF and a group of community
 members (whether in all cases truly representative or not) who are in
 conflict about a certain issue or outcome should be able to come to a
 consensus _between each other_. But when that's not possible, a group
 that is designed to be accountable to both WMF's mission and the
 community's consensus may need to be called upon to make a final call
 that is binding. In the current governance structure, that could be a
 group like the stewards. But it could be something new created for
 that purpose, if the community supports it.

 This all presupposes that we collectively sign up for this whole
 shared power idea. It's a Board creation, a guiding principle, and
 all that. But that doesn't mean the community of people who've spent
 much of their lives building Wikimedia's projects as volunteers do
 believe in it. Maybe we should ask them, as a group, offering the pros
 and cons of that approach. It's very different futures -- a WMF that
 exists purely to do what communities ask it to, or a WMF that exists -
 in part - to look forward, close gaps, and help anticipate where we
 want to be 3, 5, 10 years from now. Irrespective of what my own take
 might be, both approaches do truly have their merits.

 If we sign up collectively for shared power, then today, we lack the
 mechanisms to implement that principle effectively, which is why we
 have conflicts over power which is not shared.  And a community
 elected committee (perhaps with some additional representation of
 external expertise) might be one such mechanism, but if we don't have
 agreement on the basic idea, no mechanism will work. If we do agree on
 the principle, we can try and play with different implementations.


erik, let me ask a little in a devils advocate style:

is the conflict not only triggered by a deliverable which was not good
enough? it did not include the authors in its use cases. the deliverable
e.g. did include one click more for the authors workflow. which make
hundreds of million clicks more if you sum it up.

in a standard business world we would see two scenarios: one, the
ecyclopaedia britannica model. the authors would own the web domain, and
sue the one who delivers bad software. the design needs to be properly
specified beforehand to do this.

two, the facebook model. a company providing software to author as primary
goal, and some mechanism built in to count reads. it does everything to
increase it and would right from the start not deliver a complicated author
experience.

the wmf tries to play both models. and it then suffers schizophrenia. the
one delivering insufficient software does not get punished.

the reason is very simple: wikipedias content is of such high quality that
one might leave it with little updates for the next 20 years. also, the
readers experience is of such high quality that one might leave it for 20
years.

as somebody delivering software i understand your feelings quite well. you
get dug into a hole and do not know a good way to get out.

introducing additional levels of complexity is a well known strategy. but
we all know from our daily lives that we do tend to not like these levels
and bureaucracy.

erik, please can you tell me one good reason what hinders you to tackle the
source of all this, and rework the mediaviewer use case(s)?

devils adcocate mode out.

rupert
___
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-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Options for the German Wikipedia

2014-08-21 Thread
The page is already overly long and in places impenetrable, and I speak as
a systems analyst with Agile development experience. A shift to plain
English might be useful and more care to avoid dropping in fringe jargon
like Wiki markup is not Turing complete.
On 22 Aug 2014 01:39, svetlana svetl...@fastmail.com.au wrote:

 BTW you should all love this idea:

 https://meta.wikimedia.org/wiki/Community_Engagement_%28Product%29/Process_ideas#Get_local_consencus_for_your_changes

 svetlana

 ___
 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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe