Page MenuHomePhabricator

Download icon is confusing in file namespace
Closed, DuplicatePublic

Description

Sample of usage of the print button per namespace [1]. Number in file namespace (6) seems high in the mobile skin:

-1	7
0	14050
1	19
2	46
3	9
4	138
6	943

I imagine that people are thinking this download icon will give them a copy of the image rather than a PDF.

Should we rethink the icon/function in this context? Especially given it looks a lot like the icon we use in multimedia viewer.

Screen Shot 2017-11-17 at 4.07.19 PM.png (474×411 px, 81 KB)

Screen Shot 2017-11-17 at 4.08.00 PM.png (693×1 px, 1 MB)

[1] select event_namespaceId, count(*) from log.Print_17199246 where userAgent LIKE "%Chrome%" AND userAgent NOT LIKE "%iOS%" AND timestamp > "201711140000" and event_skin = 'minerva' group by event_namespaceId

ON PDFs this is even more confusing - https://commons.wikimedia.org/wiki/File:%E0%A6%85%E0%A6%B8%E0%A6%AE%E0%A7%80%E0%A6%AF%E0%A6%BC%E0%A6%BE_%E0%A6%B2'%E0%A7%B0%E0%A6%BE%E0%A7%B0_%E0%A6%AC%E0%A7%8D%E0%A6%AF%E0%A6%BE%E0%A6%95%E0%A7%B0%E0%A6%A3.pdf - clicking the download button provides a PDF version of the printed version of the HTML page, not the PDF itself that the user is viewing.

The desktop site also shows a download icon similar to ours which acts differently:

Screen Shot 2017-11-20 at 8.40.35 AM.png (217×474 px, 30 KB)

Event Timeline

@Nirzar - thoughts? I think the icon makes sense in all contexts, but I can see why it could get confusing

I agree with the task description.

Possible ways to solve this

  1. trigger actual download from the download button instead of print

i.e. link to the original file. we already have this url under the file

  1. remove the download action from file: namespace

#2 is obviously the easier (maybe a 1 pointer) but I'd say #1 is the correct thing to do, but a little harder (i'd estimate 2-5 points depending on how much upfront investigation we do with regards to how to obtain the download URL)

I would totally advocate for #2 if it's a 3 pointer

it will improve filepage experience on mobilefrontend

we should have done it long time ago! :P but I will defer that to the PM @ovasileva

Completely confusing indeed.

A "download" action is not expected to provide a pdf. It's not that clear what "downloading a html page" should do (eg. what if the user was at a page like this?), but for a file the expectation is clearly different.

I think the tooltip should be changed to "Download as pdf", and the icon clarified (which is a nice problem, though).

Totally agree about the usability issues described. But I'm not quite sure I understand the additional data argument - what exactly is meant by "Number in file namespace (6) seems high"? That users are more likely to tap the button on file pages than on others? Such a conclusion would need a comparison with the pageview numbers in general.

I agree with the task description.

Possible ways to solve this

  1. trigger actual download from the download button instead of print

i.e. link to the original file. we already have this url under the file

I'm not sure I understand this completely. What do you mean by link to the original file?

ovasileva triaged this task as Medium priority.Nov 21 2017, 11:09 AM

I'm not sure I understand this completely. What do you mean by link to the original file?

each file: namespace has a source url to the actual file

image.png (940×1 px, 1 MB)

we can link our download button to the original file

https://phabricator.wikimedia.org/T177215 < the task description and even the epic task description mentions the button should only show on article namespace. did we miss the checklist when we were working on deploying this button?

@Nirzar - yup. I'll open a separate bug. Currently, it's not showing on special pages, but it is showing on other namespaces.

I marked it as a duplicate for now. The feature request to have a download action on file namespace can be a new ticket.