Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Select #60

Open
govuk-design-system opened this issue Jan 12, 2018 · 15 comments
Open

Select #60

govuk-design-system opened this issue Jan 12, 2018 · 15 comments

Comments

@govuk-design-system
Copy link
Collaborator

@govuk-design-system govuk-design-system commented Jan 12, 2018

Use this issue to discuss this component in the GOV.UK Design System.

@govuk-design-system govuk-design-system created this issue from a note in GOV.UK Design System Community Backlog (In progress) Jan 12, 2018
@govuk-design-system govuk-design-system moved this from In progress to Published in GOV.UK Design System Community Backlog Jan 12, 2018
@dashouse
Copy link

@dashouse dashouse commented Oct 30, 2018

Collating a few thoughts / experiments on <select>'s

Styled selects

Although the current version of the <select> component in GOV.UK Frontend has some styles it's appearance is largely dictated by the browser default. Therefore a <select> in Chrome will look different to a <select> in Safari, IE, Edge, FF etc. This can cause alignment issues if a select is used as part of a group of components and generally doesn't feel like part of the visual style of GOV.UK.

screen shot 2018-10-30 at 10 42 52

I have an example of a styled select experiment on this codepen

iOS spinner control content cropping

Using the default <select> markup, the options that an iOS user will see will be cropped if they are around 30 characters (it may be fewer on a smaller device - test was done on an iPhone 7).

For this reason options should be front loaded to emphasise the differences.

Prefixing options like this:

  • Cool black t-shirt with GOV.UK Logo - Size M
  • Cool black t-shirt with GOV.UK Logo - Size L

has a greater chance of the important information being cropped off than if you front loaded the information that made the options different.

  • Medium - Black GOV.UK Logo T-shirt
  • Large - Black GOV.UK Logo T-shirt

The <optgroup> hack

You can force iOS to "shrink to fit" the full text of every option in a <select> by adding an empty <optgroup> to the the list of options. Of course if you are genuinely using <optgroup>'s in your <select>'s then this will also just work.

dnxqabmx0aaaznz

There is an example of this on this codepen

Please note the <optgroup> itself has a physical size so if you add an empty <optgroup> you will see an extra space at the bottom of the <select>. In this example I have used display: none; to remove this.

Legend > Radios / Checkboxes alternative to <select>

This idea is purely a conceptual untested experiment

As many of the usability issues of <select>'s are around the behaviour of the native HTML component, if you genuinely need to collapse a group of options creating a custom select component could be an option.

This is a quick example I put together which could progressively enhance a <legend>, <fieldset> using JavaScript to reveal a group or radios or checkboxes.

select-radios

@36degrees
Copy link
Member

@36degrees 36degrees commented Oct 30, 2018

Although the current version of the <select> component in GOV.UK Frontend has some styles it's appearance is largely dictated by the browser default.

Note that there was a previous attempt to style the select element but it was never merged because we found there were issues making the (recreated) arrow indicator visible in browsers where the user had overridden colours.

@sanjaypoyzer
Copy link

@sanjaypoyzer sanjaypoyzer commented Dec 11, 2018

Can we add some examples of when it is okay to use a select component? Or if we don't have any, we should more explicitly say 'We have not seen any examples of a select component being necessary'.

At the moment the current guidance "select should only be used as a last resort" seems a little vague.

@joelanman
Copy link
Member

@joelanman joelanman commented Dec 11, 2018

It's a good question. The idea of the current guidance is to try other things before using a select, as we know they have various problems.

I think there's a good example of usage on Find a job (via @dashouse)

image

I'm referring specifically to the 'sort by' select. Caveat - I haven't seen any research on this particular example.

In this case, there is not much space to use radios - they would push the main content down the page a lot.

The select has the 'right' number of items in it, few enough that you don't need to scroll within it, which is a problem for users. But more than two, which would probably be better as radios.

Finally, the 'sort by' control is where users might expect it, from using other sites - at the top right, so redesigning the control and placing it elsewhere might not be a good option.

@sanjaypoyzer
Copy link

@sanjaypoyzer sanjaypoyzer commented Dec 11, 2018

Subtly suggesting I should go get a job somewhere else with that link? 😉

I think there's a couple of options that are available to Find a Job here - One being to have radio buttons over on the left-hand side with the filters, the other being to have a horizontally aligned list, like a nav bar, in place of the select. In terms of accessibility, I would have thought the first would be better as then the filter/sort tools are grouped together which lets people refine what they are looking at it in the same place.

@edwardhorsford
Copy link

@edwardhorsford edwardhorsford commented Mar 5, 2019

I'm pro avoiding selects, but we should keep in mind that there were a variety of issues uncovered in that research, and selects aren't always so bad. You're often balancing competing constraints and in some situations they may be the most appropriate component.

Skimming Alice's video, and from memory, the issues with selects were:

  1. Users not knowing they could scroll a select
  2. If users type, and type slowly, the position might get reset
  3. Options might get truncated
  4. Issues with hover / focus / knowing which item is selected
  5. Where users try to type an answer that's not in the right format
  6. Pinch zooming issues?

Issues 1-3 aren't a problem when there's very few options of a known length. I hazard 5 wouldn't be an issue if there were a pre-selected value (such as in sort-by filters). 4 and 6 might remain an issue - though I wonder if fewer options might help people know when they've not selected an item - as might auto-submitting.


A custom component like what @dashouse suggests above would be great. It might be able to accomodate multiple items being selected too?

FWIW my service is using the the autocomplete with showAllValues to essentially simulate a select. A simpler component would be great to have.

@edwardhorsford
Copy link

@edwardhorsford edwardhorsford commented Mar 5, 2019

I came here looking for more guidance on using the select component.

I'm using it temporarily in my prototype to simulate the autocomplete with showAllValues.

I'd like it to be blank initially, and then let me pick from options. Regular selects can do this, but I can't see how you'd do it with the component.

I can see in the nunjucks that selected: true can be set to pre-select a value - is this function documented anywhere? Pre-selecting feels relevant for sort-by filters, but for general use we'd normally not recommend pre-selecting something.

If I don't preselect a value, it seems to default to the first value - how do I get it so I get a blank first entry? Skimming stackoverflow it sounds like some combination of disabled and display:none on the first option is the answer. Does the component support this?

I'd approximately like this:
select-blank

@edwardhorsford
Copy link

@edwardhorsford edwardhorsford commented Mar 5, 2019

One more from me!

Widths of selects - is it ok to use a width override?

Below our mobile breakpoint we set inputs and buttons to full width - but not selects. Is this intentional?

Adding govuk-!-width-one-half seems to work - it goes full width below the breakpoint.

@edwardhorsford
Copy link

@edwardhorsford edwardhorsford commented Jun 25, 2020

I'd like to suggest the guidance on selects be improved.

It doesn't give details about the usability issues GDS originally found (back in 2013 now), but more importantly, those issues all apply to long lists in selects, not small lists.

The guidance states "The select component allows users to choose an option from a long list." - but selects don't have to be for long lists. Indeed the example in the design system (sorting) is a good use for selects and is not a long list.

I'm not aware of any usability issues when there are a small number of options in selects. Often, radios may present a clearer choice - but that's quite different than "only be used as a last resort"

@GrilloPress
Copy link

@GrilloPress GrilloPress commented Jul 23, 2020

The other examples for radios, checkboxes have an example in error. But select does not. It'd be great to have one.

Particularly as the error state uses a different class for errors. "govuk-select--error"

@36degrees
Copy link
Member

@36degrees 36degrees commented Jul 24, 2020

The other examples for radios, checkboxes have an example in error. But select does not. It'd be great to have one.

Particularly as the error state uses a different class for errors. "govuk-select--error"

There's an issue to do that – alphagov/govuk-design-system#1049

The problem we've run in to when trying to add an example is coming up with a realistic scenario where it both makes sense to have an error state and it fits with the usage guidelines. The example used elsewhere on the page is for sort order, where it doesn't really make sense to have an error as there would always (?) be a default sort order.

If anyone has a good example from the service that we can use as an example, please add it to that issue.

@terrysimpson99
Copy link

@terrysimpson99 terrysimpson99 commented Jul 24, 2020

joelanman wrote:

I think there's a good example of usage on Find a job (via @dashouse)

image

The example of 'Find a job' may illustrate a point about 'select' but it's not a good example that scales out to UI in general. It uses two forms of concatenation:

  1. Linking label text to value such as 'Show [x] per page'.
  2. Linking two label/value combinations. In this case with the term 'and'.

Each of those constitutes a language-dependent design and is best avoided.

@haggishunt56
Copy link

@haggishunt56 haggishunt56 commented Jul 30, 2020

"The problem we've run in to when trying to add an example is coming up with a realistic scenario where it both makes sense to have an error state and it fits with the usage guidelines."

I'd like to include an error on this component if a user leaves it blank. It's a mandatory field however I can't highlight it if they dont select an option from the drop down. Am I using the correct component?

@GrilloPress
Copy link

@GrilloPress GrilloPress commented Jul 30, 2020

Appreciate the select is a "last resort" but I think trying to find a perfect example of a good select as the criteria for an error is a tough one.

It might just be a case of finding an internal system example, where in a high density screen it would feature without a preselected value and just use that.

@joelanman
Copy link
Member

@joelanman joelanman commented Jul 30, 2020

@haggishunt56 in many cases radios (single select), or checkboxes (multi select) are simpler options that work better for users than select

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants