Yesterday, I wrote about our fight against interface squalor.
The most dangerous features from this perspective are the ones that appear to
need to be available “all the time.” Each one of these occupies a space in
the window that can never be given back to the document canvas or to other
features. Needless to say, we’ve taken a very conservative approach to
allocating space for “always
available” features. One needs to be skeptical about what “always
available” really means.
That said, we are aware that some features do need to be available efficiently
nearly always. One class of functionality that we felt fell into this
category was “view switching.” In this category, I put three kinds of
- Actually changing the view of the document (from Page Layout to Outline
- Turning on and off user interface components, such as the Ruler or the
- Changing the zoom level of the document.
Because these “view switching” commands were pretty much task-agnostic, we
didn’t feel like they fit into a specific
Ribbon tab. At the same
time, we were pretty much already out of space above the document–with the
Ribbon, contextual tabs, and the Quick Access Toolbar (which I need to write
We started exploring the idea of the window frame itself being the container
for these “view switching” controls. This was an idea I liked because of the kind of
mechanical nature of it. At the time, we were in the midst of redesigning
the status bar down at the bottom of the frame. We realized that we
couldn’t do away with the status bar altogether, as it plays an important part
in the UI. On the other hand, we didn’t need all the space it took up most of
the time just to do “status-y” things.
So, taking the lead from other programs (including the Picture Manager that
shipped with Office 2003), we integrated zoom into the status bar. View
switching soon followed. Instead of the typical zoom combo box, I liked
the feeling of “live zoom”, so we built in a slider to control the zoom level.
Down the road we also integrated windowing functionality in with the view
switching, so that you control both what is showing and how it is showing from
the same place.
But the big winner, in my mind, is zoom. I never
thought about zoom much in past versions of Office; I tended to just live with
what was on-screen. It was fairly inefficient to set the zoom level
correctly; unless I wanted exactly 150%, I had to use a lot of wasteful
trial-and-error to get things set correctly. Now, using Office 12, I think
of zoom as more of an organic part of how I work with documents. I seem
much more likely to zoom in or out on something, to quickly tweak the level with
the slider. I’ve found it especially useful when navigating long documents
View, windowing, and zoom control in the Word status bar
There are a couple of downsides with putting this UI in the lower right-hand
corner. In the Beta 2 visuals we’ve made the control area more distinct
because some people had a hard time finding it initially. (The good news,
though, is that once people do find it, they remember where it is.) Also,
the Windows taskbar has an AutoHide setting which can sometimes cause the
taskbar to come up over the controls you intend to use. I personally use
this configuration at home and haven’t had a problem with it yet, but I could
imagine having a harder time with a low-precision pointer like a touchpad.
Luckily, the vast majority of users do not use AutoHide, so I don’t think it’s a
The upside is that space that is normally wasted in Windows apps can now be
reclaimed for useful purposes. In many apps, most of the status bar is
just wasted space, included to look “standard” and so that there’s somewhere to
host the window resize widget. I’m hopeful that our solution to view
switching, windowing, and zoom becomes the standard and that we see it become just a
seamless part of how document-centric apps work.