Adapt Buttons

[guywillis]

Subject of the issue

The buttons in Adapt are in need of modernisation. This includes a categorisation activity to group similar visual styles or actions together, normalising the implementation of styles across Adapt, and a visual refresh.

• Categorise into relevant sections. Example for illustration purposes:
  • Navigation
  • Component - accordion item
  • Component UI - media transcript
  • Question - mcq item
  • Question UI - submit
  • Overlay - bookmarking yes / no
  • Overlay UI - close
• Normalise button styles
  • Perhaps a mixin based approach would work here
• Visual refresh
  • Vanilla disabled state opacity

---

Categorisation

The grouping of buttons with similar visual styles or actions would help with presenting a consistent approach to the end user. Currently UI elements such as narrative controls have the same visual treatment as component elements like accordion items potentially introducing confusion to the end user when similarly styled elements behave differently visually and functionally.

For example:

• Narrative controls on the first / last items are disabled and cannot be interacted with
• Accordion items, styled the same as narrative controls, become visited when interacted with (and can continue to be selected)
• The narrative controls change to the disabled styling whilst accordion items change to visited styling

Normalisation

The button styles in Adapt are quite simplistic in approach and don't necessarily lend themselves to supporting the range of styling requirements or states required in Adapt. The introduction of a mixin layer above the base variables could go some of the way to satisfying the need for normalising the implementation.

Example code snippet:

.btn-default() {
  background-color: @btn-color;
  color: @btn-color-inverted;
  border: 1px solid @btn-color-border;
  box-shadow: 0 0 0 0 @btn-color-shadow;
}

.btn-hover() {
  background-color: @btn-color-hover;
  color: @btn-color-inverted-hover;
  border: 1px solid @btn-color-border-hover;
  box-shadow: 2px 2px 5px 0px @btn-color-shadow-hover;
  .transition(background-color @duration ease-in, color @duration ease-in, border @duration ease-in, box-shadow @duration ease-in;);
}

.btn-focus() {
  background-color: @btn-color-focus;
  color: @btn-color-inverted-focus;
  border: 1px solid @btn-color-border-focus;
  box-shadow: 0 0 8px 0 @btn-color-shadow-focus;
}

.btn-disabled() {
  background-color: @btn-color-disabled;
  color: @btn-color-inverted-disabled;
  border: 1px solid @btn-color-border-disabled;
  box-shadow: 0 0 0 0 @btn-color-shadow-disabled;
}

Which is then applied at the various elements in a fashion similar to the following:

.narrative {
  &__controls {
    .btn-default;

    .no-touch &:not(.is-disabled):not(.is-locked):hover {
      .btn-hover;
    }

    html:not(.a11y-disable-focusoutline) &:focus-visible {
      .btn-focus;
    }
  }

  &__controls.is-disabled {
    .btn-disabled;
  }
}

Visual style

While we're undergoing this examination of the buttons, it's prudent to also consider the visual style of the buttons in Adapt. Perhaps we could look to refresh the colour scheme and or style of the buttons through out.

---

Working list of where buttons appear in Adapt at present:

• navigation icon button
• navigation text button (skip nav)
• menu item
• accordion item
• hotgraphic pin
• matching drop down
• media transcript
• narrative controls (next / back)
• narrative strapline
• question submit
• question feedback
• assessmentResults retry
• trickle
• drawer icon (back / close)
• drawer item
• resources filter
• notify close
• notify text buttons (bookmarking)
• notify (hotgraphic) pagination

[kirsty-hames]

I'm in agreement with this. Before any implementation, I'm in favour of reviewing all Adapt buttons so we can group/categorise accordingly and discuss best approach.

Currently in Adapt we only categorise buttons by whether the button contains text or icon. However, not all buttons include .btn-text or .btn-icon classes. Styling buttons based on function/context rather than whether it contains text/icon is more logical. We'll also improve Adapt's UX by creating consistent UI patterns.
With AAT in mind and theme by config, this is a good opportunity to set a best practice base theme and will make colour application in the tool more intuitive. Whilst also creating a solid base to support the more complex theming.

[kirsty-hames]

In regards to categorising buttons, I was looking at the following:

UI elements

• Navigation
• Notify prompts
• Drawer

Content elements

• Content items (elements that contain content, e.g Accordion or MCQ item)
• Content buttons (trigger an action e.g. question submit or Narrative back/next controls)

Initially I started looking at the colour variable application in Adapt, where we have inconsistencies etc so I've already documented which buttons we have in the following categories and where they inherit colour (from base .btn-text or .btn-icon classes as well as colour variables). I'll share some more info on this shortly but would be good to see if anyone else has any ideas on this too.

I think as well as the button types/categories, it's also worth documenting the various states for each button type. I've noticed buttons of the same group/type share the same button states. The disabled button state issue raised will also feed into this.

[ethan-lp]

To prevent duplication of tickets, I wanted to ask is this also going to address the issue (UI) relating to button validation icons overlapping text? btn__marking

It would indirectly do so I'm sure, just wanted to clarify.

[kirsty-hames]

Hi @ethan-lp, although this is button related it sounds like a separate issue specific to the positioning of the btn__marking icon. I'd suggest raising this as a new issue ticket. Please include any relevant info in the ticket (versions and config setup as per Olivers comment).

[ethan-lp]

@kirsty-hames @oliverfoster

Thank you both issue has been raised here - #390

[StuartNicholls]

I've already put some thought in to this so I'll add this here.

So, I see this as some first steps towards a button API and consistent buttons in Adapt. So a core issue is a good place for this although this will have some crossover with vanilla theme.

Introduction: Buttons in Adapt

Buttons in adapt are placed throughout course. Buttons in adapt have two main actions. Navigating the course and interacting with the course content.

Navigation buttons

Navigation buttons are things like the buttons in the nav bar, the trickle button and dialog window buttons like the page incomplete prompt.

Content buttons

Content buttons are things like submit buttons, narrative component buttons and feedback dialog windows or dialog windows relating to a component interaction.

So we could differentiated these buttons for better UI/UX. This can be set in the theme less or in the theming section of the authoring tool, although currently the buttons aren't differentiated in this way so this is hard to achieve. As this is purely for look-and-feel and doesn’t fall within accessibly guidelines if the art director wants to employ this method, specifying contrasting (but accessible) colours here will benefit the most learners.

---

Basic Button types

We have various button types in Adapt so we can utilise and rationise these for better UI/UX. So, the buttons in Adapt can be rationalised in to three variants: plain, filled, and outlined. Each of these variants could represent a hierarchy of actions in relation to their visual prominence.

*Buttons can contain text only, icons only or both icons and text.

So suggestions here:

Plain buttons

Plain buttons are typically used for less-pronounced actions, including those located: in the nav bar, in the drawer and (sometimes) navigation dialogs.

Outlined buttons

In adapt there are two types of outlined buttons. Medium emphasis and 'reversed' buttons.

Medium emphasis buttons

These buttons are actions that are important but aren't high emphasis content buttons and are a lower emphasis alternative to filled buttons. These include MCQ buttons like ‘Show feedback’.

*Outlined buttons can also be a higher emphasis alternative to text buttons. For example, dialog buttons.

Reversed Primary and secondary buttons

In adapt buttons can sit on a background colour that is in contrast to the main background colour of your course. Where this is the case, alternative, outlined buttons could be automatically applied to avoid accessibility issues concerning colour contrast and also issues with general legibility. This also helps the art director by easing harmonisation of colour palettes. In this case high emphasis and medium emphasis buttons could be distinguished by border weight. And are either black or white to obtain the most contrast with the background colour.

Disabled button types

Plain, filled and outline buttons can all have a disabled state. The disabled state of buttons is signified by a reduced opacity level compared to their respective enabled state.

But see discussion here:

adaptlearning/adapt-contrib-vanilla#446

[StuartNicholls]

@guywillis @kirsty-hames , I think we're in agreement that the above is the right approach (refinements accepted). So if thats the case will need to formulate the best forward thinking approach to this. Once we've agreed this is the general direction is correct. I'll add some ideas about how to achieve.

[StuartNicholls]

@guywillis just reading though you're mixing. I see you've added a box shadow. So, my comment doesn't address how we'd deal with 3d type buttons so maybe we need to weave that in to my flat button comments also. And perhaps box-shadow is a good method for this.

[StuartNicholls]

In terms of a API, I think I was imagining a tailwind-esq approach from api/famework buttons, so classes like 'primary' 'secondary' classes get added to the DOM but open to suggestions here too. I think due to the complexity here we may need to think about prototyping something do help discover pros and cons to different approaches.

[kirsty-hames]

In terms of a API, I think I was imagining a tailwind-esq approach from api/famework buttons, so classes like 'primary' 'secondary' classes get added to the DOM but open to suggestions here too. I think due to the complexity here we may need to think about prototyping something do help discover pros and cons to different approaches.

I'm all for prototyping and I think the terminology/class names can be refined once we've established the button requirements/use cases etc.

[kirsty-hames]

@guywillis just reading though you're mixing. I see you've added a box shadow. So, my comment doesn't address how we'd deal with 3d type buttons so maybe we need to weave that in to my flat button comments also. And perhaps box-shadow is a good method for this.

@StuartNicholls, @guywillis, it might be worth collating button use cases such as the more complex brand guidelines we know we often adhere to on projects. Whether we incorporate all use cases in Adapt as standard or create a base for which we can support the more complex in custom theming is up for discussion.

[guywillis]

@guywillis just reading though you're mixing. I see you've added a box shadow. So, my comment doesn't address how we'd deal with 3d type buttons so maybe we need to weave that in to my flat button comments also. And perhaps box-shadow is a good method for this.

The majority of implementations I've done using box shadow don't stray into the 3d style, instead they focus on requirement workarounds:

• Increasing the border width between states (default / hover) increases the width and height of the element
• Box shadow allows for multiple arguments

@StuartNicholls, @guywillis, it might be worth collating button use cases such as the more complex brand guidelines we know we often adhere to on projects. Whether we incorporate all use cases in Adapt as standard or create a base for which we can support the more complex in custom theming is up for discussion.

In terms of brand guidelines they usually define buttons in four main categories:

• default
• hover
• focused
• disabled

pressed - in some instances this is a separately defined style to focused in the guidelines but I don't tend to attach anything to this particular state

I don't believe I've gone any more complex than this on projects, and don't see a particular need (at present) for Adapt to introduce anything more complicated. They'll need to be alternate versions such as plain, outlined, filled and their inverted variants but they can still follow the 4 main states list above.