(Duplicating this mail, as I wasn't subscribed to mobile-l a minute ago.)
On Sat, 16 Aug 2014, at 12:45, Nkansah Rexford wrote:
> [...]
> The Wikipedia app is currently under good development and I think its doing
> great.
We don't need apps. We need mobile websites which work as good as an app does.
Oh, the waste of effort.
I truly pledge you to work together to make a website which is so good that an 'app' is redundant.
svetlana
Shahyar, Juliusz, Trevor, Roan and I met to discuss using oojs inside
the mobile and Flow projects.
The following 3 patches kicks off moving MobileFrontend's class model
towards that of oojs - many thanks for Roan for doing most of the
legwork :-):
https://gerrit.wikimedia.org/r/155593https://gerrit.wikimedia.org/r/155589https://gerrit.wikimedia.org/r/129336
On the long term we'd look to swap out the Class.js and
eventemitter.js files in MobileFrontend for oojs, but this is going to
be tricky and require some care, possibly mixing both oojs and
MobileFrontend's class code in the repository at the same time. e.g.
increasing JavaScript on the short term, but reducing it on the
longterm. The MobileFrontend core development team will need to work
out how best to manage this transition.
Since Flow is very DOM-focused, as opposed to many smaller JavaScript
modules with element management per the currently-accepted use of
OOjs, it is unclear how we may go about integrating with OOjs fully.
However, some potential use cases have been identified as candidates
for implementing OOjs on an interim basis, primarily by abstracting
some current FlowBoardComponent workflows, such as those which handle
(re-)rendering of existing and new content fetched from the API.
Hi everyone,
On Wednesday, Katherine, Tomasz and I met with Joe Castorena from Google’s
Android Play Partnerships team. I’ve split up the most relevant information
into a few separate emails, to keep the discussion on each separate point
focussed.
Joe informed us of the process for getting featured in Google Play. The
long and short of it is that once we decide we’ve got a build that’s worth
featuring, we upload it to Google Play and contact Joe. There is a board at
Google that makes the decision about whether or not to feature an app and
that decision is multifactorial, including factors like what other apps are
featured at that time and whether it fits with the current theme of the
store (e.g. “Back to School”, etc.). We made need to make some tweaks to
get it featured (e.g. he said they might say something like “Make the app
more tablet-friendly and we can feature it”), and we’d be informed of what
those were.
We’ve got a choice with how we proceed with this:
1. We submit the current form of the production build to be featured.
2. We wait to finish some of the current threads of work (e.g. wrapping
up page issues and disambiguation), upload and hold that build unpublished,
then submit that to be featured, coordinating the release date with Joe.
I have a mild preference for option 2 as then we can coordinate the release
of the new features with the featuring, and get more bang for our buck.
That said, I am extremely proud of the app that we have out there right
now, so I would be more than happy to submit to be featured if that’s the
consensus.
Thoughts?
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
The Mobile App team had their monthly retrospective today.
Notes, actions and further discussion items are below.
https://www.mediawiki.org/wiki/Wikimedia_Apps/imported/Retrospective-August…
= Actions/Further Discussion =
*Set up quarterly "unstructured sprint" [Kristen/Dan]
*Give Vibha & Moiz iTunes account login access [Tomasz]; Waiting on Design
iTunes account [Vibha]
*Give Vibha & Moiz access to data about user actions [Dan]
*Set up monthly apps data review meeting [Dan/Vibha]
*Blog post and social media to recruit testers [Monte/Vibha/Moiz]
*Explore paid testing services [Tomasz]
Velocity Graph has been updated to reflect recent sprints:
https://docs.google.com/a/wikimedia.org/spreadsheet/ccc?key=0AlEIL4N8KjNndH…
Thanks apps team and friends!
-Kristen
The reduced quality images is now live in production. To see it for
yourself, compare original
<http://upload.wikimedia.org/wikipedia/commons/thumb/c/cb/Buildings_of_Bedfo…>
with low quality
<http://upload.wikimedia.org/wikipedia/commons/thumb/c/cb/Buildings_of_Bedfo…>
images
(253KB => 99.9KB, 60% reduction).
The quality reduction is triggered by adding "qlow-" in front of the file
name's pixel size.
Continuing our previous discussion, now we need to figure out how to best
use this feature. As covered before, there are two main approaches:
* JavaScript rewrite - dynamically change <img> tag based on
network/device/user preference conditions. Issues may include multiple
downloads of the same image (if the browser starts the download before JS
runs), parser cache fragmentation.
* Varnish-based rewrite - varnish decides which image to server under the
same URL. This approach requires Varnish to know everything needed to make
a decision.
Zero plans to go the first route, but if we make it mobile, or ever site
wide, all the better.
Here's a screenshot of an experimental nearby interface in the iOS Wikipedia app. The little green directional arrows take into account device orientation to guide you to the coordinate. Distances update in real time as well.
Hi,
A user in the Hebrew Wikipedia pointed out to me that it's uncomfortable to
her that after removing a page from the watchlist it is still displayed
there. It is gone after refreshing the watchlist, but she says that for her
it would make more sense if it disappeared immediately.
This is a design question more than a bug, so I'm asking here: what do the
designers think?
I can see pros and cons in both ways and I wonder how was the current
behavior decided: design and user testing or only the developers' intuition?
Thank you!
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
When the TOC is closed it would use the one on the left, and when open the one on the right (see attachment). (Reversed for RTL langs of course)
I think this would really help distinguish it from just being a "hamburger" type settings icon.
Since we had the luxury of having several people in the office,
Trevor, Juliusz, Rob Moen, Ed Sanders, Shahyar, May, Monte and I sat
down to talk about the problem we currently have of having no standard
way to create icons. Here is my write up of this meeting, again, if
you attended please add/correct me on anything and if you were not
please ask for clarification where needed.
Currently we have two modes of creating icons in MediaWiki
1) Using a font
2) Using SVGs with PNG fallbacks
and the markup varies depending on what extension you look at.
We discussed both approaches and advantages and disadvantages of each.
One of the major disadvantages of the WikiFont is the additional HTTP
request it creates to download the font and cannot be embedded in the
stylesheet using data uris like SVGs can (due to URL size
restrictions).
One of the major advantages of WikiFont is you can design a grayscale
icon, and style it using font colour. Shahyar was happy to move Flow
to using SVG based fonts if we could build grayscale SVGs and change
their colours using ResourceLoader. One concrete example is when you
have an icon used in a constructive anchor. The icon needs to be
green, but when hovered over a lighter green.
Another advantage brought up by May was that currently she finds it
much easier to build icons in this way, and that having to maintain
separate coloured versions of the SVGs is a pain point to her.
We decided that we should push towards using SVGs that can be built
into fonts for the purpose of the app.
As next steps
1) Monte to explore using SVGs in the Wikipedia apps. He will create
font from SVGs. He will work with May to ensure her workflow is as
easy as before.
2) Trevor is going to look into how we can automatically generate
different colour versions of SVGs and automatically create PNGs from
them.
3) I am going to aim to agree on a standard icon HTML markup for
mediawiki ui. We still have an issue with the fact that everyone is
using different HTML markup to create icons. After reviewing all our
current approaches [1] it was clear that we were relatively closely
aligned and that it simply is a case of agreeing on class names.
We aim to get all the above done by Sept 15th, 2014 so please poke us
on the mailing list if you haven't had a follow up then.
Full disorganised notes can be found here [2].
[1] https://www.mediawiki.org/wiki/Icon_standardisation
[2] http://etherpad.wikimedia.org/p/Icon_standardisation
