Wednesday, 23 December 2009

State of the Kadu Usability Project as of 12.2009


This my first post on this blog, so I would like to say "Hello". ;) My name is Piotr Pełzowski, I'm working on Kadu project in my free time - mostly I work on usability and PR. Today I am going to report about current state of usability work done for upcoming version of Kadu Instant Messenger. I will present mockups that had been done by Season of Usability student, Mike Harmala with cooperation with the Kadu Usability Project Contributors.

Adding a New Contact in Kadu IM 0.6.6

Kadu Usability Project aims to make the current Kadu interface more user-friendly and easily accessible for users with different levels of proficiency as well as help the development team with the introduction of new features in the best way possible usability-wise. In short: KaduTeam is serious about building usable universal instant messenger.

As you probably know Kadu IM is an open-source IM client currently supporting only proprietary Gadu-Gadu protocol, Gadu-Gadu is the most popular IM network in Poland. In addition to GG network in next version of Kadu IM the XMPP/Jabber and Tlen networks are going to be officially supported. In fact three days ago Kadu 0.6.6 alpha0 has been released - this is the first development snapshot with XMPP support. As Rafał Malinowski stated:

Alpha0 releases in Kadu are soft-API freeze releases. That means that no one is allowed to make big API changes (small changes are still allowed). (...) Now we will focus on adjusting our GUI to mockups provided by Usability Team and on fixing remaining (less important) API parts - like Pending Messages, File Transfers or Status Changer (...)

So now it is time for GUI changes in Kadu, changes which are required and needed.

Ever since its creation in 2001 Kadu IM has been developed and designed primarily for Polish users of GG protocol. Now we hope to attract international user base with Kadu as a XMPP/Jabber client as well as make life easier for Polish users, many of whom use XMPP/Jabber on a daily basis (according to our user survey, that's the case for ~30% of Kadu users). Along with adding support for multiple protocols, we're planning to support simultaneous connections to more than one communication network, usage of multiple accounts of the same protocol and 'metacontacts'. All these enhancements require big changes, sometimes radical changes, in the interface of Kadu.

IM Networks drop-down list

Those changes are not results of UsabilityTeam whim ;) , our design is based on kadu user survey results (in polish), the survey which has been completed by 5035 participants provided us with vast amounts of useful data. Based on the data acquired from the developers and user survey personas for the Kadu IM has been built by Joanna Pierożek. In 11.2008 the actual work on the design of the multiprotocol user interface has been started. Draft mockups for most of the windows that needed to be introduced or redesigned were ready by the time Mike Harmala joined our team in July 2009 as a Season of Usability student. In the course of his work with us Mike has conducted a heuristic evaluation of the mockups we've previously prepared, based on Nielsen Heuristics, KDE4 Human Interface Guidelines - which we want to comply with - and other resources identifying a lot of issues that needed to be cleared up before the final version of the mockups could start to be implemented. The final contribution Mike has made to Kadu was a set of almost final, both functionally and visually polished mockups for most of the windows that would be introduced into Kadu as soon as it becomes a MultiIM. Those mockups were tweaked/polished a little bit by us and today we will present proposed final design to you.

Let's start with guideline that better explains some of the interactions in the new multiprotocol GUI:

Main mockups in png format:

Click to see big version of each mockup.

  1. Adding a New Contact
  2. Subscription Window (for XMPP-like networks)
  3. Contact Properties
  4. Your Accounts Window- Manage
  5. Your Accounts Window - Add/Create Account
  6. Menu and Context Menu
  7. Merging Contacts (so called "Metacontacts")
  8. Preferences (switching between Simple Mode and Advanced Mode changes ContactsList appearance as described in presentation)
  9. Configuration (First Run) Wizard
  10. Chat window

At this point we've almost finished full specification of all the windows that need to change or need to be introduced into Kadu 0.6.6 to make it a user-friendly multiprotocol Internet Messenger. We know the risks of radical changes to the design our users have enjoyed and gotten used to so far but we hope what we've come up with is good enough to both make our current users stay with Kadu and enjoy its enhanced functionality and improved usability and attract new users who either need a multiprotocol messenger or a user-friendly XMPP/Jabber client.

We still have few windows to design but those mockups should be consider as final GUI proposal for upcoming Kadu 0.6.6 version. We are eager to hear your feedback on our proposal. So if you have any comments feel free to comment!

Get Involved

Do you like our vision of usable multiprotocol messenger? Do you like our 'regionalization' concept visible in "Your Accounts Window - Add/Create Account", "Configuration Wizard" and "Adding a New Contact" window? Or maybe you like our efforts to integrate "branded" XMPP providers into GUI (which will probably lower the entry barriers for newcomers in XMPP world.)?

If additional you are interested or involved somehow in usability please consider joining Kadu Design Feedback mailinglist and became a member of UsabilityTeam. We have still many things to design, improve or fix. ;) Currently UsabilityTeam consists of two active contributors Joanna Pierożek and me. Previously the work on the Usability project has been conducted mostly in Polish. However during the summer we've switched almost entirely to English on the mailing list, in the documents and in the mock-ups we've produced. As far as the Usability project goes, we're ready to accommodate international contribution without making anyone feel intimidated. Hopefully, along with introducing XMPP/Jabber and other protocols useful for people from outside Poland into Kadu, regular contributors from other countries will indeed join our ranks.

Monday, 21 December 2009

Kadu 0.6.6 alpha0

Kadu 0.6.6 alpha0 was released.

Warning: This version will eat your children. Do not use if you are not sure what you are doing. Configuration file format was changed (configuration file too), history format was changed. Reverting back to older versions is be possible, but with loss of all new history and configuration changes. If you can, use new Kadu from new user or with CONFIG_DIR set to kadu_alpha. We will not provide any official packages for this version.

Alpha0 releases in Kadu are soft-API freeze releases. That means that no one is allowed to make big API changes (small changes are still allowed). Stability in general is very good, history works, chats works, file transfers - we don't really know yet ;)

Now we will focus on adjusting our GUI to mockups provided by Usability Team and on fixing remaining (less important) API parts - like Pending Messages, File Transfers or Status Chagner. Many modules needs to be adjusted to new API too.

And of course: stability, stability and stability ;)

ChangeLog available at gitorious.
Source package available at (2MB).

Good lock!

Wednesday, 2 December 2009

Storage Layer

Code I've started writing almost year ago (new configuration API) have grown to whole new layer of code. Now it is called Kadu Storage API and this is the first thing that will get documentation (by Doxygen) for new release.

This API has some really nice features:


Some classes, like Contact or Chat, have data that depends on some plugins (like XMPP/Jabber contact data, or Gadu-Gadu contact data, or IRC chatroom data, or ...). We want to give user view to this data even if plugin is not loaded/unavailable for some reason. So as much data as possible were extracted to generic classes like Contact, Chat, or Account (see how much extra data Gadu-Gadu needs for Account).This data can be loaded from Storage at any moment and be displayed to user and manipulated.
But that data cannot be used to do anything useful: you can't talk with someone on XMPP account if Jabber plugin is not loaded (but you can view this chat history). So when the plugin is loaded every object that depends on it loads extra data by using specific Details class. This class uses the same StoragePoint as main class so it can load extra data from the same configuration node. After extra data is loaded, the object can be used (to connect to server, make some chat and so on).

Shared classes

Shared classes bring some Java-like API to Kadu. It is just a trick to hide that given class is really a pointer. Just a good usage of QExplicitlySharedDataPointer and QSharedData. But with lazy-loading and StorableObject support ;)

Generic managers

Kadu has now two generic (template-based) managers: Manager and SimpleManager. The first one has built-in support for classes that use Details (like DetailsHolder subclasses) - it only exposes object without Details loaded when code explicitly asks for that. Just look for ChatManager implementation to see how little code is now needed to implement manager that fully supports loading/storing and many more features using these generics:


Simple constructors and intuitive behavior of StorableObject

StorableObject class (and all subclasses) has now only one constructor (instead of 4). Passing parent objects, node names and so on in constructors was replaced with nice virtual functions.

This class has now State field. It can has three values: StateLoaded, StateNotLoaded, StateNew. Code of load method is executed only if the state is StateNotLoaded. By default object is treated as "new" (so no need to load, but only default data is available). To make object "not loaded" (so it will be eventually "loaded") you need to set up its StoragePoint using setStorage method.

All that simple changes give more natural and intuitive feel of how this object behave. It also allows us to remove some code, because these new default are what we need in most of our code.

What is next?

After Doxygen documentation for Storage is written, I'll focus myself on little higher layers: Buddy Storage, Chat Storage, anything Storage to make sure everything is nice and clean ;)