Notification Balloon
Implementation: Notifications
Related: Top-Level Notifications (Balloons)
Notification balloons inform users of the events or system states related to a project or IDE.

There are two types of notification balloons:
Suggestion notifications show the recommended action as a noticeable button. Use to suggest an automatic configuration for a project or an IDE, or to ask for user input.
Timeline notifications show useful actions as links. Use for showing results of long processes, automatic configuration, or actions without context.
These types appear in different sections of the Notifications tool window:

Use a timeline notification.

Use a timeline notification when an action was called from a context that is already closed, like a dialog or a popup.

Use a timeline notification when the project or IDE settings were automatically configured, and the user might need to check the changes.

Use a suggestion notification to promote an action for project or IDE configuration when not taking this action might lead to less optimal functioning or errors.

Use a suggestion notification to ask the user for an additional input or action that is not connected to their own workflows.

Sticky notifications stay on screen until the user clicks any of its actions or closes it. By default, use this behavior for suggestion notifications.
Timed notifications stay on screen for 10 seconds and then hide. By default, use this behavior for timeline notifications.
Change the default behavior if it makes sense in a particular use case.
Use to inform of a critical event or state that might disrupt the user experience.

Use in case an event or state might slow down the user's work or require an action to fix the project or IDE settings.

Use in all other cases.

When possible, use a plugin or functionality icon instead of the Info icon. This helps identifing the source of the notification quicker.

Write short and clear as notifications have limited space and may appear for a short time.
Use sentence case for both the title and the body.
Follow the punctuation rules.
Describe the event and the context in which it occurred. The context could be the name of a plugin, library, or functionality.
Provide the details on the event or system state to help users decide what to do next. Consider answering these questions:
What was the cause of this state?
What are the consequences?
What is affected: files, libraries, versions, plugins, etc.?
Use only the title when it is short and fits in one line.

Use only the body text when it fits in two lines and the title would duplicate its meaning.
Correct

Incorrect

Only the first two lines of the body text are visible by default, the rest is shown when expanded. Place the most important information in the beginning of the body text so it is visible by default.

Add actions to help users take the next steps: fix a problem, view relevant information, configure settings, etc.
The preferable number of actions is two, as it is easier for the user to choose. If more than two actions are useful, place the most likely to be used first, and hide the others under the More dropdown:

If the notification reports an error or warning, always provide an action to help users fix the problem:

If no actions are available, provide more details in the body text: how to fix or what was the cause.
Correct

Incorrect

If the notification is informational, and there is a possibility it might appear too often, add the Don’t show again action:

Use sentence capitalization for all actions in notification balloons.
Each notification balloon belongs to a group. Groups can be seen in Settings | Appearance & Behavior | Notifications.
To name a notification group, follow these rules:
Name the group with an ending to the phrase "Notifications in this group notify the user about…". Examples: Automatic indent detection, Content root duplicates.
If a name about a particular process or event cannot be given, use the name of a subsystem or plugin. Examples: HTTP Client, Power Save Mode.
When a group contains notifications about errors or problems, do not use a verb. Example: Debugger errors, not Debugger errors found.
Do not use words "notification" or "group". They are implied from the settings context.
Thanks for your feedback!