Skip to main content

Targeting Windows

By Aaron Ballman

This article helps developers whose primary experience is with Macintosh or Linux to create applications to be deployed on Windows. It assumes that you have some experience using Windows, but little experience deploying applications on Windows. This article is not meant as a primer for learning how to program, and does not cover how to write your programs. Instead, it discusses things like user interface differences, usability, general user expectations and best practices for programming applications for Windows.

Let's start off by discussing the average Windows user. For the sake of our discussion, let's focus on three types of users. Although some Windows users are programmers, technical support personnel or other tech-savvy users, by-and-large, most Windows users don't know much about the actual operating system and even less about application design. Of this group of users, there are two sub-groups of people -- those who use computers for work, and those who use computers at home.

Those that use computers at work are typically savvy enough to do things like word processing, browsing the web, email and other business-related operations. They basically use applications that their IT department approves for them and they tend to work with restricted access to computing resources. They use the computer as a resource to help them do their job better.

Home users typically use their computers for web browsing, email, instant messaging and games. For them, an application is a way to communicate and have fun. They use instant messaging and email to talk to friends, browse the web for information and play games for entertainment.

People who are tech-savvy use computers to make their life easier. They use instant messaging because it's easier than phone calls. They browse the web to learn about new tech topics. They understand a lot more about the computer they're using than almost every home and business user out there.

As I said before, most people fall into one of these categories. Of course, there are people who cross into more than one of these neat little boxes, but these are the typical classes of Windows users. Each class has a different set of expectations and your job is to tailor to their requirements because they all share one very common trait: they are inundated with applications in the Windows market to meet their needs. If your application doesn't work for them (for whatever reason), they'll simply throw it away and move on to the next application. It's a very competitive market and it's tough to get noticed.

First Impressions Are Always Important
Keeping your user's needs in mind is very important, as the user's initial reaction is very important to your product's success. Because the Windows market is so competitive, there are all kinds of software solutions out there that may perform the same or similar function as yours. Since there's almost always another program (at least!) for Windows that can do the same thing, the first impression you leave with the user is critical. So let's talk about what sort of first impression you want to give.

Compressing Your Download File
On the Mac, users are used to the practice of downloading a file, unstuffing it, and using it immediately. Even applications they purchase on a CD work this way. For Windows users, a .sit file is foreign to them, so don't use Stuff-It to package the application. Windows users expect a .zip file. So always use a ".zip" file compressor (Stuff-It does have DropZip, which works just fine). An added benefit of .zip is that is handled natively on Windows XP. Also, just about every Windows machine you'll ever see has a copy of WinZip installed. This is the delivery format that every Windows user expects. If you use a file format other than ".zip", you run the risk that the user will not be able to open the file. If the user downloads the file and can't open it with something, then it will get tossed in the trash and your user will move on.

Installing Your Application on Windows
Windows users don't install applications the way Mac users do. Windows users do not consider an application to be professional unless it comes with an installer and an uninstaller. Some web sites, like Tucows, won't even accept an entry for a Windows application that does not come with an installer. Failing to provide the installer means that most users won't know how to install your application and most likely won't use it. They might launch your application expecting it to be the installer. Your application then won't be operating as they expected and won't do things like put a shortcut to itself in the Start bar. Failing to have an uninstaller is just considered bad form and can lead to a poor user experience. Installers are a crucial thing in the Windows market since they give your application a professional feel from the start and make users comfortable with using your product.

Not only do installers provide a good first look for your application, they provide you with a handy way to properly place files where they need to be. When an application is installed on Windows, it goes into a special "Program Files" folder by default (although the user may select another location for it). But this folder can be in different places depending upon the version of Windows you're dealing with and how your user has customized their computing environment. For example, the "Program Files" folder may be on a different drive than the C:\ drive. The installer abstracts this issue from you and will automatically let the user choose where to install your application (and it'll default to the "Program Files" folder). It also lets you install support files to their proper locations, as well as setup any registry values or other configuration files. Basically, an installer is a great way to set up the initial state of your application with minimal burden on the end-user. The other benefit is that an installer implies that there will be an uninstaller, so the user feels safer using your application since they know that if it starts behaving badly, they will be able to easily remove it. There are a lot of good installer applications out there that will let you package your application properly. One of the most popular ones is InstallShield, though there are certainly other installers available on Windows.

User Experience Differences
Once your application has been installed, it's time for more first impressions (as if the impression of getting the product and installing it weren't enough to worry about!). Many Windows users have never seen a Mac application and couldn't tell you what one looks like, much less be able to point at your application and say "this looks like a Mac port". However, just like Mac users, most Windows user knows what looks "right" and what looks "wrong" on their computer.

Unlike Mac users, they're not so picky about things like being one pixel too close to the window border. But they'll spot an application that doesn't look native from a mile away and will just assume it's inferior software. To this end, test your application on a few different versions of Windows to make sure things look like other Windows applications. Don't use terms like "Windoze" or "Wintel" in your product (even in the documentation). When discussing features, make sure you use the Windows version of terms. Help Tags or Balloon Help are called Tool Tips on Windows; the Windows equivalent to the Dock is the Start Bar; the equivalent of the Finder is the Explorer, and so on. If you slip up once, chances are no one will notice. But if you write your application from a Mac-centric point of view, Windows users will notice that doesn't feel native and may not use it.

Another big difference between Windows and Mac users is that Mac users are far more likely to tell you what they find wrong with your application. It's very rare that you'll have a Windows user give you this information. So if you do get an email from a Windows user with suggestions, it's pretty safe to assume that there's a whole bunch of people who walked away without providing feedback for exactly the same reasons. One mistake many Mac users make is assuming that anything goes in terms of UI design for Windows, or that if it looks good on Mac, chances are it will look good on Windows. This type of thinking can get you in trouble. Just like Apple has its HIG (Human Interface Guidelines), Microsoft also has its Windows User Experience documentation (which is listed in the resources section at the end of this article). This document provides great detail on what the expected Windows user experience should be. Try to follow it as much as possible if you are serious about providing Windows software.

Between the packaging of your application and the UI, you should be able to appease the majority of Windows users. The home and work users will judge your application mostly on the look and feel of your application (as well as whether the application meets their needs, obviously) and not scratch too much deeper than that. You may only care about how the average user perceives your product, but you should still take into consideration how the tech-savvy users rate you. They may be in the minority of Windows users, but they're the people who make recommendations about what products to use and what to stay away from. They're also the most discerning of the bunch! They tend to take deeper looks to make sure you stay with the Windows "best practices" and will jump all over your for failing to follow them. The sort of things that these users will catch you on is failing to use the Registry properly (or failing to use it at all in the case of preferences files), permissions issues, where support files are located and so forth. Most of the things that these users will catch are things that should be transparent to the end-user and mostly won't affect how your application works. But it's always a good thing to follow the best practices laid out for your target operating system.

Best Practices for Windows Applications
What are best practices for Windows software? Well, the best way to see what Microsoft considers a best practice for anything is to go to MSDN online, found at http://msdn.microsoft.com, and search for "best practices." You'll get plenty of information as you comb through the results of that search. In addition, here's a list of "under the hood" and some common cosmetic things that you might want to keep in mind (in no particular order).

  • Don't take over file type associations for public media without user intervention. For example, don't register your application to handle the ".txt" extension. On the Mac, there are file extensions, but there are creator and type codes as well to help identify which application should open up what file. On Windows, there's only the extension; and only one application may be registered for an extension at a time. So taking over a public media extension is not acceptable unless you ask the user in advance because you could be hijacking it from another application.
  • Be sure to register private file type extensions with your application. If your application is the only one that can read a particular file type, then you should associate your application with that extension. For example, if you write a piece of software to manipulate data files that only your application can read, then you should pick an extension that is not already being used (check http://www.wotsit.org or the MIME extensions on a newer Windows machine) and associate your application with that extension. Try not use an extension that's already being used.
  • Try to stay away from preferences files and instead use the Registry. Flat file preferences are a pain in multi-user settings since you need a place to store each user's preferences file. But the Registry handles this automatically for you by giving you access to a specific location to store data for the current user, also known as the CURRENT_USER hive. If you need to store data for all the users of a machine, you can store those preferences in another special registry location called the LOCAL_MACHINE hive.
  • Try to avoid Multiple Document Interface (or MDI) applications as much as possible. Obviously, there are very good reasons to use an MDI interface such as applications which display multiple related pieces of information in separate windows (like a graphics editor). But if you find yourself wanting one simply so that you can have a global menu bar that all the windows have access to, then chances are you're using MDI for the wrong reasons. Most Windows users dislike MDI applications because they take up too much screen real estate, they don't work well with multiple monitors, and they can be unsightly. Even if you think a MDI application might make sense, try to redesign your user interface to avoid using one; MDI should only be used as a last resort.
  • Be wary of permissions issues. If your application is meant to be used in a non-administrative way, then develop and test your application on a user account with limited privileges. This ensures that your application will run for all Windows users, regardless of whether they have limited permissions or not. You can always enable (or disable) features based on user privileges at runtime. Try to avoid forcing users to run your application as an admin if at all possible.
  • Play well with other applications. If you find yourself thinking of different hacks to steal focus or other non-standard ideas, please reconsider. There's almost never a good reason to mess with another application that is running. Aside from it being very difficult to tell whether the other application is running, the code will always be fragile and will most likely be annoying or confusing to the end user.
  • On Windows, the OK button is on the left, and the Cancel button is on the right. This is opposite of the way the Mac does things. In the case of a three button dialog (such as the standard, OK/Cancel/Apply, the third button always goes on the right (after Cancel). An example of the button ordering can be seen in these print dialogs from both operating systems, as shown below.
  • Make sure your menu names and shortcuts are correct. For example, use "Exit" on Windows, not "Quit." Also, most menu items have mnemonic accelerators (the single character that's underlined), as well as specific shortcut keys. Some common ones are listed in the Windows User Experience web page. Be certain to have keyboard mnemonics for every menu item, and always try to use the standard keyboard shortcut and mnemonics whenever possible. Watch out for conflicting mnemonics and keyboard shortcuts.
  • Do not place files in the user's System directory or the Windows directory unless you're doing so from an installer. Aside from the permissions issues that you will run into, this is something that's considered bad form and can lead to damaging the user's computer. For example, if you were to overwrite User32.dll on a Windows XP machine with the User32.dll from a Windows 95 machine, bad things will happen.
  • Do not "call home" via the network to do things like serial number checks without making it very explicit with what you're doing (unless your application is networked). Unexpected network traffic may display alerts on the user's system if the user has a software firewall, or may cause their computer to dial-up unexpectedly.
  • Be sure to make use of the multiple menubar support that Windows allows you. On the Mac, you only have one global menu bar, but on Windows, each window in your application can have its own menu bar. You can use this to help you stay away from MDI applications in some instances, and will generally provide for a better user experience when implemented properly.
  • Windows users are accustomed to having lots of functions available via contextual menus. They should be contextual (meaning that if you're over a button, you get a menu for the button, but if you're over an EditField, you should get a menu for the EditField). Most commands that are accessible via a contextual menu should also be accessible via the menubar. Notice the contextual menu used by Windows Explorer:
  • Make sure your control order is correct. The control order determines the tab order between controls. Tab ordering should flow from the top of the page downward, and from left to right. If the tab order skips all over the place, this breaks the flow of people's work. Control order is even more important on Windows because more controls can get the focus than do so on the Mac (PushButtons for example). Windows users tend to depend on the keyboard more than Mac users do so double-check your control/tab order when testing your application on Windows.

Summary
Like most other computers users, the first thing Windows users will do is check out your website to download your product. So make sure you have a professional looking website with Windows screenshots and terminology to instill confidence in the user. Next, they'll download your product and try to unzip it. They expect it to be in a zip format (not .sit, .sitx, .tar.gz, etc) and will probably think twice if it's just a regular executable file. They'll expect to extract an installer from the zip file that they can just double click to run, or download the installer directly. Try to use a standard installer when possible since it will comfort the user (since they'll have seen the installer before). After all that, they'll launch your application, and assuming it has a proper Windows look and feel as well as doing whatever it's designed to do, you will have gone a long way towards developing trust with Windows users.

Finally, here's a list of resources you may be interested in checking out for more information:

Windows Resources: Installers: Software Sites:
  • http://www.download.com is one of the most widely accepted places to post your software for download software in the Windows world.
  • Another common site is http://www.tucows.com, though is frequented less than download.com.

Your feedback is welcome. Please email me at: aaron@realsoftware.com