As mentioned at the start of the last post, I wanted to pause for a moment and look back at the dialogue we’ve had via this blog, further exploring a few of the exchanges and inquires, just as we did with the Engineering Windows 7 blog. We’ll pick up where we left off the last post, discussing the importance of feedback, and then we’ll look at the discussions around the Ribbon, Metro style, and Media Center availability.
[h=4]Ribbon[/h]We thought the amount of energy around the redesign of copying files was immense. And then we posted about Windows Explorer. We even went into this knowing that there would be a lot of “energy.” To anyone who has hit on a controversial blog topic, the patterns are familiar. Rather than focus on the number of referrals from Slashdot (a lot more than other posts) or blog server performance (we tweaked our site layout for efficiency), let’s focus on the design choices.
Most importantly, this is one element of the product. Just as with the copy conflict dialog when you shine a light on it, brightly, there is a tendency to miss some things (on both sides) and to place more emphasis than it deserves. To return to our movie analogy, it is like when a specific scene is picked to market a movie and it inadvertently shifts the dialogue about the film (or even the target market). The good news is we have lots to talk about—a lot.
Without repeating the first post, I would add that we do believe we have taken into account many of the criticisms we were certain would surface. We chose the ribbon mechanism, and to those that find that a flawed choice, there isn’t much we can do other than disagree. We were certain, and this proved out, that the dislike of the ribbon is most intense in the audience of this blog. Said dislike, we assumed, would produce a high level of commentary, much the way some topics during Windows 7 blogging did. That assumption was correct.
There was a lot of back and forth over the role of the mechanism for different customers—is it advanced or beginner targeted? There’s irony here in that menus were once for beginners (the keyboard was what power users used), which then were simplified with toolbars. Context menus were originally shortcuts for advanced users, but ended up being used more by everyone. Now we are hearing (and seeing) that menus and toolbars are being touted for advanced users. Of course, we have been trying to unify these disparate mechanisms in an effort to have a simpler experience—fewer mechanisms means less UI surface area, by definition. While there are a lot of opinions, the one thing we know is that the satisfaction with our products that use the ribbon is much higher and the usage much broader and deeper. We also know a very small set of people remain unhappy. That was true in versions before the introduction of the Ribbon mechanism, though obviously for different reasons. It might be the case that no matter what we do, there will be a small set of people that are not satisfied?
To me the most interesting feedback has been about the visual overhead. The role of “Metro” came up and how we should use a lighter graphical treatment and also just expose fewer commands because people want minimalism now. Obviously we all want less—fewer exposed features means less surface area which means less code to write, test, maintain. Minimalism is not hiding features or making useful things hard to get to. Minimalism is about stripping things down to fundamental features. The question then is really defining that set of features. Our approach to minimalism is to avoid layers of commands or hidden pockets of features (those mechanisms themselves become conceptual and code overhead—bloat can come from UI itself, not just what UI exposes), and to reduce the number of mechanisms in the UI. In doing so, we aim to present the capabilities of the product in one manner. We also know that minimalism is not about doing less stuff, especially in light of all the feedback over features people want to see added to explorer.
The progressive or hierarchical rendering of features is the world we came from—some features are keyboard only, some context menu only, some top-level toolbars, some on toolbars you had to show/hide, some on menus or submenus, etc. This collection of mechanisms doesn’t work well for anyone except those who invest a lot of time. Of course if you invest a lot of time you become a very outspoken opponent of change. Perhaps there is some of that? I was a strong proponent of the Office 2000 “adaptive menus” that literally drove people crazy, and those were a deliberate attempt to have less clutter and less surface area. One failure is not a trend but the lesson that “hiding is not simplifying” is valuable I think.
We have work to do as we continue to refine the way we have organized commands and what commands we should organize (map network drive, powershell), as well as the default settings and graphical treatment. We are actively considering the feedback in this regard. We share the goal in having a clean user experience. We also have the goal of making sure people can get done the things they do want to get done. The role of data here is important when used correctly and it also helps us to avoid the use of small data sets or anecdotes driving the choices.
As the role of “Metro” came up, it became clear that for some, Metro is symbolic of a particular “palette” of colors and fonts, and perhaps some notion of controls. Several of the screen shots proposed were ones where some set of (less favored?) commands were dropped but primarily the change was to reduce the overall palette. We found the comparisons to some Metro apps like Zune interesting when you consider the amount of usage of competing products that are so much more “dense” and the requests for features that are in neither of the media players (CODECs, tags, etc.)
We’ve been looking at this and also trying to reconcile the feedback in this very forum around Windows 7 feeling washed out or “pale.” We actually added intensity and pixels to what we had in the Windows 7 design because of feedback we received via the blog. We’ll continue to look at this area of course, but want to avoid “churn” at a stylistic level because so many third-party products tend to mimic the Windows experience without utilizing the built-in metrics and system settings to obtain the palette (so things can look awkwardly different). This leads to the discussion of Metro styling.
[h=4]Metro style[/h]The challenge with the discussion of Metro style was definitely due to the ordering of our blog posts. We were not sure whether to speak abstractly at first or concretely. Given that nearly 6 million people viewed the video demonstration of the Windows 8 user experience (a rather in-depth demo) we felt that people already had the context for the user experience. That probably wasn’t a good assumption on our part. We also know that even with that much background, until you can touch the software it is going to be difficult to develop a complete picture. Many products look better or worse until you can use them. I’m fairly certain that in this case we have a lot of upside.
In many of the comments, people primarily focused on Metro as what I would say are the graphical elements of the user interface—it was Metro v. Aero. We’ve seen a clear turn where Aero is the past and Metro is the future. And with that a strong desire for the existing Windows experience to take on a new look or a Metro redesign. These comments are usually focused on style and looking "old" or "new." Generally, those details of the visual styling come later in the engineering process, but we wrongly assumed that this was known. Stating that, we could have short-circuited this concern.
A lot of this discussion will depend ultimately on what Metro comes to mean for folks. As we looked at Metro style for Windows 8, as we talked about in an earlier post, we see much more than a more monochrome set of visuals and fewer controls (when there are fewer commands). We see a new platform, a reimagining of Windows. For Windows 8, Metro style means a new type of app—an app that learns from and improves upon the current (and most popular) platform. This is a lot of what we’ll talk about at BUILD. If you watch Video #1 you can see Metro style apps at work. At BUILD we’ll talk about the attributes of those apps, and the tools and languages you can use to create those apps. What we’ve said is that there is a very deep platform that provides for a rich opportunity for apps of all types—from media to social to games to productivity. We don’t see any limits to where this will go.
The other part of this dialogue is about the desktop. The desktop is many things to many people. To some it is literally the place where the important documents are stored (the most important folder). To some it is the Explorer window for managing files (it is an app to some). To some it is a metaphor or even Windows itself (toolbars/ribbons, menus, MDI/SDI, etc.). To some, their view of the desktop is an app they run “all the time” and they experience Windows only through File Open or maybe the Start menu (for example, people who for the most part use Outlook or Word, or Photoshop, or AutoCAD, or a line of business app). The desktop might even be relatively invisible to someone who does a lot of web browsing.
The unique element of Windows has always been the “open market” approach to interface. We embraced how people used and adapted the Windows APIs to bring unique experiences to market. Within any context there really isn’t a single “desktop” experience. Certainly some have been critical in the past that “Aero” did not achieve a uniformity or consistency, even within Windows.
We said the desktop is like an app in Windows 8—you can use it or not, as much or as little as you want. Some have said “it feels jarring” to go to the desktop. My perspective is that it is no more or less jarring that switching between any other apps if you embrace diversity or experiences that are built for a specific task or purpose. Today’s websites (and mobile apps) do not strive for consistency across disparate properties or apps, and the shell of a browser does little to prevent a jarring effect as you switch tabs (or apps). We’ve long embraced apps that have palettes or toolbars, full screen / windowed / MDI, built-in controls or custom controls. The mechanisms to implement this variety are part of the desktop heritage. Some wish for more uniformity or policing. As a member of the team that built our early Windows tools, I know we tried. Even in the most homogeneous platform, developers will strive to differentiate and build their user experiences for specific purposes and experiences will diverge from commonality Commonality was an answer to complexity in another era--today we are surrounded by digital experiences of all different types and we readily adapt (just as people adapted to a wide variety of print formats or video formats as these technologies improved from their first generations). The answer today is whether the design works in the context for which it was intended.
That diversity allows us to say with confidence that going from Metro style to the desktop will be harmonious—as harmonious as switching apps or sites is today. It will take orchestration at the top level to make moving seamless—that’s why you see things like switching between apps, snapping apps, or even using ALT+TAB between apps, and the desktop itself, all mechanisms that just work. The animations will work. Copy / Paste will work. Even bridging between “legacy” control panel applets will work.
There’s a lot more to this topic, as I said. I wanted to touch on some of the feedback and play back some of what has occurred to me and other folks on the team as we read through the dialogue. I think we need to do more in terms of showing the product and maybe we erred on the side of too much transparency too soon, but we’re on board and moving forward. BUILD is just a few days away.
[h=4]Media Center[/h]While not a central topic of feedback, I received about 50 emails about Media Center. I want to reassure customers that Media Center will definitely be part of Windows 8. No doubt about it. Knowing how strong the support for Media Center is among pre-release testers, we still have work to do to make sure the quality and compatibility with add-ins is what you would expect even in pre-release (as with any release of Windows, compatibility is a major effort and when we work on the underlying video engine, as one example, we have to make sure features that push these areas receive adequate coverage).
In the coming months, many folks will be testing pre-release builds of Windows 8. As everyone knows, two things are always the case early on. First, the software is not done and things will change—features will be added and removed. Second, the different editions or SKUs are not developed or announced until late in the development process (closer to market availability).
Media Center will not be part of the first pre-release builds. Some other features/capabilities will not be in the first pre-release builds including: Windows 7 games, DVD Creator, upgrade setup, Dot Net 3.5 (I will leave room for perhaps a couple of other relatively low profile items). These are engineering decisions as well as business decisions.
As we get closer to market availability, we will make sure to explain how not just these specifically but all features of the product will be made available. As an aside, it is early to start the dialogue about a preference for one SKU with Windows. We’re well aware of this feedback and we always need to balance it with the feedback from our business partners who value a different approach. We’ll cross that bridge when we come to it. Interestingly, the feedback about Media Center was predominantly “we will pay extra, just include it” based on the input directly to me. Today Media Center is part of “premium” SKUs for Windows, which means that is the case today.
In addition a lot of folks said “everyone I know uses it.” As I said, we’re completely committed to delivering Media Center in Windows 8, but I wanted to share some of the usage data. This data in no way influenced not delivering it as part of the first pre-release build—we are as committed as ever to Media Center.
Our opt-in usage telemetry shows that in July, Windows Media Center was launched by 6% of Windows 7 users globally with the heaviest usage in Russia, Mexico, and Brazil (frequency and time). However, most people are just looking around; only one quarter (25% of 6%) of these people used it for more than 10 minutes per session (individual averages), and in 59% of Media Center sessions (by these 6% of users) we see almost no activity (less than a minute or two of usage). TV was the most common scenario we observed, and not surprisingly, traditional media (DVD and CD) are less common (and declining over time) than streaming and file-based content. By comparison, Media Player (66% of Windows users in July) and IE (88%) are popular rendering engines for all types of media content, including an increased volume of "premium" and streaming content. This is another place we’re reminded of the tremendous diversity of Windows activity.
Those were a few of the major topics raised in comments in our first posts. Just as we did for Engineering Windows 7, we took a step back to calibrate our dialogue and reflect on the conversation. It is hard for us to find negatives in the feedback and passion around what we’re doing—what could possibly be better than to work on something that so many people care so deeply about. That you are investing so much in what we write and create, even before you have a chance to use the software, is certainly humbling. We’re focused on BUILD and making sure we do a great job showing off the work we’ve done, and are definitely excited to continue the dialogue. I look forward to those conversations in person at BUILD and here on the blog as well.
--Steven
More...