Feedback communicates the result of user actions and system events. Every action a user takes in the Alius platform should produce clear, timely, and informative feedback.
Feedback Types
Success
- Confirms that an action completed successfully
- Use a success icon (checkmark) paired with a brief message
- Auto-dismiss after a reasonable duration (3-5 seconds) for non-critical successes
- Persistent for critical operations (e.g., “Firmware updated successfully”)
Error
- Indicates that an action failed or something went wrong
- Must explain the reason — “Something went wrong” is not acceptable
- Include the specific error, the likely cause, and a suggested fix or next step
- Distinguish between validation errors (inline, near the field) and system errors (page-level or modal)
- Provide actionable recovery options
Warning
- Alerts the user to a potential issue without blocking the action
- Use when an action has side effects or non-obvious consequences
- Include context about what might happen and why the user should pay attention
- Allow the user to proceed or cancel
Loading
- Indicates that the system is processing and the user should wait
- Use appropriate indicators: spinners for quick operations, progress bars for long operations
- Show skeleton screens for content areas that are loading
- Avoid blocking the entire UI when only a section is loading
- Provide estimated time or progress percentage when possible
Empty State
- Shown when a section has no content (no devices, no recent activity, no search results)
- Always include an illustration or icon, a brief explanation, and a call-to-action
- Help the user understand why it is empty and what they can do about it
- Examples: “No devices connected. Connect your first device to get started.”
Offline
- Indicates that the application has lost network connectivity
- Show a persistent banner or indicator until connectivity is restored
- Clearly distinguish offline state from error states
- Queue actions if possible and execute them when connectivity returns
Operation Confirmation
- Used before destructive or significant actions (delete, reset, overwrite)
- Clearly state what will happen
- Require explicit confirmation (not just “OK” — use specific verb buttons like “Delete”, “Reset”)
- For irreversible actions, consider requiring the user to type a confirmation
Undo
- Provides a way to reverse a recent action
- Show as a toast notification with an “Undo” button
- Available for a limited time window (5-10 seconds)
- Not all actions are reversible — do not show undo for irreversible operations
Feedback Principles
- Errors must explain the reason — generic error messages are unacceptable in an engineering platform
- Important operations show consequences — the user should understand what will happen before committing
- No vague copy — every feedback message should be specific, clear, and actionable
- Timely — feedback should appear immediately after the action, not with a delay
- Clear — the user should understand the feedback at a glance
- Recoverable — whenever possible, provide a path forward from error states
- Proportional — the intensity of feedback should match the importance of the event