1427861 - Modify ctrl+p shortcut to open print preview instead of print dialog box

Status: UNCONFIRMED

(Toolkit :: Printing, enhancement, P3)

Description

[Matheus Longaray (:mlongaray)]

As per Mike's request, I'm filing this bug to share some printing metrics I collected last month and to maybe start a discussion whether makes sense to modify Ctrl+P shortcut behaviour: open print preview instead of print dialog box.

Ever since we added telemetry patches to capture printing-related data, I’m maintaining dashboards containing all of that data separated by each release. I used the Telemetry Dashboard Generator and implemented a few modifications to customize/aggregate data. Attached are 3 PDFs containing data I’ve pulled from telemetry on December 8th, 2017 (sorry the delay, holiday close put both Mike and I behind on emails).

A few interesting points when we look to this data (average from 55 up to 57):
* 7.82% of people are trying simplify when available in print preview
* 30.64% of pages opened in print preview are addressable by Simplify
* Version 55 had 23.29% of people printing with simplify vs simplify page opened. Version 56 and 57 (on December 8th - still counting) bumped to 50.51% and 51.87% (!!!), respectively.
* Print intent to print action numbers are quite high. For Ctrl+P (no print preview) we’re getting 90.23%. For print preview, we’re getting 97.88% instead. Thus, there’s a difference of 7.65% of people more likely to print when in print preview.

Ctrl+P does not bring print preview directly today, and it looks like print action is higher when in print preview mode. What if we start thinking of Ctrl+P opening print preview instead of the print dialog box. That could potentially increase print activity, as well as expose more people to Simplify.

Mike recommended me to comment on bug 1401754 given Gijs seemed concerned that this change would break people's muscle memory a bit. I’ve filed this one separately so we can add people that might be interested discussing this topic. I’m taking the liberty to cc’ some folks from bug 1401754 as well.

Comment 1

[Matheus Longaray (:mlongaray)]

Attachment: Telemetry Printing Synthesis - Win V55 (December 8th, 2017)

Comment 2

[Matheus Longaray (:mlongaray)]

Attachment: Telemetry Printing Synthesis - Win V56 (December 8th, 2017)

Comment 3

[Matheus Longaray (:mlongaray)]

Attachment: Telemetry Printing Synthesis - Win V57 (December 8th, 2017)

Comment 4

[:Gijs (away/busy until Mar 10)]

I think in the other bug I was mostly concerned with scope-creep for 57 at the time. We'd messed with the print and print preview items in like 3 successive bugs, and I wanted to get to a relatively uncontroversial state as quickly as possible, as clearly the print (preview) item in the new hamburger menu wasn't some kind of central part of the 57 quantum release, so we shouldn't be spending a lot of time iterating on it.

That is to say, I have no particular objection to switching the shortcut to open print preview on linux/windows instead of the print dialog. I guess it's a tiny bit inconsistent with mac (which doesn't have print preview, for reasons that I've never really understood...), but that doesn't seem a good enough reason not to do it.

A slightly more serious objection, perhaps, would be that right now you can quickly print by using ctrl-p followed by [enter]. If we make ctrl-p open print preview, it'll break that workflow, and instead you'd have to go ctrl-p, [wait for print preview], alt-p, [enter], which is slightly more cumbersome and less discoverable for users who don't know about access keys.

On the whole I am a bad person to make this call because I almost never print at all. If I print, I usually print to pdf. Though to be fair, I do that even if I do want a paper copy, because I trust printing a pdf to give me the exact result I see, and I don't trust printing a webpage from the browser to do the "right thing". So in that sense, I guess defaulting to print preview really ought to help me -- but I'm also pretty sure I'm not the average user of printing in browsers.

If you work in an office and regularly print the same page (but with different data, say) from the same webapp, I could see being forced into print preview as being annoying because it's adding needless steps to your workflow. Then again, I'm not sure that's the workflow we should be optimizing for.

Really, we should get some UX opinions here, IMO. Maybe Philipp can help.

Related but somewhat orthogonal: I also think there are bugs in print preview (cf. comments in bug 1328072) that we need to work on if we're giving it wider exposure.

Comment 5

[Matheus Longaray (:mlongaray)]

Attachment: Telemetry Printing Synthesis - Win V55 (January 4th, 2018)

Comment 6

[Matheus Longaray (:mlongaray)]

Attachment: Telemetry Printing Synthesis - Win V56 (January 4th, 2018)

Comment 7

[Matheus Longaray (:mlongaray)]

Attachment: Telemetry Printing Synthesis - Win V57 (January 4th, 2018)

Comment 8

[Matheus Longaray (:mlongaray)]

Updated numbers (average from 55 up to 57):

1) 7.87% of people are trying simplify when available in print preview

2) 30.58% of pages opened in print preview are addressable by Simplify

3) Version 55 has 23.30% of people printing with simplify vs simplify page opened. Version 56 and 57 bumped to 50.53% and 52.92% (!!!), respectively.

4) Print intent to print action numbers are quite high. For Ctrl+P (no print preview) we’re getting 90.28%. For print preview, we’re getting 97.88% instead. Thus, there’s a difference of 7.6% of people more likely to print after entering print preview.

5) The number of printouts is higher with the Ctrl+P flow.

6) Looking at _5_ and _6_, could it be the case that people are bailing out from Ctrl+P as they are not going through print preview (hamburger panel's print item), so they rather see the content prior to printing it?

Comment 9

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

I think this makes sense. We are not using any of the OS capabilities to preview the print result, so the user has no way of knowing what the resulting printout will look like. So this seems to be a net positive.

Then I'd also suggest to file a follow-up bug to straighten up the UI of our print preview and make it available on all platforms.

Comment 10

[Matheus Longaray (:mlongaray)]

Got backlogged and did not spare time to keep this topic warm, sorry for that.

Well, one thing to notice is that the attached and above data is related to Windows only. See below what I found pulling data for Linux.

1- For Linux, printing is not being used as often as on Windows. From v55 to v57, print count average hits only 21,736 prints for Linux, when compared to 1,458,432 prints on Windows.

2- Print intent to print action numbers are interesting. For Ctrl+P (no print preview) we’re getting 75.91%. For print preview, we’re getting 96.74% instead. Thus, there’s a difference of 20.83% of people more likely to print after entering print preview. This difference is a bit higher when compared to Windows - see comment #8.

3- In average, from v55 to v57, percentage of people using Ctrl+P (no print preview) vs Menu print (hamburger panel's print item) on Linux hits 50.93% - a bit higher than Windows: 46.02%.


Following are the link to the dashboards I've been maintaining. It's a really rudimentary table but it does the job.
- Release 57 on Windows: https://codepen.io/printx-firefox/full/mqaZJo/
- Release 56 on Windows: https://codepen.io/printx-firefox/full/XzgjZa/
- Release 55 on Windows: https://codepen.io/printx-firefox/full/eRLLpq

 
Mike, any thoughts here? Maybe focus on Windows and later validate and analyse collected printing data (we'd have to renew the printing metrics lifetime)?

Comment 11

[jscher2000]

Ctrl+p => preview is something that users migrating from other browsers have mentioned missing. WebExtensions cannot remap built-in keyboard shortcuts, which would have been a handy workaround, and there doesn't seem to be any timeline for allowing that, so please don't wait for that.

However, longtime Firefox users might not want a change, which suggests to me to make it user configurable. I realize that is extra work, especially if the shortcut in the menu would depend on a preference, but it provides the opportunity to change the default behavior only for new profiles (similar to how URL bar search suggestions appear above general suggestions in new profiles, and below in old profiles, overridable using browser.urlbar.matchBuckets).

Comment 12

[eamon]

I wonder if anyone really prefers the existing behavior; it sounds like they're not losing anything by completely ditching the preview-less print function. In terms of muscle-memory, Ctrl-P opens a dialog with the print button focused; chrome opens the print (with preview) dialog with confirming print button focused, so if the hypothetical new behavior in firefox were the same, that would leave both the coming-from-chrome folks and the long-time firefox users with muscle-memory happy too: Ctrl-P, Enter prints.

Another (perhaps trivial) wrinkle is window.print(), which too should probably better use the chrome-style print-with-preview dialog.

(I'm a webdev and would prefer to be able to give a simple explanation to users as to how best to print certain screens without needing too many browser-specific exceptions or differences.)

Comment 13

[Evelyn Henry]

Was researching this as it came up in enterprise forums and it followed the same train of thought, "other browsers do it so why isn't it in an option in firefox?" I'm sure it's not high priority, but having the option would be especially useful for say, policies, where they don't want the users potentially wasting paper (the user in this case is a library IT admin)