The total UI overhaul in the latest incarnation of Microsoft's ubiquitous office suite may be the most sensible, and at the same time most ridiculous, thing to have happened since the move to Office for Windows. From the end users' perspective, it looks like a scary prospect with potential, and for the developer it looks like an exciting new paradigm. Which is it? Both, or neither?

UI Overhaul

After a first glance, I'll admit to mocking the Ribbon UI layout. It's not radically different to previous user interfaces, but appears to actually have less available options for the users. I took the the popular stance of "more is better". I'll now admit to being wrong.

Some who know me well actually fainted in sheer surprise when I said that I actually quite liked a new MS product. To be honest, I was as surprised as they were, so I dug deeper. I looked at it, looked at the reasoning behind it, and watched some developer-produced videos I can't help but like it.

One interesting decision is to completely replace the keyboard shortcuts. The same basic system exists as it did for menus in previous versions of Office; the combination of alt, the shortcut of the tab you want, and the shortcut for the key is all you need. In theory, all you ever need is a combination of alt++, although the embedded menus require you to use the arrow keys and enter to access them.

On the one hand, I think this is quite nice. The addition of little pop-up letters to guide you through the interface is handy for learning it, and once you know them they're easy to type without having to leave a normal typing position. Of course, the old ctrl+ shortcuts still work for those with years of Windows muscle memory.

On the other hand, it's very strange. The use of key-chords is reminiscient of a certain Free editor that is renowned for its excessively long but thoroughly comprehensive keyboard access. For those of use who like editors that pack a load of power into a few keystrokes (the text for this article is being written in Vim), it will be great. For those who just want to use the mouse, it'll be great too. For those who want to use the old menu key-chords, it'll suck.

Fonts?

Part of the new Office experience is a complete set of new typefaces, doing away with the old and crufty Times New Roman and Arial staples of the MS Office based publishing age. Instead, a whole bunch of typefaces will be included with such funky names as 'Calibri', 'Candara', 'Cambria' and 'Consolas'. This collection consists of three sans serif, two serif and one monospace font all beginning with the letter C.

Interestingly, Microsoft have gone against the grain and used a sans serif font, Calibri, as the default for new documents. I am not sure why, but my guess is that they assume that most documents produced in Word never actually get printed. A growing trend of sans serif typefaces in publications primarily intended for screen reading means that many custom templates I have seen recently use Arial as the document default. While this makes clear, crisp on-screen text, it looks awful when printed out. The added flow of a serif font on paper makes reading much easier.

UI Customisation

The method of customising the UI is completely diferent from the old way of doing things. No longer are you tied to using Word as a WYSIGWYG toolbar editor; everything is XML! Yes, that old chestnut, poster child of the data interchange age, XML. You can define controls and behaviour through the XML file, but very limited layout control. You can group them together and tell them to group into horizontal and vertical boxes, but that's about it.

One of the major changes with this XML based overhaul is that you no longer have programmatic access to the objects representing the controls. If you want to ask an edit box what its current value is, you can't. If you want to set a label from within the code, you can't. It's entirely transparent and driven by the callbacks configured in the UI XML document.

That's not to say that you can't update and read your controls. You most certainly can. Updating labels, enabling or disabling controls, setting the 'pressed' state of buttons and the like is handled by invalidation and callbacks. Instead of explicitly saying 'control, set thyself to be enabled', you would store that fact in the internal state and invalidate the control. It would then query its configured callbacks and set itself accordingly. It's actually very neat and explicitly enforces proper separation of the View from the Model the Controller in your MVC add-in. Of course, it's still up to you to separate the other two. If you're used to storing program state in the controls and querying them directly to get the data back, then it's time to update your habits.

Programmer Niggles

There are a couple of niggles that I have discovered during my romp through the new UI handling functionality of Office. Considering the number of new pieces of functionality there are, and the thorough and fundamental way in which the experience has changed for user and developer alike, it's testament to the UI developers that there aren't more curse words used to describe it.

The first problem is that of the configurable callbacks for UI controls. Given that the only way to manipulate the controls is via the callbacks provided in the XML, it would be nice if the callbacks that could be configured matched those available in previous versions of office. Unfortunately, for the combo and edit box controls, this isn't the case. They both support and onChange event that is fired whenever a change to the control is confirmed. However, if you 'confirm' (i.e. press enter while the control is highlighted) a change, sure enough your code is run. However, if you don't change anything but press enter anyway, nothing happens.

This is different from previous version of Office because they supported a more generic onAction callback. If you cause an action in a control, you could catch it and run with it. Unfortunately, without this functionality, the combo and edit boxes are of limited use.

The particular instance I was playing with was a built in search control in the ribbon. This requires that the user enter a search phrase and press enter. The first time a user does this it functions superbly. The event is called, everything works, marvellous. I select the control and press enter, expecting the search to repeat, but ... nothing.

Having these controls only fire when something is actually different causes users to have to go through a strange dance of running with a different value and switching back. Even if you change the value in an edit box and change it back to the previous value before pressing enter the onChange event won't fire. You are stuck.

The second issue is more mundane, and it's the way the keyboard shortcuts are handled. It appears to be quite brittle, in that it is easy to break by using an 'unsupported' combination of configuration methods. You can have a callback that the controls call to ask your add-in for their shortcut, you can have an explicitly designated shortcut configured right in the XML, or you can use the good old '& in the label' method of old.

Unfortunately, if you mix and match these methods it seems to break. The moral of this story is "don't do it". That's a very minor complaint.

A more serious one is the rather arbitrary way the system will reassign your keyboard shortcuts if it finds them distasteful. On several occassions I have had configured shortcuts changed to 'Y1' or 'M2' with no apparent reason. This appears to be in part a problem with legacy shortcuts. It seems that the UI team decided to keep some shortcuts working even though they aren't visible on the Ribbon for old power-users.

One of the nice features about the shortcuts is that you can have multiple keypresses for a single tab or control. For instance, you might have a custom tab that has a 'Jump Up' and 'Jump Down' feature. You could assign 'U' and 'D' for those, or 'JU' and 'JD' if you have other, better uses for the U and D keys.

This works fine in principle, but falls over when you realise that all shortcuts sharing a prefix must have the same number of keypresses. This means that if you choose 'FB' as your FooBar tab's shortcut, the File menu's shortcut will magically and silently change to 'F1'. If our previously mentioned 'Jump Up' and 'Jump Down' is joined by our all new 'Jump All Around' button, a keyboard shortcut of 'JAA' will force our others to be 'JU1' and 'JD1' respectively.

Within a single tab, this isn't too terrible. It just means you have to be careful. However, when you are assigning a shortcut for your tab itself you are pretty much stuck. If you choose a single letter it's pretty much guaranteed to conflict with something else at some point and gain an ugly '1' or '2' after it. On the other hand, if you use multiple key presses you can end up changing an existing tab's shortcut, and thus break user's muscle memory for certain commands.

A potential solution for this would be to allow a short, but user configurable, delay between pressing a key and selecting an item. Of course, this would only be necessary if there were multiple to choose from, but pressing (for example) 'F' would either delay for a fraction of a second and take you to File, or encounter a 'B' and take you to FooBar. Pressing the correct shortcut that doesn't match another tab and that exists within File would take you straight there.

This idea is by no means perfect, but to my mind is a lot nicer that arbitrarily assigning numbers to the existing tabs in a similar manner to the day of C:\PROGRA~1\MICROS~3. MICROS~3? What's that? Microsoft Office? Microsoft Visual Studio? Microsquabble? I don't know. Of course, turning off the delay option altogether would revert to the arbitrary numbering method.

Openness and Utility

In the interests of openness, I like the new OpenOffice.org OpenDocument format. The new Office document format is a direct Microsoft competitor for the same and they are essentially saying "Look how open we are! We won't support your format, but we'll make our own and say it's open!"

This is pretty petty behaviour, all in all, and this UI customisation mechanism is just one example of why they are doing it. It is possible to embed the UI customisation directly into the document file format by cracking it open like a zip file and sticking the XML right in there. Any VBA you might write to support it goes in there too.

This means that, despite the apparent openness, the new file format is only really useful to ... Microsoft. Sure, other people may be able to read and write the document itself, but great lumps of it require a per-application UI rethink to support for the UI XML. Even worse, the UI will only actually perform actions on platforms that support VBA or COM. So far, this includes many operating systems. Unfortunately they all start with 'Windows ...'

Thanks to the rather dubious Microsoft/Novell deal, some VBA support may be making its way to a platform near you soon. This is clearly an attempt to subvert the OpenDocument format in its home market, and porting VBA to previously open platforms may be the foothold Microsoft needs to get in there and embrace and extort the competition again.

My thoughts on this can be summed up quite simply. MS should have used OpenDocument. If they felt it was genuinely unsuited to some of their needs, they could have joined the companies developing the standard. Unfortunately, the one piece of functionality the OpenDocument lacked that MS really wanted was the 'customer lock-in by tightly coupled software and formats' feature. Without this, how could they maintain a stranglehold on the users of their productivity software?

If they had used OpenDocument from the start, included sensible support for what they needed (OpenDocument already supports OLE, for instance) and made a separate Office UI expansion system it could have been great. OpenDocument would have flourished, the Ribbon would have been excellent and the world would have been happy. Sadly, I can already foresee the day when a company refuses a document I send them because they only support documents that can be opened in Word, and Word is the only word processor in the world that doesn't support OpenDocument.