…or how I learned to stop worrying, and love the ribbon.
Over the years we’ve made some pretty controversial changes to Sibelius. Who remembers when the Enter key on the numeric keypad stopped editing the selected note and instead added a tie? Or when the Space bar was changed to start and stop playback, instead of inputting a rest? Or when the Sounds window was replaced by the first version of the Mixer? Or when the behaviour of the R key was changed to correctly repeat the duration of the selected note in all circumstances, rather than arbitrarily stopping at the barline?
But by far the most controversial change we’ve ever made has been to adopt the ribbon UI in Sibelius 7. Many people have taken to it very happily, but lots of people are resistant. I was recently asked by a poster on the main Sibelius forum about what the rationale was for making such a fundamental change, so I thought I’d record my response for posterity. Read it after the jump.
Long-time users of Sibelius naturally forget what it was like when they first started using the program, especially those who started using the Acorn version the best part of 20 years ago! Slightly less long-time users might cast their mind back to the days of Sibelius 1.4 and remember how simple the program seemed. Over the years since then, we’ve added things to the program incrementally, building on the excellent foundations that Ben and Jonathan Finn designed. Sibelius 3 didn’t seem so different to Sibelius 2, and Sibelius 4 didn’t seem so different to Sibelius 3, and so on: existing users could deal with the incremental change between versions because they already had a good mental model of how the software worked prior to that.
But imagine a new user coming to Sibelius 6, say, for the first time. Sure, in principle, it doesn’t look so different. But take a look at the toolbar. Are those buttons on the toolbar the operations you really use most commonly as you use the software? Could you learn how to input notes, or create text and other markings, or play back the score, from that toolbar? Put yourself in the shoes of somebody who has never seen Sibelius before, and think about changing the staff size, or adding or deleting a bar. How do you do that? How do you add an instrument to the score?
And those are just examples of the very simplest, most basic features of the software. What about the really nifty stuff, like exploding music onto multiple staves, or automatically cleaning up Flexi-time input or MIDI import, or adjusting the note spacing…?
The point I’m making with all of the above is that Sibelius has become a very sophisticated program with many hundreds of features, and long-time users cannot easily comprehend what it’s like to see it for the first time, let alone try to figure out how to use it.
Don’t get me wrong: the original design that Ben and Jonathan laid out was great, and as the product’s principal designer in the years since, I have done my best to continue along those same lines over the past several versions. I don’t think Sibelius at its most complex has ever been a fraction as hard to learn as a program like Finale, which even more obviously betrays its late 1980s roots than Sibelius betrayed its late 1990s roots.
The fundamental challenge, then: how to make the deep feature set of Sibelius more accessible to new users, so that exploration of the program is encouraged. How to make all of the common operations as easily accessible as possible, and put in signposts to the less common or more complex ones. How to provide a modern user experience that is similar to the idioms used in other software, so that things people use every day in other software (e.g. tabs in their web browser, the ribbon in their Office productivity software, etc.) are used in Sibelius, so that it feels comfortable to use alongside other modern software.
And, on the other hand, how to do this in such a way that we would not drive every existing user of the software crazy. We knew we had to try to keep terminology the same, retain every possible keyboard shortcut, retain the contextual menus that appear when you right-click, and ensure that the core operations of creating scores, inputting notes, playing them back, etc. were all exactly the same as in previous versions.
There has been lots of research done into software usability, and the ribbon is the result of perhaps the largest such research project ever undertaken. If you have 90 minutes to spare and want to really get the inside story on how the ribbon was developed, and the literally millions of data points that went into its design principles, you should watch this video.
The ribbon solves many of the problems we wanted to solve, and it does so very elegantly. It provides an icon, a text label, a detailed description and a memorable keyboard command for every single feature. It provides a means to make important features more prominent than less important ones, to group related features together, to have a richer set of controls than a normal toolbar so that more tasks can be accomplished directly in the ribbon without the need for opening a modal dialog. It scales well across displays of different sizes, and means that the same feature will always appear in the same place, even if you use a completely different screen size to me.
We looked at a number of different UI approaches, and the ribbon was the option that made the most sense, given the scope of the feature set in Sibelius, its document-centric nature, and so on. The ribbon is not a free-for-all, however: in order to implement it in your application, you have to agree to certain licensing terms from Microsoft, which includes a set of UI guidelines for ribbon applications that have to be followed. These guidelines stipulate aspects of the user experience in great detail, and also include rules about things like whether or not your application can include a menu bar (it can’t). We happily follow along with Microsoft’s rules because almost all of them make sense in the context of the UI principles of the ribbon.
Although we had to lose the menus, we were able to retain all of the existing keyboard shortcuts. Power users who had been using Sibelius for years can fly through their work in Sibelius 7 just as they did in previous versions: they can even minimize the ribbon if they don’t want to look at it. There doesn’t have to be a huge impact on the way you work just because Sibelius has a ribbon and not a toolbar.
One particular cry of anguish has been that of Mac users who feels the ribbon is too Windows-centric. Certainly it is used in very few Mac applications, the only other example at the moment that I am aware of being the latest version of Office for Mac. However, the implementation of the ribbon in Office for Mac represents a substantial compromise, missing out on many of the most powerful aspects of the Windows ribbon UI, including real time-savers like key tips, and leaving in both a full toolbar and a menu bar, thus providing three competing interfaces within one product. The primary complaint is the loss of the main menu bar, which we decided to strip down in order to prevent there being massive duplication of functionality between the ribbon and the menus, and because the way we chose to organise the ribbon did not in any case map exactly onto how the menus had previously been organised: over time, these would only diverge more and more. The problems that the ribbon sets out to solve are not specific to Windows: they are specific to complex document-centric applications. There’s no reason why the ribbon approach should not work on Mac.
And the ribbon provides a number of real, ergonomic improvements, regardless of whether you’re a Windows or Mac user: the way the galleries on the Notations tab provide quick access to the markings you’ve used in the current score; the way you can perform operations that previously required visits to dialogs, such as changing the staff size, page size, margins, etc. directly from the ribbon; the fact that all of the options related to a feature area are grouped closely together (e.g. the Text > Chord Symbols group); and to ensure that important, commonly-used features (like the menus for changing text style, font and point size, for example) are put front and centre in the ribbon, and not buried away in obscure places like the Text panel of the Properties window, where people have always struggled to find them.
Finally, consider the alternative, i.e. what if had we done nothing? Sibelius would have become increasingly ossified, held captive by the habits of its long-standing users, and impenetrable to new users. Imagine a Sibelius version 10 with another 40 or 50 menu items, and another half a dozen icons along the toolbar. Try to imagine what the other software on your computer will look like in five years’ time.
Sibelius 7 is our statement of intent. We will not be bound to the past, as that will prevent us from delivering the best products in the future. We want to bring all of our existing customers with us, and we worked hard to minimise the disruption that a radical overhaul of the user interface would bring. We quickly decided not to leave the old interface in as an option, and as we rewrote the UI parts of Sibelius 7 using the new application framework that allowed us to also provide niceties like resizable dialogs, improved keyboard and mouse access, richer standard controls, dockable panels, tabs, etc., we ripped out those old things as quickly as we could. Leaving in the old interface would cause us additional overhead and maintenance headaches, but more importantly it would be bad for the product, a ball and chain holding it back in the past.
We’ve been bold, but we’ve done it all with the best interests of our present and future customers at heart. We are glad that many thousands of you have already decided to come along. Now that we have the foundations in place, we are focused on building more features that will delight you, just as we have done in the past. Stay tuned!