Page MenuHomePhabricator

Provide a color palette and design for buttons that are purely highlighted links, to distinguish them from actual UI buttons
Open, LowPublic

Description

Problem: Many people are using "colored buttons", purely for high-visibility. (example list, below). Many of them use the exact OOUI scheme.

  1. This undermines the meaning the colors/buttons are meant to have.
  2. It makes any broken or vandalised link, into something that erodes trust in the actual interface. (e.g. "the last time I clicked a big green button it didn't work [or took me somewhere horrible]...")

Solution (suggested): We should provide a distinct/different set of styles to the community, to help them achieve this visibility purpose, without their resorting to "buttons" that are 100% ambiguous with site UI.

Context: The OOUI color-buttons are intended to have specific meanings, per


Sample list of problems (I.e. these are just plain links, but are given fancy styling for increased visibility):

Semi-relevant usages, but using the wrong color

Mixture of appropriate and inappropriate:

(Close, but not exact copies of OOUI)

Note: the easiest way to find these examples, is to search the projects for insource:"mw-ui-progressive" (and -constructive and -destructive and -button). E.g. https://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial:Recherche&search=insource%3A%22mw-ui-progressive%22&fulltext=Rechercher&profile=all


Related tasks:

Event Timeline

Quiddity created this task.Oct 25 2015, 8:29 PM
Quiddity raised the priority of this task from to Needs Triage.
Quiddity updated the task description. (Show Details)
Quiddity added a subscriber: Quiddity.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 25 2015, 8:29 PM
Quiddity updated the task description. (Show Details)Oct 25 2015, 8:41 PM
Quiddity set Security to None.
Quiddity updated the task description. (Show Details)Oct 25 2015, 8:45 PM
Quiddity updated the task description. (Show Details)Oct 25 2015, 8:49 PM

There are the "quiet" buttons too ("frameless" in OOUI), which I personally think useless, but YMMV.

matmarex removed a subscriber: matmarex.Oct 26 2015, 8:57 PM

https://commons.wikimedia.org/wiki/Template:Clickable_button isn't even using mw-ui- classes, I think it's using some jQuery UI precursor. The problem of garish buttons for links long predates Agora/MediaWiki UI, see Template:Big Blue Button :-) .

There are the "quiet" buttons too ("frameless" in OOUI), which I personally think useless, but YMMV.

Editors can add CSS class mw-ui-quiet and they will get a gray link that only colorizes on hover and click.

OOUI's frameless (framed: ""?) buttons are also quiet, but with different rollover behaviors. And neither matches the text in https://livingstyleguide.wmflabs.org/wiki/Buttons#Quiet_buttons , which says "Buttons in the quiet style do not display the Intention color or draw a button boundary unless the user interacts with them via hover or focus." I don't see a button boundary on hover/focus/click in either toolkit.

I proposed supporting OOUI widgets in wikitext with T101666: Create parser tag(s) that render OOUI PHP widgets. If it were easy enough to use MediaWiki's UX elements, maybe wikis would not invent their own.

OOUI's frameless (framed: ""?)

framed: false, yes.

And neither matches the text in https://livingstyleguide.wmflabs.org/wiki/Buttons#Quiet_buttons , which says "Buttons in the quiet style do not display the Intention color or draw a button boundary unless the user interacts with them via hover or focus." I don't see a button boundary on hover/focus/click in either toolkit.

Yeah, I don't think showing the button border on hover was ever implemented. OOUI frameless buttons used to be gray until hovered, but that was changed per T108086. I don't think anybody is still reading or updating any of the numerous living style guides that were created (maybe other than you :) ).

Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptNov 19 2015, 10:33 PM
violetto moved this task from Researching… to Doing… on the UI-Standardization board.
violetto added a subscriber: violetto.

@Quiddity, do you think the solution described in this response under "GREEN" works as a solution to this issue?

If I understand the task correctly, it sounds like it consists of two parts:

  • Provide a color palette
  • Design for buttons that are purely highlighted links, to distinguish them from actual UI buttons

That might work, yes.
The https://outreach.wikimedia.org/wiki/Education page already uses the green button style, for an example.
Though ideally we'd provide a style that isn't used in (ambiguous with) the default site UI.

Yes, those 2 bulletpoints sound like a clearer description of the overall request. :-)

Quiddity updated the task description. (Show Details)May 19 2016, 1:10 AM
Danny_B moved this task from Doing… to Unsorted on the UI-Standardization board.May 23 2016, 6:45 AM

Just simple quick note - the easiest way, how to disallow people semantically incorrectly abusing built-in styles is to sanitize relevant classes. In this particular case, trim all mw-ui-* and oo-ui-*.

Just simple quick note - the easiest way, how to disallow people semantically incorrectly abusing built-in styles is to sanitize relevant classes. In this particular case, trim all mw-ui-* and oo-ui-*.

If I understand correctly, that sounds like what one dev wrote to me over year ago: "this is SPECIFICALLY why I was trying to restrict the usage of these to <a>, <button>, and <input> tags" - I think something like that would be good, in combination with the outcome of this task, to prevent user confusion.

Just simple quick note - the easiest way, how to disallow people semantically incorrectly abusing built-in styles is to sanitize relevant classes. In this particular case, trim all mw-ui-* and oo-ui-*.

If I understand correctly, that sounds like what one dev wrote to me over year ago: "this is SPECIFICALLY why I was trying to restrict the usage of these to <a>, <button>, and <input> tags" - I think something like that would be good, in combination with the outcome of this task, to prevent user confusion.

That actually wouldn't not cover everything, since the parts of OOUI are also classes for generic wrapper tags (div/span) which are permitted in wikitext, so those would remain abusable.

Volker_E triaged this task as Low priority.Dec 15 2016, 5:27 PM