Hello!
25th June is fast approaching, and we are on track to make the release
with time to spare! Here's the proposed plan:
1. Release a final beta on Friday, 20th June.
2. Let people test the beta over the weekend, and up to 23rd.
3. Fix any bugs that pop up. No new feature work. Crashing bugs get priority.
4. Release on 25th!
This means that any non-critical-bug fix has to be in place by this
Friday. Is everyone ok with this plan, or does it feel like we are
cutting it too short?
Thanks! :)
--
Yuvi Panda T
http://yuvi.in/blog
Microsoft sent me a report that our Windows 8.1 tablet app is having a
crash-on-launch bug with today's featured articles; I've applied a quick
fix and am submitting it to the Windows Store for update.
This app was originally a prototype which I figured we'd rewrite if there
was continued demand, but Windows 8/8.1 tablet apps just haven't taken the
world by storm so far and we've not put work into it in a while... but it
does have a non-zero maintenance cost picking up these little bugs.
We may want to make sure we have an actual measure of its traffic usage
before making a decision, but we don't think it's very high right now...
A few possibilities:
1) Officially support the app for Windows 8.1 tablets, add support for
Windows Phone 8.1, and continue to work on updating and improving the app
alongside Android and iOS.
2) Transition it to an unofficial app "in-place", and I'll poke at phone
support, media playback, and UI experiments on my own time.
3) Pick an official end-of-life date and kill it off entirely. If and when
I or someone else want to make an unofficial version they can pick up the
source and create a new app entry for people to download.
Based on low demand and limited resources, I think we can safely throw out
1), so the choice is between 2) or 3).
-- brion
Made me feel very happy, thought I should share :)
> From the point of view of a blind Android user relying on Talkback, this
> beta represents a profound improvement. Thank you, Wikimedia, for
> getting accessibility right!
> There are two defects you could clear up before releasing this app.
> There are a couple unlabeled buttons in the U-I.
> I have found nothing else to complain of so far! And, for that reason, I
> expect to get much use out of this app.
https://ticket.wikimedia.org/otrs/index.pl?Action=AgentZoom&TicketID=7609290
:)
(We will fix the unlabeled buttons in the UI before release)
--
Yuvi Panda T
http://yuvi.in/blog
Greg Grossmeier, 14/06/2014 00:30:
> Tablets will be sent to the mobile version of the project
> websites. Previously they were sent to the desktop version. There is
> a blog post and central notice drafted and ready to go out day of.
Will someone be monitoring the effects [if any] on editing activity and
number of active editors/new [10+ edits] editors?
Nemo
Hi Mobilers,
Unfortunately the new toc.feature test is creating pages on enwiki.
I made a commit to fix it, but for some reason when I do a regular git
clone on the MobileFrontend repo I am not getting the master branch but
the 1.24wmf7 branch instead.
This commit really needs to be merged to master as soon as possible, but I
don't know how to do that at this point:
https://gerrit.wikimedia.org/r/#/c/139379/
-Chris
* every 2 weeks
by this I mean beta labs and enwiki are always 1-2 weeks apart
On 13 Jun 2014 09:59, jrobson(a)wikimedia.org wrote:
The code in production changes every 2 weeks. It doesn't really justify
regular Jenkins jobs. I could understand running them every Thursday on a
deployment but that's about it..
On 13 Jun 2014 09:37, "Chris McMahon" <cmcmahon(a)wikimedia.org> wrote:
I'd like to turn off browser tests in production, I don't think they bring
much value.
On Fri, Jun 13, 2014 at 8:12 AM, Jon Robson <jrobson(a)wikimedia.org> wrote:
> Maybe it is time to consider turning off browser tests in production or at
> least disabling the API URL variable on those servers to stop creation of
> pages?
> On 13 Jun 2014 08:10, "Chris McMahon" <cmcmahon(a)wikimedia.org> wrote:
>
>>
>> Hi Mobilers,
>>
>> Unfortunately the new toc.feature test is creating pages on enwiki.
>>
>> I made a commit to fix it, but for some reason when I do a regular git
>> clone on the MobileFrontend repo I am not getting the master branch but
>> the 1.24wmf7 branch instead.
>>
>> This commit really needs to be merged to master as soon as possible, but
>> I don't know how to do that at this point:
>> https://gerrit.wikimedia.org/r/#/c/139379/
>>
>> -Chris
>>
>> _______________________________________________
>> Mobile-l mailing list
>> Mobile-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>>
Forwarding to mobile-l
---------- Forwarded message ----------
From: Vibha Bamba <vbamba(a)wikimedia.org>
Date: Fri, Jun 13, 2014 at 6:25 AM
Subject: Page Styling Issues
To: Dan Garry <dgarry(a)wikimedia.org>, Monte Hurd <mhurd(a)wikimedia.org>,
Moiz Syed <msyed(a)wikimedia.org>, Yuvaraj Pandian <yuvipanda(a)wikimedia.org>,
Bernd Sitzmann <bsitzmann(a)wikimedia.org>, Dmitry Brant <dbrant(a)wikimedia.org
>
Monte and I have been recording Page styling Issues here -
https://etherpad.wikimedia.org/p/App_Page_Styling
Please add to this if you see broken styling.
Include Article and Sections as necessary.
Thanks
Vibha
----
Vibha Bamba
Senior Designer | WMF Design
Since our support table for browsers [1] is wildly out of date, we
should come up with something better. Oliver generated some statistics
for us from the last 30 days from logs for text/html requests (see
attachment).
I think we could divide browsers into Grade A and Grade B categories,
similarly to desktop. Grade A would be full support, Grade B would be
basic support for reading (non-JS version). Two additional suggestions:
* Don't care about anything below < 0.1%
* Drop support for JS for any problematic browser with < 0.5% (mark them
as Grade B)
I think coming up with a generic metric like "support last N versions of
X and last M versions of Y" for all browsers would be hard because the
browser landscape changes pretty fast. I'd rather reevaluate our support
table every few months. For now, I propose the following:
Grade A:
* Mobile Safari 5-7 (that includes Chrome for iOS since it uses Safari's
engine)
* Android Browser 2.3+ (drop 2.3 to grade B as soon as it's < 0.5%)
* Chrome for Android 18+
* Firefox for Android, latest version (since it's not very popular, but
still a good browser)
* IE Mobile 9+ (drop 9 to grade B as soon as it's < 0.5%)
* Blackberry Webkit 7+
Grade B:
* lower versions of browsers in Grade A
* Opera Mini 4+
* NetFront 3+
* Ovi Browser 2+
* Nokia Browser 7+
When it comes to Grade B browsers, I don't think we should test on them
very regularly, but accept bugs that come from their users.
Comments?
[1] https://www.mediawiki.org/wiki/Browser_support#Mobile_browsers
--
Juliusz
Vibha, May, Monte, Yuvi and I just met to discuss the dark theme work.
For context, when we rolled out the Android beta, by far the most requested
feature was a dark mode/night mode. The old beta had this, and people
really loved it.
For iOS, we've agreed to wait on implementing something, for two reasons.
The first is that iOS already has a system-level setting for colour
inversion which satisfies some of the user requirements. Secondly, users of
this platform may not even want this feature, so it makes more sense for us
to focus on page styling instead, which we agreed is not in as good of a
state on iOS as it is on Android.
For Android, we agreed the need is more pressing. May (who has some
thoughts on the dark theming due to her previous work on the apps) will
work with Vibha and Moiz to come up with a mockup for what kind of
colouring we want to use. Then we'll start implementing this next sprint.
This does mean that we won't have the dark theme at the time of the market
release, but it'll be in shortly thereafter, so that's okay.
Thanks everyone!
Dan
--
Dan Garry
Associate Product Manager for Platform and Mobile Apps
Wikimedia Foundation