https://github.com/OpenHands/agent-canvas/pull/726 - The error messages were updated to remove the red. • Grey theme styling for chat error banners (no red) • Retry button for "Unable to connect to server" errors • WebSocket`reconnect()`plumbing @millions-afternoon-47582

Why remove the red from errors?

It was deemed too garrish and alarming, making OpenHand's failure look worse, especially if it appears repeatedly. Makes the product look exceptionally broken.

To be fair, the whole background was red 🤔 Maybe there’s some other alternative, like, idk, thin margin, but that’s probably a silly thought

yeah I think we need a little red

an icon

Errors need to be clearly understood as errors. If they are appearing repeatedly then we fix the error source

Paul--do you have examples of other applications that show errors as normal text?

Add a Report Error button and system as a start. Maybe an error collection mechanism in that notification system idea that came up the other day

It's still unavoidable as an error. It's just not screaming in your eyes about it.

Just for your information: agent error, ie, error coming from the agent are in red. Are you taking care also of them?

Can you provide examples of what you mean? I haven't seen those in awhile.

You can check the video in this PR description. The problem i was trying to solve is that sometimes the error coming from the agent are obscurated and we don’t see them properly. Perhaps i should wait that you merge your Pr and do the changes in my PR accordingly https://github.com/OpenHands/agent-canvas/pull/711

@modern-fireman-99755 I left a comment on the PR. We now have three types of errors that can happen during a conversation, though they’re like, 2 big categories: • LLM blunders (that the agent will recover from on its own) ◦ AgentErrorEvent • conversation/server errors (that are real errors and require user attention) ◦ ConversationErrorEvent, ServerErrorEvent

@calm-artist-7206 I agree with you. This is also the reason I would like to wait before refactoring the PR. IMO: • LLM blunders: These should be displayed right in the conversation, as they are part of the chat history and don't block the user flow. • Conversation/Server errors: A banner above the chat box makes the most sense. However, the error must be readable and copyable so the user can easily paste it into an issue, for example. Regarding the color and style of the error: I did some quick research on how to display errors to enhance the user perspective. Without getting into overly complicated studies, a few blogs explain this well (here are a couple of them: ref_1, ref_2). Essentially: an error message should be placed directly next to the problem, using a distinct icon and clear text rather than relying on color alone. It must use friendly, human language that explains how to fix the mistake without blaming the user or wiping away their typed data. @breezy-kilobyte-39430 nit: Do we have a colorblind-friendly theme? It should be quick to add, right? Around 8–10% of men are colorblind (compared to only 0.5% of women).

Here's an updated sample, I have it in another branch I'm working on:

ref 1, ref 2

That was a fun read, thanks for the links! I love examples from real-world applications. I even used to hold a fairly large collection of fun screenshots - UX oopses from everywhere, from operating systems to random apps - it's hilarious what happens out there.

Here's an updated sample

Looks pretty nice to me. thank you!

we can run a test to see how well our app does, but it's getting close to being very colorblind friendly if it wasn't already.

I just asked an agent to go through the code and it gave some good feedback: • Backend connection status is only a small green/red/gray dot visually. It has an aria label, but sighted colorblind users still see mostly a dot with no visible “Connected/Disconnected” text. • Conversation status uses tiny dots for active/error/paused/unknown, with green and red as the primary visual distinction • In collapsed sidebar mode, the conversation row aria label is just the title/id, while the visible row is only the status dot. • Task startup status uses green/red/yellow dot colors only; WORKING intentionally hides the text badge, making the common state especially color-dependent • Key status uses the same success icon for set/unset and changes only color between success/danger • Diff colors are classic red/green inserted/removed backgrounds. Those colors have very low contrast against each other, roughly 1.1:1, and can collapse for red-green colorblind users

Also, @wooden-umbrella-84098, related to your earlier question, I did find this non-red error/info messages in Codex: