Perceptions of Application Feature Bloat

A reader recently wrote me about the Considering the New Metro Interface—Ribbon Redux? post and discussed the problem of application feature bloat. It really does seem as if software vendors are blind to the needs of users at times. Many applications have bells and whistles added that don’t appear to serve a useful purpose and support the vendor’s assertion that you pay full price for the upgrade (after all, it does contain all of these new features). From a certain perspective, these issues are real. However, let’s take a step back for a minute and examine the problems in more detail.

The problem is complex—as most of these problems are. The features you need from an application may not match the features that someone else requires. The overlap is the common feature set—those features that don’t overlap are often called bloat by those who don’t need them and productivity updates by those who do. When a vendor has thousands of users screaming for much needed features and equally decrying the massive bloat incurred by previous updates, it becomes really hard to decide what to do. The problem becomes worse when a vendor also chooses to honor backward compatibility requirements that some users need to ensure that old add-ins, scripts, and so on keep running. It truly can become a horrifying mess. Looking specifically at the Ribbon, it’s most definitely a productivity killer for power users. However, most of Microsoft’s customers aren’t power usersthey’re less skilled users who need every bit of help they can get just to become productive. So, while I view the Ribbon as a nuisance and would prefer to go back to the old menu and toolbar system, the majority of users are probably working more productively using the Ribbon. (That said, it would have been nice if Microsoft had provided a dual interface so those of us who like the menu and toolbar system could continue using it.)

One of the reasons that vendors will sometimes introduce a completely new interface is to start with a new baseline product. The old product has simply become too messy and unmanageable to maintain. A fresh start makes it possible for the vendor to do a better job of supporting user requirements from the update, forward (sans backward compatibility).  Unfortunately, this strategy also makes everyone irritable. Again, looking at the Ribbon, Microsoft has been trying, without success, to kill VBA for some time now. The Ribbon doesn’t kill VBA, but it does definitely throw a monkey wrench in the works. I imagine that Microsoft will continue to introduce incompatibilities until people move away from VBA completely. Material in both RibbonX for Dummies and updated VBA for Dummies  makes it possible to overcome these issues, for now, but Microsoft seems quite determined. It will be a dark day when VBA finally goes because many power users rely on it to create productivity solutions for Office products.

If a vendor were truly looking for just a fresh start, I could probably deal with it because anyone with a modicum of good programming skills wouldn’t need a fresh start very often. The problem is that you also have to deal with marketing.  Sales have been a bit slow, so marketing demands a new interface in an attempt to generate sales. If the old interface isn’t selling, then perhaps a new one will. The vendor often backs up the need for this fresh interface with user studies and so on, just as Microsoft has been doing. However, statistics are often misleading, incomplete, or simply incorrect. I’ve run into that problem myself when I try to decide how best to update a book based on user input. The users who write may not represent the majority of the users out there and my statistics become skewed. Microsoft and other vendors also encounter this problem. In fact, skewed statistics are probably at the heart of both the Ribbon and Metro interface decisions. More than a few members of the trade press have pointed this out as well. John Dvorak’s post on the topic seems to be the clearest of the bunch when he states, “Thus, the problem with Windows 8 and Metro finally became clear to me when I was confronted by a wall of tiles and was lost.”

Updates also come into play when new hardware becomes available. The mouse generated a ton of negative responses when it first came out and vendors started including it as a mandatory part of their software. To an extent, mousing about is a productivity killer when you’re dealing with a touch typist who can better manipulate an application using the keyboard. However, I doubt very much that people would get rid of their mice today. The same could be said of touch interfaces—they may eventually become so prevalent that people will wonder how we ever got along without them. Today, however, they’re generating a lot of negative comments because most of us don’t have a touch interface on our desktop systems. Microsoft is also encountering this problem. I personally think they’re venturing into touch interfaces far too early in the technology’s evolution and it’s going to burn them at some point.

So, are new interfaces generally a bad idea? The answer is that it depends on your point-of-view and the reason the vendor is making the change. How do you view the new interfaces that Microsoft is supporting? For that matter, how do you view most application changes today? If you’re amongst the power users out there, you probably view most changes as unnecessary feature bloat that destroys productivity and costs a lot of money for features that are nearly useless. Less skilled users may have a different viewpoint. Let me know your perspective at


Creating a Global Toggle Button

I’ve worked through a number of odd issues with the Ribbon and VBA in this blog and in two of my books VBA for Dummies and RibbonX for Dummies. For example, the Creating a Custom Styles Group post shows how to make a gallery look correct when you move it to a custom tab. Likewise, the A Quick Method for Adding Custom Ribbon Elements post demonstrates a new technique for customizing the Ribbon using built-in Office 2010 features. Unfortunately, those posts won’t show how to add some specialty controls to your custom Ribbon, such as a toggle button, that also automatically loads when Excel opens. In fact, most people assume that any custom Ribbon element must be added to the individual worksheet or as part of an Excel add-in. This post will dispel that notion.

Before you begin this article, make sure you’ve read the Creating Global Macros in Excel 2007 and 2010 post. You need to understand things such as the location of the PERSONAL.XLSB file on your system and its purpose. Of course, the main purpose is to provide a means of creating global applications that load immediately when Excel loads.

If you try to add a toggle button directly to the PERSONAL.XLSB file, you’re going to quickly find that the process doesn’t work. I tried for hours to get the toggle button to even appear. Regular buttons work fine. You can also easily add galleries using techniques I’ve discussed before, but toggle buttons proved elusive at best.

The trick is to think outside the box. You can create an individual file that contains a toggle button without any problem. Yes, it does require that you create a customUI entry in the application either directly (by changing the file extension of the file to .ZIP and adding the correct elements) or by using an editor, such as the CustomUI Editor. This post won’t cover the basics of creating a custom tab. If you don’t have a copy of RibbonX for Dummies or VBA for Dummies, you can find this information on a number of sites, including MSDN.

Begin by creating a standard Excel workbook and saving it an Excel Macro-Enabled Workbook (.XLSM file). You’ll need to add a custom tab, group, and toggle button to your workbook. Here’s the code I’ve used for this example. It’s nothing elaborate. In fact, I purposely made it simple to ensure that the post would focus on technique.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<customUI onLoad="RibbonLoaded"
    <tab id="myTab" label="My Tab">
      <group id="myGroup" label="My Group">
             <toggleButton id="SayHello"
                           label="Toggle SayHello"

This toggle button has two events it must handle: onAction and getPressed. In addition, you must load the Ribbon before you can make anything work. To make the button functional, I needed to add the following macros and global variables to the workbook.

' Define a global variable to hold the Ribbon reference.
Dim Rib As IRibbonUI
' Determines the behavior button state.
Dim lBehavior As Boolean
' Callback for customUI.onLoad
Sub RibbonLoaded(ribbon As IRibbonUI)
    ' Save the ribbon reference.
    Set Rib = ribbon
    ' Initialize the behavior state.
    lBehavior = False
    ' Show a status message.
    MsgBox "Ribbon is Loaded."
End Sub
' Callback for SayHello onAction
Sub SayHello_Click(control As IRibbonControl, pressed As Boolean)
    ' Change the behavior state.
    lBehavior = pressed
    ' Update the control.
    Rib.InvalidateControl (control.ID)
    ' Display the status.
    If pressed Then
        MsgBox "The toggle button is pressed."
        MsgBox "The toggle button isn't pressed."
    End If
End Sub
' Callback for SayHello getPressed
Sub SayHello_Pressed(control As IRibbonControl, ByRef returnedVal)
    ' Return the current behavior state.
    returnedVal = lBehavior
End Sub

Don’t forget to make sure you define the relationships if you’re editing the file by hand. OK, at this point you have a toggle button that’s functional. If you save this file, close it, and then reopen it, you’ll find that you can click the button and it’ll tell you its state—either pressed or not pressed. That’s not really the big deal here.

Now, save your file as an Excel Binary Workbook (.XLSB file). Rename this file PERSONAL.XLSB and copy it into your XLSTART folder (such as, C:\Users\John\AppData\Roaming\Microsoft\Excel\XLSTART on my system). You’ll suddenly find that you have a global toggle button. It loads every time Excel loads and the macros work just as you’d expect. Please let me know if you have any questions about this technique at

The Ribbon in Windows 8

Windows 8 will include the Ribbon in a lot of places that you’ve never seen it before and it appears that Microsoft eventually plans to use the Ribbon everywhere it can. For developers, this means a major reworking of applications that have been stable for a long time. For users, it means learning a new way of doing things when the user hasn’t worked with a version of Office that includes the Ribbon. A blog entry by Preston Gralla put things into perspective for me. Even if you hate the Ribbon, you’ll have to use it in Windows 8.

In my book, C# Design and Development, I discuss the need to create a reliable user interface that works for every user who uses an application. A number of changes are occurring in Windows 8 that are going to prove interesting when viewed in the perspective of the user interface—who it serves best. Earlier versions of Windows are better suited for the power user because they provide a quick method of finding precisely what you need using toolbars and menus. However, novice users are often lost and sometimes can’t accomplish the required tasks at all.

RibbonX for Dummies describes how the Ribbon can simplify the user experience and even create a workflow environment for novice users. In fact, many of the examples in that book are based on workflows. I get into some examples of the Ribbon in the latest edition of VBA for Dummies, but not at the depth found in RibbonX for Dummies. The emphasis of these examples is to help you create a usable Ribbon interface in Office. The point is that the Ribbon is a useful interface for a particular group of usersmost likely the majority of Windows users who aren’t technically savvy. Many power users that I’ve talked with still view it as cumbersome and state emphatically that it slows them down. Managers I talk with are obviously most concerned about training costs associated with moving to the Ribbon.

Because the Ribbon has taken center place in Office, I’ve written a number of blog entries about it for VBA developers. I plan to continue covering the Ribbon for Office in the VBA for Dummies category. From what I’ve been reading in Steven Sinofky’s blog posts, it appears that at least some of the information I’m providing for VBA for Dummies readers will also apply to Windows 8 developers, but it isn’t clear yet at what level. However, I’ll keep tracking Windows 8 carefully and let you know how things start working out.

In the meantime, as a developer, you should start looking at applications outside of Office that use the Ribbon successfully. For example, you’ll find a good Ribbon experience in WinZip. Working with this user interface will likely provide ideas for a Ribbon for your own applications.

Of course, as an author, I’m constantly looking for reader input. How do you feel about the Ribbon? Do you think it’ll prove cumbersome or will it be a great benefit? What questions would you like answered in a user-level book about Windows 8 when it comes to the Ribbon? What would a developer need to know about it? Let me know your viewpoint at


Creating a Custom Styles Group

A problem with some of the automation provided by Word 2010 is that you don’t always get the results you want. Even if you create a custom Ribbon configuration as described in the A Quick Method for Adding Custom Ribbon Elements post, you may not get the results you want without some experimentation. For example, you might want to add a full version of the Styles group as shown here to a custom Ribbon.


As described in my previous post, Office 2010 makes it easy to add tabs, groups, and existing or custom commands to the Ribbon. The standard practice would be to create a custom tab, Styles group within that tab, and then add the Quick Styles command to it as shown here.


The result isn’t going to be what you expected. The Custom tab will look something like this:


You don’t see any of the styles. To see them, you must click the down arrow, rather than simply view them as you would on the Home tab. No amount of configuration in Word is going to change this display. In order to get the right appearance, you must export your customizations as described in my previous post and modify the XML directly. After you export the customizations, you see XML for the Custom tab that looks like this:

<mso:tab id="mso_c1.F646E0" label="Custom" insertBeforeQ="mso:TabInsert">
   <mso:group id="mso_c3.F7999E" label="Styles" autoScale="true">
      <mso:gallery idQ="mso:QuickStylesGallery" showInRibbon="false" visible="true"/>

It’s important to note that the autoScale=”true” setting is correct and it’s something you’d need to add if you were creating this code by hand. However, the <mso:gallery> tag isn’t set up correctly right now. Unfortunately, VBA for Dummies currently suggests the answer, but doesn’t discuss it outright. My book, RibbonX for Dummies, provides better information in this case on page 151 when it describes the attributes for a gallery. In order to get the appearance you want, you need to change the code so it looks like this:

<mso:tab id="mso_c1.F646E0" label="Custom" insertBeforeQ="mso:TabInsert">
   <mso:group id="mso_c3.F7999E" label="Styles" autoScale="true">
      <mso:gallery idQ="mso:QuickStylesGallery" size="large" visible="true"/>

which means removing the showInRibbon=”false” attribute and adding a size=”large” attribute. When you make these two changes and import the updated XML into Word, you’ll see a new version of the Custom tab as shown here:


As you can see, the Custom tab now presents the Quick Styles Gallery as you’d expect. There are many situations where you need to modify the Ribbon customizations using similar techniques to get the appearance you want. If you have any questions, please contact me at


A Quick Method for Adding Custom Ribbon Elements

Everyone knows that the days of the CommandBar are gone. Sure, you can still use the CommandBar in your VBA applications, but the result is less than spectacular. All of the entries end up on the Add-Ins tab of the Ribbon. Consequently, even though the code in Listing 12-2 of VBA for Dummies still works just fine, you end up with this addition to the Add-ins tab as a result.


Even the icon is correct from the listing, so the code does indeed work, but it isn’t as nice as it could be. Of course, you could create a true Ribbon addition for your VBA application. Starting on page 266 you discover the incredibly convoluted and horribly difficult technique to add a real addition to the Ribbon in Office 2007. The results really are quite nice and you obtain the full functionality that the Ribbon provides. However, unless you have a lot of time to spend working through these steps, you’ll quickly learn to dread the entire process.

Fortunately, Office 2010 offers a middle ground approach. The results really are Ribbon-specific and you do have some flexibility in how the buttons appear, but there are still a few limitations. Let’s look at what you need to do to obtain this middle ground result. The first phase is to create the buttons you want to use with the application and export them to a file so you can modify their appearance. Uses these steps to accomplish this task.

  1. Create your macros as normal. The example uses these two very simple macros.
    Sub SayHello1()
        MsgBox "Saying Hello From SayHello1"
    End Sub
    Sub SayHello2()
        MsgBox "Saying Hello From SayHello2."
    End Sub
  2. Attach the macros to buttons using the technique shown in my “VBA in Office 2010” post. The example uses the setup shown here:
  3. Check your results. You’ll likely see something like this where the buttons are all large and not very attractively set up:
  4. Choose File > Options to display the Options dialog box. Select the Customize Ribbon option so that you can see the Ribbon configuration again.
  5. Choose Import/Export to display the import and export options. Select Export All Customizations to display a File Save dialog box where you can save the customizations to disk.
  6. Type a name for the file, such as MyCustomization.exportedUI and click Save. At this point, you have an XML file containing your customizations.

Open the file using an XML editor or even Notepad. Any text editor will do fine. For the example, I’m using Notepad to make things a bit clearer. What you’ll see inside is going to be messy because Office won’t add any carriage returns or white space to make the text easier to read. Adding these features won’t invalidate the file. Here’s the result from the example:


Most of this code isn’t important to the example, but it’s all functional. Let’s say you want to use icons that aren’t supported directly in the Options dialog box and you also want to use medium sized icons. You can make both changes quite easily now. First change the <group> element to allow custom sizing by changing the autoScale property to read autoScale=”false”. Second, change the <mso:button> elements to look like this:

<mso:button idQ="x1:Book1_SayHello1_0_16A6B4C"
            label="Say Hello 1"
<mso:button idQ="x1:Book1_SayHello2_1_16A6B4C"
            label="Say Hello 2"

Notice that the buttons are now medium sized and are using icons that aren’t normally supported by the Excel Options dialog box. To see the results of these changes, reopen the Customize Ribbon folder of the Excel Options dialog box. Choose the Import Customization File option of the Import/Export drop down. Excel will ask whether you’re sure that you want to replace the existing Ribbon and Quick Access Toolbar customizations. Click Yes and you’ll see the changes added to your Ribbon. Close the Excel Options dialog box and you’ll see something like this:


Notice that the buttons now use different icons and they’re arranged differently. You can use this approach to create a customized look to this much simpler approach for dealing with the Ribbon. Make sure you get the Office 2010 Icon Gallery or the Office 2007 Icon Gallery to obtain usable icon names to use for your applications.

Of course, there are always limitations. So far I haven’t figured out how to use other kinds of controls. For example, I can display a toggle button just fine by changing the <mso:button> element to an <mso:toggleButton> element, but the resulting control isn’t functional. With any luck, I’ll eventually figure out techniques for working around these issues, but this post is a good start. Let me know if you try this technique out and what additions you can figure out for it at You can download the example files, if desired, to see how things work.