9/17/2012 3:16:43 AM


Developers are constantly amazed that users don't really care about their applications. After all, the developer has put an enormous amount of effort into creating the application to meet user needs. Unfortunately for the developer's ego, what users care about is getting their work done, going home, and doing something (anything) other than work. If you try to move your application without considering the user's comfort level, the move is almost certainly doomed to failure. The following sections describe some issues you must consider before moving to Windows 7.

1.1. Defining Usage Requirements

There's always something wrong with an application — something it fails to do or something it doesn't do quite right. Ask any five users what they feel is wrong with the application, and you'll receive five different answers. The users aren't being contrary. Humans tend to perceive things differently from each other, so it's no wonder that every user will have a different list of things that are wrong with an application. No matter how contrary your users may seem, addressing these perceived application deficiencies is important if you want to perform an upgrade properly. You can group common imperfections into the following categories:

  • Common problems: Some applications have a common problem — one that everyone complains about. Perhaps it's how the application handles printing or saves data. In most cases, common problems are high priority because solving them has the potential to offer the greatest return in user satisfaction and efficiency. Some developers will write off these kinds of problems as not being worth fixing, but any common problem requires at least some consideration.

  • Innovative uses: Users work with the application every day and often see ways to make the application more efficient — ways that would never occur to the developer. Even if the user doesn't know precisely how to present or implement an innovative feature, the developer should take time to work with the user and iron out innovative details when the feature truly presents a good application addition.

  • New requirements: Everything grows and changes, including companies. As a company grows, the requirements for the applications it uses also change. It's important to differentiate between short-term and long-term changes, however, and make application updates that reflect long-term needs. Otherwise, you may find yourself removing the new feature a short time after you add it.

  • Antiquated functionality: Museums love antiques, users don't. It's important to remove old features that users no longer require because these features often get in the way and make the user less efficient. In addition, older features can increase training costs and reduce application performance (reliability, speed, and security).

One problem with most requirement listings is that the authors tend to focus on the negative. In some cases, an upgrade can actually reduce user satisfaction by changing a feature that users really like. When defining usage requirements, you should consider asking users to define as many positive features for an application as negative features. Promoting a look at the positive will help users see the application as the complex undertaking it is and reduce failure potential by helping others see the upgrade as doable. Here are some common ways to group application strengths:

  • Easy keyboard usage: It's amazing to see some users bang away at an application. The developer could never do things that quickly, even though the developer understands the inner workings of the application better. Most high-speed users rely on the keyboard — the mouse is way too slow. Any developer who changes the familiar keyboard combinations is likely to be hanged by bands of hostile users.

  • Reliable operation: Users may not use the term "reliable" precisely, but a feeling of reliability is what you want to hear in the feedback. Make sure you understand the user's definition of reliable. For one user, reliable might mean that the application never breaks, but for another user it might mean that the application works consistently (even if it does break from time to time). Reliable application operation, no matter what form it takes, is always desirable because it makes the user happy, reduces support costs, and enhances user productivity.

  • Innocuous security: Most users hate security because it gets in the way of accomplishing the task. Even entering a name and password is too much for some users. Anything that tends to keep the user from getting work done is unnecessary from the user's perspective. The best kind of security is the security that the user can't see, but that still keeps the data and user safe from harm. Upgrades should never disturb a security feature that already works well.

  • Feels peppy: From the user perspective, speed is relative. It's possible to improve actual application speed, yet make it feel slower to the user. When this situation occurs, the developer says the application is faster, yet the user balks at the change the developer has made. It's important that applications feel fast to the user, even if the application isn't actually as fast as you could make it.

  • Understandable: What's understandable to the developer probably isn't to the user. Most developers can simply look at interfaces and understand how they work because developers spend so much time creating them. A typical user doesn't spend any more time learning an interface than absolutely necessary because interfaces don't accomplish work. If a group of users tells you that they truly understand something, keep it in place because an understandable interface is truly rare.

1.2. Considering Training Requirements

Training costs money. It sounds like a simple statement, but many developers don't take training into account. If you make a change to an application that requires additional user training, then the only way to make that update pay for itself is to make the user more efficient, productive, or reliable. In short, the company must gain something of value from the training time other than simply showing the user how to work with a new application feature. New isn't better unless it results in a tangible benefit, which usually means something you can put a dollar value on. In fact, some companies are now asking the developer to provide an estimate of how long it will take the new feature to pay for itself. If a new feature lets a user work twice as fast, then it will eventually pay for the cost of the upgrade, plus the cost of the training required to get the user up to speed.

When you consider training costs, you must also evaluate support requirements. Some users won't really attend training sessions, not even if you physically tie them up and drag them to the room where the training takes place (yes, the body is there, but the mind isn't). In some cases, users will simply think about the barbecue they're having this weekend or the next presentation they must make. They'll think of anything but the new feature you're trying to tell them about because they simply don't care about your application. As a result, the user is likely to call support for help with the new feature, usually five minutes after the training session that told how to use the new feature. You must add some amount of money into your estimate for support costs in addition to the training costs.

Even though you may not consider application help as part of training, it is. Every time the user accesses help, the help file presents a lesson that the user relies upon to perform a task. There is no physical teacher present, but the lesson that a help file writer has prepared is present. If the lessons the help file teaches don't match the application, then the user won't receive the required training and the costs of hiring someone to perform the training in person increase. Because a help file is an inexpensive means of training a user to perform certain tasks, updating the help file should be a priority for your team. Help files can't replace human trainers in many situations, but a great help file can significantly reduce training costs by freeing trainers to provide lessons on difficult or complex tasks.


The easiest way to keep support costs down is to have interested users involved in the upgrade process. Even if a user's participation is limited to e-mail conversations about new features that the user would like to see, you'll get some feedback that makes the user feel like part of the process. With luck, users will tell you whether a feature works well for them and will perform other tasks as well (such as testing). In addition, users trained during the upgrade process will provide assistance to users who begin using the application after you move it to production. Try to have users from every area of the organization involved in the process. Use interested users, rather than dragging users into the process kicking and screaming. This gets better feedback and ensures that the users actually do use the upgrade as you've created it.

1.3. Keeping the User Happy

The bottom-line consideration for many updates is keeping the user happy, no matter what your other goals might be. It's certainly important to meet organizational goals and keep the application updated, but an application that doesn't receive some level of user approval won't work because the user won't use it. Some organizations have created absolutely amazing applications that never met any of the goals expected of them because users ended up using other applications that they liked better (or they simply sidestepped using the application at all). Most applications replace some process that's already in place, so the user always has the option of continuing to use the original process. Here are some techniques you can use to keep the user happy:

  • Ask the user's opinion.

  • Get user feedback as you create the update.

  • Keep users informed about application progress in a way that excites them about it.

  • Explain why certain updates are required and get user input on alternative implementations when necessary.

  • Involve the user in testing the update.


There's little doubt that your organization will make the move to Windows 7 at some point, unless you decide to wait for Windows 8 (a definitely risky procedure, considering that Microsoft has dropped support for Windows XP). The point is that if you're using Windows XP today, you'll be using a newer version of Windows sometime in the near future. However, moving to a new version of Windows doesn't necessarily mean that an application will make the move or that you'll use new Windows features as the result of an upgrade. Your strategy might be to create a compatible environment for the existing application while you write a new application specifically designed for Windows 7. It's important to come up with a strategy that works best for your organization. The following sections discuss some Windows 7-specific issues you should consider before (and while) you make the move.

2.1. Testing Issues in Your Application

Before you can formulate an update strategy, you need to know about the update challenges. Most developers will realize the need for testing immediately and begin working on a test suite to check the application. However, you must perform your tests under controlled conditions or the results you obtain will be suspect or misleading. For example, testing the application using a development account won't tell you anything because developers aren't commonly users. In order to test the application, you must create a realistic user account and use it for testing purposes. In fact, you need to create a list of user categories and test the application once for each category. A manager account could produce errors that a manufacturing user would never see. Here are some Windows 7 issues to consider as you test:

  • User interface: The Aero Glass interface presents some challenges to the developer. For example, one developer relied on title bar hints to convey information to the user — these hints no longer worked in Windows 7. You need to check everything from icons to controls when performing your test. Don't assume that any element of the interface will work as intended, because Windows 7 definitely presents some surprises.

  • Accessibility: Users with special needs shouldn't have any concerns when moving to Windows 7, but it pays to check. For example, your application may no longer size correctly when the user relies on a large font, or it may not look right when the user switches to one of the high-contrast themes. Make sure all the accessibility features still work as anticipated.

  • Security: As the Internet has become less secure, and devious people have become more adept, Windows has had to become more secure. Some Windows 7 security is almost invisible, but other forms of security will definitely impede user progress. It's important to update your application to produce as little visible security as possible to keep users from simply ignoring it.

  • Resource access: As part of the security update and because of some driver differences, you can't assume that your application will have the same access to resources it had when working with Windows XP. Make sure you check access to every type of resource as part of the testing process.

  • 64-bit compatibility: Your application may behave differently in the 64-bit environment than it does in the 32-bit one. It's important to test the application in both environments because Windows 7 is definitely headed toward 64-bit computer usage.

  • Help functionality: One of the features that developers commonly fail to test (or test fully) is the Help system. Microsoft has made more than a few changes in Help over the years. In fact, some versions of Help that worked fine in Windows 95 and marginally in Windows XP won't work at all in Windows 7. Make sure you test the Help system for your application completely — both direct help and context-sensitive help.

  • Driver or hardware incompatibility: Drivers and hardware support are less of an issue in Windows 7 than for upgrades such as Vista. Even so, Windows 7 relies on a new driver model, and users are bound to have new kinds of hardware attached to their systems. Consequently, you must test your application to ensure it works well in the new environment.

After developer testing is over, you need to create another test suite. In this case, you use the results of the developer testing to create a test procedure for real-world users. Make sure you have at least one user for each user category, or the test results won't be complete. Users work differently with applications than developers do. Consequently, users will likely find problems that a developer would never find, simply because the user lacks knowledge the developer has and the developer lacks knowledge the user has. For example, the developer might not realize that the user normally orders several parts together because one part is useless without the other. The combination of part orders could trigger an error that the developer would never see, but the user will always see because the user always orders the parts together.

2.2. Defining the Advantages of Moving to Windows 7

Part of your Windows 7 application update strategy will probably involve using some new controls. Most developers will swoon over the new controls in Windows 7, but most users won't notice until you point them out, and then they're likely to say something like, "So what?" Features such as Jump Lists will definitely make applications easier to use, but don't expect users to get too excited about them. Instead of focusing on the control, what you really need to do is focus on how the control will accomplish work faster or with greater ease. In fact, it's probably a waste of time even to mention the control name. When users do react positively to the ways in which the new controls will help them, you can use their input to define how you plan to use Windows 7 features to your advantage.

Some new Windows 7 features won't require any input from users unless you use the feature in a way that will attract user notice. For example, you can easily add new security features to your application, and as long as the security is invisible (or nearly so) you probably won't need to mention it to the user. In fact, when it comes to security, the less the user knows, the better. The same holds true for parallel programming and other features the user won't normally see. In general, the less the user knows about these hidden features, the better. Sometimes, a simple mention of one of these background features will elicit negative feedback; even when the change isn't noticeable, some users will claim to see a negative effect.

Whether you use some new feature, such as the Ribbon, depends on how you plan to change the application. A new application could certainly use the Ribbon to good effect. However, based on the continued grousing by power users about the Ribbon in Office, it might be a good idea to avoid such a prominent change in your own application unless you truly love a good battle.

Whatever new features you plan to use, your strategy should define some tangible reason for using it. In most cases, a monetary return is the easiest reason to sell and the easiest to prove after you complete the project. However, whenever you can demonstrate a security, reliability, or speed improvement, management is likely to approve the change. Defining a change as simply looking nice will never prove successful. Even if management approves the change, you'll likely find that the user gripes later, placing you in the position of having to remove the change or trying to sell the user on it as well.

2.3. Working with Windows XP Mode

You may decide not to move your application to Windows 7 at all. In this case, you can use Windows XP Mode to make it appear to the application that it still resides on a Windows XP machine. However, don't be fooled. The application is still running on a virtual machine with several additional layers between it and the resources it needs. You must test your application to ensure it actually works in Windows XP Mode.

Your users probably won't know how to work with a virtual machine. In addition to testing the application, you must determine how to configure user support for the new environment. It's important to consider training and support costs as part of the Windows XP Mode update. These are going to be a lot less than the cost of updating your application, but you still have to consider them as part of your determination of whether it's viable to update your application or not. In some cases, the costs of using Windows XP Mode may persuade you to make the update after all.


You must consider the skills of your development team and have a great software design in place. Make sure you rely on a solid development methodology, such as Agile (, to help ensure project success. C# Design and Development, by John Paul Mueller, Wrox 2009, provides the details you need to create a useful software design for your upgrade.

Windows 7 development doesn't require use of the .NET Framework 4.0 (, but it certainly helps to use the updated features that this new version of the .NET Framework provides. You'll want to spend some time considering use of the .NET Framework 4.0 as part of your upgrade process. In addition to making it easier to use new Windows 7 features, the .NET Framework 4.0 includes a number of patches, enhanced security, and other features you'll want to use when creating your new or updated application.

  •  Windows Server 2008 and Windows Vista : Group Policy Processing Events (part 2) - Foreground Group Policy Processing
  •  Windows Server 2008 and Windows Vista : Group Policy Processing Events (part 1) - Background GPO Policy Processing
  •  Kyocera Mita FS-C5150DN
  •  MSI Power Edition GeForce GTX 670
  •  Transcend's SATA III SSD720 - Safer Data
  •  Asus HD7970 - A Card For Enthusiasts, By Enthusiasts.
  •  Printers : Can't Live With Them, Can't Live Without Them (Part 1)
  •  Printers: Can't Live With Them, Can't Live Without Them (Part 2)
  •  Setting Up Multiple Accounts With OS X Lion
  •  Data Storage Considerations (Part 1)
  •  Data Storage Considerations (Part 2)
  •  Asus Ultrabook N56VM - In More Ways Than One
  •  Asus ZenBook Prime UX21A - Small, Light And Extremely Sleek
  •  Microsoft Windows Server 2003 : Maintaining the Operating System - Administering Software Licenses
  •  Monitoring Microsoft Windows Server 2003 : Using the WMI Event Logging Provider
  •  Windows 7 : Add the Built-in Administrator Account to the Login Screen, Stop Entering Password on Lockout, Using Credential Manager
  •  Windows 7 : Sharing and Securing with User Accounts - Creating a Password Reset Disk, Running Programs as Administrator
  •  A Cost Effective Printer?
  •  Get More Out Of Windows 7 (Part 4)
  •  Get More Out Of Windows 7 (Part 3)
    Top 10
    Windows Vista : Installing and Running Applications - Launching Applications
    Windows Vista : Installing and Running Applications - Applications and the Registry, Understanding Application Compatibility
    Windows Vista : Installing and Running Applications - Practicing Safe Setups
    Windows Server 2003 : Domain Name System - Command-Line Utilities
    Microsoft .NET : Design Principles and Patterns - From Principles to Patterns (part 2)
    Microsoft .NET : Design Principles and Patterns - From Principles to Patterns (part 1)
    Brother MFC-J4510DW - An Innovative All-In-One A3 Printer
    Computer Planet I7 Extreme Gaming PC
    All We Need To Know About Green Computing (Part 4)
    All We Need To Know About Green Computing (Part 3)
    Most View
    Troubleshooting Reference: Printers
    Booting on HP 9000 Servers (part 2) - The setboot Command, Boot Console Handler (BCH) and Processor Dependent Code (PDC)
    SQL Server 2005 : Dynamic T-SQL - Supporting Optional Parameters (part 4) - sp_executesql: A Better EXECUTE
    Programming the iPhone User : UX Anti-Patterns - Memory Lapse
    BenQ XL2420T : Holy Swivelling Monitor!
    OLED Technology Casts A Spell On Big Screen TV
    Best Of The Year 2012 (Part 3)
    Active Directory Domain Services 2008 : Block & Remove Block Inheritance of Group Policy Objects, Change the Order of Group Policy Object Links
    Group Policy Basics : Creating Additional GPOs
    Windows 7 : Getting Help and Giving Others Assistance
    BizTalk 2006 : Managing Exceptions in Orchestrations (part 3) - Running the EAIProcess
    Web Security : Attacking AJAX - Observing Live AJAX Requests
    The Ubuntu Server Project (Part 2) - Web access
    SQL Server 2008 : Explaining Advanced Query Techniques - Controlling Execution Plans (part 1)
    Building Your First Windows Phone 7 Application (part 2) - Using Your First Windows Phone Silverlight Controls
    Windows Server 2008 : Active Directory Federation Services
    Home Security On A Budget (Part 2)
    Which MacBook Is Right For You (Part 3)
    SQL Server 2005 : Working with SQL Server Management Objects in Visual Studio (part 2) - Retrieving Server Settings
    IIS 7.0 : Managing Application Pools (part 2) - Managing Application Pool Identities