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

[Discussion] Errors and Reply badges. Too many colors! Not enough colors! #1154

Open
sssoleileraaa opened this issue Oct 7, 2020 · 7 comments

Comments

@sssoleileraaa
Copy link
Contributor

sssoleileraaa commented Oct 7, 2020

Description

(Followup for #1142 which adds the reply badge feature)

This is a place to capture ideas around how to display errors now that we have reply badges and use colors to mean more than just whether or not there was an error.

As you can see here, it can be confusing what each color means since we're overlapping information:

journalist-badges

Note that the red badges stands out here, but other badges, including the deletion badge, may end up being orange or pink (see Zeplin project for color palette) once multicolor badges is implemented, and that many colors may make it harder to see these red badges as special error state badges. It also makes it look like the red badge refers to the same user at first glance.

@sssoleileraaa
Copy link
Contributor Author

sssoleileraaa commented Oct 7, 2020

I used the screenshot above ^ as a template for my PNG prototypes. This PNG shows how we can remove the red and gray color coding of badges and message bars to lessen information overload:

journalist-badges-and-errors

And once we add support for mutlicolor badges we can clearly see that each color is for a unique account. If dellsberg ever replies again, it will always be orange:

journalist-badges-multicolor

(The colors used were taken from Nina's badge color palette in Zep-lin. Also Nina has mocked up a "Retry and Delete" option next to replies that fail to send, which can be added later.)

@eloquence
Copy link
Member

eloquence commented Oct 7, 2020

Thank you both @creviera and @ninavizz - see also freedomofpress/securedrop-ux#113 with closely related ideas.

I also want to cross-reference the previous discussion we had around #140:
#140 (comment)

Specifically this mockup:
Source-level error display

What this illustrates is source-level error display. The idea here is that some errors, such as encryption/decryption-related ones, may not be highly specific to a message or a reply, but a problem related to a specific source. Overloading the conversation view with urgent error displays may just have the effect of triggering anxiety or alert fatigue, and we may want to instead show a prominent top-level indicator with suggested remediation steps. This is what motivated the current, subtle decryption error indicators at the message and reply level.

I suggest a dedicated follow-up discussion about error handling, so we can tease apart changes we may need to make immediately (e.g., error placement for replies to support scaling of the client window) vs. changes we may need to make longer term.

@sssoleileraaa
Copy link
Contributor Author

sssoleileraaa commented Oct 7, 2020

Thank you both @creviera and @ninavizz - see also freedomofpress/securedrop-ux#113 with closely related ideas.

Absolutely! Nina and I spent a bunch of time talking about freedomofpress/securedrop-ux#113, and I was thinking about adding all of these as direct comments there, but I figured this keeps freedomofpress/securedrop-ux#113 clear of any terrible ideas I may have ;P. In retrospect, two separate issues isn't great. Perhaps we can close this issue after we have a dedicated follow-up discussion about error handling.

Overloading the conversation view with urgent error displays may just have the effect of triggering anxiety or alert fatigue, and we may want to instead show a prominent top-level indicator with suggested remediation steps.

Yup, I agree. However, if that mockup were to be updated to include reply badges, you would see gray badges, which is part of what I'm saying should go (along with red badges) since we use colors to represent different users. I definitely see what you mean around removing the alert fatigue, which I believe we can do this without gray badges, e.g.

alert-fatigue

@ninavizz
Copy link
Member

ninavizz commented Oct 7, 2020

@creviera there are no terrible ideas! Really, truly!! UX has to be a collaboration, or it fails. PLEASE always know you are welcome to both contribute to convos in the UX repo, and encouraged to start them... when it's just The Nina Show™ it loses its value. Especially with my limited hours these days, that seems like the perfect place for convos like these.

@eloquence Thank you for remembering that older mockup! I heartily agree, that I want that Source-level message for things like Encryption keys.

For failed-to-send Replies, tho, I still would like there to be a change in the badge's coloration—even if it and the line just go gray, with a simple bang-icon to the left of the bubble, and coral text below it. Fatigue and anxiety are very important factors, but so is ensuring all journalists understand and are aware of communications intended to go to a Source, that never made it.

The client is a communication device, first and foremost; and when communication fails, that feels like the most urgent thing to let users know about.

@sssoleileraaa
Copy link
Contributor Author

sounds good! still need to dip my toes in the ux repo didn't want to step on any toes over there :) so we currently have a client level top pane error bar that shows up with an error message when there is a network issue and a reply cannot be sent. it does not show up when a reply cannot be sent due to a missing submission key, which is an issue in my opinion. when a key is missing, I think we should show a top-level error message as soon as we find out. i'll discuss more during our future error-handling meeting.

as far as red badges go, i can see the how it pops out, but it might pop out more to not overuse that color for badges. i don't know but all these mockups sure are helpful, and i agree that the more eyes the better.

@eloquence
Copy link
Member

Yup, I agree. However, if that mockup were to be updated to include reply badges, you would see gray badges, which is part of what I'm saying should go

I agree the gray badges are potentially confusing, even with the current limited palette and certainly if we expand it. It might be interesting to experiment with translucency of the existing badge color as a way to communicate state. In some ways a "cannot decrypt" error is similar to the "sending" state for a reply -- IIRC it will retry decryption at least on every client restart and is not an ultimate failure in the same way that failed-to-send replies are.

@ninavizz
Copy link
Member

I believe this issue was in effect solved, by not yet implementing a rotation of colors for Reply badges?

I no longer see gray badges in my Client, and the urgent coral I believe is only for error states. This is where we last landed with all the colors to extend to rotating journalist badges.

@eloquence I think opacity is problematic, because it implies an active state for a thing. Like, I'm observing my reply trying to post right now in the Client, and the badge at 100% with the bubble and included text at 40%, feels broken.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants