It may very well be universally understood but I would be concerned (or at least keep in mind) the user's reaction to this symbol. Would a Russian (a patriotic Russian) be happy to see money be symbolized by the US dollar?
Is there any chance that he may think poorly of your site / app for using the dollar sign?
I don't know your customer base but at first ...
Context matters a lot here.
Like others mentioned, localization and your primary userbase should inform you whether to use $, €, £ or ¥ as 'standard' symbol. It might also be possible to do a location-check (via GPS, or IP) and display whichever icon is most appropriate.
If you don't know your userbase's location or currency, you could choose to go with ¤, ...
Another option would be for the text field to ignore all non-numeric characters, and display appropriate formatting automatically.
User enters '3' -> Text field displays '0.03'
User enters '4' -> Text field displays '0.34'
User enters ',' -> Text field displays '0.34' (no change)
User enters '5' -> Text field displays '3.45'
Surely the best symbol for currency that will be universally understood would be a note and coin as every currency uses both paper notes and coins most currencies use banknotes and coins.
Given this is a simple symbol for "currency", agnostic to culture, the great majority wouldn't have heard of cryptocurrencies, and may have once heard of Bitcoin so they ...
Let's talk for a minute about user expectations and magic.
A user comes to your tool with certain expectations, and not every user's expectations are the same. You're seeing this first-hand. Culture, up-bringing and life experience all shape how a user will interact with a tool, opening a vast array of expectations to potentially meet.
One expectation ...
Show the user what's expected visually and show how the machine interprets the user's input.
My contribution to the brainstorm would be:
Use a reference to the cheque-form of the old days :)
Let the computer ignore all comma's and periods that the user enters (for that matter: non-numerical characters)
Show (if you're able to) an image in the background ...
Historically, this question has been debated for quite a long time.
There is a "Generic Currency Symbol," which looks like "¤" which has been used since at least 1985, where it was included in ISO 8859-1 (Latin-1). In theory, that is the symbol you want. However, I have never seen it used outside of reading about the code pages themselves, so that just ...
You can do whatever you wish basically, as long as you provide a way to verify the input. I would personally dynamically display --next to the input field-- the amount at least partially written out, like
[ 123.45 ] (123 US dollars, 45 cents)
[ 123,45 ] (123 US dollars, 45 cents)
[ 123,456.78 ] (123 456 US dollars, 78 cents)
[ 123,456 ] (123 456 ...
The answer is simply
of course, absolutely not
and it's surprising there is so much humming-and-hawing about it here.
It's an extremely US-centric idea, it's "just silly" if you will. Indeed the dollar symbol is often used in say political cartoons, financial cartoons, very much as a symbol of the US broadly.
If (for some reason) you wanted to use one ...
Lots of people have given good reasons. I don't think you'll get many Russians growing too irate at the $ sign but it is an interesting thought.
Another possible problem with the $ sign is it could lead people to thinking costs are in dollars. Which dollars is this? It needs to be clearly said or else you could get a particularly ignorant Australian not ...
I'm from a country that is not using dollars as a currency. Creating an app depicting money using $$$ symbols would be silly. I mean if you are 10 years old, making an app for friends, then go for it. But if you are a professional and don't want other people laughing at it simply forget about it.
Depicting money as green bills or gold coins would be OK, ...
You should be fine using flags. If you look at the list of currencies, the names are usually made up of a country name and currency (Singapore dollar, Russian ruble, Swiss franc).
Some places use currency that does not originate form a country. For example, most Caribbean countries use the East Caribbean dollar. The Euro is another example. Using the union ...
Locale is what this question is about. The fact that your users have to handle US dollars, does not mean they will do so in the locale of the 'owner' of this particular currency unit (USA). Date formats are another example of how different locales can render a value in ways that are ambiguous without knowledge of the locale the value was rendered in.
How a ...
Of course not every country in European Union uses Euro as a currency. I guess though it shouldn't be a problem, as people don't identify themselves with EU flag.
Qualitative test would resolve your problem.
A reasonable rule of thumb "remove everything you don't need" could be extracted from Nielsen's heuristic Aesthetic and minimalist design
So flip the question around and ask why you would need to display cents if the data is a round dollar value? Two reasons I have to hand
Maintain the consistency usability heuristic
download bmml ...
To non-dollar users, the '$' is understood as a foreign dollar of some kind, just as the Netflix icon for many people in the world gets recognized as the universal symbol for a movie that is "not available in [their/your] region".
You can say "patriotism" is the cause (as the accepted answer seems to have), or you can say pavlovian training is the cause,...
The UX solution is to make it error free for the users no matter what format they're used to. Nothing more. Nothing Less.
I would recommend that you look into regex type solution:
make certain there are two digits after the comma (add a 0 if necessary)
then strip out all non-digits
then add the decimal point.
Aside from the localisation issues, ¤, $, £ etc. are symbols of currency, not money. Since the stated goal is to create an icon depicting an invoice, how about simply using a basic calculation, for example:
download bmml source – Wireframes created with Balsamiq Mockups
download bmml source
The banking site I use in Belgium only allows you to input the decimal notation but not the thousands separator.
It accepts either a single comma or a single dot for the decimal notation, but nothing else can be input.
I've done some more testing of how they treat the input field.
You can only use , or a . once for the decimal notation, no thousands ...
I realize this is a bit old, but it appears that the 'answer' is -($#.##) ??? I was looking for a clear -$ -$ for non accounting here, but this struck me as odd.
I agree with the localization 'answer' and RED as not inherent to 'negativity' as well. But generally, (aside from the numeric and decimal placeholder), a set of () in finance/accounting denotes a ...
Remember that a bad user experience is all about Expectation vs Outcome Mismatch
So when a user is entering into an input field, he just expects to fill the field, but when it gets masked automatically(outcome), there is an expectation-outcome mismatch. And hence the irritation.
A simple solution to this is providing a good PLACEHOLDER with the
The $ is universally accepted as being US dollars. The Euro or British Pound use a different symbol. Usually, it's used to show an amount for when you want to buy something. If I see symbols like €, £ or ¥, I know to look up the conversion rate to figure out how much $ will be coming out of my bank account. Use $ if you want to get paid in US dollars. If you'...
They are neither language nor currency dependent, at least not solely. They are locale specific, which is a combination of language and location. So the best UX is to not rely on language alone, but check the user's locale and format the currency according to their preferred formatting. In your example of displaying USD to a French user, check what kind of ...
In general try to avoid errors, they're the UI of last resort in my opinion. If there's anything that can be handled by system logic to avoid errors that should be the go to solution. Also avoid forcing them into a particular formatting. Try to anticipate the formatting they'll use, the microinteractions, and design your system around that.
A question for ...
Fixed Decimal Benefits
Reduced Input Errors
Requiring no decimal reduces syntax error handling. The input is limited to 0-9 numeric characters and delete/backspace. So you help avoid cases like “54.2.89” (multi-decimal) or mistype of decimals.
Requires No Decimal (or Comma)
Sticking to digits 0-9 means you only need to use the top row of the keyboard.
< $0.01 might be another option to consider.
It uses the "less than" symbol, which is possibly more familiar to people than the "almost equal to" symbol. However, it may require a bit more processing to understand, as it's showing a value that is further from the actual value it represents (0.01 vs 0.00).
So how can we decide between ≈$0.00, ∼$0.00, or &...
This is a really great question. However, I think we need more information about the actual experience you're trying to build to give you an adequate answer.
I'd start by thinking about your users' goals. Are your use cases dependent on precision? Are they trying to analyze a massive list of these tiny amounts of currency? In many foreign exchange ...