Queue table | Show docket type

[lpciferri]

When BVA employees are working appeals, they need to see what type of docket the appeal is on, so they know what procedures to follow.

AC

• D = Direct Review
• E = Evidence Submission
• H = Hearing Request
• L = Legacy

and legacy can just say Legacy

Mocks

Docket types explained

Example of docket types displayed in "judge assign" table

[sneha-pai]

@allyceh @laurjpeterson @mkhandekar : I've added two variants for displaying docket type (AMA lanes and legacy). I'd love your feedback as comments below, and or we can chat about it in a call. Would love to know who will be in charge of developing the front-end of this, to verify and clarify that one or both of these treatments are accurate to the way we want to display docket numbers in Queue table.

Lanes:

• Legacy (non AMA) = L
• Hearing (AMA) = H
• Evidence Submission (AMA) = E
• Direct Docket (AMA) = D

Docket type (Variant A) + case-labels for hearing, specialty case, overtime (768px width)

Notes This variant has rounded ellipses representing each docket lane. To contrast, case-labels are more rectangular and have bolder colors that pop out more.

Docket type (Variant B) + case-labels for hearing, specialty case, overtime (768px width)

Notes This variant has semi-bold treatment for each letter that represents a docket lane. Again, to contrast, case-labels are more rectangular and have bolder colors that pop out more.

[lpciferri]

Thanks @sneha-pai!

• I like where you've placed the case labels
• I prefer Variant A because it is easier for me to distinguish the docket type from the docket number
• The case labels are more noticeable to me, likely because of the colors. I wonder if in the long run, it's more important for the docket type to be noticeable (compared with case labels) because of the different procedural considerations attorneys and judges have to take
  • For example, they need to evaluate what evidence to consider, and in what time frame, when it is an evidence submission docket
• It's still very uncertain how judges and attorneys will work a mixed docket. It's they could work cases, oldest to newest docket number, regardless of their docket. But, the law states that cases are first in, first out on each docket. Because of this, I wonder if attorneys and judges may want to group their cases by docket, and how that might affect sorting functionality. (this could be out of scope for this ticket, but wanted to surface the thought)
• Can this design exist exactly the same in the Case snapshot section of Case details?

From an engineering perspective, I think @mdbenjam should weigh in. It's likely that he or @lowellrex would implement this (though anyone else on foxtrot could do this, too!)

---

• Separate thought - we continue to see in our user research sessions that attorneys and judges spend the bulk of their time in Reader. How does this design translate, if at all, to Reader? I'm wondering if users could benefit from docket type being in the heading somehow for Reader, since the Claims folder details accordion isn't expanded when a user navigates to Reader. cc: @abbyraskinUSDS

---

[sneha-pai]

Hi @laurjpeterson

• @mkhandekar and I also slightly preferred Variant A over variant B, when comparing docket number treatment. We think it keeps the columns more aligned and even - in variant B, single-letter docket labels (H) look differently aligned vs double-letter docket-labels (ES).
• Which board stakeholders should we walk these label treatments with, both for approval of label abbreviations (ES, H, DD, L) and for visual treatment?
• Re: contrast in docket numbers - I think it will be visually exhausting to repeatedly see a more bolder, differentiating treatment for docket numbers in table, since after some practice, I'm assuming that all those who are seeing this will be quite accustomed to treating these docket types differently, according to the rules. Docket numbers will be everpresent in caseflow, and this may cause the interface to look loud everywhere. It may be helpful to create on-hover tooltips to explain each label, and maybe a more striking treatment in case details.
• Great point about Reader - Queue design and developers have been using a lean Header treatment to always display Checkout Header + veteran ID in checkout flows (to remind the user of which case they're sending away, etc) - I'm wondering if we can do a similar treatment in Reader, (Reader Folder Header + veteran ID + docket number = as always viewable?)
• Would love @mdbenjam, @lowellrex and others to chime in on this too, regarding feasibility.

[mkhandekar]

Labels:

• 👍 for Variant A
• 👍 for light docket label (which will be present for each row) and darker case labels (which will be scattered/fewer) with hover for each
• 👍 for having this column be sortable. @dannysellers with the table/sorting library we are using, what are the options available for possibly clicking on the sort arrow and a dropdown appeaing with the 4 AMA lane options... or something similar to this?

---

Can this design exist exactly the same in the Case snapshot section of Case details?

Yes, definitely, placement TBD.

---

Unified header for Reader + Queue:

• Whenever you're viewing a page that is not Case Details, maybe there is a unified, slim header with:
  • Vet name
  • Vet ID
  • Type
  • Docket number
  • any labels that are necessary which will be likely a bit larger than they appear in the table view (docket, case label)
  • View documents (only in Queue, not Reader)
• In Reader, the accordion can still contain Regional Office and Issues.
• I'd love to take a pass at this, if it makes sense?

[mdbenjam]

This doesn't seem very hard to implement, though it does add two new stylings that aren't in the styleguide. It looks like the docket type is within the docket number. I think this is 👍 , sorting will just be sort by docket type then docket number.

[allyceh]

@sneha-pai These look good! I also prefer option A like the rest of the group.

A thought for the future: It seems like we're putting a lot of information into these table rows. And arguably, it's all very useful for judges and attorneys to have when they're assigning or reviewing cases. Is there any information in these table rows that we can just display on the Case Details page one level deeper? Like docket number for instance. Now that we're displaying the lane a case is in, do users need to see the docket number, or is that information not "need to know" at this level? Same with the vet ID number. How might having the vet ID number help them at this point rather than keeping it at the Case Details level?

[allyceh]

Last thought: If we have the ability to remove any of these data points (per the comment above) in the table and keep them at the Case Details level, we could use full words (ex: Hearing, Specialty) in one set of our tags. That would allow us minimize the different groups of abbreviated tags that a user would have to remember and would help to distinguish them a little more (?).

[lpciferri]

@mdbenjam - can you weigh in on the feasibility of sorting functionality by docket number and docket type? thinking that on one click, the user could view cases grouped by docket type (either with some pre-determined ranking or alphabetical) then by docket number (oldest to newest / newest to oldest depending on the direction clicked)

@sneha-pai - looking back through some materials. i think the direct lane is officially Direct Review and has been called Direct docket for short.

[mdbenjam]

Wait so is the question can we sort by docket type and then within type docket number? That answer is yes. Easy to do. Or is the question can we sort by docket type with one click, and a second click to sort by docket number? That answer is no, much harder to do.

[lpciferri]

@mdbenjam was asking about the first scenario you walked through. Thanks for answering for both options, though, it helps!

[mkhandekar]

Separate thought - we continue to see in our user research sessions that attorneys and judges spend the bulk of their time in Reader. How does this design translate, if at all, to Reader? I'm wondering if users could benefit from docket type being in the heading somehow for Reader, since the Claims folder details accordion isn't expanded when a user navigates to Reader. -- LP

Continuing conversation about designing a more universal case title here: https://github.com/department-of-veterans-affairs/caseflow/issues/6963