guide how-to php

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.


Case Study: Bleacher Report

Not too long ago I made a blog post about how Fantasy Sports sites need to be faster.  For those of you unfamiliar with me, I run my own fantasy sports start-up called FantasySP.  It is a simple yet effective way to keep tabs on your fantasy teams.

I tend to write articles detailing things I don’t like, but it’s time for a change of pace. Its time to go in the opposite direction and breakdown one particular site called Bleacher Report that is quickly becoming a leader in the sports industry.  Bleacher Report is a sports site where its users create the articles that can range from stat driven geekiness to Hollywood type entertainment.  These guys do a lot of things right and this article is going to showcase what makes Bleacher Report (b/r) so special.  From the outside looking in, it looks like there is great balance and understanding between the content/business people and the technical aspect of things.  I emphasis this because this is a rarity in today’s world of startups.

Before I get to praising Bleacher Report, let’s take a moment to see what the critics are saying. Specifically Sports Pickle.  As you can see by their graphic, they are mocking content choices, their target audience, usage of slideshows, and their attempts at driving traffic by loosely basing stories around sports.

Is what they say valid criticism?

Of course it is. I agree with a lot of their points.  Like any website, you want to broaden the audience to reach as many people as possible to generate more pageviews, better time on site, and more revenue.  b/r is playing the game that every other website out there plays.  Look at Profootballtalk or bigleadsports, because both of those sites report about rumors and gossip because it drives traffic.  b/r is giving the people what they want and they do a good job at delivering it. Not only that, but they manage to achieve this with arguably less paid writers and editors than most other sites.

Does some of their content stink? Of course.  But overall, the best stories are the most visible and the rest are kind of just – there.

Enough with the business side of things, lets talk tech.


I should preface this by saying that I am NOT a designer, though I pretend to be one.  Now that you are confident what I have to say should be taken with a grain of salt, lets move on.

The latest redesign of b/r is very clean and unique.   I’ve talked a lot in the past about how 2nd tier sports site’s in general lack polish and attention to detail in their designs. 2nd tier websites are often bloated in design and confusing messes.  Obviously ESPN is in a league of their own, but b/r is one of the best designed sports site out there. (b/r has a killer mobile design as well.)  In fact, their design reminds me a lot of c|net’s latest design.

One of the best ways to evaluate a design (at least to me) is to compare it to the competition.  As far as I know, their direct competition is yardbarker.  Take a moment to look at yardbarker and b/r from strictly a design perspective.  There is no question that you would prefer b/r: It’s more inviting, cleaner, more organized, and feels modern.  Does it surprise anyone that b/r has about twice as much traffic as yardbarker? (source:

b/r NBA section


The guys at b/r use advertisements as a revenue source.  I am sure it’s not their only source of revenue, but its probably a critical piece to their revenue goals.  These guys understand ad placement and they understand where to draw the line.

The number of ads per page range from 3 to 5.  Sizes include 300×250, 728×90, 970×66 and background takeover ads.  None of their ads are inline with their content.  None of their ads are popups or intrusive in any way.  (I could be wrong, but based on browsing for a day, this is what I can go on).

Their ad placement alone is well done and it can be found in the usual places.  A lot of sites throw advertisements in-line with the content because it has a higher CTR, but b/r has decided not to.  On some pages, they opted to include their 728×90 ad next to the logo which is pretty much an industry standard.  Their takeover ad is somewhat obtrusive but it is done very well and does not hurt the end-user’s browsing experience.  The entire background ad is clickable, which should produce some very nice CTR’s and a bulk of their ad money.

Overall, the quality of the ads and their placement is about as good as it gets.


b/r does a great job at making sure their site is very readable.  Their main body of text on an article page has a font-size of 16.  The only time their font-size reaches 11px or lower is at the very bottom of the footer. There is plenty of whitespace inside the main article and their usage of social buttons are done in good taste (as opposed to mashable and huffington post’s dreadful examples).

If you take a closer look at their fonts, you’ll notice that they are custom fonts including: droid-sans and francois-one.  Judging by their source-code it looks like they are using font squirrel for custom font implementation.  Thankfully they are NOT using cufon which uses javascript to render font changes after the page is loaded. Their font choices add a certain flair to the site that would not be obtainable with regular font choices such as Arial.


The technology behind b/r is equally as impressive as their front-end.  According to their about page, their lead developer is Sam Parnell and I am going to assume he gets a lot of credit for their current direction of the site. (If the guys at b/r would like to clarify this then be sure and comment so I can fix it.)

Caution, things are about to get geeky. The site uses Ruby on Rails for the backend paired with nginx+mod_rails to serve requests.  As far as I can tell, this is a custom built CMS built from the ground up.  It is obvious that the tech team behind b/r is a very knowledgeable bunch. This is a far cry from the average LAMP stack that we often see.

They utilize Amazon Cloudfront for their CDN and jQuery for their javascript library of choice.  To monitor server performance they are using NewRelic.  It goes without saying that these guys must spend a lot of time on improving site performance.  They also utilize the standard practices of website optimization by gziping, caching, and minifying stylesheets/javascript etc.

I also want to make mention of their use of Ajax, specifically how their article pages will load content via ajax without reloading the entire page.  I imagine the point of this is to encourage users to load more pages per visit and this tends to save on server resources as well.  To see this in action load any single article and click on one of the “recommended stories” on the top right.  If you notice, the href links point to their actual URL (Finally a site that does not use the “twitter” method by including a # in the url).  This is the BEST way to handle ajax content because the failsafe url is there for the user to load if the javascript is broke and googlebot can easily crawl these pages as well.

Areas to Improve

Even some of the best sites have ways they can improve and b/r is no different.  Their facebook implementation is a bit wonky (technical term).  I used their facebook connect and their popup was initially blocked, then when it did go through it asks for my email and then a bunch of other follow-up questions.  As a developer I understand how shitty it is to use facebook connect, but its even shitter for the end user to have to enter their email address when you already have access to that information in the API.  Furthermore, once I close my browser and go back to the site I have to click the “sign-in” button for facebook to re-authenticate.  Not cool.

Either fix the facebook implementation or drop it all-together.  Don’t get me wrong, this isn’t the worst I’ve seen (cough: huffington post).

Another questionable decision is the whitespace above their 970px advertisement (shown in the above screenshot).  That is a huge waste of space and is pretty pointless.  I’m not very religious, but I do follow the rule of “Thou shall cherish their above-the-fold space“.

Finally, the pages are a bit on the hefty side, some approaching nearly 2mb in size.  This has a lot to do with the amount of images on the page and it might be a good idea to lazy-load some of those to improve load times and lower CDN bills.

Wrap Up

Hopefully this case study has proved useful to some of you guys out there on best practices and a good example of company appearing to make the right decisions. I am sure I missed plenty of other aspects of the site, but this article has gone on long enough.  In fact, two other things I didn’t have time to go into full detail are their great implementation of the search box and mobile site.  Both are top notch, especially their mobile site.  Anyone out there who is looking to design their mobile site should use b/r’s as a template.

I am extremely pleased to see that some startups have the right people behind the wheel.

Agree? Disagree?  Let me know in the comments. I’m new at this case-study stuff.