[yarone]

I think there's a general purpose need for "optimal" form components. Let me elaborate:

- Fields for typing-in a credit card

- Fields for typing-in an e-mail address

- Fields for typing-in a U.S. street address

There are widely-known techniques for optimizing data entry for these fields, yet these techniques aren't widely adopted, and further yet they're known to increase conversation rates.

Someone should build a (subscription) service where you can embed a bunch of fields (and labels) onto a form with a single line of Javascript.

Then, the fields would render on the page. The performance of the fields (their effect on conversion rates) could be measured continuously. New variants of the labels and fields could be A/B tested continuously as well. That is, the performance of the fields would improve over time.

If there's interest I'll elaborate in a blog post (with mockups).

made a few edits

[fennecfoxen]

"Someone should build a (subscription) service ..."

I think you misspelled "open-source widget library".

[lamby]

Embedding a credit card field using third-party Javascript sounds scary.

[gauravk92]

Stripe does this really well using a js lib. The sensitive data thus never hits your servers and it's a much better experience for devs who don't want/have to deal with PCI compliance.

[ceejayoz]

I'm not convinced using Stripe or similar services gets you out of PCI compliance.

The vast majority of PCI compliance requirements - those relating to server security - would seem to still apply. If someone hacks your server, they could easily add an additional bit of JavaScript that sends the CC field to a second, malicious server.

[gauravk92]

That's a worst case scenario and things could be worse if they hacked your production code base.

All data should be 256bit ssl encrypted for point to point security and asset tampering protection. After that, i doubt stripes js lib is much of a problem, it communicates in a secure tunnel from the client to stripe.

They as well say you don't have to worry about PCI compliance then because you are never handling financially sensitive data directly, only indirectly.

[elliotanderson]

The GP is referring to doing client side Luhn validation on the credit card number, giving the user feedback if they mistype a number.

It's a technique I use, along with only allowing digits and doing some format masking (i.e. spaces or dashes to split the number into 4 digit blocks) to make the number more readible

[adgar]

Actually, the GP is talking about somehow building a startup based on... form widgets. He specifically said a "(subscription) service" - which would invariably require server-side support for these apparently startup-backed form fields.

[yarone]

Why? Many of us use Spreedly / Chargify / Recurly. Imagine embedding a Spreedly form on your site. Still scary?

[ceejayoz]

> Still scary?

As someone who's currently looking over PCI compliance stuff: YES.

[untog]

Actually, these third party services can be a lifesaver when it comes to PCI compliance. If you use a service like Stripe in it's entirety then you don't have to worry anywhere near as much about PCI compliance yourself.

[ceejayoz]

Has there been any actual confirmation of that? i.e. an official ruling from the PCI standards council?

Other than the long-term storage of credit card numbers stuff, most of it focuses on security measures I'd want someone using Stripe to have implemented.

After all, if someone hacks the server, they're going to have an easy time adjusting the flow to save the CC# that's supposed to only be going to Stripe.

[corin_]

But on the other hand, if anyone hacks any server, they're going to have an easy time putting up a page with a form asking for credit card numbers. For example say somebody hacked HN and added a "pay for premium membership" form, that just mailed off credit card numbers to the hacker...

Just thinking out loud really, I know nothing about PCI compliance or law.

[bvdbijl]

I think you would want to inspect the source code before you use a third-party library in a case like that

[lamby]

The whole point is that third-party source code can change without your knowledge (or permission, etc). Or, worse, the third-party can simply be hacked.

[ceejayoz]

Well, only if you're linking it off someone else's servers.

jQuery is third-party source code too, but I can host it myself.

[lamby]

Obviously. This was a response to OP putting forward a hosted solution.

[taf2]

Nothing a hosted solution for more $$$ can't solve

[thechangelog]

The credit card one is especially important. We run a hosted online ticket system for some of our customers and noticed they were getting a bunch of 'Invalid CC' responses from their payment gateway (and paying for each invalid attempt).

We implemented the Luhn[1] algo credit card check on the checkout page. Invalid CCs would trigger a little warning but still allow the form to be submitted. Invalid CC transactions dropped ~90% immediately. Even better we were able to get rid of the 'select your card type' field since that was detected by Luhn. A little JS was a win all around.

[1] http://en.wikipedia.org/wiki/Luhn_algorithm

[FireBeyond]

"Even better we were able to get rid of the 'select your card type' field since that was detected by Luhn."

FYI: Card Type is not determined by Luhn algorithms, but rather (broad brush strokes, see http://en.wikipedia.org/wiki/Bank_card_number#Issuer_Identif... for more detail):

3 - American Express 4 - Visa 5 - Mastercard / Diners 6 - Discover

[ceejayoz]

> Invalid CCs would trigger a little warning but still allow the form to be submitted.

Out of curiosity, why allow the form to submit anyways?

[richthegeek]

Rule #1: never assume your code covers 100% of all cases.

[thechangelog]

What richthegeek said. We put it in as a rough helper but didn't want to run the risk of denying something valid. The middle ground seems to work well.

[scoot]

"Someone should build a (subscription) service where you can embed a bunch of fields (and labels) onto a form with a single line of Javascript.[...] The performance of the fields (their effect on conversion rates) could be measured continuously."

Not quite the same, but sounds a bit like inForm[1]. These guys presented at a recent HN London meetup[2] and this was the meetup.com description which summarizes it better than I could:

"Ever wondered how users engage with your site, where they get stuck or how long they spend making choices? Forward Technology's upcoming form analytics service inForm can help you answer all these questions and more. Without any configuration Inform allows you to quickly build up a strong picture of what happens when real visitors interact with your forms."

Beta sign-up for HNers here[3]

[1]http://inform.forwardtechnology.co.uk [2]http://vimeo.com/32617520 [3]http://inform.forwardtechnology.co.uk/users/sign_up

[tantalor]

See http://paweldecowski.github.com/jQuery-CreditCardValidator/ or http://webstandardssherpa.com/reviews/auto-detecting-credit-...

[yarone]

Very similar to what I had in mind. Just no need to read or understand how it all works. Just embed some Javascript, and assume 1) that it works great and 2) it will improve over time (based on A/B tests on your site and other sites).

[altano]

You're probably interested in http://wufoo.com/

[debacle]

HTML5 and tablets are moving towards this. You can set the disposition of the on-screen keyboard based on the input metadata, making it easier to type stuff in. I think email is included in the spec.

[aresant]

Great idea, but the problem here is that what works somewhere, doesn't work elsewhere and it's all about testing.

But testing multiple fields, with multiple variables and experiments requires lots of traffic.

And what works for one source of traffic, PPC for example, won't duplicate to other sources of traffic like TV / Radio / PR / SEO / etc.

We recently ran a ton of traffic just around an inbound-email newsletter pop-up that lists out what we found to work best here:

http://www.conversionvoodoo.com/blog/2012/01/opt-in-email-ne...

Those are some "tried and true tips" that we'd stand behind for a popular affiliate marketing blog getting most of their traffic via SEO and referral, but unfortunately the entire addressable universe that we can guarantee those results for are the client we undertook the project with ;)

[smokinn]

Which is why I think it would be an interesting startup.

The base case alone would be enough to get many to buy your component but for a subscription (where the real money is) you need to provide continuous value.

So your pitch could be that using your product would instantly get you the best industry standard input forms but over time they'll get better because you're going to apply a/b testing and machine learning on them continuously.

[_pius]

http://wufoo.com/