Input fields - Is more user friendly for credit cards than ?
Basically this question, but with more usability focus:
https://stackoverflow.com/questions/48534229/what-is-the-correct-input-type-for-credit-card-numbers
So we have these two general keyboard layouts (at least that's how they look on my phone).
One is <input type=number>
and the other <input type=tel>
.
Now by the logic they were designed, you would use the number one for credit cards.
But I'm wondering, aren't the buttons on <input type=tel>
much easier to hit for a field where you only need numbers? It feels like all the extra symbols on <input type=number>
are just cluttering the view, you can't use them for this field anyway.
Now the questions are:
Would you consider this a better user experience, even though we'd be using the "wrong" format?
What about possible drawbacks, would this possibly hinder the user in some way?
mobile input-fields mobile-web mobile-text-entry
add a comment |
Basically this question, but with more usability focus:
https://stackoverflow.com/questions/48534229/what-is-the-correct-input-type-for-credit-card-numbers
So we have these two general keyboard layouts (at least that's how they look on my phone).
One is <input type=number>
and the other <input type=tel>
.
Now by the logic they were designed, you would use the number one for credit cards.
But I'm wondering, aren't the buttons on <input type=tel>
much easier to hit for a field where you only need numbers? It feels like all the extra symbols on <input type=number>
are just cluttering the view, you can't use them for this field anyway.
Now the questions are:
Would you consider this a better user experience, even though we'd be using the "wrong" format?
What about possible drawbacks, would this possibly hinder the user in some way?
mobile input-fields mobile-web mobile-text-entry
add a comment |
Basically this question, but with more usability focus:
https://stackoverflow.com/questions/48534229/what-is-the-correct-input-type-for-credit-card-numbers
So we have these two general keyboard layouts (at least that's how they look on my phone).
One is <input type=number>
and the other <input type=tel>
.
Now by the logic they were designed, you would use the number one for credit cards.
But I'm wondering, aren't the buttons on <input type=tel>
much easier to hit for a field where you only need numbers? It feels like all the extra symbols on <input type=number>
are just cluttering the view, you can't use them for this field anyway.
Now the questions are:
Would you consider this a better user experience, even though we'd be using the "wrong" format?
What about possible drawbacks, would this possibly hinder the user in some way?
mobile input-fields mobile-web mobile-text-entry
Basically this question, but with more usability focus:
https://stackoverflow.com/questions/48534229/what-is-the-correct-input-type-for-credit-card-numbers
So we have these two general keyboard layouts (at least that's how they look on my phone).
One is <input type=number>
and the other <input type=tel>
.
Now by the logic they were designed, you would use the number one for credit cards.
But I'm wondering, aren't the buttons on <input type=tel>
much easier to hit for a field where you only need numbers? It feels like all the extra symbols on <input type=number>
are just cluttering the view, you can't use them for this field anyway.
Now the questions are:
Would you consider this a better user experience, even though we'd be using the "wrong" format?
What about possible drawbacks, would this possibly hinder the user in some way?
mobile input-fields mobile-web mobile-text-entry
mobile input-fields mobile-web mobile-text-entry
asked Jan 17 at 12:42
Big_ChairBig_Chair
1,92711026
1,92711026
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
The fields should be configured in a way that directly relates to what data goes into it.
So, in this case, while it might be slightly easier to input the numbers with the tel
format, that's not what the data actually is. You're breaking syntax rules. This has implications on accessibility, among other things. You don't want a screenreader user being informed that the field is a Credit Card field (by the label) but then being told to enter in a telephone number in the field. That's confusing. Not only during the entering of the data but also when the user is reviewing what they've entered.
Also, you can't be 100% sure that all the devices that the page is being accessed on will interpret the Tel in that format. They may end up defaulting to standard text input keyboard.
Keep the syntax correct for the data.
Yep, to my demise I just had to notice that it was an edge case with my special keyboard (SwiftKey). Native Android keyboards seem to display the number type just fine. So everything is working as it should.
– Big_Chair
Jan 17 at 13:01
add a comment |
I find that keyboard type tel is much more convienient for users because it is focused on numbers in their big keys layout. It is also (on Apple) resembles the numeric keypad seen everywhere. It is true that accessibility has a role here and syntax is important but I believe you can find a solution for it.
I found this —> “ Using the pattern attribute, pattern=”[0-9]*”, with the number input type will display the 10-digit numeric keypad similar to the tel keypad“
I like to add this keyboard layout to a credit card masked input field so the user focuses on numbers and no other symbols.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "102"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fux.stackexchange.com%2fquestions%2f123207%2finput-fields-is-input-type-phone-more-user-friendly-for-credit-cards-than-i%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
The fields should be configured in a way that directly relates to what data goes into it.
So, in this case, while it might be slightly easier to input the numbers with the tel
format, that's not what the data actually is. You're breaking syntax rules. This has implications on accessibility, among other things. You don't want a screenreader user being informed that the field is a Credit Card field (by the label) but then being told to enter in a telephone number in the field. That's confusing. Not only during the entering of the data but also when the user is reviewing what they've entered.
Also, you can't be 100% sure that all the devices that the page is being accessed on will interpret the Tel in that format. They may end up defaulting to standard text input keyboard.
Keep the syntax correct for the data.
Yep, to my demise I just had to notice that it was an edge case with my special keyboard (SwiftKey). Native Android keyboards seem to display the number type just fine. So everything is working as it should.
– Big_Chair
Jan 17 at 13:01
add a comment |
The fields should be configured in a way that directly relates to what data goes into it.
So, in this case, while it might be slightly easier to input the numbers with the tel
format, that's not what the data actually is. You're breaking syntax rules. This has implications on accessibility, among other things. You don't want a screenreader user being informed that the field is a Credit Card field (by the label) but then being told to enter in a telephone number in the field. That's confusing. Not only during the entering of the data but also when the user is reviewing what they've entered.
Also, you can't be 100% sure that all the devices that the page is being accessed on will interpret the Tel in that format. They may end up defaulting to standard text input keyboard.
Keep the syntax correct for the data.
Yep, to my demise I just had to notice that it was an edge case with my special keyboard (SwiftKey). Native Android keyboards seem to display the number type just fine. So everything is working as it should.
– Big_Chair
Jan 17 at 13:01
add a comment |
The fields should be configured in a way that directly relates to what data goes into it.
So, in this case, while it might be slightly easier to input the numbers with the tel
format, that's not what the data actually is. You're breaking syntax rules. This has implications on accessibility, among other things. You don't want a screenreader user being informed that the field is a Credit Card field (by the label) but then being told to enter in a telephone number in the field. That's confusing. Not only during the entering of the data but also when the user is reviewing what they've entered.
Also, you can't be 100% sure that all the devices that the page is being accessed on will interpret the Tel in that format. They may end up defaulting to standard text input keyboard.
Keep the syntax correct for the data.
The fields should be configured in a way that directly relates to what data goes into it.
So, in this case, while it might be slightly easier to input the numbers with the tel
format, that's not what the data actually is. You're breaking syntax rules. This has implications on accessibility, among other things. You don't want a screenreader user being informed that the field is a Credit Card field (by the label) but then being told to enter in a telephone number in the field. That's confusing. Not only during the entering of the data but also when the user is reviewing what they've entered.
Also, you can't be 100% sure that all the devices that the page is being accessed on will interpret the Tel in that format. They may end up defaulting to standard text input keyboard.
Keep the syntax correct for the data.
answered Jan 17 at 12:48
JonW♦JonW
30.6k18110148
30.6k18110148
Yep, to my demise I just had to notice that it was an edge case with my special keyboard (SwiftKey). Native Android keyboards seem to display the number type just fine. So everything is working as it should.
– Big_Chair
Jan 17 at 13:01
add a comment |
Yep, to my demise I just had to notice that it was an edge case with my special keyboard (SwiftKey). Native Android keyboards seem to display the number type just fine. So everything is working as it should.
– Big_Chair
Jan 17 at 13:01
Yep, to my demise I just had to notice that it was an edge case with my special keyboard (SwiftKey). Native Android keyboards seem to display the number type just fine. So everything is working as it should.
– Big_Chair
Jan 17 at 13:01
Yep, to my demise I just had to notice that it was an edge case with my special keyboard (SwiftKey). Native Android keyboards seem to display the number type just fine. So everything is working as it should.
– Big_Chair
Jan 17 at 13:01
add a comment |
I find that keyboard type tel is much more convienient for users because it is focused on numbers in their big keys layout. It is also (on Apple) resembles the numeric keypad seen everywhere. It is true that accessibility has a role here and syntax is important but I believe you can find a solution for it.
I found this —> “ Using the pattern attribute, pattern=”[0-9]*”, with the number input type will display the 10-digit numeric keypad similar to the tel keypad“
I like to add this keyboard layout to a credit card masked input field so the user focuses on numbers and no other symbols.
add a comment |
I find that keyboard type tel is much more convienient for users because it is focused on numbers in their big keys layout. It is also (on Apple) resembles the numeric keypad seen everywhere. It is true that accessibility has a role here and syntax is important but I believe you can find a solution for it.
I found this —> “ Using the pattern attribute, pattern=”[0-9]*”, with the number input type will display the 10-digit numeric keypad similar to the tel keypad“
I like to add this keyboard layout to a credit card masked input field so the user focuses on numbers and no other symbols.
add a comment |
I find that keyboard type tel is much more convienient for users because it is focused on numbers in their big keys layout. It is also (on Apple) resembles the numeric keypad seen everywhere. It is true that accessibility has a role here and syntax is important but I believe you can find a solution for it.
I found this —> “ Using the pattern attribute, pattern=”[0-9]*”, with the number input type will display the 10-digit numeric keypad similar to the tel keypad“
I like to add this keyboard layout to a credit card masked input field so the user focuses on numbers and no other symbols.
I find that keyboard type tel is much more convienient for users because it is focused on numbers in their big keys layout. It is also (on Apple) resembles the numeric keypad seen everywhere. It is true that accessibility has a role here and syntax is important but I believe you can find a solution for it.
I found this —> “ Using the pattern attribute, pattern=”[0-9]*”, with the number input type will display the 10-digit numeric keypad similar to the tel keypad“
I like to add this keyboard layout to a credit card masked input field so the user focuses on numbers and no other symbols.
answered Jan 17 at 16:22
MilahMilah
393
393
add a comment |
add a comment |
Thanks for contributing an answer to User Experience Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fux.stackexchange.com%2fquestions%2f123207%2finput-fields-is-input-type-phone-more-user-friendly-for-credit-cards-than-i%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown