LinkedIn | FaceBook | Twitter
We've used two major system management paradigms for SQL Server: The Microsoft Management Console (MMC) and the Visual Studio shared components. In early versions of SQL Server, we had Enterprise Manager for most management tasks from a graphical standpoint and Query Analyzer (QA) for command entry. This suited some people fine - many told us they "never used anything other than QA". But even more people told us that splitting the tools didn't make sense - they wanted everything in one place. So we took the decision to move to SQL Server Management Studio (SSMS). Some people liked the decision, others didn't. The point is, we did make a change. And even in the subsequent versions, we're asked to change where this click or that icon lives.
But above and beyond what you click on the left that shows up on the right, there are two overiding concerns I have. One is consistency. If I click on the right for the OK button, I always want it on the right. The second thing is effeciency. I want to click as few times as possible to make something happen.
There are problems created with these goals, however. Consistency means things can't change - even when they are wrong. Hey, even the keyboard we use in the US is based on a design from over a hundred years ago, and I've even heard stories that it was intentionally designed to slow typists down so they wouldn't jam up the keys! So whenever we fix something, we make a change, which breaks the consistency.
On the efficiency standpoint, having fewer clicks means fewer choices. But since you may want to actually specifiy where a backup goes, for instance, we have to provide that option, which slows you down and clutters the screen. So we do both. We have some choices that perform several operations at once, and then we let you edit it with a powerful set of tools after. That's the paradigm that you see in SQL Server Integration Services (SSIS).
So when you see your favorite icon or right-click menu item move around, know that we've thought about it a lot, and lots of people have told us what they think about it. We're trying to "un-jam the keys", if you will.
PingBack from http://msdnrss.thecoderblogs.com/2007/09/11/change-it-no-wait-leave-it-alone/
I more wish you first fix trivial bugs like (reported and confirmed by MS) the one that you still cannot edit the content of columns that have dots (".") in their column names.
That sucks soooooooo much.
Good feeback - have you posted this on the "Connect" site? Bugs get tracked and voted on there, as I mentioned, and we fix the ones that we see most often and that have the highest impact.
Of course it's on the Connect site:
But Bill Ramos said it would be fixed only in Katmai... Really, how hard would it be to fix it in SQL 2005 SP3 ? It's just a couple of brackets that need to be in the right place !
And there are other trivial interface bugs that really need to be fixed, for example:
(with it's duplicates: 156985, 275240, etc). This bugs should be fixed in the next service pack, not in the next release!
Please, focus on fixing the bugs first, and then move the buttons around.
SQL Server MVP
I hear you. It's a matter of time and resources, and when in the cycle we can drop the code we're getting ready to ship and take care of the issues like these.