One of the many little things that annoys me about Windows is the inconsistency of where items are placed in contextual menus. Case in point: the menu that pops up when you right click on a taskbar item or window. I haven’t done a scientific study, but I’m going to guess that 80% of the time or more the last item in this particular contextual menu is the option to close the window that is being right clicked on. This is what the majority of the contextual menus look like:

Having it as the last item makes sense. It’s probably the most commonly used menu item and it’s an easy target when it’s the last item in the list. The problem is: because that item is listed as the last item over 80% of the time, I start to expect that it’s always going to be the last item in the list. Unfortunately, that’s not always the case.

For whatever reason, some applications list other options below the Close option. Here’s an example of the right click menu for a cmd.exe window:

When I want to close that window, I right click on the cmd.exe item in the taskbar and choose the last item that pops up. But it’s not going to close the window. Instead it’s going to bring up the properties dialog for the cmd.exe window. Now, not only do I need to close 2 windows instead of 1, I also need to always remember that cmd.exe breaks the convention and lists Close as the 4th item up from the bottom of the menu.

Here’s another example:

That’s the right click menu for SQL Server Enterprise Manager. It’s outdated now, but it used to be the main tool for dealing with SQL Server databases. Like cmd.exe, this application also lists an item below Close in the contextual menu. What’s even more annoying in this case is that the item listed below Close is Help Topics. It’s another option that I will accidentally click on instead of the option I wanted, but, this time, choosing the wrong item will start up another application. And, no matter what computer I’m working on, the help application always seems to take a painfully long amount of time to open up.

Now, I would be able to excuse all of this if it was just 3rd party developers who weren’t following the conventions set up by other Windows applications. The problem is: cmd.exe is a integral part of Windows and Enterprise Manager was Microsoft’s official application for SQL Server Databases. So it’s Microsoft that’s disregarding an informal convention and randomly placing items below the Close option. I can only hope that Microsoft plans on dealing with this problem with Windows 7.

Now that Microsoft has hired Rob Conery from the SubSonic project I’m hoping and praying that Microsoft will put as least as much energy behind SubSonic as they put behind their own .NET projects.

Today, I needed to add another filter to an existing query that was created with a popular ASP.NET ORM that will remain nameless (it’s not SubSonic). I started by trying to decipher the 30 or so lines of code that created the query, but after around an hour of screwing around with it, I had made no progress. Finally, I gave up and asked a fellow employee who is more experienced with this particular ORM if he could figure out exactly what I needed to do to modify the query. Another 15 minutes of staring at the screen and we had finally determined what the intent behind the query was, and where I needed to add another line to filter on the field I wanted to filter on. Now, I concede that maybe I’m an idiot, and that’s why I couldn’t figure how to change the query. But my fellow employee is not an idiot and it still took him much longer than I think it should have to make a change to a fairly simple query.

This isn’t the first time I’ve run into problems with this ORM (it’s not even the first time this week—and it’s only Tuesday). Had we (the fellow ORM enthusiasts and I) have known how troublesome it would be, maybe we wouldn’t have chosen it. But when we were first looking for a decent ASP.NET ORM (around 2 years ago) there really weren’t a lot of viable options out there that offered stability and flexibility, and didn’t require hundreds of lines of XML configuration. So we chose it. And we convinced the skeptics that it was great by showing off how much time it shaved off simple CRUD tasks. And, in the end, everyone learned to use it. Even if it meant coding around some of it’s shortcomings.

But now there are options. Really, really good options, like SubSonic. I’ve been following the SubSonic project for while, and I’d love to use it for a new project. The problem is that it’s another new ORM to learn. And while I’m willing to learn it, I can’t guarantee that everyone working with me on a project is going to be willing to or have the time to learn it. It was a big enough hurdle to convince people that our current ORM (as complicated as it is) was the right option. Now that I’ve changed my mind about it, how can I convince people that SubSonic is going to be any better?

I’m hoping that Microsoft will do the convincing for me. Now that Rob Conery is at Microsoft, I’ve sort of taken for granted that SubSonic will be the default model layer for Microsoft’s new ASP.NET MVC framework. But Microsoft already has other technologies (like LINQ) that could be used in the place of SubSonic for database connections. Personally, I don’t think Microsoft offers anything that has as much potential as SubSonic. My hope is that, even though it wasn’t invented at Microsoft, and it’s a open source project, Microsoft will still put some muscle behind SubSonic. Not just development muscle, but maybe a little marketing muscle too. At least the same kind of marketing they use for the rest of ASP.NET. If only so that someday I’ll never use our current ORM ever again.