A repository for WikiGrok has been created, I've pushed a boilerplate for
review: https://gerrit.wikimedia.org/r/166080
Now trying to recall how to move gerrit notifications into our channel...
We can start moving all WikiGrok stuff into this extension!
--
Best regards,
Max Semenik ([[User:MaxSem]])
Forward to mobile-l, too.
Freundliche Grüße / Kind regards
Florian
-----Ursprüngliche Nachricht-----
Von: wikitech-l-bounces(a)lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] Im Auftrag von Florian Schmidt
Gesendet: Freitag, 10. Oktober 2014 22:03
An: 'Wikimedia developers'
Betreff: Re: [Wikitech-l] {{TemplatesThatWorkOnMobile}}
Hello,
> I'm also interested in some kind of easy "preview how this page will look on mobile" in the editor, which would probably be a separate thing...
I took the liberty to take this idea and created a sample change for MobileFrontend: https://gerrit.wikimedia.org/r/#/c/166089/
With this patch you would be able to click "Mobile preview" right next to the "Show preview" button. In a new tab you will see the parsed content of your edit in the mobile skin.
I like the whole idea of a mobile preview for desktop editors, so maybe, we can reach this in any way :)
Freundliche Grüße / Kind regards
Florian
-----Ursprüngliche Nachricht-----
Von: wikitech-l-bounces(a)lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] Im Auftrag von Brion Vibber
Gesendet: Mittwoch, 8. Oktober 2014 00:14
An: Wikimedia developers
Betreff: Re: [Wikitech-l] {{TemplatesThatWorkOnMobile}}
On Tue, Oct 7, 2014 at 3:02 PM, Jon Robson <jrobson(a)wikimedia.org> wrote:
> On mobile we continuously get bugs related to inline styles in
> templates. For example:
> https://bugzilla.wikimedia.org/show_bug.cgi?id=68001
>
> When these happen we usually spend time investigating, discover it is
> because of a troublesome inline style in the template and then we
> communicate this on the template talk page [1]
>
> However, rarely do these get replies and rarely does anything get fixed.
>
> Am I doing something wrong? Should I be posting these problems
> elsewhere? It seems like a lot of templates do not have active
> maintainers.
>
The wiki way is not to ask and wait for someone else to act, but to act directly in good faith and communicate what you did and why so that if there is disagreement it can be resolved afterwards.
Ultimately if we're unwilling to help edit and maintain the content and style of the wikis, we're going to be stuck working around bad styles forever.
> There has been an RFC [2] open for ages that when solved I hope will
> lead to lots of discussions between developers and template
> maintainers but right now it seems even without the tools we are
> failing.
>
> How can we get better at making our template styles more mobile friendly?
>
> [2]
> https://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_t
> emplates
>
I'd like to revitalize this one; I'll do some testing this weekend and put it on the agenda for next week's RfC.
I'm also interested in some kind of easy "preview how this page will look on mobile" in the editor, which would probably be a separate thing...
-- brion
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Switching to mobile-l
Use global less import paths. I wrote this in a fixme in my hot fix
yesterday :)
On 10 Oct 2014 12:22, "Yuvi Panda" <yuvipanda(a)wikimedia.org> wrote:
> Another option is to merge MobileApp back into MobileFrontend, but that
> might be a bad idea for code hygiene reasons (and would also mean Mobile
> Web team would be responsible for maintaining that part).
>
> On Sat, Oct 11, 2014 at 12:51 AM, Yuvi Panda <yuvipanda(a)wikimedia.org>
> wrote:
>
>> Yay to componentization!
>>
>> I'm wondering how to best depend on the styles from MobileApp in a
>> forward compatible way. Mooching off MF's module definitions comes to mind,
>> as does maintaining an array of file paths in MobileFrontend and
>> referencing them in MobileApp. Other suggestions?
>>
>> On Sat, Oct 11, 2014 at 12:20 AM, Rob Moen <rmoen(a)wikimedia.org> wrote:
>>
>>> If you depend on some of the LESS files in MobileFrontEnd (Apps) You
>>> may want to know about the recent changes.
>>>
>>> TLDR: Content specific less was split from common.less and
>>> main.less into separate files.
>>>
>>> Below are the related changes:
>>>
>>> https://gerrit.wikimedia.org/r/#/c/165850/
>>> https://gerrit.wikimedia.org/r/#/c/165851/
>>> https://gerrit.wikimedia.org/r/#/c/165852/
>>> https://gerrit.wikimedia.org/r/#/c/165853/
>>> https://gerrit.wikimedia.org/r/#/c/165854/
>>> https://gerrit.wikimedia.org/r/#/c/165855/
>>> https://gerrit.wikimedia.org/r/#/c/165856/
>>> https://gerrit.wikimedia.org/r/#/c/165857/
>>> https://gerrit.wikimedia.org/r/#/c/165858/
>>>
>>>
>>> --
>>> Rob Moen
>>> Wikimedia Foundation
>>> rmoen(a)wikimedia.org
>>>
>>
>>
>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Quote:
'''These are "simple" to implement as
they have few server-side dependencies.
- - Remote / push. These notifications hook up to services (e.g. Google
Play Services) to retrieve information and only trigger when they
information is received (i.e. pushed) to them.'''
Dan: i'm just pointing out that not every android user is using the play services, those users should get notifications as well.
On 10 באוקטובר 2014 15:00:28 GMT+03:00, mobile-l-request(a)lists.wikimedia.org wrote:
>Send Mobile-l mailing list submissions to
> mobile-l(a)lists.wikimedia.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>or, via email, send a message with subject or body 'help' to
> mobile-l-request(a)lists.wikimedia.org
>
>You can reach the person managing the list at
> mobile-l-owner(a)lists.wikimedia.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Mobile-l digest..."
>
>
>Today's Topics:
>
> 1. [Apps] Notifications: product/technical details (Dan Garry)
> 2. Re: [Apps] Notifications: product/technical details (Yuvi Panda)
> 3. Mobile article preview gadget (Brion Vibber)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Thu, 9 Oct 2014 17:31:21 -0700
>From: Dan Garry <dgarry(a)wikimedia.org>
>To: mobile-l <mobile-l(a)lists.wikimedia.org>
>Subject: [WikimediaMobile] [Apps] Notifications: product/technical
> details
>Message-ID:
> <CAOW03MHOipSEkmBOjjSq+6Wswo_ykejYDC14Bj0N9AoDybYjWw(a)mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>Hi everyone,
>
>The Mobile Apps Team met to discuss some of the technical aspects of
>notifications and how they can be served in the apps. This email
>summarises
>the technical aspects of the discussion as seen through the lens of
>product.
>
>Broadly speaking, there are two classes of notifications:
>
> - Local / pull. These are triggered on some kind of schedule or timer
>(e.g. every X minutes). They may, if they choose to, retrieve (i.e.
>pull)
> data from an API call when they are triggered, and present information
>retrieved from that API to the user. These are "simple" to implement as
> they have few server-side dependencies.
> - Remote / push. These notifications hook up to services (e.g. Google
> Play Services) to retrieve information and only trigger when they
> information is received (i.e. pushed) to them. The nature of the
> notifications means they can typically be more personalised. These are
>"hard" to implement, as there is server infrastructure required to push
>the
> information to the device.
>
>>From a UI perspective, there is absolutely no difference between a
>local
>and remote notification. This distinction is not presented to the user,
>so
>it is totally irrelevant to them.
>
>In terms of evaluating the success of notifications, it is important to
>consider that there are three interaction patterns that a user can have
>with a notification:
>
>- Engage. The user taps on the notification and is directed to wherever
> the notification wants to direct them to.
> - Dismiss. The user dismisses the notification and it's not shown to
> them any more.
>- Languish. The user sees the notification, but neither engages with it
> nor dismisses it.
>
>So, it is possible to build metrics around notifications. You can say
>"Of
>the X users we served this notification to, Y engaged with it, so we
>have a
>Y/X engagement rate". However, it's important to take these interaction
>patterns with a pinch of salt, for a variety of reasons.
>
> - Firstly, do not assume that dismissing a notification means that it
>was ineffective, as that depends on the intent of the notification; if
>the
> notification was a reminder, then dismissing it means the user was
>successfully reminded! The exact metric used to evaluate the success of
>a
> notification will have to be decided on a case by case basis.
> - Secondly, on iOS, users may heavily customise the way notifications
>are presented to them which will mould the way they interact with them.
>- Thirdly, it is difficult on a technical level to distinguish between
>a
> "dismiss" and a "languish", and in fact on iOS there is often no
> distinction between these modes anyway.
>
>That's all I have for now. Our initial discussion was very exploratory.
>More to come. :-)
>
>Thanks,
>Dan
>
>--
>Dan Garry
>Associate Product Manager, Mobile Apps
>Wikimedia Foundation
>
Hi everyone,
The Mobile Apps Team met to discuss some of the technical aspects of
notifications and how they can be served in the apps. This email summarises
the technical aspects of the discussion as seen through the lens of product.
Broadly speaking, there are two classes of notifications:
- Local / pull. These are triggered on some kind of schedule or timer
(e.g. every X minutes). They may, if they choose to, retrieve (i.e. pull)
data from an API call when they are triggered, and present information
retrieved from that API to the user. These are "simple" to implement as
they have few server-side dependencies.
- Remote / push. These notifications hook up to services (e.g. Google
Play Services) to retrieve information and only trigger when they
information is received (i.e. pushed) to them. The nature of the
notifications means they can typically be more personalised. These are
"hard" to implement, as there is server infrastructure required to push the
information to the device.
>From a UI perspective, there is absolutely no difference between a local
and remote notification. This distinction is not presented to the user, so
it is totally irrelevant to them.
In terms of evaluating the success of notifications, it is important to
consider that there are three interaction patterns that a user can have
with a notification:
- Engage. The user taps on the notification and is directed to wherever
the notification wants to direct them to.
- Dismiss. The user dismisses the notification and it's not shown to
them any more.
- Languish. The user sees the notification, but neither engages with it
nor dismisses it.
So, it is possible to build metrics around notifications. You can say "Of
the X users we served this notification to, Y engaged with it, so we have a
Y/X engagement rate". However, it's important to take these interaction
patterns with a pinch of salt, for a variety of reasons.
- Firstly, do not assume that dismissing a notification means that it
was ineffective, as that depends on the intent of the notification; if the
notification was a reminder, then dismissing it means the user was
successfully reminded! The exact metric used to evaluate the success of a
notification will have to be decided on a case by case basis.
- Secondly, on iOS, users may heavily customise the way notifications
are presented to them which will mould the way they interact with them.
- Thirdly, it is difficult on a technical level to distinguish between a
"dismiss" and a "languish", and in fact on iOS there is often no
distinction between these modes anyway.
That's all I have for now. Our initial discussion was very exploratory.
More to come. :-)
Thanks,
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
Hi everyone,
The Mobile Apps Team met today to continue our discussion about some of the
issues we face with adapting Wikipedia articles to the small screen. In
particular, the issues we’re facing in handling tables and infoboxes.
Basically, there are two major design issues with tables and infoboxes
right now:
- Infoboxes are very long, meaning that you often have to scroll for an
excessively long time to get past them and back into the prose.
- Infoboxes don’t look good on the screen because they’re too wide and
were constructed only with how they look on large screens in mind.
These issues make article display sloppy and disincline people from
continuing to use the app. For example, quite a few staff at the office
often save articles to other apps such as Instapaper rather than using the
Wikipedia app, because we’ve not handled issues such as these properly.
The latter issue is hard to grapple with as it’s a problem which is
compounded by the lack of uniformity in the way infoboxes are used, meaning
that for every fix there are thousands of edge cases that are not handled
properly. Many of our competitor apps only trivially change the formatting
of infoboxes due to the complexity of the problem, for example changing the
font and adding or removing some horizontal lines.
The former issue, however, is a bit easier to deal with. Recognising that
tables present such large issues for small screens, the commonly taken
approach by our competitor apps here is to either totally strip infoboxes
and tables from articles, or more commonly to aggressively collapse all
tables so that the user has to explicitly choose to open them. The tradeoff
here is, of course, that the very useful information contained in the
infobox is now hidden and therefore we would have a duty to expose
information to the users, but there are lightweight ways of mitigating that
which can be considered (e.g. a little tooltip).
At this stage we have no action items out of this, but we’re continuing to
explore these things in advance of our two sprints dedicated to design
issues.
If you have any questions, let me know.
Thanks,
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
Hi everyone,
As mentioned at the standup yesterday, let's get our next release
candidates for the apps in order!
On iOS, this release candidate should include:
- UI scaling for larger devices
- Fix for the web view loading half way down the screen on slow
connections
- Page load indicator
On Android, this release candidate should include:
- Page issues and disambiguation rolled up into a button under the page
title
- Onboarding for the table of contents
- Nearby, a feature that lets you see articles about things you're near
Let's aim to get these release candidates in the appropriate channels
(TestFlight for iOS, Wikipedia Beta for Android) by end of day tomorrow
(Wednesday), so that we can get them submitted for release at the start of
next week.
Thanks!
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
Doesn't appear to explode in simulator, looks the same as on iOS 8 -- ToC
animation works and all (except the bottom toolbar is still doing that odd
scaling thing). Yay!
-- brion
how is this done in epub format?
rupert
On Wed, Oct 1, 2014 at 10:44 AM, renaud gaudin <rgaudin(a)gmail.com> wrote:
> Hi,
>
> Full text search engine was not left out for performance reasons but for
> practical ones.
> Yes, we don't want people to generate the index on their phone. Except for
> tiny tiny zim files, it would be too much CPU, battery and time consuming.
> But we do want to add full text search to Android.
> It could work today but the search index is a (large) folder so it would be
> a pain to setup.
> As soon as we integrate both the ZIM file and the index in a single file,
> we'll enable full text search on the Android App.
>
> Hope that helps,
>
> renaud
>
> On Wed, Oct 1, 2014 at 5:48 AM, Federico Leva (Nemo) <nemowiki(a)gmail.com>
> wrote:
>>
>> Dmitry Brant, 01/10/2014 01:07:
>>>
>>> Looking at the Kiwix app for Android, it doesn't seem to have full-text
>>> search within articles (unless I missed it). I assume that this was left
>>> out of the Android version for performance reasons.
>>
>>
>> Don't assume, ask Emmanuel (cc Offline-l).
>> If I understand correctly, you're talking of small selections of articles
>> (hundreds or thousands). Making an index for tens of GB of text takes hours,
>> so Kiwix doesn't always make one (on desktop, you usually download the
>> pre-made index). But for few articles, the problem is easier (and one can
>> also reduce compression).
>> In general, I have no idea what it means that "zero team starts to think
>> about pre-loaded content": sounds a lot like reinventing Kiwix, which would
>> be a disastrous idea. :)
>>
>> Nemo
>>
>> _______________________________________________
>> Offline-l mailing list
>> Offline-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/offline-l
>
>
Florian found and fixed a bug with VE - the editor switcher icons
disappeared making it look like VE was no longer available
See https://bugzilla.wikimedia.org/71608 for details/background/fix
Florian has prepared a patch
https://gerrit.wikimedia.org/r/164587
Should we lightning deploy this Monday? Anyone want to own this?
Jon