Organization of button colors in Tiki

Finding a balance between semantic colors and theme palette colors

Tiki uses the Bootstrap CSS framework and one design principle of Bootstrap is to use semantic colors to indicate user interface meanings so, by default, Bootstrap websites use several button colors that have more or less intuitive meanings. However, these meanings aren't necessarily clear and can appear random, and in some cases they don't work well visually with the site's theme. For this reason, the designer or administrator might want to modify the concept of semantic colors for buttons. This is described below.

Starting point: implementing meaningful button colors

The goal here is to make the meaning of button colors in Tiki more intuitive and consistent, in the Bootstrap Default theme, for example, as a baseline. Of course every theme has its own color palette and button colors vary from the default.

In Bootstrap 4, which is integrated into Tiki starting in version19, some button class names and default colors have changed from Bootstrap 3. (See https://getbootstrap.com/docs/4.3/components/buttons/ .) The meanings conveyed by button colors may not be as clear now as they were in Bootstrap 3, when the default button color was essentially neutral and colors were used for special meaning and, even with Tiki and Bootstrap 3, there wasn't a clear pattern of button color use.

For this reason, the button classes are being organized in the .tpl files, etc. and will be in the HTML and they will be most apparent in the Default Bootstrap theme. Other themes, of course, can style buttons as they please but the hope is that the organization of button colors makes sense and will benefit themes and users even if the themes' palettes vary from the Bootstrap default.

One suggestion is that sites could assign an admin theme that shows the button colors most clearly, and another site theme with perhaps less obvious colors that are toned down from the default ones.

• In principle, links that are used for navigation should be styled as links (text only or text with icon), not as buttons. But there can be exceptions such as widgets which call an action and also link to another page. Then btn-link can be used. For example: This is a small button link!
• On pages or sites where there aren't many buttons, the button colors might seem random, but as the number of buttons and user interactions increases, then hopefully the color pattern will be more evident and useful from a UI standpoint.
• For consistency this semantic scheme should be applied to icon buttons as well, like the magnifying-glass "search" icon and the "i" and "?" tooltip icons, in forms and so on, but not in an array like the admin icons where color consistency is more important.

Dev mailing list discussion starts here: https://sourceforge.net/p/tikiwiki/mailman/message/36346433/

Edge cases

• The Post new comment button leads eventually to a positive action so could possibly be considered btn-primary, but this button itself only causes the comment form to display, so is btn-secondary. The Post button in the comment form is btn-primary because it actually causes the action.
• Although clicking the Clear all caches button is destructive in the sense that it deletes files in the caches, this button can be btn-primary because clearing the caches is a positive action (to remove unwanted files and use updated content, etc.).

Questions

• Where is the limit between significant and insignificant changes?
  • I don't know of a criteria yet but I would say that for any case where there is a question, it should be classified as signficant.
• Is it allowed to use btn-primary for confirming a non-destructive change, or to make a destructive change?
  • I think it's more appropriate to use the success color to confirm a non-destructive change; and I think it would be confusing and inconsistent to use btn-primary to make a destructive change.
    • I understand that another color would be more appropriate; my question was whether it is acceptable, because if it is unacceptable, that is not clear in the table's current state.
• Why is btn-secondary "cyber grape" when in default Bootstrap4 it is dark grey (#6c757d) ?
  • The Bootstrap docs say "Bootstrap includes several predefined button styles, each serving its own semantic purpose" but doesn't give any guidance on the use. The semantic purpose can be inferred from the button class name and color, except in the case of btn-secondary. A rationale can be seen for btn-danger being red (in our cultural context anyway), but there isn't a particular rationale for btn-secondary being dark grey. IIRC, the button's color change in Tiki was to give it a color like the other buttons have and not a gray shade. Maybe the change was also to give it some relationship to btn-primary and its color, which is blue by default, in the same way there is a color relationship between btn-warning and btn-danger.

Giving priority to the theme palette - examples: FiveAlive-lite and FiveAlive

In October 2019 (in Tiki 20svn), the issue came up that, in particular, the "Info" button color (blue by default) looked out of place in some of the FiveAlive-lite child themes that are used for the Tiki project sites (tiki.org, themes.tiki.org, etc.). The color looked "wrong". The reason for the button being blue isn't apparent to site users. The suggestion was made (by luci) to use the theme child colors shown at https://branding.tiki.org/Colors for the Primary, Secondary, and Info buttons. (The Warning and Danger button colors are probably more intuitive in context, so theme palette compatibility is less an issue.)

Other themes and other websites might also have issues with the default Bootstrap semantic colors on buttons, so clearly it's necessary for designers and admins to make choices to get the best end result, and the colors in the site's theme or themes should be chosen accordingly.

Unique problem of child theme variants

For a standard Tiki theme, the semantic colors (for primary, secondary, success, info, warning, danger meanings) are defined in the theme's variables file and compiled to disseminate into all parts of the theme that need the coloring. It's a little problematic for child themes to diverge from the parent theme in regard to these colors because of the complexity of button variations - normal, hover, disabled, outline, etc. And the child theme stylesheet should be kept small; if it gets too large and comprehensive, it might as well be a standard theme. Some child themes are edited directly in CSS, for simple cases. Others are compiled from SCSS files, to be able to use variables and to avoid duplicated code, etc. This is a good choice when button colors need to be modified.

To vary the button colors in compiled child themes, follow the example of the FiveAlive-lite child themes (solid button background colors) and FiveAlive child themes (gradient button backgrounds).