Re: [Wikimedia-l] The reader, who doesn't exist
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 wrote:
>
>> 2014-08-21 9:30 GMT+03:00 Federico Leva (Nemo) :
>> 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,
>
___
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,
Re: [Wikimedia-l] CheckUser openness
Notification of some checks would always have to be withheld to allow complex investigations to be completed without "tipping off". There is public information that suggests there have been complex abuse cases (real abuse, like harassment, not vandalism). To notify parties suspected of involvement while these long running investigations are underway is broadly analogous to receiving an automated email when your name is searched on the FBI national computer: the innocent want an explanation that wastes police time; the guilty realise they are being investigated and are tipped off to adapt their behaviour. As soon as there is an option to suppress the alert you are back to square 1: CUs may suppress the notification to "hide" what they are doing. End of the day, the communities elected the CUs knowing they'd be able to secretly check private data - so you have to trust them to do what you ask them to do or elect someone else you do trust. Neil / QuiteUnusual@Wikibooks -Original Message- From: Nathan Sender: wikimedia-l-boun...@lists.wikimedia.org Date: Thu, 14 Jun 2012 22:10:33 To: Wikimedia Mailing List Reply-To: Wikimedia Mailing List Subject: Re: [Wikimedia-l] CheckUser openness On Thu, Jun 14, 2012 at 8:06 PM, Dominic McDevitt-Parks wrote: > I think the idea that making the log of checks public will necessarily be > a service to those subject to CheckUser is misguided. One of the best > reasons for keeping the logs private is not security through obscurity but > the prevention of unwarranted stigma and drama. Most checks (which aren't > just scanning a vandal or persistent sockpuppeteer's IP for other accounts) > are performed because there is some amount of uncertainty. Not all checks > are positive, and a negative result doesn't necessarily mean the check was > unwarranted. I think those who have been checked without a public request > deserve not to have suspicion cast on them by public logs if the check did > not produce evidence of guilt. At the same time, because even justified > checks will often upset the subject, the CheckUser deserves to be able to > act on valid suspicions without fear of retaliation. The community doesn't > need the discord that a public log would generate. That's not to say that > there should be no oversight, but that a public log is not the way to do it. > > > Dominic > The threat of stigma can be ameliorated by not making the logs public, which was never suggested. A simple system notification of "The data you provide to the Wikimedia web servers has been checked by a checkuser on this project, see [[wp:checkuser]] for more information" would be enough. En Pine's reply to my queries seems calibrated for someone who is unfamiliar with SPI and checkuser work. I'm not - in fact I worked as a clerk with checkusers at SPI for a long time and am quite familiar with the process and its limitations. I know what's disclosed, approximately how frequently checks are run, the general proportion of checks that are public vs. all checks, etc. I still am not clear on how disclosing the fact of a check helps socks avoid detection, and I still believe that it's worthwhile for a transparent organization like Wikimedia to alert users when their private information (information that is, as Risker has mentioned, potentially personally identifying) has been disclosed to another volunteer. Nathan ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l ___ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
