Page MenuHomePhabricator

Review current style and integrate Messages and message boxes (errors, warnings) as WikimediaUI component
Closed, ResolvedPublic


Messages and Message boxes are used in various places and should be part of M101

Current status quo

MediaWiki coremediawiki.UI
.warningbox in application
MW core: .fmbox-editnoticeMW core: PostEdit messages
Editing a disambiguation page on English Wikipedia, with an fmbox-editnotice on top and anonymous user edit warning with class .warningbox (core messages) below
MW core: .mw-warningMW core: .mw-warning-with-logexcerpt

Scope of this task are the visual aspects of message boxes.
Finding guidelines on Voice & Tone is important, but are not part of this specific task.

Definition of messages

  • Messages, neutral notices
  • Success messages
  • Warnings, define clear separation from:
  • Errors

Success criteria

  • Responsive
  • Color coding not the only way to identify type, additionally icons (definition of treatment) and voice&tone(?)
  • WCAG 2.0 level AA color contrast sufficient
  • Support of limited rich text and not only text, although be strict about limitation.
    • Rich text examples: Links, bullet and numbered lists, bold text
  • Works as block and toast messages (overlays)

Proposed solution

Related Objects

Resolved Spage
Resolved Nirzar

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Also, MobileFrontend features some more styles

@colorWarningBackground: #feb;
@colorWarningBorder: #fde29b;
@colorWarningText: #850;
@colorSuccessBackground: #e1fddf;
@colorSuccessBorder: #b7fdb5;
@colorSuccessText: #009000;
@colorErrorBackground: #fae3e3;
@colorErrorBorder: #fac5c5;


Yup. We have warning, error and success states would be great to consolidate all these things. First things first they'll need to be created the same way...

@Jdlrobson For me this is not about the technical creation, it's about using one set of CSS classes. That's what WMUI Base is for.

JGirault renamed this task from Review current style and integrate Messages and message boxes as MediaWiki UI component to Review current style and integrate Messages and message boxes (errors, warnings) as WikimediaUI component.Oct 28 2016, 12:21 AM

I have a requirement for displaying a warning message in Maps (for more details see T148883).

Based on the new color palette and a brief discussion with @Nirzar , here is how the message may look like:

border=Y50, text=Y70, bgColor=Y10, fontWeight=bold
border=Y50, text=Y70, bgColor=Y10, fontWeight=normal
border=none, text=Y70, bgColor=Y10, fontWeight=bold
border=none, text=Y70, bgColor=Y10, fontWeight=normal
border=none, text=Y70, bgColor=B10, fontWeight=bold

Note: I left the icon black because for now we don't really have a solution for coloring the OOjs UI icons , besides generating new files.
Another note: the warning text is there as a placeholder, and is likely to change for a more precise message.

Also, as a separate discussions, we can discuss the position of the icon in case of a longer message:

Please give your feedback and suggestions

See also MobileFrontend implementation

Here are a few collected thoughts on UI:

  1. As color shouldn't be the only indicator (for accessibility reasons) it seems preferable to have an icon for these messages as well.
    1. Is it an icon on rounded background? Or do warning feature a triangle and errors an octagon or a rectangular shape?
    2. Are messages supposed to have an icon as well (example: “Log in to contribute” in MobileFrontend)?
  2. Are we going to feature two types of messages, one for the general use case, for example above login, or in a form, flat and one with box-shadow on products like maps, and also not fully opaque background-color?

Another one in Flow using the color that should be reserved for interactive elements only:

Another one in Flow using the color that should be reserved for interactive elements only:

At the time the accent color was consider appropriate for use as background color for messages. Using it only on interactive elements can be a useful cue, but I'm not sure that was already decided as the way to go or we need to refine the criteria a bit (e.g., should progress bars be blue?).

Currently a bug prevents the message to be connected to the input area as intended (framing the active interactive element as te blue borders do):

(I created a separate ticket for that: T154762 )

Ok, so in deriving a solution for the Flow message some kind of yellow background was among the discussed options as well T108762.

Ok, so in deriving a solution for the Flow message some kind of yellow background was among the discussed options as well T108762.

To add a bit of context: the goal was for the message to be (a) noticeable (to prevent you from posting anonymously by mistake) but (b) not present it in a negative way as an error/warning (since it is legitimate to post anonymously if you want to do so). I think we can explore different solutions if needed, but I think we need to preserve these two properties.

Hello, what is the progress of this task? :)

Based on what I saw further up I made a mock to discuss on.

  • Regarding the colors: I kept red for an error, yellow for a warning and green for a success message. I could see grey as a remark, so it doesn't appear to be an actionable item. Have it without color makes it less "judging" I think, which is in my understanding, what these remarks should be.

    Picking parts of this up again in current work in T92026.
    I agree in various points with @Hanna_Petruschat_WMDE proposal.
    And have provided feedback on M241 itself, an example of UploadWizard:

    There is also the JS popup notice used by the watchlist star icon and some other things, native form errors (HTML5 form validation attributes which are handled by the browser directly - try submitting a registration form with an empty password for example), edit notices (which VisualEditor hides into a weird dropdown thing and the old editor just pastes on top of everything), wikitext parse errors (they use the errorbox, but not always, I think? maybe it depends on preview vs. save?), Lua console errors (open a Module: namespace page for editing and enter something into the debug window at the bottom); AbuseFilter warnings/errors. If you want to get into templates as well then also {{error}}.

    MediaViewer also has its own homegrown error page (open some image in MediaViewer, disconnect from internet, open another image on same page). Also there's the Varnish error page when MediaWiki servers are not available at all, although hopefully these days that's not shown much.

    @Tgr Yes, we have several native elements, which we leave as is as the browser doesn't let us reach into the elements (optgroup cross-browser or autocomplete menus in recent Chrome as examples aside of the error styles).
    This task is about the error notes which are already in place and styled by us.
    There's also T113114: Make all wiki-facing error pages consistent for error page styles.

    Change 517197 had a related patch set uploaded (by VolkerE; owner: VolkerE):
    [wikimedia-ui-base@master] Add user system message variables

    Change 517197 merged by jenkins-bot:
    [wikimedia-ui-base@master] Add user system message variables

    This has been merged and is now part of Design Style Guide's Components overview.
    Further amendments will be made on project-specific tasks.