We've been working on a new version of Bright Journey for a long time now and it's finally coming to fruition (putting the final touches).
There are some changes that might initially disorient regular users of the site. There's no way for us to only release one feature at a time (the entire site is a different codebase).
What's an optimal way of deploying:
Which approach would you recommend and why?
I would've blogged about it as it was under development, so regular users and new potential users could get a preview & headstart on the new conventions, and you could've gotten early feedback. I'd also have done a closed (thus avoiding duplicate content penalties) alpha test to get the power users (and the most interested of new potential users from the blog) on board with it and again gotten feedback to make quality-of-life improvements and bug-fixes while the experience was still framed as an "alpha" / you're-part-of-the-process work in progress.
But apparently it's already built and waiting to go, so... too late for that. =)
I'd put up an announcement post with lots of screenshots that tours us through the new version, and sets a date for when it will be implemented (next Monday, August 3rd?), assuming people don't universally hate it. (Really doubt we would, but it's worth saying since that's how services like digg have met their downfall before: rolling out a totally new version with little user input and no chance to stop it.)
Looking forward to trying it!
A/B or display a banner allowing people to click to "see"/enable the new version. I've seen several sites lately deploy new sites by letting people test it on their own and choose whether to stay on the new version or revert back with the click of a links.
Two examples are reddit.com's mobile and ksl.com, a large news/media site in Rocky Mountains. Both allowed opting in to the new version with an easy ability to opt back out. Seems to be the best of both worlds.