New answers tagged

1

C#and javascript both have a few good tools for converting number formats... if you can get the country/language iso code from the user or site (eg "de-DE" for Germans), this is easy to do... C#, for instance, has the CultureInfo class for this purpose... User goes to your site (eg. with "/de-DE/" somewhere in the URL) User enters his value in his format ...


0

On the input side I would leave the thousand separator, and allow only numbers and decimal separator based on the language settings of the current user, but store the values in a unified way eg: allow 1000.0 (as 1000) and store as 1000.0 allow 1000,0 (as 1000) and store as 1000.0 On the output side you can again rely on the language settings. And can ...


1

One way to resolve this is to not make people enter decimal periods. Reject any non numeric input and let people choose the unit (meter, centimeter, etc). For dates, use a date picker rather than a textbox. The risk of using user's locale setting is that if people are sharing information (e.g. in support forum/wiki) about how to enter fractional inputs, ...


2

Regarding input: do your users really need to type thousand separators manually? If no (which is the most likely case), I would treat both . and , typed into the field as a decimal point and allow only one symbol of that kind for that value. Regarding output of the values: IMHO, it is better to rely on OS formats by default, but to provide possibility to ...


7

I would suggest using the E.123 number unless your audience is purely USA based. That way, us poor internationals don't have to guess about how to call a number. +1 800 555 1234 since then it'll work on every phone, worldwide* http://en.wikipedia.org/wiki/E.123 Bitter experience of working for multiple USA based companies who have large address Exchange ...


9

Although option 1 is used most often, I would argue that the concept of an "area code" is pretty much deprecated by cell phones. Now we simply have 10-digit phone numbers. many areas of the United States (and, I'm pretty sure, all cell phones) mandate 10-digit dialing, so the idea that the first three digits might be optional is also outdated. For these ...


59

I agree with you that the first is best. Good UX is largely about reducing the cognitive load of a user. (###) ###-#### is a format that, in North America, is unique to phone numbers, so I know as soon as I see the format that this is a phone number. At first glance, if I just see {several numbers} {hyphen} {several numbers}... well, this could be a social ...


10

Option 1 has the following characteristics, making it the preferred choice: It's Conventional The Wikipedia page for "National conventions for writing telephone numbers" states: The traditional formatting convention for phone numbers is (NPA) NXX-XXXX, where NPA is the area code and NXX-XXXX is the subscriber number This is probably why you feel ...


1

We have faced the similar issue recently. We deal with client from multiple timezones & everyone wants date to be displayed in their own formats in reports. So we ask for default date display format on creation step & display date accordingly on every report. For a date which is meant to be consumed by a user only, I think it's best to spell out the ...


0

I'm a proponent of using ISO dates (YYYY-MM-DD) because this ambiguity is so annoying. This is generally understood, though it is not hugely common outside technical applications. Even if it is not the most widely used way of displaying dates, I think it is worth pushing because it is a clearly superior solution. It also has the virtue of resulting in ...


0

Require the input to have a single dot followed by exactly two digits, with no commas. But allow the user to type multiple dots and commas into the field. If these requirements are not met when the user clicks outside the box, reject the input and show a text error so the user must manually remove stray commas and put a dot and the number of cents. A note ...


0

I tend to use autoNumeric for number input fields, always I set it to accept both comma and dot/period/whatever you call it as decimal separator, without any thousands separator (seriously, who whould even use it in input?) Unfortunately even if you set it up to accept comma as decimal separator when you paste number using comma it just drops it (I'm ...


6

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 ...


23

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 ...


25

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 ...


1

I had the problem with an app for German users in the past. I sticked to the dot notation (for computers) and wrote a js to transform all commas to dots (no need to type the 1000s delimiter, the js would display whitespaces for that). I wanted to make sure that no comma reaches the backend server. There were different respones by the users. Some did not ...


52

Another option would be for the text field to ignore all non-numeric characters, and display appropriate formatting automatically. For example: 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' User ...


4

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 ...



Top 50 recent answers are included