Windows 7 - user interface is king
Based on what experimentation I have done, though, the Windows team has spent a lot of time thinking about ways to really streamline the user interface. Windows 7 is clearly a lot snappier than any installation of Vista I've used thus far. A number of bloggers claimed, based on previously leaked screen shots, that Windows 7 was just rewarmed Vista, but I think that if Microsoft inaugurated some dramatically different new interface convention, it would be proof that they have learned absolutely nothing from their experience of Vista.
As Samuel Moreau, Principal Design Manager for Windows, said in a session on Wednesday, small things matters from a user interface standpoint. Those small details are the things that can turn into annoyances with frequent use. Simple things like changing the color of the "tasks" bar and fonts used in the photo gallery make a huge difference. Vista's color scheme promotes the frame to the detriment of the photos in the gallery (as well as leaves less space for the photos), while the new frame does a better job of making the gallery simple and intuitive...and leaves more room for content. Another small change involves a more refined toolbar interface that removes some of the "action" cues (such as mini-buttons atop taskbar buttons whose intent was to indicate the presence of additional menus, but served to make the menu look "busy"), replacing them by interface elements that expect you will understand that right clicks bring up the new "jump list."
Granted, those are incredibly minor changes, and there are bigger adjustments that I will discuss later (I picked the previous points because they were examples used by Moreau to describe how small changes have big usability effects). The distinguishing factors of a well-designed, intuitive application may be hard to define on paper, but are obvious when viewed comparatively. It's simply true, as Moreau stated, that applications often do the visual equivalent of shouting at users in order to grab their attention, which can become a real cacophony when all applications do it. Windows as an OS was guilty of this as much as standalone applications. Windows 7 tries to turn the volume down (example: notifications are now collected in a single, unobtrusive collector in the status tray, a region that itself has been cleaned up, at least on the Microsoft side), and extends those lessons to the applications included as part of Windows (and, hopefully, to other applications made by Microsoft).
The clearest sign of a shift in the mindset surrounding the Windows development team, however, is the fact that an interface designer presented at a Professional Developers Conference in the first place. It was a lunch sessions, so the room wasn't packed, and a few attendees did leave in the first 10 minutes once they realized that it was about squishy design principles and philosophies and not subjects normally of relevance to hardcore computer geeks. Microsoft, however, needs to lead by example. COM, a thoroughly geek-oriented technology, took over the Windows world because Microsoft used it extensively in their own products. A Microsoft that ranks designers alongside its framework engineers will result in products that influence the development strategies used by third party ISVs. At the next PDC, I expect more will attend the design sessions.
Anyway, I'll go into more depth on Windows 7 as I have more time to play with the operating system.
Windows 7's release (it betas in Q1 next year, with release intended for some time in 2009), however, will be a timeframe within which we will see a lot more WPF applications. Standard inclusions such as Paint, Wordpad and the Calculator have gotten the WPF treatment [CORRECTION: Paint, Wordpad and the Calculator do NOT use WPF; see additional details at the end of this post] (and all use the "Ribbon" interface introduced with Office 2007, support for which was released this week to .NET developers as part of a set of new WPF controls). As noted in the keynote, AutoCAD by Autodesk has made the move to WPF. Of greater importance, however, is the fact that Visual Studio 2010 will have an interface completely written in WPF.
This creates new levels of UI customizability. Scott Guthrie, during Tuesday morning's keynote, threw together a plugin that customized the look of the "comments" tags used to annotate classes and methods in the code editor window of Visual Studio 2010. WPF, clearly, enables levels of customizability that would have been very difficult, if not impossible, in older native interfaces.
One of my pet peeves with respect to Microsoft's handling of the transition to WPF, however, has been insufficient use of the technology by internal Microsoft teams. The technology is two years old, and the lack of major Microsoft applications written in WPF has created doubt as to whether WPF is truly the basis of future user interface development atop Windows. The first Microsoft person I asked about this problem gave what I thought to be the wrong answer. We didn't speak on it much, but the impression I got was that there should be no preference given to managed code development atop Windows. That statement, in my opinion, was belied by a PDC where sessions devoted to managed code development outnumbered native code development sessions by a factor of 10 to 1.
Admittedly, however, the individual I asked was in the beer line at Universal Studios (as was I, so blame me for talking shop during a party). So, I rephrased the question the next day, asking a different person on the WPF team, and was rewarded with a more nuanced answer. Basically, Microsoft hasn't converted all their applications to WPF because a) it would be an insane amount of work to do all at once, jeopardizing many billions in revenue (though Visual Studio and Windows applets now seem ready to bite the bullet), and b) WPF took some time to achieve the performance characteristics necessary of major applications like Visual Studio.
On the question of "commitment to a WPF future," Mr. WPF (I can't remember his name, though Vaseem seems vaguely correct) said that Microsoft will ALWAYS ensure that all functionality has both sensible native and managed components, not because Microsoft wants to encourage schizophrenia in the development community, but because others who make frameworks that run on Windows might wish to plug into the same infrastructure that Microsoft uses for its own managed layer. In other words, if you are writing user interface applications for Windows, WPF is the API you should use. The native layer exists mostly to assist others who want to plug in at a deeper level with their own code (often to build their own framework).
The fact that those native interfaces are welcomed by those who refuse to consider managed code is a happy, albeit important, accident. If COBOL applications still play important roles at big companies, so will native Windows applications. You shouldn't, however, create new applications in COBOL any more than you create new mainstream native applications atop Windows.
Miguel de Icaza was also in attendance at this year's PDC, and though he didn't talk about WPF very much (WPF isn't supported by Mono (an open source .NET runtime), though Moonlight supports the Silverlight subset), he did mention an unnamed game developer who found their development productivity quadrupled after they shifted their application to Mono. That, I think, is the reason native code development will grow less common over time. Productivity gains will be the driver behind the shift to .NET among Windows ISVs.
One last thing: I can't build an entire blog post out of this (and it's not really related to the point of this post), but it's a useful nuggest I just found in my notes. The new version of WordPad, besides sporting a WPF interface and support for OXML, also supports ODF (according to Sinofsky...I haven't verified it yet). Whether that will fill the open source world with glee or consternation remains to be seen.
[CORRECTION ADDITIONAL DETAILS: when I checked this blog from the conference center at around 2:55PM, I noted PB_z's comment stating that Paint, WordPad and the Calculator do not use WPF. So, I ran down to the expo hall where Microsoft Windows 7 experts had been camped out since Tuesday, pushed past security people who didn't want me to enter at the time (okay, slight exaggeration, but it was near 3:00, the official end of the PDC), and decided to hear the story straight from the proverbial horse's mouth.
As it turns out, WPF (which stands for Windows Presentation Foundation, the new .NET library for user interface development that Microsoft wants developers to use) is NOT used in those applications.
I find that rather disappointing, though all in all, it's a grain of sand in an oyster that was, on the whole, rather tasty (thanks Mike Daly for the metaphor). Even so, I will be asking someone on the Windows 7 team the official explanation as to why WPF wasn't used for Windows 7 integrated applications. I don't buy the argument that performance is so critical in Windows 7 that they can't afford the incremental difference that a WPF version of Paint would entail (and they did go through the trouble of rewriting the user interface).
Like I said in this blog, it is Microsoft's job to lead by example. I think Microsoft would have an easier time pulling the Windows development community onto the WPF bandwagon if most Microsoft applications used WPF. I'm glad they are doing it with Visual Studio 2010. Why not Windows 7 Paint, WordPad and Calculator?]