Choosing the right flavour

Changing the user interface of an application used by thousand of users around the world is a delicate task, especially when your community is always looking for increased efficiency and performances: in every newsroom, today even more than in the past, every step counts when delivering breaking news or live updates to all channels. In some cases, like news agencies, performances are stressed even more, and each process is measured in fraction of seconds.

Nevertheless, since the early stages of Méthode 6 development, we decided to include a revision of some GUI elements, also leveraging on several technology updates applied to the software - our main focus was on introducing new toolbars.

While most users will rely entirely on keyboard shortcuts, there is no doubt that the toolbar is one of the most frequently accessed UI element. Since its first releases, Méthode sports a default set of toolbars, that can be easily extended using COM-based scripting: all the toolbars are context-sensitive, and their appearance can be associated with the various “modes” of the application: editing, browsing, paginating, and more. So far so good, the model worked well, but toolbars suffered from a few limitations: they can only contain buttons and listboxes, and their arrangement on the screen is left to the user. Yes, it’s always possible for a tech guy to create custom workspaces and distribute them to users, but in many cases these workspaces do not include toolbars, resulting in poorly organised work areas, with possible waste of screen real estate.

The work on the new toolbars started with a basic set of clear goals: they should provide increased usability, modern design, remain context-sensitive and extensible. One major point of the new toolbars design was to cope with the requirements of completely different user profiles, for example editors and designers. In the first case, when writing a story in the text editor, the less intrusive the UI the better, therefore we started considering simplicity first, and a minimal set of icons and functions distilled from the most frequently used items: this was also a great opportunity for adding accessibility to functions hidden (read: buried) in complex menus and submenus hierarchies. When considering designers, web editors or, more in general, advanced users, the approach is towards providing quick access to multiple functionalities, involving not only buttons, but also selection of options (e.g. select color hues), and entering value fields (e.g. enter rotation angle). We started calling these two profiles basic and advanced, and thinking of a solution covering both their conflicting requirements and core Méthode functions, like the channel bar, that must be common to all users: in search of additional advice, we also looked for design guidelines.

Finding the right model

You may love or hate Apple, but no doubt they know something about design: their wonderful Human Interface Guidelines will drive you step-by-step in creating great-looking apps for both OS X and iOS. With that in mind, we hoped to find an equivalent guide for Windows applications: actually, Microsoft created a great manual covering the design of Metro Windows Store apps for Windows 8, where new concepts like “Semantic zoom”, “Charms” and “Contracts” are beautifully explained. But for Windows Desktop apps, the latest valid UX guidelines are still the ones released with Windows 7 which, while lacking the appeal of Apple’s equivalent, provide solid lists of do’s and don’ts, and some very good advice.

The richness of Windows toolbars may be overwhelming

Although empowered with guidelines, we were still far from having the right model in place, capable of balancing simplicity and power: therefore it was natural to have a look at how major applications solved similar problems. When you’re considering Windows applications, the 800-pound gorilla is MS Office, which set several standards of user interface over the years: actually, the latest major change in Office was the ribbon, based on toolbars organised in tabs.

While popular in many other programs today, the ribbon interface is one of the best examples of the difficulties in changing an established UI: probably everybody remembers very well the initial discovery phase needed to relearn the user interface of Office 2007 in order to accomplish what you already knew how to do. A reason behind the negative reaction is Microsoft's decision to remove the traditional menu system with ribbon-based toolbars, and, for exactly the same reason, we decided not to fully embrace the ribbon model, although it has been adopted even in the Explorer of Windows 8: simply put, there are so many functions in Méthode menus that it would take forever to reproduce them all in the toolbars. Notably, Office 2011 for Mac, while employing the ribbon, also retains the menu system in the Mac menu bar, and provides a nice example of a mixed approach.

In any case, Office toolbars have plenty of nice features, for example tabbed toolbars are great when used in context-sensitive environments, and the mix of large and small icons provides a pleasant variety in the design: at the end, they provided a good starting point for covering our basic user’s need. 

But, what about power users? Well, the applications of Adobe’s Suite are a synonym of professional tools, so we briefly studied them. Adobe applications are available on both Mac and PC since forever, and, clearly to avoid designing the UI for both platforms for every new release, Adobe’s engineers developed a proprietary framework capable of rendering the same interface in every environment. That’s interesting, but being Méthode a Windows-only application, we paid attention only to their toolbars design, and - boy - they can be complicated! Some of the most complex toolbars (Control panels, in Adobe’s jargon) are organised in sort of tabbed areas (e.g. the text toolbar in InDesign, with “character” and “paragraph” collections of controls) to allow collapsing dozens of icons in a small space: when needed, a floating panel pops up to provide even more options (this is popular in Illustrator). 

A large amount of user interface elements, in a control panel and in a floating menu: typical features of Adobe’s applications UI.

Definitely this approach can be appreciated by power users only, but, in any case, this complexity has an impact on usability: try googling for “Adobe InDesign toolbars” - plenty of tips and tricks pages and dozens of “cheat sheets” to help navigating the mass of controls. It’s also hard to maintain consistency between apps, in fact there are many sites devoted to moaning about mistakes in Adobe products (!).

From Photoshop, Illustrator and InDesign, we learned that pro users somehow love the complexity and richness of that toolbar model, but we did not want to limit our review to just the two biggest software suites. Considering how complex applications manage user interface, it’s evident how guidelines are not really taken into account, and, in some cases, usability. Design and CAD programs use the toolbar area to place as many controls as possible, to support what’s required by each task. Different UI models are frequently mixed, and tabbed toolbars are prominent due to their capability of managing large collections of icons.

Toolbars can easily get very, very complicated.

One pixel at the time

Our design finally started by setting the base dimensions of our toolbars, and the initial concept was centred around the tabbed model. The ribbon area had to be high enough to include two rows of icons, and provide the possibility to include other controls and larger icons: in this way, we could have a lot more functions in comparison to old toolbars, and occupy less space on screen. Even if existing menus were entirely preserved, we had the option to make several important features immediately accessible to the users.

Default size for icons was set to 16x16 pixels, with a 24x24 size available for larger ones, ideal for grouping similar functions. Initial concepts and design has been done using Photoshop, but test versions of the applications has always been quickly developed in parallel: this was essential, as we discovered it’s impossibile to “feel” the behaviour of a user interface just by looking at its design, you have to interact with it. We went through many, many iterations, adjusting almost intangible details like margins, tab size, white space and moving between tabs buttons, icons and controls: there were many crazy discussions about how frequently users need this or that, what should be promoted in the default tab, what should move to front when the context changed, and so on. Long lists of Méthode functions have been created, with their priority and position shuffled up and down.

Early concept of the new toolbars

Anyway, we knew this was the fun part: sooner or later, the nightmare job had to start - recreating all the icons. When you have 256 pixels available, no matter how sophisticated the tools, you have to place them all by hand: our designers tried many variations of large-size editing with Photoshop and Illustrator, and subsequent export, with no luck. Each icon had to be individually crafted, one pixel after the other, for a total of about 400 icons.

After a few iterations, we had the first family of toolbars available, covering both basic and advanced users, with some key concepts firmly in place: adoption of the tabbed model, distribution of commands between tabs, contextual behaviour, and the presence of the channel bar (one of the main tool used for multi channel production) always in top-left position.

Everything seemed ok with this toolbar style: while having its own personality, it was very efficient, bringing the most important tools in the front tab, and keeping tons more functionalities quickly accessible in secondary tabs. We also added grouping of similar functions and a label at the bottom of each toolbar “zone” - we expect almost no training required.

But, with the beta version of the software running in front of us, we started a sort of “What if?” game.

What if I want to maximise my work area and reduce to a minimum size toolbars?

What if toolbars could be condensed to contain more controls?

What if I’m a power user and I don’t need labels to distinguish icons?
What if tabs where not necessary by relying entirely on a context-sensitive switch?

Well, we couldn’t resist: a new model for toolbars was quickly assembled, by reusing graphics, repositioning controls and reviewing the original design. And, unexpectedly, we came with another model that fitted perfectly the needs of advanced users: these compact toolbars were half the height of the tabbed ones, and provided a tiny switch on the left to toggle between modes: in the image below, the layout toolbar has a switch to become the typo toolbar, but normally this change is managed automatically by changing context.

Best of both worlds

The final decision was quite easy - keep both models in the final release. After all, these toolbars will be only the starting points provided by the application when installed: and, while we really hope most of the users will be happy with them, we know how hard it is to make a huge community of professionals completely satisfied. That’s the reason why our toolbars remain under control of our customers, that may decide to simply remove a few icons to entirely redesign them, applying layout, color and functionalities as they wish.

Let’s see how much of this long journey will remain, thanks for following!