Having a computer program communicate with the user in a clear, understandable and consistent way is a non-trivial problem to solve. In the Mac world, the Apple Human Interface Guidelines can help us a long way in presenting information in a format that is familiar for a Mac user. At the same time, a user may expect products from F-Secure to behave similarly across operating systems - an expectation that sometimes conflicts with our desire to fit into the environment. The Technology Preview of F-Secure Mac Protection shares a lot of UI elements with the similarly recent Internet Security Technology Preview for Windows.

Another obstacle is the position our user interface should take with regards of the surrounding environment. The kind of applications we typically develop usually do not require much user interaction - indeed, we even want to minimize user interaction whenever we can, since we don’t want to bother the user without good cause. A user probably expects a prominent notification when our product find malware on the disk, but is not that interested in a regular database update (they come several times per day on Windows platforms). At the same time, the user wants to be sure that the application is actually performing as expected.

In the Mac Protection Technology Preview, we went the way of not displaying any user interface elements at all unless the user explicitly launches our UI, or our on-access scanner has detected malware. We essentially treat the on-access scanning as a system service, that is always running in the background, invisible to the user. If the user is curious whether it is working correctly or not, he or she can launch the user interface from the Applications folder. However, it is clear from the feedback that some users have different expectations - there is a need of telling the user “yes, the product is installed and working OK” in a non-intrusive and lightweight manner.

In the Linux Security products, we have accomplished this with two small programs; one for KDE and one for GNOME, both fitting into the respective environment. In Windows, there is a system tray icon visible giving that kind of feedback. On Mac, the place to give such information is not as clear-cut. There has been considerable discussion about this in our team, and clearly our Technology Preview testers have some thoughts about this too (and, by the way, the feedback we’ve got from our Mac Protection Technology Preview is over-the-top awesome - we are really blessed with such enthusiastic and knowledgeable testers!).

In OS X, I personally feel that the Dock should be reserved for applications that the user interacts with on a regular basis. In an ideal situation, a user should not have to interact with our application in their day-to-day work - only in the rare event that malware is found or during installation/uninstallation et cetera should the user need to bring up our user interface. But as our feedback tells us, if there is no Dock icon visible, how is the user supposed to know that the product is running and functioning properly? One element of the Mac OS X Aqua UI is the “menu bar extras” that sit in the upper-right corner of a Mac, and in some ways it resembles the system tray in Windows. Some applications make their own menu bar extras, but this is strictly reserved for use by Apple according to the Human Interface Guidelines - so we would like to avoid it if possible. But what is there then left for us to use that could be very visible but at the same time non-intrusive? Some users seem to like the idea of having our application icon in the Dock all the time. Right now, we close the UI completely when the last window exits. This is consistent with the Apple guidelines, even though they give plenty of room for interpretation:

In most cases, applications that are not document-based should quit when the main window is closed. For Example, System Preferences quits if the user closes the window. If an application continues to perform some function when the main window is closed, however, it may be appropriate to leave it running when the main window is closed. For example, iTunes continues to play when the user closes the main window.

The way I see it, our user interface is like the Apple System Preferences in that its main purpose is to control the behavior of system services. However, I understand that one could argue that, like iTunes, since our products still perform some function even after the user has closed all its Windows, it should still remain active in the Dock. The upside of that approach would be that we could use the Dock icon to represent the status of the product.

We’re happy to receive any and all opinions our readers may have on this subject - please send them along to . And once again, thanks a million for the feedback we’ve already got - it is extremely useful in guiding us in the right direction as we take one step at a time towards a better user experience.

Last year, when we were writing a series of posts titled ”Stuff that works” (part 1, part 2, part 3, part 4), we were using a home-grown set of shell scripts to automatically build our software. Initially the scripts were run from cron every night, then later every hour and even later the script was triggered for every commit.

The autobuilder script worked, but we were missing features like IRC notifications, triggering builds from a web page and IRC and statistics. We would also have liked to have a history of builds combined with the test results of every build.

We were already setting up a MySQL database for builds and test results when we discovered that Continuous Integration is actually a hot topic these days and there is plenty of software available to help you with it. We eventually decided on software called Hudson.

Hudson is open source software and it is under active development by a large and growing community.
Hudson is written in Java and packaged so it can be set up easily and quickly. Basically you download the hudson.war file and run it: java -jar hudson.war

That’s it! Then you point your browser to port 8080 on that host and you have a pretty Web UI for setting up, managing and monitoring of various build jobs.

In a nutshell a job consists of following steps:

Poll a version control repository for changes.

Check out the source to a workspace directory.

Execute a build script.

Archive build results from workspace (or build artifacts like Hudson calls them.)

(Optional) pick up test results from XML files in workspace.

Each build of each job has a nice web page showing if the build was successful, when it was run and how long it took. The build artifacts can be downloaded from the same page and you can also inspect the test results.
You can configure a job to trigger one or more other jobs. For example, when the job that builds F-Secure Mac Protection finishes successfully, we have set it to trigger 2 other jobs: Installtest and Smoketest.

A job does not have to build software. Hudson does not care what the build script does. The build script in Installtest downloads the last successful build artifact from the job that launched it and installs it on a Mac mini running on a side table in the corner of the team room. Then it makes couple of simple checks and uninstalls the software. The result of this run is recorded in an XML file in the JUnit format. When the build script exists successfully, Hudson reads the XML file and stores the test results.

Hudson executes the Installtest parallel with the Smoketest job. Smoketest takes much longer to run (about 7-8 minutes), which is why we have the Installtest to provide us fast feedback in case we break something. Smoketest is similar to Installtest, except it runs many more tests.

We have also a number of other jobs, which are triggered by the Smoketest: Fulltest (runs all the tests taking about an hour), Upgradetest (runs upgrade from previous version and all tests from fulltest) and Performancetest (runs a set of common user tasks, measuring the time it takes.)

As you see, it is a good practice to split long jobs into multiple smaller jobs that run quicker. The quicker a job runs, the faster you get to know if you broke something and the faster you can fix it.

Hudson also has a whole lot of plugins that can be used to enhance and extend the basic functionality. There are plugins for supporting most of the popular version control systems and plugins to analyze source code and create reports and lots more. (And there is a plugin for IRC too.)

If you are doing continuous integration you could do a lot worse than use Hudson to help you. I definitely recommend you check it out.

The team hit a major milestone last week: technology preview of F-Secure Mac Protection.

The team is now called ”Mac & Linux team” and we’re taking care of all F-Secure Linux software and also the new Mac software. Mac OS X is, after all, a UNIX system under the pretty user interface.

We are considering whether we should post also Mac-related articles here on the Linux blog or not. We love Linux as much as we love the Mac, but maybe our readers are only interested in one or other. Please tell us what you think by email to