Currency input #68
Currency input #68
Comments
This could be considered a specific implementation of a more generic prefix/suffix component. I've proposed one here |
@fofr great, do you have any research on it? For example do you ever see people try to delete the £, or add another? How does it get read out for screen readers? |
@joelanman It's largely just worked. In a prior version we had a The £ isn't pronounced but some hidden text in the label can keep the currency context, eg "Fee for UK and EU students in £". |
Dropbox Paper auditOn 6th March 2019 the Design System team reviewed a Dropbox Paper document discussing the Currency Input pattern. The aim was to reduce the number of places containing guidance and code by:
If you need to, you can see the original Dropbox Paper content in the internet archive. Currency inputHelp users enter an amount of money in a specified currency. When to use this componentUse the Currency input component whenever you need users to tell you an amount of money in a particular currency, for example pounds sterling or euros. How it worksThe Currency input component shows users which unit of currency they need to enter their amount in. Preventing non-numeric charactersThe component uses input type=”text” rather than type=number to ensure that all users can enter the decimal symbol. The Currency input component has a progressive enhancement that prevents non-numeric input. To use this enhancement, install the numeric input component or include Research on this componentThis component has been tested in a prototype of the Apply for a temporary event notice service. Read more about how the Curcrency input component has been tested and iterated. Companies HouseWe’ve been using the pattern below for a while. Our service is designed to allow users to enter accounts information based on accounts they would have already prepared (that is, they’re pretty much just copying figures from a paper set of accounts into an online set of accounts) - and accounts tend to have the currency declared just once, at the top of the page, so we’ve mirrored that. We’ve not had a single user have any issue around the currency. We’ve tested with a variety of users including those with low digital skills and those reliant on assistive technology (there is some hidden, screen-reader friendly label text on those inputs, for example “Intangible assets 2017 in £”. These hidden labels are revealed on the mobile view.) One or two have suggested a ‘nice to have’ feature would be a persistent header (accounting period and currency) which follows the user down the page, but it’s not a must do for us just yet. |
The HMCTS Design System now has a currency input. We've tried to take all of the comments from the community into account: |
I'm currently working on a project with Skills for Care and we have followed the same approach as @adamsilver by visually differentiating the currency symbol from the input text. |
@Guillermoreno which service was this on? was just looking for the repo to have a look |
Hi @etheya, Capital Gains Tax for Property Disposals |
@MalcolmVonMoJ are you aware that the MOJ Design System already has a currency input component used in a number of services across the MOJ, not least the LAA's Get Paid for Legal Aid? I ask because it varies from the one you highlight. https://moj-design-system.herokuapp.com/components/currency-input |
@whatterz |
Why when I click on the currency sign, the input does not receive focus ? |
@b2whats, good spot. My solution to this will be to z-index the input box above the pound sign, make the background transparent obviously so it still shews through. |
Does anyone have any thoughts on the use of formatting within number fields - particularly using commas to seperate thousands - for example... On the one hand, it makes proof-reading large numbers easier, leading to more accurate input. On the other hand there may be accessibility/UX concerns? There would also be questions about how to present data when the field is in focus. Immediate options...
This question could equally apply to #74 (Number input field) |
You could strip them out after submit to avoid any on-screen jumping. This is easy enough, but there are other considerations. Whilst they are common when typing in large numbers. e.g. 1,000,000, on the other they are used in mainland Europe for the decimal separator. 1,5 for 1½. If we strip them out, a well-meaning European could enter 1,5 meaning 1.5, and inadvertently enter 15. If we error, then someone entering an ordinarily perfectly acceptable 25,000 would be inconvenienced. So by that logic, if we accept them at all, we should only accept them in the -3xth position of the string, from the end or decimal point? I am assuming that we don't want to go down the road of accepting non-UK formats - which sounds like a minefield with the different formats used in India, Switzerland etc. |
Would the approach by the (US, but widely used around the world) National Institute of Science and Technology (NIST) to grouping digits be something to consider? They suggest using a space (or half-space) to indicate groupings:
That may not entirely fix the problem of using period and comma for the decimal point, but would help with display, I think. |
The international standard is ISO 80000-1 |
Thanks Terry - I wonder if that standard reflects common usage, in the UK or elsewhere? At the moment, the GOV.UK style guide position is "For numerals over 999 - insert a comma for clarity: 9,000". |
I mentioned ISO 8000-1 to add information to what Alan (Zeno001) said. I do have an opinion on it. Unfortunately, without a github for the content style guide, I don't think it matters much what we say here. |
Thanks Terry, understood. I think regardless of how we format numbers ourselves, we'll need a way of handling numbers input by users, which may contain a number of separators (if we allow it). I wonder how 'safe' it is to assume that the last-comma-on-the-right is a decimal marker only if there are no more than 2 digits after it? |
We've discussed this issue in our team. I know some services don't want decimal values and just want integers but I think that issue can be handled separately. I'd like to accept comma decimal marker and I'd like rules that are 'safe' as you put it. This isn't just because of how people type or use voice, it's also because of cut & paste. Incidentally, the english-language numeric keypad has a full stop but has a comma in some languages. I think the following are invalid regardless of whether the decimal marker is a comma or full stop:
The following should be valid:
As I said, I'd like to accept a comma as a decimal marker. It's not a the top of my wishlist. I have a bit of fear, uncertainty, and doubt. If somebody can specify a safe design, I'd be up for it. |
What
Help users enter an amount of money in a specified currency.
Why
Anything else
The text was updated successfully, but these errors were encountered: