Get Inside Unbounce

Subscribe

Responsive is in the Hands of Real Customers! Progress Update #2

Over 3 months ago I posted a screencast of the prototype we were working on for Responsive, mobile-ready pages in Unbounce. Being our number one requested feature this year, it got a lot of attention and I promised an update as we progressed. Well, I’m excited (like, reeeeally excited) to announce that as of yesterday morning we have officially rolled into an “Alpha” testing stage with a handful of customers building real responsive pages in our Page Builder!

I said “over 3 months ago” though, so just what have we been working on all this time? I’ll try and give an overview in this post and share some insight into the progress that we’ve made:

  1. Building our upcoming conference website to be responsive (aka “dogfooding”)
  2. Alphas & Betas: what do these these release milestones mean?
  3. Experimenting with auto-magically converting old pages into responsive ones…
  4. What’s next and how do I sign up?

1. Building our upcoming conference website to be responsive (aka “dogfooding”)

If you’re in the world of building products, you’ll be familiar with the term “eating your own dog food.” That’s where your company uses your own product to validate its quality and capabilities. Some people call it “drinking your own champagne” and others (well, one guy at Microsoft) tried to change it to “icecreaming” which just sounds weird to me.

Back in May we had the perfect opportunity to icecream our very own Responsive feature. Not too long ago, Stef wrote a post to announce our very first Marketing Conference in Vancouver this Fall. To go with the announcement we built the Call-to-Action Conference landing page in Unbounce and used our new feature to make sure the page looked great on mobile (go ahead, open it on your phone!) We call this phase of development the “Pre-Alpha” phase. I’ll tell you what that means in a second…

Now, while the feature was still quite buggy and required a fair amount of custom CSS to work around incomplete functionality, everything went pretty smoothly. We published the page, and then sat down with Matt Coady, our UI Dev who built the page, to find out what corners he had to cut to get the page working as designed. This helped us narrow down what we needed to do before moving into the next “Alpha” stage with real customers.

2. Alphas & Betas: what do these release milestones mean?

As you can imagine, we’ve released a fair amount of big features in the last 4+ years. Every time we do, we evolve our release milestones to include phases like “Alpha” or “Closed Beta.” This gets confusing as our team grows and we’re trying to define the requirements that fit into each release. For our own sake, I’ve outlined what these phases mean to us today:

  1. Proof-of-concept (Prototype)
    This milestone is pretty universal. This can be either a clickable prototype put together by the UX team, or a functioning piece of software showing the concept in working order. Typically we use these to communicate complex ideas to a wider audience internally, or to prove that a certain technical approach is feasible. At this phase customer involvement is limited to concept and usability testing.
  2. Pre-Alpha
    At this stage we are dog-fooding internally. There will be lots of bugs and missing functionality, but it will be easy to work around them since we know exactly what our team of dog-fooders are trying to achieve with the feature. When we experience the value first-hand and it outweighs the bugs and missing functionality, we can move on to the next milestone.
  3. Alpha
    A small group of power users are let in (~10 or so.) Enough to get some feedback from trusted customers, but not too many that we aren’t prepared to answer phone calls, emails or chats promptly and individually. There are still many bugs and some missing functionality, but things are evolving quickly at this stage.
  4. Closed Beta
    All known major bugs are gone and we feel comfortable letting 100+ customers in. At this point we should feel confident that we won’t be fielding issues for every customer in the beta, and that we have the resources necessary to inform about updates and changes. We should also have any required tracking in place to measure adoption and success of the feature.
  5. Open Beta
    We don’t do these too often (after Closed Beta we’ll often go straight to Public Launch,) but it can be a good idea when the release is a major re-design. The level of comfort around bugs and stability should be similar or better to the Closed Beta milestone, but this time we have a way for customers to opt themselves in and out of the beta. This might be in the form of a “Try out the new design” link in the app, along with a “Go back to the old design” link from the new version.
  6. Labs
    The Labs section (under the “Settings” tab) has been a great place for us to put functionality that might not be entirely validated at a conceptual level. Features that nobody asked for (Hyperspace Publishing anyone?) or behind-the-scenes improvements that we’ve yet to fully test out (Faster Page Serving for example.) Similar to both Open and Closed Betas, we should have a high degree of confidence that there are no known bugs with this feature.
  7. Public Launch
    All bugs are fixed and all required functionality is completely finished. If there has been an Open Beta period where customers were given the opportunity to opt-out, we have warned them in advance about the public launch where the “old version” will be discontinued. The CS team has created all necessary resources to support the new feature and the Marketing team has been given ample time to prepare a campaign. Launch the feature and rejoice!

3. Experimenting with auto-magically converting old pages into responsive ones…

When we’re ready for Public Launch, the plan is to convert all of our templates to be responsive so that building new mobile-ready pages is dead simple. What about the 220,000+ published pages that are currently live and not responsive though? The experience of converting those to be responsive can be a little painful today, as it’s a manual process that requires you to resize and re-position all the elements on your page.

To alleviate this, we’ve been looking at patterns in mobile layouts and trying to see what we can automate to convert your old desktop page into a responsive mobile-ready masterpiece. Our head magician (R&D), Justin Stacey, has put together a little screencast showing the proof-of-concept that he’s been working on to accomplish this:

Unable to display content. Adobe Flash is required.

We’re pretty excited with the results so far, and are hoping to roll this out to our Alpha testing group as quick as we can for feedback.

4. What’s next and how do I sign up?

Now that you know how our release milestones work, and that we’re currently in the “Alpha” phase as of yesterday morning, our next goal is to move into “Closed Beta” as quickly as possible. This will require fixing a few known bugs and implementing some improvements like the ability to enable or disable the mobile version of your page in case you’re not ready to publish it. Many of you have already been tagged in our system for Closed Beta access, but if you want to make sure we’ve heard from you just sign-up for access over here.

I hope that helps give a bit more of an overview of where we’re at and how excited we are for the next phase. We can’t thank you enough for your patience, and hope you can hang in there just a little longer while we iron out the remaining kinks. It will be worth it, I promise!


Carter Gilchrist
Co-founder, Director of Product & UX