Hi list,
I recently helped shepherd a new skin into Mediawiki;
https://www.mediawiki.org/wiki/Skin:Erudite
I would like to think it is perfect in every way, but one area it
hasn't had any love is making sure it works well on mobile devices.
To the best of my knowledge it shouldn't do anything particularly
heinous, but I don't have any such devices to test it on. If anybody
has a few minutes and could have a play, and see if anything could
be improved, please do and let me know on list.
A live example of it is at
https://www.dur.ac.uk/nick.white/erudite-demo/mediawiki-current/
which should have full editing etc rights enabled. It's a dummy
wiki, so add whatever you like.
Thanks in advance!
Nick White
<brion> and <tfinc> told me that the "Wikimedia Mobile" product in
Wikimedia Bugzilla is rather dead and that bugs should be reported
either against "Wikipedia App"/"Wiktionary App"/"WikiLoves Monuments
Mobile" for apps, or "MediaWiki extensions" -> "MobileFrontend" for the
mobile website.
Is this general consensus? (Silence means agreement.)
If so:
1) There are 56 open tickets that need retriaging
(your help is welcome):
https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&resolution…
2) I am going to close "Wikimedia Mobile" product for new bug
entries, and edit its product description to state where to
file tickets instead.
Thanks for your input!
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
Hello,
I found out, that items with class noprint are not delivered to the mobile
version. Is that a bug or feature? If it is feature, then I strongly suggest
to reconsider it and rather set up new class "nomobile" instead. Some stuff
with noprint is useful on mobile, it just does not have a sense to *print*
it.
Kind regards
Danny B.
Hello everyone!
As you might be aware, there has been ongoing work on a Commons application
for Android[1]. Hashar was awesome enough to set up automated builds of it
on Jenkins - you can download the latest from:
https://integration.mediawiki.org/nightly/mobile/android-commons/
It is currently at a state where you can upload fine (goes to testwiki),
but has minor issues on pre-4.0 devices. Expect rapid work on it over the
coming weeks!
[1]: https://github.com/wikimedia/android-commons
--
Yuvi Panda T
http://yuvi.in/blog
I just recently joined the Wiki community with the recent launch of
WikiVoyage. I have some experience working with iOS and would like to get
work started on an open source mobile app for WikiVoyage. Before I begin, I
want to know if WMF has any guidelines that need to be followed when
beginning development. Is there a particular architecture or set of
standards you guys use? Or are we free to "Plunge Forward" and make
whatever kind of app we want?
One WikiVoyager has already developed an open-source Android app, which
lives here: https://github.com/nicolas-raoul/OxygenGuide-Android and can be
downloaded here:
https://play.google.com/store/apps/details?id=org.github.OxygenGuide
If we build the app around that, can we use the WikiVoyage logo and
branding to make it the official app?
Thanks in Advance!
Hello all,
I am Nicolas Raoul, 10 years of wikipedia editing.
I just released this non-official Android app for Wikivoyage offline:
https://play.google.com/store/apps/details?id=org.github.OxygenGuide
Free, open source, of course.
It serves a different purpose than the existing official Wikivoyage app.
It lets people read Wikivoyage even when offline.
Like a paper guidebook, but stored in your phone.
At first run, it downloads OxygenGuide (a ZIP of all Wikivoyage text, 80MB).
Then you can enjoy the articles offline.
Bonus: Offline is much faster, because data is loaded from the SD card, not
from the Internet.
Offline is vital for travellers, because roaming is expensive.
Wikimedia's official app is great, but not offline, making it no-go for
most travellers... there is a "Save page" feature, but it is difficult to
know in advance every place and topic a travel you lead you to. Imagine
selecting and cutting pages from a paper guidebook one-by-one... rather
take the whole book if it is not heavy, right?
Special:Book generates monolithic A4-sized EPUB files with images, too
heavy for a phone if you select more than a few articles.
The app is functional, but ugly and many features could be added.
If anyone is interested, you're very welcome to join the team :-)
If Wikimedia wants to overtake the app, I would be flattered! If not, I
just continue as non-official, no worry.
If I violate any trademark or license, please let me know.
Also, any feedback is very welcome!
By the way, non-Android users can also copy the HTML articles manually to
their phone/reader/laptop: https://code.google.com/p/oxygenguide
Cheers!
Nicolas Raoul
http://nrw.free.fr
PS: Sorry for not writing as a reply in Chris' thread, I had not subscribed
yet when he posted. And sorry for kind of cross-posting with wikivoyage-l.
On 12/14/2012 02:17 PM, Chris McMahon wrote:
>
> 2. Decide a mobile area to focus, a way to run the sprint
> and a date for it. Define also the goals and how to measure
> the success of the sprint.
>
>
> I'm on board too, but I would like to suggest that Michelle spearhead
> this activity.
She seems to be busy...
I can put time organizing the event and promoting it but there is a key
aspect YOU (defaulting to Michelle / Maryana?) need to decide:
- What problem do we want to solve with this activity?
Once this is clear then we can answer better how, wen and who exactly
must be there doing what.
> ..."a way to run the sprint" is the tricky part. I think there are
> basically two options: synchronous and asynchronous. Synchronous is
> arguably more difficult, so lets' talk about that option first...
>
> Synchronous test event: we did this successfully for AFTv5. Here is
> the test plan that I used:
> http://www.mediawiki.org/wiki/QA/Article_Feedback_Test_Plan . That test
> plan is based on ideas from "Session Based Test Management",
> http://en.wikipedia.org/wiki/Session-based_testing (Just btw, the
> software testing articles on enwiki are pretty awful, someday I'd like
> to clean them all up, but it's a big job)
>
> I borrowed a lot of details for synchronous test events from the Weekend
> Testing Americas group. They found some time ago that Saturdays from
> 10AM-1PM Pacific time is generally more successful than other times.
> We had a dedicated test environment and an irc channel. Everyone worked
> at the same time and collaborated on IRC simultaneously, and it was more
> fun than you might imagine.
>
> Asynchronous test event: For a period of time (a day? a week?) I'm not
> sure...) everyone participating is testing on their own, pending
> whatever collaboration they can create among themselves I guess. I
> think a test plan with "charters" would be required for an async test
> event, as well as a coordinator to field information, feedback,
> questions, etc. from participants. I think Yuvi has done this before
> for mobile, but I don't know any details.
Again, without deciding the problem we want to solve it is difficult to
find the perfect answer to this.
In general I think an approach like this could work:
* We have one big goal and then other little goals related.
* Each goal has some tasks defined.
* Some of the tasks can be started and eventually completed by anybody
anywhere. We open the gates for those asap, identifying who can help
volunteers here and on IRC.
* As the sprint day approaches we can see what hard nuts haven't been
solved yet, what tasks benefit from synchronous collaboration.
* The goals of the sprint day (end eventually the agenda, if any is
needed) will be come clear as the date approaches.
* Then the sprint day is today and we all do our best.
* After that some of us still need to have energy and time in the
following days to process the useful data in the relevant wiki pages,
write the blog post and close the activity properly.
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil