Adapting the Office 2007 Look & Feel :: A Case Study
I have a day job as a UI designer for a mobile software company, but on the nights and weekends I’m a bit of a hobbyist programmer in C# (Microsoft’s Java-like .NET programming language). My side project is called FloSpace FloPrompter and I recently published version 2.0 (www.flospace.com). FloPrompter is a teleprompter. Users can author text in one window which offers basic wordprocessing features, then click a button to launch a special teleprompter player window.
One of my chief design goals for the FloPrompter project was to emulate the new Office 2007 look and feel, including the new Ribbon toolbar design. What I’d like to do here is offer a brief ‘case study’ on how I approached this design goal.
As most readers probably know by now, Microsoft basically re-conceived their approach to toolbars and menu item organization for Office 2007, presumably for the purpose of enhancing their overall software usability. The result is, in effect, a new paradigm for command and menu item organization on the Windows platform.
(Yes, I know Apple has done something similar for the MacOS, but most PC users are oblivious to the MacOS world. So for all intents and purposes, this paradigm is completely new to gazillions of PC users.)
The design goal of emulating the MS Office 2007 look and feel (“L&F”) actually spawned several challenges practically speaking, especially given that I’m a hobbyist programmer working on a shoestring budget.
Challenge 1: Icons
A long-standing challenge I faced was finding icons that were both aesthetically pleasing and comprehensive enough to cover the moderate feature set in FloPrompter. For small projects like this, it’s easier and cheaper to purchase a royalty-free stock icon library. Who has the thousands of dollars necessary to create a completely custom set of icons? Even so, the biggest issue is finding a library that is comprehensive enough for the functionality of your application — in other words, that all the actions you want to represent as icons are present.
After a lot of searching, I settled on Glyph Lab. Their stock icon set is very comprehensive, aesthetically pleasing, consistent with the Office 2007 L&F, and also affordable (about $200). What’s also cool is that each icon comes in an array of formats, color depths, and so on, which simplify life considerably for the designer and/or programmer.
Challenge 2: Finding UI Components
Since Microsoft hasn’t yet released free standard UI components which give desktop applications that Office 2007 L&F, I needed to find a third party software vendor whose components were both high quality and affordable. I tried several vendors and after several weeks settled on a UI component library from DevComponents. Now that I had the library, I could fairly quickly and easily create a UI emulating the Office 2007 L&F.
As a side note, there are many companies out there which sell user interface component libraries, like buttons, window menus, color pickers, etc., usually with enhanced functionality and “theming” capabilities. In the .NET world, fortunately, the market for third party UI components is particularly robust. It’s a pity that the market for commercial quality, third party components are fairly poor for the desktop Java and QT programming languages.
Challenge 3: Menu & Toolbar ‘Information Architecture’
After I had the UI component library, the more difficult task of organizing the menus and toolbars in this new Office 2007 style began. First, I had to become familiar with how Office 2007 organizes everything even though I don’t own a copy of the product. After a bit of Google searching, I found a great article online which showed enough screenshots that I could reverse-engineer the design principles of the new look & feel.
The Application Button
Gone are the words like “File,” “Edit,” “View”, “Help”, and so on from the top of a window! In their place is a single round button in the upper left-hand corner which, when clicked, offers application-level functionality which had previously been located under the “File” menu. Generically, I’ve heard this button referred to as the Application Button. This button should have the product’s logo on it so it serves not only as an access point for application-level features specific to your product, but it also offers an additional branding opportunity in the UI.
When the user clicks on the Application Button, the user ought to see a popup with three sections: a left-hand command panel, a right-hand recently used documents list, and a panel with commands at the bottom. The left-hand command panel has large icons (32×32) and most of the old “File” commands, like New, Open, Save, Save As, Print, etc. The third section, the little panel at the bottom, ought to have the application’s Options and Exit commands. I suspect that the Options and Exit commands are set apart visually to make them easier to find and help address the truism, for example, that users rarely customize the application options.
For FloPrompter, I replaced the Exit command with the Close command because the product has no explicit “Exit” command to close all open windows at once. A design assumption I made about the product is that users will rarely have more than two or three windows open at once, so I didn’t want to add cognitive load by having two similar-sounding “Close” and an “Exit” commands in the UI.
Ribbon Information Architecture
As one can see in the screen shots on Geekpedia, the commands displayed on each tab in the Ribbon are organized around specific tasks, such as “Write” for Word, “Design” for PowerPoint, and “Review” for all of them which support these collaborative activities.
Within each Ribbon Tab, commands are further divided into “Ribbon Groups” which are logically related small groups of commands. In Word’s “Write” tab, one can see groups for: “Clipboard” holding Cut, Copy, Paste, and Format Paint; “Font” for font name, size, and style commands; “Paragraph” for text alignment, bullets, indenting; and so on. In the old style of UI, commands that appear in Ribbon Groups might have once appeared in a cascading menu or between two dividers.
One can also see that within each Ribbon Group, one or two commands might be featured as a large icon button (such as Paste in the Edit group), while the rest are smaller buttons featuring icons only (if very familiar like Cut, Copy, and Format Paint), or featuring both icons and text (like Replace and Select on the far right). Presumably, the Office 2007 designers display the most commonly used feature within the group as the large button, and all others as regular sized buttons. Notice also that almost every command in the Ribbon UI has an icon, which again puts pressure on stock icon libraries to have thoughtfully complete feature sets.
FloPrompter’s feature set isn’t as rich as Microsoft Word’s, so I had some difficult decisions around command organization. I thought for awhile over how to organize the Ribbon Tabs and Groups. It was fairly easy to figure out that I needed a tab for “Write”, like Microsoft Word, and a second one called “Segments” for the unique feature in FloPrompter for creating and managing what I call “broadcast segments.”
However, I was stumped at first over where to put the commands which used to appear under the Window and Help menus in the old style, such as product Help, About, and so on. FloPrompter also has new theming and color customization features which in the old style might have appeared alongside Window as its own menu called, “Theme”. In the end, I decided to put all of these commands on a separate Ribbon Tab called “View”. My rationale was that the theme and color customization commands and the Window list all affect the current view; and the commands that would have been under the old Help menu could be phrased in the user’s mind as, for example, “View product help information.”
Back to FloPrompter’s Write tab. Figuring out a good way to organize the Edit group was tough. One will notice in the Edit group that Cut, Copy, and Paste all are displayed as big buttons, while Undo, Redo, and Select All are displayed as small buttons in a vertical column.
I decided to give Cut, Copy, and Paste equal weight within the UI for a couple of reasons. One was that I wanted to give the appearance of a hefty feature set in the Ribbon, so pulling those three out as buttons helped. Another reason was that it looked unbalanced to emulate Word’s Clipboard group and display only Paste as a big button with Cut and Copy in a vertical column by themselves. Also, Ribbon Groups look better when they have a vertical column of three buttons or three horizontal bars (like in FloPrompter’s Font group). It would have looked odd to have a large Paste button, a vertical column with Cut and Copy, then another vertical column with Undo, Redo, and Select All. So my advice to the reader is to try a number of different combinations of big buttons, vertical and/or horizontal bars of buttons, and see which works best visually for the given feature set.
The Quick Access Toolbar
The reader may have noticed the row of small icons at the very top of the window called the Quick Access Toolbar (“QAT”). The icons displayed here are intended to be the short list of the most commonly used commands in the application, regardless of context. For the FloPrompter product, given its smaller feature set, I felt like the most commonly used commands would be around file management (Open, Save), segment management (Add Segment, Play [which launches the teleprompter window]), and Help. I also added a feature so that the user can show or hide the Ribbon because some early alpha users said that it was too big.
Ribbon Customization
Ideally, one should allow the end user to customize which commands appear on the QAT and elsewhere on the Ribbon control. Although the DevComponents UI library supports customization of the QAT dynamically by the user, it doesn’t allow me to specify icons that have been optimized for each size (say, 16×16 vs. 32×32). Instead, if the user wanted to put the Paste command on the QAT, which is shown in the Ribbon with a 32×32 icon, DevComponents shrinks it to 16×16 to show on the QAT. Unfortunately, simply scaling the icon down to 16×16 introduces artifacts which make the icon very ugly.
In fact, I turned off the user customization feature of the entire Ribbon Control for the same reason as for the QAT: allowing the user to move things around means that icons will be dynamically shrunken or enlarged and will therefore be very ugly. I don’t want users to see ugly icons and associate an imperfect feature like this with FloPrompter in general. So I’ve decided to turn off the QAT and Ribbon customization features for the current FloPrompter version until either DevComponents fixes this issue in their library or I can figure out a workaround. Hopefully, I’ll turn on QAT and Ribbon customization in the next major release!
Summary
It’s been a fun challenge figuring out how to adapt FloPrompter’s UI to the Microsoft Office 2007 design style. It helped to experiment a lot with different configurations. It also helped that FloPrompter has only a modest feature set. Playing with DevComponents’ Ribbon control, I could see that there’s quite a number of brand new components in the Office 2007 design style such as image galleries.
Successfully applying the Office 2007 design style will require a fresh approach to your application’s information architecture with a stronger emphasis on the contextualized usage of your product’s feature set. Take advantage of the new UI components (such as galleries) that are part of this design style. You’ll also need to work with the graphic design team to ensure that you have icons for almost all of the commands in the UI.
Experienced UI designers will quickly adapt to the new design style. I found that the more I worked with this design style, the more I liked it. I hope the FloPrompter users like it, too!
