I just ran a usability study with 9 participants where we asked them to build two forms, one a WinForm and one a Web Form, that had a drop down list that drove the contents of a grid below it. The participants had to figure out how to fill the drop down from all the cities in the database, and then how to fill in all the rows that matched that city in the drop down (from a different table). We gave them a little more then an hour for each form.

Whidbey has a ton of new data binding features, and there were a couple of interesting observations out of this study. First, users got much farther along then they did in similar studies with the Everette feature set. All the participants got to see data in the form at least a little bit. This seemed to make the whole experience much more pleasing for them. This was a great thing to see. I think getting that positive reinformcement early in the process will improve the first impressions of .NET users and will contibute significantly to driving adoption during the evaluation phase.

The second interesting thing harkened back to something that I have observed many times over the years. Users like to layout the controls onto a form, and then they like to make those controls work. The only caveat to this is that some experience .NET users started the task by dragging data components out of the toolbox, because they knew from experience this was the most efficient way to accomplish the task.

In any case, there was definately a very strong “Toolbox First” approach to writing these forms. A lot of the new data features in both win and web scenarios are available and easily discoverable when using this approach, and users seemed to be both successful and pleased by features that worked with the toolbox first approach. The data features that did not work “toolbox first” were either not discovered, or users struggled to make them work and abandoned them.

So from now I think that when we think about feautres that support any UI programming, we should always think that the user is going to approach it by laying out the form first, and then making the design of the form work by writing code, running wizards, using other features, etc... If users have to do work somewhere else in Visual Studio before they can start laying controls onto the form, they probablyt won't discover this dependency, or won't want to use that feature.