I've just met with Jean-Baptiste and Felix from the VLC media player
project about integrating their player as a library that we can drop into
the iOS Wikipedia app to get Ogg and WebM audio/video playback working.
This will be *a lot* easier than maintaining our own media player library
(which I'm already doing with ogv.js in JavaScript to get things working in
Safari and IE, so that saves me having to duplicate the work in
Objective-C!) Using the player is just a few lines of code and will take
very little time to integrate once the clean library build is available.
I'll whip up a provisional patch on the weekend after we've landed some
general app refactoring which is currently higher-priority.
*= Performance =*
Native code playback is much faster than my JavaScript solution, so the app
will be able to play back high-definition WebM files that we can't play in
Safari. Nice!
*= Patents =*
Felix is working right now on adjusting the build scripts to make a
"free-codecs only" build easy, which thus won't have any patent concerns.
(They've done it before manually for consulting customers, but it'll soon
be a simple switch on the build script.)
Once this is set up it should be very easy for me to make a local build
with the options we need, without having to maintain a fork or anything. We
can then just drop the pre-built library into our app.
*= Copyright licensing =*
libvlc/VLCKit is LGPL-licensed, and between the VLC team's interpretation
and our legal team's interpretation (thanks Luis!) and Apple's de-facto
treatment of existing VLC-based apps, we're pretty sure this should not be
a problem for our open-source app.
(The individual codec libraries are mostly BSD-ish licensed.)
-- brion
I've been digesting the new updates introduced in Android 5.0, and it looks
like there's at least one thing that we'll need to do relatively soon, if
we want to embrace the latest libraries and components.
In the new (v21) AppCompat library, it looks like they're gradually
deprecating the use of ActionBar, in favor of the more general "Toolbar".
Don't worry - the work we've done towards using a native ActionBar was not
in vain; there's a simple and straightforward migration path from ActionBar
to Toolbar. Nevertheless, it might take ~2-3 story points to transition to
the new Toolbar, which I suggest we try to squeeze in during the next
couple sprints.
Visually it won't be much different, except for a three-dot overflow icon
(instead of three squares), and a slick new slide-out animation in the top
left corner (see attached screen-grab).
device-2014-10-26-122152.mp4
<https://docs.google.com/a/wikimedia.org/file/d/0BzcksMsMNpY1dDJjOUlPWHIzNkU…>
The most (relatively) annoying thing is that the ActionBar in the v21
library no longer has a built-in ProgressBar, which we've been using
extensively, so, that'll take just a bit of restructuring.
All of this will allow us to start building the app with the new v21
library, and use the Material theme, and future-proof more of our code!
-Dmitry
Hello all together!
Today we fixed a little problem[1] with the login page, when you access it
in beta mode (not stable, nor alpha). Now the bug is in wmf/1.25wmf5 branch,
which is currently on group0 wikis (mw.org, testwiki, ) and will be
deployed next week on group1 (wikisource, wikivoyage, , Tuesday) and on
group2 (Wikipedias, Thursday) wikis and will be online one week (7 days). I
would be happy to LD the patch to wmf/1.25wmf5 [2], but Jon pointed out,
that its only a styling issue and no functionality is broken. LD or not LD,
that is the question :) Opinions?
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=72482
[2] https://gerrit.wikimedia.org/r/#/c/168616/
Freundliche Grüße / Kind regards
Florian
The iPhone 6+ is currently being treated as a mobile device.
This is because the thresholds for window.innerWidth and
window.innerHeight are 414px by 736px
Currently we invoke tablet mode only when one of those values is over 768px.
It's hard to get an idea of the sort of traffic we get from iPhone 6+
as it doesn't have its own unique user agent.
I looked on James's iPhone 6 and I can confirm that the site generally
renders well on it in tablet mode. Once strange thing I noticed
however is that if in landscape mode, clicking edit gives you the
option of VisualEditor however if you click edit in portrait mode you
get wikitext editor with no VE option. When in landscape mode and
switching to portrait mode, you stay in VisualEditor but the interface
becomes too cluttered. We'd need to make some optimisations to the
toolbar in conjunction to enabling tablet mode on an iPhone 6+
See http://imgur.com/JsOOM2K to see how it currently looks in portrait mode.
Proposed actions:
* Optimise the text 'Editing' next to the title in VE mobile mode
* Optimise the VE toolbar for display on a 320px screen - I would
suggest hiding the bold and italic buttons via media queries
* Drop threshold from 768px to 736px
I took a look at the early data from the WikiGrok prototypes. None of this
data is being posted to Wikidata yet since we want to get an idea of the
quality level before we do anything with it. The bad news is we have very
little data so far, the good news is that the response we do have are very
high quality.
We collected a total of 229 responses. About half of them were from a
short-lived bug that showed WikiGrok on all articles (for logged in Beta
users), a quarter were internal tests, and 45 were legitimate user
responses on appropriate articles. All 45 of the legitimate responses were
from WikiGrok version A (which is the version in Beta).
Of the 45 responses, 42 were definitely answered correctly. The other 3
were ambiguous, i.e. it isn't 100% clear what the correct answer is. As an
example of an ambiguous case, a user marked the following claim as true:
'Kailash Satyarthi: occupation->engineer'. The article states that Kailash
Satyarthi studied engineering in college, and may have taught engineering,
although it is unclear if he ever practiced engineering. The article is
mainly about his career as a political activist.
The most interesting thing about the responses so far is that there are
zero blatantly wrong claims. In other words, it appears that all of the
users so far have at least tried to answer the questions in good faith.
Only 9 of the 45 claims are anti-claims, i.e. 'John Doe was not a teacher'.
It isn't clear, however, if this is due to the fact that negative claims
are much harder to be certain about or due to most of the potential claims
in the suggestions database being accurate claims.
Looking at the data from the bug period (Oct. 16) is also interesting. Due
to an API bug, we temporarily surfaced WikiGrok on all articles. This
resulted in nonsensical questions like "Was Supersymmetry a politician?"
Even in the face of nonsense questions, 94% of responses were accurate.
Kaldari
Dan and colleagues,
I appreciate the table of contents flyout in the Android app.
Would it also be possible to have sections collapsed by default, as happens
on mobile web? See for example English Wikipedia's page WP:GAB for a long
page that may be easier to navigate with sections collapsed by default.
Thanks,
Pine
Hi Multimedia and mobile folks,
I have found that I like MV on mobile, particularly when browsing galleries.
I have a request. While I can zoom in on an image that is loaded in MV on
mobile, I can't pan the zoomed image. Is that a feature in the queue?
Thanks,
Pine
*This is an Encyclopedia* <https://www.wikipedia.org/>
*One gateway to the wide garden of knowledge, where lies The deep rock of
our past, in which we must delve The well of our future,The clear water we
must leave untainted for those who come after us,The fertile earth, in
which truth may grow in bright places, tended by many hands,And the broad
fall of sunshine, warming our first steps toward knowing how much we do not
know.*
*—Catherine Munro*
Hi everyone,
Our current release process does not give anyone outside the team
visibility in to when we are doing releases and what is included in
them. By virtue of our deployments system being apps, we've not got the
same integration as other teams at the WMF. It's difficult for someone like
Erik or Greg to, at a glance, know when things are being deployed in
Appsland. We should strive to integrate our process more so that the senior
management can have visibility in to it. As such, I'm proposing the
following process.
Beta releases [1] are performed as frequently (or infrequently) as required
for testing purposes. The base criteria for a feature going in to beta are
that:
- The feature has some basic functionality that delivers some value to
the user.
- The feature does not crash during basic usage.
- The feature behaves as expected during basic usage.
Production submissions [2] occur on the last Thursday of every month.
Features that are currently in the beta are evaluated to see if they should
be included in the production release. The base criteria for a feature
going in to production are that:
- The feature has functionality which provides value to the user.
- The feature is aimed to advancing us towards meeting our quarterly
goals.
- The feature has been QA tested and found to:
- not crash even under stress.
- behave as expected in typical use cases.
- not introduce regressions.
- The feature has undergone qualitative or quantitative user testing
which validated its objectives.
- The feature has clear criteria for success set which are measurable
(quantitatively *or* qualitatively), such that post-hoc analysis can be
performed about its effectiveness.
In a nutshell, the above is simply a formal documentation of our current
process, except that we've agreed a specific date to do the submissions,
and explicitly included QA (now that we have limited QA resources in The
Specialists Guild, and we are set to get more with Elena and Rummana
joining us).
I plan to officially declare this our release process within a few days,
probably on Friday.
Thoughts?
Dan
[1]: On Android, "beta" refers to the Wikipedia Beta app in Google Play,
whereas on iOS "beta" refers to our latest build in TestFlight.
[2]: As we have a review process on the iOS side due to Apple, which will
stretch releases out an unknown amount, I have specifically denoted this
phase as "submission" and not "release" so that there is congruence between
the iOS and Android teams.
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
I just pushed out a beta release (versionCode 85) 2014-10-20 with the
following changes:
* Search results ordering updated to be consistent with mobile web.
* Use real action bar for pages and navigation changes:
** Back button will revisit saved pages, history, nearby, search, ...
** Search input is collapsed by default. You had to press on the field
anyways to bring up the keyboard.
** Search/find in page use standard search component.
** Use horizontal progress bar in action bar when page is loaded.
** Highlight the nav list item that is currently shown.
** On 2.3 devices with a menu button this could result in the overflow menu
indicator to disappear; you can open it using the menu button.
* Nearby: Long press starts geo: intent (allows to open in Maps, Google
Earth) + crash fixes.
As always, it'll take some time to propagate.
Enjoy,
Bernd
For people who are using the Android app alpha apk:
Yuvi has switched to a new server at https://android-builds.wmflabs.org/.
You can download the latest alpha build from there.
Enjoy
Bernd