*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
I propose we remove the Wikimedia Commons app from the store.
Clearly there is no time available to work on it, there is no one maintaining it or following up on the problems that have been reported since 2013.
Yann is just brining it up on wikimedia-l and I think that it is bad to have an app out there that no on is taking care of. So we should pull it and whoever wants to continue with it can release it under a name of this own.
DJ
Hi everyone,
In light of the Phabricator migration, a few people in the Mobile Web and
Mobile Apps teams met to discuss how we're going to handle this.
In a meeting with Quim a few weeks ago, Mobile Web and Mobile Apps decided
that the long term plan was to switch to Phabricator, but for now we're
going to stick with Trello because Phabricator is missing a few bits of
functionality that we really like. We communicated these so the team
upstream is aware.
For now, people will be filing issues with our products in Phabricator. So
how do we get those into Trello? We may make Phabello, a tool to
automatically import things using the Trello and Phabricator APIs, but
that's not on the cards right at this moment.
Here were our outcomes of how we're going to interact with Phabricator:
- All engineering team members should make sure they're receiving
information about bug escalations. Do this by clicking "Watch project" on
the relevant projects on Phabricator:
- Joaquin, Kaldari, Baha, Rob, Jon, Max, Sam, Maryana: MobileFrontend
- Adam, Monte, Brion, Dan: iOS app
<https://phabricator.wikimedia.org/tag/wikipedia-app-ios-app/>
- Dmitry, Bernd, Dan: Android app
<https://phabricator.wikimedia.org/project/view/489/>
- Kristen will volunteer to serve as Phabello for now. Say hi to KPhab!
The process will be:
- Look at all new bugs entered since last standu
- Enter those as cards in Trello:
- Create card with same title as bug in Phabricator
- Add link to Phabricator in the card description
- Add link to Trello in the Phabricator bug, saying that the issue
is tracked in Trello
- Mark bug as "Normal" priority
All hail KPhab!
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
Hi, just wanted to give people a heads up about language-sensitive
redirects on the m.wikipedia.org/ (and zero.wikipedia.org/) webroot:
https://www.mediawiki.org/wiki/Wikipedia_Zero/Accept-Language_Aware_Redirec…
Dan Foy, Maryana, and I spoke on this stuff, and we thought it would be
best to see how this works in Wikipedia Zero land, and then if it works
well, continue dialog for the mobile web Wikipedia webroot afterward for
the non-Wikipedia Zero use case.
Usually we don't like to vary the cache on Accept-Language, but this is one
place where we're exploring the concept. It's possible to try to figure out
the language prefix in Varnish, but for now we're trying this as a pure
MediaWiki thing.
-Adam
CC'ing mobile-l to let them know of this
Exciting to see projects like this showing up. I do notice that it's
not compatible with Nexus5, Nexus7, and a number of other standard
devices.
Looking at your manifest it should just work. Did you put in a Google
Play restriction on which devices it works on?
--tomasz
On Mon, Nov 24, 2014 at 2:25 AM, Adrien Maglo <adrien(a)visualink.io> wrote:
> Hello,
>
>
> I am not sure this is the right mailing list to introduce this project but I
> have just released Displee. It is a small Android app that allows to search
> for images in the English Wikipedia by taking pictures:
> https://play.google.com/store/apps/details?id=org.visualink.displee
> It is a kind of open source Google Goggles for images from en.wikipedia.org.
>
> I have developed Displee as a demonstrator of Pastec http://pastec.io, my
> open source image recognition index and search engine for mobile apps.
> The index hosted on my server in France currently contains about 440 000
> images. They may not be the most relevant ones but this is a start. ;-)
> I have also other ideas to improve this tiny app if it has an interest for
> the community.
>
> Displee source code (MIT) is available here:
> https://github.com/Visu4link/displee
> Pastec source code (LGPL) is available here:
> https://github.com/Visu4link/pastec
> The source code of the Displee back-end is not released yet. It is basically
> a python3 Django application.
>
> I will be glad to receive your feedback and answer any question!
>
> Best regards,
>
>
> --
> Adrien Maglo
> Pastec developer
> http://www.pastec.io
> +33 6 27 94 34 41
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Greg, James, Kristen, Rummana, Elena and myself met today to discuss our
next steps for the QA resources assigned to Editing and Mobile Apps.
We decided that both Elena and Rummana will split their time roughly 50%
between Editing and Apps. As we agreed that QA should be integrated into
the teams, Elena and Rummana will attend the standups and meetings of both
teams. This will help ensure that both QA testers are aware of ongoing
feature development and can allocate themselves accordingly.
That said, we acknowledged that with any assignment of our very limited QA
resources, there would be need to be some inherent flexibility. Perhaps the
Editing Team needs more QA than normal one week due to a big release, and
perhaps the Mobile Apps Team needs more in a different week. That
flexibility is agreed going in, and we can evaluate that on a week-by-week
basis.
Although both testers will test for both Editing and Apps, there will be
primary points of contact for QA in both teams to ensure continuity of
communications:
- Elena will be the primary point of contact in QA for Mobile Apps
- Rummana will be the primary point of contact in QA for Editing
Mobile Apps will continue to engage with The Specialists Guild for broad
regression testing and testing of compatibility with different versions of
the iOS and Android OS.
The success of this arrangement will be reevaluated in early February, or
sooner if deemed necessary.
Thanks,
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
I spoke to some Taiwanese students learning English (with help from a
translator) about Wikipedia, Wikimedia and mobile. Age range was 17-35
so quite a mix. I was hoping I'd find some developers in the room but
sadly no so I focused the talk around using the mobile site.
Interestingly everyone here used Wikipedia, but when I asked them if
they used the mobile site of Wikipedia they all said no. When I probed
more I discovered "Google" was where they got their information. I
managed to confirm that they were going to Wikipedia but most of them
didn't realise.
Some things I notice:
* They actually were disappointed they couldn't upload images anymore.
Most wanted to edit but didn't know how. Post wikigrok it would be
interesting to see if we can use the saving mechanism there to queue
up uploads to the site.
* When I showed them Listen To Wikipedia they got really excited and
registered straight away just to see their name. Interesting tactic we
might want to explore for signups :)
* They struggled with the captcha when registering (surprise
surprise). It's English words not Chinese words. I notice everyone has
WiFi passwords here that are numbers. It would be interesting to
explore captchas that involve numbers if that is at all possible.
* In the language overlay in 3 out of 3 cases where people have used
it they all seemed to scroll down, no one realises they can search for
the language at the top. That's a UX problem I guess we need to fix.
* When they have flicked from Chinese to English Wikipedia and then
use the search bar at the top of the page to search for information
they type in chinese and expect search terms to show up there.
* They didn't seem to recognise the hamburger as a menu icon
* They asked to edit and surprise surprise I saw lots of templates in
every example I tried. The keys to the templates are English e.g. in
infoboxes. I think this makes a strong argument for being able to edit
infoboxes from wikidata (I've got an example below).
Today is my last day working remotely from China but I'm happy on my
travels to do anymore Chinese research if you find this interesting
and want to know more about potential Wikipedians here :)
Example infobox:
{{Taxobox
| color = pink
| name = 斑尾鹃鸠
| status = LC
| status_system = iucn3.1
| image = MacropygiaUnchall.jpg
| regnum = [[动物界]] Animalia
| phylum = [[脊索动物门]] Chordata
| classis = [[鸟纲]] Aves
| ordo = [[鸽形目]] Columbiformes
| familia = [[鸠鸽科]] Columbidae
| genus = [[鹃鸠属]] ''Macropygia''
| species = '''斑尾鹃鸠 ''M. unchall'''''
| binomial = ''Macropygia unchall''
| binomial_authority = (Wagler)<ref name='id2051'>{{cite web | url =
http://www.bioinfo.cn/db05/BjdwSpecies.php?action=view&id=2051 | title
= 斑尾鹃鸠 | work = 《中国动物物种编目数据库》 | publisher = 中国科学院微生物研究所 | author =
中国科学院动物研究所 | accessdate = 2009-04-04 }}</ref>
}}
I notice I accidentally only sent this to Joaquin.
DJ
---------- Forwarded message ----------
From: Derk-Jan Hartman <d.j.hartman(a)gmail.com>
Date: Fri, Nov 21, 2014 at 4:07 PM
Subject: Re: [WikimediaMobile] [Web] Spike: Explore using CSSLint/LessLint
in mobile
To: Joaquin Oltra Hernandez <jhernandez(a)wikimedia.org>
Ehm, I tried working with CSSLint several times and in my opinion it simply
doesn't (yet) work at our scale. We have WAY too many overrides. It also
horribly fails on anything that is not known to it yet (new browser
specific properties or values) and it doesn't have 'comment' overrides to
ignore warnings or errors (at least last time I checked).
If you are starting from scratch it is great (I even contributed a few
patches to it), but I found it horrible to work with (unlike JSHint) in
real world practice where exceptions are simply the norm to make stuff work
cross platform. If you want to use it, plan on spending quite a bit of time
tweaking upstream.
DJ
On Fri, Nov 21, 2014 at 9:45 AM, Joaquin Oltra Hernandez <
jhernandez(a)wikimedia.org> wrote:
> CSS is a beast and any help is going to be useful.
>
> As Jon said, we probably need a longer spike/task to see if any other
> teams are doing CSS linting and there are already conventions we can use,
> and to determine what validation rules we want to use.
> El 21/11/2014 2:53, "Jon Robson" <jrobson(a)wikimedia.org> escribió:
>
> Which rules would MobileFrontend be able to use from the start?
>> Which rules might be controversial to adopt?
>>
>>
>> On Fri, Nov 21, 2014 at 9:00 AM, Bahodir Mansurov
>> <bmansurov(a)wikimedia.org> wrote:
>> > After reading benefits of CSSLint there is no doubt in my mind that we
>> > should use it. Here [1] are some of the benefits. They range from
>> possible
>> > errors to compatibility to performance, etc. With grunt we can use
>> > grunt-lesslint [2], which employs CSSLint under the hood so we can also
>> > tweak it using CSSLint rules.
>> >
>> > What do you guys think?
>> >
>> > [1] https://github.com/CSSLint/csslint/wiki/Rules.
>> > [2] https://github.com/jgable/grunt-lesslint
>> >
>> > _______________________________________________
>> > Mobile-l mailing list
>> > Mobile-l(a)lists.wikimedia.org
>> > https://lists.wikimedia.org/mailman/listinfo/mobile-l
>> >
>>
>> _______________________________________________
>> Mobile-l mailing list
>> Mobile-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>