On Mon, 12 Jun 2017 18:21:10, Jon Robson jrobson@wikimedia.org 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 :)
On Sun, Jun 18, 2017 at 7:08 PM Kaartic Sivaraam < kaarticsivaraam91196@gmail.com> wrote:
On Mon, 12 Jun 2017 18:21:10, Jon Robson jrobson@wikimedia.org 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,
- 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 sectionsI 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.
- 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 :)
On Tue, 2017-06-20 at 18:48 +0000, 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 <unloaded> 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
- 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 :)
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 <unloaded> 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".
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
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
- 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 https://phabricator.wikimedia.org/T135022, 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 jrobson@wikimedia.org wrote:
On Sun, Jun 18, 2017 at 7:08 PM Kaartic Sivaraam < kaarticsivaraam91196@gmail.com> wrote:
On Mon, 12 Jun 2017 18:21:10, Jon Robson jrobson@wikimedia.org 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,
- 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 sectionsI 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.
- 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 :)
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. :)