I propose we remove the Wikimedia Commons app from the store.
Clearly there is no time available to work on it, there is no one maintaining it or following up on the problems that have been reported since 2013.
Yann is just brining it up on wikimedia-l and I think that it is bad to have an app out there that no on is taking care of. So we should pull it and whoever wants to continue with it can release it under a name of this own.
DJ
As the zero team starts to think about pre-loaded content the question
of how search will function within an off line environment has come
up. While it'll be up to each individual community to think about the
size of the pre-loaded we should think about these collections being
longer than a user would want to scroll through given only our article
title search.
Thus i'm eager to get a discussion going abut how we would support the
following users story
"As a user who has a Wikipedia pre-loaded device with little or no
internet connectivity, I would like to search by article text, so that
I can find multiple articles that could be relevant to me"
Given this, an article title search is not good enough.
* What would we have to change about our underlying data storage
architecture to do full text search?
* How fast would it be?
* Would it scale to 100's/100's/etc on articles ?
* What would the user experience look like?
...
* ... other bits i haven't thought about ?
This is not at a resourced feature level discussion yet but I'd like
to get some engineering thoughts on it before we get there.
--tomasz
Bryan, one of the engineers in the MediaWiki Core Team, is starting to look
at making MediaWiki have more of a library-based structure instead of being
a gigantic monolith. In particular, he asked one question which is of
relevance: "What functionality from MediaWiki do you miss when you write a
standalone PHP app?". As this is about MediaWiki internals this may only be
of limited relevance to the Mobile Apps Team since we consume MediaWiki
content via the API, but I thought I'd forward it here anyway in case
anyone has any questions or suggestions for Bryan.
Dan
---------- Forwarded message ----------
From: Bryan Davis <bd808(a)wikimedia.org>
Date: 29 September 2014 23:07
Subject: [MediaWiki-Core] Library infrastructure project ideas
To: mw-core-l <mediawiki-core(a)lists.wikimedia.org>
I've started an etherpad [0] with some ideas about what we could try
to do for the Q2 Library infrastructure project. Since this morphs a
bit every time two or more of us talk about it, I'd like to get some
collective notes/input before we walk into the quarterly review to
pitch the idea and let the group there tell us what we should be
doing.
I know that I want to finish the logging work. I think this can be
used as a good example of how to consume external libraries in
MediaWiki core as well as helping solve a real deficiency in our
existing code base. My RFC on the topic is a good start but the
processes and procedures outlined there need to be published in a more
visible place on wiki and battle tested for deficiencies.
I think I'd also like to see the Profiler work done as I've heard that
many components in MediaWiki are basically only tied to logging and
profiling. I'm totally willing to be persuaded that there is a better
candidate for extracting into a library however. One question I'd like
to ask is "what functionality from MediaWiki do you miss when you
write a standalone PHP app?" Database? Caching? I18n bits and pieces?
Is one of these more compelling for extracting and publishing than the
profiler?
I'd also like to hear ideas about how we should be documenting the
extracted libraries. Should we have a different workflow for
generating docs from code? Is publishing docs as wiki pages a good,
bad or meh idea? If we don't document on wiki how can we encourage
document contributions from casual users? If we do document on wiki
how can we ensure that changes in the API are propagated to the
documentation soon after merge? How important is localization for code
documentation?
In case you are wondering "who put Bryan in charge here?", the answer
is RobLa. :) Following in the model of the HHVM project where Ori has
been acting as project manager / product owner, RobLa has tapped me to
take the lead on organizing the library infrastructure project if it
gets green lighted. I'll need a lot of help since I still don't know
as much about MediaWiki itself as our average 13 year old contributor,
but I hope I can be of service with my experience in project and
product management.
[0]: https://etherpad.wikimedia.org/p/MWCoreLibraryInfrastructure
Bryan
--
Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
[[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA
irc: bd808 v:415.839.6885 x6855
_______________________________________________
MediaWiki-Core mailing list
MediaWiki-Core(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-core
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
Forwarding from Siko Bouterse:
Greetings! The Wikimedia Foundation Individual Engagement Grants program is
accepting proposals for funding new experiments from September 1st to 30th.
<https://meta.wikimedia.org/wiki/Grants:IEG>
Your idea can improve Wikimedia projects by building a new tool or gadget,
organizing a better process on your wiki, conducting research on an
important issue, or providing other support for community-building. Whether
you need $200 or $30,000 USD, Individual Engagement Grants can cover your
own project development time in addition to funding for a team to help you.
The program has a flexible schedule and reporting structure, and
Grantmaking staff are there to support you through all stages of the
process.
Do you have have a good idea, but you are worried that it isn’t developed
enough for a grant? Put it into the IdeaLab, where volunteers and staff
can give you advice and guidance on how to bring it to life. <
https://meta.wikimedia.org/wiki/Grants:IdeaLab> Also, IEG will be hosting
three Hangout Sessions for real-time discussions to help you make your
proposal better - the first will happen on September 16th. <
https://meta.wikimedia.org/wiki/Grants:IdeaLab/Events#Upcoming_events>
For inspiration, you can read more about past projects <
https://blog.wikimedia.org/tag/individual-engagement-grants/> that received
funding or review open proposals <
https://meta.wikimedia.org/wiki/Grants:IEG#ieg-reviewing>. We are excited
to see some of the new ways your grant ideas can support our community and
make an impact on the future of Wikimedia projects.
Submit your proposal in September! <
https://meta.wikimedia.org/wiki/Grants:IEG#ieg-apply>
(Duplicating this mail, as I wasn't subscribed to mobile-l a minute ago.)
On Sat, 16 Aug 2014, at 12:45, Nkansah Rexford wrote:
> [...]
> The Wikipedia app is currently under good development and I think its doing
> great.
We don't need apps. We need mobile websites which work as good as an app does.
Oh, the waste of effort.
I truly pledge you to work together to make a website which is so good that an 'app' is redundant.
svetlana
Background:
* A patch got merged Fri Aug 29 [A] that bucketed 50% of edits so they
would reload the page after an edit (test A), and 50% of edits would
re-render the page in JavaScript using an ajax loader (test B)
* The patch went live on English Wikipedia on the 11th September.
Method:
* I looked at an arbitary 7 day period before the 11th September (27th
August till 4th September) and I looked at an arbitary 7 day period
after the A/B test went live (12th till 19th September)
* I counted successful edits via the mobile interface on English
Wikipedia, restricted to the stable mode of the site and to the source
editor only (not VisualEditor interface). This would minimise variance
between the interfaces that could happen across different
projects/languages/experimental features.
* I looked at the exact same 7 day periods but this time restricted
them only to editors with less than 5 editors to restrict the data to
new editors.
* I counted edits across all projects and how they varied post A/B test
Results:
Table 1:
For the 7 day period before the A/B test [1].
isTestA Successful edits
0 9883
1 11097
Table 2:
For a 7 day period after the result went live [2].
isTestA Successful edits
0 8835
1 7011
Table 3:
For the 7 day period before the A/B test where the editors at the time
of completing an edit had less than 5 edits [3]
isTestA Successful edits
0 4276
1 4449
Table 4:
For the 7 day period after the A/B test where the editors at the time
of completing an edit had more than 5 edits [4]
isTestA Successful edits
0 3359
1 2707
A breakdown per project can be found here generated using this SQL query [5]:
https://docs.google.com/spreadsheets/d/11RFrOd4CBVk2hXIHjbSz8SPyMH7GlARUkNb…
Analysis:
Pre-A/B test for all editors, 1214 more edits occurred in bucket A
(5.7%). See Table 1.
You'd expect these to be the same. This raises concerns that there
might be a problem with the A/B bucketing.
However if you look at table 3:
Pre A/B test for editors with less than 5 edits, 173 more edits
occurred in bucket A (1.9%).
Post A/B test for all editors, 1824 more edits happened in bucket B
according to table 2 (11.5%)
Post A/B test for editors with an edit count of less than 5, 652 more
edits happened in bucket B according to table 4 (10.7%)
* Considering the shift of successful edits from occurring in bucket A
to bucket B, it is possible that ajax loading a page is generally
getting us more edits. It seems that looking at new editors (edit
count less than 5) is a more accurate way to compare the two sets of
data.
* This could possible be because the page reloads quicker, and a user
is more likely to see a mistake and do a follow up edit or to get a
better experience from editing (finds it quicker and more
pleasurable.)
I'd suggest more investigation into this but this data is pretty
fascinating. Please do tear apart my method/investigate further.
Links____
[A] https://gerrit.wikimedia.org/r/#/c/155675/
[1] select event_isTestA, count(*) from MobileWebEditing_8599025 where
event_action = 'success' and timestamp > 20140827000000 and timestamp
< 20140904000000 and event_editor = 'SourceEditor' and wiki ='enwiki'
and event_mobileMode = 'stable' group by event_isTestA
[2] select event_isTestA, count(*) from MobileWebEditing_8599025 where
event_action = 'success' and timestamp > 20140912000000 and timestamp
< 20140919000000 and event_editor = 'SourceEditor' and wiki ='enwiki'
and event_mobileMode = 'stable' group by event_isTestA
[3] select event_isTestA, count(*) from MobileWebEditing_8599025 where
event_action = 'success' and timestamp > 20140827000000 and timestamp
< 20140904000000 and event_editor = 'SourceEditor' and wiki ='enwiki'
and event_userEditCount < 5 and event_mobileMode = 'stable' group by
event_isTestA
[4] select event_isTestA, count(*) from MobileWebEditing_8599025 where
event_action = 'success' and timestamp > 20140912000000 and timestamp
< 20140919000000 and event_editor = 'SourceEditor' and wiki ='enwiki'
and event_userEditCount < 5 and event_mobileMode = 'stable' group by
event_isTestA
[5] select event_isTestA, wiki, count(*) from MobileWebEditing_8599025
where event_action = 'success' and timestamp > 20140912000000 and
timestamp < 20140919000000 and event_editor = 'SourceEditor' and
event_mobileMode = 'stable' group by wiki, event_isTestA order by
wiki,event_isTestA
Hi everyone,
*tl;dr: The Mobile Apps iOS Engineering Team is doing some refactoring of
network operations and data storage in the iOS app. Track our progress
using the red and purple filters on our Trello board
<https://trello.com/b/zgT6XuU6/mobile-app-sprint-40-ios-insert-theme-9-15>.*
The iOS team has been working on the "Update all for saved pages" story
this sprint. The work is taking much longer than expected due to some
antiquated code in the app that handles network operations and data
storage. The code is fragile, which creates peculiar crashes that are
difficult to diagnose, it's hard to maintain, and it's difficult to develop
on. "Update all for offline reading" in particular involves one synchronous
process (the downloading of the data) talking to another (the saving of the
data) in the background while there are other tasks going on in the main
thread, which is a difficult enough problem to deal with without also
dealing with antiquated code.
This problem needs to be dealt with. Rather than delaying dealing with it,
we decided to tackle it head on.
Our two high-level objectives for the refactor are:
- Migrate from our custom network operation code to the AFNetworking
library, a well-maintained open source networking library.
- Migrate our data storage system from Core Data to using a flat file
system.
This translated into a list of 11 action items, which are recorded on on
our Trello board
<https://trello.com/b/zgT6XuU6/mobile-app-sprint-40-ios-insert-theme-9-15>
using
the purple (networking refactor) and red (storage refactor) filters.
In terms of priorities, this refactoring effectively blocks the "Update all
for offline reading" story. That said, a sprint represents a commitment to
completing the stories in said sprint, so we are going to complete
everything in our current sprint that is not dependent on the refactoring
before we begin the refactoring itself.
If you have any questions, please do ask!
Thanks,
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
I'm using an Apple iPad mini (1st gen), on iOS 8.0 (12A365).When logging in, the button should say "log in", and not "done".There is a lot of "blank"/whitespace at the bottom of every page.Pressing "W" should make the "Black" a little transparent, and not compleatly black.Pressing the "share"-button makes the app crash.There is nothing in the about privacy policy or disclamers (like in the bottom of the website).Make it possible to drag the "W" and "lines" and not just the sides.When searching: if only a few results show, the rest of the space with no results, should not be white, but transparent.I'm unable to delete specific pages from the "Saved pages"-page.
Abbey and Daisy did some live user testing of WikiGrok version A out at
Yerba Buena yesterday – here's their full write-up:
https://www.mediawiki.org/wiki/Guerrilla_Testing_Wikigrok_Version_A
A few actionable/interesting takeaways:
1) This version (in-line) is definitely less obtrusive to the reader
experience than the pop-up overlay of the initial WikiGrok prototype;
people didn't react strongly to it and didn't seem to think it was anything
unusual or surprising. I think this is a good sign – it means we're more
likely to get answers from people who are carefully reading the article and
notice the call to action, not random button-mashers ;)
2) The UX is very easy to use, virtually painless. Good designin', Moiz!
The only potential issue is that the tap events are being triggered a bit
inconsistently. You can see it for yourself if you play around with it on
beta labs – sometimes it takes awhile for the buttons to register a tap,
and if you're impatient and tap a few times, you might accidentally end up
on the second screen tapping on "yes" before you've even had a chance to
read the question. Might need to investigate ways to improve this
(Juliusz's Microtap stuff?).
3) People thought this might be an alternative to editing or a new way to
edit. A few who'd tried unsuccessfully to make an edit in the past even
pointed out how much better/easier this is. Early days and small sample
size, but it's cool to get a bit of validation of the hypothesis that we
can engage a much wider audience with a feature like this, including people
who would never otherwise contribute to Wikimedia projects :)
--
Maryana Pinchuk
Product Manager, Wikimedia Foundation
wikimediafoundation.org