Remix.run Logo
▲ dofm 6 hours ago

I don't really print. I do make quite a lot of archive PDFs of articles by simply printing to PDF. Sometimes a design both breaks reader mode (which often makes a better PDF) and frustrates printing from the ordinary view.

For a couple of applications I have built recently, an offline view of the data in print form has been part of the design requirement. It's still reasonably common in situations where people will meet in real life and a physical clipboard will be needed with a register or some physical signatures are needed, or in situations where paper goes home with people from meetings for them to read and sign. So, lots of school/community/disclaimer tasks where you can't presume people have devices (or a device wouldn't be usable/practical/useful, especially in outdoor contexts).

These days PDFs are also useful for marking up in some devices.

For my own work, making an app printable is a basic thing I always do — it's part of the normal process.

But that often means little more than disabling headers/footers/sidebars, rendering simple text where a logo was, putting in page break guidance at sensible points, perhaps overriding a few text colours, maybe a couple of media queries for items that need to only appear/not appear in print. Basic stuff. From there, most "print this" views are little more than a slightly simpler template.

The cool thing about is that printability often comes up late in the requirements, and it's a thing people try before they ask you about it — they try to print from the demo. So it's an easy positive surprise if the print view does more or less what the user would hope for, right from the beginning.

Making it so all of an interface is at least basically printable is actually easy if you plan for it, and it's a good way of keeping focussed on broader usability.