Skip to content

Alert Specification DRAFT

Jump to bottom
Stefan Ivanov edited this page Jan 31, 2022 · 1 revision

Alert Specification

Contents

  1. Overview
  2. User Stories
  3. Functionality
  4. Test Scenarios
  5. Accessibility

Owned by

Team Name: Design and Web Development (DnD)

Developer:

Designer: Stefan Ivanov

Requires approval from

  • Simeon Simeonov | Date:
  • Stefan Ivanov | Date:

Signed off by

  • Product Owner: Radoslav Mirchev | Date:
  • Radoslav Karaivanov | Date:

Revision History

Version Users Date Notes
1 Stefan Ivanov Date 21 January 2022 First specification draft

1. Overview

The <igc-alert> component is primarily used for system messaging, push notifications, warning messages, and information. It shows alerts either inline see banner, or as an overlay see notification.

Acceptance criteria

  1. The alert component should represent a message or notification.
  2. The alert should be shown inline wrapped in a banner.
  3. The alert should be shown as an overlay wrapped in a notification.
  4. The alert component should support a rich template with icon, text, buttons, hrefs and more.
  5. The alert component should disappear automatically.
  6. The alert component should be able to prevent auto-hiding.

2. User Stories

Developer stories:

  • Story 1: As a developer, I want to be able to provide a way to inform a user about an application operation.
  • Story 2: As a developer, I want to be able to define content templates with text, icons, links, buttons etc., so that I can show elaborate errors, warnings, notifications, and other messages.
  • Story 3: As a developer, I want to be able to customize the appearance of the alert, so that it better fits the design language of my application.

End-user stories:

  • Story 1: As an end-user, I want to see a message notification about a certain operation, so that I can understand its implications.
  • Story 2: As an end-user, I expect that the alert does not hide other critical information, so that I have context about the message it displays.
  • Story 3: As an end-user, I want to be able to click a button, so that I can take action in accordance to the message delivered by the alert.
  • Story 4: As an end-user, I expect that the alert is styled in accordance to its message, so that I am well aware of the seriousness of the situation.
  • Story 5: As an end-user, I expect that the alert has visual elements such as an icon, so that I can get a clearer picture of the situation at hand.

3. Functionality

3.1. End-User Experience

The alert component displays a notification show to the user in various shapes e.g. as a simple message toast, as a message with action snackbar, inline as a banner or in an overlay as a notification.

Some examples of toasts:

3.2. Developer Experience

<igc-toast keepOpen="true">
Toast Message
</igc-toast>

3.3. API

Properties

You should be able to configure the igc-toast by setting its properties:

Name Description Type Default value Reflected
open Determines if the toast is opened. boolean false true
displayTime Sets the duration of time span in ms in which the toast will be visible. number 4000 false
keepOpen Sets whether the toast should close after the displayTime is over. boolean false true

Events

The igc-toast should emit the following events:

Open/Close?

Methods

The igc-toast exposes the following methods:

Name Description Arguments
show Displays the toast. -
hide Closes the toast. -

Slots

Name Description
(default) The toast content.

CSS Parts

Name Description
base The base wrapper of the toast.
message The toast message.

4. Test Scenarios

Automation

  • Scenario 1: Should change the toast display time correctly.
  • Scenario 2: Should change the toast keepOpen option correctly.

5. Accessibility

Roles:

Clone this wiki locally