The Place of Automation in the User Interface

There was a time that a developer could rely on users to possess a certain level of technical acumen. That’s no longer the case. Most of the people using a device containing a CPU today (I’m including PCs, laptops, tablets, and smartphones here) don’t know anything about how it works and they don’t care to know either. All these people know is that they really must have access to their app. (Some don’t even realize the role data plays in making the app work.) The app can perform myriad tasks—everything from keeping track of the calories they’ve eaten to maintaining the scheduled events for the day. Devices that contain CPUs have become the irreplaceable partner for many people and these devices must work without much concern on the part of the user. In short, the device must provide a superior level of automation or the user simply won’t know how to interact with it.

I was recently watching television and saw a commercial for a Weight Watchers app for mobile devices. In the commercial, a woman exclaims wonder about the new programs that Weight Watchers provides, which include this app for her mobile devices. To track her calories, she simply points her phone at the box containing whatever food she plans to eat and the app tracks the calories for her. The interesting part is that there is no data entry required. As technology continues to progress, you can expect to see more apps of this type. People really don’t want to know anything about your app, how it works, or the cool code you put into it. They want to use the app without thinking about it at all.

Of all the parts of a device that must be automated, the user interface is most important and also the most difficult to create. Users really don’t want to have to think about the interface. Their focus is on the task that the app performs for them. In fact, some e-mails I’ve received recently about my Windows 8 book have driven home the idea that the app must simply work without any thought at all. It’s because of these e-mails (and those for other books I’ve written) that I wrote the article entitled, “Designing Apps with Automation in Mind.” This article points out the essential behaviors that applications must exhibit today to be successful.

On the other side of the fence, I continue to encounter an “old world” philosophy on the part of developers that applications should pack as much as possible into a small space—users will eventually figure out the complexity of the interface provided. Unfortunately, as users become more vocal in requiring IT to meet their demands, these approaches to the user interface will lose out. The next app is a click away and if it does the job of automating the interface better, your app will lose out. Even if there isn’t another app to use, the user will simply ignore the app you’ve provided. The user will rely on an older version or simply not interact with the app if there is no older version. Many organizations have found out the hard way that attempting to force users to interact with an app is bound to fail.

The fact is, to be successful today, a developer must be part psychologist, part graphics artist, and part programming genius. Creating an acceptable interface is no longer good enough, especially when people want to access the same app from more than one device. The interface must be simple, must work well, and must automate as much of the input as possible for the user or it simply won’t succeed. Let me know your thoughts about user interface automation at John@JohnMuellerBooks.com.

 

Installing and Managing Third Party Products

Most of my books make recommendations about third party products that you can use to enhance your computing experience. Each of these products is tested during the writing process, but without any of the add-on applications that may come with the product. For example, if I test a Windows enhancement product, I don’t test the toolbar that comes with that product. So, it’s important to realize that the advice you obtain in the book doesn’t include those add-on features.

However, it’s important to take a step back at this point and discuss why the product includes an add-on in the first place. Just like you, the product vendor has bills to pay and must obtain money from somewhere to pay them. An important concept to remember when working with computers is that free doesn’t exist. Typically, product vendors who offer free products will do so by paying for them in one of these ways:

  • Advertisements: Advertising comes in many forms, not just banner ads. Marketing types constantly come up with new ways to advertise products and induce you to buy them. A developer can obtain payment from advertisements in several ways, such as referral fees.
  • Product Add-ons: A developer can provide the means to install other products with the product that you’re installing. The company who provides the additional product sponsors the free product that you’re using.
  • Marketing Agreements: The application collects information about you and your system when you install it and the developer sells this information to marketing companies.
  • Value-added Products: The free product that you’re using is just a sample of some other product that the developer provides. If you like the free product, the developer is hoping that you’ll eventually purchase the full-fledged product.
  • Government Grants: A developer creates a product after obtaining a grant from the government. You pay for the product through your taxes.
  • Sponsorship: A larger company supports a developer’s work to determine whether the idea is marketable or simply the seed of something the larger company can develop later. You pay for the product through higher prices when you buy something from the larger company.

There are other methods that developers use to get paid for their work, but the bottom line is that they get paid. Whenever you see free, your mind should say, “This product doesn’t cost money, but there is some other price.” You need to decide whether you’re willing to pay the price the developer is asking. In the case of a government grant, you’ve already paid the price.

When you install a free product, you must watch the installation routine carefully. In almost every case, you must opt out of installing add-on products that the free product supports. So, you have to read every screen carefully because these opt-out check boxes are usually small and hard to see. The developer really isn’t pulling a fast one—just trying to earn a living. Make sure you clear any check boxes you see for installing add-on products if you don’t want that product on your machine. The reason I don’t discuss these check boxes in my books is that they change constantly. Even if I were to tell you about the check boxes that appeared at the time I installed the free product, your experience is bound to be different.

Of course, you might accidentally install one of these add-ons, an add-on that you really didn’t want. In this case, you must locate the product in the list of products installed on your system, such as the Programs and Features applet of the Control Panel for Windows users. The product name won’t be straightforward, but a little research will help you find it. Simply uninstall the add-on product. However, it’s always better to avoid installing something you don’t want to begin with, rather than remove it later, because few applications uninstall cleanly (even those from larger vendors such as Microsoft).

Unfortunately, there isn’t much I can do to help you when you install an add-on product. I do have some experience with the third party product in my book, but I won’t know anything about the add-on product. You need to contact the developer of the third party product to ask for advice in removing it from your system. This may seem like I’m passing the buck, but the truth is that the add-on products change all the time and there simply isn’t any way I can keep up with them all. When in doubt, don’t install a product, rather than being sorry you installed it later. Let me know your thoughts on third party products at John@JohnMuellerBooks.com.

 

Interesting Additions to the Dummies Site

I’ve written a number of Dummies books over the years so I check on the Dummies site regularly to see what sorts of things the publisher is currently offering. Of course, there are always new books to read in a broad range of categories. Sometimes I like to browse just to see some of the interesting topics people have come up with over the years. For example, there is a book specifically for Yorkshire Terrier owners named, “Yorkshire Terriers for Dummies.” I keep hoping to find a Dummies book on Border Collies, but so far, no one has taken up the topic. Perhaps I’ll suggest such a book in the future since we work quite a bit with that particular breed. Keeping up with the wide range of books makes it a little easier for me to recommend books to my readers when they ask and I sometimes get a new idea or two simply by browsing through the topics pursued by others.

There are a couple new additions to the Dummies site that you might find interesting. First, if you really want a tee-shirt, coffee mug, or key chain (amongst other items) to show your love for Dummies products, you can get them at For Dummies Merchandise. I was a bit surprised to find that the site doesn’t offer hats at the moment, but perhaps that will change in the future.

Second, if you’ve ever wanted to create your own Dummies book, you can at least generate the cover now at The Official For Dummies Cover Generator. What you’ll get is a novelty cover that includes your title, bullet points, and art. Personally, I found some of the sample covers hysterical, so it’s worth a look even if you don’t intend to generate a cover. You’ll find titles such as Training Your Cat to Play Fetch for Dummies. Interestingly enough, our cat Smucker does, in fact, play fetch. So that particular cover caught my eye immediately.

The point behind these offerings is to have a bit fun with Dummies products. Even though the books cover serious topics, they’ve always done it is in a fun way, which is one of the reasons I’ve enjoyed writing for them so much. Let me know about your favorite Dummies site addition at John@JohnMuellerBooks.com.

 

.NET Framework Version Error When Installing Visual Studio 2012

I received a few messages from readers recently asking about an error message they receive when trying to install the release version of Visual Studio 2012 on their Windows 8 system (I imagine that the same error will occur when installing on Windows Server 2012, but no one has contacted me about it). The error says that Visual Studio 2012 can’t install because the version of the .NET Framework 4.5 is wrong.

Unfortunately, the error message isn’t very helpful. You can’t install a new version of the .NET Framework 4.5 over the top of the existing installation. In addition, you can’t uninstall the old version and then install the new version because Windows 8 requires the .NET Framework 4.5 for certain operating system elements. In short, there isn’t any apparent way to fix the problem.

The issue will go away at some point because it originates as a conflict between the Windows 8 version and the Visual Studio 2012 requirements. Every reader who has had this problem is using a non-released version of Windows 8 (normally the RC version). You can’t install the release version of Visual Studio 2012 on a non-release version of Windows 8. I’m assuming that the same error occurs if you try to install a release version of Visual Studio 2012 on a non-release version of Windows Server 2012, but I’d like to hear if anyone has tried this out at John@JohnMuellerBooks.com.

What concerns me about this particular error is that it’s one time where Microsoft could have (and probably should have) come up with a substantially better error message or provided some sort of Knowledge Base article on the topic. As far as I know, there isn’t any such article and developers are currently having to rely on community support to fix this problem. It isn’t the first time Microsoft has left developers wondering. If you ever encounter this sort of problem, please let me know about it. If I can confirm the issue, I’ll put together a blog entry about it to get the word out to others in order to save them a bit of time.

 

Using Appropriate Application Testers

It doesn’t matter what sort of application you’re creating—every application requires testing by an appropriate audience. Even VBA applications, such as those described in VBA for Dummies, require testing. I wrote about this topic in C# Design and Development, but it applies to all developers equally. The application stakeholders need to be involved in every phase of application development, but most especially in the testing phase. You may obtain stellar results when testing your application using a select group of users, but the real world is much harsher. Users come in all shapes and sizes and your application must accommodate them all.

One of the most critical groups to include in your testing environment are those with special needs. I wrote about this group in Accessibility for Everybody: Understanding the Section 508 Accessibility Requirements. It’s important to understand that our aging population makes testing for this group critical. I think that Microsoft’s statistics are low, but you can read about how Microsoft has improved the accessibility features in Windows 8 in Enabling Accessibility to accommodate all groups, especially the elderly. However, you also need to include less skilled users, those with a lot of skills, but little computer knowledge, and those who are quite technically savvy, but want to get their work done quickly. In short, your stakeholders should include someone from each group of users in your organization. (The smart development team creates a list of these groups before the application is underway in order to start obtaining input from them as early as possible.)

Someone recently wrote me to say that he applauds my efforts to encourage developers to write better applications. The reader went on to say that I didn’t have any idea of just how hard the real world could be though and that actually implementing even a subset of my ideas would be incredibly hard. In short, the idea of accommodating everyone who will use an application is simply not possible in today’s environment. The problem with this attitude is that not accommodating user needs actually ends up costing an organization more in the long run.

It’s essential to understand that applications can be well-written and yet not serve the needs of the people using them. You can create a fabulous application that no one uses quite easily. When I say that testing must involved appropriate application testers, it means that these testers must represent all groups who will actually use the application and that you must accept all sorts of input from these users. The input may require that you rework the user interface or that you fix certain bugs. In some cases, you may even need to remove features because the stakeholders will never use it and the feature simply ends up confusing everyone. Applications that don’t address the needs of the users will cost your organization time and money in the following ways.

 

  • Users have a choice about applications today and they will simply ignore your application to use something that meets their needs better.
  • Whenever users become confused, they call support, which ends up costing your company both time and money.
  • Support calls take time and your user isn’t being productive while talking with support.
  • Even when the user is able to use the application, the accumulation of errors tends to slow the user down and increase the time required to perform a task.
  • Confused users tend to try combinations of things in frustration, which often results in data loss and other unfortunate consequences.


Part of the problem with the corporate atmosphere today is that management applies considerable pressure to get an application in production as quickly as possible. A developer can become quite tempted to use a group of “yes man” testers to show management that the application is ready for use, when it really isn’t even close. The theory is that it’s much easier to ask forgiveness for a poor design later, than to ask for additional time today. However, savvy developers know that it’s easier to change an application design than to apply fixes to an application that’s already hosted on a production system. The bottom line is that you always need to test with the appropriate group and create an application that really will do the job.

What are your worst experiences with application testing environments? How do you choose the testers you rely on to check your applications? Let me know at John@JohnMuellerBooks.com.

 

Thinking Through Indentation and IDE Automation

I’ve been asked a number of times about code indentation in my books by publishers, editors, and readers alike, so I thought it might be a good idea to talk about the matter in a blog post. It’s important to indent your code to help make the code more readable—to help make the flow of your code easier to see. Each indentation represents another code level. The application is at one level, classes at another, methods within the class at another, loops within a method at still another, and so on. By viewing the various levels of code within an application, you see an outline of application functionality and can better understand how each application element works. Because indentation is so important to the understanding of code, I spend considerable time working through indentation in my books so that you can better understand the examples I present.

Indentation is there for the developer to use as an aid to understanding. A few early computer languages, such as COBOL, were positional and depended on coding elements appearing in certain positions on each line. Most languages today don’t require that you use any sort of indentation. In fact, more than a few languages would let you write the entire application on a single line without any indentation at all (as long as you supplied a space between statements and expressions as needed). The compiler doesn’t care whether you indent using spaces or tabs, whether there are three or four spaces per indent, or whether you provide an indent for continued lines. The fact is that all of these characteristics are controlled by the developer to meet the developer’s needs.

Modern IDEs make it easy to indent your code as needed by performing the task automatically in some cases. For example, given an example of a Java method, you could begin by typing:

public void MyProc()
{

The moment you press Enter after the curly bracket (}), most IDEs will add an indented line and a closing curly bracket. Your cursor will end up on the indented line, ready for you to type a statement. You see something like this in your IDE:

public void MyProc()
{
 
}

The developer hasn’t done anything so far to provide indentations for the code, yet the code is already indented. Let’s say you create a variable like this:

boolean MyVar = true;

You then type a statement like this:

if (MyVar == true)

It’s at this point where some IDEs continue to provide an automatic indent and others don’t. For example, if I press Enter at the end of this line in Eclipse, the IDE automatically indents the next line for me. However, when I’m working with CodeBlocks, pressing Enter leaves the code at the same indention level as before. Neither approach is wrong or right—simply different. If I were to add a curly bracket on the next line to hold multiple lines of code within a block, CodeBlocks will already have the cursor in the right position and Eclipse will have to outdent the curly bracket to position it correctly.

Let’s say that this if statement has just one line of code following it, so I don’t use a curly bracket. When working with Eclipse, the cursor is already at the correct position and I simply type the next statement. However, when working with CodeBlocks, I must now press Tab in order to indent the line of code to show that this line (and only this line) is associated with the if statement. In this case, the example simply outputs a statement telling the value of MyVar like this.

System.out.println("MyVar == true");

Pressing Enter automatically outdents the line when using Eclipse because the next statement is automatically at the same level as the if statement. However, when working with CodeBlocks, I must press the Backspace to outdent the line manually. The resulting method could end up looking like this:

void MyProc()
{
    boolean MyVar = true;
    if (MyVar == true)
        System.out.println("MyVar == true");
     
}

Of course, a good developer will add some comments to this code as a reminder of what task the code performs and why the developer chose this particular technique to perform the task. The point of this post is that indentation is an essential part of working with most languages in order to make the resulting application easier to understand.

A final thought on IDEs is that most of them make it possible to configure the editor to indent or not indent to meet the requirements of your organization or personal tasks. IDEs commonly allow the use of tabs or spaces for indents (spaces are better when you want to write documentation). You can also choose the right amount of indentation (three spaces is optimal for books where space is limited). Let me know your thoughts on indentation and how you use it at John@JohnMuellerBooks.com.

 

Source Code Support

Sometimes I need to make really tough decisions.  It isn’t a matter of wanting to make the decision—the need to make the decision is thrust upon me. The topic of this post is source code support in the form of reader uploads. The topic of just how far I need to support book source code has come up before in conversations with readers. For example, in the Source Code Download Issues post, I discuss problems that readers have had in obtaining source code for my books in the past. The issue addressed in this post is files that are removed from archive (.ZIP) files by applications such as firewalls. In some rare cases, files are missing from the download and the reader looks to me to solve the problem. A few readers have gone so far as to say that I really need to provide CDs with the source code on them and mail those disks out free of charge as part of supporting the book. Unfortunately, supporting the books in this way is well beyond my ability. I could easily go bankrupt providing this level of support.

Up until now, I’ve been willing to send source code to a reader who needs it using e-mail unless the book is on my unsupported list. This past month has been especially hectic with reader requests for source code uploads (well over a hundred of them). In some cases, the books in question are ten or more years old, which means I must look the book up in my archives and determine whether the source code is even available. Once I make that determination, I copy the source from the archive and send it to the reader in one or more e-mails. Some of the source code files are 20 MB or so in size and many reader e-mail accounts won’t accept a file that size, so I have to break the file down into pieces and send multiple e-mails to the reader—a time-consuming and error prone task. This past week I went through several problematic uploads and finally gave up trying to support the reader in a number of cases. Nothing I would do would allow the reader to receive the file using e-mail.

I’ve thought about making the source available on my Web site, but that approach hasn’t worked well in the past because readers will often complain they can’t find the source or that the source on the Web site is corrupted (or any number of other issues). Of course, there are also costs associated with online storage for source code for 89 books. After a lot of thought, I have decided that trying to support a book’s source code in this manner won’t work either.

With this in mind, I’ve decided that you’ll need to rely on the publisher’s site for downloading any source code associated with a book, unless the publisher provides a CD for the book. If there is a source code CD, then you need to follow the procedure described in my Obtaining Replacements for Broken Media post to obtain a new CD. I didn’t come to this decision easily because I prefer to provide the fullest possible level of support for my books whenever possible. The issue is the time required to provide the support. On some days it has gotten to the point where a good part of my day is spent looking for resources that readers need and not getting much else accomplished.

When a publisher decides that it’s no longer feasible to provide download support for a book, the source code for that book will become unavailable. In fact, I’ll likely add the book to my unsupported list. It wasn’t an easy decision, but I had to make it because the e-mail support has gotten to the point of affecting the support I can provide to readers for other needs. Please let me know about any concerns you have about this new policy at John@JohnMuellerBooks.com. If someone has a really good solution for this problem—one in which I can provide long term source code support without incurring huge monetary or time issues, I’ll provide an updated post. Thank you for your continued support of my books.

 

Sending Comments on My Books

I regularly receive a stack of e-mail about my books. Readers question everything and it makes me happy to see that they’re reviewing my books so closely. It means that I’m accomplishing my principle goal, helping you understand computers in every possible way so that you can be more productive and accomplish tasks with less effort. When I make something easier for someone and they tell me about it, the grin extends from one side of my face to another. It really makes my day.

Some readers are still asking me if it’s OK to send me comments. I definitely want to see any constructive comment that you have. Anything that helps me understand your needs better or corrects errors in my writing makes it possible for me to write better books. As I mentioned in my Contact Me, Please!, I really do want to hear from you. The main element that I need to obtain a usable comment is that it’s constructive. A comment that says, “This book really stinks!” doesn’t tell me anything. Here are some of the things you can do to create a constructive comment:

 

  • What book are you reading?
  • Which page contains the error?
  • What do you view as an error on that page?
  • How would you fix the error?
  • What sort of system are you running?
  • Are you using the correct version of the software (the same version that appears in the book)?
  • When did you encounter the problem?


The more information you provide, the easier it is for me to understand the issue and provide you with feedback. In many cases, I’ll upload the fix to my blog so that everyone can benefit from the response (so be sure you keep an eye on my blog for new entries). I work hard to ensure that my books are as error free as possible, but everyone makes mistakes. Also remember that sometimes mitigating factors, such as differences in software versions or anticipated hardware, make it appear that there is an error in the book when you’re really looking at a different in environment. Help me provide you with better books—send me comments!

There are a few things that I won’t do for you. I won’t help you pass an exam at school. Your learning experience is important to me, which means that I want you to continue your education by working through the instruction on your own. I also don’t provide free consulting. This means I won’t check the code that you created on your own for errors. I’ll help you with any book-specific question, but I draw the line at that point. Let me know if you have any input or insights on my books at John@JohnMuellerBooks.com.

 

Examining the Calculator in Windows 7

Almost every book I write on programming has some element of application design in it. If you don’t create applications with a great design, users are less likely to use them. I examine general design issues in C# Design and Development. However, books like C++ All-In-One Desk Reference For Dummies, LINQ for Dummies, Professional IronPython, Start Here! Learn Microsoft Visual C# 2010 Programming, and Web Matrix Developer’s Guide all have design elements in them because I feel application design is extremely important. Even RibbonX for Dummies and VBA for Dummies have design discussions in them because they both talk about user interfaces. The most specialized book I’ve created about application design is Accessibility for Everybody: Understanding the Section 508 Accessibility Requirements, which discusses user interface requirements for those with special needs. All of these books have one thing in common, they all try to quantify what makes for good user design. They all ask the question, “How can you as a developer write an application that users will enjoy using and use efficiently?” Unfortunately, examples of poor design abound and seem to be more common as time goes on, which is the point of this post.

The Calculator application in Windows 7 is a perfect example of an application that has gone the wrong direction when it comes to the user interface. Sure, the Standard view is the same in both cases as shown here.

Calculator02 Calculator01

The Windows 95 version of Calculator is on the left and the Windows 7 version is on the right. As you can see, the buttons are the same, but someone at Microsoft felt obliged to rearrange them, just to make things difficult for anyone used to using the old version of Calculator. There isn’t a good reason for the change except to change for change’s sake. The Windows 7 version does have larger numbers, but at the expense of providing room for larger calculations. Personally, I’d prefer the Windows 95 version because sometimes I do need to perform really large calculations. Both versions of Calculator offer features such as digit grouping, so there isn’t any change here either. In short, Windows 7 offers less capability in a rearranged format that makes it hard for people who are used to the old version of Calculator to use it—breaking the rules of good design.

The problems get worse, unfortunately. I never used the Standard view of Calculator because I need to perform programmer math and scientific calculations relatively often. Switching to Scientific view in the Windows 95 version of Calculator, you see the perfect interface as shown here.

Calculator03

During the time I worked with Windows 95, I never switched out of this view. All I did was start Calculator whenever I needed it and did the math that I needed to do. Never once did the view I was in enter my mind. That’s great design! Users shouldn’t have to think about how your application works—the user’s only thought should be how to get work done.

The Windows 7 version of Calculator now has four modes: Standard, Scientific, Programmer, and Statistics. Every time I use Calculator now, I must first figure out what I want to do and change the view appropriately—wasting time and effort in the process. The views unnecessarily limit my options. For example, look at the Programmer view.

Calculator04

I do gain access to the RoL (rotate left) and RoR (rotate right) buttons, but I can’t think of when I’ll need them. The modern languages that most developers use don’t actually require these buttons. If I were using assembler, they could see some use, but I don’t remember ever using rotate left or rotate right with C#, Visual Basic (any version), Python, or even C++. So, these buttons are extraneous and only serve to complicate the interface. In addition, I do gain a bit display, which could prove helpful at some point, but I found that the Bin view on the old version of Calculator worked just fine and served my needs well. However, notice that the decimal point button is disabled. The loss of this button means that every time I have to perform any sort of math with a decimal point, I have to switch to another view. Programmers do use floating point numbers! So, a capable programmer calculator has been replaced with something less useful—something that makes me irritable and work harder.

Now let’s switch to Scientific view. Remember, I used to be able to do everything in one view. If I want to raise a value to a power now as part of checking application output, I have to switch to the Scientific view shown here.

Calculator05

As usual, someone felt that it was absolutely required to move the buttons around so that it takes a while to relearn how to use this view. For the most part, I don’t use any of the new features provided by this view. The few times I needed to use this feature with the old Calculator required a switch to Standard view, but the switches were seldom indeed. The Scientific view does include a number of additional features, all of which are likely helpful to someone, but the cost is one of having to switch views when you need to do something else.

Before someone writes to tell me that the new calculator has square root, cubed root, and root to any power buttons, the Windows 95 Calculator has these features as well. You just had to know how to use a calculator to understand them. Let’s say you want to find the cubed root of 27 using the Windows 95 Calculator. Simply type 27, check Inv, and click the x^3 button. You’ll see the cubed root answer of 3. Not convinced? OK, let’s try a quad root. Type 16, check Inv, and click the x^y button. Now, type 4 (the quad root) and press the = button. You’ll see the quad root of 16 is 2, which is the correct answer. The Windows 7 calculator adds nothing new in this regard—just more buttons to hunt and peck!

In short, the new Calculator is an example of a failed interface update. Most people will find that they have to constantly switch between views to get anything done. When you force people to think too much about the interface, they tend to get grumpy, less productive, and end up tossing out the application at some point. Personally, every since  I found the Windows 95 version of Calculator runs just fine on my Windows 7 system, I’ve been using it instead of the broken product Microsoft has offered. The Windows 95 version truly is the superior application. Let me know your thoughts on Calculator and on application design in general at John@JohnMuellerBooks.com.

 

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 John@JohnMuellerBooks.com.