960940 - PDF tabs should have favicons

Status: VERIFIED FIXED

(Firefox :: PDF Viewer, defect, P5)

Description

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

We need favicons on PDF.js tabs that indicate that file type.

Comment 1

[Brendan Dahl [:bdahl]]

The favicon for the site is shown. We've had a few other issues opened about this and it is generally preferred that the site favicon is shown instead.

https://github.com/mozilla/pdf.js/pull/2329

Comment 2

[Yury Delendik (:yury)]

It will be nice some research/motivation attached to this bug before we blindly replace site favicon with some icon that will represent PDF document (e.g. I personally see no value in having picture of the PDF). Or that icon with be "in addition to the favicon"?

Comment 3

[u279076]

I think the testing required here should be pretty minor and can be covered via automated tests. Please let me know if test coverage is not going to be checked in with the fix.

Comment 4

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to Yury Delendik (:yury) from comment #2)
> It will be nice some research/motivation attached to this bug before we
> blindly replace site favicon with some icon that will represent PDF document
> (e.g. I personally see no value in having picture of the PDF). Or that icon
> with be "in addition to the favicon"?

Most sites (at least in my experience) don't show a favicon on PDF documents at all. That makes it hard to identify the tab with »that PDF I opened«. If the site supplies a favicon I'm all for using that, but we should show a generic PDF icon for the many sites that don't.

Comment 5

[Dão Gottwald [:dao]]

There's no precedent for us setting a default favicon based on the file type. Why should users care about file types and why would they more likely look for "that PDF file" than e.g. "that OGV/GIF/SVG/HTML/plaintext file"?

Comment 6

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Well, HTML files often times have favicons and they represent the majority of tabs users have opened. So it is safe to assume that showing »this background tab contains an HTML file« doesn't add a lot of information.

With other types, the fact that they are out of the norm makes them easier to remember (»I don't know which tab this was in, but it was in a PDF file«). Currently we do nothing to assist users here.

I agree that we should expand that policy to other file types, but PDF seems to be the most widespread one, so it makes sense to start here. Images are already represented with a miniature of their content by the way.

Comment 7

[Yury Delendik (:yury)]

> Images are already represented with a miniature of their content by the way.

So shall we make favicon as a miniature of the first or current page of the viewed pdf?

Comment 8

[Dão Gottwald [:dao]]

(In reply to Philipp Sackl [:phlsa] from comment #6)
> With other types, the fact that they are out of the norm makes them easier
> to remember (»I don't know which tab this was in, but it was in a PDF
> file«). Currently we do nothing to assist users here.
> 
> I agree that we should expand that policy to other file types, but PDF seems
> to be the most widespread one, so it makes sense to start here. Images are
> already represented with a miniature of their content by the way.

You seem to assume that users generally understand file types or that we should educate them about file types. Currently, when opening a PDF document, nowhere in the UI do we tell users that they're looking at a PDF document, except for the URL in the URL bar (if the file name ends with .pdf, which it doesn't have to) but it's a known fact that many users ignore the URL bar as UI noise. What matters to users is the kind of content (text, image, video etc.). The binary format or markup language is an implementation detail.

Comment 9

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to Dão Gottwald [:dao] from comment #8)
> You seem to assume that users generally understand file types or that we
> should educate them about file types.

I assume that a significant group of users can identify a PDF when it opens in their browser (if only because many links to PDFs clearly state what you are getting – either in the text or through an icon).
Even for those who don't the icon can be a visual anchor which is much better than having no icon at all.

> Currently, when opening a PDF
> document, nowhere in the UI do we tell users that they're looking at a PDF
> document, except for the URL in the URL bar (if the file name ends with
> .pdf, which it doesn't have to) but it's a known fact that many users ignore
> the URL bar as UI noise. What matters to users is the kind of content (text,
> image, video etc.). The binary format or markup language is an
> implementation detail.

In addition to what I wrote above, the PDF viewer has some quite unique UI mechanics (pagination, the additional toolbar, probably the side bar).

(In reply to Yury Delendik (:yury) from comment #7)
> > Images are already represented with a miniature of their content by the way.
> 
> So shall we make favicon as a miniature of the first or current page of the
> viewed pdf?

I generally agree that the closer we get to represent the actual content, the better. Though since many PDFs are just text, my concern is that they would just degrade to a grey square when scaled down to 16x16px image.

Comment 10

[Yury Delendik (:yury)]

> > > Images are already represented with a miniature of their content by the way.
> > 
> > So shall we make favicon as a miniature of the first or current page of the
> > viewed pdf?
> 
> I generally agree that the closer we get to represent the actual content,
> the better. Though since many PDFs are just text, my concern is that they
> would just degrade to a grey square when scaled down to 16x16px image.

Majority of PDFs have authentic first page (some will have color, some unique title text layout). It might not be a trivial task to not-"degrade to a grey square", but shall be doable. Are we trying to fit this bug into "p=1" or we going to do what's right?


Just out of curiosity, what PDF icon you have in mind. Because I not sure you can use something Adobe used for years to promote the product (e.g. http://acroeng.adobe.com/wp/wp-content/uploads/2014/01/pdf_icon_gen.png). Or you are trying to re-educate people to recognize a different icon?

Comment 11

[Yury Delendik (:yury)]

See also https://bugzilla.mozilla.org/show_bug.cgi?id=668954#c8

Comment 12

[Jennifer Morrow [:Boriss] (UX)]

Attachment: Mockup in intended behavior: favicon where possible, whole PDF preview if smaller than max_size, section if larger

Thanks for the good discussion here.  I’ll try to summarize.

Philipp correctly points out that we don’t indicate PDFs on tabs aside from, when available, showing the domain’s favicon.  The benefits of doing this are:

1. Indicates to users domain the PDF is in, as with all pages within the domain, thus distinguishing its source even when multiple PDFs are open
2. Treats PDFs consistently with other pages within a domain

So what are the drawbacks to showing domain favicon?  Arguably, that users don’t know that the site is a PDF until they open the tab.  But, do users benefit from knowing this?  A PDF is a file format which some users will be familiar with and others not.  The domain is branding that the user is, arguably, more likely to recognize.  Overriding what is recognizable branding with a format indication seems to serve little purpose - particularly as its unlikely to change behavior.  After all, a paginated PDF is quite similar to a paginated HTML file in terms of how it’s read and used.  Yes, there’s different UI on a PDF than on other pages, but the same could be said of any page on the web.

Thus, if a favicon is available, it seems best to show it for a PDF and not change current behavior.

But what if a favicon isn’t available?

Showing no image ont he tab is guaranteed to not be useful.  Currently, for images larger than pref browser.chrome.image_icons.max_size (hereafter MS), we show no image on the tab.  For images smaller than MS, we show a preview of the image.  We should do exactly the same for PDFs which, rare as they may be, are smaller than MS: show a preview on the tab.

What should we do for images, including PDFs, over MS and with no available favicon?

I propose that we cut a MS-sized rectangle out of the top left corner of PDFs larger than MS (and all images, for that matter, in a different bug) and show that as a preview on the tab.  

Why would we do this, rather than show an icon that says PDF?

1a. The content of the item is more likely to be useful to users than the file format, as it gives information about what the document contains, not just how it’s encoded
2a. The content of the item can help users distinguish between multiple PDFs, while a PDF icon cannot
3a. This is consistent with how we treat other images smaller than MS, which are given a preview rather than, for instance, an icon that says PNG (and this was done for reasons 1 and 2, iirc)

Why top cut from the top left?  For any language that’s read top left to bottom right, this is arguably the most likely section to contain some identifying words, colors, or images.  It’s entirely possibly that over time we may decide to cut this differently based on research, but as long as we’re currently displaying nothing at all this will undoubtedly be an improvement.

Why not do this for all PDFs, even if there’s a favicon available?  Because for large PDFs, the image is less likely to be as identifiable as the favicon designed for the purpose of being distinguishable.  These is a worst-case scenario for a large file, not best behavior.  We show preview for small images even when there’s a favicon because a small image takes the place of a favicon for being small enough to be graphically identifiable.  After all, if we thought there was great value in 16x16 previews, we’d do it for any page on the web and throw out these blasted favicons altogether.

tl;dr Action Items:
1b. If a favicon is available for a PDF, always show the favicon
2b. If a favicon is not available and the PDF is smaller than pref browser.chrome.image_icons.max_size, show a preview of the PDF just as with other images
3b. If a favicon is not available and the PDF is larger than pref browser.chrome.image_icons.max_size, cut a section from the top left of the image the size of pref browser.chrome.image_icons.max_size and display that as a preview in tab (for LTR languages, cut a section from the top right, etc)

Comment 13

[Jennifer Morrow [:Boriss] (UX)]

UX Acceptance criteria for this bug has been filled.  Two followup engineering bugs have been filed for implementation: bug 988687 and bug 988686