Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Text input #51
created this issue from a note
in GOV.UK Design System Community Backlog
Jan 12, 2018
The example for the
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.
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.
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):
There is more discussion about this in the original issue.
A couple thoughts on inputs from me.
1. Pattern naming
I consistently look to
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
Example: my service has users type in a 6 digit 2fa code. Going by the available classes,
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
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:
You can also play with a preview here: https://govuk-frontend-review-pr-1222.herokuapp.com/components/input/extra-tracking-reference/preview
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?
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
Before inspecting the inputs in devtools I had expected to potentially see
Is the height of a lowercase
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.
@lauriejones It's somewhat dependant on the font itself, we also expected