Hello together!
On an IRC talk i saw a link to our coding convention [1] with the hint, that
we use tabs for indentings, so far so good. Now i was wondering, why our
en.json language file (the only one) uses whitespaces, instead of tabs, and
if there was a special reason for this? If not, can we change these to tabs?
Background: My favourite editor doesnt show any difference between tabs and
whitespaces (sure, more a setting or a problem of the editor), so i had
sometimes the problem, that i forget, that there are whitespaces, instead of
tabs, which ends in a new patchset for a change :) All our files, including
our language files (excluding en.json) uses tabs instead of whitespaces. Now
i suggest to be consistent in en.json, too (if there is no special reason
for it dont do it) :) Opinions?
[1] https://www.mediawiki.org/wiki/Mobile_web/Coding_conventions
Freundliche Grüße / Kind regards
Florian
You should be able to swipe quickly to expose the 'delete' button for individual items, however this isn't super obvious. We might add a more traditional iOS 'edit' mode to that list? Not sure what's best here. I can, if I swipe on the text and not the "invincible box". (under/above the text, but still within the "image"-sized field...)
Make it possible to drag the "W" and "lines" and not just the sides.I'm not sure what you mean here? Can you describe in more detail?When swiping on the right of the screen it brings up the TOC, but if I swipe from the button, top-right, nothing happenes. I have to click it. And nothing happenes at all if I swipe at the left side. Then I think that should bring up the "Wikipedia"-menu.
If you need any more feedback about iPad mini, please ping me. Either here, or on IRC, I go under the nick Josve05a or Josve.
Date: Tue, 23 Sep 2014 12:04:57 -0700
Subject: Re: [WikimediaMobile] Feedback of iOS WIkipedia 4.0.3 by Josve05a
From: bvibber(a)wikimedia.org
To: gladjonatan(a)outlook.com
CC: mobile-l(a)lists.wikimedia.org
On Tue, Sep 23, 2014 at 11:55 AM, Jonatan Svensson Glad <gladjonatan(a)outlook.com> wrote:
I'm using an Apple iPad mini (1st gen), on iOS 8.0 (12A365).
Thanks for the testing -- we still need to do more work on iPad!
When logging in, the button should say "log in", and not "done".We'll consider this; would be clearer action yeah.
There is a lot of "blank"/whitespace at the bottom of every page.Yeah, a lot of our dialog screens are built for iPhone and don't scale up to iPad cleanly. They should generally be retooled to run as popups or something which will clean up their space usage, but we need to put more work into it. This might happen later in the year?
Pressing "W" should make the "Black" a little transparent, and not compleatly black.Pressing the "share"-button makes the app crash.Looks like this is an iPad-specific bug, I've added it to our bug tracker: https://bugzilla.wikimedia.org/show_bug.cgi?id=71189
There is nothing in the about privacy policy or disclamers (like in the bottom of the website).
It's in the '...' submenu from the W menu, but it's kinda hidden yeah.
Make it possible to drag the "W" and "lines" and not just the sides.I'm not sure what you mean here? Can you describe in more detail?
When searching: if only a few results show, the rest of the space with no results, should not be white, but transparent.
Yeah, that might be a good way to handle on iPad...
I'm unable to delete specific pages from the "Saved pages"-page.You should be able to swipe quickly to expose the 'delete' button for individual items, however this isn't super obvious. We might add a more traditional iOS 'edit' mode to that list? Not sure what's best here.
-- brion
We ran into some code signing issues getting a beta update out yesterday
and ended up recreating all the certs/profiles for the Wikipedia iOS beta
distribution channel.
It looks like this has the side effect of preventing the old version from
installing or running anymore. Awesome!
I've just send out an update ping for the version we tried yesterday with
the new cert, which runs ok for me.
This version *should* work where the previous one did not. As an additional
plus, it'll sit side-by-side with the store version! So you can delete the
old beta and reinstall the store version if you want to have them both
installed at once.
We plan to change the beta version's icon to help users distinguish them in
future.
Sorry for the inconvenience...
-- brion
Just published a new beta[1] version to the store. Should be available in
an hour or two.
Changes:
* Introducing a new feature to list nearby pages (within 10 km of current
location). This is why we now request a new Android permission to be able
to retrieve the current location (from network or GPS).
* An issue was fixed that caused saved pages to not load when offline. The
issue was introduced in the previous beta release. So, if you've saved
pages with that version it's recommended to update those saved pages. To do
that go to saved pages screen and select the ones you want to update
(long-press) and hit the refresh button. Or you could just update all
by hitting
the refresh button while not having any pages selected.
* Table of Contents drawer opens automatically on pages with more than 1
section until the user knows how to use it or presses the Got it button.
* Better error messages for account creation
* Changed "Other meanings" to "Similar articles"
* Made app available on devices that don't have a true touchscreen but only
"faketouch" (e.g. mouse and keyboard).
Enjoy!
Bernd
[1] https://play.google.com/store/apps/details?id=org.wikipedia.beta
Several of the engineers and advisors developing components for front
end standardization met Friday to check status, set direction, and
identify upcoming obstacles
Big take aways:
= MediaWiki theme for OOjs UI =
* Should be finalized this week by Trevor and Bartosz
* Server side to follow in the next couple of weeks
= Icon system =
* Bartosz has done the early work for a Grunt task that takes SVGs
and a JSON config to generate colored SVG and PNG renderings and the
corresponding LESS markup for them
Notes and additional items from the discussion can be found on mw.org [1]
Follow up items:
* Generate prospective roadmap [Trevor]
* Raise Template RFC w/ arch committee and make a decision [Brion]
* Find out if Derk-Jan (cc'd) can join us next time
* Discuss Server-side OOUI at next meeting
Please update as necessary if you attended and I've forgotten or
misrepresented anything.
thanks all
--tomasz
[1] - https://www.mediawiki.org/wiki/FrontEndStandardsGroup/Weekly-Sept_19_2014
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,
*tl;dr: Sprint 41 (29th September - 12th October) for Mobile Apps will be
unstructured time for engineers to work on whatever they like.*
Sprint 41 is coming up. During that sprint, the Mobile Team is having its
quarterly planning sessions. These planning sessions involve all remote
staff travelling to the WMF office, and participating for two full days in
those sessions. Staff also take this time to meet other staff in the office
and network. Realistically, much less structured work gets done during this
time than in normal sprints.
Both the iOS and Android apps engineering teams have decided to take sprint
41 to be unstructured time. No cards or stories will be scheduled for this
sprint. Engineers will be free to work on whatever they want. It's a great
opportunity to fix bugs, dabble in projects other than apps, or work on
features, such as the Nearby feature which came out of recent unstructured
time.
Additionally, sprint 41 also so happens to fall in the time period where
the SUL finalisation feature development should be wrapping up. Given my
commitments to that product as its product owner, it would be good for me
to be able to take a little bit of time away from the apps and pour over
those features in detail. So I will likely be using the unstructured time
for that, as well as starting implementation of the evil master plans we
generate in our quarterly planning. :-)
Thanks,
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
In the last 2 days we went from 110 signups to 336!
Of these, 143 people have actually installed the latest beta, up from a
previous high of 20.
I've also received multiple feedback emails through the testflight system.
Dan, I've added you as a "leader" in testflight so hopefully these feedback
emails will go to you as well. Is this ok?
Other thoughts on where to forward feedback email? In the mean time, here's
the feedback from yesterday:
-----
I went to Article History and tried to click on an article Editor's name to
see articles they have also edited, and this functionality is not yet there.
I have no understandable way to Mark an article for watching (for web WP
usage) - will this be implemented?
I also do not see articles i am already watching from The web WP
Are These "saved for offline use" articles somehow saved to web WP?
I think the top-right article summary button could show The amount of
languages The article is available in and allow to choose when "26 other
languages" is tapped, f.ex.
Editing a segment of an article could allow for a toolbar above The editor,
having The usual set of functionality or a subset of them (link with text,
bold, list, reference generation)
Tapping on this:
↑ a b Yle, uutiset viitat
(Am referring to a and b) should modify Back-button functionality so that
can get back to references by tapping on Back.
Also, i am seeing hugely garbled text pasted now, see attached screenshot
I.e. Would be nice to get a non-formatted copy-to-clipboard out of WP
Share button on lower-right could have AirPrint? Hmm.
I will attach two crashlogs that occurred while searching for a WP article
in the next Mail.
Sent from some iDevice. Written by Esa.
----
Great update,
Can i translate the app into arabic language ?
Feras Younis Qrinawi
----
Hey I have the TestFlight iOS 8 app how could I transfer the Wikipedia App
inside the TestFlight App?
----
Just from using this to view 2 articles, Infobox placement is a bit
problematic. On an iPod 5, the page "Carboxynorspermidine decarboxylase" is
split up by the Infobox; half the equation seems to be on either side of it.
(Note: ^ this last one is from the previous beta)
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