Designing the Windows 8 file name collision experience
Thank you so much for all the comments about our work to improve file management basics. We’ve been overwhelmed by the dialog—there’s a huge amount of excitement for the changes we’re making and a ton of energy around this topic. That’s what makes working on Windows 8 so much fun. While there were comments and suggestions around many parts of what we talked about, by far the most back and forth (expressing all sides of the issue for sure) came from the discussion of the file name collision dialog (one dialog!). We thought it would be great to dig up the design archives from the development cycle and show you some of what we considered and how we got to where we are. Down the road we will of course circle back and talk about any changes we might make, but we thought spending some energy looking at our design path would be a useful effort. This post was authored by a set of folks who worked on the feature (they all worked on other parts of Windows 8 as well)-- Ben Truelove (designer), Matt Duignan (UX researcher), Jon Class and Ilana Smith (program managers) . --Steven
Our previous post about the new copy experience in Windows 8 generated a lot of questions and comments about the new “Choose Files” dialog for resolving file name collisions. Based on the level of interest, we thought it would be fun to share some of the design iterations and our usability testing that led us to this design.
In the implemented design, there are two levels of control when acting on file name collisions (or “conflicts”).
- The primary experience is a simplified, one-click, bulk management of all conflicts, offering “Replace all” or “Skip all.” We call this the “Simple Conflict Resolution dialog.”
- There is also an option to enter the secondary experience which offers more information and more fine-grained control. This is the “Detailed Conflict Resolution dialog.”
Windows 7 and before
Resolving file name collisions is an inherently tricky task, as it involves making a meaningful choice between two very similar things.
Here’s how we did this back in Windows 3.1:
We’d certainly made some progress by the time we got to this in Windows 7:
In Windows 7, there’s a lot of information to aid the choice, and more options about what action to take. For Windows 8, we thought we could improve this even further, so it’s easier for you to make the right decisions more efficiently, and get your file transfer tasks completed faster. As we mentioned, the feedback and support calls on the existing dialog were clear—folks were having a hard time finding the information needed to make an informed choice in a fairly complex dialog. Even with the amount of work we do, sometimes it takes quite a while to surface something that isn’t optimal. Keep in mind millions of people used pre-release Windows 7 and this was not a big topic of discussion on our forums (not to say that it didn’t come up, but it was not a broadly raised topic).
Improving on the Windows 7 experience
First, we looked at ways to keep the experience basically the same, but to incrementally improve it by optimizing for the key information that is necessary for the decision.
These designs introduced some concepts that really stuck around:
- Getting rid of unnecessary labels (like “Date modified:”) and obvious explanatory text enabled us to present the important details at a glance.
- Metadata adjectives were emphasized. Rather than requiring users to compare values like file size, using words like “Larger” gave users the right summary.
- Smart defaults were pre-selected, reducing the work for users.
Fast and fluid: better bulk management of conflicts
In Windows 8, we want you to be able to get stuff done more quickly and efficiently—"fast and fluid" are key design words around Windows 8 for all of our designs (for touch, mouse/keyboard or both together). The next major design iteration looked at ways that we could follow on from the cohesive copy progress experience, bring queued-up conflicts together into a single dialog, and provide you with the ability to manage them in a more streamlined way.
The idea of optimizing for the “Replace all” or “Skip all” choice was introduced. Most of the time, you know exactly what you’re copying and why it is conflicting, and you can make a simple choice about what action to take.
For cases where you need more information or finer-grained control, we decided to disclose information in “tiers” of greater detail.
We started with two tiers:
Then we tried three-tiers:
And ended up back at one-tier:
This design offers many positive attributes. It provides a lot of information. Since clicking on the headers selects everything in a column, it provides real power for managing conflicts. But it was a very complex piece of UI to be presenting as the initial experience.
Instead, we combined the best of these options into the following:
Simple and detailed conflict resolution
It was clear that this design was heading toward a balanced combination of simplicity and power that would suit user patterns.
Unfortunately, we identified a real challenge with this design: when you select “Let me pick,” the result is confusing and overly complex because the simpler and advanced options are both available. This led us to a design where the “Simple Conflict Resolution dialog” and the “Detailed Conflict Resolution dialog” were discrete experiences.
With this decision, our basic structure was in place.
In preparation for testing with users, we iterated on the design.
- We cleared up the confusion caused by a single thumbnail.
- We made the source and destination (and their columns) more apparent.
- Our User Assistance team (the experts in authoring text we use in the product, assistance, and the web) helped us out with better text.
It’s interesting to see the similarities between the Simple Conflict Resolution dialog and some of the earliest designs for dealing with single file conflicts. It’s also interesting how similar they both are to the final design for the dialog.
First round of usability research
In our usability tests our researchers find a diverse set of subjects who don’t work at Microsoft and represent a range of different skill levels and experiences. We show them the software and ask them to complete a set of tasks. By listening as they describe their thought process, using eye-tracking to watch how they see the UI and measuring successful task completion, we gain valuable insights into what works (or not) about a design.
It is super important to understand that usability tests are one tool we use. Anyone who has ever used this tool knows that you have to be both an expert in the domain and also an expert at designing tests themselves as observer bias and test construction can easily lead you to a false sense of security or efforts to optimize an inherently flawed solution. To help us in that regard, our tests are designed by objective researchers who understand the limits of what can be tested and also make sure that the conclusions drawn from the test match what the test was meant to measure. Ultimately, design choices require the use of many different inputs both qualitative and quantitative as well as experience and intuition.
We knew that we’d learn a lot in our first round of usability tests and make many changes, so we used the RITE method as our protocol. Most usability studies test the same UI with all users, but with RITE, we make changes continuously between participants, based on what we learn. (We were testing with PowerPoint slides at this point, so change was cheap.)
We didn’t end up needing to make many changes to the Simple Conflict Resolution dialog as it tested well, but we tested lots of different things for the Detailed Conflict Resolution dialog:
Our key lessons:
- Check boxes are necessary. As much as we preferred the cleaner no-checkbox look, it simply didn’t test well. Users didn’t know what to do when presented with the UI. Check boxes were much more effective in providing appropriate cues for selection. We made sure to retain a large click-target area, so users can click on the check box, thumbnail, or the text to select a file.
Click target area for file selection
- Mixing the adjectives (e.g. “newer,” “larger”) and the metadata was confusing. Users interpreted them as two different concepts. The adjectives were particularly problematic – people thought they were titles, or described the file location (for example, “older” was interpreted to mean the files in the destination because they were present prior to the copy.)
- Columns needed to be more distinct. At first glance, it looked like the Tiles view in Explorer, rather than a table.
There was no simple solution to the adjective and column issues, so that led to more design explorations:
We really struggled with how best to define the hierarchy and importance of source/destination versus conflict rows. We tried vertical lines, which separated the source and destination too much. We ultimately landed on horizontal lines, combined with the file name as a header, to give the most prominence to the distinction between conflicts. The check boxes aided in distinguishing a choice between source and destination without interfering with this distinction.
Some of our earliest ideas were discarded at this point in the process:
- No default choices. With conflicts scrolling off the page, defaults posed too much of a risk of data loss. No selection in a row results in the copy of that file being skipped, so nothing is lost.
- No adjectives. We liked “Newer” and “Larger,” but they added confusion and users valued the concrete data.
Instead, to help users make the choice, we chose a more subtle suggestion – the newer and larger metadata values are bold in the UI. This has proven to be surprisingly effective, without introducing new concepts or adding clutter.
More usability research
In our next round of usability tests, we were heading toward the final design, and tested fewer alternatives:
The third option was the clear winner. The two-column view is the most efficient use of space and moves the check boxes close to the question. Date and time need to be on the same line because these are primarily a single value.
The Detailed Conflict Resolution dialog also offers the following features to help when even more information is required to make the decision:
- Double-clicking the thumbnail opens the file.
- Right-clicking the thumbnail opens the standard context menu.
- The blue Source and Destination text are clickable, and open those locations in Explorer.
- Hovering on the thumbnail or link shows a tooltip with the full file path.
Continuing to iterate
We’ve continued to conduct more studies and make minor changes since the initial research, but the core design has remained basically the same. It has been very encouraging to witness the ease with which users complete usability tasks. Resolving file name collisions is a tricky problem, but users are efficient and successful.
Check out the video in our previous post on file management basics to see this design in action.
We love feedback and want to use it to make the best design we can, so we’ve been carefully reading all your comments, and look forward to you working with it in practice.
-- Ben Truelove, Matt Duignan, Jon Class, and Ilana Smith