Updating the presentation of message macros

[CharpentierLucas]

Good afternoon!
In the context of XWIKI-21452: Macros info, success, warning and error are only distinguished by colors, we came up with a change of UI related to message macros: {{info}}, {{error}}, {{success}} and {{warning}}.
After considering multiple tweaks (see the PR), with Michael Hamann and tkrieck we agreed on the following UI:

For comparison, here is an overview of what such an UI would look like on master today:

The main changes are:

• An icon appears on the left of the message box, indicative of the nature of this box. This icon follows the icon theme defined in the wiki.
• The message title for the standalone macro is styled bold (still doesn’t appear on inline macros)
• Line height is tweaked slightly for inline macros so that the box doesn’t overlap on neighboring lines.

Do you agree with these changes?

Thank you,
Lucas C.

[vmassol]

@CharpentierLucas

The message title for the standalone macro is styled bold (still doesn’t appear on inline macros)

AFAIR the title could contain markup, no? And thus the style was part of the title content, no?

[CharpentierLucas]

I think that most casual users would expect the title to at least be in bold.
IMO there are way more cases where the user wants the title in bold rather than looking similar to the block content, so I’m in favor of putting it in bold by default.
Note that with the HTML changes proposed in the PR, a block is introduced to contain the title (makes it trivial to apply whatever custom style on it from a style extension).

See for example: Loading... and the discussion on Refactor note, tip, info, success, warning, error macros · Issue #97 · xwikisas/xwiki-pro-macros · GitHub

EDIT: I’ll test different markdowns and make sure that it’s possible to override the new default style for titles easily.

[mflorea]

Hi,

Thanks for working on this. There’s something about the indenting / padding on the left of the message, below the icon, that doesn’t look good to me. I don’t know why, maybe it’s the lack of symmetry or balance. It resembles a bullet list, but it’s not. For a bullet list it works because most of the time you have more than 1 item. While in this case I think most of the time you have a single “item”. You probably already tried without the indentation, and it didn’t look good either?

Thanks,
Marius

[tmortagne]

It looks a lot better than the current version, for sure.

I would be +1 to apply it as is, but let’s try to find things to improve:

• in the inline version, the white space between the border and the icon feels a bit too much
• in standalone mode, the indentation of the content feel strange (especially when there is a title)

[vmassol]

Related thoughts:

• Let’s hope everyone will like icons (especially in inline mode where I feel it’s a bit too much). If we get complaints in the future we might need to have a configuration, or at least document a SSX to remove them.

• I think we need to discuss the title and image parameters. I don’t see how they are useful since they can both be specified in the content of the macro. In addition the title accepts wiki markup which will cause problems (depending on how it was used) with the new bold of the title.

  Heres’s an example (from https://extensions.xwiki.org/xwiki/bin/view/Extension/Box%20Macro):

  {{box title="==Quick breakfast== " 
  image="http://farm4.static.flickr.com/3260/2894738978_ca0d3afd07_t_d.jpg"}}
  * cheese
  * omelet
  * milk
  {{/box}}
  
  vs 
  
  {{box}}
  image:http://farm4.static.flickr.com/3260/2894738978_ca0d3afd07_t_d.jpg
  ==Quick breakfast==
  * cheese
  * omelet
  * milk
  {{/box}}
  

  which currently gives:
  

  

  I’d personally be in favor of deprecating/legacifying them because:

  1. they’re not needed. For example if you check how the info, warning, error, success macros are used, you’ll find that they almost never use these parameters and that instead if they need a title they specify it as part of the content, which is way more powerful.
  2. The fact that the title contains markup is a pain (and as mentioned doesn’t play well with the boldification proposed)

  WDYT?

[mflorea]

@vmassol

I’d personally be in favor of deprecating/legacifying them because:

1. they’re not needed. For example if you check how the info, warning, error, success macros are used, you’ll find that they almost never use these parameters and that instead if they need a title they specify it as part of the content, which is way more powerful.
2. The fact that the title contains markup is a pain (and as mentioned doesn’t play well with the boldification proposed)

+1, I don’t remember ever using these 2 parameters.

Thanks,
Marius

[CharpentierLucas]

@mflorea

There’s something about the indenting / padding on the left of the message, below the icon, that doesn’t look good to me. I don’t know why, maybe it’s the lack of symmetry or balance. It resembles a bullet list, but it’s not. For a bullet list it works because most of the time you have more than 1 item. While in this case I think most of the time you have a single “item”. You probably already tried without the indentation, and it didn’t look good either?

This is a prototype I had at one point. Thiago afterwards highlighted that having a consistent line start would increase legibility. I think it looks cleaner to have all the text start at the same level whether or not there’s a title in the box.

Later on, I proposed another version with left-alignment, but less padding compared to the final one (ignore changes on the position of the icon itself):

The icon takes a bit less space but there’s also less unbalance between left and right paddings.

I think the final version (proposed in message 1 of this topic) looks the most appealing.
In my biased opinion, this indentation doesn’t look that odd, because the box itself is an item in the page content, and all the text inside it follows this indentation.

Ultimately, it depends on how we consider the icon:

• If it’s a feature of the box, it doesn’t need to be inline and can be in a position that disregards text flow
• If it’s a prefix to the text, it should be inline and we should avoid adding indentation to following lines.

[CharpentierLucas]

Continuation of Updating the presentation of message macros - #3 by CharpentierLucas

Here is a few examples of markup being used in a title, in order: no markup, h2 example, italic, table.

With a small SSX, we can revert the change proposed in this fix to what it used to be:

#xwikicontent .box .box-title {
  font-weight: unset;
}

[pjeanjean]

Like others have said before, the indenting/padding looks a bit weird with the standalone version, and personally I think it’s because the overall padding is too small. Keeping the top/bottom padding as large as your first prototype, and putting a bit more on left/right as well, would probably work better.

[Simpel]

Those message boxes are used with a meaning. Users who can see all colors learn their meaning by color. But screen readers won’t see a difference. So we teach our users to start those boxes with a keyword like: note, error, warning etc. These keywords should be the title I think.

We really would like those titles prefilled/default, so they won’t be forgotten to use. (You can change or delete them if you don’t want them.) With a translation page those defaults then could be adapted to the needs of the wiki.

I personally don’t think that wiki syntax is needed for the title. But what could be interesting is a switch to separate the title (including icon) with new line from the message body or not. Short messages could be look weird with separate title and body.

[CharpentierLucas]

@vmassol

Let’s hope everyone will like icons (especially in inline mode where I feel it’s a bit too much). If we get complaints in the future we might need to have a configuration, or at least document a SSX to remove them.

There’s also a quick SSX fix (LESS for convenience):

.successmessage, .errormessage, .warningmessage, .infomessage {
  & > span {
    display: none;
  }
}

If they are still relevant by the time we merge, I’ll add those snippets to the docs

@vmassol

I think we need to discuss the title and image parameters. I don’t see how they are useful since they can both be specified in the content of the macro. In addition the title accepts wiki markup which will cause problems (depending on how it was used) with the new bold of the title.

Okay, I agree that those should be deprecated.
If that’s alright, I’ll revert the title changes from this PR (so that it can be merged soon), and open a new improvement ticket to:

• deprecate title and image
• Provide heading as a replacement, which does not accept markup and is always bold.

[vmassol]

@Simpel

Those message boxes are used with a meaning. Users who can see all colors learn their meaning by color. But screen readers won’t see a difference. So we teach our users to start those boxes with a keyword like: note, error, warning etc. These keywords should be the title I think.

AFAIK this is exactly why the icons were added.

[vmassol]

@CharpentierLucas

• Provide heading as a replacement, which does not accept markup and is always bold.

I’m not sure why we would need this parameter. In my message above, and in Marius’s reply, we don’t think there’s a need for a replacement.

[Simpel]

Do have those icons an alt text or anything like this so that screen readers will see their meaning? And is this possible to translate?

[CharpentierLucas]

@tmortagne

in the inline version, the white space between the border and the icon feels a bit too much

I reduced it from .6rem to .2 rem in a new commit
Here is what it looks like now:

[tmortagne]

@CharpentierLucas

Here is what it looks like now:

Feels better indeed.

[CharpentierLucas]

Thanks for the reminder!
I did forget to provide a systematic alternative for this icon for scren readers. I’m adding this ASAP to the proposal.
Those alternatives will rely on a translation and will be available to change for admins of a wiki.

[tkrieck]

Hey everyone, I did some explorations to provide some options for the standalone version. One of them is with larger paddings, like @pjeanjean mentioned, and another one with the same padding all around.

1. Bigger paddings and a left border to grab attention and give it a “card” look

2. Same padding all around with the icon applied inline (I am not a big fan of this version, but here it is)

WDYT?

[mflorea]

@tkrieck

1. Bigger paddings and a left border to grab attention and give it a “card” look

This is interesting. I think it looks better, also thanks to the square corners, but I’m wondering if this is consistent with the rest of the UI that has rounded corners. If we go with this then we need to find some guiding rules for when we should use rounded vs. square corners.

Thanks,
Marius