Scaling Up, Scaling Down
A question that has been asked a lot is: "How does the Ribbon scale down?"
Anytime you see the Ribbon demoed live, you'll see it at 1024x768 resolution. Why? Simply because that's the native resolution of most projectors. If you saw my presentation at PDC, you know that even 1024x768 can be fuzzy on a projector, depending on the length and quality of the cables and splitter involved.
As a result, we tend to put screenshots up in 1024x768 as well. It tends to be a nice resolution shrunk down to thumbnail size and, because it's the most common resolution people have today, it lets them envision what the UI would look like on their monitor.
The reality, of course, is that Office is used on everything from a squished-up narrow window on the left side of the screen to a maximized 2048x1600 200 DPI screen and everything in-between.
1024x768 is the most common resolution for people using Office 2003, however we're seeing constant growth of the 1280x1024 and beyond segment. We're almost to the point where half of the Office 2003 monitors are running resolutions higher than 1024x768, and I'm hopeful that in another two years 1280x1024 will be the majority. 800x600 usage continues to decrease every month (even worldwide), and we're currently seeing less than 15% of our Office 2003 customers using that resolution.
In the past, when designing user interfaces at Microsoft, we've always picked a target resolution (say, 1024x768) and then figured out how to make the UI scale down below that resolution. Usually, that scaling is achieved by means of "overflow" mechanisms, such as scroll bars.
As a result, certain UI components that were designed for 640x480 (such as the top-level menu structure) look comically small on a 1400x1050 laptop. No thought was put into how the UI could get richer if you had more space.
The Ribbon was designed to scale up and scale down. It has no "target" resolution per se, but instead sizes itself to fit. As you give it more space, it takes advantage of that space to label commands, give you more choices, and eliminate extra clicks. As you shrink it down, the Ribbon packs more information into less space and eventually goes away altogether.
Each "chunk" in the Ribbon can have multiple layouts. These layouts are different ways of communicating the same commands using variable amounts of space. The larger chunks attempt to label all commands and present bigger buttons for more important commands. The smaller chunks sometimes have no labels at all and require tooltips to see what commands do (similar to toolbars today.)
Chunks can also turn into "popup" chunks, in which the entire chunk turns into a singe button. When the button is clicked, a full-size version of the chunk contents pop down, like a menu. This is the most compact version of any chunk and it only used at small widths (because it adds extra clicks.)
(Click to view full picture)
Here's a movie I made so that you can download to see scaling in action. The tab pictured is not really a true example of any tab in the product--I've changed the scaling to illustrate the different kinds of scaling possibilities all in one tab.
(Click to view movie - Windows Media Format, 1.6 MB)
We've tried a lot of different kinds of scaling for the Ribbon--this is one of those items we've been working on in the usability labs pretty much straight for two years now. We want to be predictable, and we want people to be able to move between different monitor sizes and be successful. At the same time, we wanted to keep the Ribbon as efficient as possible to use at all sizes--this ruled out just adding scroll arrows to either side.
Each of the chunk sizes is designed by hand, and the order in which the chunks collapse into different versions is also designed by us and not by the computer. There's no attempt to "auto-scale" the UI. At 800x600 it will look the same on everyone's computer.
Ribbon tabs that include in-ribbon galleries scale up very well, because they can contain any number of discrete items.
In order to satisfy our usability criteria for Ribbon scaling, we ended up defining the following rules:
- No commands ever appear or disappear between chunk sizes
- Multiple commands cannot be rolled up into a menu at smaller sizes
- Keep labels on commands as long as possible unless the icons themselves are well-known
- Popup chunks show the same layout people would have seen in the Ribbon itself
These rules came directly out of watching people use the product in the labs over the last few years. Other rules we thought would be important (such as always collapsing from right to left) turned out to not matter at all.
Scaling a tab takes a lot of design effort to get right, and we spend a lot of time on the craft. Some have wondered why we don't just have a computer algorithm that decides all the layouts (or, even better, auto-optimizes them.)
The answer: I think the rigorous thought into the design is part of what helps make the Office 12 UI work--it's designed by humans for humans. That's a philosophy I strongly believe in, and I think it will be reflected in the quality of the final designs.