Consider removing the disabled button from EUI

[gavinwye]

I'd like us to consider removing the disabled buttons from EUI for the following reasons:

1. The exist but are not documented in the guidelines
2. In Kibana we use a disabled button 7 times, so they are not well used.
3. Disabled buttons can cause problems for users. This post Disabled buttons suck explains a lot of the problems.

Image of buttons for reference

[elizabetdev]

Hi @gavinwye,

Thanks for opening this discussion. We are considering changing the disabled buttons to make them more inclusive. You can follow the issue here: #5666.

[cchaos]

One other thing to note is the all EuiButton's accept both isDisabled and the raw HTML property disabled. I'm sure there are a lot more usages of disabled buttons using the simpler prop disabled.

In general, it's a hard ask to completely remove default HTML functionality from a component that renders that HTML element. Disable buttons are valid HTML elements and do serve a purpose when used correctly. Like @miukimiu said, we're investigating how to make this state better for all, but we cannot remove the functionality completely.

I'd love to see some guidelines written around the proper usage of disabled buttons. @gavinwye If you'd like to write something up, we can add it do our docs.

[snide]

+1 for guidelines. Easier to start from the solution than the problem.

[elizabetdev]

@gavinwye @cchaos we can start by doing an inventory of our products to see what are the situations where we use disabled buttons, for example:

Then, we can add the screenshots to a Figma project and try to come up with better patterns or guidelines.

Just to give an example. For the screenshots I shared, I don't see a problem with the pattern of having disabled buttons to prevent users to submit. But I think from a design perspective we can improve the button design to allow more contrast and better a11y (#5666.).

As the following article points out, another solution would be to never disable the button: https://css-tricks.com/making-disabled-buttons-more-inclusive/. On clicking the submit button the errors would appear. But I prefer the disabled button version (if the button a11y is in place).

So to tackle this issue we can start by doing an inventory. Then try to come up with better patterns/guidelines or improve the designs.

@gavinwye do you want to create a Figma for this? And then we can all collaborate?

[elizabetdev]

We can follow this template to add the inventory/guidelines: https://www.figma.com/file/tEKAoonjs9hN2pgZJkoVYG/In-product-help?node-id=0%3A1

[dimadavid]

I think we should NOT remove the disabled button in EUI. But we should, in UX guidelines, suggest a better workflow to avoid the usage of disabled buttons IF possible.

[gavinwye]

Hey everyone thanks for the comments.

I've started a Figma file to start auditing these buttons here: https://www.figma.com/file/vU2DfvWdtZDitqhKxoP7L6/Disabled-buttons-in-Kibana?node-id=7%3A8

@miukimiu I've added the screenshots you've added above. I don't know an efficient way to collect all of the other disabled buttons. I've searched the Kibana repo again and found 12969 occurrences of disabled, not all of those are buttons so I probably need a more specific search. Any ideas on how to go about this in an efficient way?

To be clear on my opinions on this I've listed some things below.

Disabled buttons are confusing for users for the following reasons:

1. Users have to know/learn what they need to interact with to make a disabled button not disabled.
2. Because users have to interact with things to make a button not disabled, That excludes people with low digital skills. These people exist in all industries.
3. Causing errors is more helpful to users than disabling buttons.
4. Unless users know what your not disabled button looks like, they may not understand the subtleties of state

I'm much more in favour of the approach of showing an error when a button is clicked that tells users what they need to do to solve that problem. I think it's a better design.

[elizabetdev]

Hi @gavinwye,

I use a lot https://cs.github.com/ for search specific repos. For example you can only search the Kibana repo for euiButton disabled:

This will result in:

But I don't think you need to do a very large audit. Just an idea of how the disabled buttons are used. Then you write the guidelines with the proper usage of disabled buttons and use some of these Kibana examples with the new guidelines.

For example, in our Empty Prompt guidelines, we're using real Kibana use cases: https://elastic.github.io/eui/#/display/empty-prompt/guidelines. This way we ensure EUI consumers follow patterns that exist in our products.

You can also find here a Figma project "In product help" where we have a page with guidelines and other pages with Kibana and Cloud inventories: https://www.figma.com/file/tEKAoonjs9hN2pgZJkoVYG/In-product-help?node-id=1%3A12884.

[cchaos]

@gavinwye I agree with your reasons for not disabling buttons generally for your typical submit/save/form buttons. However, there are instances of disabled buttons that are better disabled as way of indicating functionality that is not available.

For instance, consider an application with a toolbar such as Lens. The user will associate and remember all the specific actions they can perform an any given chart by way of placement of buttons within a toolbar. There are a few options, however, that don't/can't apply to specific types of charts. In this case, disabling the button and present the user with information as to why this action cannot be performed is a better experience than throwing an error in a toast that is far away from the button that would have been clicked.

It's similar to any sort of menu system even in OS's where the menus and options should always stay the same and in the same order, disabling the options that can't be performed.

This is where being distinctive about what the button does and the context in which it is presented will need to be specified when deciding on these guidelines.

[gavinwye]

@cchaos Thanks, I agree with most if not all of that.

I'm talking/thinking here specifically about submit/save/form buttons where users could be left wondering what they need to do to activate a button. I wonder how widely we use that type of button 🤔.