Analyze order of docket sheet to optimize user workflows

[mlissner]

Right now, the most recent filings are at the bottom of the docket so it reads in chronological order. I didn't give this a lot of consideration when I implemented it originally, but I just heard from a user that wants it switched. I think they're probably right that we should do so.

I think the counter argument is that folks like to read the initial complaint. To the extent that's true, maybe we should do both: Most recent first, and pin the complaint at the top somehow.

Thoughts?

[mlissner]

Twitter poll here: https://twitter.com/FreeLawProject/status/1323720475982262279

[brianwc]

I even get annoyed when docket alerts reverse-chron the docket to show me the latest filing first. I ALWAYS want the docket to appear in regular chron and would prefer a user-setting that controls that.

On Tue, Nov 3, 2020 at 12:16 PM Mike Lissner notifications@github.com wrote:

Twitter poll here: https://twitter.com/FreeLawProject/status/1323720475982262279

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/freelawproject/courtlistener/issues/1434#issuecomment-721352537, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACPKOMTU3Z43C4N4D3PDODSOBQIZANCNFSM4TJF53LQ .

[johnhawkinson]

I don't think that this is a good proposal, and I think the poll is misguided, because it asks people what they want, rather than evaluates their workflows to determine what they want (i.e. they are "threadbare recitals of a [solution], supported by mere conclusory statements." Ashcroft v. Iqbal, 556 U.S. 662 (May 18, 2009) (misquoting to characterize the notice pleading standard as a poll worthiness standard…yet it fits)).

The problem we really want to solve is that readers want to see what's new, and they don't get that when they land on the first page of a paginated docket sheet. We can't ignore that, and hopefully it will help guide us to a solution.

This is not "easy pickins" — it's actually a really hard design problem. How do our peers solve this problem, and what are the reasonable web design patterns more broadly?

People want access to the case initiating documents, and people want access to the latest documents. I think those are the most common cases, and then there are people who want stuff in between, who are less common. And there are people who want to Cmd/Ctrl+F and search the page for a string, and those people are sad.

There's a strong argument for keeping it the way it is, because you have created a reliance interest. Furthermore, you're not designing a website from the ground up, you are mimicking PACER/CMECF, and should take strong direction from their design choices, even when they are not great (but not, perhaps, when they are abysmal—which this is not). And of course there are good use cases for it.

A whole deeper debate is whether there should be a knob. I would tend to think not, because that distracts us from finding a good solution.

As you proposed, providing access to the case-initiating document as well as the latest documents is an intriguing suggestion. As is my independently-generated three-quarters -joking suggestion of giving the first 50 and the last 50, instead of the first or last 100. We should perhaps also give serious thought to the JavaScripty solutions of dynamic loading, even though I hate hate hate those, it is possible I hate them less than I hate the concept of pagination. I am not sure.

I think this design problem needs careful thought and analysis. We should start by talking about the uses cases, and then look at our peers, and then look at web design in general, and then see how to apply all that stuff to the problem.

[mlissner]

The poll has its limitations, no doubt, but it gives people a voice, which is good, and it is something of a landslide, which helps.

I think we mostly know the use cases:

• Read a docket top to bottom (favors current design)
• Find the most recent thing (favors reversed design)
• Get a sense of what the case is about (favors current design or initial complaint + reversed design)
• And maybe: Figure out and read the important documents (somebody on the poll suggested we order based on votes, reddit style. That's wacky, but there's a point there that big parts of the docket sheet are cruft that can be mostly ignored).

I don't feel great about a javascript scroll to load design. I like that it lets you load up one page with TONS of content, but I mostly see it as a fancy way of clicking the "next" button. (It's also hard to build, but we could learn.)

I'm not sure what others are doing here. I'd welcome that analysis.

I can't think of other websites with a problem space like this. If you frame this as trying to display/understand chronological information, then I guess you can consider social media timelines, which are all ordered with newest first or algorithmically. OTOH, I use twitter in a way that preserves chron reading because otherwise it's super confusing, so I get that too.

---

All this said: My current leaning is to show the initial complaint + reversed chron by default with a setting that allows you to go pure chron if you want. Maybe the setting just gets set any time you flip results, I dunno, but ideally it's not in the user profile anywhere.

[mlissner]

I guess you could also imagine a design that shows pure chron + latest filing. Something like:

Doc
1
2
3
4
latest
22

So, in other words, it'd be at the bottom.

[johnhawkinson]

The poll has its limitations, no doubt

but it gives people a voice, which is good

But it's not! That statement assumes facts not in evidence, and we actually know it to be very problematic. People do not know what they want! Asking them to pick from a fixed set of overlapping choices doesn't tell you what the right thing is even when the choices are all the best choices, and I think they are not the best choices here. Instead, the poll sets up a false set of expectations among the poll respondents and it provides confirmation bias to the developers. It's all bad.

and it is something of a landslide, which helps.

Except there are overlap issues.

More significant is your sample pool. You have sampled Twitter and asked if they are more interested in brand new stuff versus stodgy old stuff. What kind of answer did you expect?

There is every reason to think that is not representative of RECAP users.

But hopefully we can come up with an answer that is better than all of these choices!

Find the most recent thing (favors reversed design)

Does it? Would we not be better starting on the the last page in chronological order and warping the page to the final item? Reverse chronological order is…tricky.

Get a sense of what the case is about (favors current design or initial complaint + reversed design)

Favors nothing. Sometimes old stuff is more relevant sometimes new stuff is. We don't have a good way to do this.

And maybe: Figure out and read the important documents (somebody on the poll suggested we order based on votes, reddit style. That's wacky, but there's a point there that big parts of the docket sheet are cruft that can be mostly ignored).

We know the document types that are most interesting. It's not rocket science. It's the case initiating documents and amended/supplemental pleadings, the motions for summary judgment (or other dispositive motions, 12(b) motions, etc.), the opinions. After that then non-dispositve non-PHV motions and orders. We don't have a model for dealing with that but it's a pretty easy regexp. But it's probably outside the scope of this issue, but it is an important need.

I guess you could also imagine a design that shows pure chron + latest filing. Something like:

Yes. See my 3/4 joking suggestion. Of course you would want good design to show the gap in a very clear way.

I can't think of other websites with a problem space like this. If you frame this as trying to display/understand chronological information, then I guess you can consider social media timelines, which are all ordered with newest first or algorithmically. OTOH, I use twitter in a way that preserves chron reading because otherwise it's super confusing, so I get that too.

Really? Like any other website that uses pagination to show items? All the other websites that show court dockets? Twitter is a great example of how they have fucked this up. It's so hard to view a thread of tweets now and it got a lot worse in the past month or two.

[brianwc]

So many sites have the scroll down to auto-load more content, I have to believe that there's a couple dozen lines of standard code that do it now. This is sort of a separate but related issue, as the paging through long dockets currently is fairly painful, but is not directly related to chron vs. reverse chron vs. a hybrid. First stack overflow link I followed suggests people figured this out over 7 years ago! https://stackoverflow.com/questions/14035180/jquery-load-more-data-on-scroll

I also put no stock in the Twitter poll. People voting in Twitter polls on Election Day are in a very scattered state of mind.

On Tue, Nov 3, 2020 at 2:55 PM John Hawkinson notifications@github.com wrote:

The poll has its limitations, no doubt

but it gives people a voice, which is good

But it's not! That statement assumes facts not in evidence, and we actually know it to be very problematic. People do not know what they want! Asking them to pick from a fixed set of overlapping choices doesn't tell you what the right thing is even when the choices are all the best choices, and I think they are not the best choices here. Instead, the poll sets up a false set of expectations among the poll respondents and it provides confirmation bias to the developers. It's all bad.

and it is something of a landslide, which helps.

Except there are overlap issues.

More significantly is your sample pool. You have sampled Twitter and asked if they are more interested in brand new stuff versus stodgy old stuff. What kind of answer did you expect?

There is every reason to think that is not representative of RECAP users.

But hopefully we can come up with an answer that is better than all of these choices!

Find the most recent thing (favors reversed design)

Does it? Would we not be better starting on the the last page in chronological order and warping the page to the final item? Reverse chronological order is…tricky.

Get a sense of what the case is about (favors current design or initial complaint + reversed design)

Favors nothing. Sometimes old stuff is more relevant sometimes new stuff is. We don't have a good way to do this.

And maybe: Figure out and read the important documents (somebody on the poll suggested we order based on votes, reddit style. That's wacky, but there's a point there that big parts of the docket sheet are cruft that can be mostly ignored).

We know the document types that are most interesting. It's not rocket science. It's the case initiating documents and amended/supplemental pleadings, the motions for summary judgment (or other dispositive motions, 12(b) motions, etc.), the opinions. After that then non-dispositve non-PHV motions and orders. We don't have a model for dealing with that but it's a pretty easy regexp. But it's probably outside the scope of this issue, but it is an important need.

I guess you could also imagine a design that shows pure chron + latest filing. Something like:

Yes. See my 3/4 joking suggestion. Of course you would want good design to show the gap in a very clear way.

I can't think of other websites with a problem space like this. If you frame this as trying to display/understand chronological information, then I guess you can consider social media timelines, which are all ordered with newest first or algorithmically. OTOH, I use twitter in a way that preserves chron reading because otherwise it's super confusing, so I get that too.

Really? Like any other website that uses pagination to show items? All the other websites that show court dockets? Twitter is a great example of how they have fucked this up. It's so hard to view a thread of tweets now and it got a lot worse in the past month or two.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/freelawproject/courtlistener/issues/1434#issuecomment-721416930, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACPKOORAURUPRL4ZO3FM6TSOCC63ANCNFSM4TJF53LQ .

[mlissner]

First stack overflow link I followed suggests people figured this out over 7 years ago!

That explains how to trigger something on scroll. That part's easy. The hard part is the something that you trigger. We'd need an API to serve the results, and we'd need a template for folding them in below the current ones, etc. But yes, there are solutions to this and we'll be close to them when I land the tags feature one of these days.

[mlissner]

Reading through this a year later, it feels like we let the perfect be the enemy of the good. I think a solid UX boost would be to add the complaint at the bottom of the reverse chron, and to add the most recent fillings at the bottom of the regular chron.

This way, no matter your sort, the page that loads has both the latest and most recent fillings when it loads.

I could almost see these docs going below the pagination, but that's getting wacky...

[troglodite2]

There are people that want the docket in reverse order, there are those that want it in ascending order.

The compromise, as I understand Mike, is that we have a "smart" version.

Under the smart version, the first docket entry would be shown at the very top. Under that would be the latest N docket entries in ascending order.

Following that would be the entire docket in the sort order requested.

[mlissner]

Yeah, the idea here is that everybody has a preferred default, but regardless of whether the docket is sorted desc or asc, we can make the page better by showing the extreme endpoints. So:

• if it's sorted asc and has more than one page, we should show the $X last items $somewhere.
  • I'm not sure the right value for $X, but three feels good. One feels like it'd often not be enough, and five feels like a lot.
• If it's sorted desc, has more than one page, and has the first docket entries, we should show the first $Y items $somewhere
  • Again, I'm not sure the right value for $Y, but one might be enough, if we have entry number one. Typically, the first entry is really interesting, but number 2 isn't so interesting.

As for the value of $somewhere, I'm not sure how to best do it. Options:

• When asc: It could go at the bottom, below the pagination, with a small header that says, "Last $X Items". This could even be integrated into the pagination box, maybe, but that sounds tricky.

• When asc: There could be a little accordion illustration that says > 554 more entries < and then it could show the last $X items, all as part of the normal table.

• When desc: It could show the first item near the top, above or below the filter box, but I think this is tricky because of the table headers having to be repeated.

• When desc: It could show the first item at the bottom, accordion style, as above.

• When desc: It could show the first item below the pagination, as above.

One other thing. Django Paginator's have an orphan setting that prevents small final pages. we should use to avoid the scenario where we show the last few items above/below the table, and then the next page has only those same items. So:

• If a docket has 105 items, pagination set to 100, and is showing five extra items below the pagination.
• orphan should be set to 5 so that there's no page two that only has the same extra five items on it.

[troglodite2]

Two potential options to consider which I think will make for a better UX.

Option one is to have a tab with better language which would be a docket entry with first entry and last 5 entries, in that order.

The second option would be the same, but with the first entry and the last 5 entries in an accordion which the user can open. This would give a quick change as the HTML would already be loaded, no need to hit the servers with a page load.
We can attach a value to the session cookie to open the docket on the last tab picked by the user. So if they normally use the quick look then that tab would be the tab displayed.

If we do an accordion then the open/closed state of that section would be retained on the users session cookie.

[mlissner]

Good thoughts. I don't like the idea of another tab, I think it'd be confusing since it'd be so similar, and I think we can cram the functionality into the existing tab with a bit of UX experimentation.

I do like the idea of the collapsed accordion. But I have a simplifying approach that also helps us answer what happens on page 2 or 3 or whatever. Instead of showing it at the top or bottom of asc or desc, what if it is always shown if there are more items to show.

So imagine page size of 50 items on a docket with 1005 items.

Asc

Page 1 shows:

• No accordion at the top
• Items 1-50
• Accordion at the bottom showing 1000-1005

Page 2 shows:

• Accordion at the top for item 1
• Items 51-100
• Accordion at the bottom for 1000-1005

...

Page 20 shows:

• Accordion at the top for item 1
• Items 950-1005
• No accordion (because of the orphan parameter)

Desc

Same as above, but flipped.

I think this approach means that the accordion can just go as a row below/above the rest of the other entries (not outside the current table or above/below the pagination or filters — just as another entry in the table).

Agree about not doing it with Ajax, and having it there in the page load.

I don't think we need a session value for this. It's less of a preference and more of something you'd want some of the time but not others.

So yeah, I think it'd be great to have buttons at the top and/or bottom that say either "See Latest Filings" or "See Initial Filing." Maybe a blue or white button centered in a row with a single cell and a zigzag left and right border?

[troglodite2]

Bluntly, I think users are lazy. There are people that are going to be reading the docket. They are going to pick the order they want to read it in and go from there.

The other class of people are interested in the latest updates. These are the people getting a docket link from somewhere else or via a search that want to come up-to-date on the case.

Consider https://www.courtlistener.com/docket/4286773/kolbe-v-omalley/ if it were still a live case.

If I'm just looking to come up to speed I'm going to want to read DocketEntry.objects.get(docket_id=4286733,entry_number=1) and then entry_numbers=[97,96,95,94,93] Sorry if I got the field name wrong.

Those six docket entries are going to give the causal user as much as they need.

For somebody that is following the case and just wants a quick peek at what is happening. Instead of the last 5 entries consider the following logic.

if the number of entries is < 6 quick look displays them all.

If the number of items is >= 6 then: The number of entries is at least the 5 latest but will include all entries between last date_filed and last date_filed minus 3 days.

Since it is common to see a number of docket entries all drop in quick succession, this would be a good methodology. to pick what people are looking for.

I.e. the complaint and the last 3 days of filings.

In our example that would get us 1, 97, 96,95,94, and 93.

If we were to look at the docket on April 4, 2014. Then the quick look would give 1, 61..49 That's because there are a number of entries added on Mar 17 and Mar 18.

I think we have agreed on an accordion. The placement of that accordion would be as I suggest above. When it opens it is a new table with exactly the same headers we have now.

On clicking to go to the next page it would close the accordion. We wouldn't update the session cookie. The user can open it back up if they want on following pages. Only on page 1 would the session value control if the accordion is open or closed.

[mlissner]

Hm, I'm not hot on the tab idea, but I'll think on it some more. Maybe land that as a second piece?

Why put the accordion above instead of integrated into the existing table? Better UX or easier tech or something else?

[troglodite2]

This is how I see it working. Default is quick look closed. Then open it and the first entry and last "n" entries are presented.

[mlissner]

OK, cool, yeah, that's where I had in mind too, thanks. Can you tweak it though to do a button in the middle that says either:

Show Initial Filing

Or:

Show Latest Known Filings

This is looking great.

[troglodite2]

I am not a front end sort of person. I think that what might happen is that I do a PR with the functionality and then let somebody else make it prettier.

[mlissner]

I'm not a front-end person either, but that second one looks pretty good. Just put the button classes on the link and I think you're there? Add class="btn btn-default btn-lg and see how it looks?

[mlissner]

Also, sorry, one other thing. Is it possible to have different text for the initial button and the end button or is that hard?

[troglodite2]

It is currently set to just show one accordion at a time but we can set it to have both open.

[mlissner]

Oh, I was thinking it'd go above and below, like the description I put here:

Page 1 shows:

• No accordion at the top
• Items 1-50
• Accordion at the bottom showing 1000-1005

Page 2 shows:

• Accordion at the top for item 1
• Items 51-100
• Accordion at the bottom for 1000-1005

...

Page 20 shows:

• Accordion at the top for item 1
• Items 950-1005
• No accordion (because of the orphan parameter)

[troglodite2]

What is the use case for putting it at the bottom? What I currently see as the use case is user comes to case in one of two modes, ascending or descending. The user is now on the first page of the docket. That docket could be many pages long. They want to know what the latest or what the initial entry is and do not want to scroll to the bottom of the page and potentially click to the last page and scroll to the bottom.

We can be smart and provide just the information they need at the top or we can provide both at the top.

The second use case is that the user is at the bottom of the page and doesn't want to scroll to the top or to a different page in order to see the initial or latest filings.

Since I'm just one user and users are known for wanting what they want, why don't we compromise and put the double accordion at the top and the bottom. Option 4 below.

If it is descending they have everything they need to know what is currently happening but not what the initial filing was.

If it is ascending they have the initial filing and will have to scroll to the bottom or page to get to what is currently happening.

Option 1: Ascending put the latest in accordion at the top. Descending, put the initial at the top

Option 2: Ascending put the latest at the top and the initial at the bottom. Descending put the initial at the top and the latest at the bottom

Option 3: Ascending and descending, put initial and latest at the top

Option 4: Ascending and descending, put initial and latest at the top and at the bottom.

Code wise there is no difference in effort to do any of these options. In the view I created two new DocketEntry lists, one with the initial filing and the other with the last 5 entries. The number 5 is just for mock up at this time. I think it needs to be smarter than just a constant.

This is passed to a the docket.html template. docket.html then includes a new template includes/de_list_w_accordion.html This file currently contains 2 accordion items. If we go with different options we just add or remove accordion items. The body of the accordion is {% include "includes/de_list.html" with docket_entries=first_entry %} where the context variable changes according to which accordion it is.

de_list.html is modified by stripping out the table header and one level of div. That table_header is now in de_list_w_accordion.html

[mlissner]

Sorry for the delay. I needed to think on it a bit. I think I'm sold on the idea that putting both at the top is a good idea, provided that it doesn't repeat content that's already on the page. So:

• If the initial filing is on the page, don't put it in the Quick Look accordion.
• If the latest five items are on the page, don't put it in the accordion.
• If both are already on the page, don't do an accordion at all.

I think if the latest and first docs are in a thing at the top of the page, the need it at the bottom is really minimal, so I think I'm describing option 3 instead of option 4.

---

About your coding approach:

• Yeah, just having a variable set to 5 seems good to me.
• I don't follow the template concept you're proposing, but it sounds like you're doing minimally invasive template work, which is good. It'll make sense when I see it, and it sounds like you're doing it how I'd imagine?

Thank you!

[troglodite2]

I think I prefer that "quick view" to be the same, regardless of sort order. I can easily see having a table where we store the "open close" default. That way when a user goes to the page and it is in a default to open, then the user sees everything in the same order every time.

I'm looking at a person that has a list of docket links, maybe from their alerts, and they just want to click on the docket link, they see the initial and latest and don't even look outside of the accordion. It is all right there

Option 3 is what I like the best as well.

[mlissner]

Out of an abundance of over-communicating, when you say this...

I think I prefer that "quick view" to be the same, regardless of sort order.

...you're just agreeing with me, right?

[troglodite2]

Yes. I am agreeing

On Thu, Apr 6, 2023, 17:49 Mike Lissner @.***> wrote:

Out of an abundance of over-communicating, when you say this...

I think I prefer that "quick view" to be the same, regardless of sort order.

...you're just agreeing with me, right?

— Reply to this email directly, view it on GitHub https://github.com/freelawproject/courtlistener/issues/1434#issuecomment-1499666855, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATTKVMTTCEF2SA2B3G2R6W3W7425NANCNFSM4TJF53LQ . You are receiving this because you commented.Message ID: @.***>

[troglodite2]

I believe that the PR will give us a place to build from.