Windows 8.1 was released yesterday, with some changes to the search
interface.
I've pushed out a new version of our Wikipedia app for Windows 8.1 which
uses the new search box style, and fixes a few crashing bugs. The bug fixes
(without the search UI change) are also available as an update on Windows 8.
Both Windows 8 and Windows 8.1 versions are available for installation via
the Windows Store.
Note that source has been broken out from the older cross-platform mobile
app to a standalone repository for future maintenance:
Repository view: <
https://git.wikimedia.org/summary/apps%2fwin8%2fwikipedia.git/HEAD>
Github mirror: <https://github.com/wikimedia/apps-win8-wikipedia>
-- brion
>> identity might be more important on some projects rather than others
>
> they have a profile and can access it by tapping on their username in the
> menu.
>
I actually thought the number of clicks was pretty high but noticed it
was higher on enwiki suggesting some projects might care more about
this sort of thing. I suspect a lot of this is due to "oh what's this
new thing"
>
> How do we know they're switching between beta/alpha/stable frequently?
>
I am making this big assumption yes and I don't know this but I'm
alluding to the fact that logging what people do on the settings page
might be a useful thing to do. Personally I'd be very surprised if use
of the toggle images on/off feature is significant. I would actually
like to kill this if data allows a reason to. This to me is a feature
that browsers should have - not websites.
> I like the idea of making 'random' easier to get to - I would certainly use
> that a lot for testing. It bugs me that I have to always open the menu
> first.
https://gerrit.wikimedia.org/r/#/c/87427/ might interest you then
>
> --
> Arthur Richards
> Software Engineer, Mobile
> [[User:Awjrichards]]
> IRC: awjr
> +1-415-839-6885 x6687
--
Jon Robson
http://jonrobson.me.uk
@rakugojon
More hopefully interesting data for you to digest...
We added some click tracking to the left menu (aka the 'hamburger
menu') in the beta/alpha version of the mobile wiki sites to get a
feel for how people use it.
My take on the data is the following theories (note this is skewed to
users of beta who are likely to be a completely different profile to
users of stable - it would be good to collect similar data on the
stable version of the site to see how it differs):
* users click on the home button to escape special pages and get back
to the search - this is why it is the most popular button. We should
make the UI for special pages more consistent with article pages.
* The watchlist is the feature of choice for logged in users
* Nearby is a much more popular choice for anonymous users but doesn't
seem to be used by editors to discover
* Profile is a new addition and early data suggests a sense of
identity might be more important on some projects rather than others
* People seem to go to the settings page to switch between
beta/alpha/stable frequently. It would be interesting to understand
why - is it because features are broken, or they want new features? It
would be good to reduce this - I'd like to get to the stage people
feel more comfortable in one rather than the other - ideally lack of
desire to switch modes suggests we are creating a comfortable
environment for them to live in.
* Random is actually a popular feature. We could probably make this
feature between that a link in a menu you have to open first to get
to.
* Anonymous users don't tend to login directly from the left menu they
are likely to be driven by a link to the feature they want to view
And the data:
********************************************************************************************
For enwiki beta/alpha logged in users [1]:
hamburger-home 138
hamburger-watchlist 107
hamburger-settings 99
hamburger-random 71
hamburger-profile 57
hamburger-uploads 56
hamburger-nearby 37
hamburger-logout 21
For all beta/alpha wikis logged in users [2]:
hamburger-home 302
hamburger-watchlist 263
hamburger-settings 216
hamburger-random 148
hamburger-uploads 115
hamburger-nearby 89
hamburger-profile 57
hamburger-logout 22
We recently added logging for anonymous users in beta and alpha [3]
hamburger-home 383
hamburger-random 384
hamburger-settings 350
hamburger-nearby 171
hamburger-watchlist 158
hamburger-uploads 101
hamburger-login 6
Break down of what mode people are in whilst using settings [4]:
alpha 127
beta 441
stable 30
[1] SELECT event_name, count(*) from MobileWebClickTracking_5929948
where event_name LIKE 'hamburger%' and event_username != '' and
event_mobileMode!='stable' and wiki = 'enwiki' group by event_name
[2] SELECT event_name, count(*) from MobileWebClickTracking_5929948
where event_name LIKE 'hamburger%' and event_username != '' and
event_mobileMode!='stable' group by event_name
[3] SELECT event_name, count(*) from MobileWebClickTracking_5929948
where event_name LIKE 'hamburger%' and event_username = '' and
event_mobileMode!='stable' group by event_name
[4] SELECT event_mobileMode, count(*) from
MobileWebClickTracking_5929948 where event_name = 'hamburger-settings'
group by event_mobileMode
Commons mobile app updates are in staging now...
Wikimedia Commons for Android 1.0beta12 should appear in Google Play within
a few hours. It can also be installed directly from
http://dumps.wikimedia.org/android/wikimedia-commons-1.0beta12.apk
Android version includes various smaller bug fixes, and now displays
license info for previously-uploaded photos.
Wikimedia Commons for iOS 1.0.9 has been released to registered beta
testers; if nothing explodes we'll push to Apple for review Thursday or
Friday.
iOS version includes support for iOS 7 visual style, many many many UI
improvements and bug fixes, and is generally just awesome! Users can also
now select from CC-BY-SA 3.0, CC-BY 3.0, or CC-Zero license options instead
of being always forced to CC-BY-SA 3.0.
-- brion
The MobileFrontend extension will see 2 changes within the next 3
weeks that will result in more API requests. I wanted to bring these
to the attention of ops to give you an opportunity to raise any
concerns.
The first makes the mobile uploads page exhibit infinite scroll. You
can see what this does if you compare the existing version [1] with
the beta version [2] and scroll to the bottom of the page. You will be
able to see the additional requests such a feature makes.
The second change will make Echo notifications load in mobile via
JavaScript avoiding a request to
https://en.m.wikipedia.org/wiki/Special:Notifications (this is no
different from the desktop version of the site)
You can track these changes on Mingle [3,4]. Based on the teams
existing velocity they are likely to be made and deployed no sooner
than Thursday 23rd to test wiki in that week's deployment train,
however there is a small chance they could make it a week early.
Please let us know if this could cause any issues.
[1] https://en.m.wikipedia.org/wiki/Special:Uploads/Kaldari
[2] https://en.m.wikipedia.org/wiki/Special:Uploads/Kaldari?mobileaction=beta
[3] https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1282
[4] https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1283
Hi Mobile List
One of my biggest gripes about the app is the fact that I need to load the
front page onto my phone when I open the app up. In my scenario, I will
usually pull up the Wikipedia app to look up some facts to settle a
friendly discussion; all of my friends who use the app use it similarly.
Since I never use the app to *browse* Wikipedia like I do when I'm at home
at my desktop computer, there's no use in loading the front page. In fact,
it's pretty frustrating when the text I'm typing in the search bar lags, or
gets reset as I'm typing my entry, and I'm forced to wait for the front
page to load first. It sort of defeats the purpose of having quick access
to Wikipedia, since the alternative would be to open up a browser and go to
wikipedia.org or flip through Google search entries.
(I'm using Version 3.3.1 on an iPhone 4 with iOS 7 if that's relevant.)
I was curious if there has ever been discussion about adding a setting that
would allow the user to see the search bar only instead of the front page
when she opens the app.
I've already posted about this idea on the Mobile/2013 strategy planning
page, but I'm not sure how deep into the idea list people are reading:
https://www.mediawiki.org/wiki/Mobile/2013_strategy_planning#Option_to_only…
Apologies if this is not the appropriate forum to discuss this kind of
issue. I just subscribed to this list.
Thanks,
Oliver Zhu
Hi,
So today I worked with Kaldari (thanks for the help!!) and committed a very
simple module to enable webfonts support in MobileFrontend:
https://gerrit.wikimedia.org/r/#/c/86340/https://gerrit.wikimedia.org/r/#/c/86337/
Review and any comments are very welcome, of course.
The current implementation is very simple. It doesn't allow any
configuration or choice of fonts - if there is a default font for the
language, it is used wherever there's a lang attribute or a style or a
class the sets a font explicitly. (Some languages, like Tamil and Hebrew
have fonts, but they are not default, so none are used). It may be worth
optimizing it, for example:
* Only loading the font of the content language to save time and bandwidth.
(Loading additional fonts can be an option.)
* Only loading fonts on devices that are known to have bad font support. On
iPhone and it's pretty for many languages. On the latest Windows Mobile
version it's very good. On Android below 4.0, however, it's very bad: most
languages of India are completely unreadable, which is the main reason to
do this (the same goes for languages of Ethiopia, South-East Asia and some
others). Android 4 and above is not always perfect either.
I'd love to hear more considerations about bandwidth, performance, testing
etc.
Thanks!
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore