One of our readers recently sent us a message complaining about the recent trend of “horrible menuless windows,” which he compared with cars where all dashboard functions were hidden in the glove-box compartment. His annoyance had been triggered by the new desktop version of Firefox that “copies the Chrome browser” and hides the menu options under a hamburger icon.

The hamburger menu is just one incarnation of the current trend to downplay the chrome (UI elements such as buttons, menus, and other widgets) on the desktop. Our recent analysis of homepages noted that chrome and navigation tend to get a smaller share of the homepage nowadays compared with 12 years ago.

Behind this antichrome movement stands the mobile-inspired assumption that we should prioritize content over chrome. Of course, users go to a website to engage with the content and not to admire the clever UI, so content is ultimately the king. So, if that’s the case, is hiding the chrome bad?

Cost of Hiding the Chrome

Truth is that chrome supports how users engage with that content and determines whether a site is useful or not. Hiding the chrome incurs a substantial cost for the users:

Users must discover the chrome. Whether that chrome is hidden under a generic menu button, or under a gesture (as in Windows 8 for touchscreens), people must think to look under that button or perform the gesture in order to uncover the chrome. Even after they’ve discovered the chrome, users must recall how to access it later during the same session. Exposing the navigation options favors recognition over recall, and thus follows one of the 10 usability heuristics. In our Windows 8 testing we often saw users discovering how to access the chrome, and then forgetting all about it later on. Out of sight is truly out of mind. Even if they discover and remember how to access the chrome, users suffer an increased interaction cost to access the functionality provided by the chrome. For a hamburger menu, they must first click the menu icon, and then select the option that they need, instead of just clicking on a navigation choice right away. Of course, you may say — what’s one extra click? Most of the time it’s not much in itself, but it can quickly become annoying if users must repeatedly access those hidden options.

Content-to-Chrome Ratio and Screen Size

Too much chrome is bad, but too little chrome is bad too. What we need to maximize is not the amount of content on a screen; instead, we need to maximize the content-to-chrome ratio. And that ratio is modulated by the screen size. On a tiny screen, a navigation bar with 8 items easily consumes more than half the available screen space; it can displace content and make users scroll to get a sense of what the page is about. The content-to-chrome ratio is too small, so it makes sense to try to increase it by hiding some of the functionality under a menu button. (Even on small screens, hiding the navigation under a hamburger menu is not ideal: out of sight is out of mind and people do take a little more to discover it. Our studies with gesture-based interfaces also show that invisible chrome is hard to access. But on tiny screens such as those of smartwatches, gestures are pretty much the only way to go. On-screen buttons simply consume too much real estate and can make the content-to-chrome ratio unacceptably small.)

On a much larger desktop monitor, an 8-item navigation bar will minimally impact the content-to-chrome ratio. Yes, the ratio would be slightly better if the navigation is hidden, but not better enough to justify the cost of hiding the chrome. Plus, a tiny icon is easier to overlook on a large screen than on a small one.

Ultimately, if the capacity of the communication channel between the person and the device is small, we need to compress information to send as much value as we can in as few pixels. Since the value is delivered mostly by the content, it makes sense to minimize the chrome. But that argument does not stand for larger screens.

Desktop Design Patterns that Minimize the Chrome, but Don’t Affect the Content-to-Chrome Ratio

Several of our recent articles focus on mobile-initiated design trends that misguidedly try to improve the content-to-chrome ratio on desktop. In the process, they minimally alter the content-to-chrome ratio, but they sacrifice usability.

Hamburger menu for navigation The popularity of the hamburger icon on the desktop was inspired by its ubiquity on mobile and by the proliferation of responsive websites that attempt a single design across all devices. Unfortunately, the small size of the hamburger menu (relative to the large desktop screen) makes it hard to discover. The hamburger menu is more discoverable on mobile. Still, even on mobile, many users don’t access the functionality inside the menu, or simply forget to check it. Magnifying-glass icon instead of search box Eliminating the search box and replacing it with a magnifying-glass icon has become almost standard on mobile. It doesn’t work as well on the desktop: the space is simply too large and users don’t have the patience to hunt for a small search icon. If you consider using it on the desktop, keep in mind that the space saved most of the time does not justify the loss of discoverability of the search tool. Icons (or thumbnails) with no labels You may think that icons or pictures provide a more immersive experience and save screen space, but in fact most are a lot more ambiguous than words. When icons or pictures are used for navigation by themselves, with no accompanying text, the space saved does not justify the loss of information scent.

Conclusion

Desktop and mobile screen sizes have different constraints and therefore different usability rules. Trade-offs that designers are forced to make on mobile don’t generalize well to the desktop (and vice versa). Before jumping on the chromeless bandwagon, think twice. Ask yourself: does a reduced-chrome interface substantially improve the content-to-chrome ratio? If the answer is no, then make the chrome visible. And remember: for the same design, the answer may be different on different devices.

Learn more about design differences between devices in our class on Scaling User Interfaces.