This is a comparison of the usability of Empathy and Pidgin (as suggested in DesktopTeam/Meeting/2008-08-07), to help in deciding which should be used in Ubuntu Intrepid Ibex.
Test performed by Matthew Paul Thomas from 11~20 August 2008, with empathy 2.23.6-0ubuntu2 and pidgin 1:2.4.3-ubuntu1 on Intrepid Ibex alpha 3.
Wherever the wiki page says "()", it needs a link to a bug report. I have not yet had time to report them all as bugs.
Access and installation
In the Applications menu, Empathy had the tooltip “Send and receive instant messages”, and Pidgin had the slightly geekier “Send instant messages over multiple protocols”. In both cases, this is slightly missing the point: sending and receiving instant messages are the means by which you chat with people, not ends in themselves. (And in Empathy, you can have voice or video chats without sending or receiving instant messages at all.) A better tooltip would be “Chat with people on AIM, Google Talk, MSN, Jabber”... etc.
Empathy appeared in “Applications” > “Internet” as “Empathy Instant Messenger” with an icon of two blue blobs. Clicking the status icon in the panel also revealed or hid the Contact List.
Pidgin appeared in “Applications” > “Internet” as “Pidgin Internet Messenger”, with a purple bird icon. Clicking the status icon in the panel also revealed or hid the Buddy List.
Whichever program is chosen will be installed by default, so the package description matters more for whichever program is not chosen. However, the description still appears in Add/Remove Programs’ “Installed applications only” view. And for both programs, the description presented in Add/Remove Programs is quite user-hostile.
In Empathy (inappropriate sections underlined): (LP 259788)
Empathy Instant Messenger
High-level library and user-interface for Telepathy
Empathy consists of a rich set of reusable instant messaging widgets, and a
GNOME client using those widgets. It uses Telepathy and Nokia's Mission
Control, and reuses Gossip's UI. The main goal is to permit desktop
integration by providing libempathy and libempathy-gtk libraries.
libempathy-gtk is a set of powerful widgets that can be embeded [sic] into any
This packet contains the empathy IM application and account manager.
And in Pidgin (inappropriate sections underlined): (LP 259793)
Pidgin Internet Messenger
graphicalmulti-protocol instant messaging clientfor X
Pidgin is a graphical, modularInstant Messaging client capable of using
AIM/ICQ, Yahoo!, MSN, IRC, Jabber, Napster, Zephyr, Gadu-Gadu, Bonjour,
Groupwise, Sametime, SILC, and SIMPLE all at once.
Some extra packages are recommended to use the core functionality present
in most pidgin installations:
More extra packages are suggested to use increased functionality:
gnome-panel | kicker | docker:
To use the system tray icon functionality (minimizing to an icon, having
the icon blink when there are new messages, etc.)
For interfacing with an Evolution address book
To use Contact Availability Prediction plugin
How easy is it to:
- set up my existing Yahoo, Google Talk, AIM, and Jabber accounts?
- create a new Jabber account?
connect to Freenode IRC with automatic NickServ identification?
- connect to Canonical IRC with SSL and authentication?
On first launching Empathy, nothing appeared to happen: a non-expert might easily think that the program doesn’t work at all. A small grey square appeared in the notification area, but it took me a while to notice. (fixed in trunk)
Clicking the grey square opened an empty “Contact List” window, with an “Accounts” window over top of it. The window said: “To add a new account, you can click on the 'Add' button and a new entry will be created for you to start configuring.” This made it unclear how to set up an existing account, why the “Add” button hadn’t clicked itself, or why I’d be interested in “configuring” an “entry” instead of setting up an account (b.g.o 548703). The “Add” button required further interaction to complete its goal, but did not end with an ellipsis (b.g.o 548704).
Clicking “Add” changed the right side of the “Accounts” window into a form for setting up a “New Account”, despite having an “I already have an account I want to use” checkbox (b.g.o 548707). The “Undo” button didn’t actually undo anything; it just returned to the “No Accounts Configured” display (b.g.o 548709, fixed in trunk). If the “I already have an account I want to use” checkbox was checked, the “Create” button didn’t actually create an account either (b.g.o 548712).
Accounts were given weird names by default, for example “jabber0” or “aim1” (b.g.o 546445).
The “Login ID” or equivalent field should have been focused by default, but was not (b.g.o 548716).
Expanding the “Advanced” section enlarged the window, but collapsing it again did not return the window to its previous size (b.g.o 548717).
Empathy repeatedly asked to create a “default keyring”. If I chose not to do this (by clicking “Deny”), Empathy falsely reported that all accounts had an “authentication failure”, and it wasn’t obvious why this had happened (). And if I did choose to create a “default keyring”, when I changed Empathy’s status to “Available” I was confronted with four keyring alerts in quick succession, one each for each of the accounts I had set up (). This was extremely unpleasant.
Pressing the Enter key in the password field did not complete setting up the account (). And whenever an account was created, by default it was not “Enabled” (b.g.o 547323). These are likely to make people wonder why the account setup isn’t working. Even after enabling an account, Empathy remained “Offline” by default, when the reason I set up an account in the first place was almost certainly that I wanted to use it (). The status menu did not extend to the full width of the menu’s button, making choosing a status needlessly difficult ().
The Accounts window covered the entire contents of the Contact List window by default, making the effects of account changes difficult to see (), and the Contact List window could not be brought in front of the Accounts window ().
When I set up exactly the same account twice “by mistake”, Empathy did not correct the error. Trying to connect the second of the duplicate accounts produced the error “(null) Network error” (). When I chose to delete one of the accounts, Pidgin produced a confirmation alert that appeared centered over the Buddy List instead of over the Accounts window whence I’d actually opened it ().
Failed authentication was cleverly shown in the contact list with an “Edit account” button, but this panel was not scrollable, so in a small window it subtracted from the space available to show contacts in other accounts (). And the notification persisted even after the account had been removed; clicking the “Edit account” button in this case produced a malfunctioning Accounts window ().
Clicking “Remove” produced an obnoxious alert telling me that “Any associated conversations and chat rooms will NOT be removed if you decide to proceed”, despite Empathy knowing that there were no associated conversations or chat rooms ().
With “Yahoo” chosen, Empathy asked for “Login ID” and password, which — because it was in a single “Settings” group — looked wonky (). Having previously used my Yahoo account with Yahoo Messenger and other chat programs, I was familiar with the term “Yahoo ID”, but not “Login ID”, so it wasn’t clear whether I was supposed to enter my Yahoo ID or my entire Yahoo address (b.g.o 548693, fixed in trunk).
Entering just my Yahoo ID, I successfully connected to my Yahoo account.
With “Google Talk” chosen, Empathy again asked for “Login ID” and password. My Google Talk account uses an e-mail address, not a “login ID”.
Entering my e-mail address in the field, I successfully connected to my Google Talk account.
The first field was correctly labelled “Screen Name”, but again was not focused by default.
The “Advanced” section of the account setup was not lined up with the rest of the form ().
I successfully connected to my AIM account.
The Advanced section was oddly indented and poorly aligned (), and contained a “Use old SSL” checkbox for which the meaning of the off state was not obvious ().
I successfully connected to my existing Jabber account.
I guessed that to create a new account, I needed to uncheck “I already have an account I want to use”. However, this appeared to do nothing: the resulting form looked identical to that for adding an existing Jabber acount, and it did not ask me to enter the password for my new account twice (as a registration form should do). I went ahead anyway, and Empathy pretended to add a new account, but uselessly showed the error “Name in use” in the Contact List, instead of showing it in the registration form when I might have been able to do something about it ().
There was no apparent way to set up an IRC connection in Empathy.
There was no apparent way to set up an IRC connection in Empathy.
On first launch, Pidgin helpfully noticed that I had no accounts set up, and presented an “Accounts” window with a welcome message inviting me to “press the Add button below and configure your first account”. Since this was the only useful thing I could do, it wasn’t clear why the “Add” button didn’t click itself (d.p.i 6659). The button also required further interaction to complete its goal, but was missing an ellipsis (d.p.i 6662).
On clicking “Add”, a fairly straightforward “Add Account” window appeared, with the only slightly confusing details being “Protocol” (d.p.i 6663) and “Local alias” (d.p.i 6824).
The “Add Account” window was not a dialog, so it was possible to return the “Accounts” window to the front, click “Add” again, and open any number of “Add Account” windows. It seems likely that the only reason people will ever do this is by mistake (d.p.i 6823).
The “Add Account” window should have focused the first text field by default, but did not, instead focusing the “Basic” tab (d.p.i 6825). Almost the entire contents of the second tab changed depending on the “Protocol” menu selection, which was confusing because that menu was inside the first tab (d.p.i 6869).
Choosing a different account type caused the window to resize in both directions, causing even the account type menu to jump around ().
The button for completing the account setup was labelled “Save”, when “Add” would have made more sense (). The button did not respond to the Enter key ().
When I set up exactly the same account twice “by mistake”, Pidgin did not correct the error. Whenever I connected one of the duplicate accounts, the other would disconnect with the message “1 account was disabled because you signed on from another location” (). When I chose to delete one of the accounts, Pidgin produced a confirmation alert that appeared centered over the Buddy List instead of over the Accounts window whence I’d actually opened it ().
Failed authentication was cleverly shown in the Buddy List with “Modify Account” and “Reconnect” buttons, but this panel was not scrollable, so in a small window it subtracted from the space available to show contacts in other accounts (). The notification correctly disappeared if I removed the account from the “Accounts” window.
On choosing “Yahoo” I was invited to enter my “Username” and password. Yahoo accounts have Yahoo IDs, not “Usernames” ().
On clicking “Save”, the (now very different) “Accounts” window showed that I was online with Yahoo, and my Yahoo buddies appeared in the “Buddy List” window.
On choosing “Google Talk” I was invited to enter my “Username”, “Domain” (defaulting to “gmail.com”), “Resource” (defaulting to “Home”), and password. In contrast, Google’s own Google Talk client asks only for “Email” and password. I had no idea what a “resource” was in this context, and there was no help available ().
Ignoring the “Resource” field, I successfully connected to my Google Talk account. Confusingly, it showed up in the “Accounts” window as an “XMPP” account rather than a Google Talk account (). (I know that Google Talk uses XMPP, but presumably the point of having an explicit Google Talk option at all is to hide that implementation detail.)
“AIM” was the default “Protocol” choice, and invited me to enter my “Username” and password. AIM accounts have Screen Names, not “usernames” ().
I successfully connected to my AIM account.
The protocol menu contains “XMPP” but not “Jabber”; even if technically correct, this is unhelpful, since even people who use Jabber may be unfamiliar with “XMPP” (d.p.i 4564). (One way of solving this would be to label the choice “Jabber/XMPP” or “Jabber (XMPP)”.)
On choosing “XMPP” I was invited to enter my “Username”, “Domain”, “Resource”, and password. I was used to entering my complete Jabber ID (email@example.com), not separating it into a “username” and “domain”, and again I did not know what a “resource” was. Pidgin let me enter firstname.lastname@example.org as my “username” without entering a “domain”, and only once the “Add Account” window was closed did it show the unhelpful error “Error resolving jabber.org.nz@: Name or service not known” ().
After re-entering the first and last parts of my Jabber ID in the appropriate fields, I successfully connected to my Jabber account.
I nearly completely missed seeing any way to create a new Jabber account within Pidgin. The fourth time I used it, I noticed that a “Create this account on the server” checkbox appears when the “Add Account” window’s “Protocol” menu is set to “XMPP”. This isn’t nearly obvious enough for what most people will think of as a different operation from setting up an already-existing account; and without asking for the password twice (as registration forms usually do), there is no protection against creating an account with a mistyped password and then never being able to sign in to it (). It also resulted in poor feedback: instead of telling me in-place in the “Add Account” window that the ID I had chosen was already taken, Pidgin put up a nasty alert featuring the face of a dead person and the near-useless text “409: Conflict”, and then left me with no clue what to do next ().
On choosing “IRC” I was invited to enter my “Username”, server, and password. Here “Username” meant “Nickname”, and this time it wasn’t just misleading, it was false: the real IRC “Username” field was on the “Advanced” tab ().
I successfully connected to Freenode, and a small window opened containing server messages that I wasn’t interested in. This happened every time I connected to the network ().
I successfully connected to Canonical IRC using SSL.
- Can I easily tell which accounts are online, and toggle accounts online and offline?
- Can I easily change my picture, choosing from a set of default pictures or taking a photo with a built-in camera?
Seeing which accounts were online and offline, and trying to reconnect a disconnected account, required opening and closing the “Accounts” window, which was annoying ().
Setting my picture was not obvious: it required clicking an unlabelled button in the “Personal Information” window (). Clicking the button opened a file picker titled “Select Your Avatar Image” (avatar??) to my Pictures folder, despite it containing no pictures. It did not let me take a picture using my computer’s built-in camera (), it did not let me crop my chosen picture to be recognizable at buddy icon size (), and it did not make easy using the same picture for every account ().
Pidgin let me disconnect from, and reconnect to, an account using its “Accounts” submenu, but suggested this would “Disable” the account, which was needlessly alarming ().
Setting my picture for every account was possible by clicking the existing picture in the Buddy List window. And setting my picture for an individual account was possible by opening the “Accounts” window, selecting the account (none was selected by default, ), choosing “Modify”, checking the “Use this buddy icon for this account” checkbox, then clicking an unlabelled button (). In both cases, clicking the button opened a file picker titled “Buddy Icon” to my home folder. It did not let me take a picture using my computer’s built-in camera (), it did not let me crop my chosen picture to be recognizable at buddy icon size (), and it did not make easy using the same picture for every account (). A “Remove” button let me remove the current icon, but was available even if there was no current icon ().
- How easily can I see my current status?
- How easily can I change my status?
I could see and change my status from the menu at the top of the Contact List window. I could even change my status when no accounts were set up, which was probably more confusing than useful (). I could also see my status from an icon in the panel, though there was no apparent way of changing my status from there (clicking the icon toggled the visibility of the Contact List window).
I could easily change my status using the menu at the bottom of the Buddy List window. When I chose “Away” or “Do not disturb”, a text field appeared temporarily in case I wanted to be more specific about my status, which was pretty neat.
- How attractive and compact is the contact list?
- How easy is it to find someone and tell whether they’re online?
- How easily can I add and remove contacts?
- If someone has multiple accounts, how easy is it to group them?
- Are animated pictures distracting? If someone has a garish or unrecognizable picture, how easily can I override it with a photo of the person?
- How well-integrated is the contact list with my address book?
The initial presentation of the contact list was adequate, though using italics to show each person’s status was gratuitous since it was already both smaller and grey (b.g.o 548632), and showing “Available” for everyone who had not set a custom status made it needlessly difficult to see who had set one (). There was a border under the heading for each group, which was slightly misleading (b.g.o 548627). There was a stylized picture of a foot at the top right of the window for no obvious reason (); clicking it opened the Accounts window. Each contact had a very large tooltip, in which the account name was in inverse color for no obvious reason (). The status icons for each contact were exactly aligned with my own, which was a nice touch.
The “New Contact” dialog was quite small by default, and poorly organized (): it used a “Contact” group to separate everything in the dialog from nothing else by default, it had a large person icon on the right that apparently did nothing, it used an “Identifier” label instead of the proper account-specific terminology (), it used the term “Alias” without explaining it, it had a picture of a blackboard in the bottom left corner for no apparent reason (), and the “Groups” section featured a run-on sentence almost as bad as this one ().
Copying and pasting a colleague’s Jabber ID, I copied some leading and trailing whitespace as well. The “Identifier” field should have ignored this, but did not ().
When clicked “Add”, all trace of the person I was adding disappeared: there was no option to show pending contact approval requests, which meant there was no apparent way to cancel the request. There was also no apparent way to remove a contact ().
There was no apparent way to group a person’s multiple accounts together ().
Having selected a contact to update their details, I was surprised to find that “Edit” > “Personal Information” showed my own details rather than the contact’s (). I eventually found what I was looking for, accessed from the repetitively-labelled “Edit” > “Contact” > “Edit” menu item (). Despite this labelling, the window included non-editable information such that it was a superset of the “Edit” > “Contact” > “Information” window, so the latter window seemed to be completely redundant ().
The “Edit Contact Information” window contained a large buddy icon, but there was no apparent way to override this icon ().
There did not seem to be any address book integration. Evolution had let me enter instant messaging details for people in its address book, but Empathy ignored them ().
The initial presentation of the contact list was adequate. There was a border under the heading for each group, which was slightly misleading (). Each contact had a very large tooltip, containing (amongst other things) mysterious “Subscription” text such as “Subscription: From” or “Subscription: None (To pending)” (). The icon for my status was slightly out of line with the icons for everyone else’s.
The “Add Buddy” dialog was quite understandable, except that it used the same needlessly vague “username” term as the main “Accounts” window. However, once I clicked “Add” and the dialog disappeared, nothing seemed to have happened: the other person became one of the “Not Authorized” contacts that are not shown by default (). There was no apparent way to cancel a contact approval request, or to remove a contact ().
I could group a person’s multiple accounts together by dragging and dropping, but the drag feedback was poor and there was no obvious way to undo a mistaken grouping ().
Having selected a contact and chosen “Buddies” > “Get User Info”, I was surprised to be confronted with a dialog asking me to “enter the username or alias of the person whose info you would like to view”. To its credit, the text field auto-completed names from my Buddy List, but what about the contact I had already selected ()? Once I had selected a contact, the “Buddy Information” window was adequate but had slight layout problems (), and did not let me override the contact’s image () (see also “Sending and receiving files” below).
There did not seem to be any address book integration. Evolution had let me enter instant messaging details for people in its address book, but Pidgin ignored them ().
Notification of new conversations
- What happens if someone starts a chat with me?
- What happens if someone mentions my name on IRC?
A new conversation was indicated by the icon in the panel flashing with a speech bubble icon. The person who had started talking to me was indicated by the same flashing icon next to their name in the Contact List window, but depending on the number and order of my online contacts, this might have been scrolled out of sight. Strangely, the conversation window itself did not open automatically; if it had, Ubuntu’s window manager would have done a much better job of notifying me of the new conversation than Empathy did ().
It turned out that the person had since gone offline. The only indication of this in the conversation window was that the window had a tab with a grey square, which wasn’t obvious, and there was no indication at all of when they had gone offline ().
A new conversation was indicated by the icon in the panel changing color (from green to orange). A window opened for the person’s chat, so the window manager effectively requested attention.
- How easy is sending a message?
- Are conversations attractive and easy to read?
- How well are long messages handled?
- How well are URLs handled?
- How well are emoticons handled?
By default, text chats were displayed in a window that showed only eight lines of text (). They were presented as plain colored text, with graphic emoticons but no buddy icons or speech bubbles. In Ubuntu’s default dark theme, timestamps were practically impossible to read (). The window had two close buttons, one in the title bar and one inside the window’s single tab (b.g.o 551096).
Sending a message was easy, as the message field was focused by default. Entering a long message resized the window to enlarge the message field automatically, but not as much as it could have (), and pasting in a long passage of text did not automatically show the end of the text as it does in most text fields ().
URLs were displayed as links, but a character at the end of a URL was not treated as part of the link (), and URLs of the form apt:package-name were not recognized and produced an emoticon instead ().
By default, text chats were displayed in a window that showed about 12 lines of text. IRC channel windows were the same size as an individual chat window, which is inappropriately small for a chat that is likely to involve dozens of people (). A timestamp was shown for every utterance, which was a little cluttersome, especially at the default window size.
Sending a message was easy, as the message field was focused by default. Entering a long message resized the window to enlarge the message field automatically, but not as much as it could have ().
URLs were displayed as links, but URLs of the form apt:package-name were not recognized and produced an emoticon instead ().
A button labelled “Smile!” (whimsical, but possibly discouraging for business use) offered a selection of 16 emoticons in a floating window. This was surprising, because the other items in the same toolbar behaved like menus (and so do the emoticon selectors in other IM programs), and because it meant clicking outside the list of emoticons did not close it ().
- How easily can I see which people accept voice chat?
- How easily can I start a voice chat?
- What’s the sound quality like?
- Is it easy to mute the input? or the output?
It was easy to see which people accepted voice chat, as they appeared with a microphone icon in the Contact List. It was incongruous that starting a text chat required double-clicking anywhere in a person’s row except the microphone, while starting a voice chat required single-clicking on the microphone.
On trying to start a voice chat, Empathy opened a small mostly-blank window with the text “Ringing”, which eventually became “Closed”. When the other person tried to initiate the call, it did not show up at all.
I was unable to have a voice chat using Empathy.
Pidgin does not have voice chat.
- How easily can I see which people accept video chat?
- What’s the sound and video quality like?
- Is it easy to mute the sound and/or video?
I was unable to test video chat, because Ubuntu did not recognize my notebook’s camera.
Pidgin does not have video chat.
Sending and receiving files
- How obvious is sending a file?
- How easy is receiving a file?
Empathy does not yet support sending or receiving files.
A file being sent to me was indicated by a small, oddly-placed alert featuring the face of a confused person (). On clicking “Accept”, I was was confronted with a “Save File...” () dialog that was massive but mostly empty (). On clicking “Save”, a “File Transfers” window appeared, but the transfer never began.
On dragging an image to a person in the Buddy List, or into their open chat window, I was confronted with an alert asking me whether I wanted to set the image as the person’s buddy icon (oh, so that’s how you do it!), or send the file to them. It would have made more sense to devote this gesture to sending files, and to have a more obvious mechanism elsewhere for overriding someone’s buddy icon. (d.p.i 7019) Once I had chosen to send the file, it appeared in my “File Transfers” window, but not in that of the other person (who was also using Pidgin), and the transfer never began.
In summary, I was unable to send files to, or receive files from, someone else using Pidgin with a Jabber account.
For someone using Google Talk on the Web, which does not support sending/receiving files, I was still able to choose “Send File” and select a file. Only then was I confronted with the error message “Unable to send file ... user does not support file transfers”, again with a face-of-a-dead-person icon (), but the impossible transfer still falsely showed up in the File Transfers window as “Waiting for transfer to begin” ().
- How accessible are chat logs?
- How easily can the logs be searched?
- Can logs from multiple accounts for the same person be grouped, regardless of whether those accounts are still in my contact list?
- Does your previous conversation with a person show up when starting a new conversation with them?
Empathy logged conversations by default. It had a “View Previous Conversations” menu item, which opened a “Previous Conversations” window with two tabs: “Search”, where I could filter conversations by search text, and “Conversations”, where conversations can be filtered by account and then person and then date and then individually searched. This is an artificial distinction; it would be more powerful to combine the tabs into a list of conversations that can be searched by text, person, and/or time.
Pidgin’s logging feature was hostile bordering on vexatious. As with contact info, Pidgin’s “Buddies” > “View User Log…” menu item showed me not the log of the person I had selected, nor a list of contacts for whom any conversations had been logged, nor even a list of logged conversations, but a “View User Log” window (again with the icon of a confused person’s face) asking me to type the name of the person whose log I wanted to view. Once I’d entered someone’s name, Pidgin would then unfailingly report that “No logs were found”, because “Instant messages will only be logged if the "Log all instant messages" preference is enabled”, and that preference was disabled by default. Pidgin could have detected within a few hundredths of a second that it did not have any logs stored, but it presented the “View User Log” scavenger hunt as an available menu item anyway ().
Once I had turned on logging, the log viewer let me see conversations for one person per log window. The logs were searchable, with search matches highlighted in fluorescent green.
Other cool stuff
- What other cool features are available?
Empathy did not have any visible features other than those described above.
Pidgin had “Buddy Pounces”, letting me contact a particular person immediately whenever they come online (albeit taking the fun out of that game); useful, if a little hidden, privacy controls; and a raft of plugins for extra features and various behaviors.
- “I get an error whenever I go online.” Does the help assist with this example problem?
- “I can’t find someone in my contact list.” Does the help assist with this example problem?
- “How do I do voice chat?” Does the help answer this example question?
- Does the About window describe what the program is about?
Empathy’s help was appalling (b.g.o 561033). Discouragingly titled “Empathy Manual”, it featured such inanities as “When you start Empathy the following window is shown”; “Allows to update the user's status”; a pointless full-size screenshot of the “Accounts window”; “talk with other users (called contatcs)” [sic, italics in original]; multiple occurrences of “proceed as follow”; and a “Modifying a Contact” page that was completely empty. Possibly the only two helpful help pages were those on “Registering an Account”, because it provided links to the Web sites for actually signing up for the types of account that Empathy lets you use; and on “Creating an Account”, because Empathy’s account setup procedure is likely confusing enough to need it. It did not provide help with any of my example issues.
Empathy’s About window described it as “An Instant Messaging client for GNOME”. Who’s he?
A “Help” > “Online Help” menu item opened a Web browser to a single long page of friendly and detailed help on the Pidgin Web site. It is not the Pidgin developers’ fault, but a problem nonetheless, that this menu item was confusingly similar to the “Get Help Online…” item inserted into the “Help” menu by Ubuntu (LP 38341).
That the help was on a Web site made it unavailable when offline; this would make it ineffective for many of those who need help realizing that their Internet connection in general is the reason they’re having trouble with instant messaging in particular. And that the help was not platform-specific also meant that someone using Ubuntu would have to navigate through “All Platforms”, “Windows Specific”, and “Linux and Unix-like platforms” sections, when people may be unfamiliar with those terms. The sections may also be distracting: for example, the help addressed my example “I get an error whenever I go online” problem, but only for Windows.
The help usefully addressed my example problem “I can’t find someone in my contact list” with specific instructions, though they only covered one possibility (erroneously-grouped contacts). The help also addressed my example question “How do I do voice chat?” honestly, if a little bleakly (“We plan to implement these features eventually … we have no idea when this will happen”).
Pidgin’s About window described it as “a graphical modular messaging client based on libpurple which is capable of connecting to AIM, MSN, Yahoo!, XMPP, ICQ, IRC, SILC, SIP/SIMPLE, Novell GroupWise, Lotus Sametime, Bonjour, Zephyr, MySpaceIM, Gadu-Gadu, and QQ all at once. It is written using GTK+.” TMI, TYVM.
Empathy and Pidgin are both quite unpleasant to use. In a couple of cases, this is because the human interface for an entire feature has been poorly designed — most notably Empathy’s account setup and Pidgin’s chat logging. Mostly, however, it is a constant stream of small design glitches and other defects that combine to make the overall experience a frustrating one.
Empathy shows promise as a modest and unobtrusive messaging program that will, apparently, be adaptable as a communication framework in future Ubuntu applications. And its developers have been enthusiastic and responsive in tackling problems discussed in this evaluation. For now, though, this “rich set of reusable instant messaging widgets” does not seem to have reached 1.0 quality. It is likely that some features will need extensive redesign before Empathy is usable by a mass audience. So if it was introduced as Ubuntu’s default instant messaging program, those novices who did learn to use the current version would get a bad experience with it (and, thanks to Empathy’s near-useless help, would further distrust help in general), and would then have a lot of relearning to do for the next version.
Pidgin is more mature and fully-featured, with the large exceptions of audio and video chat. Few design details are actually impressive or delightful, but Pidgin’s developers have a strong culture of simplicity and consistency, and most of its features (apart from chat logging) are more understandable than their equivalents in Empathy. And Pidgin’s plug-in mechanism allows for customization and experimentation with new features.
I suggest that Ubuntu Intrepid Ibex continue using Pidgin by default. I look forward to working with the Empathy and Pidgin developers, if invited, to design solutions to their usability problems.
That's not "two blue blobs" in the Empathy icon, but two blue heads having a telepathic mind link or something. AndreasSchildbach
Regarding "delayed" error notfication on sending a file to someone using gtalk web interface. I think that Pidgin (or any other third party client) cannot differentiate between the web client and the normal client. So, it cannot give apriori error (unless there is some handshaking mechanism involved in the XMPP protocol that allows clients to "discover" capabilities before starting a chat)- Shantanu Goel
Your Google Talk account does NOT use an email address for its "login ID", it uses a Jabber ID (or XMPP ID if you prefer). The text in the interface can of course differ from these terms, as long as it doesn't reference email. The "@" character does not equal "this is an email address", the XMPP specification uses the @ symbol to give Jabber IDs in the form user@server/resource (like email@example.com/athome), but has nothing at all to do with emails. Google's implementation happens to use the term "gmail" in its Jabber IDs, in the same way that Microsoft uses "hotmail" is some MSN addresses, but this doesn't make either them email services (there are email services hosted at those servers as well though). Asking for "email" credentials in a chat application would cause confusion in my opinion, as it wouldn't be clear that the messages were not emails, which is an important implementation detail to show in a world where the term email is used universally to describe the system. PS: I find it rather ironic that this Wiki software has also made the same incorrect assumption and inserted the above Jabber ID into a completely meaningless and broken mailto link. - Warbo
I understand that it’s not an e-mail address, and that it’s possible to use Google Talk without even having a Gmail account, so the Google Talk client is just plain wrong. However, that’s no excuse for Pidgin’s Google Talk setup to be more complicated, asking you to enter things that have only one possible value. -- mpt
Agreed. I was just dreading that the applications would switch to using the term "email address" for Google Talk accounts, and then users thinking that the chat program was therefore displaying their emails. It can take a long time staring at an empty Conversations window before one realises that this program won't show incoming emails. - Warbo
I think it's great that these apps are finally getting some solid scrutiny. You must be one of the professionals Canonical hired to improve usability. With the spot-on review I see here, I am really looking forward to the future! ~ethana2
-- troy-sobotka 2008-09-21 18:35:47 I have a problem with an analysis that purports to be about usability and yet declines to state who it will be usable for. Usability-for-everyone inevitably is an exploration about usability-for-only-one. Chat logs? What audience desires chat logs and easy searching? What audience would find the added feature more cumbersome to a simple chat interface they desire and add to the complexity of their experience? How easy is it to set up an account for someone who has never set up a single chat account before? An expert who wants to set up multiple accounts quickly without flipping through multiple window panes? Both examples require quite different implementations, and as such, no single implementation will succeed for both. Once again, who is the audience?
It is false to say that “Usability-for-everyone inevitably is an exploration about usability-for-only-one”. For example, the sort of person who has trouble with unfamiliar terminology when setting up an AIM account is highly unlikely to be the same sort of person who needs to set up an IRC account with SSL authentication. But it wasn’t particularly difficult mentally switching character to test both those things (though the evaluation was by no means exhaustive). You are also exaggerating the difference in account setup interface suited for different skill sets, because it’s a rare task and therefore one that an expert usually would not mind (or even notice!) spending a little more time on in the edge case of setting up multiple similar accounts. And as for chat logs, both programs already expose that feature and have therefore paid its complexity fee; but neither of them are getting as high a dividend from it as they could. For both programs, a better-designed log window would require less interaction overall. -- MatthewPaulThomas, 2008-09-24
-- troy-sobotka 2008-10-04 18:27:17 Ugh. The point I was trying to make is that your audience drives _all_. And yes, the person who sets up an AIM account is a far cry from one who sets up IRC with SSL. That's the point. While the high level proficient user can 'dial down' their knowledge, a greener individual cannot 'dial up' their knowledge quickly nor effectively. If the extra feature resides in plain view, it will only complicate the matter ( http://www.ted.com/index.php/talks/barry_schwartz_on_the_paradox_of_choice.html ) If Mark is deadly serious about delving into the seamless design pattern established by Apple, his 'usability' people had better understand the cornerstone of design taught in every entry level course -- audience. Symptomatic terms such as 'What other cool features are there?' scare me. What does your audience want and how can a design more greatly take them there? Microsoft Movie Maker and Final Cut Pro are two entirely different applications aimed at entirely different audiences. While one could argue over the merits of one particular interface element, the bottom line is that the audience drives the application's design and a comparison between the two based on random audiences would yield completely random results.
Again, I think you are vastly exaggerating the difference in interface suited for different skill sets. Instant messaging is an extremely simple task compared with making a movie or editing a photo, and that means there is little need to target an instant messaging application at any particular fraction of the audience. If it helps, you could consider the target audience as “everyone who isn’t an IRCop”. -- MatthewPaulThomas
It is probably true that average user does not use chat history, chat history can be given lower priority and moved out of sight (it actually kinda is). About quickly setting up accounts: instant messenger's developers need to setup the account with minimum clicks possible. The rest of world wants to do it without error, looking to documentation, providing information they do not know for sure, thinking or using advanced knowledge - which results in quick use case. Even expert users benefit from having setting where they expect them. And the audience? The common people: janitors, taxi drivers, shopkeepers, musicians, news reporters. Half of the people I know do IT for living (or at least know what filesystem is) but I am a freak, world everywhere else is different. -- Petr.bug
I just installed empathy 2.24, ekiga 3.00, and gizmo while looking for an alternative to Skype for voice/video chats. So far empathy is the only program that's given me consistent success, using SIP. I still haven't figured out how to get it to do voice/video with Jabber accounts. I haven't imported my other account settings into it yet, so I'm still using pidgin for text chat. Main reasons here are the familiar UI, metacontacts, support for filetransfers, and several months worth of accumulated logs. The account creation UI in empathy disturbs me in a couple ways, as already noted above: newly created accounts should be enabled by default; the sequence of clicks from +Add, Cancel/Create and Close is very unsettling. In particular, when you're on the last part of the dialog, the only Submit button is "Close" - I don't know if that means "OK, I'm satisfied with this" or "Forget it". In fact, experimentation reveals that if you filled in the username/password fields then "Close" = "OK" but if you left the input blank then "Close" = "Cancel". It's simple once you know it, but experimentation shouldn't have been required in the first place. Given the number of hours I spent (unsuccessfully) trying to get voicechat working in the other programs, I'll use empathy for this purpose. If some of the nicer features of pidgin make it into empathy, then I will probably migrate completely. But for now, I'm going to be using both pidgin and empathy for a while. - hyc 2008-09-28
pidgin is getting some audio + video see gsoc 2008 projects. -- does empathy have otr support ? ~~~~~
As with contact info, Pidgin’s “Buddies” > “View User Log…” menu item showed me not the log of the person I had selected
: And it shouldn't, since there would then be no way to show logs for users who are not listed (offline users, for instance). I agree that this is confusing, but you need to take more into account: This behavior is consistent with the behavior of the other options in the menu (send a message, view user info, and join a chat all require you to enter a buddy or chat before doing anything), whereas right-clicking on a user and selecting "View Log" or selecting "View Log" from the IM window itself is the way that you open the log for a particular user directly. You can, similarly, right click on a user and view their info or send them a message without typing in their name.
For years, privacy and security experts worldwide have called on the general public to adopt strong, open-source cryptography to protect our communications. The Snowden revelations have confirmed our worst fears: governments are spying on our digital lives, grabbing up communications transmitted in the clear.
Given widespread government surveillance, why don’t people routinely use tools to encrypt their communications? Wouldn’t we all communicate a little more freely without the shadow of surveillance?
It boils down to two things: security and usability. Most of the tools that are easy for the general public to use don’t rely on security best practices--including end-to-end encryption and open source code. Messaging tools that are really secure often aren’t easy to use; everyday users may have trouble installing the technology, verifying its authenticity, setting up an account, or may accidentally use it in ways that expose their communications.
EFF, in collaboration with Julia Angwin at ProPublica and Joseph Bonneau at the Princeton Center for Information Technology Policy, are joining forces to launch a campaign for secure and usable crypto. We are championing technologies that are strongly secure and also simple to use.
The Secure Messaging Scorecard examines dozens of messaging technologies and rates each of them on a range of security best practices. Our campaign is focused on communication technologies -- including chat clients, text messaging apps, email applications, and video calling technologies. These are the tools everyday users need to communicate with friends, family members, and colleagues, and we need secure solutions for them.
We chose technologies that have a large user base--and thus a great deal of sensitive user communications--in addition to smaller companies that are pioneering advanced security practices. We’re hoping our scorecard will serve as a race-to-the-top, spurring innovation around strong crypto for digital communications.
Here are the criteria we looked at in assessing the security of various communication tools.
1. Is your communication encrypted in transit?
This criterion requires that all user communications are encrypted along all the links in the communication path. Note that we are not requiring encryption of data that is transmitted on a company network, though that is ideal. We do not require that metadata (such as user names or addresses) is encrypted.
2.Is your communication encrypted with a key the provider doesn't have access to?
This criterion requires that all user communications are end-to-end encrypted. This means the keys necessary to decrypt messages must be generated and stored at the endpoints (i.e. by users, not by servers). The keys should never leave endpoints except with explicit user action, such as to backup a key or synchronize keys between two devices. It is fine if users' public keys are exchanged using a centralized server.
3.Can you independently verify your correspondent's identity?
This criterion requires that a built-in method exists for users to verify the identity of correspondents they are speaking with and the integrity of the channel, even if the service provider or other third parties are compromised. Two acceptable solutions are:
An interface for users to view the fingerprint (hash) of their correspondent's public keys as well as their own, which users can verify manually or out-of-band.
A key exchange protocol with a short-authentication-string comparison, such as the Socialist Millionaire's protocol.
Other solutions are possible, but any solution must verify a binding between users and the cryptographic channel which has been set up. For the scorecard, we are simply requiring that a mechanism is implemented and not evaluating the usability and security of that mechanism.
4.Are past communications secure if your keys are stolen?
This criterion requires that the app provide forward secrecy, that is, all communications must be encrypted with ephemeral keys which are routinely deleted (along with the random values used to derive them). It is imperative that these keys cannot be reconstructed after the fact by anybody even given access to both parties' long-term private keys, ensuring that if users choose to delete their local copies of correspondence, they are permanently deleted. Note that this criterion requires criterion 2, end-to-end encryption.
Note: For this phase of the campaign, we accept a hybrid forward-secrecy approach with forward secrecy on the transport layer (for example through TLS with a Diffie-Hellman cipher suite) and non-forward-secret end-to-end encryption, plus an explicit guarantee that ciphertexts are not logged by the provider. This is a compromise as it requires trusting the provider not to log ciphertexts, but we prefer this setup to having no forward secrecy at all.
5.Is the code open to independent review?
This criterion requires that sufficient source-code has been published that a compatible implementation can be independently compiled. Although it is preferable, we do not require the code to be released under any specific free/open source license. We only require that all code which could affect the communication and encryption performed by the client is available for review in order to detect bugs, back doors, and structural problems. Note: when tools are provided by an operating system vendor, we only require code for the tool and not the entire OS. This is a compromise, but the task of securing OSes and updates to OSes is beyond the scope of this project.
6. Is the crypto design well-documented?
This criterion requires clear and detailed explanations of the cryptography used by the application. Preferably this should take the form of a white-paper written for review by an audience of professional cryptographers. This must provide answers to the following questions:
Which algorithms and parameters (such as key sizes or elliptic curve groups) are used in every step of the encryption and authentication process
How keys are generated, stored, and exchanged between users
The life-cycle of keys and the process for users to change or revoke their key
A clear statement of the properties and protections the software aims to provide (implicitly, this tends to also provide a threat model, though it's good to have an explicit threat model too). This should also include a clear statement of scenarios in which the protocol is not secure.
7.Has there been an independent security audit?
This criterion requires an independent security review has been performed within the 12 months prior to evaluation. This review must cover both the design and the implementation of the app and must be performed by a named auditing party that is independent of the tool's main development team. Audits by an independent security team within a large organization are sufficient. Recognizing that unpublished audits can be valuable, we do not require that the results of the audit have been made public, only that a named party is willing to verify that the audit took place.
We've discussed this criterion in depth in a Deeplinks post: What Makes a Good Security Audit?
Entries in the Secure Messaging Scorecard were checked with the listed projects and companies when the Scorecard launched on 2014-11-06. Updates will be made if the listees or others inform us of changes or inaccuracies. A log of all such changes is below:
- 2016-04-05 :
- 2016-03-13 :
- Cryptocat was removed as the service has been suspended.
- 2015-11-03 :
- 2015-10-30 :
- We removed Subrosa as the project was discontinued in October 2015.
- 2015-06-12 :
- We removed Secret as the service was shut down in May 2015.
- 2015-03-06 :
- We credited QQ for completing an independent internal security audit (✓).
- 2015-02-17 :
- We credited Telegram (both secret and regular mode) for undergoing a code audit in February 2015 (✓).
- 2015-01-29 :
- We have credited QQ for encrypting messages in transit (✓). Though QQ does not use TLS/SSL, which is considered best practice, they have implemented a custom protocol for message encryption in transit.
- We have clarified our scoring for forward secrecy (criterion #4).
- 2015-01-05 :
- We have split the scoring for Telegram into two rows: baseline Telegram and Telegram secret chats. Baseline Telegram chats are not end-to-end encrypted so that the provider can't read them (✘). Telegram secret chats are, and in addition Telegram now supports perfect forward secrecy so that messages can be securely deleted (✓)
- Wickr now provides the ability to verify contact's identities by exposing key fingerprints, which can be verified out-of-band or through in-band video. (✓)
- 2014-11-14 :
- RIM has told us that BlackBerry Messenger Protected uses an out-of-band passphrase exchange and EC-SPEKE to perform identity verification. (✓) RIM has also told us that BBM Protected receives security reviews by an internal security team. (✓)
- Viber has received a recent external security audit from EY Advanced Security Center. (✓)
- Pidgin has documented a number of auditing processes including regular use of static analysis tools and audits by a team at Cisco Talos. The Pidgin developers were clear that they do not know how thorough and complete these audits have been, but the audits nonetheless meet our criteria. (✓) Although auditing of Pidgin improves the security of the related Adium project (the projects share many components including libpurple, libotr, and libxml2), the Adium developers tell us that besides occasional static analysis by the developers themselves they are not aware of any independent auditing effort that addresses the Adium-specific code. So for the time being that project will not receive an audit checkmark.
- 2014-11-10 : Skype check mark for end-to-end encryption removed. (✘)
- 2014-11-04 : Snapchat app has audits from an internal security team. (✓)