Success Alerts in Record App

[jrchudy]

Background

The current implementation of record app, shows success alerts when a pure and binary table has records added to it ("Link records" was used). Other actions on record app that modify the contents of the page don't show an alert. Those actions include:

• related table - "Add records"
  • refresh content on record page after create succeeds and page is focused
  • can show alert when this content is updated
• related table - "Edit"
  • refresh content on record page edit create succeeds and page is focused
  • can show alert when this content is updated
• main record - "Edit"
  • changes current record page to recordedit and shows that record page again after completing the edit
• related table - "Bulk edit"
  • changes current record page and shows resultset view
  • issue Rob asked about for having a "Back" button to go back to the record page that initiated this workflow

This behavior to show an alert is removed in issue #2273 to be consistent with what we are currently doing for these other actions.

Task

This issue is for improving the "alerts" on record app to communicate changes more accurately when a user uses the actions on record page that "refresh" content for the user. The content that is refreshed happens "silently" with spinners on the sections that are updated but could easily be missed.

The alert should include information about:

• which related table was updated
  • like the reference.displayname that was used in the success alert for P&B before
• how many rows were added (or updated)
• If an alert for the current related table is still on the page, that one should be updated (increment/decrement count) instead of adding another alert.

Alerts should be added when the page is focused again and we are "fetching" data. This happens for

• "Add records"
• single edit for a row in a related table
• Should we change the alert if fetching the data fails?
  • maybe change to a warning alert (yellow instead of green) and suggest refreshing the page

Other UX changes

If we have multiple alerts on the page, this can eventually change the main content area to be very small making it hard to interact with the app unless the user clears the alerts. We need to explore the following:

• How can we stack/collapse alerts?
  • should they stack by default? Or should we provide a mechanism to collapse them all into a "stack"?
• if collapsed, how should we communicate how many there are?
  • show a notification circle with a number in it for the total number of alerts visible
• Provide a way to "Clear all Alerts"?
  • should we have an option to clear only success alerts?
• spacing for alerts can be reduced
  • reduce padding in the alert itself
  • reduce white space in between alerts

other pages/places

We have other pages where content can be added/updated where the main page opens a tab and then refreshes then content when focused again. These places include:

• the Recordset page when "Create" is clicked
• The edit button for a row on recordset page
• "Create new" in a recordset modal
  • when doing "Link records" for pure and binary
  • foreign key modal popup
  • modal picker in a facet when clicking "Show Details"

[KenyShah24]

Here are the different UI approaches we can implement to enhance how we convey messages to users:

UI Options:

1. Toast Alert:
   A small, non-intrusive toast notification at the top-right or bottom-right of the screen.

2. Fixed Notification Bar:
   A persistent notification bar at the top of the page, similar to the current setup for general alerts.

Toast notifications are commonly used in apps with real-time updates, but applications like Gmail, Netflix, and Amazon tend to use top-fixed, dismissible, or auto-fading alerts, making it a widely adopted practice. Below are some UI examples for displaying global alerts:

Alert with Title on Top:

Alert Highlighting Important Table Updates:

Content Example:
"Data for [Table Name] has been successfully updated. [X] new rows have been added."

UX Considerations:

1. Incremental Alerts:

• Instead of stacking multiple alerts for the same table updates, we could consolidate them, e.g.,
  "Data for [Table Name] has been updated: [X] new rows added, [Y] rows modified."

2. Collapsible Alerts:

• Another approach could be collapsible alerts that append updates for the same table, allowing users to expand the details as needed.

For Color/Visuals we can use standard badge background: Green for successful updates, yellow for warnings, red for errors. But with either dismissible, collapsible or undo/retry options if needed per what kind of scenario we are implementing it on (For eg. Add records, link/unlink records, edit)

[KenyShah24]

Here are the solutions we discussed and how they address the two main concerns: (1) avoiding content shift, and (2) not reducing the workspace.

1. Grouping alerts into a collapsible alert:

• Partially solves the space issue by reducing the space taken by multiple individual alerts.
• However, it might cause content to shift when the alerts are expanded.
• Additionally, presenting a large amount of information at once may overwhelm users, as they might not want to read all the details at once.

2. Adding a "Delete All" option:

• This addresses the inconvenience of having to manually close each alert individually.
• However, it doesn't solve the main issue of reducing workspace or preventing content shift.

3. Fade-away stacked alerts:

• This solution fully addresses both concerns.
• The alerts will appear temporarily, without shifting or shrinking the content, as they will float above the page (using a higher z-index).
• We can limit the number of visible alerts to 3 at a time, with the most recent ones at the top.
• Alerts will disappear after a set timeout (e.g., 2 seconds), ensuring minimal interruption to the user’s workspace.

4. Having a 'Donot notify me' option to suppress alerts:

• Users who find alerts distracting/unnecessary can opt out of alerts allowing them to focus better which will again deal with both of the main concern.
• With a config variable defined to set and disable these success alerts.
• Question: Will there be any harm in doing this?

[KenyShah24]

--Collapsible Alerts Design Options--

We have explored several designs for collapsible alerts to handle success messages effectively. Below are the approaches and corresponding visuals:

-Current Implementation-

1. Collapsible Alerts with Show More/Less Option:

2. Collapsible Alerts with Arrow Option:

Close State:

Open State:

3. Collapsible Alerts with Bullet Points:

4. Collapsible Alerts without the Success Title:

--Different Styles for the Alert Message--

• We can try different colors which looks consistent and more prominent to make this message highlighted for the important information to the user.

Style1:

Grid Style (Better Readability):

Wrapping message when table name is long:

--Message Formations and Placements of Words--

1. Action First: [14:02] Successfully linked 10 records in accommodation_image table
2. Number of Records Highlighted: [14:00] 10 records in accommodation_image table have been successfully linked.
3. Highlight the action first: [14:00] Linked 10 records to the accommodation_image table successfully.
4. Short and to the point: [14:00] 10 records linked in accommodation_image table.
5. Structured format for logs or technical reports: [14:00] Action: Linked | Records: 10 | Table: accommodation_image

[KenyShah24]

This alert will display upon successful completion of user actions such as link, unlink, add, and single edit.
(Note: This will not appear for bulk-edit, bulk-delete actions, or for delete actions, as delete has its own summary alert.)

Here are some design improvements for collapsible alerts, as discussed:

1. Showing more/less option with title :

2. Showing more/less option without title:

3. Showing collapse arrow :

--Few success alert title options that can accommodate all the success actions are:

1. Action Completed
2. Successfully Updated
3. Update Successful
4. Records Updated Successfully
5. Action Completed Successfully