Do front end and API for Pray and Pay

[mlissner]

An earlier message has a nice prototype of how the front end could work:

I'm thinking through the front end, my first thought was to have something like this where the prayer emoji is available in rows of documents that need to be bought, right next to the "Buy on PACER" button. If someone clicks it without being logged in, they'll be directed to the sign in page. If they've exhausted their daily quota, the emoji will be grayed out with CSS.

Thoughts?

Originally posted by @v-anne in https://github.com/freelawproject/courtlistener/issues/4486#issuecomment-2379736233

---

To do this, we'll need two things:

1. An API for creating and deleting prayers
2. The actual HTML tweaks

The API should probably use the Django Rest Framework. I think a good example for this would be DocketAlertViewSet, which is documented here:

https://www.courtlistener.com/help/api/rest/alerts/#dockets

I don't think we need documentation for P&P.

For the front end, I think the picture above is good, but two thoughts off the bat:

1. I think the icon needs a few states:

   • Unclicked with or without a count of other users
   • Clicked with or without a count of other users

2. I like how unobtrusive the icon is now, but it doesn't teach people what it is. Maybe a mouseover popup? Explaining or leading to a help page?

Another question is how people find the leaderboard. Ideally it'd somehow be tied to the button, I think, but I'm not sure how. Maybe it could also live in the mouseover popup.

We usually use HTMX for doing updates like these, if that's feasible.

Finally, with UI stuff, it's really nice and fairly easy to use django-waffle to launch it for just a few people at a time. I'd definitely recommend that for a feature this big.

[v-anne]

@mlissner, right now I'm thinking of doing the API first and allowing tech-savvy people to test the internals of the feature (does the leaderboard show the documents, etc.).

Good points on the front end--I hadn't thought it through that deeply until seeing your post. I will take a bit to digest it before offering a new design.

One thing that I've been thinking of, however, is whether it is beneficial to limit document requests to people with accounts. Do you have statistics for what fraction of the CourtListener DAU count signs in with an account? If we're limiting the feature to a small fraction of the user base, that seems counterproductive.

[mlissner]

One thing that helps a lot with getting front-end stuff in place is django-waffles. That will easily allow us to get something into prod that can only be used by a few select people. It really lowers the stress level.

If we're limiting the feature to a small fraction of the user base, that seems counterproductive.

A bit, perhaps, but I think the alternative is to use cookies on anonymous users, right? That is fine right now, but we're planning a CDN that would serve cached content to those without cookies, so I don't think I want to start using cookies on anonymous people just because of that.

We do have a pretty good solution for this though, which is to prompt people to log in when they click something like this. Try loading a docket page while logged out and clicking the "Create Alert" button. You'll see this:

We could easily trigger that modal on the prayer-hands emoji, and I think we'd get people logging in if they want to participate. Seems better than allowing anonymous trouble-makers!

[v-anne]

@mlissner I am making good progress on the front end. I was thinking of the following design.

• Each document that is not yet on RECAP will have a button to the right of "Buy on PACER" with varying text:
• If there are no open requests for that document, the button will say "Request purchase".
• If there are pending requests, the button will say "[num] requests".
• If a user clicks the button, it will change to either "1 request" or "[num +1] requests" via javascript
• If the user has exhausted their quota, the buttons will be grayed out, with alt text informing them to wait 24 hours.

My question for you: is this an impractical use of resources? Every unavailable document would need a database query to see if there are any open prayers for it. For a page with n docket entries, I suspect there are already 2n database queries (n for the text of the row, and another n for the documents themselves). This might turn that into 3n queries.

[mlissner]

Thanks @v-anne, this is getting close! I think I'd prefer a smaller button without the words, if we can pull it off. Maybe using a mouseover on desktop, and maybe just simply hidden on mobile?

I think your various states seem pretty good. I think the "wait 24 hours" might be wrong though, because I think they'd get their next batch...when? At midnight UTC? I'm actually not sure, but I suspect it's not 24 hours?

What do you think?

[v-anne]

I think I'd prefer a smaller button without the words, if we can pull it off. Maybe using a mouseover on desktop, and maybe just simply hidden on mobile?

Yeah, this is definitely possible, it could just be the 🙏 emoji, and then if there are open requests for that document, it could show something like "2 x 🙏"

I think the "wait 24 hours" might be wrong though, because I think they'd get their next batch...when? At midnight UTC? I'm actually not sure, but I suspect it's not 24 hours?

I think the current function has a rolling limit, where it sees if 5 requests were made within the last 24 hours (not the last calendar day, but the last 24 hours), it stops the user from making another request until there are no longer 5 requests within the time limit.

  async def prayer_eligible(user: User) -> bool:
      allowed_prayer_count = settings.ALLOWED_PRAYER_COUNT

      now = timezone.now()
      last_24_hours = now - timedelta(hours=24)

      # Count the number of prayers made by this user in the last 24 hours
      prayer_count = await Prayer.objects.filter(
          user=user, date_created__gte=last_24_hours
      ).acount()

      return prayer_count < allowed_prayer_count

[mlissner]

it could show something like "2 x 🙏"

Yep! Maybe without the × even.

until there are no longer 5 requests within the time limit.

Yeah, that seems right, so we'll just want to tweak the language we show the user to something vague instead of the 24 hours thing.

You also said, but I didn't catch, that you were going to put that in the alt text. Maybe this goes in the mouseover/tooltip too? I'm envisioning something like these little things:

https://getbootstrap.com/docs/4.0/components/tooltips/#examples

[v-anne]

You also said, but I didn't catch, that you were going to put that in the alt text. Maybe this goes in the mouseover/tooltip too? I'm envisioning something like these little things:

I'm sorry, I was conflating the two. I intended to mean using the mouseover, just like you suggested, but I didn't realize there was a distinction between them.

[v-anne]

@mlissner can you add me to the waffle flag?

[mlissner]

Done.

[v-anne]

I'm experimenting with the feature now. I'm glad that we were able to push to production. I think the prayers/top/ page will need some changes, because right now it's hard for users to know what case a document is from. I will work on a mock up and then make a new PR.

[mlissner]

A few bits of quick reaction from me:

1. The document pages should have more prayer hands. See:

   

   

2. There's nothing explaining to the user what these weird emojis are about. Maybe a mouseover with a link to a help page about them would be a good place to start?

3. The buttons themselves seem to be unclickable on the far right side?

4. I'm not getting a mouseover on the warning emoji when I run out of votes, but we should think about ways to refine that. I see that Stackoverflow uses a toast for this:

   

5. I wish I could see my own prayers somewhere. I guess a profile page would be the obvious place where we put things?

6. On the top prayers page, we need a good deal of refinement, but I think we know that, so I'll hold suggestions for the moment.

What else are others thinking/seeing?

This is really cool. Now it's about polish!

[mlissner]

I'm glad that we were able to push to production.

I heartily love waffles for anything UI-related. After another round of cleanup and documentation, we can do a social media post and get more people opted in.

🧇!

[v-anne]

The buttons themselves seem to be unclickable on the far right side?

Sorry, what do you mean by this?

[mlissner]

Try and click just inside the button to the right of the emoji. It doesn't work for me.

[v-anne]

Got it, I see it now. Not sure what's going on.

[v-anne]

A few more issues:

• people can request minute orders but the "Buy on PACER" button on the leaderboard doesn't allow for them to be purchased. That means those requests will just stay around indefinitely?
• I don't know if this is independent of the new feature, but after clicking the "Buy on PACER" buttons, I don't see the blue "View document and upload to RECAP" button.

[ERosendo]

I think the prayers/top/ page will need some changes, because right now it's hard for users to know what case a document is from

@v-anne I'm experimenting with this template. Here's my progress so far:

[v-anne]

@mlissner is the button clicking issue fixed now? I can't replicate it anymore.

[v-anne]

I wish I could see my own prayers somewhere. I guess a profile page would be the obvious place where we put things?

I'm thinking of taking this a step further. We can allow users to make their list of prayers public. That way journalists can share their lists with their readership and ask them to crowdsource documents they'd like to use for their work.

[mlissner]

@mlissner is the button clicking issue fixed now? I can't replicate it anymore.

Seems to be. Must have been related to the other JS problem.

We can allow users to make their list of prayers public.

Fun idea, but let's not add to our MVP requirements, and let's just see if we can get something out the door first?