Bad Wow - Telling a user that a feature they've requested already exists in the product they're using; they just can't find it.
Good Wow - Having a user suddenly discover a host of really useful features they never knew existed, which you've just magically brought to the fore.

Picture a few people in a room, peering nervously at a laptop: two developers, two testers, a project manager, a user interaction designer, and a technical author. That’s us, the SQL Compare team. We’re watching someone use SQL Compare 7.1, and we’re nervous because in a minute we’re going to show him SQL Compare 8 for the first time.

We start it up. There’s a note of excitement about the new Project Configuration dialog, then we ask him to perform a few tasks. We hold our breath.

“Normally,” he says, looking down a long list of database objects from which he’s been asked to find two or three, “I would just go through like I did before and find it. But I’m just dying over here to push the button. Can I push the button?” He clicks a button marked Edit Filter Rules “Wow!” Everybody laughs.

He sets up a filter, and finds the objects quickly and simply. This is good.

But didn’t we have a filter already? Well, sort of, I suppose. This version is configurable - you can set up and save complex filtering rules, exclude objects based on their schema, various things like that. More importantly, you can see it, and if you try to use it, you’re unlikely to end up frightened and confused. It’s that whole falling tree thing: does SQL Compare really have a comparison results filter if nobody can find it?

You see, this wasn’t the first “wow”. This was the good one, the one where somebody liked something. What got us started was the bad “wow”, a few months ago now, when we’d just released SQL Compare 7.1.

Pretty much right away, we started wondering what was next. What else could we add to SQL Compare? It’s an established and powerful tool, and one a lot of people like and rely on, so we ran some user trials, and started thinking about what else they might need. “What about” somebody suggested “a way to compare to a backup?” Err – haven’t we had that’s since 7.0? Yes, as it turns out, but plenty of our users didn’t know. “What about comparing to a scripts folder?” Well, that went into version 6, didn’t it? Again, only if people use it. Filtering? Snap. Exporting data sources? Likewise. “What about the ability to synchronize your databases?” Pull the other one – that’s been in since 1.5! No, not from the perspective of several existing users it hasn’t. The bad “Wow” was collective.

We’ve been adding features to SQL Compare for quite some time now, they’ve worked well, and yes, plenty of people have felt the benefit. But it hit us pretty hard that we’d not properly sat down and thought about how discoverable those features were, and how easy to use once you’ve found them.

An example: we’ve noticed some users (especially the ones using the existing results filter) who aren’t completely confident about what they’re going to synchronize. In a large, complex schema, it’s easy to lose track of which objects you’ve selected. There’s a confirmation step in the wizard, and that’s kind of comforting, but it doesn’t tell you very much. Now, we tell you exactly which objects will be synchronized, how many, and what their dependencies are. We do this at the front of a wizard which is – we think – much simpler to use. You can synchronize directly, or generate a script in fewer steps, and you can choose to back up automatically first. It’s a blend of new features we were asked for, and existing ones implemented more intuitively. It looks a lot nicer, too.

This was a usability led project as much as a functionality driven one, so even existing features were up for heavy scrutiny. We spent a lot of time talking to users, showing them things, and making changes based on their feedback, and we thought about how we could make their lives easier.

In fact, we’ve made changes (not necessarily drastic changes) to almost everything. Project configuration is simpler and more obvious, and the same goes for synchronization, scripts folders can now be modified directly, or used to generate a synchronization script, filtering is now visible, flexible, and useful, and the whole interface is much less cluttered and confusing. What we haven’t changed is the workflow. It’s still select, compare, synchronize: it’s still SQL Compare. We just think it’s a bit more grown up, a bit friendlier, and maybe a little more likely to make you say “wow!”

If you're interested in the more technical details of the move from SQL Compare version 7 to version 8, take a look at the Red Gate support pages.