Site A: Ah ah ah! You put a slash in your date! No soup for you!
Site B: Ah ah ah! You didn't put a slash in your date! No soup for you!
The internet is constantly getting better and I don't think we give that progress we've made in web design over the last few decades enough credit.
Just imagine how bad it used to be to just purchase a simple thing on an ecommerce site in the mid 2000s. Or remember what car websites used to look like vs what they look like now. Even newspaper websites like NYT are leaders with quality design.
It's easy to complain about those who still don't get it, but I feel like we've also made massive progress from the early wild-west days of the internet.
Still, I'm all for shaming those sites who still make inserting credit card numbers a pain in the ass.
lingscars.com ?
That's some real artisanal HTML right there. <3
Side note: anyone remember "I knows me some ugly myspace" from Ze Frank?
Disclaimer: I'm not english, and only half german.
We've reached a point where it seems like the amount of people who know react looks pretty close to the amount of people who know CSS. CSS wasn't even a thing when I built my first site, and now the phrase "web design" isn't even really in the vernacular today.
I'm not asking anybody to get off my lawn or anything, it's just interesting.
A non-numeric text field is so much easier, and you should also be able enter your birth year as Roman numerals (which is even easier for millennials).
Won't pattern="[0-9]*" do the exact opposite of what you're suggesting?
Flexibility is key here and since many websites handle things differently (and since many of the physical cards have literal dashes on them, which they are looking at when inputting the numbers), you should be able to guide your user into the right format without them having to get error messages or other nonsense.
Not enough web designers appreciate the anxiety of having to input a credit card number or other format-varied content into input boxes.
If you have Japanese users, their browser/input method editor may send full-width characters by default, such as 4321 instead of 4321. You should probably honor those, but unless you wrote code to do this, you almost certainly won't. Even most Japanese sites are user-hostile here, either failing to detect them as numbers or telling the user "You wrote your number in full-width characters; please try again in half-width characters" despite them being trivially convertable.
(Disclaimer: this is professionally relevant to me and yes, Stripe Elements / Checkout do do the right thing here.)
You can attempt to infer intent or meaning based on the context of the input field but often the least-problematic method is to provide instruction/hints with the field, examples of correctness, and real-time validation with specific syntax errors when invalid or unexpected data is provided. I'd argue that it would also be worthwhile to request clarity from the user when an input hits a filtering rule so that they can make clear their intent... e.g. if you assume that they're using "-" as a symbol for separation rather than simply follow that assumption, ask if that's the case and list other optional valid contexts for that symbol so they can be explicit. If they choose None of the Above or a context that is inappropriate for the field, inform them of that.
The 4-box credit card form, while pretty terrible in many ways, at least made explicit the expectations. Often we now hide the expectations and either auto-reformat what was put in the field (which can be surprising to the user or worse can modify their input to mean something other than what they intended) or do hidden filtering, which can have the same problems but doesn't even bother to inform the user of the changes.
So what? I can't imagine any possible way it would be unclear whether someone entered a credit card number or a negative number. They have different numbers of "-" in completely different places. Am I missing something?
> I'd argue that it would also be worthwhile to request clarity from the user when an input hits a filtering rule so that they can make clear their intent... e.g. if you assume that they're using "-" as a symbol for separation rather than simply follow that assumption, ask if that's the case and list other optional valid contexts for that symbol so they can be explicit. If they choose None of the Above or a context that is inappropriate for the field, inform them of that.
That sounds like such bad usability I'd assume you were joking if the rest of your post didn't sound so serious.
What I'm advocating is a focus on ensuring the user's explicit intent rather than attempting to infer intent or making hidden assumptions that either could be wrong or exist to make things easier for the developer.
Too many times I've had to deal with data that someone optimistically sanitized or filtered client-side and then stored, only to discover the sanitizing/filtering rules were wrong and the original data provided by the user was lost because the only thing stored was the result of those rules.
Not your entire post, but the part about the '-' key was pretty specific and narrow-scoped.
> What I'm advocating is a focus on ensuring the user's explicit intent rather than attempting to infer intent or making hidden assumptions that either could be wrong or exist to make things easier for the developer.
'explicit intent' sounds like a nice goal but asking the user inside the form is not going to give you good info, and it will very often annoy them.
> only to discover the sanitizing/filtering rules were wrong and the original data provided by the user was lost because the only thing stored was the result of those rules
It wouldn't hurt to store the original. Even if the user told you what they meant, they might have said the wrong thing.
I have had to deal with localizing date inputs though. Ugh.
For example, afaik, the standard way Chinese dates are written is something like "2020Y02M28D" but with the Chinese characters (words) for year, month, and day, instead of Y, M D. I find this totally beautiful: it doesn't take up more space than "-" or "/" or "." as a separator, and it totally disambiguates the meaning. (Well, there is the trailing "day", so we are losing one character.). It is such a wonderful use of the fact that Chinese is using ideographic characters. Isn't it?
But it goes beyond "this is what they do". Users tend to do a wide range of things when entering dates and you kinda have to guess what they mean. Throw in guessing what localization should be used (it's not always clear) on top of that fuzzy system and it can become a frustrating experience for everyone involved.
I feel most of these things should be solved by browsers, not designers...
Problem is for something like credit card every single browser vendor will try to plug their own service in one way or another (think Apple Pay and Android Pay).
In our research it's commonly most often helpful to validate when the user submits as that's when you can be sure they're 'done'. There are cases when realtime helps so it's fine to add it in those situations.
Because you can't enter spaces, they don't get submitted, and validation doesn't fail.
As long as they don't also do 'class="nopaste"' or whatever, we're golden!
I'm a bit older than the average HM demographic, so using a date picker to scroll back many years might take hundreds of clicks. Then I made a mistake (details long forgotten) and the whole thing reset and I had to start again. On the third time around I just quit.
Don't make hundreds to millions of users do extra work that could've been automated with a little more care.
EDIT: Also more widely supported than https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
Inputmode isn't supported by most desktop browsers but it doesn't need to be. Every mobile browser save mobile Firefox supports it.
...I wonder what's up with Mobile Firefox?
I apologize if you already know this, but to make sure we're on the same page: what "inputmode" does is tell phones to display the onscreen keyboard as a numpad, instead of a full set of QWERTY letters and numbers. Outside of a few edge-cases, you don't generally need that on desktop.