[UX] Support a 4th "info" type for backdrop_set_message

[klonos]

https://api.backdropcms.org/api/backdrop/core%21includes%21bootstrap.inc/function/backdrop_set_message/1

...we currently support only the following message types:

• status:

  

• warning:

  

• error:

  

I propose supporting another type of info:

I think that by doing this, we would also allow contrib modules to communicate info things in a standardised manner. Think Drupal webform module and the message that was added recently:

(This should not affect our backwards compatibility, as it seems like an API addition.)

---

PR by @klonos: backdrop/backdrop#2217
PR by @jenlampton: backdrop/backdrop#2291

[opi]

Agreed. I suggest we use an "Info" picto, like https://fontawesome.com/icons/info-circle?style=solid

[opi]

Note that in backdrop_set_message and backdrop_get_message, the $type argument is never checked, nor in theme_status_messages where the type is printed out as CSS class, without check or sanitization.
It means the implementation is only on the admin theme side, and documentation.

[klonos]

I suggest we use an "Info" picto, like https://fontawesome.com/icons/info-circle?style=solid

Of course we should! ...I was lazy when I was putting the mockups together :)

[klonos]

PR just filed: backdrop/backdrop#2217

Unfortunately, the info type for messages is not being used anywhere in core at the time being, so you cannot test this in the sandbox. For those that cannot test locally, here's how it looks:

[docwilmot]

Is there anywhere in core now where this could or should be used? If the answer is "no" I suspect we should be questioning if this is necessary.

[klonos]

@docwilmot yes, I think I have mentioned this in another issue recently. Here are a few examples where messages we throw at the user are either not using backdrop_set message when they should've:

...or are using the status/success message type, when the user has not performed any directly related action:

^^ this is visiting the module installer page, after having installed modules that were intentionally left disabled. I have just intentionally navigated back to the Project Installer page with the intention to install additional modules that I forgot to add in the first go.

...this specific message persists across other project installer sections as status/success. Here's the same message, talking about recently installed modules, while I'm at the layouts installation page:

^^ this can a) either be considered a bug (in which case we should make sure that this message only shows in the modules installer page), or b) considered a feature (in which case the message could use the new 'info' type).

Here's another example:

^^ ...layout templates are automatically enabled during the last step of the installer (unlike modules and themes). The first part of this message is correctly thrown as a success, the last part should be an 'info'. Separating this message to a success and an info one, would allow us to dismiss the one, while keeping the second one persistent...

...here's how this story continues, if you navigate away from the layout templates page and install a theme:

^^ this is where my previous suggestion makes sense. The first message now seems like a bug, unless we have only kept the "You can manage layout templates on the layouts Settings page." as a persistent 'info' message. Also, the part that is placed at the top of the list of themes as plain text feels like it could also be a separate 'info' message.

There's other examples where this could be used in core, but contrib can also use it to convey messages like additional manual steps that might be required after upgrading to a major version etc.. In general, messages that need to be shown as help text, but unlike actual help text, should not be shown all the time.

[docwilmot]

I'm not clear on the difference between status and info though. Can we have it explicitly described and agreed on in preparation for this?

[klonos]

Sure. Here's my take on this...

"Sophisticated" definitions:

• Status/Success message: something that needs to be displayed to the user as a direct result of the action they were performing. Shown once, on the page where the action finishes.
• Help/Info message: something that needs to be displayed to the user persistently across various pages. Can be the result of their actions on another section of the site (excludes messages that should be warnings/errors).

(overly) simplified rules:

• Status/Success message: Yay! It worked.
• Help/Info message: Did you know ...??

Would be interested to know what others think.

[klonos]

...having said that, I personally think that although it is good to define/document these, they should not be strict/explicit. The success messages have been abused in many cases over the years, both in Drupal and in Backdrop. The introduction of the new 'info' message type should be a way to better the situation and clarify things IMO. A means to expend and provide more options; not a means to impose and restrict.

[opi]

I'm not clear on the difference between status and info though.

Probably because 'status' is more a 'success' message, with a green color theme and a positive check pictogram. Is it worth renaming ?

[opi]

Here is a full list of message display through backdrop_set_message() : https://gist.github.com/opi/f28a1ed0dc2e26b44b543b02026addb4 ; Not sure we will find so much to display as 'info'

[laryn]

It makes sense to me to have an "info" message separately from the "success/status" message, and @klonos's description of the difference is helpful.

Other examples of "persistent" info messages that should not have a checkmark/success indicator:

• Your account is pending approval
• There are no updates currently

[jenlampton]

Yes please! Love this idea, thanks @klonos :)

[klonos]

@laryn ...this is my OCD talking again plus my personal preference for Backdrop CMS the product to be "intelligent", but I believe that the examples you have listed are not 100% fit for the use case. If a message has been triggered by a user action, then this should be a success message. The info type should be used in the case that we need to convey something additional to the user, or if the message we are trying to display has not been a direct consequence of the user's current action.

To be more precise...

• in the case of the "Your account is pending approval" message, it should be a success message if it is shown to the user directly after they have created an account. If they revisit the page at a later point in time (not sure if that is possible in this specific case), then this message should change to an info type. So first time we show the message: success (convey "it worked!"), successive times we show the message: info (convey "still pending").

• in the case of "There are no updates currently", it should be a success message if the user has just clicked the "check for updates" button, but if we need to show this message to the user again at a later point (they navigated away and have returned to the same page after a while for example), then this should be an info message this second time. In actuality, we show this to the users:

  

  ...I see how this could be a "Checked available update data for 3 projects." success message (as opposed to a "something went wrong" error), followed by:

  • a possible "all projects are up to date" success message
  • a possible "updates found for x projects" info message
  • a possible "recommended updates found for x projects" warning
  • a possible "pending security updates found for x projects" error

[klonos]

...another example where this can be used in contrib:

The "Installation is complete." success message would suffice in this case, and the other 2 messages could be shortened to just "[module_name] does not provide any new functionality on its own but may be used by other modules.", and converted to the new info type 😉

[opi]

Filled a related issue: [DX] Use proper 'success' message type and deprecate the ambiguous 'status' type. #3179

[klonos]

Joomla has this "messages" section that lists messages that need to be communicated to the user:

...although some of these seem that they should be warnings, respective messages about stats collection, or unsupported php versions in upcoming Backdrop releases could use this new info message type (unsupported php version in the current installation should still be a warning/error).

[klonos]

...bootstrap also seems to have this 4th info alert type too:

[klonos]

Note to self (for when this gets merged): another place where this could be used: #2583 / #3050

[opi]

Add a request regarding accessibility of focused links. Easy to fix though

[klonos]

Thanks @opi 👍...for posterity and so that we get some feedback from others, I am posting your comment here too:

just realized that links has no hover or focus effect. This is not nice regarding accessibility.
The easiest could be to remove the text-decoration:

.messages a:hover,
.messages a:focus {
  text-decoration: none;
}

...although from what I see we are doing the opposite everywhere else in the admin UI: links are not underlined by default, and they get underlined on hover/focus. Hmm... let me give it a bit of thought and I will update the PR ...I will probably go with your suggestion @opi unless anyone else has better ideas. @wesruv?

[opi]

Actually, the "focus" rule is not needed here, because it's already defined globally (blue outline)

[quicksketch]

from what I see we are doing the opposite everywhere else in the admin UI: links are not underlined by default, and they get underlined on hover/focus.

Although it's opposite, I think it's better than no hover effect. This looks so close!

[jenlampton]

I've filed a new PR that includes the hover state: backdrop/backdrop#2291

[quicksketch]

Looks great. I added one more commit to add @since 1.11.0 Added "info" as an acceptable $type parameter. to the docblock of backdrop_set_message().

I've merged backdrop/backdrop#2291 into 1.x for 1.11.0. Thanks @klonos, @opi, @docwilmot, and @jenlampton!

[klonos]

Thanks everybody for finishing this off 👍...I have plans for putting it into good use 😄