Per <https://bugzilla.wikimedia.org/show_bug.cgi?id=65820> we currently
only fetch a limited number of revisions on the page history view in the
iOS app, but legally we're probably supposed to show everything... need
this fixed before we submit to the app store.
Either we need to handle fetching of additional items when scrolling past
the end, or we need to add some temporary hack that links to the on-web
view in Safari.
If the latter, we can either replace the entire page history view
temporarily, or have a final entry in the table that says "see more in
browser" or something and links out when clicked.
Any preferences or opinions on complexity of adding the 'infinite scroll'
style?
-- brion
Hi.
I’m KeybladeSpyMaster, and I’m an editor at the Kingdom Hearts Wiki. I’m writing because we recently updated our home page, which raised the concern about it’s appearance on mobile devices. That created a interest/desire in a mobile app, which I’m venturing/experimenting in doing. However, I’m not very knowledgeable in coding or anything of the like; it’s something I’d like to learn, and something I hope to learn through this project. However, I don’t currently know it, and I’m having trouble creating this app. I have a couple of questions that I hope you will be able to help me with, but I think some information on my efforts is in order, so that you may understand my situation and hopefully be able to guide me in the right direction.
Efforts
I’m trying to develop the app for Windows 8.1 first, since I’m familiar with that environment and design. In fact, I’ve already designed the UI on paper. I hope to be able to expand to Android, I just can’t right now because the Eclipse software will not run on my computer right now, and I don’t understand why. I’ve got no experience or knowledge of iOS apps, so I personally do not have plans of going there right now.
Since I learned a little C# in school, I’m trying to code the app in C#/XAML
I’ve downloaded the source code for the Wikipedia app, hoping that it would help me. However, I don’t really understand HTML/JavaScript enough to know what it is that goes on in the app, and how it’s able to extract the information from the website.
Concerns
I’m hoping you could help me at least understand how to get the app to access the information from the wiki and display it on the app in a similar fashion to how the Wikipedia app does so now. Also, I know the Wikipedia app is in HTML/CSS/JavaScript. Would I have to switch to HTML/CSS/JS to code the app, or would it be okay to still try in C#/XAML? I personally am more comfortable in C#/XAML because it’s easier for me to design the UI in C#/XAML than in any of the other languages.
Thank you for you time,
KeybladeSpyMaster
Editor, The Kingdom Hearts Wiki
Sent from Windows Mail
I've been complaining lately about how our practice of running SVGs for the
mobile interface through SVGO to minimize them causes lots of problems:
* Stripping the XML declaration breaks rendering in some browsers
* Stripping all the whitespace makes them very difficult to edit by hand
(which I commonly do to tweak colors or bounding boxes)
* Removing all the IDs makes them harder to edit in graphics programs that
use the IDs to label objects and/or groups.
* Collapsing all the groups also makes them harder to edit in graphics
programs.
It turns out that a lot of SVGO's behavior is configurable from the
command-line. In order to minimize the issues listed above, I would like to
propose that we start running SVGO with the following options within
MobileFrontend:
svgo file.svg --pretty --disable=removeXMLProcInst --disable=cleanupIDs
--disable=collapseGroups
Here are some comparisons of compression size:
Simple SVG (8.8 KiB):
With options: 48.1% reduction
Without options: 55.5% reduction
Complex SVG (636 KiB):
With options: 31.1% reduction
Without options: 36.7% reduction
As you can see, adding the options above doesn't have a large effect on
compression efficiency. They do, however, allow our SVG files to retain a
lot of legitimately useful information.
Ryan Kaldari
Hi everyone,
I've started an etherpad to document relevant comments from the app store
reviews in order to manage user feedback.
https://etherpad.wikimedia.org/p/App_Store_Feature_Comments
Please paste comments directly without editorial in the relevant sections
if you would like to help out. Synthesis/ Analysis to follow.
Thanks!
Vibha
----
Vibha Bamba
Senior Designer | WMF Design
Wikipedia Android version 2.0-alpha-2014-07-02 comes with a few smaller
changes:
- Fixed some crashes related to logging and find in page
- Last updated link goes to mobile site instead of desktop site
- Add link from create account to login screen
- Change edit workflow licensing text to include a link to the Terms of Use
but bigger ones are on their way. :)
Bernd
+mobile-l
On Wed, Jul 2, 2014 at 9:31 AM, Adam Baso <abaso(a)wikimedia.org> wrote:
> I'd like to add something about the Table of Contents to the app
> description for the Wikipedia Android app. This would help to step some
> complaints, I think. Cool?
>
> -Adam
>
Hi all,
Vibha, Monte, Luis and I met to discuss the blockers for the iOS release.
As a group we identified the following things that need to happen before
the release:
1. Making the information in the footer link to the article history.
[Legal blocker, Brion working on this right now]
2. Add a Terms of Use link into the App Store description upon release.
[Legal blocker, Dan to do this]
3. Refine the More menu. i.e. product and design to decide what should
be in there, and what the prose should be [Dan and Vibha to work on this,
top priority card in for next sprint]
- Add links to privacy policy and terms of use [Legal blocker]
4. Auditing internationalisation. Try to switch to other languages.
[Dan to test]
5. ToC refinements [Monte, in current sprint]
6. Remove the "tap to hide chrome" behaviour [Monte, in current sprint]
Some of these, namely {1, 5, 6}, are being handled in the current sprint.
Some, namely {2}, are handled at release. However, {3, 4} can't be handled
in the current sprint.
Given the quarterly planning this week, and the four day week, we're
delaying the release, instead placing {3,4} as top priority issues for the
next sprint, and targeting 14th July instead.
Let me know if you have any questions.
Thanks,
Dan
--
Dan Garry
Associate Product Manager for Platform and Mobile Apps
Wikimedia Foundation
Hi everyone,
I just chatted to Vibha about how to improve how we iterate on designs.
Right now our process is that we decide what cards need designs in the
story review meeting, then we review the designs and estimate them in the
estimation meeting. This often leads to designs that need reviews going
unestimated, which leads to blocked cards sneaking into the current sprint.
To alleviate this, we're going to try having a design review meeting every
other Wednesday (i.e. the day before the estimation meeting). Vibha, I, and
the lead engineers will be present, and that'll be the time for the
engineers to give her feedback and generally reduce the number of cards
that go unestimated.
Monte, Vibha and I have chatted and we all agree it sounds like a worthy
investment of 30 minutes. We'll continually reassess whether the meeting
remains productive.
We won't do the meeting this week due to the quarterly planning. Please can
everyone review the designs on Trello for Sprint 35, as we're unblocked on
everything except two cards, which Vibha's working on now. :-)
Thanks!
Dan
--
Dan Garry
Associate Product Manager for Platform and Mobile Apps
Wikimedia Foundation
With the dust settling for our launch of the new native Android app in
the Google Play Store [1] I'd like to acknowledge the great work that
the team [2] has done and forward some of the reviews we've seen come
in. [3]
Here are some of my favorites
"Super, the bugs are out. Runs like clockwork. Class layout. Now again
everything tip top."
(Translated from German)
"I am glad that there are also pages in the app can be edited. The app
is really fantastic!"
(Translated from Dutch)
"Keeping it 100 This app is a great way to access Wikipedia and the
fact that it doesn't snoop all your information is really cool. I'll
support Wikimedia till the end."
"Perfect since the last update Native Android is always the better way
for an android app. Looks marvelous and awesome, gg :-)"
"Great! Since the latest update everything is much improved. No more
random crashes on start-up and the UI is much more pleasing to the
eye. Well done!"
"To have One of those applications that you put "default". Wikipedia
is always helpful and this app is a good summary of simplicity and
functionality"
(Translated from Italian)
"Simply brilliant From idea to implementation, a round good thing, a
walking stick for humanity on your way to unity."
(Translated from German)
And a healthy amount of critique that we're ready to take head on
"Very good I really like the current interface. What I totally
disagree is that they have placed the option of modifying entries from
Mobile. If there are already many people adulterating tickets from the
web version, the mobile version now since many people with nothing to
do will too"
And my personal nonsensical favorite
"Savage app! This app is totally SAVAGE bro! It will make your day
glow like a lemonade cooler and bring home the bacon, fry it up in a
pan! Now that's what i call SAVAGE!"
(Translating this is beyond me but I love the energy)
Thank You to Dmitry, Bernd, Yuvi, Dan, Vibha, Moiz and others for
getting us here.
We're all excited to see iOS go next.
--tomasz
[1] - http://blog.wikimedia.org/2014/06/25/revamped-wikipedia-app-now-available-o…
[2] - https://www.mediawiki.org/wiki/Wikimedia_Apps/Team
[3] - https://play.google.com/store/apps/details?id=org.wikipedia
Hi,
(see also my other mail just now on mobile non-app feedback in general)
In this case I searched bugzilla for ~5 mins and didn't see anything
relevant and so I forward here. Although, maybe I used the wrong
search keywords. (quicksearches were ":mobilefrontend summary:text",
":mobilefrontend summary:font" and ":mobilefrontend blur". and then I
realized of course this isn't MobileFrontend at all and tried again
with "ipad|ios font|text|blur")
I don't see the issue myself but I'm
not looking on an iPad. It may be valid or WORKSFORME or fixed but not
yet deployed.
At first glance this seems like Brion's kind of bug?
I just asked the user about the rendering with MobileFrontend. (I
guess they must have opted out because it's such recent feedback?
given the recent switch to redirect tablets also by default.)
-Jeremy
(obviously removed name and redacted screenshot a bit)
screenshot now uploaded instead of attached because list has a size limit:
https://i.imgur.com/oLFawll.png
---------- Forwarded message ----------
From: OTRS 2014062710022031
Date: Fri, Jun 27, 2014 23:00 UTC
Subject: Blurry text on iPad
To: "info-en(a)wikimedia.org" <info-en(a)wikimedia.org>
Just to report a bug - Since today, the text became blurry on the main
content area of the site while visiting wikipedia on a non-retina iPad
in portrait orientation (the top and sidebar remains sharp). You can
find a screenshot in attachment. This also happens while visiting
articles.
