Targeting Windows (too) for Your REALbasic Appsby Aaron Ballman
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.
First Impressions Are Important
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.
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 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.
Installing Your Application on Windows
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.
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.
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 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.
Pages: 1, 2