Windows 8 Ribbon
Last Updated on Friday, 2 September 2011 01:30 Written by Mire_B Friday, 2 September 2011 01:30
Like it or not, Ribbon is here to stay. Well, not here per se just yet, but I suspect this will change as of BUILD.
I have heard extremely visceral negative feedback from some of my friends of the new ribbonized Windows Explorer. They watched Microsoft’s Windows 8 Explorer video, and they didn’t like it. Simple as that.
In hindsight, I think it was a mistake for Microsoft to let people see the Ribbon UI of Windows 8 Explorer, but not let actually touch it, use it, get a hands on experience, form an opinion themselves.
This way, the Windows 8 Explorer Ribbon UI has already started on the wrong foot. Here’s Steve with some extra explanations on Ribbon:
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.
Windows 8 Explorer Ribbonized User Interface (UI)
Last Updated on Monday, 29 August 2011 10:02 Written by Mire_B Monday, 29 August 2011 10:02
Don’t really know about you, but I’ma big fan of the Office 2010 UI, the Ribbon UI – when it doesn’t get in the way that it. There are also times when I feel like smashing my keyboard against the screen, but very few and far apart. So when I saw the first screenshots from leaked copies of Windows 8 with the new user interface of Windows Explorer, I was intrigued to say the least.
Microsoft just demoed the new Ribbonized UI of Windows 8 Explorer in a new post on the Building Windows 8 blog, and I must confess that I love how easy it is to Copy as Path and Launch cmd with Admin privileges.
Windows Explorer is a foundation of the user experience of the Windows desktop and has undergone several design changes over the years, but has not seen a substantial change in quite some time. Windows 8 is about reimagining Windows, so we took on the challenge to improve the most widely used desktop tool (except maybe for Solitaire) in Windows. Alex Simons on the program management team authored this post with a detailed look at the evolution of Explorer and the major improvements to its interface and functionality for Windows 8. Judging by the passion on file operations and user interface design, we know this is an important subject so we expect a pretty engaged dialog on the topic. We put this in one lengthy post, will watch the comments and dialog, and down the road we’ll continue the discussion.
It’s exciting to have this opportunity to share the improvements we’re making to the file management capabilities of Windows Explorer. Explorer is one of the most venerable parts of Windows with a heritage you can trace back to the “MS-DOS Executive” in Windows 1.0!
Over the years, Explorer and its forerunners have gone through several major iterations:
It’s a bit daunting but also pretty exciting to have the opportunity to revisit and rethink this cornerstone of our product. Many of you who are reading this (and most of us on the development team) are among the most extreme “power users” of the file management tools in Explorer and likely start from a different perspective than the broad base of customers. As we approach the work to improve file management in Windows, we do so knowing many of you have long ago “given up” on Explorer and are using some of the wide variety of add-ons or alternatives.
As we mentioned in our post on improvements in the copy function, telemetry data indicates these add-ons and alternatives are mostly used by us power-users and we represent a small but influential group of people. The most popular add-ons and replacements (programs like TeraCopy, FastCopy, xplorer2 & QTTabBar) are installed (note that does not mean used) on about 0.45% of PC’s. Our goal is to improve the usage experience for a majority of customers while recognizing that, with such a long history and variety of depth usage, we cannot possibly provide all of the power everyone might want. We expect that there will be a vibrant third-party toolset for some time to come. Windows 8 is an opportunity to substantially improve the experience for everyone.
How Explorer is used today
Over the years, Explorer has grown to support a number of different scenarios, many unrelated to file management – launching programs, viewing photos, playing videos, and playing music, to name just a few. We wanted to know which of these capabilities customers were really using. Using telemetry data, we were able to answer the question of how the broadest set of customers use Explorer in aggregate. As a reminder, the telemetry data is opt-in, anonymous, and private, but it does represent hundreds of millions of sessions from all customer types.
This data is pretty interesting. First it shows that even though there are over 200 commands in Explorer, customers use a small number of them with any real frequency: the top 10 commands represent 81.8% of total usage. Additionally it shows us that people overwhelmingly use Explorer for core file management tasks – the top 7 commands (72.2% of usage) are all for managing/manipulating files.
This data represents the total usage of Explorer and includes cases where a person has a third-party add-on installed that uses one of our built-in commands (i.e. “play,” “open,” “edit,” “email,” etc.) A good example would be that a customer might have a third-party music app installed, which is the default player for all their music formats. The command usage of this third-party add-in from within Explorer is included in the data above. There are a class of add-ons that add their own custom commands (i.e. “rotate”) and we don’t get telemetry data for those, though we do know how often they are installed and get invoked (<2% of user sessions). This data is pretty solid and given the hundreds of millions of data points, it gives us a very clear picture of average usage across the population as a whole, and also of the spectrum of usage patterns (depth and breadth, frequency, etc.).
We also wanted to know how people most frequently invoke commands in Explorer.
The telemetry data here shows that 54.5% of commands are invoked using a right-click context menu, and another 32.2% are invoked using keyboard shortcuts (“Hotkey” above) while only 10.9% come from the Command bar, the most visible UI element in Explorer in Windows 7 and Vista. With greater than 85% of command usage being invoked using a method other than the primary UI, there was clearly an opportunity to improve the Explorer user experience to make it more effective—more visible and uniformly accessible. While context menus are convenient, the features in them can be overlooked if you don’t condition yourself to “search” via a context menu for the feature (a well-known challenge with the mechanism).
We also did an analysis of which of the commands that customers used were available in the Command bar:
Only 2 of the top 10 commands customers invoke in Explorer are available in the Command bar, the main UI element for invoking commands. This further reinforced our thinking that there was a big opportunity here to improve Explorer by making common commands more readily available. A clear user interface design principle is that frequently used commands should be easy to get to—clearly we had not yet accomplished that with existing designs.
Next, we turned to customers and community feedback. Customers have a lot of suggestions for how they’d like to see Explorer evolve. Many of these suggestions are for things that after-market add-ons like TeraCopy, QTTabBar, DMEXBar, & StExBar, or Explorer replacements like xplorer2, XYplorer or FreeCommander already offer.
The biggest category of feedback was requests to bring back features from Windows XP that were removed in Windows Vista, especially things like bringing back the “Up” button from Windows XP, adding cut, copy, & paste back into the top-level UI, and for providing a more customizable command surface. Also frequently requested is the need for more keyboard shortcuts. As you’ll read below, we’ve addressed many of these top requests in the redesigned Explorer. Each of these “removed” commands has a long history rooted in the changes to the Windows architecture and/or design philosophy.
Goals of the new Windows Explorer
We set out to accomplish three main goals with this new version of Explorer.
Optimize Explorer for file management tasks. Return Explorer to its roots as an efficient file manager and expose some hidden gems, those file management commands already in Explorer that many customers might not even know exist.
Create a streamlined command experience. Put the most used commands in the most prominent parts of the UI so they are easy to find, in places that make sense and are reliable. Organize the commands in predictable places and logical groupings according to context, and present relevant information right where you need it.
Respect Explorer’s heritage. Maintain the power and richness of Explorer and bring back the most relevant and requested features from the Windows XP era when the current architecture and security model of Windows permits.
We evaluated several different UI command affordances including expanded versions of the Vista/Windows 7 command bar, Windows 95/Windows XP style toolbars and menus, several entirely new UI approaches, and the Office style ribbon. Of these, the ribbon approach offered benefits in line with our goals:
Provides the ability to put the most important commands in very prominent, front and center locations.
Makes it easy to find commands predictably and reliably. Every important file management command could be given a home in the ribbon, and customers would always know where to look for them.
Exposes a large set of commands (~200) in one easy and consistent experience and organizes commands into scenario-focused groups without the use of nested menus, popups, dialogs, and right-click menus.
Aids command identification with support for grouping, a variety of button sizes and icons, and aids deeper investigation with live previews and expanded tooltips.
Takes a similar approach to Office, Microsoft Paint, and Windows Live Essentials, which means that many of our customers will be familiar with the model and not have a lot to learn.
Provides a consistent, reliable UI that doesn’t degrade over time like traditional toolbar and menu-based user interfaces do. See Jensen’s earlier blog on this topic from the development of the ribbon.
These strengths fit well with our three goals – the ribbon would allow us to create an optimized file manager where commands would have reliable, logical locations in a streamlined experience. The flexibility of the ribbon with many icon options, tabs, flexible layout and groupings also ensured that we could respect Explorer’s heritage. We could present a rich set of commands without removing access to previously top-level commands, something we knew was really important to our customers. As it so happens, while not primarily a touch interface, the ribbon also provides a much more reliable and usable touch-only interface than pull-down menus and context menus (we’ll have lots more to say on the topic of touch, of course—as a reminder, check out this Windows 8 video–we definitely know there is a lot of interest but also want to make clear that we know how important keyboard and mouse scenarios are to power-user scenarios of file management).
We knew that using a ribbon for Explorer would likely be met with skepticism by a set of power-users (like me), but there are clear benefits in ways that the ribbon:
- Exposes hidden features that they already use but which require third party add-ons to use in the Explorer UI today.
- Provides keyboard shortcuts for every command in the ribbon, something many people have been asking for.
- Provides UI customization with the quick access toolbar, taking us back to a customization level that is basically equivalent to Windows XP.
We also knew that, similar to when we added the ribbon into Office, there would be concerns about reduced screen real estate. We worked hard to mitigate this issue, and I’ll tell you what we did here a little later in this blog post.
Finally, there are quite a few third-party add-ons that some of our more advanced customers use with Explorer today. These add-ons will continue to work in the right-click context menus in Windows 8, which is by far the most common access point for experienced customers running these add-ins (where discovery and occasional usage are not the primary design points). However, add-ins will not be able to plug into the ribbon UI. This was a difficult engineering choice for us and we expect that many of you will read this and suggest we add the capability–of course if we could get it right this time around we would have done that. A big part of this blog is sharing these choices–tradeoffs–between new features and adding everything we can dream up and finishing. We also think the customization we provide and the improvements are worthwhile this time around.
In a related note, one of the most common requests we get in any redesign is to continue to provide the old user interface along with the new. Sometimes this is suggested as a “transitional” benefit, and other times as a “compatibility mode.” We’ve learned over many product cycles that the work to provide this significantly impacts the evolution of the product. The most immediate challenge is that any new commands added to the ribbon then need to be added in the old UI, even if there is no logical place for them. And of course as the new UI evolves, backward compatibility proves doubly challenging. Each time we change we double the number of “old” experiences we carry forward. Our hope is that those who maintain software understand that these are tradeoffs we make in a thoughtful and deliberate manner, and are not meant to be forceful or painful in any way. We are fully aware of the responsibility that comes from changing an interface used by so many people.
A ribbon gave us a lot of layout options and we explored a number of different approaches to tabs and grouping. We decided to go with three main tabs: Home, Share, and View, plus a File menu and a variety of contextual tabs.
The new ribbon
The Home tab is focused on the core file management tasks, and we’ve put all the major file management commands there in prominent locations: Copy, Paste, Delete, Rename, Cut, and Properties. We’ve also given new prominence to two popular heritage features, Move to and Copy to, along with exposing a hidden gem, Copy path, which is really useful when you need to paste a file path into a file dialog, or when you want to email someone a link to a file on a server.
The Home tab is the heart of our new, much more streamlined Explorer experience. The commands that make up 84% of what customers do in Explorer are now all available on this one tab:
The Share tab is for sharing files by typical methods like zipping them up and emailing them to a friend, or burning them to optical media. Or you can quickly share files with other people in your home group or your network domain. It also provides one-click access to the ACLs for the currently highlighted file.
The View tab provides access to options for view customization. We’ve enabled one-click access for turning on/off the Navigation pane, Preview pane, and Details pane, a live preview gallery for the different icon display sizes, quick access to sorting and grouping by column, the ability to quickly add columns, plus easy access to three hidden features: show file name extensions, show hidden items, and hide selected items.
The customization options for the Navigation pane are also much easier to access – in the drop-down menu, you get one-click access to them, including a new option to show or hide favorites.
The file menu and other tools
The file menu lets you quickly open new Explorer windows, access your shortcuts, and change folder and search options. It also includes a hidden feature that we love, Open command prompt, and a really useful new command, Open command prompt as administrator, both of which launch a command prompt with the path set to the currently selected folder.
We’ve provided a variety of contextual tabs that activate in the context of specific files and folders, and for tasks like searching, managing libraries, viewing pictures, and playing music. One of the best examples is the new Search Tools contextual tab which launches when you click in the search box.
The Search tab surfaces a bunch of hidden gems that most people are not aware of, but that could solve some common problems for them. You can quickly adjust the scope of any search, filter by common date ranges, file type, file size, and other properties like the author or name. Then you can save these searches for future use.
Here are examples of some of the other Explorer context tabs:
- January 2014
- October 2013
- August 2013
- July 2013
- June 2013
- May 2013
- April 2013
- March 2013
- February 2013
- January 2013
- November 2012
- October 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- October 2010
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009