[General Topics] Menneisyys:
History, copy / paste, logging group: in this group, I've elaborated on how a given client supports text selection and copy to the clipboard (copy / paste), whether it supports logging discussions to a file in the local file system and whether the links (for example, Web links) are clickable.

With IM clients where Web links aren’t clickable, you can still copy them to the clipboard – if the client supports text selection and clipboard copy, that is – and, then, paste the URL manually to the address bar of a Windows Mobile Web browser.

Also, if your client doesn't support logging, you can still use copy/paste to copy the contents of your discussion to the clipboard and, from there, to a file. This is, however, far from automatic and also depends on whether copy / paste is supported at all.

Protocol-specific group: in here, I’ve elaborated on what services the given client supports and how it works with them; does it have specific bugs with them and so on.

New message notification; suspended modegroup: if you plan to use your IM application mostly for receiving messages, you’ll really want to scrutinize what has been stated in these tests.

in-program, if multitabs are utilized, are they colored?: While you’re actively chatting with a contact or browsing the user list and a(nother) contact sends you a message, what does happen? As most user interfaces are tabulated (using multiple tabs; that is, multitabs), I’ve mostly concentrated on whether you can see at once who has sent the new message to you; one of the most commonly used ways of doing this is making the tab – which contains the chat session with the given buddy - red.

Suspended mode usable on Windows Mobile phones?: this is one of the most important rows. If you do plan to use an IM app to be able to receive messages the entire day, you can only achieve this if you suspend your Windows Mobile phone to greatly reduce its power consumption. This should be a major deciding factor when you plan to select an IM application.

Not all applications are suspending-friendly; a most important example of these is PocketICQ. Fortunately, all the other non-disqualified IM apps support operating in suspended state; so can, as far as IRC clients are concerned, wmIRC.

What notification settings / capabilities are used?: if you do plan to rely on the audio / vibration notification capabilities of an IM client, you will want to choose one that supports preferably both if you often rely on vibration (which is available in all Windows Mobile phones).

Unfortunately, vibration isn't necessarily supported in all IM applications. As a rule of thumb, applications that rely on the system-level Sounds and Notifications settings applet to set the type of their notifications don't have problems with vibration either. Applications that don't rely on the system-level settings won't necessarily support vibration (albeit some do - for example, wmIRC or mChat / gsICQ).

A quick note for developers of applications: it's actually very easy to add system-level notification support to any application - it's just a question of adding some registry keys.

Today plug-in: several IM applications also have a Today plug-in so that you can always see whether they're online and whether there are any new messages / buddies around. Please consult the individual chart cells to find out how each Today plug-in behaves.

Misc: CPU usage while listening to incoming messages with all the possible networks logged in?: particularly with waiting for incoming messages for more than a few minutes, the processor (CPU) usage of the given IM application becomes of interest (unless the messaging is SMS-based because, then, the mobile only wakes up and starts executing your IM application when there's an incoming instant messaging-related SMS). The less CPU usage, the better. Fortunately, almost all IM applications have negligible CPU usage; the only exception is WebMessenger, which has a bit higher CPU usage, resulting in a bit (not much!) reduced battery life.

Doc quality?: in here, I've explained whether the on/offline application documentation is verbose and comprehensive enough. I've also linked in the online documentation, whenever available, to make your life easier.

Conference (MSN: Action / Invite a contact to join this conversation; ICQ: Start a multi chat icon; Yahoo: Action / Invite to a conference; Google Talk and AIM, as of now, don’t allow for group chat): many IM services support "conferencing" or "group chatting". In here, I've examined how the WM IM clients support this.

As can clearly be seen, if you need groupchat support on WM, go for either Jabber and imov Messenger Enterprise (this is the ideal solution for the Jabber-based enterprise with groupchat needs) or MSN / Live Messenger. The latter two are the only MSN clients to offer seamless groupchat support. Finally, of course, you can always use the venerable IRC clients for groupchat.

Flags?: in cases, you won't want to show your contacts you're ready to talk. That is, you will want to modify your presence information. In here, I've elaborated on what states (flags) you can choose from.

Note that I haven't elaborated on the auto-away flag because none of the clients set the state to "Away" automatically, unlike on the desktop. This is, of course, understandable as you most probably always have your Windows Mobile device with you, ready to be reached , even when you're otherwise away from your desktop computer.

Mobile flag?: some (not all!) services also support showing a flag like "the user is using a mobile device". You may want to prefer a client that does support this flag so that you can effectively show your party you won't be able to type as fast as on a desktop computer because of the non-existing or, at least, far smaller / more awkward hardware keyboard. Unfortunately, very few clients support this.

Unicode support?: while most services (except for some really old ones; for example, IRC) do support (16-bit) Unicode characters, not all client products support these (unlike on the desktop). Note that, while Unicode may not be supported, as with IRC, you can still switch 8-bit codepages in most clients. That is, if you both use a 8-bit char page (for example, Cyrillic, Central-European, Turkish etc), you can still use all your national, non-Western characters even with clients not supporting Unicode. It's only real Unicode communication (with languages that, because of the huge number of their characters, can't use a 256-character 8-bit page) that's impossible with these IM clients.

Note that I've tested Unicode transfer in both directions because it's possible Unicode characters will only be transferred (and rendered) in one direction but not in the opposite one.

SOCKS proxy support?: in here, I've elaborated on the Socks (and, to a lesser degree - unfortunately, less clients support HTTP clients, even when almost all the messaging protocols support it -, HTTP) proxy support. When not used in the enterprise, you most probably don't need the support for this; however, if you do have a local firewall blocking all non-standard remote ports (for example, those of IRC), unless you have a Socks and/or HTTP proxy-capable client, you won't be able to communicate.

Multiple logins with more than one account to the same network?: while some desktop clients (for example, IRC) allow for multi-logins using the same client (or an independently started instance), this isn't the case with Windows Mobile ones.

I haven't listed the ability to log in using the same account but on different devices. Protocol-level support for this would be really nice (see for example the section "MPOP and presence by observation" here) but, alas, not all protocols support this. The two most important ones that do are Jabber and AIM. With these protocols, you can log in from your mobile device, which not (necessarily) will result in your already logged-in instance to be logged out.

... and to different networks?: multi-service clients (there are several of them - all the reviewed IM clients, except for PocketICQ, gsICQ and IRC) are able to make use of all the supported services by logging into them at the same time - just like Gaim or Trillian on the desktop.

Offline (non-mail) messages?: some IM clients support the underlying feature of delayed message delivery in almost all current services. (Exceptions are IRC, if you don't use an add-on messaging service and at least older versions of Skype are the only notable exceptions; see the "Asynchronous message relaying" column here.) Unfortunately, not all - in here, I've elaborated on which client supports this and which doesn't.