Hide RECAP content when printing from PACER

[mlissner]

One of our users is unhappy that RECAP is "tattling" on him when he prints from PACER:

That's fair enough. We should be able to fairly easily apply a print CSS file or a similar approach to prevent this.

[arcataroger]

Hey @mlissner, could you please link to an example URL where this is happening?

Is it something like this example: https://ecf.nysb.uscourts.gov/cgi-bin/DktRpt.pl?912650776082285-L_1_0-1

Where there's a "RECAP Actions" button?

[mlissner]

Yeah, exactly. Everything that RECAP injects into the page should be hidden when printed.

[arcataroger]

OK, I think this PR should do it? freelawproject/recap-chrome#355

[johnhawkinson]

It is not apparent to me that it is prudent to suppress the [R] icons on documents (class recap-link) in the docket sheet by default.

I recognize that some people may want that sometimes, or even always…on those rare occasions when I print a docket sheet from CM/ECF, though, I appreciate knowing what documents are available in RECAP.

(Do we also feel like it is "tattling" if a Clerk's Office prints a docket sheet from CM/ECF and it has little scales icons to indicate pending motions that have not been ruled on? Err, or maybe they mean items that have been ruled on, I forget.)

[johnhawkinson]

(I guess, also, as a matter of principle, I am uncomfortable with CSS that hides semantic elements when printing. Hiding borders and changing margins is one thing, but this is not that.)

[arcataroger]

@johnhawkinson Thanks for the feedback! Ok, let's discuss this a bit more:

• Are there some USERS who prefer to print RECAP elements, and others who prefer to hide them?
• Or is it more the case that across most users, there are certain ELEMENTS that should be hidden while others should be shown?
• Or some combination of both?

What about an option that the user can set for themselves?

Alternatively, if you feel safe about always hiding some things and always showing some other things, just give me a list of what to hide and that would work too?

[arcataroger]

Also, just for background: I am not a lawyer or anything remotely close to it, and I don't know how most of you use these sites :) I just answered a call for volunteers that Mike put out on Hackernews.

So, 1000% please feel free to correct me and suggest changes that make sense to you!

[johnhawkinson]

• Are there some USERS who prefer to print RECAP elements, and others who prefer to hide them?

Yeah, I think that's my position. But, you know, no userbase is a monolith and we don't have a lot of user research.

• Or is it more the case that across most users, there are certain ELEMENTS that should be hidden while others should be shown?

Setting aside (or perhaps modifying) my above comment about semantic elements, nobody really needs to see form submission buttons or actions/controls in printouts, because clicking your pen on the piece of paper doesn't do anything.
So that speaks to, e.g., "Create alert," in Mike's lead screenshot.

But reasonable people may differ on indicators that convey information, like the [R] icons on docket entries.

I will say, at one time, I used to be self-conscious about sharing screenshots of docket pages with [R] icons on them, and I ultimately got over it. But there would have been a time when, had there been a control to hide [R] icons on a docket sheet, I would have used it. (On the gripping hand, I certainly knew I could write a browser bookmarklet in a few seconds that would hide them, and I never did.)

• Or some combination of both?

What about an option that the user can set for themselves?

I mean, adding knobs are the obvious thing to do when people disagree on how functionality should work.
And they come with the downside of adding complexity, so the question becomes whether the added complexity of interface (and implementation) is "worth it."

Alternatively, if you feel safe about always hiding some things and always showing some other things, just give me a list of what to hide and that would work too?

It is not the case that anyone has carefully thought this through, I do not think.

[arcataroger]

If we don't have enough user data yet, maybe we can start with a simple opt-in choice to hide RECAP stuff on printouts? (i.e. just a binary show/hide toggle without the intermediate option of only hiding SOME elements)

• The default would remain the same (everything prints)
• Users like adamthelawyer (who reported this issue) can hide everything if they want
• It's simple to implement and doesn't introduce too much complexity
• We can refine it later if needed

No need to make such a simple feature super complicated upfront then, if people aren't asking for that sort of nuance yet? We could start with a barebones implementation and see if anyone wants something more configurable later?

[arcataroger]

Or actually, thinking it through a little more, I agree that certain elements (like buttons) could just be hidden by default for all users. No reason to print those out.

Then, we could still have an extra option (hide/show all PACER elements) for those who don't even want the "semantic" icons either.

[AdamTheLawyer]

Agreed with arcataroger.

Pure interface elements like buttons shouldn't print--there's no upside.

Indicators that convey information as well as offer a place to click should be hidable but not necessarily hidden. Which to make the default is a matter of philosophy, I suppose. Whether it's more valuable to go "under the radar" or to keep the icons and normalize RECAP will differ by user.

I mostly would want them hidden because I sometimes have to submit printouts of things like docket sheets into evidence. If opposing counsel notices them and decides to make a Thing of it, the very best case is that I spend 5 minutes talking about something that isn't my case--worst case the judge thinks it's something nefarious and it stands in the way of me admitting my evidence.

Having to explain why my client's case was damaged because I supported RECAP is just a bad place to be, for RECAP and its users.

I wrote a quick userscript to hide anything with "RECAP" in its class on print... it just injects this line of CSS on all the PACER/CMECF pages:

@media print { [class*="recap"] { display:none; visibility: hidden; }}

Seems to work fine.

AK

[mlissner]

Sorry not to reply sooner, but I'm going to don my benevolent dictator hat and say that the original plan here is the one to pursue.

I have talked to a lot of users at this point, and there are tradeoffs in the groups:

1. Journalists are willing to broadcast that they use RECAP.

2. Lawyers hide the fact that they use RECAP or are at least quite cautious about it (for now)

3. Other people don't have strong opinions for the most part.

Based on this broad sketch, I feel comfortable saying that all RECAP stuff should be hidden by default and that we shouldn't have user-visible settings for this. If there's an easy way to document this and put it in about:config, say, I'm +1 for that as well, but printing is a rarely used feature, and we don't want to add a setting for it from now until eternity.

(I'm also concerned that we're bikeshedding a bit. This should be a non-controversial issue because practically nobody prints things anyway. If we get blow back, it's very easy to reverse.)

Thanks for all the input. I do appreciate it.

[arcataroger]

OK, then freelawproject/recap-chrome#355 should do the job? We can always change it up later.

[AdamTheLawyer]

That's not unreasonable; I have no doubt that any change can have unexpected downstream effects. As an alternative--this is something users (or at least sufficiently nerdy users) could do themselves. The userscript I posted earlier seems to work pretty well--it basically suppresses all elements with a class name that contains "recap" from printing (but otherwise leaves them alone). I'd be more confident in that kind of solution if RECAP had some sort of guidelines about how it tags the elements that are added to the UI. "All elements with 'recap' in them" could be both under- and over-inclusive, after all. If RECAP tagged everything it added to the user's screen based on a consistent rule, a userscript could be much more precise. Maybe an additional class that's not used for any formatting by default...or another attribute entirely. Maybe a "recapext" attribute that's set to "buttons", "marker", or whatever other kinds of interface elements are pushed to the screen by the RECAP extension. A user could easily write their own script to filter some or all of them out as they saw fit. In short--just provide some means to consistently identify the DOM elements which RECAP added (and preferably give some idea of why). RECAP isn't changing the behavior of how pages print, it's just being transparent with its end users about what was added to the page. Or if there is such a rule in place, just share what it is (it might actually be "the outermost added element has 'recap' in the class name", but that's just a guess from a couple examples. Does that make sense? I realize that may have downstream consequences, too, but it would satisfy my needs. EDIT: just saw this in another thread as the proposed implementation. So that pretty much answers my "how do we identify "recap" inserted objects. So mostly never mind about that bit; thanks. @media print { [class^="recap-"], [id^="recap-"] { /* Any class or ID that starts with `recap-` */ display: none; } }

…

On Mon, Jan 8, 2024 at 1:35 PM Mike Lissner ***@***.***> wrote: Sorry not to reply sooner, but I'm going to don my benevolent dictator hat and say that the original plan here is the one to pursue. I *have* talked to a lot of users at this point, and there are tradeoffs in the groups: 1. Journalists are willing to broadcast that they use RECAP. 2. Lawyers hide the fact that they use RECAP or are at least quite cautious about it (for now) 3. Other people don't have strong opinions for the most part. Based on this broad sketch, I feel comfortable saying that all RECAP stuff should be hidden by default and that we shouldn't have user-visible settings for this. If there's an easy way to document this and put it in about:config, say, I'm +1 for that as well, but printing is a rarely used feature, and we don't want to add a setting for it from now until eternity. (I'm also concerned that we're bikeshedding a bit <https://en.wikipedia.org/wiki/Law_of_triviality>. This should be a non-controversial issue because practically nobody prints things anyway. If we get blow back, it's very easy to reverse.) Thanks for all the input. I do appreciate it. — Reply to this email directly, view it on GitHub <#360 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG6G45Q6KO7T7HD27GPV6ADYNQ37LAVCNFSM6AAAAABBGVC52GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRGYZDCNZVG4> . You are receiving this because you commented.Message ID: ***@***.***>