Windows 7 - user interface is king

Windows 7 - user interface is king

Summary: Windows 7 places user interface design at the center of the Windows 7 development effort. WPF - Microsoft's new .NET API for Windows user interface development - will also truly come into its own in Windows 7 timeframes. Oh, and WordPad in Windows 7 supports ODF.

SHARE:

The PDC attendee partyPDC attendees received the Windows 7 "Pre-Release Preview" as part of the goodies Microsoft distributed Tuesday afternoon. I have already installed the new OS on a spare computer at home, though as I did that shortly before running out to Universal Studios for the Attendee party (if you are in LA, the Halloween Horror Nights are absolutely spectacular), I haven't had much time to play with the bits. The machines that line the hallways at the PDC magically switched over to Windows 7 after Tuesday morning's keynote, however, which I think is rather telling. I don't remember Microsoft doing that with the Longhorn bits at the 2003 PDC, so it sure seems like Windows 7 is pretty stable for a pre-beta.

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?]

Topics: Software, Apps, Microsoft, Operating Systems, Windows

John Carroll

About John Carroll

John Carroll has delivered his opinion on ZDNet since the last millennium. Since May 2008, he is no longer a Microsoft employee. He is currently working at a unified messaging-related startup.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

44 comments
Log in or register to join the discussion
  • All Open Standards Advocates Should Rejoice.

    Watching the keynote from home I also saw Sinofsky mention that WordPad will support the open formats for OOXML and ODF. I think this is a fantastic move by Microsoft. This will help level the playing field between Office Suite competitors like MS Office and OpenOffice.org.

    With the proliferation of Win7 starting next year people will no longer have to pick an office productivity suite based on format compatibility but rather on the merits of the software.

    Definitely a win for Open Format advocates.
    mikefarinha
  • WPF never really excited me once I started looking at it closely.

    WPF looked cool at first - until I looked at it from a developer's perspective rather than a user's perspective.

    It uses this thing called "XAML," made by people who think XML is a hammer and everything else is a nail.

    Unfortunately, this time they hit a screw. XAML is just horrible. It's too static, and trying to do anything dynamic in it is a royal pain. Also its connection to the code is confusing. I just don't see the point.

    People kept trying to convince me that once I learned it, it would be obviously better.

    But the more I learned about it, the more I really didn't like it. It just doesn't seem to be the right tool for the job. I can do a clean separation of the view and the model/controller using OOP just fine, I don't need it enforced by Microsoft or made into a whole new language.

    I'm sorry. XML is not a cure all, and it didn't cure anything in this case.
    CobraA1
    • Maybe you should have used it a little more...

      You don't have to use XAML at all to build WPF apps. Every control, UI element etc is a .Net class, and if you like building up your object hierarchies with imperative code, then you can do just that. Indeed Petzold's authoratitive tome on the subject doesnt use or mention XAML until chapter 19!

      XAML is not specific to WPF - its a general purpose way of defining (and creating) object hierarchies. Its a lot easier to build tooling that works on XML than imperative code.

      Could they have created a non-Xml based markup for WPF? Yeah, sure - it would not be hard. But for all those like you who dislike xml, there would be plenty of people asking why Microsoft was re-inventing the wheel.
      TheTruthisOutThere@...
      • Maybe not.

        "Its a lot easier to build tooling that works on XML than imperative code."

        So use the object oriented paradigm rather than the imperative paradigm, which works even better.

        "XAML is not specific to WPF - its a general purpose way of defining (and creating) object hierarchies."

        Which XML has always been poor at. It's designed for document markup, not object hierarchies.
        CobraA1
        • Are you that clueless?

          Whether its WinForms in C# or Swing in Java, constructing hierarchies of objects in object oriented languages can degenerate in to untoolable lists of imperative code.

          The way around it is a markup language for object creation. Whether Xml is or isn't the best idea here, its still far better than doing it in code.
          TheTruthisOutThere@...
          • sigh . . .

            You don't need hierarchies to have OOP. OOP just means you use objects. Maybe they're in a hierarchy, maybe not. Sometimes I use polymorphism, sometimes I don't.

            "constructing hierarchies of objects in object oriented languages can degenerate in to untoolable lists of imperative code."

            Rarely does that happen in modern OOP. Sure, it can theoretically happen (any language can be abused), but today there's a big emphasis on modularity and loose coupling that makes replacing components easy.

            "The way around it is a markup language for object creation. Whether Xml is or isn't the best idea here, its still far better than doing it in code."

            I'm still not convinced.
            CobraA1
          • Re: sigh...

            Not sure if you really looked at WPF/XAML with the kind of detail your original post seems to suggest.

            What Truth is suggesting is object hierarchies - as in a panel containing a collection of other controls each of which might themselves contain further more controls and so on. It has nothing to do with OOP's inheritance. (BTW, the WPF framework itself uses clean OOP if that is what you are looking for).

            Look at it this way. In the past, when you did native development, you would use a designer to develop your UI - the designer used to create stuff like RC files. In WPF, it uses XML files called XAML.

            If you liked native development using RC files, it is no different now except that RC format is replaced with XML format.

            If you are against using designers to develop your UI, then you wont get a counter-argument from me - it would be just pointless.
            tick tock
    • I agree...

      ...it's a total distraction from C#/VB.NET and leaves one thinking it is a deliberate attempt to leave programmers high and dry in favor of designers and modellers using MS proprietory software and services which only needs to expose complex markup in a very superficial way. Meanwhile it's difficult to obfuscate. The way Chris Anderson was talking about 'M' on Channel9, this kind of markup has been on the table for years which is simply not true going back to the PDCs of 2000 and the arrival of .NET and C#.
      rmac2
    • XAML is software engineering done right

      When you think of XAML, you think of loose coupling, layered approach and all those software engineering done right concepts. Taking the design part out of your app code and putting it down as XML so designers can work on it without reading code is the right approach.

      Also XAML has platform implication. We all know how frustrating it is to code on top of HTML which is designed as documentation tags rather than app markups. We need sth much better than that for web apps to take off. In comes XAML and problem solved. We can build very capable apps with SilverLight/XAML now. Now that M$ has the weapon for both fronts, what's left is to figure out how to grab the lion's share in the web world while keeping an overwhelming advantage in the desktop world.
      LBiege
      • I don't see what's so loosely coupled or layered about it.

        "When you think of XAML, you think of loose coupling, layered approach"

        Where? For all practical purposes it's like HTML - it's static markup. I don't see what's so loosely coupled or layered about it.

        "We all know how frustrating it is to code on top of HTML which is designed as documentation tags rather than app markups."

        Precisely. XAML doesn't look all that different.
        CobraA1
        • Right

          Right! XAML (or the current implementation of it) is much more cumbersome than the much more product drag/drop/design/code methodology in WinForms. The last thing I want to do is program a WinForms apps like I used to have to do classic ASP. Ugh! What an incredibly UNproductive change!
          Software Architect 1982
        • Explanation

          "I don't see what's so loosely coupled or layered about it."

          Say I'm OK with the logic of my WPF app but not the look and feel. I can therefore give it to the designers to modify its skin, theme or style while leaving the logic alone. Imagine doing the same on a Winform app where there's no markup and everything has to be coded down. You are forced to change the code because logic and GUI are tightly coupled while they don't have to be. XAML-based WPF is more nimble than Winform.

          "XAML doesn't look all that different."

          It's what sits behind XAML and HTML making the difference. XAML is an integral part of the whole .Net environment. HTML is part of, hmmm, nothing. You can force a .Net, J2EE or PHP server to generate HTML pages running some AJAX programs but that's pretty much it. Doing a little conversation back and forth between HTML clients and servers that involves any non-trivial data / objects transfering is like a hacking contest.
          LBiege
          • I need something more dynamic.

            "I can therefore give it to the designers to modify its skin, theme or style while leaving the logic alone."

            Well, that's easy enough. Look at Java. It can be skinned and changed, and nobody needs to touch my logic. The part that draws the controls is completely separate from the logic. I can apply a Windows skin or Java's own Metal skin or something completely different.

            And I **AM** having to change my logic to use XAML, it appears. I wish I could make dynamic controls without touching the XAML, but it appears impossible.

            It's just too d*** static from my point of view. I like my applications to be interactive, dynamic. Not pretty but static.

            I wish I could like it. But the more I try to make it work, the more I hate it.
            CobraA1
  • Unfamiliar TLA

    Pardon me for my ignorance (you'd be so surprised to learn that I'm not a Windows developer), but what is WPF?

    From what I've seen thus far, Windows 7 appears to be "Vista as it should have been", which may actually be enough, though that would make it 6.1 (or maybe 5.3) under a more honest numbering system. I suppose I'll have to come up with a reason for testing my employer's software under it at some point in the near future, but it looks like MS was actually listening to their users this time.

    Nice photo. I assume that's your lady standing opposite you.
    John L. Ries
    • WPF defined

      Sorry, after a week spent at a conference for Windows developers, I forget that not everyone knows what in the hell I'm talking about.

      WPF is "Windows Presentation Foundation." It's the latest API from Microsoft that is based on vector graphics, and brings some of the ease of web development (e.g. text markup files for screen layout) to desktop development. Silverlight is a subset of WPF, borrowing the basic UI conventions while leaving out the stuff that would be hard to do cross-platform (or on lower power devices).

      Yes, that's my wife. She has appeared in other photos I've posted (such as one from my trip to Mexico, which had less to do with the nature of that blog post than this photo does), but back then, she wasn't my wife.
      John Carroll
  • What is WPF?

    I don't know what the style manuals say, but it is helpful when using an abbreviation or acronym to "spell it out" when first used in the article.
    dprozzo
    • Windows Presentation Foundation.

      It is the technology that Microsoft is encouraging developers to use instead of WinForms.

      It is basically the framework that developers use to create the visuals of their windowed applications.

      Also a side note, Microsoft's Silverlight uses a lightweight version of WPF, originally called WPFe (Windows Presentation Foundation Everywhere).
      mikefarinha
    • It's a common MS mispelling, its supposed to be W<b>T</b>F... nt

      nt
      T1Oracle
    • You're right...

      I've spent an entire week hanging out with Windows developers, and that has led me to forget that my blog is not read exclusively by Windows developers.

      Anyway, from a post I just made for John L. Ries...

      WPF is "Windows Presentation Foundation." It's the latest API from Microsoft that is based on vector graphics, and brings some of the ease of web development (e.g. text markup files for screen layout) to desktop development. Silverlight is a subset of WPF, borrowing the basic UI conventions while leaving out the stuff that would be hard to do cross-platform (or on lower power devices).

      In other words, it is user interface development technology for applications targeted at Windows.
      John Carroll
    • The answer you're looking for...

      Windows Presentation Foundation (WPF) is a Microsoft technology that uses Extensible Application Markup Language (XAML) pronounces [i]"zammel" [XML based][/i] to define user interfaces. Much like designing web pages in HTML, XAML makes designing Windows and Web interfaces more precise. WPF forms part of the .NET 3.0 framework. WPFe (where e = Everywhere) is a lighter version of WPF and is referred to as Silverlight (alternative to Flash).

      Designing interfaces with WPF has many advantages such as a smoother interface, unlike the pixellated effects of the older technologies. WPF is also a lot easier for Web developers to get into than Windows Forms developers, because of the Markup Language.

      The coolest thing about WPF is it has the characteristics of a web application, but the flexability of a Windows application. It's a very very powerful technology that all developers should learn.
      General C#