FantasySP, Building a Better Upgrade Flow

A few weeks ago I came to the realization that my current implementation of upgrading and billing users on FantasySP using Paypal was pretty terrible.

It was a clunky process where the user left my site to go to paypal, then they could sign in and/or input their credit card information.  After that, they get directed back to my site to a “success” page.

The user was unable to upgrade from a monthly subscription to a yearly subscription, if he so chose.  I never implemented automatic membership downgrades/upgrades because I thought I would be leaving paypal sooner rather than later.  To top it off, the design of the page was just plain bad.

Talk about a mess.  This is what my upgrade/billing page used to look like:


Old Billing Page

Simplicity is Key

When it comes to designing and implementing the new upgrade flow, I knew I wanted something extremely simple and easy to use:

  1. User should stay on the domain during the process (SSL would have to be installed)
  2. Only 2 subscription choices to pick from with a suggested audience.
  3. Able to upgrade from monthly to yearly with a prorated cost.
  4. Able to apply a coupon code during selection BEFORE he checks out.
  5. Easily see the breakdown of features.

For me, Stripe seemed like the best option.  There are countless posts out there detailing what Stripe is all about and why its cool.  During the checkout process, stripe uses a javascript library that handles the form submission and processing of credit card information.  If it all checks out, then the form is submitted to my server with an authenticated token that stripe recognizes to perform the transaction, create a new customer, or subscribe them to a plan.  Therefore no credit card information is actually handled by my server.

Design the Page

Instead of hiring a professional designer, I decided to take a crack at this one myself.  If what I made looked like shit then I would bite the bullet and hire a pro.  I would never say that I am a designer, but I can pretend to be one.   I looked at quite a few checkout pages ranging from 37signals to Old Navy.  I skipped the Photoshop process of a mockup and went straight to designing in HTML/CSS because I knew what I wanted in my head:

User Upgrade Options

The boxes look pretty much like Monopoly cards, right? Instead of smashing everything together, I wanted to make sure I utilized the entire width of the website.  The user is presented with a CLEAR option of free, monthly, or yearly plus.   Underneath the price suggests who would benefit best from the plan.  Monthly is for the seasonal fantasy player, whereas Yearly is for hardcore players, and Standard is for the casual player.  When mousing over each box, the background turns yellow.

You may notice that I decided to use different fonts (via Google Fonts) because I think it makes it appear and feel more unique.  Arial gets boring real quick.  I also wanted to make sure that the page relied solely on CSS for styling.  Everything you see there are some fairly simple and common CSS techniques to add a bit of flare to each box.

The coupon code is shown just below the choices WITHOUT a button.  My site will analyze the text as the user types or pastes the coupon into the box.  In order to proceed to the next page, the user must click a box.  If a valid/expired coupon code is detected then it gives a message like so:

Coupon Code Entered

But of course, the user needs to see the full breakdown of the features.  The user also needs to see what the site would look like as a Yearly Plus subscriber, which means the top banner of the site will show Player Trends instead of banner ads:

More of the Page

The user can mouse over the bottom 4 choices and see more information about each via tooltips powered by qTips.  Now lets move onto the actual form to submit the subscription order:


Checkout Form

Thanks to Stripe, I don’t need their billing address or even full name to process an order.  We want the bare minimum here so the user can quickly move on.  Next to the plan is an option to change their plan.  There is also an option to “Go Back” incase the user changes their mind. The “Submit Payment” button is BIG and BOLD because the user should be able to quickly find the “Submit” button.

Again, clicking the “Submit Payment” button sends the information to Stripe and then responds back with a token if valid.  Once that happens, then communication between Stripe occurs and the user is upgraded to their selected plan.  If all goes well, the form is finally submitted and the user is presented with a Success page.

But Wait, There’s More

You thought that was it, huh?  That is the basic checkout process, but the user needs to see an email invoice to ensure they have something for their records.  Sounds like something else I have to design that also needs to look just as good and be just as simple.  Luckily I recently redesigned the email newsletter that goes out, so I used that template for the invoice:

Email Invoice

Looks like I should be nearly done with the design of the billing process, but there are a few more possibilites to take into account.  What about Cancelling memberships?  What about Upgrading from a Monthly subscription to a Yearly Plus?

Enrolled in Monthly
Clicked to Upgrade

As you can see, choosing to upgrade a subscription prompts the user with a new box via jQuery UI.  After clicking yes, the user is shown the price and is sent a new prorated invoice. Similarly, if the user wishes to cancel, then a similar box would pop up.

Wrap Up

Revamping a billing page takes a lot of planning, testing, and fine tuning.  Just the design implementation alone took about 2 weeks with lots of tweaking.  Lots of frontend technologies are used including jQuery, jQuery UI, Google Fonts, Stripe, and qTip.  There are still a few things that need to be tweaked on the frontend and backend, but overall the new billing is exactly what I envisioned and is light-years better than what I had.

Hopefully this post will help others who are thinking about revamping their upgrade flow. Nearly 3 weeks of hard-work launched a few days ago and it was great to see a few users already go through the process with no problems.  Merry Christmas to me.

Fix the WordPress SQL_CALC_FOUND_ROWS Bug

Anyone who has a WordPress blog with a lot of posts will eventually encounter an extremely slow query. I refer to this as the SQL_CALC_FOUND_ROWS Bug. If you have slow-query-log enabled then a query similar to this might have shown up before:

SELECT SQL_CALC_FOUND_ROWS wp_posts.* FROM wp_posts WHERE 1=1 AND wp_posts.ID NOT IN (44682, 44657, 44630) AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish') GROUP BY wp_posts.ID ORDER BY wp_posts.post_date DESC LIMIT 24580, 5

Just how detremential is this to your blogs performance?  Well thanks to newrelic, I can show you:


Unfortunately I don’t know why WordPress runs this query.  What I do know is that it apparently only shows up on index.php.  What you probably care about is how to fix this problem.   I’ve located a possible workaround thanks to this open ticket at  The diff log on the changes are listed as well.  I went ahead and applied these code changes to wp-includes/query.php.  The fixed query.php can be found here.

How are the results so far?  Inconclusive.  I just applied this patch and nothing broke so far, which is always a plus.  I suggest you give it a try and see how your blog responds in a development environment.  If I STILL spot slowdowns in the revised query, then I will update this post and let you know.

Some of you might be asking, does this affect your version of WordPress? The answer is yes.  I am running WordPress 3.2.1.

Please do post your thoughts, concerns, or comments to help others out.

My Review of New Relic, with some Performance Numbers

When optimizing your web application or server, the process can be a bit daunting.  In fact, its usually something that is never fully checked off your to-do-list.  The reason being is that you’ll never really know how your application will scale until it starts to show its growing pains.  Just when you thought that you’ve addressed the performance issues, a few weeks or months go by and new ones will crop up.

Before New Relic came along, I used to cat the slow-query-log.  I would address any queries that I saw took a while to execute.   Then there is the MySQL Performance Tuning Primer Script.  Also a great tool and will give you a good idea on how MySQL is performing as a whole.  I would continue to look at these things, but the load averages kept climbing and I could not figure out what the problem was.  I also couldn’t figure out which pages took the longest to load.

Enter New Relic

I actually considered throwing more hardware at the problem, since I could not figure it out through the usual means.  Then New Relic came along and I decided to give it a try. Here is my site performance graph since I first started using New Relic:


You’ll notice that when it was first turned on, the database was clearly the issue. The problem was UPDATING a table that has almost 2 million rows. (Duh.  Apparently, it was way more costly than I ever imagined)  Incrementing the view count on one of the main tables was the root cause to 90% of my problems.  I went ahead and created dedicated tables to hold these stats  and load averages eventually settled to around .20 across the board.  MySQL was no longer an issue.  FantasySP was silky smooth, once again!

The best part about New Relic is that once you set it up, you don’t have to spend time SSH’ing your box to find performance issues.  Everything you need is much easier to read, not to mention there is a performance breakdown based on each page/script.  Now I can easily see the pages, ajax requests, and background tasks that take the longest to complete.  All of these can be easily optimized now.  Their interface isn’t perfect, but it’s improving every day.

Impact on Google Bot & Organic Search

Of course when you optimize your website you do so for the end user experience.  The added plus to this is that Google Bot gets a huge benefit from it too.  I’ve been reading over and over about how load time is now a ranking factor.  Sure, but it’s not that big of a deal, right?  Well, lets take a look at how Google Bot responded to these tweaks: | Pages Crawled Per Day | Time Spend Downloading | Pages Crawled Per Day
m.FantasySP | Time Spend Downloading

Clearly, the faster the response time, the more pages that can be crawled in a given day.  The average response time for is now at around 100ms.  The average response time for Mobile FantasySP is at 72ms.  Google Bot quickly realized that the site is performing faster and ramped up its crawl rate.

So you might be wondering, has the faster and more responsive site resulted in more search engine traffic from Google?  So far, the answer is yes.  By about 5 – 10% the past 7 straight days. Coincidence?  I doubt it.  Getting a bump in SERPs for being a considerably faster site is very real.  There is no question that the easier it is for Google Bot to crawl, the better off I’ll be in the long run.


New Relic has just released a whole bunch of new changes such as Real User Monitoring , an improved install process, and a much more affordable pricing structure.  It doesn’t matter if your a company of 15 developers or just one developer working on a side project. . . New Relic will be worth it.  In fact, for smaller sites you should be able to take advantage of New Relic’s 14 day professional trial and be done optimizing by the time your trial is finished.  However, I’ve been addicted to the stats and will eventually subscribe to their “Standard Package”.

New Relic essentially takes the guesswork out of optimization.  Now you can easily track down costly plugins in WordPress and even compare performance numbers from week to week.  This is by far the best tool you can use to make your site or app run faster.  Spend the time and install it, or submit a support ticket and have your host do it.

I can go on and on about New Relic and you will probably get a bit lost in the data for a few days.  So go ahead and give it a try.

Web Developers, You’re Not Alone

Web developers who plan to work alone, or are already doing so have a lot of obstacles to overcome.  One of which is being isolated and having no like-minded professionals to turn to for advice and feedback.   I know this one all too well and have been working alone  for the past 5+ years on various projects.  My current project, FantasySP, has been extremely challenging and rewarding at the same time.  Reinventing how people manage their fantasy sports teams can be quite a challenge.

Smashing magazine wrote a great article detailing why you should not be working alone.  However, some of us have no choice but to work alone. It could be that you are doing a solo project that no one believes in, or you simply do not have enough funding to get anyone else on board.  Fear not, this article will show you where to go to get some helpful feedback.

  1. Stack Overflow
    This is my personal favorite for websites to turn to when you are stuck in a bind.  As a developer on your own you will eventually run into programming problems that you need to get some outside advice on.  Whether it be a MySQL scalability issue or how to parse JSON in PHP.  You are free to post about whatever problem you are having, even newbie questions are often given great responses.  Questions are mostly geared towards programing, but can occasionally touch on server configuration or just plain old HTML questions.

    Best part about the site?  The community is friendly, extremely knowledgeable, and eager to help.  I’ve asked questions on that site that directly and indirectly led to answers.  I can’t say enough good things about this site and suggest anyone who is involved in coding to sign up and participate.   You’ll feel compelled to help others and try to be the first one to get selected as “Best Answer” to rack up points.

  2. Forrst
    Forrst is a site that can be used for networking with like-minded individuals and provide a spot to ask a wide range of questions that usually don’t pop up on Stack Overflow.  This site isn’t specifically limited to questions.  You have the option to post code snippets, screenshots of projects, to gain feedback.  You can even post useful links that you think can be beneficial to others.  Your posts can be private or made public, it’s completely up to you.

    If you are looking for feedback on a blog layout, design mockups, or coding then Forrst can be a great spot to check out.  I do not have much experience here, but from what I’ve seen thus far the community seems helpful and eager to help.  Getting started on Forrst you may feel a bit isolated, since it has a social aspect to it.  The site requires you to apply for it, but after waiting a week or so then you will recieve your invite code in your mail.  However, if you are helpful and engaged in the site then you should gain quite a few followers and get the feedback your looking for.

  3. Dribbble
    Dribbble’s sole focus is to post your designs and try to gain feedback from it’s userbase.  The site is invite only and is fairly difficult to become a member of without getting lucky or knowing someone already on the site.  I am not a member of Dribbble, but a designer friend is and told me the site is less about feedback and more about showing off your awesomeness.  Egos abound.

    So should Dribbble be on this list of helpful sites?  Yes and no. It’s still a great spot to post your designs and get feedback, but if you aren’t up to par then expect to hear about it.  That isn’t necessarily a bad thing if you are a pro, but amateurs beware.

  4. Web Hosting Talk
    Here we have a throwback site that you probably heard of.  Unlike the other sites mention, this is a forum and is geared towards web hosting questions.  Being a developer on your own means making web hosting decisions as well, so this site is a must to learn which places to avoid.

    It may not look the best, but the forum is loaded with people who have lots of experience with multiple web hosts and it even has employees from dozens of hosting companies.  Ask your questions about domain registrars, VPS’s, cPanel, or Plesk and you’ll get lots of great feedback

  5. Webmasterworld

    Another blast from the past, webmasterworld is the place to go for questions related to your server and SEO.  This is a fantastic place to go to learn about harmful webbots that should be blocked and the latest rumors/news about search engines.  Users on this site are anonymous, and for good reason.

    This site is about  asking questions that you probably wouldn’t ask elsewhere.  For example, if you plan to partake in questionable practices such as cloaking content for Googlebot.  The community is helpful and there is a large mix of newbies and experts on the topic of SEO.

    This list is far from perfect and I have a feeling I’ve missed quite a few useful sites.  Be sure and leave comments to other helpful websites to go to for feedback.

jQuery vs Prototype, a newbies perspective

When I first started to dabble with javascript and ajax, Prototype was the only game in town that was making any headlines. So of course I used prototype with .  I was able to make some simple stuff, but my coding with Prototype wasn’t very elegant and it certainly wasn’t the best way to code things.  But you know what, I’m a javascript newbie and  it worked!

Over the last few years it seems like Prototype development has slowed down a lot, while jQuery is making huge headway.  Every tutorial I see is using jQuery.  So I FINALLY decided to buy a book and learn it.  They are vastly different to say the least.  My prototype code had an awful lot of onclick=”” kinda stuff inside the HTML, while jQuery let’s your code appear more transparent and natural.  I love being able to pass my own variables using html attributes.

I went through a lot of WTF, why isn’t this working moments during my first attempts at coding using jQuery techniques.  However, overall I love jQuery.  Now my code is optimized, cleaner, and I feel as though I am not limited in what I want to do.  If I can dream it, I can code it with jQuery.  Not a small feat for someone like myself.

For example, with Prototype I simply didn’t know how to show a loading gif when an ajax command was in use.  It sounds simple and a lot of you are probably thinking what an idiot.  I turn to jQuery and my first attempt I find that it’s so simple to achieve.  Not only that but I can easily manipulate form values, check their validity,and pass them along with no problem at all.

To learn jQuery I completely rewrote all of my javascript code for FantasySP.  It took me about 2 LONG weeks, but now I feel as though I can code just about anything I want.  My code is a mere 7kb in size now, compared to 49kb in Prototype.  I am actually making reusable functions now and you can too.

My only quibble with jQuery is that coding an advanced autocomplete function is a huge pain in the ass.  Prototype let me customize it from the backend (PHP), whereas jQuery forced me to use JSON and adding extra javascript code.

So for those of you who haven’t used a framework before, or are still using Prototype, give jQuery a try.  You won’t be disappointed.