We plan on shipping a billing system for Sampa some time between now and the end of times. I've never done this before and as far as I know there is a lot of little details.
I'm looking to borrow a developer's brain that has done a billing system for their startup recently. Anyone is interested in coffee or lunch (I pay) to tell me about the dirty side of building a billing system?
Sorry for being picky about it, but I'm not interested in business people or program managers. I really want a developer that got his/her hands dirty defining the schema, doing the API, testing it, etc.
Also, Sampa is not e-commerce type of billing (one time transaction). We (will) have a subscription model, so I care about startups that have similar models.
It has been just a few days, but Dave Sampson is already making his mark on Sampa as VP of Marketing. Dave is a convert. He started as a techie and moved into marketing, which is just the kind of person we were looking for.
The VP of Marketing at Sampa was the position that was open the longest, probably since I started Sampa in 2005.
You can read more about him on our Leadership page, on LinkedIn or watch one of his lecturers at the University of Washington where he teaches Marketing on the Software Product Management Certificate program.
When I started Sampa, I thought that most content would be traditional page GET/POST. But then I went back and checked a family tree that I did for my personal site in 2000 that used AJAX. It made sense to use that technology on Sampa and I went overboard. I created my own AJAX framework (in 2005 there wasn't anything solid that I could use) and used AJAX everywhere on the system.
Later AJAX started to become a pain, because a page after being loaded required 3 or 4 AJAX calls to get the additional content. Bad design for the user. The good part is that Sampa used a combination of Frames that allowed us to cache content on the browser, so the AJAX calls to the server were minimized.
From a development standpoint, AJAX is a pain because it requires you to parse the returning XML and do something with it, usually generate some HTML or data structure. This is where AJAH and JSON come in hand.
If you need a piece of HTML to sitck on the middle of the page, you can generate that HTML on the server and send it on an AJAH call. Once you get that is just a matter of setting the innerHTML on an element.
JSON does the same thing, but for data structures and its data in Javascript. Get a JSON response, eval-it, and you have data and 'classes' ready for use, instead of parsing the XML and putting into a data structure.
So, of the 4 technologies above (in-page, AJAX, AJAH, JSON) which one should you be using on your web-based service? All of them! Each one solves a different problem and they need to be used in combination.
This is my non-comprehensive list of tips on those technologies:
in-page: Use that to minimize server calls when the page is first loaded. The same way you should have few CSS, JS and Images file on a page, you should try not to make any JSON, AJAX or AJAH call once the page is loaded at the first time. Everything should be embedded on the HTML you send to the user.
AJAX: Great to take action on the server ("delete this record") without needing to refresh the page, or when you need pagination ("contacts 1-50 of 1750").
AJAH: When the HTML generated is smaller (or faster) than sending an AJAX response and creating the HTML in Javascript. It's also good because you can keep all the HTML generation routines on the server. Like AJAX, you should only use it when you can't have the content embeded on the page directly on the first page request to the server.
JSON: When the results of an AJAX call will be parsed into a data structure, you probably should consider JSON. Size of the response and parsing time are important considerations. Remember "eval" can be very very very very (add 17 more 'very') expensive at runtime. You don't want your user's browser freezing every time it clicks on something.
I'm a big advocate of using 1 or 2 letters field names. Instead of "Username" just use "n", and that goes both to JSON and AJAX. Put the comment on the code to what it means, but save a lot on response size.
If you look back at the Sampa sign up form, it has been through 4 or 5 different versions. At one point we asked you about 15 questions. Then we worked with one local UX expert to simplify a bit, then we worked with a Portland-based UX firm to simplify it even more and we had just 8 inputs:
Name
Email
Confirmation of email
Password
Confirmation of password
Agree to Terms of use
Web address
CAPTCHA
After reading the book "Web Form Design Fillin in the Blanks" (by Luke Wroblewski) over the 4th of July, I decided to take a closer look at our sign up form again.
I am always afraid of making any change to our sign up pipeline since we have such fantastic conversion rates that is easy to assume something, make a change and it to backfire.
Well, there was at least one change I've made that was a no-brainer. The Terms of Use checkbox wasn't checked by default and I changed that.
But that's not the interesting part. On the book, Luke mentions that a lot of the things we ask on forms are limitations of the application itself and that it doesn't add value to the customer ("inside out").
You can clearly see some of that on Sampa. Why do we ask twice for your email? Why do we ask twice for your password? Why do we need your name? Why do we need CAPTCHA?
We have good answers for all of the above, and we A/B tested several scenarios over the last 2 years to know that we are close to the right combination that yields maximum conversion and retention. But one piece was never tested and it was off: CAPTCHA.
Why do we need CAPTCHA? Like any other free web service that you sign up to (Hotmail, GMail, Ticket Master, Blogger, etc.) CAPTCHA is necessary to prevent automated bots from creating hundreds or thousands of fake accounts, either for Spam or Link Farm. So it's a necessary evil that good people have to go through so we can keep the bad people out, or is it?
Well, last Monday at 5:13 PM we removed CAPTCHA from Sampa. It wasn't easy and clean, but we created a set of tests and rules that will make us not display a CAPTCHA about 99% of the time. I can't really disclose the tests we make since that's the secret you want to keep out of the hands of bot creators.
The result: 9.2% improvement on our conversion rate!
The entire team is just shocked that such a huge percentage of users wanted to sign up to Sampa and either didn't pass the CAPTCHA (less likely) or found the form more intimidating with a CAPTCHA (more likely). The third explanation which we've been talking about is that with less vertical space, the "Continue" button is above the fold more often and give users a better sense of how short this form is.
Subscribe to this Site
.
October, 2007