*tl;dr: The programming language used to develop new features by our iOS
app engineering team is changing from Objective C to Swift at some point in
the near future.*
When making a native app, the language you have to implement the app in is
chosen by the third party responsible for the platform. For iOS apps, Apple
chose Objective C to be the language the app is written in. Objective C is
a... very strange language. It has a lot of quirks that slow down
development.
To solve the above problem, you can now write apps in a new language called
Swift. Notably, Swift has features that make it less error prone and more
concise than Objective C, which should increase our velocity of feature
development. Swift is also much more readable and in-line with other
languages, which lowers the barrier of entry (which is currently very high
with Objective C).
Importantly, Objective C and Swift can live alongside each other. So, when
we "switch to Swift" we do not need to rewrite all of our existing code
from Objective C to Swift. Instead, we can just start developing new
features using Swift, and slowly rewrite the old code from Objective C into
Swift as time allows.
On the downsides, Swift is only supported on iOS 7 and above. iOS 6 only
represents around 5% of our user base, and we can pin iOS 6 users to the
last version of the app we released before we used Swift. We need to decide
what the last set of features we're want in that build are before we switch.
Here are our next steps:
- Evaluate more concretely whether Swift actually fits our needs or not.
[Engineering]
- Decide last set of features for our iOS 6 build. [Product/Design]
Thanks,
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
+1 for this idea. I still have an Android 2.3 device, but the Wikipedia app (and others too) is very slow and becomes more and more unusable, while it's agreat user experience on my Android 4.4 device.
If dropping 2.3 support means a faster development of the main Wikipedia app and the <2.3 users still have access to Wikipedia through a lite app (which will be faster and more usable) i would say: do it, it has advantages for both sides :)
Florian
Gesendet mit meinem HTC
----- Reply message -----
Von: "Dan Garry" <dgarry(a)wikimedia.org>
An: "mobile-l" <mobile-l(a)lists.wikimedia.org>, "Carolynne Schloeder" <cschloeder(a)wikimedia.org>, "Toby Negrin" <tnegrin(a)wikimedia.org>, "Lila Tretikov" <lila(a)wikimedia.org>
Betreff: [WikimediaMobile] [Apps] Wikipedia Lite app?
Datum: Sa., Jan. 31, 2015 06:45
Hi everyone,
Those of you who were at the Mobile quarterly review heard me mention Facebook Lite, an app that's designed especially for the developing world.
Notably, their app has a lot of optimisations which make it good for users in developing world:
It's only 252kB, good for limited data plans.It supports down to Android 2.2, good for older devices.It's data-efficient, good for 2G connections and for people on limited data plans.
From a development perspective, some advantages are:
You no longer have to support older versions of Android in your main app.
You can tailor the performance of the lite app to the older devices so it's faster.You can tailor the features of the lite app to the developing market.So obviously there are a lot of advantages for our users if we do this. And, selfishly, I can't stress enough how much dropping Android 2.3 from our current app would speed up development. As an example, almost all of the edge cases with lead images occurred on 2.3 devices, and they required quite a lot of investigation and hacking to fix them up. Obviously we've not dropped 2.3 so far because it's a very strategically important part of our user base, which I'm sure Carolynne can attest to!
I'd say that we should put some serious thought into whether we'd prefer to have a Wikipedia Lite app for the developing world, rather than our current "one app to rule them all".
Comments? Questions?
Dan
--
Dan GarryAssociate Product Manager, Mobile Apps
Wikimedia Foundation
One of the frustrations I have heard so far is that the audience there
is too small to get meaningful data around various experiments.
Currently people have to opt in by going to
https://en.m.wikipedia.org/wiki/Special:MobileOptions which is hidden
away in the mobile interface. They can do this whilst anonymous or
logged in.
Have we thought about automatically opting people into beta mode e.g.
a sample of our users in a certain geographic region / certain zero
enabled area/ all users in a certain bucket based on their user id ?
How many users could beta actually handle?
Is this technically possible?
If someone was bucketed into beta would they be able to opt out into
stable again under any of the above situations?
Jon
Ed Sanders, Trevor and I had an in real life conversation, last
Friday, where we spoke about the VisualEditor tablet (and future
mobile) offering. We've had a bunch of issues with it so far breaking
and a lot of this is due to two conflicting technologies.
We're keen to bring VE code and mobile code closer together with the
ultimate goal to get a good VisualEditor mobile experience going.
Since Damon has asked us all to get VisualEditor released this
quarter, between us we think mobile VE will become a high priority
soon.
We'd thus like to spend this quarter making the VisualEditorOverlay
[1] more OOJS UI like.
Ideally all the existing code should live in VisualEditor and be based
on OOJS UI. In the future we could also imagine the wikitext editor in
mobile becoming part of the VisualEditor tool itself.
At a bare minimum this could be rewritten as an OOJS UI dialog [2] and
would require us looking at the mobile overlay manager and seeing if
it can be consolidated with VisualEditor's seemingly similar window
manager [3] which I do not believe has any support for storing state
via the hash fragment [citation needed, please correct me]
As a result of this work, the mobile frontend code and VisualEditor's
front end code should naturally become more aligned.
Ed, Trevor anything you would like to add to the above? Any
corrections to my interpretation of this chat?
[1] https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/maste…
[2] https://doc.wikimedia.org/oojs-ui/master/#!/api/OO.ui.Dialog
[3] https://doc.wikimedia.org/oojs-ui/master/#!/api/OO.ui.WindowManager
i'm a novice of wikimedia_android app, and i got problems when i tried to build and run the project in andorid studio 1.0.1.
i need some help ,see this http://stackoverflow.com/questions/28248801/build-problems-with-mediawikis-… .
besides ,this is my first time send email to mobile-l ,is there something i need to pay attention to .
thanks a lot .
cxyshine(a)yeah.net
Minutes and slides from four recent quarterly reviews are now available:
Team Practices Group:
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter…
Engineering Commmunity Team:
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter…
Release Engineering and QA (Quality Assurance) team:
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter…
Mobile Partnerships (Wikipedia Zero) team:
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter…
On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller <erik(a)wikimedia.org> wrote:
> Hi folks,
>
> to increase accountability and create more opportunities for course
> corrections and resourcing adjustments as necessary, Sue's asked me
> and Howie Fung to set up a quarterly project evaluation process,
> starting with our highest priority initiatives. These are, according
> to Sue's narrowing focus recommendations which were approved by the
> Board [1]:
>
> - Visual Editor
> - Mobile (mobile contributions + Wikipedia Zero)
> - Editor Engagement (also known as the E2 and E3 teams)
> - Funds Dissemination Committe and expanded grant-making capacity
>
> I'm proposing the following initial schedule:
>
> January:
> - Editor Engagement Experiments
>
> February:
> - Visual Editor
> - Mobile (Contribs + Zero)
>
> March:
> - Editor Engagement Features (Echo, Flow projects)
> - Funds Dissemination Committee
>
> We’ll try doing this on the same day or adjacent to the monthly
> metrics meetings [2], since the team(s) will give a presentation on
> their recent progress, which will help set some context that would
> otherwise need to be covered in the quarterly review itself. This will
> also create open opportunities for feedback and questions.
>
> My goal is to do this in a manner where even though the quarterly
> review meetings themselves are internal, the outcomes are captured as
> meeting minutes and shared publicly, which is why I'm starting this
> discussion on a public list as well. I've created a wiki page here
> which we can use to discuss the concept further:
>
> https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r…
>
> The internal review will, at minimum, include:
>
> Sue Gardner
> myself
> Howie Fung
> Team members and relevant director(s)
> Designated minute-taker
>
> So for example, for Visual Editor, the review team would be the Visual
> Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker.
>
> I imagine the structure of the review roughly as follows, with a
> duration of about 2 1/2 hours divided into 25-30 minute blocks:
>
> - Brief team intro and recap of team's activities through the quarter,
> compared with goals
> - Drill into goals and targets: Did we achieve what we said we would?
> - Review of challenges, blockers and successes
> - Discussion of proposed changes (e.g. resourcing, targets) and other
> action items
> - Buffer time, debriefing
>
> Once again, the primary purpose of these reviews is to create improved
> structures for internal accountability, escalation points in cases
> where serious changes are necessary, and transparency to the world.
>
> In addition to these priority initiatives, my recommendation would be
> to conduct quarterly reviews for any activity that requires more than
> a set amount of resources (people/dollars). These additional reviews
> may however be conducted in a more lightweight manner and internally
> to the departments. We’re slowly getting into that habit in
> engineering.
>
> As we pilot this process, the format of the high priority reviews can
> help inform and support reviews across the organization.
>
> Feedback and questions are appreciated.
>
> All best,
> Erik
>
> [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus
> [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
>
> _______________________________________________
> Wikimedia-l mailing list
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
--
Tilman Bayer
Senior Analyst
Wikimedia Foundation
IRC (Freenode): HaeB
Hi everyone,
Those of you who were at the Mobile quarterly review heard me mention
Facebook Lite, an app that's designed especially for the developing world.
Notably, their app has a lot of optimisations which make it good for users
in developing world:
- It's only 252kB, good for limited data plans.
- It supports down to Android 2.2, good for older devices.
- It's data-efficient, good for 2G connections and for people on limited
data plans.
>From a development perspective, some advantages are:
- You no longer have to support older versions of Android in your main
app.
- You can tailor the performance of the lite app to the older devices so
it's faster.
- You can tailor the features of the lite app to the developing market.
So obviously there are a lot of advantages for our users if we do this.
And, selfishly, I can't stress enough how much dropping Android 2.3 from
our current app would speed up development. As an example, almost all of
the edge cases with lead images occurred on 2.3 devices, and they required
quite a lot of investigation and hacking to fix them up. Obviously we've
not dropped 2.3 so far because it's a very strategically important part of
our user base, which I'm sure Carolynne can attest to!
I'd say that we should put some serious thought into whether we'd prefer to
have a Wikipedia Lite app for the developing world, rather than our current
"one app to rule them all".
Comments? Questions?
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
I've proposed that Florian gets +2 on the MobileFrontend repository.
Florian has been an extremely active MobileFrontend developer (he is
our 5th most active contributor).
It would be great to have him helping out with merging patches. He
also is based in Europe so it would strengthen our ability to get
regressions fixed on different timezones quicker!
You can support this by voting using the {{support}} template on:
https://www.mediawiki.org/wiki/Gerrit/Project_ownership#.2B2_for_Florian_Sc…
Please show your {{support}} on the wiki page to make this happen!
(In the words of Spiderman with great power comes great reponsibility)