Closed wittejm closed 4 years ago
We can work on this incrementally type by type, so y'all can feel free to spam smaller PRs for this issue.
Love this. Here's a proposal for revealing it on the frontend. Please take a look @michaelzhang43 and all:
Updated mockup below
This looks great!
Agree with Jordan. This looks great
One thing I’m concerned about is overexposing information and potentially confusing the user. For example, for a dismissed B Felony, I think our documentation should just be that any dismissed case is type eligible for expungement.
That concern makes sense.
We already show the type eligibility reason which is usually very short. For dismissals we currently usually say "Eligible under 137.225(1)(b))" but there is an open issue #812 to clarify with "Dismissals are eligible under 137.225(1)(b))"
How about, to avoid overwhelming the user the link for more documentation should be a little "less welcoming" -- so the user doesn't click it thinking that they actually need that extra information. Maybe it's called "more legal details", then no one will click on it unless they really want to.
Maybe take the link off entirely, and it's only in the docs section of the website?
How about one of the following:
Todo: Identify and complete the set of charge types that don't have a rules string yet.
Updated mockup to account for multiple types when a charge needs clarification:
Showing charge rules in the results page was completed with #1324. I'll make a new issue for part 2, the standalone page of rules for all charge types.
Edit: Renaming and updating this issue for the next phase, of adding the frontend feature.
See below for mockups.
To handle charge types that are essentially split between two classes (
RomeoAndJulietIneligibleSexCrime
andDUII
), we'll need to address then in a way that both the Manual's charge types page and the entries included in the search results page both look "good" to the user, while the manual page is ideally still easily generated from the text written in the backend.older, completed phase of writing the expanded documentation.
This will need to be a work in progress as we figure out exactly how to handle detailed explanatory documentation. We want to:
For now, we can achieve this by writing the explanation for a charge type as a string field on the charge type class object. The python doc module Phoenix relies on comment strings attached to classes and methods (
obj.__doc__
) but we should use a named string field because__doc__
strings are meant to be developer-facing, not user-facing.The doc for each charge type can include the following:
ChargeClassifier
for that charge type, especially when a charge seems like it could qualify as multiple charge types? A charge always gets exactly one type, and the order of rules getting applied is very specific. It might be useful to provide any extra context on why a charge type can be applied with higher precedence than other types (e.g., Subsection12 names some Felony statutes, so the classifier needs to check Subsection12 with higher priority than the Felony charge types).The string field on each Charge type can be called
expungement_rules