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

Text input #51

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

Comments

@govuk-design-system
Copy link
Collaborator

commented Jan 12, 2018

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

Related issues

#134 Add prefixes and suffixes to form inputs

@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

@timpaul

This comment has been minimized.

Copy link
Contributor

commented Apr 10, 2018

If this component is also intended to be used for things like decimals, emails and telephone numbers, should we rename it to 'Input'? @nickcolley ?

@joelanman

This comment has been minimized.

Copy link
Member

commented Apr 10, 2018

Problem is, if we're trying to follow the html naming where possible, input is a lot of things including radios and checkboxes. This is input type=text, so 'text input'? I think decimals, emails, phone numbers are all people entering text

@timpaul timpaul added the component label May 21, 2018

@soniaturcotte

This comment was marked as resolved.

Copy link

commented Jul 20, 2018

The example for the govuk-input--width-3 says CVV.

On GOV.UK Pay, we found from research that CVV isn't very meaningful to people. "Card security code" performed much better in user research. In addition, card security codes can be 4 digits for AMEX cards, so maybe the entire example isn't so good in this case.

I'm not sure if this matters at all since it's just an example of how to change the size of the inputs.

@nickcolley

This comment was marked as resolved.

Copy link
Contributor

commented Jul 20, 2018

We try to make sure the examples always make sense, since people may copy and paste them, so that sounds sensible to update that.

I guess we'd just need an example for 3 characters to replace that one.

@stevenaproctor

This comment was marked as resolved.

Copy link

commented Jul 20, 2018

@nickcolley Tax office number is 3 characters.

@charge-valtech

This comment was marked as resolved.

Copy link

commented Aug 22, 2018

The example for this should probably have the correct type="email" in both the HTML and Nunjucks snippets. Or maybe don't use email as an example. Lots of people will be copy and pasting this example without the correct type.

36degrees added a commit to alphagov/govuk-design-system that referenced this issue Aug 22, 2018

Use simpler default example for text inputs
Change the default example for the text input component from an input asking for an email address to an example asking for someone’s full name.

As raised in the backlog [1], we are not currently using the correct `type=“email”`. We could fix this, but as users are likely to take this ‘default’ example and modify it to ask different questions, it makes sense to make it as generic as possible, avoiding using a type specific to a particular type of input.

Therefore changing to a more ‘generic’ question, such as full name, which does not require specific input types, makes more sense.

[1]: alphagov/govuk-design-system-backlog#51 (comment)
@36degrees

This comment was marked as resolved.

Copy link

commented Aug 22, 2018

The example for this should probably have the correct type="email" in both the HTML and Nunjucks snippets. Or maybe don't use email as an example. Lots of people will be copy and pasting this example without the correct type.

Good spot, thanks Henry! I've raised a PR to change the default example for the text input component to ask for full name instead.

@36degrees

This comment was marked as resolved.

Copy link

commented Aug 22, 2018

The example for the govuk-input--width-3 says CVV.

On GOV.UK Pay, we found from research that CVV isn't very meaningful to people. "Card security code" performed much better in user research. In addition, card security codes can be 4 digits for AMEX cards, so maybe the entire example isn't so good in this case.

I'm not sure if this matters at all since it's just an example of how to change the size of the inputs.

@soniaturcotte We've replaced the labels on the example inputs with 'non-realistic' labels that just denote the width of the input, so 'CVV' became 3 character width. Thanks for raising! 👍

@36degrees

This comment has been minimized.

Copy link

commented Aug 22, 2018

As raised by @edwardhorsford in Elements, our text inputs don't currently have a disabled style (this is still the case in GOV.UK Frontend):

Similar to alphagov/govuk_elements#367, should we provide styles for disabled inputs? With our current styles there will be no visual difference if an input is disabled, which is not good.

Services will either have inputs that are identical but don't actually work (confusing) or come up with their own designs (inconsistent.

We do not recommend the use of disabled elements, but that doesn't mean they won't be used. There may also be situations where they can't be avoided - a 3rd party payment interface, for instance.

How would you expect it to work?

Disabled textboxes should have some visual difference when disabled.

How does it work currently?

Disabled inputs look identical to non-disabled inputs

Feel free to suggest a fix...

An example with the colours knocked back and a grey background applied.

screen shot 2016-12-07 at 11 29 57

There is more discussion about this in the original issue.

@edwardhorsford

This comment has been minimized.

Copy link

commented Feb 4, 2019

A couple thoughts on inputs from me.

1. Pattern naming

I consistently look to input to find the pattern, not text input - I wonder if any others struggle to find the pattern?

2. Input width classes

I keep looking for width classes in style / layout, not in this one pattern. Presumably the width classes apply to more than just text inputs - textareas, autocompletes, selects. Should / could helper classes live in the styles section?

3. Text width classes

Do we have use cases for the fluid width classes? If inputs are meant to be sized appropriately to their content, when do we expect fluid to be used?

Long ago we had discussions about recommending fixed widths (or min widths) on inputs - I wonder if we could consider this again? If we do, ideally we'd include widths wider than 20 characters. At the moment, on desktops the fluid classes provide a greater range of choices.

4. Fixed width classes

I wonder if naming them by characters is correct? Talking with @dashouse he told me this is measuring the width of the widest possible character - presumably w or m. At the moment this may lead to our users choosing a wider input than needed if they're accepting numeric input only.

Example: my service has users type in a 6 digit 2fa code. Going by the available classes, 10 character width is the closest. But in reality 5 character width is good for us.

Dave also mentioned that they're sized to allow a bit extra width because some browsers add icons in the inputs - I wonder if this should be mentioned in case some users pick a smaller one that visually works, without realising what needs to be allowed for.

IMHO if it was clearer how many numeric characters and how many latin characters each supported, users could pick the right one.

Update @dashouse mentioned on Slack that fixed width classes were also in the styles section, which I'd missed - I don't think I expected them under 'spacing' - I see they're in search so I should probably rely on that more. I'm curious why they don't include the fixed width styles - which to me are the more useful ones.

@36degrees

This comment has been minimized.

Copy link

commented Feb 28, 2019

I'd like to propose a new modifier that increases the tracking on an input, useful for situations where we expect a user to be 'proof-reading' a character at a time, such as when entering a reference number from a document.

Example usage might look like:

<input  type="text" name="reference-number" class="govuk-input govuk-input--extra-tracking">

Without modifier

localhost_3000_components_input_extra-tracking-reference_preview 1

With modifier

localhost_3000_components_input_extra-tracking-reference_preview 2

You can also play with a preview here: https://govuk-frontend-review-pr-1222.herokuapp.com/components/input/extra-tracking-reference/preview

This is based on work by @quis in alphagov/notifications-admin#1545.

I've raised a PR to introduce this but it could do with testing in a few services before we roll it out.

Is anyone else already using something similar in their service?

Is anyone interested in trying this out on their service? Ideally where there is an opportunity to observe how users react to it in user research and/or there's analytics in place where we might be able to see a drop in error rates?

Potential risks:

  • Users misinterpreting the extra tracking as additional spaces that they then try to delete.
  • Users confused because of the different way we present numbers (especially noticeable with 1s)
@edwardhorsford

This comment has been minimized.

Copy link

commented Feb 28, 2019

I really like the idea! I could see it being used for 2FA code fields too.

I share a concern about people thinking there's a space in there - perhaps the tracking could be reduced until we think that's much less likely?

@lauriejones

This comment has been minimized.

Copy link

commented May 24, 2019

Hi! I am a big fan of the govuk design system and reference it often when working on my own system.

I have a question about the fixed width inputs:

Why are the widths defined in ex units?

Before inspecting the inputs in devtools I had expected to potentially see ch units, but was wrong!

Is the height of a lowercase x more similar to the average width of a character than the width of a 0?

Playing around with this myself I quickly noticed that box-sizing, border and padding makes what would be a delightful solution of the number of characters being used directly in the width impossible. 😞

@dashouse

This comment has been minimized.

Copy link

commented May 28, 2019

@lauriejones It's somewhat dependant on the font itself, we also expected ch to be more accurate but had a closer result with ex in our situation. We did this considering the worst case scenario using all cap W's and an extra 10px or so for Safari's autocomplete icon, so we generally overestimate the size.

@lauriejones

This comment has been minimized.

Copy link

commented Jun 7, 2019

@dashouse thanks for the reply! I am at the point where I am looking to implement character-based widths for our inputs and I am having some issues for (extremely) zoomed in users. Is the only solution for that to just add a bit of "give" in the widths?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.