3

I'd like to have opinions to see things differently or to confirm that my view is better :)

Situation: We are developing a complicated information system (legal stuff) - lots of information, lots of form fields, lots of text etc. It is used only on monitors and laptops - no mobile devices nor pads. It is quite old and now we updated architectural part and with it we have to make changes in UI. There are about 3000-5000 users.

Ux logic problem: Our fullstack developer changed alert logic by himself and now we are having a huge discussion. We have three types of alerts: success (green), warning (yellow) and error (red). (red ones of course with validation error, etc.) Up until now we displayed all of them at the top of the screen - between menu bar and form. From now on red and yellow ones are still displayed there, but green ones he moved on snackbar witch are displayed at the bottom left corner. Picture is just an illustration, what kind of alerts I mean: enter image description here

He: He says he made this decision (by himself) cause the green ones do not contain important messages and this way there is less information on the upper area of the screen.

Secondly, he says that those three message types are not equivalent, cause green are not important and they only may be interesting to the user, but a user can live without them. Unlike red and yellow one witch user NEEDS to see.

He says that success alerts are like global messages which does not require the attention of the user as they do not prevent the use of the system.


Me: I can't agree with that and my argumentation is:

  1. red, yellow and green alerts are equivalent in the sense that they appear after a user action (when information is saved, deleted, changed or manipulated any other way). It means green ones are not random system messages, but they are followed by user actions.

  2. it means equal and similar elements/information should appear or displayed in the same place/area

  3. Green alerts are important, because user needs to have feedback if his actions are committed (success) or not. Otherwise, I have to recheck (for example, whether the workflow / procedure was saved/created etc.)

  4. If users are used to see all three alerts one place, why should you move just one, it conflicts consistency principle


Nielsen: Lastly, we both tried to argue based on Nielsen article, but it seems that we both understand it differently because after reading it I didn't change my mind nor did he. He made even new arguments from this article:

"Indicators  An indicator is a way of making a page element (be it content or part of the user interface) stand out to inform the user that there is something special about it that warrants the user’s attention. "

He emphasizes this part "...warrants the user’s attention..." eg red and yellow alerts. Green do not need user attention, user can use the system without noticing green ones.

"Notifications  Notifications are informational messages that alert the user of general occurrences within a system. Unlike validation, notifications may not be directly tied to user input or even to the user’s current activity in the system, but they usually inform the user of a change in the system state or of an event that may be of interest."

He emphasizes this part "...may not be directly tied to user input...".


To finish: I still feel that I have good arguments and it is not right to put success alerts to snackbar while other alerts are somewhere else, but I need some other opinions, maybe I see this wrongly or maybe somebody can give new "proofs" :) Nielsen article made it worse.

1
  • I'd like to have opinions: opinion-gathering questions are off-topic, check How to Ask
    – Luciano
    Mar 14, 2019 at 10:08

5 Answers 5

2

I agree with @simonlh's point, that the tradeoff is between consistency vs distraction.

At 3-5k, you've got quite a large user base - has anyone complained that the number of notifications is excessive or distracting? If there are no complaints, I would maximise for consistency - reduce the amount of cognitive load on the user.

What's more, if the notifications are all top right you can the advantage of ordering to imply time. From the UI elements you show, it looks like the notifications dismiss themselves on a timer? If there is ever a situation where multiple cards are displayed at the same time (for example, 1 success, 1 error), it would be more useful to stack them. enter image description here

2
  • 1
    Good point on the order implying time. Regardless of other reasons for keeping them on one spot versus separated, if your example is a use case it could be the argument that trumps all others.
    – mnearents
    Mar 14, 2019 at 20:18
  • Thanks @sharkonaut - but like you said, it all comes down to solving the larger problems! Mar 15, 2019 at 19:38
1

I see this as a discussion about either:

  • Being consistent (alerts should be in one place)
  • High speed (flow) by limiting disturbing elements (confirm should not be an alert)

To keep the perceived performance and productivity high we should consider how to keep perception Doherty Threshold and focus (attention) on the current task. Most probably after a commit the users want to continue on to their next task.

This is probably what the developer was trying to design for when they moved the confirmation to a less prominent place. Knowing that a message from a general direction is positive means they can be safely ignored. Still that doesn't solve the issue as any incoming message will disturb the user flow and require that users get into the habit of ignoring the message or have to concentrate on two spaces at once to either receive positive/negative. If the confirmation is visually insignificant this might also lead to change blindness.

Suggestion:

I would try to find some pattern to either integrate confirmation without needing an alert.

For instance using a loading indicator if the user has to wait for a commit. Or if it is a high frequency task include the loading inside the button and update the state without a confirmation message.

The best would be that the UI contextually updates without needing to display an alert. Optimistic UI's would even update the UI before the commit is completed, and only alert if the commit fails. This is often done by including some low-attention visual indicator on the changed item to indicate that it is currently being updated.

Ant.design loading indicator

Ant design: Loading button

Smashing magazine: True lies of optimistic UI

0

I'm working with your system, updating a law with just a few thousands of articles. And suddenly the system freezes.

Your developer knows that the system has to explain me what happened in the best possible way. That I can not upload more than a hundred articles per time. Because if there is no proper explanation up there, in a position with high visibility, I'm going to call the company and the company is going to call him.

He also knows that working with a computing machine is difficult, I need to be focused, whatever distracts my attention is harmful. And that notification bar/balloon/window is distracting, it is consuming my attention. Please, at least give an option to remove all those meaningless notifications.

I vote for the developer's approach. It prevents pointless phone-calls, it helps me finish my job faster and learn how to work with your system. It prioritizes in a better way important information over not so important information.

0

These messages serve the same functionality: giving users feedback on the system status. If they appear in 2 different places, it means that each time the user makes a change, they have to check two places on their screen (top and bottom) to assert that their changes went well or went wrong. They can't know in advance where to look, as it's exactly the point of these messages.

It's the reason why I think it makes for a bad user experience to have them appear in different locations.

To limit impact of green messages, which demand only a short attention span and do not require the user to take any action, I would make them disappear automatically after a few seconds (if it's not already the case).

Red and yellow warning messages, which require attention and action from the user, should stay until they are manually dismissed. Ideally, they should direct users to what they can do to fix the issue.

4
  • You could be totally right. But let me play devil's advocate: assuming both locations are equally prominent, couldn't the users learn that lower-left means success and upper-right means failure, such that they wouldn't even have to look anymore, but that the movement in their peripheral could be enough to inform them of the problem? (i.e. anything that appears on the left means success). Users, after all, can learn. I don't know the answer, just curious about your opinion.
    – mnearents
    Mar 14, 2019 at 20:16
  • We can (try to) train users for anything, that doesn't mean it's convenient and we should do it. It seems to me that it would increase the cognitive workload significantly to have 2 possible warning areas. Just the fact that they would need training means it won't be easy to grasp. Mar 15, 2019 at 10:57
  • Training doesn't necessarily mean something isn't easy to grasp. We had to be trained to swipe left and right to move from screen to screen on phones. Now it's second nature. Just an example. Long press, force touch, double tap, all things that had to be trained. Truth is unless the nature of our interactions is going to remain constant forever, then we'll always need to learn new and better ways. The way we interact with interfaces in 10 years will be vastly different than how we interact now which will require learning.
    – mnearents
    Mar 16, 2019 at 17:24
  • But I do agree with your statement "...doesn't mean...we should do it". You're right. It doesn't. But the fact that it's already implemented, and would cost time and money to change, I guess I'm saying no one knows if this is a situation where we should or should not do it, so probably testing and feedback is the only way to know. But I think in the UX world there's a bad connotation around creating things that users have to learn. Having to learn = always bad. But I don't think learning always equates to a bad experience. It's individual to each project.
    – mnearents
    Mar 16, 2019 at 17:38
0

In my opinion, you are both right and wrong at the same time. The true answer is it really just depends.

First, although arguments can be made for consistency, you don't actually know if one is more visible than the other until you run a usability test, observe users, or ask for feedback. The movement and contrasting color might make them equally prominent against what I assume is a light background. Is there a way you can collect some data?

Second, you're not dealing with conversion. It isn't an e-commerce application. So even if it takes time for users to learn, they can learn. Look at Apple, pretty much everything new they create is not user-friendly. Force touch, for example, is something that isn't obvious and is not very discoverable (there's no hint that it exists). But somehow we learn and then we glorify Apple for their creative genius. Perhaps the separation of success and failure alerts becomes part of the users' mental model: success lower left, failure upper right. The difference in position alone might give the user an understanding of the result using peripheral vision and not having to actually look at the alert. Versus having all the alerts in the top right corner, does the color and icon make it obvious enough that the user doesn't have to look to see? That's a good question for you to answer.

I'm not saying the system your developer created is learnable. Maybe it's not. I'm not saying I would have designed it that way. But until you have data from your system specifically, you two can argue heuristics and best practices all day long and won't get anywhere.

In the end, what is of greater importance than small usability issues is whether the application itself is actually solving people's problems. I tend to spend more of my time around the larger strategy and flows and whether these are serving actual real-world needs, than smaller feature interactions. Not that I am okay designing clunky systems, and if there is low-hanging fruit that can be improved, by all means, improve it. But if your app is old, and full of complex information and forms, odds are you have bigger issues to worry about (again, an assumption). Try looking at flows as a whole and making sure they match your users' natural workflow. A workflow mismatch is a much bigger issue than an individual feature.

Not the answer you're looking for? Browse other questions tagged or ask your own question.