Conversation
✅ Deploy Preview for industrial-experience ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Summary of ChangesHello @flxlst09, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces a new blog post that serves as a comprehensive guide to effective messaging and feedback within applications. The post aims to clarify the appropriate use cases for various UI components, moving beyond the limitations of simple toast notifications to enhance user experience through timely, clear, and contextual communication. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a new blog post on messaging and feedback patterns, which is a valuable addition to the documentation. The post is well-structured and provides clear guidance on when to use different messaging components. I've added several comments to align the new markdown file with the repository's documentation style guide, addressing minor issues in formatting and grammar. The other changes, including the new SVG images and the changelog update, look good.
tokyojen
left a comment
tokyojen
left a comment
There was a problem hiding this comment.
As im away for a week, I will go ahead and approve so I dont need to approve again.
MaryZab
left a comment
MaryZab
left a comment
There was a problem hiding this comment.
Hi @flxlst09,
I really like the structure and clarity of your blog post, the flow is intuitive, and the examples make the content easy to digest.
While cheking the content of released design patterns, I noticed one example that felt a bit “overtoasted” (https://www.figma.com/design/OHbtNe9ZP7s3KT1r5hUypI/UX-Design-Patterns?node-id=543-40944&t=kbSKBUDgHtqLsl5Y-1). It would be good to remove it from our content, sicne it contradicts to the blogpost content.
Best regards,
Ryna
kathrinschalber
left a comment
kathrinschalber
left a comment
There was a problem hiding this comment.
A few suggestions :)
| - Within a data table, showing a message about filtering results. | ||
| - Inside a specific widget, providing status updates. | ||
|
|
||
| ### Banner: For persistent, system-wide or page-specific messages |
There was a problem hiding this comment.
Not sure if I would go with "banner" since our component is called message bar or simply go with our component name directly
|
|
||
|  | ||
|
|
||
| [Toast](/docs/components/toast/guide) notifications are quick, non-intrusive pop-ups that provide simple feedback on a user action. They are excellent for immediate low-priority confirmations, e.g. a successful deletion. |
There was a problem hiding this comment.
| [Toast](/docs/components/toast/guide) notifications are quick, non-intrusive pop-ups that provide simple feedback on a user action. They are excellent for immediate low-priority confirmations, e.g. a successful deletion. | |
| [Toasts](/docs/components/toast/guide) are quick, non-intrusive pop-ups that provide simple feedback on a user action. They are excellent for immediate low-priority confirmations, e.g. a successful deletion. |
I would stick to simply toasts
|
|
||
| <strong>When to use it:</strong> For immediate and highly contextual feedback related to user [input fields](/docs/components/forms-validation/guide), direct feedback texts are the recommended choice. These messages appear below the input field. | ||
|
|
||
| <strong>Why it's better than a toast:</strong> Input field feedback is directly tied to the user's action. It helps users correct errors and prevents frustration. A toast would be too far removed from the input field to be effective here. |
There was a problem hiding this comment.
Please check the document for the right apastrophes (' are the wrong ones)
There was a problem hiding this comment.
I really like the idea of using a "sketchy" font <3 How about adding a "planned" badge below the title directly on the image, to make it even clearer?
|
|
||
|  | ||
|
|
||
| <strong>When to use it:</strong> Banners are ideal for important, non-blocking messages that need to persist until dismissed or resolved. These messages can be system-wide (affecting the entire application) or page-specific (relevant to a particular view). In our design system the [message bar](/docs/components/messagebar/code) component is used for banner notifications. See our UX writing section on [time-related messages](/docs/guidelines/language/writing-style-guide-getting-started). |
There was a problem hiding this comment.
The UX Writing link isn't really connected in any way to the rest of the paragraph. What's the link to have them here?
| # When to use what | ||
|
|
||
| We already offer a set of components designed to handle various messaging needs. Let's explore the alternatives to toast messages and understand when to use each one from contextual feedback to required decision making. | ||
|
|
There was a problem hiding this comment.
Maybe a TL;DR would be nice here with a table or a decision tree? 🤔
| Alternative | When to use | Why it's better than a toast |
|---|---|---|
| Input field helper texts | Immediate, contextual validation | Aligns with the Law of Proximity |
Otherwise it's difficult to choose the correct pattern due to its level of detail
| Examples: | ||
|
|
||
| - Confirming a permanent deletion. | ||
| - Alerting the user to a unsaved changes before navigating away. |
There was a problem hiding this comment.
| - Alerting the user to a unsaved changes before navigating away. | |
| - Alerting the user about unsaved changes before navigating away. |
|
|
||
| Users might miss a critical message or need to refer back to past notifications. A dedicated notification management provides a persistent record of important events and messages. | ||
|
|
||
| <strong>When to use it:</strong> This is particularly valuable for applications where: |
There was a problem hiding this comment.
in my opinion, "particularly valuable" exaggerates a bit its necessity over its complexity and user value
| - "Password too short (minimum 8 characters)." | ||
| - "Required field." | ||
|
|
||
| ### Inline notification: Feedback within components (planned) |
There was a problem hiding this comment.
Not a feedback directly related to your post but to the idea of having a new component:
I asked copilot to critically review the guideline, and in favor of Jakob's Law (user prefers familiar patterns) where users are familiar with the message bar, it violates aesthetic-usability consistency. Hence, same functionality and behavioral idea with different style.
|
|
||
| We already offer a set of components designed to handle various messaging needs. Let's explore the alternatives to toast messages and understand when to use each one from contextual feedback to required decision making. | ||
|
|
||
| ### Input field feedback texts: Immediate, contextual validation |
There was a problem hiding this comment.
Is there any option to shorten the headings? They make the toc on the right a bit difficult to read
5 participants
💡 What is the current behavior?
No guidance between different messaging components
🆕 What is the new behavior?
Blogpost on when to use which messaging component