Why is low contrast between active and inactive window title bars considered a good thing?

Question

It seems like recently, there is a movement toward applications forcing a color scheme on the user as well as using custom-drawn windowing elements, particularly title bars, with very low contrast between active and inactive windows. In my opinion, this makes it difficult to tell which window currently has input focus.

This is the case both with "regular user" software as well as some high-end, specialized software. On the end-user side, consider the color theme of Office 2010 title bars (completely ignoring the fact that I have configured the system for "classic" look with the there-default quite large contrast between active and inactive title bar background); on the high-end side, consider something like Visual Studio 2013, which also appears to ignore the Windows settings and draw its own title bar however it pleases itself.

A major advantage of a central configuration for things like user interface color selection is that all applications can take advantage of them without needing to go out of their way. Yet quite a few applications these days seem to deliberately go out of their way to override user preferences in the matter, and often inconsistently between applications too. Why is this considered desirable? In what way does it provide an advantage for the end user's experience, or, put differently, how did it ever get back up to 0 points?

For example, consider a fairly stock installation of Visual Studio 2013 with the "Light" color theme selected:

or a stock installation of Word 2010 as packaged in Office Professional Plus 2010:

Quick now, if these two windows were next to each other, possibly even separated somewhat, rather than overlapping (which I did mostly to reduce the image size of the screenshots), which window has input focus? Now imagine I'm running a dual-screen or even triple-screen setup (which isn't all that uncommon; I have a dual-screen setup at work, and have pondered moving in that direction at home), with the windows on different physical monitors. Which one has input focus?

Now, compare to how I have Windows set up (this is from the same machine as the Word screenshot above; the Visual Studio one is from a different system with slightly different settings):

In the last one, admittedly I'd need to know that dark blue means active, but with good color vision (selecting different colors can help, otherwise) there can't really be any mistake about which window has input focus. To me, that provides much more clear feedback about where something I type will end up, which improves UX at very little (more like zero) cost. Applications going out of their way to draw their title bars in their own way has a direct cost in programmer time and software complexity, yet it appears to be done more and more.

Answer 1

Application designs that don't differentiate between active and inactive windows are violating the principles that:

1. Recognition is more valuable than recall.
2. A system should inform the user about its state.
3. The system should help prevent errors.

These are all Nielson classics. Showing the user what window is in focus prevents users from "typing into nothing" or interacting with the wrong window. Users shouldn't have to remember which one is in focus, especially when the windows are not overlapping, like in your dual/triple monitor example.

And lastly, it's just plain good form to indicate to the user where their interactions are taking place on screen—i.e., blinking text cursors, title bar color changes, mouseover effects, onclick effects, menu highlighting. All of these features let the user know they are actually having an effect on the system and that the system is responding to their input correctly.

I've noticed this trend as well, and it seems to occur when the application tries to replace the default system title bars, which typically have the active/inactive functionality built in. Why is this considered desirable by some people? It looks like a classic case of artistic design over good UX. Whenever these two disciplines don't interact well, it's ugly for users, functionally and aesthetically.

Answer 2

Microsoft gave some explanation for these changes to Visual Studio in this article:

Visual Studio 11 User Interface Updates Coming in RC (May 2012)

(emphasis mine)

Another area of requested change relating to user interface controls/chrome has been for us to improve the overall sense of Metro styling within the themes by drawing our own window chrome. By drawing our own window chrome we have succeeded in both making more efficient use of space and in increasing the overall sense of Metro styling.

the article continues...

The custom chrome and line work changes we’ve made together with reducing the number of default toolbars and toolbar icons combine to give you three extra visible lines of code in the editor compared to Visual Studio 10. As I noted at the beginning of the post the overall objective behind many of the Visual Studio 11 theme changes is to give you maximum real-estate for, and ability to focus on, your code.

It looks like Microsoft designed a custom title bar in Visual Studio 2012 to:

1. Move the "Quick Launch" search bar all the way up to the top of the window, so that users could hide all toolbars and see a few extra lines of code.

2. Make a more consistent metro theme.

3. Increase focus on "content" (i.e., code)

Based on the article it seems like the custom, low contrast title bars were Microsoft's attempt to "get you to focus more on your code" rather than looking at the window chrome.

---

Issues with Microsoft's article:

• If you hide all the toolbars, Visual Studio 2010 and 2013/2015 are very similar in the amount of vertical space you have for your code.

In the newer versions of visual studio, Microsoft made the tabs smaller, but they increased the size of the logo in the upper left, the notification button / indicator is also larger than a standard title bar button in Windows Classic.

For Classic Themes: Visual Studio 2013 and 2015 actually have one less pixel of vertical space than Visual Studio 2010.

(click on the image to enlarge it)

For Aero Themes: Visual Studio 2013 and 2015 give you four additional pixels of vertical space. (Default font, the pink line is the top of the i in #include ... in Visual Studio 2010)

(click on the image to enlarge it)

This comparison was done on Windows 7.

In Windows 10 / Visual Studio 2017:

• Compared to Visual Studio 2010 with Windows 7 Aero, you gain an additional 3 pixels of vertical space for your code.

• Compared to Visual Studio 2010 Windows 7 Classic you lose 5 pixels of vertical space.

So far no environment has more maximum possible space for code as Windows 7 Classic / Visual Studio 2010, though the difference is negligible (not even enough for a full line of code).

As for "Metro makes it easier to focus on content":

A) In an article talking about Office 2007 (see below), Microsoft specifically mentioned that "Replacing the Window chrome is a very visible way to differentiate your app and increase branding impact"; it seems like if anything replacing the window chrome would make it so that users are noticing the unique look of your application more than the content.

With custom chrome, the application no longer blends in with the rest of the user's system (and it will probably only look more foreign later on, because it doesn't "evolve" when the OS updates).

B) Microsoft made the exact same claim about Windows Aero years ago (Archived: Oct. 2009):

One of Aero’s more visually obvious features is glass window borders, which let you focus on the contents of your open windows. Window behavior has also been redesigned, with subtle animations accompanying the minimizing, maximizing, and repositioning of windows to appear more smooth and effortless.

---

Office 2007

Joe Castro (Microsoft) wrote an article on the usage of custom window chrome (archived 2019), he mentioned Office 2007.

See excerpt below, he was mostly focusing on the technical side of it in the article, however, he mentions that replacing the window chrome can give your application a distinctive look, though it will require more work to implement standard system features. He specifically mentions Active/Inactive states as something requiring extra work.

It seems that some employees at Microsoft recognized the importance of differentiating between an active and inactive window, though perhaps a more "subtle" difference between active and inactive was preferred in the long run.

Predicting the future is hard – or “How to make some people unhappy, all of the time”

Ultimately replacing the window chrome is doing the job of the window manager. Emulating Windows like this has potential to miss behaviors that your users expect, or not work correctly under some circumstances (like high-DPI, or under a screen reader). Care should be taken to ensure that the behaviors your users care about will work correctly with your replacement.

For example, some of the standard window caption features today are:

• Left-click on the icon to get the system menu.

• Double click on the system icon to close the app (Office’s pearl does this as well).

• Right click in the caption to get the system menu.

• Double-click the caption to maximize the app.

• With DWM, change the caption text style when maximized.

• Change colors based on Active/Inactive states (The colors it uses respect DWM colorization when Aero glass is on, the Theme colors when not in Windows Classic, and System colors when in Windows Classic.)

• It respects system metrics for sizes, and the metrics available for measurement have changed in different versions of Windows (e.g. iPaddedBorderWidth was added for Vista).

These are all things that the system no longer does automatically for you when you use your own chrome. And some of this behavior has changed in different versions of Windows.

Replacing the Window chrome is a very visible way to differentiate your app and increase branding impact, but it’s likely that an implementation will miss some things, or that future versions of Windows may change some behaviors making your app look out of place.

This doesn’t mean “don’t do this.” Just that replacing the chrome should be an informed decision.

Also, user feedback on Office 2013 has shown that low contrast in title bars is not just a hypothetical issue:

And another thing, now that I have to have all of these separate window open, how can I tell which one is selected? Previous Office products had a color change in the bar at the top of the window to show whether that window had the focus. Office 2013 doesn't seem to have any visible indication. I keep pasting things into the wrong windows.