Off the top of my head, I can come up with exactly 4 features that the N900 has going for it:

• It supports multitasking in a very usable way. Indeed multitasking becomes second nature in no time, when using the N900 on a daily basis
• Deploying applications to the N900 is a breeze. Simply compile the application and scp it on to the phone.
• Development in Qt for the N900 is not only supported, it is encouraged. Mmm… Qt. I may be biased
• A massive screen resolution.

On the other hand, the list of deficiencies is just too long to ignore:

• The worst touch screen of any device seen in the past few years. I mean, how did this ever pass alpha testing, much less make it to the assembly line? Compared to the the iPhone, the touchscreen is neither precise, nor responsive. It doesn’t support multi touch, and with the N900’s extreme screen resolution, using finger navigation is next to impossible (a link in the Maemo browser takes up around 6 square millimeters). And the stylus: well it’s just so damn 1990’s.
• Portrait mode only supported in the Phone app. This is just plain horrible: In order to use the N900 as a phone, I need to unlock the screen (in landscape mode), start the phone app (or even worse, find the phone app in the list of running apps) still in landscape mode, once the phone app starts, I need to tilt the N900 by 90 degrees because, lo and behold, does in fact support running in portrait mode.
• Next to no apps supported via the Ovi app store or apt archives. And the few apps that are actually to be found, are generally of mediocre quality. I am not going to go into details though, as it makes me depressed.
• Kinetic scrolling of virtual desktops is sluggish and clunky. Specifically I expect kinetic scrolling to continue scrolling at the speed that I choose. The N900 however clunkily falls back to default speed as soon as I lift my finger from the swiping motion. Not a bug as such, but it sure doesn’t look all that impressive.
• Syncing with my Mac involved downloading a 3rd party iSync profile from some guys web page. I realize that Apple computers isn’t the most widely used brand out there, but still…

The list goes on, but given that “I” paid close to 5000 DKK for the damn thing, I really don’t feel like continuing this rant for much longer.
Adding insult to injury, I actually gave my old iPhone to my wife, so going back isn’t even an option. Frick.

I am not going to go into details about the procedure, as it has been, well, excruciating.

Suffice it to say that I am one of the few to have had to follow courses after successfully defending my masters thesis.

Now, I’ll be over here waiting for the prince of darkness to call me up requesting by diploma back. This time around, he will have to pry it from my cold dead fingers though.

So, without further ado, a summary of online backup solution privacy goodness (again, I would like to remind you that I am not a lawyer, simply a concerned luser):

Carbonite

The Carbonite privacy policy looks a lot friendlier than Mozys. Carbonite distinguishes between two types of disclosure. Disclosing (a) your personal information, presumably your name, address, phone number, etc, and disclosing (b) your backed up data.

With regard to (a), the privacy policy contains the following:

Carbonite is committed to protecting your privacy. Carbonite will not, under any circumstances, rent, sell, or give away your Personal Information nor does Carbonite trade or exchange mailing lists with any other organization. Carbonite maintains this information; but we may disclose your Personal Information to third parties if we believe that such action is necessary to (1) comply with the law; (2) protect and defend the rights or property of Carbonite; (3) enforce the Carbonite Terms of Use Agreement.

Although slightly rubbery, I guess that is what is to be expected, so we move on to (b), to which the following quote refers:

Carbonite will not share your encrypted files with any third party unless such action is necessary to comply with a government or court order legally compelling us to do so.

That’s more like it. As I’ve mentioned before, handing over data when ordered to do so by the courts are clearly a no-brainer.

So except for the fact that Carbonite, like Mozy, is situated in the US (which during the Bush administration has become an increasingly hostile environment with respect to legal rights), there really doesn’t appear to be much cause for concern.

In summary though, Carbonite appears to be a whole lot more privacy friendly than Mozy. Moving on to IBackup.

IBackup

The Ibackup privacy policy appears somewhat more fragmented than those of Mozy and Carbonite.

It appears that the following paragraph, taken from the IBackup terms of use, defines the cases in which Carbonite chooses to share stored data with third parties:

(…) In addition, Pro Softnet may be asked to provide user data and logs as a part of a legal issue in a third party case by a court order or a subpoena, discovery request or other lawful process that may override privacy rules.

As was the case with Carbonite, IBackup pledges not to share stored data with any third parties, unless ordered to do so by the courts.

Conclusions

Both Carbonite and IBackup provide reasonable terms of use with respect to sharing data with third parties. That is, according to their respective privacy policies, stored information is only divulged under court order.

This is in contrast with Mozy Inc. which allows itself to share stored information with any third party at any time that they deem fit.

As neither of the providers publicly disclose their encryption algorithm implementation, the privacy policy/terms of use of the providers are pretty much all that users can rely on for keeping their private data private.

I must say, the Mozy client works beautifully, and the 2GB free storage plan makes it easy to test the service without spending anything except the time. It took me less than 2 minutes to download and configure the mozy client to do remote incremental backups of a few select directories on my mac book. No problems.

So there I was, pretty impressed, until I decided to ready the Mozy privacy policy. It starts with the following:

We will not sell or market the email addresses or other collected personal information of registered Users to third parties.

We will not view the files that you backup using the Service.

We may view your file system information (file extensions, sizes etc. but not your file contents) to provide technical support.

So far, so good. Further down, however, I encoutered this:

Mozy, Inc. may disclose Personal Data, including the data you back up with the Service, with or without notice (a) if required by a subpoena or other judicial or administrative order, (b) where required by law, or (c) at our sole discretion, where we deem it necessary to protect the safety of any individual or the general public or to prevent violation of our User Agreement or the rights of Mozy, Inc. or any third party.

Now, I am not a lawyer, but that seems to be in direct contradiction with the first set of statements. The way I understand is this: At our sole discretion we may violate the privacy of the data you choose to back up.

Hmm. I am not sure I like that.

Additionally, it turns out that Mozy is based in Utah in the US. Again, I am no lawyer, but from what I can tell, the US have all but abandoned the idea of due process in their precious war on terror. For all I know, any old US government agency could waltz into Mozy’s data center and make a copy of whatever data they damn well want to.

Whoops. I just uninstalled the Mozy client.

Recently I found myself wanting some kind of notification thingy, which would allow Irssi to discretely notify me when when something interesting happens on IRC. Irssi, being a console app, doesn’t really have any way of supporting this, except through the use of plugins. So, I had pretty much decided to dive back into perl and write up a simple script for irssi, utilizing the Growl for notifications by means of the Mac::Growl package.

As it turns out, someone else already did. And not only that, someone else took the time to explain in meaningful detail how to get the whole thing working. So, now I have growl notifications whenever someone sends me a private message or says my name in a channel that I have joined.

I like good software.

So, what’s good and what’s bad about Mac OS X.

The good:

• I absolutely love the tight integration between OS components. E.g. how easily bluetooth devices are configured via the user interface, how the user interface and network can be configured,  and how every hardware peripheral is instantly usable through the user interface. I can’t count the hours I have spent making these things sort of work Xubuntu/Xfce.
• Software availability is generally better on Mac OS X than is the case on Linux, especially now that I have fink working. I especially like that I am now able to use reasonably new versions of skype and google earth.
• My favorite games like Warcraft III and StarCraft work on OS X.
• Applications may be bound to a specified virtual desktop, forcing them to display there, whenever they are started.
• IPod integration is obviously very smooth.

The bad:

• Poor keyboard shortcut support for manipulating windows. There are various hacks around which use apple script to support trivial things like maximizing any window. Basically, though, native OS X support for these things suck.
•  No sloppy focus (or focus follows mouse). This is probably the biggest drawback of them all. For the life of me I cannot comprehend why people insist on clicking to give windows focus, when the same thing may be accomplished by simply moving the mouse.

More of these will probably surface when I’ve spent a bit more time with OS X.

He was born on the March 5th at 09:53 at Regionshospital Randers. Please give him a warm welcome.

Now, between diaper changes and loss of sleep, I hope to get back to work in a few days.

I was given COD4 as a going-away present by my old employer, and I’ve been playing for a few hours (in single player mode) over the last few evenings. I never was much of a first person shoorter kind of guy (except GoW), but COD4 is really quite amusing. Even completely FPS-impaired people (such as myself) get loads of kills during missions, which makes for exceptionally entertaining game play. It should be noted that the AI is reasonably sensible, and doesn’t move infantry into the open too often (This in stark contrast with GRAW, which gives new meaning of artificial stupidity). Additionally, the types of missions vary from run of the mill first person action, over stealth oriented assassination missions, to taking on the role of gunner in a gunship providing cover for an evac mission. All in all, COD4 is surprisingly amusing for a FPS.

Additionally, it is, uhm, interesting to note how bad guys® in COD4 do not all conform to the cliché middle eastern AK47-slinging “holy warrior” stereo type. For extra realism Activision chose to add a truckload of Russians with bad American accents.

Anyway, I do enjoy the game, and I am not the only one.

During a semi-recent upgrade of Drupal (before making the switch to wordpress) I accidently forgot to migrate a data directory stored in the web root. After the upgrade, as everything related to the site appeared to work according to plan, I deleted the old drupal directory, including the data that I had forgot about.

Then, a few days ago, I received an email telling me that every download (and a few other things) on the site had stopped working. Realising that I probably made a booboo, I turned to by backups (made with rdiff-backup, and withing 2 minutes I had completely recovered the most recently backed up version of the lost data. Until now I’ve been a recovery virgin. Not any more I guess.

Joel is a programmer, which means that he, unlike most UI folks, can relate to the pain of programmatically designing user interfaces. On top of that, he has a rather exceptional way of staying on topic, while making jokes about various semi-related topics.

In the following, I sum up the points made by Joel during the books’ 18 shortish chapters.

Chapters 1 and 2 discuss user and program models, That is, the way the programmer and the user sees the tasks that the program attempts to accomplish. The main points revolve around aligning the program model with the users model, which pretty much always entails keeping the program model very simple. This leads directly to chapter 3, which is appropriately titled “Choices”.

The central point of chapter 3 is to only provide the user with choices, if they are really really needed. That is, don’t ask the user questions or provide options just because someone implemented some feature that they love ever so much. Like in all other chapters, the main point is summed up in a large reading friendly font: “Every time you provide an option, you are asking the user to make a decision”. The implication clearly is that superfluous choices are bad.

Chapters 4 and 5 discuss metaphors. That is, how to use real world concepts to make the the user understand how stuff is supposed to work. The chapters basically provide a programmer friendly introduction to many of the points presented by Norman in “The design of everyday things”. It is quite useful, and makes appropriate fun of a number of well known software building organisations, for either ignoring or overdoing the use of metaphors.

Chapter 6 discusses user interface consistency, and the lack thereof. And the central point here is “Good UI designers use consistency intelligently, and though it may not show off their creativity as well, in the long run it makes users happier”. I wholeheartedly agree. In fact, it is the single most annoying user interface issue when using Unix based graphical desktop programs: They mostly have totally inconsistent behaviour, both across programs and within single programs.

Chapter 7 discusses the important distinction between usability and learnability. The discussion is based on a comparison between generations of user interfaces, starting with the basic CLI, and ending with the kind of stupid 1 page wizards at which particularly Microsoft excel.

Chapters 8, 9, 10, and 11 discuss designing for extremes. This can essentially be summed up by naming the chapter titles “People can’t read”, “People can’t control the mouse” and finally “People can’t remember”. The point that Joel is trying to make, is that designing as if these statements were true will usually result in added usability for the average user of whatever program you’re designing. The chapters are spiced up with a number of excellent examples from real world user interfaces, which really help in getting the message across.

Chapters 12 and 13 focus on designing programs for users. Be they imaginary or usability testing subjects. I didn’t find these chapters all that interesting, as Joel spends a significant portion of these chapters explaining how spontaneous usability tests with whatever non-developer person you can get your hands on are mostly just as usable as elaborate usability tests performed in an appropriately designed map, and how programmers are generally worried about going changing stuff which was included because some usability test indicated that it would be a good idea. You get most of this “for free” if you follow some of the most obvious advice provided as part of
the extreme programming principle.

Chapter 14 talks about time, and how time is important in a number of ways when designing user interfaces. It has a number of obvious points, which are not quite so obvious until you’ve actually read about them.

Chapter 15 discusses “smartness” in software. Ie. it discusses how heuristics may be used to improve the user interface, if the heuristic is chosen and implemented appropriately. As an example heuristic, take auto completion in Microsoft Word. I leave it to you decide whether you think that is appropriately implemented.

Chapter 16 is entitled “Tricks of the trade”. ’nuff said.

Chapter 17 talks about user interface design for the web. Its main point is that usability applies as much to web site design as it does to application design. Unfortunately, the book is old enough (© 2001) to not really deal with technologies like ajax. In stead Joel spends much time talking about reloading web pages at modem speeds, which is not really the relevant for a rather large number of users these days.

Chapter 18 is the obligatory “taking a step back” chapter.

All in all, I found the book entertaining and useful. I am definitely going to try to apply some of the advice provided. I do wish that Joel would have spent a bit more time discussing “power users” and their user interface design requirements. In stead he pretty much writes of command line interfaces as ancient and mostly useless (p. 76).