Our goals: toward Instantbird 0.2 and beyond

As you may already know, Instantbird 0.2 will be released soon. The development of this version has been going on for more than a year already! While we have been busy adding new features or polishing existing ones, we may have missed a few opportunities to communicate about what we were doing, what we had already done, where we are going, and why. And when we did write something about our new features, the announcements lacked screenshots, and probably didn’t convey much of our enthusiasm.

The last few days before the 0.2 release are an opportunity for us make up for our lack of communication.

The way toward Instantbird 1.0

Let’s begin with a clarification about the way we are slowly but surely going to our future 1.0 release. Our initial roadmap contained the somewhat misleading claim that our goal for 1.0 was to reach “feature parity” with Pidgin. This led some people to believe that we were basically copying the Pidgin graphical user interface and reimplementing it in XUL. Although this could have held some truth for the earlier goal of Instantbird - which was to provide the extensibility that is loved in Firefox and features similar to those found in Pidgin - this is no longer the case.

When we implement a new feature in Instantbird, we carefully consider how it is likely to be used. We think about the use cases. We look at how the same problem has been handled by other existing IM clients, so that we can benefit from what others have done before us. Sometimes we take inspiration and implement something in a similar way to another client (for instance the message theme system that we have borrowed from Adium), but sometimes things don’t look satisfying and we have to look for a better solution. We especially try to avoid exposing the user to new popup dialogs that interrupt the user but don’t seem absolutely necessary.

Once something is implemented, we do our best to take advantage of the early feedback we get from our nightly testers.

So why are we doing this? Copying the interface of an existing application as quickly as possible would be easier, and would lead to a fast result. But it would be worthless. We don’t need another Pidgin, Adium, … (insert the name of your favorite multi-protocol IM application here). These applications already exist and are mostly great, there’s no point in cloning them. What we do care about is our users: our current users of course, but also future users. We believe instant messaging should be less frustrating. We want to build an all-in-one instant messaging application that is as easy as possible to use, yet powerful. We value simplicity and ease of use in the default configuration, and at the same time we want to allow advanced customizations. Developers with an idea should be able to easily customize their IM client, like they can already do with their web browser.

We value privacy, and respect your data. Instant messages often have confidential or intimate content. We believe that our users should have the power to decide how this information is used, and where it is stored. This is the reason why even though more and more users decide to use web applications like Gmail, Facebook or Meebo for their IM needs, we believe that it is still relevant in 2010 to build an IM application that runs directly on the computer you own.

We don’t know yet how Instantbird 1.0 will be, it will need to be discussed. With You. At this point we are discussing which improvements will compose the 0.3 release. If you want to take part in this discussion or have questions related to our long term goals, don’t hesitate to get in touch with us.

What’s next?

We are confident that if you have tried a release from the Instantbird 0.1.* series, you will see Instantbird 0.2 as major improvement. And if you haven’t used Instantbird before, then the 0.2 release is a great time to start! In the next few days, we will detail a few of the features that already make Instantbird 0.2 a very usable instant messaging application, despite its low version number.

Status Update - Why 0.2 is not out yet

The last status update here was more than a month ago, so it’s probably time for another update. We are still working toward releasing Instantbird 0.2 in the near future.

At this point, the code of the application is ready. Two points are still holding the release though:

  • we have to rework the server side part of our update system, because the scripts we used on the server up to version 0.2b2 of Instantbird were not able to handle updates in several languages. We want to be sure that users who downloaded Instantbird 0.2 beta 2 in a non-English language will receive an updated version in the same language.
  • we are redesigning the main website of Instantbird. The goal of this redesign is partly to provide a visual refresh, but also to clarify the message. We are de-emphasizing the “multi-platform” argument (it is probably irrelevant to most users and is probably quickly understood by those who care about using Instantbird on more than one operating system), and we try to emphasis the simplicity and ease of use of Instantbird.

We look forward to putting Instantbird 0.2 in the hands of users who didn’t dare to try the beta releases.

Translations

We have been contacted by lots of individuals who volunteered to translate Instantbird into their native language and were eager to start working on it. As we were not ready to host the translations, we asked people to wait before starting their work on localized versions of Instantbird.

As we plan to release the next beta of Instantbird 0.2 in several languages, we feel that now is a good time to start translating the UI of Instantbird. Please note that the development work is not finished yet, and that there will still be string changes before we are ready to release this next milestone.

You will find information on the translation process on our wiki at http://wiki.instantbird.org/Instantbird:Translation. As usual, if you have any question, feel free to ask them in #instantbird on irc.mozilla.org or to contact us at contact AT instantbird DOT org.

Instantbird 0.2 feature preview: conversations customization

In our roadmap we stated that for 0.2 we were going to improve the conversation window, and especially make it customizable. Let’s show you an overview of what we did.

Smileys

People are used to see little images like :-) in conversations instead of the plain text version :-). Testers of Instantbird 0.1.* have probably noticed that this feature was missing. No more.

Instantbird 0.2 supports smileys, and has a theme system for them. Creating a new smiley theme is easy: it is just a bunch of images and a file (JSON format) describing how to use them, bundled into an XPI file.

Message styles

Selecting a smiley theme is not enough for you to feel comfortable when looking at your conversations? Ok, we have more! We have borrowed the message style system of Adium to let you fully customize the way your conversations look.

An image is worth a thousand words so… I’m gonna give you a thousand of images. Ok, not really a thousand, but we took a few hundreds of screenshots to show how Instantbird is doing with the hundreds of Adium message styles downloadable from adiumxtra.com.

The compatibility is not perfect because there are some differences in the way Instantbird and Adium handle themes, and some Adium themes may use some webkit-specific features, but most themes look right.

This theme system is very flexible, and quite easy to learn. The technologies used (HTML, CSS, JavaScript) are well known by web-developers and web-designers. If you are not happy with the existing themes, go ahead an create your own. And don’t hesitate to let your creativity play with all the cool new developer features of Firefox 3.5.

Extensibility

The eye candy is cool but… I’m a developer, I want to create extensions and I want to be able to interact with the conversations! Don’t worry, we love you too. We added several new APIs for extension developers. It is now easy, for example, to change the way we filter incoming messages, modify the text before it is displayed (adding links for instance), and more coming!

Instantbird 0.2 Feature Preview: Localizability

As you may (or may not) know, we previously wrote that Instantbird 0.1.* was not localizable. The reason evoked for this was the use of gettext by libpurple, which is not compatible with the way XUL applications are localized. I’m going to give more details about the issue, and explain how we solved it for Instantbird 0.2.

Comparison of translation systems used by Mozilla and libpurple:

Inside libpurple, localizable strings are just marked by _("string"). For example, you can find this in the code:

description = _("Unknown error");

During the compilation, _() is expanded by the C preprocessor to a call to a gettext function. Gettext tools can analyze the source code, find all strings enclosed in _() markers, and produce a translation template. This template (a .pot file) is then handed to translators, who translate the strings and then provide a .po file for their language.

The translation system for XUL applications is quite different, here are 2 significant differences:

  • localizable strings are not directly in the source code. The source code uses unique identifiers, and these identifiers are used to find the actual string in the locale files.
  • the strings are spread across several localized files. Usually each window has its separate files, which makes it easy to decide at a later point that something will become an extension, and makes it easy to localize an extension like any other part of the application.

How do we deal with this in Instantbird?

Obviously, we don’t want Instantbird to use both of these localization systems, so one had to be removed. In Instantbird 0.1.*, we just removed gettext without replacing it. This means that the gettext _() macro was defined to something doing nothing, and the string used was just the one specified directly inside the source code.

For Instantbird 0.2, this is no longer acceptable, and we worked on a way to simulate the action of gettext, that is, hiding the 2 differences I’ve just explained.

Splitting the translation in different files wasn’t very difficult. Actually, gettext has a concept of packages that makes it possible to split the translation of an application into several packages, the feature is just unused by libpurple. With a little bit of build system tweaking, I finally got a translation file for the core of libpurple, and a separate translation file for each protocol plugin. This was needed so that libpurple protocol plugins packaged as extensions can be localized.

Creating a unique identifier for each localizable string was a bit more work. The solution we have settled on is:

  • Take the original string and remove all string formatters (words starting with %), hexadecimal numbers (words starting with 0x) and more generally, all non alphanumeric characters.
  • Remove all the whitespace in the remaining string, keep only the 7 first words, and convert to camel case.

At this point, we have an identifier for the original string, but it is not unique. Long strings that differ only at the end result in the same identifier, and strings that don’t contain any real word (‘%s:%s’ for instance) all result in an empty string. To disambiguate in these cases, and only in these cases, we append the 8 first characters of the hexadecimal MD5 hash of the original string to the identifier.

Now, how do we use this?

We have a .properties file for libpurple and one for each protocol plugin. When libpurple is compiled for Instantbird, the gettext macros are modified to point to some of our code instead of the gettext library. Our code uses the en-US string to build the identifier, and attempts to find it in the .properties file. If it isn’t found, it tries again with the identifier plus the 8 first characters of the MD5 hash of the string. If it still isn’t found, then it returns the en-US string as a fallback (and emits a warning in debug builds).

How do we make the .properties files for libpurple?

I wrote a python script that generates automatically the appropriate .properties files for the en-US language from the source code of libpurple. Additionnaly, it uses the various .po files of Pidgin to produce files that can be used as a base for localizing this part of Instantbird.

Does this mean I can start translating Instantbird into my own language?

No, not yet, but very soon! Once we are ready to accept contributions from translators, we will ask translators who volunteer to localize Instantbird to contact us so that we can provide them with these generated files.

An alpha build of Instantbird 0.2 will be available soon. We will provide an experimental French translation of this build (most people in our team are French, so French was the logical choice for testing all of this ourselves).

Instantbird 0.2 feature preview: protocols as extensions

One of the features we wanted in Instantbird 0.2 was the ability to install libpurple protocol plugins like any other addon. I’m happy to report that this is now possible with current nightly builds.

To demonstrate this feature, I compiled the Facebook Chat libpurple protocol plugin. The result is an installable xpi file of about 200kB, that people can try with nightly builds of Instantbird.

This file contains a binary module compiled for Windows, Linux and Mac OS X (universal), produced by copying the code from here into the Instantbird source tree. This is the quickest way I found to build it, we will need to figure out a better (without having to download and build the whole Instantbird source code) way later. This is the exact patch I used to build it.

The xpi file also contains a set of icons and a locale file. I will explain in another post how we replaced the usage of gettext in libpurple by a way to get localized strings from regular .properties files.

Feel free to try this facebook chat addons. I don’t know how stable it is, but I’ve used it for a few days already and haven’t encountered any serious issue. If this turns out to be crashy for you, don’t hesitate to send us crash reports, I uploaded the symbols to our symbol servers, so the reports should provide useful information.

I have other nearly-ready Instantbird 0.2 features to introduce in more details later, including: localization, emoticon themes, message styles (like Adium), …

Next time: how localization works with Instantbird and how we replaced gettext.