🎨 Palette: [UX improvement] - Semantic error colors in TUI footer - #74
🎨 Palette: [UX improvement] - Semantic error colors in TUI footer#74omsingh02 wants to merge 1 commit into
Conversation
- Fixed TUI footer logic to explicitly detect error states (e.g., "[!]" or "error") and display them with semantic red colors instead of defaulting to the success/listening styles (cyan/green). - Added critical UX learning log entry to `.Jules/palette.md`. Co-authored-by: omsingh02 <215121080+omsingh02@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
💡 What:
Updated the TUI
_make_footermethod to explicitly check for error states (presence of[!orerror). When an error state is detected, the indicator dot and the panel's border style change to a semantic red color. Normal states (listening, processing) retain their previous cyan, yellow, and green colors.🎯 Why:
Terminal user interfaces rely heavily on color to communicate state. Previously, error statuses (which are often prefixed with
[!]) were falling back to the default "success" style (green dot, cyan border) because they didn't match the specific string matches for "Listening" or "Processing". This created a visually confusing and contradictory experience for users trying to diagnose issues. Using a clear semantic error color ensures users notice immediately when something has gone wrong.📸 Before/After:
Before: Error states like
[!] Connection errorshowed a bright green●and cyan panel border.After: Error states show a bold red
●and a red panel border, making them immediately obvious as failures.♿ Accessibility:
While primarily a visual polish for terminal users, relying on semantic colors appropriately (using standard red for errors) aligns with established UX paradigms, reducing cognitive load when parsing the terminal's state at a glance.
PR created automatically by Jules for task 1074980237568893145 started by @omsingh02