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.

The world's biggest software company is gearing up to tell you how its new modelling platform will transform developer productivity. Modelling is meant to make programming easier, by expressing the design of an application in easily understood diagrams rather than in a bunch of complicated C++, C# or Java files.

The snag is that while models are a great way to design, describe and communicate how an application works, in the end someone still has to write the code. Smart people have made immense efforts over the years to fix this by integrating the code with the model: generating code from models, generating models from code, or even devising ways to execute the model itself.

While these efforts have not failed completely, model-driven development has never taken off in a big way. Developers figure that they have enough trouble writing and debugging code, without taking on the burden of keeping a complex model in synch, or learning the mysteries of Model-Driven Architecture (MDA), with its PIM, PSM, MOF, OCL, ODM, SPEM and so on - have a look at the Object Management Group (OMG) if you want to know more.

Now Microsoft is having another go. Code-named "Oslo", the project includes a store, a language and various tools; and it's going to figure in a big way at the company's Professional Developer Conference next month. Some details are already trickling out. Posts from Don Box and Doug Purdy explain it in simple terms, and this eWeek article has a bit more. The modelling language is code-named D, and I suspect it is another role for XAML - see my post on 10 things you might not have known about XAML if you thought it was just for building GUIs and Silverlight applications.

It would make sense for Microsoft to use XAML, since it is a flexible textual language that is designed to play nicely with visual tools. I'm guessing that you will be able to create the model visually and then run it, just as MDA promises. In a video, Senior Vice President Bob Muglia says:

When a model is created, it's possible for the business process to run directly with very minimal procedures being created around that. The model is the centre of the universe.

There are also hints that Oslo will tie in with Microsoft's cloud computing initiatives - maybe Live Mesh or some more business-focused variant.

Will it work? Microsoft is certainly serious about it. It has even joined the OMG, despite years of antipathy, though I hope this does not mean Oslo will be as complex and unsatisfactory as MDA. I see it as model believers getting together, and a way for Microsoft to get more academic and enterprise credibility for its initiative.

There are however plenty of reasons to be sceptical. Microsoft has had numerous modelling initiatives over the years. In Visual Studio 2003 it was Visio and UML. In Visual Studio 2005 it was class diagrams, Domain Specific Languages (DSL) and Design for Deployment, a way of taking deployment constraints into account before and during development. This article explains the strategy, and enthuses about software factories as the way forward. Now there is Oslo, which looks like a brand new approach. Why think this will succeed any better than what has gone before? Why think that Microsoft will achieve what the fine minds at the OMG and its industry partners have failed to do?

There is also little evidence that this is driven by customer demand. When I talk to Microsoft developers, I don't hear many asking for better modelling tools; and if the subject does come up, it is usually a request for more standards-compliant and up-to-date UML diagramming, not full-on model-driven development. This is a top-down initiative.

Count me a sceptic then; but I also want to give Oslo a fair assessment when it is unveiled next month. It is quite simple. If Microsoft can deliver a modelling platform that really does simplify rather than complicate software development, and one that does not impose a heavy performance burden, then developers will love it. The big question: what is the chance of that?

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.