It's been a couple of weeks since my last post, and after recovering from illness I thought the best way to get back into the blogging habit would be to answer another question from my All Points Bulletin Board. This question, like many of the early ones, revolves around demystifying terminology.
While still learning the lingo at the start of my dev career, when I heard "chrome" I immediately thought of the Google web browser. But the term existed in the programming lexicon long before Google came along in 1998, and it's a major principle in UX/UI design, frontend development, and the effort to understand and create usable applications.
Short Answer: Chrome is the collection of UI elements provided by an underlying system to show more information about, or perform actions on, the screen's content. Chrome obesity refers to a disproportionate amount of the screen space being obscured by overhead UI, leaving too little room for content and negatively impacting usability.
Coined sometime in the 1950's, the term "chrome" is likely a nod to the flashy chrome features found around the bodies of American cars during the era. In programming, chrome refers to the visual UI elements that live around the edges of the screen.
Chrome is a recognizable and accessible representation of power at the user's fingertips - the power to return to the previous page, to navigate to a new window or program, and achieve various tasks inside those programs.
When we stop to think about it, chrome is everywhere on the screen. There's chrome from the underlying OS, the web browser, and website or local applications. This means that chrome quickly accumulates, or stacks, and can consume a majority of screen space before we realize it.
When chrome takes up too much screen space it's referred to as chrome obesity, or chrome bloat, and it's a major concern in UX/UI design and development in general. Like human BMI, there's a range when it comes to chrome obesity - and there are clear danger zones in either direction. Too little chrome, or chrome that's abstracted away in layered hamburger and drop-down menus, is an equally serious concern.
Imagine opening an Excel spreadsheet to find a menu-less expanse of cells. Sure, we'd be able to see a lot of them at once - but often times we're only concerned with the information in a particular cell because we want to do something with it.
Without the chrome of the Microsoft Excel program, how would we quickly do things like change the font color, perform a mathematical operation, insert another cell, navigate between sheets and so on? Conveniently, these functions are bound to recognizable icons that exist on a snack bar at the top of the window. If they were instead hidden in drop down menus, we'd probably find the program frustrating to use as the interaction cost accrued.
On the other hand, some applications benefit lean and unique chrome, like a simple note and reminder app intended for a mobile device. We wouldn't want so much chrome that the point of the application - the user's notes and the data associated with them - were lost under layers of unnecessary functionality.
Designing unique and unexpected UI can be fun, and even groundbreaking, but at the end of the day users don't want to deal with a steep learning curve when using an app. The goal is for the experience to be intuitive, and require as little trial and error as possible.
The best chrome design is simple in function and execution. A great example of this is the 'back' button. It's all over the place - in pretty much every browser, OS, and mobile device. As users, we just expect it to be there - because it works. And it works the same in every application. The space it occupies is more than worth the simple, reliable functionality it provides.
Aim to create chrome that is recognizable at best and easily learned at worst. Visual icons are a common and useful a way to communicate an element's purpose regardless of the user's native language. If an action can't be summarized neatly by an icon, or is especially unique to the product, then the interaction cost - the amount of clicks or other purposeful interactions a user must make to complete a task - should be low, and easily remembered when the user returns.
Chrome empowers users to easily interact with the data on their screens. The "right" amount depends on the purpose of the application and the device it's intended for. Chrome should follow standards to allow users to learn less between applications, and focus more the real-world problems they arrived at the application or website to solve.
To get an idea of what works and what doesn't, pay attention to industry standards and the applications you use. What ones are especially easy to download and use right out-of-the-box? Why is that? What do highly usable applications have in common with each other? What are the trends, visual or otherwise? And what does all that show us about how users want to interact with their devices and data?
Maximize the Content-to-Chrome Ratio, Not the Amount of Content on Screen - Raluca Budiu, Nielsen Norman Group
Browser and GUI Chromes - Jakob Nielsen, Nielsen Norman Group