If there are several status and/or error messages shown on the same page, they are often not in any reasonable order. The order messages are thrown is sometimes not the order the processes logically take place. This is especially true, when other modules plug in via a hook and throw additional messages.

This usability problem is especially severe when there are both status and error messages: First the status messages are bundled to a list, then the bundle of error messages follows separately. While this looks pretty and clean, it would often make a lot more sense to have the messages in a logical ordering.

A good example is the admin/build/modules page. Just take a look at the enclosed picture and you see what I mean. This is really confusing!

To fix this I propose:

  • To add a weight key to drupal_set_message(), so messages can be logically ordered.
  • To only bundle status messages with the same weight to a list, to avoid a logical connection being suggested that doesn't exist. Messages with different weights should be displayed one by one.
  • Not to keep status, warning, and error messages together, but to line them up intermixed.

Think this is a usability bug to be fixed. I'm waiting for some input, before supplying a patch.

Files: 
CommentFileSizeAuthor
#1 unordered messages.png23.3 KBPancho

Comments

Pancho’s picture

FileSize
23.3 KB

Forgot the picture...

The expected order would have been:

  • STATUS: The configuration options have been saved.
  • STATUS: Database tables for the Copyright module have been successfully installed. (inserted by a module's _install hook)
  • ERROR: Inserting standard licenses failed (inserted by a module's _install hook)
  • WARNING: No information is available about [...] can take a long time, so please be patient. (inserted by update_status module)

The first message could be given a weight of -10 (or even -100) to make sure it is always the first message.
The last message could be given a weight of 10 (or even 100) to make sure it is shown after more contextual messages.

Pancho’s picture

Version: 6.x-dev » 7.x-dev

Moving this to D7 queue

Sutharsan’s picture

Component: base system » usability

Moving all usability issues to Drupal - component usability.

gzfelix’s picture

Component: usability » base system

If adding a $weight, does it add another layer of complexity to drupal_set_message?
For usability, a message related to a specific widget on the page should actually be displayed alongside a widget on the page, such as beside a text field or a select list. However, the current drupal_set_message is not able to do so. If implementing $weight, the order of messages is going to depend on an arbitrary number, which is a bad solution.

Current drupal_set_message stores messages in a queue, so messages are shown first-come-first-serve. Unless we plan to get the call stack to maintain a certain order of the messages, I don't think the issue is going to be resolved.

yoroy’s picture

Version: 7.x-dev » 8.x-dev
Issue tags: +Usability

From a ux point of view, I'd expect messages to be sorted on cardinality: errors first, then warnings, then status.
Currently not the case:

webstandards’s picture

Issue summary: View changes
Issue tags: +accessibility

Tagging this accessibility.
We got dinged on WCAG Accessibility testing for "the list of errors are wrongly not in the same order as the order of the fields". In testing we found users disoriented by the seemingly random sequence of the errors in relation of the sequence of the form (which describes the general Usability problem) however for people with Cognitive disabilities this adds an additional unnecessary level of confusion and disorientation. Relevant sections of WCAG 2.0 include 1.3.2 "Meaningful Sequence" and 3.3.1 "Error Identification".

mgifford’s picture

Version: 8.0.x-dev » 8.1.x-dev
Related issues: +#1493324: Inline form errors for accessibility and UX

Just adding a related issue. Form errors are going to get a lot better soon I think.

It should make it much easier for people to identify what to fix.

WCAG requirements 1.3.2 & 3.3.1 are both WCAG 2.0 A level requirements, but usually issues around cognitive disabilities are AAA.

I can see some advantages to being able to weight the errors, but not sure how often this is likely to come up.

I do like @yoroy point of ordering by cardinality.

mgifford’s picture

Status: Active » Postponed
mgifford’s picture

Status: Postponed » Active

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

yoroy’s picture

Issue tags: +ux-hierarchy

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.