Re: [WikimediaMobile] Reading monthly update for May 2017

2017-06-26 Thread Kaartic Sivaraam 

On Monday 26 June 2017 03:19 PM, Olga Vasileva wrote:

Relatively "soon".  We're planning on tackling this in the next three 
months.  If we consider some time for testing, etc, it should be out 
within 4-5 months from now.  Since the print to PDF functionality from 
the browser doesn't have heavy usage, we weren't planning on doing a 
quick fix in the meantime, but I like the idea of having a general 
warning or text that lets the user know why images are not appearing.


I actually thought of suggesting to promote the "print to PDF from 
browser functionality" to users in some way. Most users wouldn't be 
aware of the great work that's done in print styles. I held myself back 
because of the different path[1] taken currently.

Once again, thanks for the feedback!

You're welcome.

[1]: https://phabricator.wikimedia.org/T163472

--
Regards,
Kaartic

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Reading monthly update for May 2017

2017-06-26 Thread Olga Vasileva 
A quick not on next steps"

In case '[EPIC] Promote usage of "print->pdf" an article on mobile'[1]
> isn't planned to be deployed sometime soon how about considering some
> kind of temporary and helpful "quick fix"?
>

> It could be something like filling the blank spaces of unloaded images
> with some helpful text that act as links. The helpful text might be
> something like, "Click here to see  image", for example. The
> user could be taken to taken to the location of the image file when he
> taps the text. I'm suggesting this believing that it would be possible
> to identify the unloaded images.
>
> I guess this doesn't require much work and could be a "quick fix". This
> is not required if [1] is being planned to be deployed "soon".
>
> [1] : https://phabricator.wikimedia.org/T163472



Relatively "soon".  We're planning on tackling this in the next three
months.  If we consider some time for testing, etc, it should be out within
4-5 months from now.  Since the print to PDF functionality from the browser
doesn't have heavy usage, we weren't planning on doing a quick fix in the
meantime, but I like the idea of having a general warning or text that lets
the user know why images are not appearing.

Once again, thanks for the feedback!

- Olga
-- 
Olga Vasileva // Product Manager // Reading Web Team
https://wikimediafoundation.org/
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Reading monthly update for May 2017

2017-06-24 Thread Kaartic Sivaraam 
On Fri, 2017-06-23 at 16:32 -0700, Nirzar Pangarkar wrote:
> I agree! I'm trying to find subtle ways to indicate links but we also
> have to be cautious of best practices around accessibility.
That's right. Semantics and accessibility shouldn't be sacrificed for
the sake of design. A good design should take them into account.

> We usually avoid using color alone to indicate an intend. i.e. links.
> There have been requests to even add the underlines to desktop
> wikipedia for same reason. For now, I'm playing around with thick but
> grey underlines and increasing the line height to not clutter up the
> reading experience. Keep an eye out for desktop print styles, where I
> will be adding designs for this. 
> 
> and thank you for detailed feedback :)
> 
You're welcome. Just a little help that I could do. :)

-- 
Regards,
Kaartic Sivaraam 

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Reading monthly update for May 2017

2017-06-23 Thread Nirzar Pangarkar 
>2. Rendering links would be helpful but it seems to clutter up the
reading experience of printed articles which have a lot of links in
them (e.g. God). It would be better if some kind of alternative was
chosen to highlight links such that they don't distract the user from
their main motive (reading).

I agree! I'm trying to find subtle ways to indicate links but we also have
to be cautious of best practices around accessibility. We usually avoid
using color alone to indicate an intend. i.e. links. There have been
requests to even add the underlines to desktop wikipedia for same reason.
For now, I'm playing around with thick but grey underlines and increasing
the line height to not clutter up the reading experience. Keep an eye out
for desktop print styles , where
I will be adding designs for this.

and thank you for detailed feedback :)

On Tue, Jun 20, 2017 at 11:48 AM, Jon Robson  wrote:

>
>
> On Sun, Jun 18, 2017 at 7:08 PM Kaartic Sivaraam <
> kaarticsivaraam91...@gmail.com> wrote:
>
>> > On Mon, 12 Jun 2017 18:21:10, Jon Robson 
>> > wrote:
>> >
>> > It's deployed!
>>
>> Good to hear that! I tried to print a page using my mobile and it
>> looked great! Great work people. It would be better if the following
>> were considered,
>>
>> 1. Currently it seems that the images found in the unexpanded sections
>> aren't rendered in the PDF file. As a result a blank space is found in
>> their place and the image description seems to be describing a blank
>> space!! Possible solutions are,
>>
>> i) Trying to render all images found in a page regardless of whether
>> the sections are expanded or not
>>
>> ii) Don't print the unexpanded sections
>>
>> I would love to see (i) being chosen as a solution. :)
>>
>
> Yes sadly this is a known problem and relates to the fact we lazy load
> images. You can follow what we discussed and what our plans are going
> forward here:
> https://phabricator.wikimedia.org/T162414
>
> The short of it is:
> * There is no way to asynchronously load images when a print is detected
> * We filed a bug upstream against the HTML standard:
> https://github.com/whatwg/html/issues/2532#issuecomment-294021096
> * It looks like the only way to avoid this problem in the mean time is to
> provide a non-browser print button.
>
>
>> 2. Rendering links would be helpful but it seems to clutter up the
>> reading experience of printed articles which have a lot of links in
>> them (e.g. God). It would be better if some kind of alternative was
>> chosen to highlight links such that they don't distract the user from
>> their main motive (reading).
>>
>
> I'll defer to Nirzar on this one!
>
>>
>> > Note they will only work if you are using the print function on your
>> > phone... not if you are viewing the mobile site on desktop :)
>> >
>>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Reading monthly update for May 2017

2017-06-21 Thread Kaartic Sivaraam 
On Tue, 2017-06-20 at 18:48 +, Jon Robson wrote:
> 
> Yes sadly this is a known problem and relates to the fact we lazy
> load images. You can follow what we discussed and what our plans are
> going forward here:
> https://phabricator.wikimedia.org/T162414 
> 
> The short of it is:
> * There is no way to asynchronously load images when a print is
> detected
> * We filed a bug upstream against the HTML standard:
> https://github.com/whatwg/html/issues/2532#issuecomment-294021096
> * It looks like the only way to avoid this problem in the mean time
> is to provide a non-browser print button.
> 
In case '[EPIC] Promote usage of "print->pdf" an article on mobile'[1]
isn't planned to be deployed sometime soon how about considering some
kind of temporary and helpful "quick fix"?

It could be something like filling the blank spaces of unloaded images
with some helpful text that act as links. The helpful text might be
something like, "Click here to see  image", for example. The
user could be taken to taken to the location of the image file when he
taps the text. I'm suggesting this believing that it would be possible
to identify the unloaded images.

I guess this doesn't require much work and could be a "quick fix". This
is not required if [1] is being planned to be deployed "soon".

[1] : https://phabricator.wikimedia.org/T163472

> > 2. Rendering links would be helpful but it seems to clutter up the
> > reading experience of printed articles which have a lot of links in
> > them (e.g. God). It would be better if some kind of alternative was
> > chosen to highlight links such that they don't distract the user
> > from
> > their main motive (reading).
> 
> I'll defer to Nirzar on this one!
> > > Note they will only work if you are using the print function on
> > your
> > > phone... not if you are viewing the mobile site on desktop :)
> > >
> > 

-- 
Regards,
Kaartic Sivaraam 

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Reading monthly update for May 2017

2017-06-20 Thread Jon Robson 
On Sun, Jun 18, 2017 at 7:08 PM Kaartic Sivaraam <
kaarticsivaraam91...@gmail.com> wrote:

> > On Mon, 12 Jun 2017 18:21:10, Jon Robson 
> > wrote:
> >
> > It's deployed!
>
> Good to hear that! I tried to print a page using my mobile and it
> looked great! Great work people. It would be better if the following
> were considered,
>
> 1. Currently it seems that the images found in the unexpanded sections
> aren't rendered in the PDF file. As a result a blank space is found in
> their place and the image description seems to be describing a blank
> space!! Possible solutions are,
>
> i) Trying to render all images found in a page regardless of whether
> the sections are expanded or not
>
> ii) Don't print the unexpanded sections
>
> I would love to see (i) being chosen as a solution. :)
>

Yes sadly this is a known problem and relates to the fact we lazy load
images. You can follow what we discussed and what our plans are going
forward here:
https://phabricator.wikimedia.org/T162414

The short of it is:
* There is no way to asynchronously load images when a print is detected
* We filed a bug upstream against the HTML standard:
https://github.com/whatwg/html/issues/2532#issuecomment-294021096
* It looks like the only way to avoid this problem in the mean time is to
provide a non-browser print button.


> 2. Rendering links would be helpful but it seems to clutter up the
> reading experience of printed articles which have a lot of links in
> them (e.g. God). It would be better if some kind of alternative was
> chosen to highlight links such that they don't distract the user from
> their main motive (reading).
>

I'll defer to Nirzar on this one!

>
> > Note they will only work if you are using the print function on your
> > phone... not if you are viewing the mobile site on desktop :)
> >
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Reading monthly update for May 2017

2017-06-18 Thread Kaartic Sivaraam 
> On Mon, 12 Jun 2017 18:21:10, Jon Robson 
> wrote:
> 
> It's deployed!

Good to hear that! I tried to print a page using my mobile and it
looked great! Great work people. It would be better if the following
were considered,

1. Currently it seems that the images found in the unexpanded sections
aren't rendered in the PDF file. As a result a blank space is found in
their place and the image description seems to be describing a blank
space!! Possible solutions are,

i) Trying to render all images found in a page regardless of whether
the sections are expanded or not

ii) Don't print the unexpanded sections

I would love to see (i) being chosen as a solution. :)

2. Rendering links would be helpful but it seems to clutter up the
reading experience of printed articles which have a lot of links in
them (e.g. God). It would be better if some kind of alternative was
chosen to highlight links such that they don't distract the user from
their main motive (reading).

> Note they will only work if you are using the print function on your
> phone... not if you are viewing the mobile site on desktop :)
> 

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Reading monthly update for May 2017

2017-06-12 Thread Jon Robson 
On Mon, Jun 12, 2017 at 3:41 AM Kaartic Sivaraam 
wrote:

>
>  Original Message 
> Subject: [WikimediaMobile] Reading monthly update for May 2017
> Local Time: June 1, 2017 4:16 AM
> UTC Time: May 31, 2017 10:46 PM
> From: ckoer...@wikimedia.org
> To: wikitec...@lists.wikimedia.org, mobile-l@lists.wikimedia.org
>
> Hello,
> Welcome to the first in a reoccurring monthly update from the Reading
> department at the Wikimedia foundation. Here we'll provide a quick summary
> of things that are currently being worked on. An archive of past activity
> can be found on Mediawiki.org. Feedback and questions are welcome.
>
>
> == Web ==
>
> === New print styles for the mobile web ===
> Based on the findings of the New Readers team, we learned that users are
> increasingly getting information online, and then sharing or consuming it
> offline. In terms of mobile devices, this often means taking screenshots of
> useful information, or saving the article as a PDF to read later on their
> phones. Our older print styles did not account for reading on mobile
> devices - they focused on paper printing. We will update our print styles
> for mobile devices to account for offline consumption, making them easier
> to read and navigate, as well as accounting for missing crucial information
> such as article title and branding.[0]
>
> I would love to see this getting deployed :)
>
It's deployed!
Note they will only work if you are using the print function on your
phone... not if you are viewing the mobile site on desktop :)


>
> === Moving the lead section before the infobox on the mobile web ===
> Over the past few quarters, we've been focusing on the top of the article
> experience on the mobile website. One of the identified issues was that,
> for articles which contained an infobox, users were exposed to the infobox
> content prior to having an overview of the subject of the article itself.
> To improve on this issue, we've moved the lead section of each article so
> that it appears before the infobox on mobile, allowing readers to have
> access to the main content of the page earlier. This change is now live on
> all projects. Before, [0] After [1]
>
> === Completing related pages deployment ===
> Since March 30, 2017, we have been running a test on enwiki on the related
> pages feature. Over the past month, we collected data and analyzed the
> performance of the feature.[2] Based on the results, we completed the
> deployment of the feature on mobile English Wikipedia.
>
> These seem to be great features too. Thanks a lot for the great work!
> --
> Regards,
> Kaartic
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Reading monthly update for May 2017

2017-06-12 Thread Kaartic Sivaraam 
Sorry, the "smart" client cluttered up the formatting. Here's a better
one,

> == Web ==
> 
> === New print styles for the mobile web ===
> Based on the findings of the New Readers team, we learned that users
> are
> increasingly getting information online, and then sharing or
> consuming it
> offline. In terms of mobile devices, this often means taking
> screenshots of
> useful information, or saving the article as a PDF to read later on
> their
> phones. Our older print styles did not account for reading on mobile
> devices - they focused on paper printing. We will update our print
> styles
> for mobile devices to account for offline consumption, making them
> easier
> to read and navigate, as well as accounting for missing crucial
> information
> such as article title and branding.[0]
I would love to see this getting deployed :)

> === Moving the lead section before the infobox on the mobile web ===
> Over the past few quarters, we've been focusing on the top of the
> article experience on the mobile website. One of the identified
> issues was that, for articles which contained an infobox, users were
> exposed to the infobox content prior to having an overview of the
> subject of the article itself. To improve on this issue, we've moved
> the lead section of each article so that it appears before the
> infobox on mobile, allowing readers to have access to the main
> content of the page earlier. This change is now live on all projects.
> Before, [0] After [1]
> 
> === Completing related pages deployment ===
> Since March 30, 2017, we have been running a test on enwiki on the
> related pages feature. Over the past month, we collected data and
> analyzed the performance of the feature.[2] Based on the results, we
> completed the deployment of the feature on mobile English Wikipedia.
These seem to be great features too. Thanks a lot for the great work!

--

Regards,
Kaartic

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Reading monthly update for May 2017

2017-06-12 Thread Kaartic Sivaraam 
 Original Message 
Subject: [WikimediaMobile] Reading monthly update for May 2017
Local Time: June 1, 2017 4:16 AM
UTC Time: May 31, 2017 10:46 PM
From: ckoer...@wikimedia.org
To: wikitec...@lists.wikimedia.org, mobile-l@lists.wikimedia.org

Hello,

Welcome to the first in a reoccurring monthly update from the Reading 
department at the Wikimedia foundation. Here we'll provide a quick summary of 
things that are currently being worked on. An archive of past activity can be 
found on Mediawiki.org. Feedback and questions are welcome.

== Web ==

=== New print styles for the mobile web ===
Based on the findings of the New Readers team, we learned that users are 
increasingly getting information online, and then sharing or consuming it 
offline. In terms of mobile devices, this often means taking screenshots of 
useful information, or saving the article as a PDF to read later on their 
phones. Our older print styles did not account for reading on mobile devices - 
they focused on paper printing. We will update our print styles for mobile 
devices to account for offline consumption, making them easier to read and 
navigate, as well as accounting for missing crucial information such as article 
title and branding.[0]
I would love to see this getting deployed :)

=== Moving the lead section before the infobox on the mobile web ===
Over the past few quarters, we've been focusing on the top of the article 
experience on the mobile website. One of the identified issues was that, for 
articles which contained an infobox, users were exposed to the infobox content 
prior to having an overview of the subject of the article itself. To improve on 
this issue, we've moved the lead section of each article so that it appears 
before the infobox on mobile, allowing readers to have access to the main 
content of the page earlier. This change is now live on all projects. Before, 
[0] After [1]

=== Completing related pages deployment ===
Since March 30, 2017, we have been running a test on enwiki on the related 
pages feature. Over the past month, we collected data and analyzed the 
performance of the feature.[2] Based on the results, we completed the 
deployment of the feature on mobile English Wikipedia.
These seem to be great features too. Thanks a lot for the great work!

--

Regards,
Kaartic___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Reading monthly update for May 2017

2017-05-31 Thread Chris Koerner 
Hello,
Welcome to the first in a reoccurring monthly update from the Reading
department at the Wikimedia foundation. Here we'll provide a quick summary
of things that are currently being worked on. An archive of past activity
can be found on Mediawiki.org. Feedback and questions are welcome.


== Web ==

=== New print styles for the mobile web ===
Based on the findings of the New Readers team, we learned that users are
increasingly getting information online, and then sharing or consuming it
offline. In terms of mobile devices, this often means taking screenshots of
useful information, or saving the article as a PDF to read later on their
phones. Our older print styles did not account for reading on mobile
devices - they focused on paper printing. We will update our print styles
for mobile devices to account for offline consumption, making them easier
to read and navigate, as well as accounting for missing crucial information
such as article title and branding.[0]

=== Moving the lead section before the infobox on the mobile web ===
Over the past few quarters, we've been focusing on the top of the article
experience on the mobile website. One of the identified issues was that,
for articles which contained an infobox, users were exposed to the infobox
content prior to having an overview of the subject of the article itself.
To improve on this issue, we've moved the lead section of each article so
that it appears before the infobox on mobile, allowing readers to have
access to the main content of the page earlier. This change is now live on
all projects. Before, [0] After [1]

=== Completing related pages deployment ===
Since March 30, 2017, we have been running a test on enwiki on the related
pages feature. Over the past month, we collected data and analyzed the
performance of the feature.[2] Based on the results, we completed the
deployment of the feature on mobile English Wikipedia.

== New Readers ==

* The New Readers team is deep in beginning pilots to address the barriers
that were identified as highest priority through deep research in 2016.[3]
You can see deeper, cross-team updates at m:New Readers/Updates. [4]
* For Reading, we're supporting the Android and Web teams in developing
deeper support for readers who have internet sometimes, but want access to
some content when they're offline or don't want to spend the data to read.
To see a summary of that work, check out m:New Readers/Offline.[5]

== Multimedia ==
* In addition to bugfixes and maintenance, the team has been evaluating the
pre-release version of 3D model file support and collecting feedback via
the Commons Village Pump.[6] During the forthcoming month the team will be
prioritizing and working on 3D tasks in anticipation of a future launch.[7]

== Other Noteworthy Stuff ==
* Following April's Q3 quarterly check-in, we examined core readership
metrics for the same timespan in a followup presentation.[8] [9]


[0]
https://www.mediawiki.org/wiki/Reading/Web/Projects/Print_Styles#Mobile_Printing
[1]
https://www.mediawiki.org/wiki/File:Mobile_website,_older_version_of_infobox_and_first_paragraph.png
[2]
https://www.mediawiki.org/wiki/File:Lead_paragraph_before_infobox_example_-_Ada_Lovelace_article.png
[3]
https://www.mediawiki.org/wiki/Reading/Web/Projects/Related_pages#Metrics_analysis
[4] https://meta.wikimedia.org/wiki/New_Readers/Findings
[5] https://meta.wikimedia.org/wiki/New_Readers/Updates
[6] https://meta.wikimedia.org/wiki/New_Readers/Offline
[7]
https://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2017/05#Preparing_for_3D_models_on_Commons
[8] https://phabricator.wikimedia.org/tag/3d/
[9]
https://www.mediawiki.org/wiki/File:Reading,_Comm_Tech_%26_TPG_Quarterly_Check-in,_Apr_2017.pdf
[10]
https://commons.wikimedia.org/wiki/File:Wikimedia_Foundation_Reading_metrics_Q3_2016-17_(Jan-Mar_2017).pdf

---

The archive of all past updates can be found on MediaWiki.org:

https://www.mediawiki.org/wiki/Reading/Status_updates


Yours,
Chris Koerner
Community Liaison - Discovery
Wikimedia Foundation
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l