Editor's note: REALbasic is a popular IDE that enables programmers to create applications for Mac, Windows, and Linux platforms. Here on Mac DevCenter, we've naturally focused on software creation for the Mac. But I can see instances where it makes sense to take the work you've done and port it to Windows. (Look at what a cross-platform iTunes has done for Apple.)
When Aaron Ballman, a software engineer at REALbasic, pitched this article about using REALbasic to create apps for Windows, too, I thought this would be nice to have in our catalog. I hope you find this piece interesting, and maybe someday, helpful.
This article is designed to help 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 there. This piece isn't a primer for learning how to program, nor does it 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.
First, I want to discuss the average Windows user. I'll focus on three types of users. Although some Windows users are programmers, technical support personnel, or another type of tech-savvy users, by and large most don't know much about the actual operating system, and even less about application design. Of this group of non-geek users, there are two sub-groups--those who use computers for work, and those who use 'em at home.
Windows users at work are typically savvy enough to do things like word processing, browsing the Web, send email, and other business-related operations. They basically use applications that their IT department approves, 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 commonly 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 want to make their computing 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, allowing for some crossover, of course. Each class has a different set of expectations. Your job is to tailor your software to their requirements, because they all share one very common trait: they are inundated with applications in the Windows market. If your application doesn't work for them (for whatever reason), they'll simply throw it away and move on to the next. It's a very competitive market out there.
The user's initial reaction is very important to your product's success. So let's talk about what sort of first impression you want to give.
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 StuffIt to package the application. Windows users expect a .zip file. So always use a .zip file compressor (StuffIt does have DropZip, which works just fine). An added benefit of .zip is that is handled natively in 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.
Windows users don't install applications the way Mac users do, either. They don't consider an application to be "professional" unless it comes with an installer and an uninstaller. Some websites, like Tucows, won't even accept an entry for a Windows application that does not come with an installer. Failing to provide this 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.
|
Related Reading 
Mac OS X for Java Geeks |
Your application then won't be operating as they expected, and won't do things like put a shortcut to itself in the Start menu. 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 set up 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.
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 users knows what looks "right" and what looks "wrong."
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 Menu; the equivalent of the Finder is Windows 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 Human Interface Guidelines (HIG), 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 closely 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!
Tech-savvy users 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.
|
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 (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 also creator and type codes 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 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 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 of 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 box (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 on 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 menu bar 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 menu bar. 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 can do so on the Mac (PushButtons, for example). Windows users tend to depend on the keyboard more than Mac users, so double-check your control/tab order when testing your application on Windows.
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.
Your feedback is welcome. Please email me at:
Aaron Ballman is a software engineer at REAL Software, makers of REALbasic (a cross-platform programming language).
Return to MacDevCenter.com.
Copyright © 2009 O'Reilly Media, Inc.