Amir E. Aharoni, 17/09/2014 10:05:
> WAT.
>
> Are these millions and millions of real people clicking Random article
> all the time? Not search engines or bots or something?
I have no reason to believe it's an especially inflated number:
Special:Random is the most common tool for curious users in search of
something to read or edit, together with watchlist (which anons don't
have) and recent changes. Disbelievers can do some appreciated
additional research though. :-)
>
> Do taps on Random article in the apps count as hits to Special:Random?
Not for stats.grok.se, for sure.
https://en.wikipedia.org/wiki/User:Killiondude/stats#What_about_mobile.3F
Nemo
The Mobile App team had their monthly retrospective today.
Notes, actions and further discussion items are below.
https://www.mediawiki.org/wiki/Wikimedia_Apps/imported/Retrospective-August…
= Actions/Further Discussion =
*Set up quarterly "unstructured sprint" [Kristen/Dan]
*Give Vibha & Moiz iTunes account login access [Tomasz]; Waiting on Design
iTunes account [Vibha]
*Give Vibha & Moiz access to data about user actions [Dan]
*Set up monthly apps data review meeting [Dan/Vibha]
*Blog post and social media to recruit testers [Monte/Vibha/Moiz]
*Explore paid testing services [Tomasz]
Velocity Graph has been updated to reflect recent sprints:
https://docs.google.com/a/wikimedia.org/spreadsheet/ccc?key=0AlEIL4N8KjNndH…
Thanks apps team and friends!
-Kristen
[Was: iOS app feedback (via testflight)]
When I first saw the "Random article" in Wikipedia bask in 2004 or so, I
immediately though - "Right, they probably added because they wanted it to
look like an old-school paper encyclopedia that you can open randomly."
I guess that it's not clear to all people.
If I recall correctly, that button was added because there were requests
for it, but was its existence ever justified? If there's interesting data
about using the "random" button, a blog post could be published about it
that would serve as the rationale for keeping the functionality. For
example, that it gets people to read and click more links and maybe become
editors.
Also, it could be relabeled as something more fun without using the word
"random", which is a tad technical. The first thing that comes to my mind
is "I just want to read something."
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
2014-09-17 3:48 GMT+03:00 Monte Hurd <mhurd(a)wikimedia.org>:
> We received the following feedback email through testflight:
>
>
> Hi, I already tested your latest updates in Wikipedia 4.0.2, and I want to
> give you some feedbacks :
>
> 1.) If I want to see my previous article or my next article, I don't need
> to press the back (<) button or forward (>) button. Instead, I can swipe my
> finger from the left or right side of the display. (For example, the
> navigation gesture in Safari)
>
> 2.) When I want to delete my saved page, the animation is a bit late.
>
> 3.) The "Random" button in the sidebar. Actually, I don't understand why
> it was made. Because, someone who opens Wikipedia, must be know what he/she
> looking for. So, I want to suggest to delete the "Random" button (*if you
> don't mind)
>
> That's all I want to say. And I hope to see another beta updates. Thank
> you.
>
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
We received the following feedback email through testflight:
Hi, I already tested your latest updates in Wikipedia 4.0.2, and I want to
give you some feedbacks :
1.) If I want to see my previous article or my next article, I don't need
to press the back (<) button or forward (>) button. Instead, I can swipe my
finger from the left or right side of the display. (For example, the
navigation gesture in Safari)
2.) When I want to delete my saved page, the animation is a bit late.
3.) The "Random" button in the sidebar. Actually, I don't understand why it
was made. Because, someone who opens Wikipedia, must be know what he/she
looking for. So, I want to suggest to delete the "Random" button (*if you
don't mind)
That's all I want to say. And I hope to see another beta updates. Thank you.
Several front end engineers, designers, and others got together again
to update on their progress to standardize icons across projects
today. This was a follow to the previous conversation on 8/27 [1].
Big take aways:
* Monte iterating and almost completing his SVG->Font python scripts
* Trevor & Bartosz finalizing an npm module for customizing SVG generation
* Jon needing additional support from Sam to move forward on mw ui icon markup
Notes from the discussion can be found on etherpad [2]
Follow up items:
* Finish up SVG2FONT2SVG script (hopefully done in a week) (Monte)
** Create manifest for padding and other small options (Trevor)
* Review Trevor's SVG/PNG generation (Everyone present once its out)
* Followup with Sam for standard icon html mark-up (Matt)
* Schedule team discussion follow up (Tomasz)
Please update as necessary if you attended and I've forgotten or
misrepresented anything.
thanks all
--tomasz
[1] - https://lists.wikimedia.org/pipermail/mobile-l/2014-August/007922.html
[2] - http://etherpad.wikimedia.org/p/IconStandardization
We'll see how long the review queue takes. :D
If people get their iPhone 6s before this hits they should still work with
4.0.2, they'll just be scaled up and a little fuzzy.
-- brion
Hi everyone,
Often someone will ask the question "Hey, when was feature X released?".
It's really important that we keep this information logged. So that we have
this information, we have a release history page
<https://www.mediawiki.org/wiki/Mobile/Release_history#Native_Wikipedia_Apps>
to
serve as a one stop shop for this information. But it's a bit out of date
right now.
I'd like to propose that whenever someone pushes out a build to the App
Store or to Google Play, that person takes 5 minutes afterwards to fill in
this table for posterity.
Notably, the iOS app section is totally blank. It'd be great to get this
filled in. :-)
Thanks,
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
The reduced quality images is now live in production. To see it for
yourself, compare original
<http://upload.wikimedia.org/wikipedia/commons/thumb/c/cb/Buildings_of_Bedfo…>
with low quality
<http://upload.wikimedia.org/wikipedia/commons/thumb/c/cb/Buildings_of_Bedfo…>
images
(253KB => 99.9KB, 60% reduction).
The quality reduction is triggered by adding "qlow-" in front of the file
name's pixel size.
Continuing our previous discussion, now we need to figure out how to best
use this feature. As covered before, there are two main approaches:
* JavaScript rewrite - dynamically change <img> tag based on
network/device/user preference conditions. Issues may include multiple
downloads of the same image (if the browser starts the download before JS
runs), parser cache fragmentation.
* Varnish-based rewrite - varnish decides which image to server under the
same URL. This approach requires Varnish to know everything needed to make
a decision.
Zero plans to go the first route, but if we make it mobile, or ever site
wide, all the better.
Here's a screenshot of an experimental nearby interface in the iOS Wikipedia app. The little green directional arrows take into account device orientation to guide you to the coordinate. Distances update in real time as well.
