1. DETERMINING THE USER WINDOWS 7 COMFORT LEVEL
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.
NOTE
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.
2. CONSIDERING WHETHER TO MOVE
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.
3. MOVING YOUR APPLICATIONS TO WINDOWS 7
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 (http://en.wikipedia.org/wiki/Agile_software_development), 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 (http://msdn.microsoft.com/library/w0x726c2.aspx),
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.
