UX Design - explore ways to handle multiple notifications on integration details page

[dongniwang]

This is a...

[x] Feature request
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Documentation issue or request

The problem

When there are multiple inline notifications (>5) appearing on the integration details page, the main content got pushed down below the fold.

Expected behavior

A better way to display these inline notifications on the page.

• Some kind of way to group the notifications so it's not being displayed in a flat list
• Let users know there are more than one notifications
• Have a control to expand/collapse the notification group
• Catch user attention that something needs to be done

Screenshot

Reference

See comments in #3637

[dongniwang]

Just adding a screenshot.

[dongniwang]

PF4 has a pattern for handling multiple notifications herehttps://github.com/patternfly/patternfly/issues/654

FYI @nding-anges @mcoker

[nding-anges]

@dongniwang @mcoker Thanks Dongni. I just have a concern about whether the Toast notification is suitable for this use case? I suppose that Toast notification is in charge of display message of global system on the overall situation. Inline notification points out an issue of a specific use case on one UI. Here, as the error message is addressed to an integration, it is better to display by Inline notification and be close to the relative item.

I just made a draft solution to have a discussion with you, see image below:

1. Adding a 'close' button on notification( there should be display maximum one notification on UI) ; 2. After the user close the notification, an Alert icon will display on the header while a constant occurrence of an error (same error should be display by the same message if it is technically possible)

3. onMouse over on Alert icon, a dropdown will show the detail messages. It could be display a list of message on dropdown. Refer to Openshift:

If the direction is good, I will continue to design more detail situation, please feel free to brainstorming ;-)

[dongniwang]

@nding-anges - Thanks for posting. Here are my thoughts:

• I agreed that it's not a use case for Toast Notification, and I'm not suggesting we should use toast notification here. I was referring to the concept of having a "two more unread" and "dismiss all" message.
• I like the idea of the close button. But not sure if limiting to only displaying one notification at all time is a good idea.
• I do like the idea of having a consistent error message (alert/warning icon) shown somewhere on the page, but not sure if the icon itself is enough or we need more help text. Also, since the "stopped" label there is also some kind of status indicator, maybe we can explore another location for displaying the alert/warning?

[nding-anges]

@dongniwang Thanks for the suggestions. It's a draft design and I will continue to do an iteration design in this direction.

[nding-anges]

@dongniwang @mcoker Hello everyone, I updated the design solution and I'd like to have a discussion with you, please find images below:

Another regarding the notification message: I notice that most of these massages have the same content since a configuration required status. Is that possible to display only one notification message if the configuration required status is continued? That will solve the problem fundamentally. Thanks~

[phantomjinx]

@nding-anges

I notice that most of these massages have the same content since a configuration required status. Is that possible to display only one notification message if the configuration required status is continued?

Each message is actually checking a different connection in the integration then returning the more generic message. Therefore, although the message is the same the underlying reason for it being flagged will be different. I have merged in an API change to the backend that actually delivers a more detailed message the references the specific differences. However, no UI picks this up yet. Maybe, that is something that could be factored in, eg. details button + slide-out panel.

On the other hand, knowing that some part of the integration is stale and editing the integration would solve it is probably sufficient for the user to be told only once. Therefore, maybe at the UI-level despite receiving several notifications, a de-duplication function could be added so only one is displayed (maybe even with a number in brackets to suggest there are (n) number of these messages)?

[dongniwang]

@nding-anges - Thanks for the update! Is it possible to move the designs into InVision? It would be easier to review and provide feedback that way. Thank you.

[nding-anges]

@phantomjinx Thanks for explaining the context of notification. That is really helpful and now I understand very well where the problem is. Could you please give me an example of phrase that will show on the notification message after you changed API and delivered more detail? I will integrate it into the UI design.

Another question: The new design can handle multiple notifications without quota, and the current strategy is to display message one by one. Do you think that will have a huge quantity of the message, like 50，100 or even more? If so, we will consider the acceptability on UI level and also from the user standpoint. Thus, I think that 'a number in brackets to suggest there are (n) number of these messages' is a good idea for a de-duplication function.

[nding-anges]

@dongniwang I uploaded the design on Invision please have a look: https://redhat.invisionapp.com/share/J3P909MXTHQ#/332778522_Default_Status

[phantomjinx]

@nding-anges

So this is an example of a detail message that is produced for a SYNDESIS011, ie. 'A connection associated...' message:

PostgresDB:Connection$configured-properties
=> '{password=»ENC:3f7a6a025bb0e953d8cbe0cba59328fc55f58732e9a037a13f4651ca ...'
=> '{schema=sampledb2, password=»ENC:3f7a6a025bb0e953d8cbe0cba59328fc55f587 ...'

1. The syntax starts with the connection that has the difference and its specific property;
2. What follows is 2 bullet points representing the 2 differing values. In this case, configured-properties has an extra 'schema' property with a value of 'sampledb2'. These bullets are truncated to about 70 characters for the sake of brevity and communication.

To reiterate previous conversations, it was felt that showing this detail was something to be avoided in preference to the more generic messages. Therefore, the placement of this detail as detail hidden behind a button.

The detail property is only used currently for SYNDESIS011 & SYNDESIS012. However, that doesn't mean more messages could take advantage of it in the future. Obviously, their syntax may vary.

[dongniwang]

@gashcrumb @phantomjinx - do you know if we would have error messages (instead of warning messages) on this integration details page? e.g. what kind of message do we display when users are not able to publish an integration (and let's say they stay on this details page when the publishing is in progress)?

[gashcrumb]

I think there's two possibilities, one is if the API request errors out. That'd be reported via toast notification. The second case would be a problem in the publishing process, that's reported eventually via an error field on the integration object. I think we may not surface that error on the detail page at all as I think about it, it used to be the field that would drive a red x on the integration list page.

…

On Tue, Nov 27, 2018, 11:51 AM Dongni (Iris) Wang ***@***.*** wrote: @gashcrumb <https://github.com/gashcrumb> @phantomjinx <https://github.com/phantomjinx> - do you know if we would have error messages (instead of warning messages) on this integration details page? e.g. what kind of message do we display when users are not able to publish an integration (and let's say they stay on this details page when the publishing is in progress)? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3648 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAVdrIWm3jTEPJEnH8t0z4tGoNW-Z75yks5uzW17gaJpZM4W0Xsw> .

[nding-anges]

@dongniwang @phantomjinx @gashcrumb

So this is an example of a detail message that is produced for a SYNDESIS011, ie. 'A connection associated...' message:
PostgresDB:Connection$configured-properties
=> '{password=»ENC:3f7a6a025bb0e953d8cbe0cba59328fc55f58732e9a037a13f4651ca ...'
=> '{schema=sampledb2, password=»ENC:3f7a6a025bb0e953d8cbe0cba59328fc55f587 ...'

The syntax starts with the connection that has the difference and its specific property;
What follows is 2 bullet points representing the 2 differing values. In this case, configured-properties has an extra 'schema' property with a value of 'sampledb2'. These bullets are truncated to about 70 characters for the sake of brevity and communication.

Regarding the example above, it is clear that providing more detail info on the Notification is more helpful and makes more sense to the user than a generic message. Therefore, Inline Notification has a limitation of characters and truncated policy. Maybe, it is not suitable for display more detailed information. Also, It will be annoying on the header with too much characters. I think that we could explore another design solution for that.

P.S The message should be definitely re-wrote from the user stand point and make more readable.We will show an original massage directly from the backend on the UI leve for sure.

[dongniwang]

Re the detail message in the above comment, I don't think we want to expose any of the password or sensitive information.

And from a user point of view, what's the most important information from this message? I'm assuming "PostgresDB" is the most important part of the information.

So this is an example of a detail message that is produced for a SYNDESIS011, ie. 'A connection associated...' message:
PostgresDB:Connection$configured-properties
=> '{password=»ENC:3f7a6a025bb0e953d8cbe0cba59328fc55f58732e9a037a13f4651ca ...'
=> '{schema=sampledb2, password=»ENC:3f7a6a025bb0e953d8cbe0cba59328fc55f587 ...'

And what would be the immediate action they need to perform? Wondering if we can somehow aggregate this type of information into one message (maybe try the [n] number of message method), but allow users to see more. And we list out the connection names (based on the detailed message @phantomjinx mentioned above).

[nding-anges]

@dongniwang
I agreed that we will not expose any of the password or sensitive information on the message, and I'm not suggesting we will show an original message directly from the backend. The message should be definitely re-wrote from the user standpoint and make more readable.

From the example above, we saw clearly that the message will contain two or more aspects:

• indicated which connection has a problem ;
• indicated some specific property of the connection.
• this properties maybe has an extra 'schema' property with a value..etc

The syntax may vary...

Showing all these detail info will be more helpful to the user than a single message. I was wondering if we just show a type of information into one message ( with different connection names + the[n] number of massage), we will still need to display the detail somewhere on the UI and allow the user to check.

So I suggest to make enhancement design or explore another design solution.
I suppose that we could display just one Inline notification on the header and indicated [n] the number of messages it will have. And the user could click and check all message list with more detail info on the Tab of 'Metric' or it could be organized in a new Tab on the content area below.
@phantomjinx @gashcrumb

[nding-anges]

Hi, @dongniwang @amysueg I made a new design proposal after our discussion on UX meeting last week.

Considering our short-term goal for the improvement of Multiple notifications, I suppose that we could only have two status of the message list: 1) collapsed as a default status; 2) expanding status to show all message. That is good enough to meet our first goal:

• providing some kind of way to group the notifications so it's not being displayed in a flat list
• Let users know there are more than one notifications
• Have a control to expand/collapse the notification group
• Catch user attention that something needs to be done

So it is not necessary to have ‘a Close individual message’ and Dismiss All button as in previous design. For the reasons below:

1. When the user clicks ‘X’ for closing a message, the message will probably appear again while re-enter or refresh the page，because the warning status of required configuration will still be continuing.

2. If the user clicks ‘Dismiss All’ and all messages are hidden, in case of some new notifications are delivered by refreshing the page, that will be some new notifications are display on expanding list and some of them are hiding. That is complicated and confusing for the user.

Thus, I think only keeping these two status of display notification will both simplifier the logic of display and the user’s behavior. Here is the link: https://redhat.invisionapp.com/share/J3P909MXTHQ#/334617056_Noti-Intro_New
Please have a look and feel free to leave your comments . Thanks!

[stale]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!