The FDO front-end is the old ("Classic") view of the message boards seen only from inside the proprietary AOL client. It was superseded by the Web board front-end a couple of years ago, though you could still backdoor your way into the FDO view.
And many people did just that -- partially because the Web front-end had some problems, but also because they were simply used to things as they were. And why wouldn't they be? Outside of a back-end transition near the beginning of the millennium, the FDO message board interface was substantially the same as it had been, going back to the early days of the AOL service. It wasn't fancy, but it worked (mostly), it was pretty fast, and most important, people were used to it.
We've Always Done It This Way: Cognitive Lock-In
So, this is a particularly dramatic example of cognitive lock-in (an issue I'd written about in the AIM Social Media Blog last year: THIS SUCKS! Or, Cognitive Lock-In: The Familiar Is Better (Even When It's Not) .
Cognitive lock-in is a fancy term for "You can't teach an old dog new tricks," usually combined with a flavor of "If it ain't broke, don't fix it." It means that once people learn one way of doing things, they usually prefer it to a newer way, even if the newer way is "better" (by any objective standard -- like it takes 3 steps to do something instead of 5).
Which means that, even if the new product is a lot better, it would still have a couple of strikes against it, simply because people -- especially the stereotypically non-tech savvy AOL users -- were so invested in the old version.
It doesn't help, if, as in this case, the newer Web front-end is not a lot better. It had a lot of problems, dropped a few features, and still lacked many, many features any Web board user-at-large would take for granted (I remember a new internal employee who could not believe that people couldn't edit or delete their own posts.)
Psychology Strikes Again: Emotional Lock-In
So, when change like this happens, people complain. Often and loudly.
You can't expect people to understand the business and technology rationale for doing stuff like this (even if it's valid, which isn't always the case). And sometimes, you just outgrow the product, or the product outgrows you. In cases like these, I often wondered why people didn't just vote with their feet: If things were so bad, why didn't they just... leave?
If you weren't one of those paying customers who needed the dialup, there wouldn't seemingly be a lot to hold you -- there are lots and lots of robust interest communities out on the Web that match or surpass the communities that had developed on AOL, and they've definitely got more features.
This is where psychology comes into play -- especially for long-time community users, there's a sense of ownership and entitlement. For the folks who got to be the old guard, who were the big dogs and got to feel like they owned the joint: If you go to a new community, you're starting over from scratch -- a newbie all over again. If you've already paid your dues, why should you have to do that again? It's a powerful disincentive to leave, so you stay and complain, even beyond the point where it makes any rational sense to an outside observer (there's community in complaint and commiseration, too).
We saw another prominent example of this in the recent Digg algorithm change top user revolt. If you're an outsider, it looks silly and self-important there, too.
So What Can You Do?
You can't not update your products -- that way lies stagnation and the death spiral. The lesson to companies, then, is make sure that when you're making changes that could hit the walls of cognitive and emotional lock-in:
- Don't do it unless you can make demonstrable, positive improvements with clear benefits you can show regular users (Note: Telling people about the cost-savings you'll realize because you're not trying to support dead or multiple platforms is not a user benefit)
- Don't just add new features -- Make sure that you don't lose any of the old ones
- Find user advocates to help evangelize and message the changes
- Communicate the changes early, incorporate meaningful user feedback, and tell people what you do as you do it.
- Prepare to take your lumps, because there will always be those folks who hate any kind of change... and in that group, you'll find the folks who won't leave unless they absolutely have to.