Time for smugmug to implement a "beta" program for significant new features?

jfriend

With all the issues that surfaced with the Lightbox and the uncertainty over how some users will react to some feature changes, I'm making a suggestion that the smugmug developers think about a way to run a beta process where some account holders could "opt-in" to the beta process and their accounts would be accessed via the new software while the other accounts would continue to run the old software. In this way, you could "get the kinks out" before flipping the whole user base to the new version.

I suspect that it's not trivial to have some accounts accessed via a newer version of the software whlie the rest stay on an older version, but it seems that it's next-to-impossible to make it perfect in your test lab so, you either have to figure out a way to run a beta process to shake the final kinks out or you're going to discover serious functionality flaws or browser flaws after you've gone live and have to scamble to fix them in an emergency process.

From my software experience, a good beta process actually lets you go faster with your develoment, not because you don't still have to test, but because a test lab plus beta customers is way more effective at testing a wide variety of configurations than a test lab can ever be on it's own.

Just a suggestion...

cabbey

I'll second jfriend's suggestion, and happily volunteer some time here and there to kick beta tires. Or heck, I'll sit my wife down in front of it... she's managed to break just about every piece of software I've put in front of her.

jfriend wrote:

I suspect that it's not trivial to have some accounts accessed via a newer version of the software whlie the rest stay on an older version, but it seems that it's next-to-impossible to make it perfect in your test lab so, you either have to figure out a way to run a beta process to shake the final kinks out or you're going to discover serious functionality flaws or browser flaws after you've gone live and have to scamble to fix them in an emergency process.

However, as long as the backend data isn't being changed, it's ususally quite easy to put the beta code on a seperate server that accesses the same backend datasource. So that instead of accessing our sites by http://name.smugmug.com/ we would access by http://name.beta.smugmug.com/ or some other pattern that resolves to a completely different server with a different code base installed. (Staging servers are usually what we call them at work, I think that's a common name for it in the industry.)

rainforest1155

Great idea - this could definately reduce the amount of initial bugs and after-release userproblems resulting from every release.

Sebastian

joffun

I agree that this would be a good way to iron out any bugs or other operating concerns that users may have, before it is rolled out to everyone.

As others have said elsewhere, an email advising of major site updates would also be helpful. Going to your own site & then discovering that it doesn't work as it used to is disconcerting (particularly when bugs exist) - what do potential customers of mine think?

I think these two ideas would help alleviate a lot of people's concerns that 'their' site is being changed without their knowledge, particularly when they have spent many hours customising it & then finding that some aspects of it won't work.

Andy

Thanks for the suggestion, guys.

flyingdutchie

jfriend wrote:

With all the issues that surfaced with the Lightbox and the uncertainty over how some users will react to some feature changes, I'm making a suggestion that the smugmug developers think about a way to run a beta process where some account holders could "opt-in" to the beta process and their accounts would be accessed via the new software while the other accounts would continue to run the old software. In this way, you could "get the kinks out" before flipping the whole user base to the new version.

I suspect that it's not trivial to have some accounts accessed via a newer version of the software whlie the rest stay on an older version, but it seems that it's next-to-impossible to make it perfect in your test lab so, you either have to figure out a way to run a beta process to shake the final kinks out or you're going to discover serious functionality flaws or browser flaws after you've gone live and have to scamble to fix them in an emergency process.

From my software experience, a good beta process actually lets you go faster with your develoment, not because you don't still have to test, but because a test lab plus beta customers is way more effective at testing a wide variety of configurations than a test lab can ever be on it's own.

Just a suggestion...

Amen to that!
It also may help Smugmug with issue that arrise due to users' customizations (e.g. Lightbox did not work for me under IE6.0 only and some other issues).

Andy

flyingdutchie wrote:

Amen to that!
It also may help Smugmug with issue that arrise due to users' customizations (e.g. Lightbox did not work for me under IE6.0 only and some other issues).

Anton - that's great but remember, your site is one in a million

flyingdutchie

Andy wrote:

Anton - that's great but remember, your site is one in a million

But still. I had only 3 issues with the upgrade. Not bad.
The 'major' one being the lightbox... which i still don't understand why it doesn't work (on IE6) without the dynamic CSS i added ..

jfriend

That's the point

Andy wrote:

Anton - that's great but remember, your site is one in a million

But that's exactly the point of a beta. You can't test every single customized site. A beta process would give Anton a chance to test out his own site with the new changes and report back to you what he finds. You could then decide whether they were issues you need to fix or he needed to fix "before" you went live and everyone else was affected by the changes.

Andy

jfriend wrote:

But that's exactly the point of a beta. You can't test every single customized site. A beta process would give Anton a chance to test out his own site with the new changes and report back to you what he finds. You could then decide whether they were issues you need to fix or he needed to fix "before" you went live and everyone else was affected by the changes.

Thanks John for the feedback.