131–140 of 206 posts
I believe there's an algorithm to determine if a card number is valid (before determining if the other credentials are correct). Implementing that would probably be the most useful thing you could do in Skeuocard, as it helps people find typos in an otherwise inscrutable list of numbers.
Upvoting because this is so beautifully executed and I'd love to see people test this out on their checkout process. That said, my experience indicates that this is not going to convert well. To mirror the author's own quote: "Every question a user has to ask themselves during the checkout process is another reason for them not to complete it." What's presented here is a drastically different experience from the norm…
Earlier quoted context omitted.
Hi Ken, it looks great! Unfortunately, for unrecognised card types it makes it impossible to proceed. I have just tried a maestro card number (beginning 6759) and am unable to enter any of the additional details (expiry, etc). It may be worth adding a generic fallback for cards that are not recognised to account for unexpected edge cases. Keep up the good work!
GREAT CATCH! Thank you. I totally missed Maestro Card as a product. I'll get it added ASAP. The fallback is a good idea, too! Glad you liked it :)
http://en.wikipedia.org/wiki/List_of_Issuer_Identification_N...
This is a great step up from that. The one thing I felt was not perfect was the multiple entry boxes for the different card types. Erasing/backspacing is not so easy. I would suggest a single entry field, and do something about adding padding spaces automagically. This also plays in to the auto-complete/form fillers these days. A credit card number is a single number, not 4 groups of numbers you copy and paste independently.
Upvoting because this is so beautifully executed and I'd love to see people test this out on their checkout process. That said, my experience indicates that this is not going to convert well. To mirror the author's own quote: "Every question a user has to ask themselves during the checkout process is another reason for them not to complete it." What's presented here is a drastically different experience from the norm…
Thank you for being willing to test it! This isn't something I'm making money off of, nor is it something I feel the need to ram down people's throats -- I just wanted to try something people hadn't seen before. If it works, and people like it, great! I'm glad to have helped a little. Please let me know if you run into any trouble (my Twitter and email are on the site).
But I liked the concept. The "flip over for CVC" worked for me on Firefox, and that was an elegant solution. I think a lot of the criticism could be avoided by just making it static: don't load the image and redraw the card based on the input numbers. It then boils down to, essentially, the image of a generic card with some generic fields on it. Add some red text for fields that require input, and I think it's an elegant way to guide people when entering CC info. I'd be interested if anyone did A/B testing with this variant (and others) against regular forms.
Earlier quoted context omitted.
> Agreed, I stumbled for a second before realizing I could type a name in the card I didn't realize this until I read your comment.
This was the primary weak point in the implementation. Expecting users to recognize that they can click on the static-looking fields on the card (or relying on them to use tab to move between fields) does not pass the grandma test. It'd be great if you detected when a field had been fully filled out and moved to the next one automatically.
The main problem, and many designers make that mistake, is that you're modeling a physical thing inside an app for no good reason. Other than the nice visuals it doesn't help anything. As a designer, you should think of how to make the process of entering the CC more efficient and less distracting, so your conversions don't go down the drain. A simple clean design with standard input fields will outdo your pretty des…
> The main problem ... is that you're modeling a physical thing inside an app for no good reason. There is a very good reason to model the physical card. On the assumption that most folks enter their CC information by taking the card out of their wallet & copying the information from the card into the form. Then for those folks following the physical object makes it easier for the user to locate the expiry date & CCV…
You learn where the CVV is the first time you successfully buy something online. You learn how this specific form design works the first time you enter a website that uses it. Which do you think is going to be happening more frequently?
Upvoting because this is so beautifully executed and I'd love to see people test this out on their checkout process. That said, my experience indicates that this is not going to convert well. To mirror the author's own quote: "Every question a user has to ask themselves during the checkout process is another reason for them not to complete it." What's presented here is a drastically different experience from the norm…
It depends what you are trying to sell. If you have used all known tricks to convince user to buy "lose 50 pounds in 2-weeks" product, then yes unusually good looking CC form nothing circa 97 can discourage user from converting. On the other hands, many times you offer product that user truly wants, and when your checkout is broken, they will send you a long explaining email, showing you how far they would go to get what they want.
>Beyond that it has to load images dynamically based on card type which on a slow or interrupted connection
I noticed that too, but thats mostly because this post > 420 upvotes. All you have to do is load them all in div style = "display: none" on body onload and viola! all are preloaded and hidden, waiting for your browser to use one from your cache.
Earlier quoted context omitted.
I think blind people / screen readers might have difficulty with this interface, too. It's important to keep accessibility in mind when designing futuristic interfaces.
If you press tab, it at least cycles through all of the input boxes on the front side in an appropriate manner, and you could probably design it to flip over on the next tab press. I'm fairly certain that would make it work with screen readers (but not positive).