AnEndlessArray of Geekery Brought to you By Lauren Scime.

3rd June 2007

I <3 BETA Forever

posted in design, general, projects, web apps |

I heart beta foreverA lot has been written about the notion of BETA and the web 2.0 tendency to launch to public beta and stay there indefinitely. However, I’ve found most of the negativity centered around this phenomenon to be limiting and perhaps a bit closed minded – let me explain:

The notion of Beta comes from the traditional software development model – develop a product, enter into “alpha” inhouse testing, launch to public beta and give the public an opportunity to respond and report bugs and other usability issues that an internal team might have missed – then after a set time in public beta testing, the full version (dubbed “omega”) is born and available for purchase. One problem with this model though – the product is never going to be bug free, nor the pinacle of user interfaces – because a bug free totally usable product does not exist – there are just too many variables. So versions are created and upgrades made available. So it was never really “omega,” right? The greek system is flawed (and I ain’t just talking about college kids hazing eachother and drinking too much cheap beer)…..

When it comes to web applications I would advise developers and critics alike to get the Microsoft-esque stick ouf of their ass….this delineation between products and versions is not really as necessary – first off, you’re not buying software – web apps live (as one might expect) on the web and have a different distribution and capital model altogether – and unless you’re talking about browser add-ons and widgets, you aren’t downloading anything that needs a .03 tacked on the end of it, or any other decimal for that matter.

When authoring web apps, hard launches are not the key here – I would argue that, in a web application, subtle (and sometimes not so subtle) extension/addition of features and consistent bug removal is more important. Product evolution can be much more fluid and should continue to change to meet demand over time.

So why declare something 1.0 if you can benefit from suspended Beta….prioritized expansion according to user demand is a good thing…right? (if you answered no to this RHETORICAL question, even in your head, then you have an itch to leave feedback – my point precisely. People like to give opinions).

The common criticism is that many webapps launch to public beta too early – before they are done completing the product. In some cases this criticism bears merit – A branded entity with a buggy, incomplete functionality in an environment of fierce competition can wreck public oppinion of your site and deter future would-be-users from revisiting.
In Your Beta Better Be Brilliant, a blog entry last year, author Blaze (side note: is this his real name? Or is he stuck in the early 90s Snow Crash alias aesthetic? No offense intended…I kid…) writes:

Developers, you need to ask yourself…By letting people in on our beta is there a chance of destroying initial interest in our product? Is it better to do demos and screencasts etc until the date when we can release something substatial and impressive.? What can we do (marketing wise) to innovate and keep people interested instead of exposing some buggy software.

He goes on to sum it up:

If someone sees something impressive, they will use it, they will continue using it and they will rave about it. People are getting smarter on the internet and if you disappoint them with your initial offerings, it is definately a bad marketing move on your part.

This all makes sense – people can be swayed away from a new web app if it doesn’t deliver something of value and a certain standard of functionality on launch, but there are other things to consider, and users can return again happilly suprised to find something doesn’t suck anymore (this actually happened for me in the case of Stumbe, which I found kinda cute but buggy and pointless on launch, and now find it entirely useful and entertaining to boot).

That said, there are times when an early launch to public beta can be advantageous:

  1. When there are no other competition in the market doing what your app does – and opportunity to be the “first” can trump completely debugged functionality and and a flawless UI -Think about it – we say “Kleenex” to mean tissue and “Google” to mean search the web – you can’t buy this kind of branding – you get it by sticking your flag on the mountain first.
  2. No one else is doing it well, and your product has something to offer that the other’s don’t. You’re still ahead of the competition because even if your bugginess or lack of full features is a disability, they suck more. You win.
  3. When your product will ultimately benefit from the user’s ability to give constant longterm feedback and shape the development process. This is especially true if you’re a small company and you don’t have the moolah to hire UI experts, testers, etc. Inhouse. You’re giving something to the public for free, and they should be honoured to contribute their opinions. People like it when their feedback matters – being able to tell a company “I want this feature” is a bit more exiting than reporting bugs.
  4. When getting it out there is an issue of getting investors. If getting it out there will spark investor interest and get you some funding to continue forward in your efforts (seriously, though we don’t like to talk about it because it’s not really kosher to divulge the fact that we all need cash, but most of us who are trying to do innovative things on the web are on a shoestring budget because we believe in our products and how they will bring something to the users out there – but at a certain point, we all need a bit of loot to continue development and not end up broke or dead from malnutrition caused by Ramen Noodles….).


Early to Beta, Early to Rise

There are a lot of web apps that went out early and made great progress from early feedback. In the case of SideReel (which, for those of you not familiar with my earlier posts, is a vertical media search engine for finding things to watch on the fly, as well as a growing wiki database of tv, film and video, and discussion forum), getting it out there and getting user feedback has been crucial. As a small team, we’ve had to prioritize our efforts based on what the users want and taylor our development objectives to meet demand.

In many instances, we’ve found that what we thought people would want, and what they infact do want, differ greatly. For example, our initial post-beta launch objectives included creating user accounts and profile pages, expanding the wiki to include a custom wysywig interface, and creating more user friendly forums. However, after getting feedback from a broad spectrum of users, we’ve reassessed based on their desires and have refocussed our efforts to include featuring the search and watch functionality with greater emphasis (people seemed to think the wiki was the main functionality of the site, rather than watching stuff).

We’ve also been reworking the homepage to be brighter, slicker, and reflect more image-rich featured content. The current homepage wasted too much space on the what we are and how to use us - seems people get how to use us much better than we initially thought (which we know because THEY told us). Here’s a quick snapshot of the old homepage vs. the soon to launch new:

The old site:

sidereel old

New, bright and chalk full of images - we’re going live with the redesign this week, so here’s your sneak peak:

sidereel new

Basically, my point is, if you dont’ have excessive inhouse resources for testing an Alpha phase, launching to public beta early and hanging out there indefinitely can be a good thing., allowing rapid evolution that is deliberately responsive to the user and their needs. And honestly, I think the notion of Beta, as a symbolic term that recognizes progress as consistent and neverending, is kinda sexy. Beta says “I’m here evolving for you” – and that’s a good message to send.Perhaps the trend of the neverending beta is a humble realization of developers that we are all in a perpetual state of amateurism as the many hands that shape standards and practice evolve faster than any one development team let alone any one person can keep up.Beta is a commitment to constant growth, and that’s something I respect highly.

So go beta, go! I <3 you forever!

There are currently 3 responses to “I <3 BETA Forever”

  1. 1

    On June 5th, 2007, Blaze said:

    Yes, real name ;). I wouldn’t exactly say cyberpunk though…. more rockstar influences.

    Nice post. Definately making some good counter points against my old posts. :)

  2. 2

    On June 5th, 2007, Mark said:

    Why not dispense with the word “Beta” entirely? It sets up an expectation in the user that there is eventually going to be a 1.0 release because that’s what we have all been trained to expect. I like your four points about when a public beta is a good idea.

  3. 3

    On June 6th, 2007, Administrator said:

    Blaze - thanks for the props, and for clearing up my questions about your name - I wish I had an alias for a real name, but alas, I’m stuck with Lauren…yay fun…Anyway, I liked your old post b/c you made good points rather than just whining about protocol like the other returns of my Google search on the subject.

    Good point about expectations Mark - I actually hadn’t thought about future release expectations persay - I guess it does set us up to expect a 1.0…oddly enough we never had an official Web “Beta” and here we are at Web 2.0! Guess O’Reilly didn’t really think about retroactive expectations…

Leave a Reply