CC'ing mobile-l as i'm sure the'll be interested by this.
--tomasz
On Wed, Apr 23, 2014 at 7:52 AM, Hari Prasad Nadig <hpnadig(a)gmail.com> wrote:
> 'Wikitrack' started out from an idea that I had about tracking edits on
> Wikipedia from mobile. I always felt that there's more to tracking edits
> and their quality on Wikipedia. For one, we could zero-in on better
> contributors than just going by the edit counts. And doing that for mobile
> could be good for a tool that can be used on the go.
>
> WikiTrack in its initial version had been released last year for Wikipedia
> projects of few Indian languages, namely Tamil, Malayalam, Kannada and
> Sanskrit for Android. The initial version allows the users to just track
> the Recent Changes, the diff between changes, their Watchlist and any
> user's contributions. Each of these have seen thousands of downloads (As of
> the day of sending this email: WikiTrack Tamil[1] - 17345 downloads with
> an average rating of 4.2 out of 5, WikiTrack Kannada[2] - 14480 downloads
> with an average rating of 4.038 out of 5 and WikiTrack Malayalam [3] with
> 7756 downloads with an average rating of 3.8 out of 5 on Google's Play
> Store) with thousands of active users tracking their favorite Wikimedia
> project using this application. The project so far has been self funded and
> the source code of the app has been released under GPL.
>
> I've put in an IEG Proposal[4] with a goal to consolidate these different
> apps into one and to provide support for all Indian languages and beyond
> (covering as many languages as possible), to rewrite the code, to make it
> better and to extend it further to improve the utility of the app including
> a release for iOS.
>
> The idea is to achieve the above goal and get it to a good shape before
> planning further on including other useful ways of allowing the editors to
> track Wikimedia projects from mobile and to keep them engaged.
>
> I realize that this is the very last minute request, but would love to hear
> feedback about it.
>
> [1]
> https://play.google.com/store/apps/details?id=com.saaranga.wikitracktamil
> [2] https://play.google.com/store/apps/details?id=com.saaranga.wikikannada
> [3]
> https://play.google.com/store/apps/details?id=com.saaranga.wikitrackmalayal…
> [4] https://meta.wikimedia.org/wiki/Grants:IEG/WikiTrack
>
> In case this is an incorrect list to post this, kindly accept my apologies
> and help by pointing me to the right one.
>
> Thanks!
> --
> Hari Prasad Nadig
> http://hpnadig.net
> http://twitter.com/hpnadig
> http://flickr.com/hpnadig
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Should auto update for those of you who have subscribed to it via the
play store (see
http://lists.wikimedia.org/pipermail/mobile-l/2014-March/006642.html
for details).
Changes from last alpha:
* Add instrumentation for edit, login, create account and reading
activity tracking
* Fix bug causing captcha in editing to not work
* More accurate User Agent setting
* Begin testing new icon
--
Yuvi Panda T
http://yuvi.in/blog
Yuvi, this may or may help for Android which I think did some slightly
different stuff in page saving.
In the application's Library/Caches folder there is a sqlite file
'Databases.db', which contains meta-information about the websql tables
that the PhoneGap-based app used.
In its 'Databases' table, the 'origin' field maps to a subdirectory of
Library/Caches, such as 'file__0'. 'name' holds the app-given table name,
in our case 'historyDB' or 'savedPagesDB' which is the fun one! And finally
the 'path' field maps to a filename of yet another sqlite database file
that actually contains the table, with cute names like
'000000000000000001.db'.
At least in the iOS version, the 'savedPagesDB' actual table appears to
actually be a mapping from API urls to JSON blobs holding the page title,
language, and format version.
The JSON data fetched from the API...? apparently is saved as a local file
in the 'Documents' directory, with the filename being the hex md5 sum of
the API URL.
So there's two main ways to go about this:
The first would be to just extract the saved title/language pairings out of
'savedPagesDB' value blobs, load those pages in sequence and run them
through our new save logic. This probably needs to be wrapped with a
progress bar and a way to cancel.
The second would be to try to actually migrate the saved data offline and
save it into the new format. This might be ickier, and I would happily skip
it, though working offline is always nice.
I'm starting on option 1, methinks. :)
-- brion
Wikimedia Mobile Web Team,
Where is our latest list of top phones to test on? This seems out of date
https://www.mediawiki.org/wiki/Compatibility#Mobile_browsers
and i can't find our other matrix chart.
--tomasz
On Fri, Apr 4, 2014 at 7:54 AM, Megan Hernandez
<mhernandez(a)wikimedia.org> wrote:
> Hey Tfinc,
>
> We're getting into testing more mobile banners over here in fundraising. At
> the moment, we're testing these out on our mix of personal phones, friends,
> & online simulators. So we want to get our reader top used phones to use for
> internal testing.
>
> Do you guys already have a list of the top devices we should get based on
> our reader usage? Any best practices / tips you can share about internal
> mobile testing before our new banners hit the site? At the moment, we are
> testing the banners out ourselves on a variety of devices, putting them into
> usertesting.com, watching readers in focus groups and of course on loyal
> friends/guinea pigs. Would love to hear your tips.
>
> TY for the info & go mobile,
>
> Megan
>
>
> --
>
> Megan Hernandez
>
> Director of Online Fundraising
> Wikimedia Foundation
I conducted a little bit of research on visual regression testing,
mainly for the mobile team for now, but it could be easily reused for
other teams. I had a look at three existing solutions that seem somewhat
popular and are actively developed:
* Wraith (https://github.com/BBC-News/wraith)
* PhantomCSS (https://github.com/Huddle/PhantomCSS)
* Huxley (https://github.com/facebook/huxley)
They all have their own pros and cons, but in my opinion they share one
important disadvantage: they can't be easily integrated with our current
browser testing setup. For all the aforementioned tools we would have to
create from scratch a completely separate set of tests just for visual
regression testing instead of extending our existing browser tests.
I spent a few hours in my spare time tinkering with an alternative idea
which would enable us to add visual regression testing to our
Cucumber/Watir tests. The result is a small prototype available at
https://github.com/jgonera/photographer. There is no docs or anything
yet, but I prepared a simple demo patch for MobileFrontend:
https://gerrit.wikimedia.org/r/#/c/126878/.
The idea is to add a new method for Cucumber steps (snap) that takes a
screenshot of the current browser state and compares it with a
screenshot taken in one of the previous test runs. To update screenshots
that are used as a reference you run tests with env var
PHOTOGRAPHER=update. If newly taken screenshot differs by too many
pixels from an old one, the test will fail.
It's still only an early prototype, but I'd appreciate any comments
about this idea.
--
Juliusz
Moving to mobile-l@ since this tool pulls in community filed bugs
On Fri, Apr 18, 2014 at 1:17 PM, Arthur Richards
<arichards(a)wikimedia.org> wrote:
> Bugello was choking on a unicode character in the current sprint board
> title, preventing it from running. Tomasz changed the title of the board,
> and bugello is now running, happily piping in bugs since its last successful
> run.
>
> As an aside, I will be working on some bugello enhancements over the coming
> days to try and achieve closer feature parity between Bingle/Bugello - I
> will be in touch as that all unfolds. If there's anything in particular
> you'd like to see Bugello do that it currently doesn't, please file an issue
> on github: https://github.com/wikimedia/bingle
>
> --
> Arthur Richards
> Software Engineer, Mobile
> [[User:Awjrichards]]
> IRC: awjr
> +1-415-839-6885 x6687