Magento2: Usability issues with error/notice/success messages

[erikhansen]

This issue covers what I consider to be two major usability issues with messages:

1. Error message hides after 5 seconds

When error messages are displayed on the frontend, they disappear after 5 seconds (this is controlled by the onHiddenChange method in app/code/Magento/Ui/view/frontend/web/js/view/messages.js). If a user is not paying attention, if they are a slow reader, or if the error message is long, they message may disappear before they read the entire message. My recommendation would be to NOT hide the message but to leave it on the page until the user takes some other action that causes the message to be hidden.

Here is an example of an error message that will hide after 5 seconds:

@mttjohnson did some digging into what happens when there is an error with a payment method in the checkout process. It looks like the payment methods use the Magento_Ui/js/modal/alert component to display an alert-style modal that doesn't go away until the user closes it. The red error message I displayed above occurs when there is an exception thrown by Magento when progressing from Shipping > Billing, so it may not warrant an alert style popup, but it should at least persist on the page and not hide. This is what the alert-style popup looks like:

2. Error messages may display outside of current viewport

If a user is a on a small screen device, there are many situations where they will never see an error message. For example, if they're on the "Shipping" step of the checkout process and an error message is added, they may not see the error message get added to the top of the page. My suggestion would be to either smooth scroll the user up to the error message, display the error message next to the button they used to submit, or come up with a notification system that display notifications on top of all content.

[MomotenkoNatalia]

Hi @erikhansen
We have created task for our Design team to refine a pattern of messages from your proposals - Internal ticket MAGETWO-47763

Thanks for sharing your ideas!

[tkacheva]

Implementation task MAGETWO-54422

[ErvinLlojku]

Hello,

Please kindfully consider updating the error messages for the swatch elements. It is the same usability issue as described above. Should be reconsidered the way the styles are applyied to the swatch inputs.

Thank you!

[tkacheva]

@ErvinLlojku could you provide more details about swatch error messages please. I suggest to open separate ticket for this

[blizam]

This is huge I think... especially on credit card processing errors... if a card is declined in any of the PayPal checkout options there's a good chance the error is outside of the users' window (above) and because the error clears so quickly (it hides immediately if you put your mouse on it; or after 5 seconds) the user will quite often miss it (I know I did in testing) and therefore have no idea if their payment went through or what they should do next.

The error messages should persist on checkout and not auto-hide

[erikhansen]

@blizam Yes, I consider this a serious usability issue and I hope Magento addresses it in the next release.

[adragus-inviqa]

Hijacking this thread to express my facepalming: I don't know whose idea was to hide the messages after 5 seconds, but it's a darn bad decision.

[piotrekkaminski]

Thank you for your submission.

We recently made some changes to the way we process GitHub submissions to more quickly identify and respond to core code issues.

Feature Requests and Improvements should now be submitted to the new Magento 2 Feature Requests and Improvements forum (see details here).

We are closing this GitHub ticket and have moved your request to the new forum.

[erikhansen]

@MomotenkoNatalia I posted a comment to you in the forums: https://community.magento.com/t5/Magento-2-Feature-Requests-and/Usability-issues-with-error-notice-success-messages/idc-p/53406#M2548

[Sanfam]

@MomotenkoNatalia , I, much like @erikhansen , am eager to know where Magento stands on this issue. I've posted a comment in the forum but noticed that Magento has been silent on the topic since August 2016.

[tuyennn]

I found no go with this issue, no way to fix this after trying so much Temporary fixes

[cykirsch]

@magento-engcom-team I don't see any referenced commits. So no specific changes were made, you just noticed it was fixed in 2.3? Can you figure out what the difference is and backport to 2.2 and 2.1? This is really important and several people in both this thread and in the forum thread have made excellent points describing its importance.

[cykirsch]

@MomotenkoNatalia

[erikhansen]

I patched magento/module-ui using the composer-patches plugin to show the error message for 30 seconds, and scroll it into view.

Here are the contents of the patch:

From b56d22d93e24b45a2ecbcf9f849502411cb99829 Mon Sep 17 00:00:00 2001
From: Erik Hansen
Date: Wed, 16 Nov 2016 16:50:31 -0600
Subject: [PATCH] Show error message for 30 seconds and scroll it into view

---
 view/frontend/web/js/view/messages.js | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/view/frontend/web/js/view/messages.js b/view/frontend/web/js/view/messages.js
index e6d3bc8..ddb9a99 100644
--- a/view/frontend/web/js/view/messages.js
+++ b/view/frontend/web/js/view/messages.js
@@ -50,7 +50,12 @@ define([
             if (isHidden) {
                 setTimeout(function () {
                     $(self.selector).hide('blind', {}, 500)
-                }, 5000);
+                }, 30000);
+                try {
+                    $(self.selector)[0].scrollIntoView();
+                } catch (error) {
+                    // Do nothing
+                }
             }
         }
     });
-- 
2.8.1

[djview]

If somebody doesn't want to run the composer patch above, you can make this change by editing the js file directly by going to vendor/magento/module-ui/view/frontend/web/js/view/messages.js and editing starting at line 67. Delete the following code:

if (isHidden) {
setTimeout(function () {
$(self.selector).hide('blind', {}, 500);
}, 5000);
}

And replace it with:

        if (isHidden) {
             setTimeout(function () {
                 $(self.selector).hide('blind', {}, 500);
            }, 30000);
            try {
                $(self.selector)[0].scrollIntoView();
            } catch (error) {
                // Do nothing
            }
         }

[vovayatsyuk]

@erikhansen, thanks for your patch.

By the way, I'm interested why the following code having a place in view/messages.js:

        isVisible: function () {
            return this.isHidden(this.messageContainer.hasMessages());
        },

The problem is that this method always returns js object instead of boolean value and changes isHidden value to true when error messages found.

I don't know, but for me, it looks like an accident error.

It was added a long time ago without any explanation.

p.s. If we change this method as follows, messages will not we hidden automatically anymore:

        isVisible: function () {
            return this.messageContainer.hasMessages();
        },

[ywsw]

@djview @erikhansen thank you so much for your fix. It definitely works for me - only that the page scrolls up to the error notice on the first error only. For any consecutive errors, the page does not scroll back to the error (though the error notice does still last longer - if the user decides to scroll back up to the top). Would you be able to advise how this can be fixed?

[dawhoo]

@djview @erikhansen thank you so much for your fix. It definitely works for me - only that the page scrolls up to the error notice on the first error only. For any consecutive errors, the page does not scroll back to the error (though the error notice does still last longer - if the user decides to scroll back up to the top). Would you be able to advise how this can be fixed?

Try this:

if (isHidden) { setTimeout(function () { $(self.selector).hide('blind', {}, 500); }, 30000); try { $(self.selector)[0].scrollIntoView(alignToTop); } catch (error) { // Do nothing } }

It seems to have worked for me.

[avra911]

Maybe

 $("html, body").animate({scrollTop: 0}, "slow");

works better than

$(self.selector)[0].scrollIntoView();

for consecutive errors.

[przmak]

This is still not fixed, my messages are dispersing, 4 years a show success/error message functionality does not work.... how hard can that be?

[junnhouse]

This fixed only displaying on Safari. Chrome and Firefox is not working