Best practices: 6 AIR features that may annoy your users

Posted by on Dec 17, 2008 in AIR, Best practices, How-to, Popular | 18 comments

I get to see and play with a lot of really cool AIR applications (even when they’re still being developed). Every now and then I come across an app that totally ignores any best practices or usability rules. AIR provides developers with a lot of features that could potentially annoy users if not used wisely. I thought it was a good idea to write this article. I’m not saying you shouldn’t use these features, I just want you to think about them before you add them to your application.

  1. Launching your application on login

    NativeApplication.nativeApplication.startAtLogin = true;

    That’s all it takes to have your application launch whenever your user logs in to his account on his computer. However, if this is something that you set automatically without telling the user about it, you may find your application to be uninstalled faster than it was installed. There really is no reason why you should set this automatically. You can also set this on runtime. So why not ask the user if he wants to launch your application on login when he first launches the app? And why not provide a small preferences panel that allows the user to easily change this setting?

  2. Always in front

    NativeWindow.alwaysInFront = true;

    Again, very easy to do and in some cases it totally makes sense to have an application stay on top but it should be the user’s decision and not yours.

  3. Automatically setting the filetype

    NativeApplication.nativeApplication.setAsDefaultApplication("mp3");

    Imagine you’re building an application that can play MP3 files. Are you sure you want to automatically open your application whenever the user clicks on an MP3 file? This is also one of those things you may want to check first and we provide all the methods to do so.
    When you first launch your application, you can first check if your application is already set as the default for this filetype.

    NativeApplication.nativeApplication.isSetAsDefaultApplication("mp3");

    If it’s not, check which application is the default for the filetype you want to use.

    NativeApplication.nativeApplication.getDefaultApplication("mp3");

    This returns the path to the application registered as the default app for this filetype. You can then ask the user something like: “Hey I see you play MP3-files with QuickTime but I can also play these files. Can I set myself as the default application?”.

    Since you already added a prefs panel for setting the launch on login and always in front preferences, you can also add this one. To remove your application as the default for a specific filetype, just call:

    NativeApplication.nativeApplication.removeAsDefaultApplication("mp3");

  4. Full screen applications

    I think there are only a couple of valid use cases for full screen applications (not the fullscreen displaystate but just taking over the entire screen with the exception of the menu bar). The obvious ones are video and kiosk applications. If your application fits in this category or you think taking over the entire screen is totally acceptable for your app, please do make sure that you add close and minimize buttons. If quitting your application is the only way to quickly check an email, the user may never return to your app.

  5. Custom chrome

    This is actually related to #4. If you are making an application that has custom chrome, you should always add the standard close, minimize and maximize buttons. Everyone is used to having these in an application window so make sure you don’t forget to add them. These are the methods to call whenever one of these buttons gets clicked.

    NativeWindow.close();
NativeWindow.minimize();
NativeWindow.maximize();

    You should also be aware that because of the way custom chrome is rendered on a user’s machine, an application with custom chrome can take a performance hit.

  6. Self signed applications

    What is “Joe The Plumber” going to do when he sees 2 red icons in the installation screen of the app he’s trying to install? As a rule, no AIR application should be publicly launched without being signed with a code signing certificate. We are aware of the fact that individuals can’t get these certificates anywhere right now and this is something that we are working on. Individuals can get a code signing certificate from Chosen Security. However, for companies, it’s really easy to get a cert.

I hope these “rules” will help you build better applications. I’m sure some of you can think of other rules developers should think about, so feel free to add them to the comments if you know of any.