Adapt Buttons - Vanilla issue

[guywillis]

Subject of the enhancement

Vanilla issue for core issue described here: adaptlearning/adapt-contrib-core#386

Your environment

• Master

[guywillis]

A little bit of a brain dump below:

Preamble

• Define new button categories
  • Nav bar
  • Button item (accordion, mcq, etc.)
  • Button action (question submit, narrative controls, etc.)
  • Button content (drawer / notify) - questionable, is it needed? could they be the inverse of drawer / notify colour?
• Define button importance
  • Mandatory
  • Optional
• Define button types
  • Filled
  • Outline
  • Plain
• Define current application of buttons across Adapt
• Map current application into new button category, importance, and type

Actions

• Remove .btn-text and .btn-icon classes
• Add new button classes for importance and type to existing application
• Introduce new button variables for styling
• Add mixin support for multiple button types
• Use html class or data attribute to differentiate between button types e.g. btn-mandatory-filled btn-optional-outline or btn-mandatory-outline btn-optional-plain etc

Thanks @kirsty-hames and @StuartNicholls for your thoughts in adaptlearning/adapt-contrib-core#386 which have formed the base for the above list

[guywillis]

• Define current application of buttons across Adapt

I've taken an initial stab at categorising the various buttons that appear in Adapt below:

See table below for better overview

[kirsty-hames]

• Define new button categories

  • Nav bar
  • Button item (accordion, mcq, etc.)
  • Button action (question submit, narrative controls, etc.)
  • Button content (drawer / notify) - questionable, is it needed? could they be the inverse of drawer / notify colour?

• Define button importance

  • Mandatory
  • Optional

Thanks @guywillis. I think it would be good to confirm the above and the button states (default/hover/locked(disabled)) before looking at button types. I see button types being a second step as this could go various ways (design preference vs semantics etc). Mapping out all the buttons and their specifics will mean we haven't overlooked anything hopefully.

Some similarity but I've got a slightly different approach to the button categories based on UI vs content (previously I shared in the core issue thread). I'm going to make some updates to this and post below to get your thoughts.

Actions

• Remove .btn-text and .btn-icon classes
• Add new button classes for importance and type to existing application
• Introduce new button variables for styling
• Add mixin support for multiple button types
• Use html class or data attribute to differentiate between button types e.g. btn-mandatory-filled btn-optional-outline or btn-mandatory-outline btn-optional-plain etc

I think the first point can be addressed last until we have the new button classes/styles in place. Currently all buttons that inherit from .btn-text and .btn-icon classes have overriding styles anyway - except Trickle and Question Submit/Feedback. These only inherit from .btn-text which is probably an oversight.

[guywillis]

Remove .btn-text and .btn-icon classes

I think the first point can be addressed last until we have the new button classes/styles in place.

Over the weekend I have actually had a change of thought on this point and am musing over whether keeping them in as classes differentiators between text and icon based icons could be useful for things like padding.

[guywillis]

@kirsty-hames and I have taken an in-depth view at buttons in Adapt and come up with the following table:

• The Adapt column details where the button appears
• The Category column is our definition of how that button should be categorised
• States - Current details what states the button currently has whilst States - Ideal is where we'd like to get to
• We've also defined the type of button for each state - filled or outline for the time being

Whilst investigating and after contemplation, we've decided that the relevance of button importance isn't required as it currently stands.

Thoughts very much welcomed from all.

[kirsty-hames]

Having reviewed all comments above and Core issue 386 I've put some next steps together to progress with this.

Part 1: Focus on colours only (sticking with background-color and color styles only as per current Adapt to keep things simple whilst we get the structure set up)

• Expand on _colors.less variables based on the catergories and states defined (in table above)
• Review existing variables and identify missing catergories/states
• Create mixins to normalise button styles based on the catergories and states defined.
• Review and discuss.

Part 2: Introduce button styles (visual refresh)

• Create button styles e.g. plain, filled, outlined
• Introduce other CSS styles as needed such as border, box-shadow etc. I suggest we keep font styles separate for a later phase (if needed). We only have a single button font style as is (.button-text).
• Review and discuss.

Part 3: Implementation

• API with DOM classes vs LESS application
• Fine tune naming of variables/mixins etc
• AD flexibility (choose your button styles) vs set button styles predefined in theme

---

Use of .btn-text and .btn-icon classes

Keep .btn-text and .btn-icon classes for padding only (whilst we focus on Part 1 at least).

Existing Core references:
.btn-text - sets padding
.btn-icon sets padding + border

Existing Vanilla references:
.btn-text - sets font + colours
.btn-icon - sets colours

---

Buttons that don’t have their own styles currently

These inherit colours from .btn-text or .btn-icon classes only. These could be picked up as Part 1 tasks.

Question submit / reset / show correct answer (.btn__action)
inherits @btn-color via .btn-text class

Question feedback (.btn__feedback)
inherits @btn-color via .btn-text class

Trickle .trickle__btn)

• inherits @btn-color via .btn-text class
• inherits @btn-icon-color via .btn-icon class
• if both text and icon exist then .btn-text takes precedence

LanguagePicker language button (.languagepicker__language-btn)

• inherits @btn-color via .btn-text class

Pagenav (.pagenav__btn)

• text buttons inherit @btn-color via .btn-text class
• icon buttons inherit @btn-icon-color via .btn-icon class – this did originally use @nav-icon variables btn-icon variable support cgkineo/adapt-pageNav#17
• only icon buttons have component specific overrides - @btn-icon-color which just inherits @nav-icon anyway.

Buttons missing .btn-text / .btn-icon classes

• Media transcript
• Narrative strapline
• Drawer plugins (drawer item etc)

[guywillis]

Updated button table