Follow-up: Starting, Launching, and Switching
Lots of discussion on the taskbar and associated user interface. Chaitanya said he thought it would be a good idea to summarize some of the feedback and thoughts. --Steven
We’d like to follow up on some themes raised in comments and email. This post looks at some observations on consistent feedback expressed (though not universal) and also provides some more engineering / design context for some of the challenges expressed.
First it is worth just reinforcing a few points that came up that were consistently expressed:
- Many of you agree that the Notification Area needs to be more manageable and customizable.
- We received several comments about rearranging taskbar buttons. This speaks to the need for a predictable place where taskbar buttons appear as well as your desire for more control over the taskbar.
- There were comments that talked about Quick Launch being valuable, but that it could stand to be an even better launching surface (e.g. larger by default or more room).
- Thumbnails are valuable to many of you, but their size doesn’t always help you find the window you are looking for. There is interest in a better identification method of windows that consistently provided the right amount of information.
- Better scaling of supported windows was discussed. This includes optimizing the taskbar for more windows and spanning multiple displays.
Several of you asked about the conclusions we are drawing from the data we collect and how we will proceed.
@Computermensch writes “The problem with this "analysis" (show me the data) is that you're only managing current activities surrounding the taskbar. So with respect "to evolving the taskbar" you're only developing it within its current operational framework while developing or evolution of really should refer to developing the taskbars concept.”
@Bluvg posts “What if the UI itself was a reason that people didn't run more than 6-9 windows? In other words, what if the UI has a window number upper bound of effectiveness? Prioritizing around that 6-9 scenario would be taking away the wrong conclusion from the data, if that were the case. The UI itself would be dictating the data, rather than being driven by user demand.”
As we’ve said in all our posts around the data we collect and how we use it, data do not translate directly into our features, but informs the decisions. Information we collect from instrumentation as well as from customer interviews merely provides us with real-world accuracy of how a product is currently used. The goal is not necessarily to just design for the status quo. However, we must recognize that if a new design emerges that does not satisfy the goals and behavior of our customers today, we risk resistance. This is not to say one should never innovate and change the game—just that to do so must be respectful of the ultimate goal of the customer. Offering a new solution to a problem is great; just make sure you’re solving the right problem and that there is a path from where people are today to where you think the better solution resides. With that said, rest assured that our design process recognizes the need for the taskbar to scale more efficiently for larger sets of windows. This would allow those who possibly feel “trapped” in the 6-9 window case to more comfortably venture to additional windows, if they really require it. Also, the improvements we make to the 90% case should still hold benefits to the current outliers.
With so much feedback, it is always valuable to recognize when customer comments converge. The original post called out the problems with the Notification Area and these issues were further emphasized with your thoughts.
@Jalf writes “Having 20 icons and a balloon notification every 30th second taking up space at the taskbar where it's *always* taking up space is just not cool. By all means, the information should be there if I need it, but can't we just assume that if I don't actively look for the information, it's probably because I don't want it.
Jalf’s comment is particularly interesting because it speaks to both the pros and cons of notifications. They certainly can be valuable, but they can also very easily overwhelm the customer as many of you note. A careful balance therefore must be reached such that the customer is kept informed of information that is relevant while she continues to remain in control. Since relevant is relative, the need for control is fundamental. Rest assured we are aware of the issues and we are taking them very seriously.
It comes as no surprise that many of you wrote to discuss multi-monitor support for the taskbar. This is a popular request from our enthusiasts (and our own developers) and was called out as an area of investigation in the original post.
@Justausr is very direct with this comment: “The lack of multi-monitor support is just about a crime. We've seen pictures of Bill Gate's office and his use of 3 monitors. Most developers have 2 monitors these days. Why was multi-monitor support for the taskbar missing? Once again, this is an example of the compartmentalization of the Windows team and the lack of a user orientation in defining and implementing features. The fact that this is even a "possible" and not an "of course we're going to..." shows that you folks STILL don't get it.”
At least in this particular case we tend to think we “get it”, but we also tend to think that the design of a multi-mon taskbar is not as simple as it may seem. As with many features, there is more than one way to implement this one. For example, some might suggest a unique taskbar that exists on each display and others suggest a taskbar that spans multiple displays. Let’s look at both of these approaches. While doing so also keep in mind the complexities of having monitors of different sizes, orientations, and alignments.
If one was to implement a taskbar for each display where each bar only contained windows for its respective portion of the desktop, some issues arise. Some customers will cite advantages of less mouse travel since there is always a bar at the bottom on their screen. However, such a design would now put the onus on the customer to track where windows are. Imagine looking for a browser window and instead of going to a single place, you now had to look across multiple taskbars to find the item you want. Worse yet, when you move a window from one display to another, you would have to know to look in a new place to find it. This might seem at odds with the request to rearrange taskbar buttons because customers want muscle memory of their buttons. It would be like having two remotes with dynamically different functionality for your TV. This is one of the reasons that almost every virtual desktop implementation keeps a consistent taskbar despite the desktop you are working on.
Another popular approach is a taskbar that spans multiple desktops. There are a few third-party tools that attempt to emulate this functionality for the Windows taskbar. The most obvious advantage of this approach (as well as the dual taskbar) is that there is more room offered for launching, switching and whispering. It is fairly obvious that those customers with multiple displays have more room to have more windows open simultaneously and hence, require even more room on their taskbar. Some of our advanced customers address this issue by increasing the height of the taskbar to reveal multiple rows. Others ask for a spanning taskbar. The key thing to recognize is that the problem is not necessarily that the taskbar doesn’t span, but that more room is required to show more information about windows. So, it stands to reason that we should come up with the best solution to this problem, independent of how many displays the customer has.
We thought it would be good to just offer a brief discussion on the specifics of solving this design problem as it is one we have spent considerable time on. One of the approaches in general we are working to do more of, is to change things when we know it will be a substantial improvement and not also introduce complexities that outweigh the benefits we are trying to achieve.
Once again, many thanks for your comments. We look forward to talking soon.