Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changing time and type eligibility displays #1190

Open
michaelzhang43 opened this issue Jun 4, 2020 · 11 comments
Open

Changing time and type eligibility displays #1190

michaelzhang43 opened this issue Jun 4, 2020 · 11 comments
Labels
Complexity: 3 Refer to issue #739 for more details design frontend not ready yet

Comments

@michaelzhang43
Copy link
Contributor

Creating an issue here to bookmark this idea:

We currently display a green checkmark for Type eligibility if it is Type eligible, even if the case is not Time-eligible and therefore not Eligible as a whole. I'm thinking that the green checkmark may be misleading. At the same time, the red X would also be inaccurate.

Let's brainstorm a possible solution in the comments. I will start by proposing that, in the above scenario, we simply omit the green check

This task is done when:

@wittejm
Copy link
Contributor

wittejm commented Jun 4, 2020

Getting rid of the green check mark sounds like a good change.

Another thought on this is that "Type Eligibility" has become more complicated and difficult to express succinctly. The 22 (!) types are defined by a patchwork of their identifying information, relevant statute subsections, and case law / convention.

Also, "a charge must be both time eligible and type eligible" itself is getting messy because these two criteria aren't fully distinct. Class B felony is the best example; also the <1 oz Marijuana charge, and MarijuanaUnder21 have type-based time eligibility.

The key information the user needs to see is the answer to "This charge is eligible because __" . Our type eligibility Reason text covers most of this. Could we go further and hide charge type names, and only show reason text, And re-word the reason text where necessary?

@hmarcks
Copy link
Member

hmarcks commented Jun 10, 2020

It's harder to determine why an eligibility reason is given at a quick glance, but it may not matter to the common user and it does reduce some noise:

eligibility-icons

@michaelzhang43
Copy link
Contributor Author

Thanks for pinging on this, Hunter - I had lost track of this issue

Jordan - I agree that Type and Time eligibility concepts overlap and are potentially confusing categories esp. for the Chargetypes you named.

I'm inclined to think that we can do away with the icons altogether, as Hunter marked up in the No Icons panel.

What do yall think @wittejm @KentShikama

@KentShikama
Copy link
Member

KentShikama commented Jun 11, 2020

@michaelzhang43 I think that sounds good as a short term solution.

As a longer term solution, I'm wondering whether we could do something like the network diagnostics tool on OS X

Screen Shot 2020-06-11 at 7 07 11 AM

To make it even clearer that each step is linked to the next one, there should be a "river" (line with an arrow pointing in the direction the "river" flows) that connects each step. If any node is non-green, it pollutes all the nodes "downstream". As @wittejm mentioned, for some charges like MJ <1, the time eligibility function (step) is just the identity function, but I think it is fine to just state the fact that it is an identity function.

Our version would have four nodes: type eligibility, time eligibility, balance owed, and final verdict. The color of the final verdict node should match the top-level eligibility label.

When there are n ambiguities, the river should split into n individual rivers at the top and merge at the bottom for the final verdict.

@michaelzhang43
Copy link
Contributor Author

what? @KentShikama

@KentShikama
Copy link
Member

KentShikama commented Jun 11, 2020

@michaelzhang43 Hmm? Do you want to call?

@hmarcks
Copy link
Member

hmarcks commented Jun 11, 2020

I see what you're saying @KentShikama , isn't it very similar to the current approach, except we aren't including Balance? At least this was how I was thinking about it when designing it. To make it more clear each node would be more visually connected.

@KentShikama
Copy link
Member

KentShikama commented Jun 11, 2020

Indeed. I guess I'm imagining the river flows downwards instead of upwards like it currently is.

@KentShikama
Copy link
Member

Linking #1303

@KentShikama
Copy link
Member

@michaelzhang43 I believe this issue can be closed now?

@hmarcks
Copy link
Member

hmarcks commented Jul 27, 2020

One thing that hasn't been updated yet is the Time icon when ineligible:
Screen Shot 2020-07-26 at 10 47 29 PM

@KentShikama KentShikama added this to the August Milestone milestone Jul 29, 2020
@KentShikama KentShikama removed this from the August Milestone milestone Aug 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Complexity: 3 Refer to issue #739 for more details design frontend not ready yet
Projects
None yet
Development

No branches or pull requests

4 participants