Over the weekend Microsoft's Scott Guthrie, Coporate VP of the .NET developer division, announced that the open source jQuery Javascript library will be integrated into Visual Studio, the main Windows development tool. Further, Microsoft will treat jQuery as a supported product within technical support contracts, and will use jQuery to build new controls for ASP.NET, its web platform.

This is a breakthrough both for Microsoft and for open source. In the past, Microsoft has preferred to reinvent the wheel rather than adopting existing open source code. For example, when the company delivered Visual Studio Team System, it did not use existing open source products like NUnit for unit testing, or Subversion for source code management, or Nant and CruiseControl for build management, but shipped all-new equivalents. That strategy may have backfired. At the recent Remix08 conference in Brighton, I noticed that when a developer asked about Team System during a panel discussion, he was immediately advised by several other delegates to stick with the open source products.

I don't mean to suggest that Microsoft has only just discovered open source. After all, the company has its own open source community focused on interoperability, and publishes source code to some of this products under various shared source licenses. On the developer side, Microsoft sponsors significant open-source products like IronPython and IronRuby. But the jQuery case is particularly interesting, because Microsoft already has its own Javascript library called ASP.NET AJAX.
 
Is Microsoft now abandoning its own library? At Remix08, I asked Guthrie this very question. "We are definitely still investing in ASP.NET AJAX, there's lots of features coming out," he told me. "But there's a proportion of developers coming from other platforms where having support for other AJAX frameworks makes it more likely they'll use Visual Studio, which is good for us, and there's some proportion of developers on .NET that would prefer to use other frameworks in addition. People tend to be pragmatic. jQuery is great for CSS selectors and for the animation engine, but doesn't have a type system like Prototype or ASP.NET AJAX. We see a lot of developers wanting to use the ASP.NET AJAX class and type system, and then use CSS selectors and animation from jQuery."

In his announcement, Guthrie explains how jQuery support came about. Developers were asking for features to be added to ASP.NET AJAX, when they were already in jQuery. "As the team started to investigate building it, though, they quickly realized that the jQuery support for these scenarios is already excellent, and that there is a huge ecosystem and community built up around it." That sounds like common sense to most of us, but getting to this point has been a considerable journey for Microsoft.

The move is not without risks. If jQuery is good enough, then what about PHP, an open source alternative to ASP.NET? What about using Linux instead of Windows, or OpenOffice instead of Microsoft Office? The company can hardly suggest that open source stuff is never any good, when it is integrating open source code into its own products. Instead, Microsoft has to compete on real-world issues like quality, productivity, reliability and support, which can only be good for its customers.

"Developers, Developers, Developers" is the famous rant of Microsoft's Steve Ballmer. Maybe he picked the wrong word. I'm just back from the Remix 08 conference in Brighton, where the company's Principal Researcher Bill Buxton spoke on software design. He made a big impression, especially when he suggested in an interview that unless Microsoft changes its culture in a way that put design at the core of its software, the company would die.

Underlying this is the ascendancy of Apple, widely admired for its design, and the mixed fortunes of Windows Vista, which was meant to have great design but in practice has plenty of irritations many of which are design issues. There is a tendency to think of design as primarily about graphics and layout, but this view is too narrow. Design is about the user's experience, and encompasses all kinds of user interaction.

Few companies have the resources of Apple or Microsoft; but raised expectations of what constitutes good or even acceptable design affect the whole industry, including developers of internal applications as well as web site authors. Design failures are frustrating for users; and the consequence is that software is used less, and satisfaction is lower.

An example which comes to mind has no graphics at all. A certain telecom company with a colourful name has a telephone menu system which is unavoidable if you need to call support. Whenever I have to use it, I feel my blood pressure rising before dialling the number. I know I will have to go through numerous layers before being allowed to speak to a human. I know I will be given mandatory choices, none of which apply to me, forcing me to lie. I know each step will be ponderous, with a recorded messages I have heard before, and invitations to use the web site instead - if I thought that would do, why would I call? If you call outside working hours, you are taken through all the steps and told right at the end that the office is closed, goodbye. When I do eventually speak to someone, I am already in a bad temper.

This is the consequence of poor design. I could reel off countless further examples, such as Microsoft Outlook 2007, with its obscure dialogs - click Message Options to show email headers, very clear NOT - its habit of blaming the user for its own shortcomings, "The data file was not closed properly," and its slow performance with large mailboxes. Some of these are technical issues, but because they directly damage the user experience, they are also design problems.

Enough ranting. The interesting question is how developers and designers can work together to improve software design at every level. Buxton talks about continuous design, where designers participate in the development process throughout, rather than only at the beginning of a project, or even worse, only at the end. It is a good thought; but as the panel discussions at Remix demonstrated, there is no consensus about how the developer/designer relationship should work.

There are signs of change. Tools are appearing which have both developers and designers in mind, such as Microsoft's Expression Blend which can open Visual Studio solutions, or Adobe's product codename Thermo, which converts artwork into application code. That said, it is people rather than tools that hold the key. It is about developers ceding some of their power to designers; and about designers learning more about the constraints under which developers work; and about learning to treat poor user experience as a defect. It is not easy; but teams that get this right will gain a substantial commercial advantage.

I just can't stand it. I was talking with someone recently who was thrilled about the developers in his organisation. I asked about the testers and writers. "Oh, you mean the tester monkeys?"

I gave this guy my best cold stare and said, "Product development requires many more people than just coding monkeys. And, I don't know any code-monkeys or test-monkeys or writer-monkeys or any other monkeys in organisations. Do you?"

Look, if you want to develop systems, you need all kinds of people, from developers to testers to writers to release engineers to business analysts, to whomever else you need. The larger and more complex the product, the more roles you need.

Don't make the mistake of being developer-centric, test-centric or particular-role-centric. Producing a product (or system if you prefer) requires many people to do their jobs well.

No monkeys need apply.

The first week of September brought the most interesting tech news for ages. The reason is Google's launch of a new web browser, called Chrome, which has stolen the thunder from Microsoft's beta release of Internet Explorer 8. The browser wars are back, and with Firefox, Safari, IE, Opera and now Chrome, users have more choice than ever.

That's all very well for consumers, but will this make any difference in the Enterprise world where IE still reigns supreme? It is hard to see this changing soon. Web designers hate IE for its poor standards support (though this is much improved in IE8), but it has plenty of attractions for system administrators, integrating with Microsoft's system management tools, controllable through group policy, and easily kept patched with system update services.

All this is true; but having played extensively with Chrome over the last few days I think it will have a wide impact. For a start, like Google search and Google mail it will leak into enterprises simply by user choice. A remarkable feature of the Chrome install is that it does not trigger Vista's UAC (User Account Control), because it writes only to areas within the user's profile. Put another way, it does not require administrator rights to install, so machines will need to be tightly locked-down to prevent it. A web site might say, "best viewed with Chrome", and the user could have it installed and running a couple of minutes later.

What is more significant is that Chrome has the potential to change expectations over what a browser application can be like. Chrome includes Google's Gears extensions, which means browser applications can save files locally, run a local database, or even run off a local web server when offline. Another interesting feature is that Chrome can install a desktop shortcut to a web site, and that sites opened from one of these shortcuts appear in a full window without any browser controls at all - without any "chrome", in fact. This is by design. If you put the offline capabilities of Gears together with desktop shortcuts and a window that does not look like a browser, then you get something that users will not easily distinguish from ordinary Windows software.

 
Spot the difference: this page was opened from a Chrome shortcut and has no browser furniture.

With skilled coding, such applications can look good and perform well. The V8 JavaScript engine compiles to native code, and is designed to handle applications larger than today's AJAX sites. The Canvas element in WebKit, the rendering engine used by Chrome, enables flexible 2D graphics without the need of a plug-in. What Google has done is to raise the bar for web applications, letting them compete more effectively with old-guard software like Microsoft Outlook.
 
Personally I won't be ditching Microsoft Office just yet. Still, I respect what Google has achieved with Chrome even in this first beta, and I like the fact that the code is open source; anyone can download it and compile their own build in Visual Studio 2005. It is early days: but my guess is that we will see a lot more of Chrome in the coming months and years.