The Perils of Removing Features

In the last couple of weeks, Microsoft have released preview versions of two new software products. First up is Windows 8, the highly anticipated successor to Windows 7, sporting the brand new “Metro” interface, which promises to deliver a Windows UI suitable for tablet PCs. The other new product is Visual Studio 11, which debuts a number of key new features, including the next version of .NET and the ability to create Metro applications for Windows 8. All very exciting, and lots of us rushed to try out the preview versions as soon as possible.

Given that both products essentially are upgrades to existing and successful products, one would expect the reaction to these new products to be very positive. Both are loaded with cool new features and usability improvements, and yet the majority of the online chatter has been to complain.

What is the problem? As well as giving us new stuff, both products have taken something away. Windows 8 has taken away the Start menu, and VS 11 has taken away the colours from the icons. These two omissions, though relatively minor in the context of the overall changes, have managed to dominate the reaction to the new products.

One senses a little bit of frustration on the part of Microsoft (e.g. these two posts from Scott Hanselman), and you can understand why. All that hard work on new features has seemingly gone unnoticed, and all people can do is moan about two decisions that were intended as a bold step to improve user experience.

So what is the moral of the story? Users hate having features taken away from them. It doesn’t matter if you tell them that the feature removed was redundant, or poorly implemented. They feel robbed and short-changed. They feel like they are not understood. And they resent having to change the way of working they have been comfortable with.

Microsoft have a few options available. First, they stick to their guns, and say “you’ll thank us later, once you understand”. That may of course be the case, but is it really worth upsetting your customers over this? Second, they back down, and give us back our start menu and our coloured icons. A victory for the customer perhaps, but that is a recipe for never making any progress. The third option is to make it configurable. Let us choose if we want the old-fashioned start menu, or the colourful icons. If the new UX is truly an improvement, over time, people will be won over, and the obsolete features can be removed in the next version.

In summary, if you want to remove a feature from your application, even if you consider it to be an unnecessary one, consider first making it optional (whether that be on or off by default). The customer isn’t always right about what the best UX is, but they are right about what they like, and if they don’t like it, they won’t buy it. It will be very interesting to see which direction Microsoft take when the next preview versions come out. If they get it right, I’m sure they’ll get more bloggers talking about how cool these new products are, instead of moaning about what was taken away from them.

IronPython 2.7 Visual Studio Integration

I’ve been trying out IronPython 2.7 beta 1, which includes Visual Studio 2010 integration and I’ve been very impressed. Here’s a brief rundown of the features (at least the ones I’ve found).

Project Templates

Four new project templates are included – these are a Console Application, a WinForms application, a WPF application and finally a Silverlight web page. The templates each have just enough code to get you started.

The Code Editor

As you might expect there is syntax highlighting for Python files:

Another nice touch is that pressing backspace with the cursor at the start of a line of code moves it in one level of indentation. What I wasn’t expecting was intellisense, but it’s available in some places (though not everywhere since the dynamic nature of Python means you can’t guarantee that a variable will keep the same type that it was initially assigned).

Another nice touch is red squiggly lines indicating syntax errors – very useful if like me you keep forgetting the colon at the end of if statements:

Also the Navigation Bar is populated with the classes and methods in your source file:

Another very nice touch is that the Find All References and Go To Definition both work. Also the Object Browser includes classes and methods from your IronPython source files.

Solutions

When you create an IronPython project it creates a regular .sln file, but your project is a .pyproj file (which like .csproj is an msbuild project file under the hood). It doesn’t have too many configuration options, but it does allow you to add search paths for external python scripts or .NET libraries. You can also specify which your startup file is.

Search Path can also be configured in the Solution Explorer:

The Debugger

One of the most compelling reasons to use Visual Studio to write your IronPython apps is support for the debugger. You can set breakpoints and step through your code:

Sadly tooltips showing the values of variables don’t seem to be implemented. The only tooltips I could get up was by hovering over the open quotes of a string literal. Also you can’t get at variable contents using the Immediate or Watch windows. Neither can you use Python variables or expressions for breakpoint conditions.

However, the Locals window does come to the rescue and can be used to examine the contents of variables while you are at a breakpoint.

The IronPython Interactive Window

Another great feature is the IronPython Interactive Window. This is the same old familiar interactive IronPython interpreter you get when you type ipy.exe, except that it has a few tricks up its sleeve. It supports both syntax highlighting and intellisense, which works even better here since it can look at the live objects rather than having to analyse your source code.

There is an option on the debug menu to execute your application in IronPython Interactive:

This brings up the IronPython interactive window and attempts to run your project in it. You can even change scope, and investigate the value of variables in the various scopes of the different modules of your application. Here’s it running the simple test app I showed earlier:

There are still a couple of issues using this for debugging. First, it doesn’t apply the Search Path to the interactive session so import statements fail. Second, running in this mode doesn’t seem to invoke the debugger, so you won’t stop at breakpoints. Hopefully these issues will be addressed in a future update of the tools.

Another nice feature is the ability to select IronPython code in the editor, right-click it and say – Send to Interactive. You need to be on a blank line in the interactive console though or it can get a bit confused. But this is a great way to get longer functions into the interactive window.

Conclusion

The Visual Studio support for IronPython is very impressive. It still needs a few enhancements, particularly in the area of debugging, but there are still plenty of advantages to using Visual Studio for IronPython development over simply working directly with files.

Since this post is fairly long, I’ll save comments on Silverlight with IronPython for another time.

Visual Studio Beta 2

I wrote a post a while ago criticising Orcas Beta 1 so I suppose its only fair that I write about Beta 2. I have been using it for a few months now, and have found it to be excellent. I have only discovered one crash so far (to do with intellisense, and apparently fixed already for RTM).

The multi-targetting feature is superb, and the WPF designer has improved a lot (you can create a click handler for a button by double-clicking), although I can't seem to find any way of browsing other available events and adding handlers, short of using the intellisense in the XAML file. Some of my other criticisms still hold true - there is no help in setting FontFamily and Ctrl-Click copying of controls doesn't work.

I was able to attend a presentation by Daniel Moth last Thursday, who demoed some of the new features for web development. I am not an expert in ASP.NET, but have been doing a bit of learning in the last year, and the new features look excellent, particularly getting better intellisense (even in Javascript) and help with CSS. These features should be very helpful for me getting up to speed.

Silverlight support is sadly not going to be built-in, although to be fair, Silverlight 1.1 has still not been officially released. Having said that, the Silverlight development story is very good in VS2008 compared to the pain of working on it in VS2005.

Overall though, I'm a lot more enthusiastic about VS2008 having used the Beta 2. What is even more exciting is the possibility of using the new C# 3 language features against .NET 2.0 projects. This is a really compelling reason to upgrade even if you have no intention of using the .NET 3.0 or 3.5 libraries.

Orcas Beta 1 - Not ready for the Prime time

I've had Visual Studio Orcas Beta 1 installed on a Virtual PC for a while now, and have mainly been using it to do some Silverlight 1.1 development. For the most part it has worked OK, although I've had a few niggles with it:

• Doesn't let me step through JavaScript (despite turning on Script debugging in IE)
• Insists on covering up part of the code with a toolbar window whenever I run in debug mode.

But today I tried to develop a WPF application in it, instead of simply using Visual Studio 2005 with the .NET 3.0 extensions. The experience was painful. The designer regularly threw exceptions, and Visual Studio itself crashed a few times.

More concerningly, the WPF designer itself seems very lacking in the basic functionality we have come to expect with Windows Forms. I am very enthusiastic about WPF, but if I am to persuade anyone at my work that using it would be a good idea, we need a much better experience for those who just want to create a Window and add controls and event handlers if they are to be tempted away from plain old Windows Forms.

• You have to continually ask the designer to show you just XAML - it defaults to a split view with not enough space to see either the layout or XAML
• Double-clicking a button in the designer doesn't add a handler
• You can't choose font settings in a nice dialog - you just have to know what you can enter into FontFamily
• You can't ctrl-click and drag to copy a control

So unfortunately, Orcas Beta 1 is very much a beta, and still a long way from being a release candidate. Hopefully there will be a beta 2 before too long, with a much enhanced WPF designer, and built-in Silverlight support.

Visual Studio Regions

Visual Studio has a really nice regions feature which allows you to mark off sections of a file so they can be collapsed in the editor.

#region Painting Functions
... code goes here
#endregion

Now it seems that at Microsoft, there is a growing tendency to group absolutely everything in a class up into groups such as:

• Public methods
• Public properties
• Protected methods
• Private methods
• Events
• Private data

And many developers who see this then go about implementing this in their own code, removing any regions already defined and moving things into new regions based on their accessibility.

But here is the issue I have. How useful an organization is this really? I like it when a class has all of its private data together (I prefer at the top, but some put this at the bottom), so that is fine. And it makes sense for the constructors to be kept together.

But grouping methods by whether they are private, protected or public makes about as much sense as organizing your house by putting all the tables in one room and all the chairs in another. Yes its very organized, and yes you will know exactly where to go when you want a chair, but its not much use when you want to sit down at the table and eat dinner.

Say I'm looking at some code and I see a call to a CalculateOffsets function. How should I know whether I will find it in the public, private or protected methods region?

Surely it makes more sense to group functions into regions by whatever logic the class does. A good example would be a region for the Dispose pattern which includes a public method, a protected method and a finalizer. Another example would be the implementation of an interface such as IComparable. In a Windows forms class, you might have a region that had event handlers for all controls on the form, or a region for just for dealing with one particularly complex control's events.

I'm not saying that the Microsoft way doesn't have benefits or should never be used. But its the one-size-fits-all approach that bothers me. I don't want to expand eight regions every time I open a file only to find most of them are empty or just have one item in each.