Jabber Vision
Something’s not right with Jabber. There is not one major thing wrong with it, there are a bunch of little things. The problem is that when added up these little things form a major problem.
My intention is for this to be a guiding document. There has not been a clear vision for Jabber for quite some time—at least not an overarching vision which includes everyone from protocol designers to client authors to web site maintainers.
This document will be critical. In fact, during the upcoming months I’m going to attempt to be even more critical than usual. I will probably criticize your project at some point in time. Yes, yours. I do not do so to offend you or the people who have worked on your project—on the contrary, I very much appreciate the work everyone has put into Jabber. But like a father to a son, sometimes someone just has to tell you when you’re not living up to what you could be. None of us have been lately when it comes to Jabber.
This document will also be prescriptive. I’m going to tell you what I think you should do. No one will be able to accomplish all of the goals of this document on their own in any reasonable amount of time. If you’re not currently helping out Jabber I ask that you review this document, find where you fit in, and then contact me or the person responsible for that piece. Please.
I will attempt to follow the flow of what I see to be a typical user’s perspective on Jabber. I will discuss the breakdowns in that step. I will then tell you what you can do to fix it. You can feel free to disagree with me, but what we really need right now is focus.
Learning about Jabber
This one’s so rough I was going to leave it out in my initial thoughts of this document. What do people have when they first want to learn about Jabber? Pretty much just jabber.org, and that site is only barely for end users. The guides on it are a nice start, but it’s not a community site.
We need a centralized community-run web site which talks about Jabber and serves as a place for people to learn about it and meet other users. When I say a community-run site, I’m not talking about something like kuro5hin, I’m talking about something like planetquake (in the good days), or more appropriately, something like konfabulator’s site, quicksilver’s site (Note that quicksilver’s site is very good at conveying the point of quicksilver: it’s not user-friendly, it’s user-optimized. You have these choices. They’re not well-labeled but they make your path more efficient. Well done for software like quicksilver, but not what we want), mozillazine, or even spreadfirefox.
A group of people (not just one lonely person) need to get together and develop an outline and roadmap of development of a community-run site and then follow through. I’ve heard from at least one person who wants to do it. Contact them and help out.
The end user site needs a good name. The site needs to be vocal about and prefer specific clients. I’d go so far as to say that it should only recommend one client for Windows, one client for Mac OS X, one for Gnome, and one for KDE. Maybe two if you recommend one Jabber-only and one multi-protocol.
It may even be worthwhile considering having linux.somejabbersite.com, mac.somejabbersite.com, and windows.somejabbersite.com—Windows, Mac, and Linux users all have different expectations for software sites—how they should look and feel and what they should provide the most direct access to. Mac sites really need to look good and convey the image of the software they’re offering. Linux sites need to be clean and functional, and offer links to download the software, report bugs for the software, and obtain source code for the software as prominently as possible. Linux users are also more likely to be concerned about Jabber as a server than Mac or Windows users.
The site needs to have forums. Not just some forums thrown up like Gabber’s were, but real forums which integrate fully into the look and feel of the site. They need to feel finished and not partially under construction. Find some of the more active users and make them moderators. Don’t leave it all to one person.
The main goals of the site should probably be letting the user know what Jabber is, letting the user register an account (more on that below), letting the user know which client to download, and letting the user discuss things in a community. Any goals beyond that can and should be discussed later. Get these things done and implemented first.
If you’re interested in helping out with a Jabber end user web site, contact me: julian at jabber dot org.
Rachel Blackman has said that once a domain name is picked she can get the site hosted.
Registering an account
Every client does it differently. Some don’t do it at all. None make it as easy as it should be.
I’ve started putting ideas together for a web site form through which people can register a Jabber account. The first step is selecting a server. I need someone to help me put together a clickable map of the world. The user will click approximately where they’re from and then this script will return the closest Jabber servers to them. This will help the “only using jabber.org” problem. As a counterpiece, we’ll probably need a version of this script for people who wish to add their server to the list.
Regardless, I’ll probably use PHP or Perl on the backend and have the script do all the dirty work of setting up an account with the given server. Later it can even set up user information.
The source code to this script will be released so that people can use it on their own Jabber sites as needed, but a primary installation will be on the aforementioned community/end user site.
If you’re interested in helping out with a Jabber registration script, contact me: julian at jabber dot org.
Connecting to a server
Servers need help. If you’re a programmer and you’re interested in servers, pick one of them and help. Rob Norris needs help with jabberd 2. There’s even a great page for developers. Please, please help out if you can.
Publication/subscription service
This topic almost sickens me. There is no complete server component which implements pub/sub. We so badly need such a component to move forward with Jabber clients—it’s what client authors have been thinking about for such a long time. If you know Twisted or Python please help Ralph Meijer finish idavoll (or at least get all of the pieces we need for avatars).
Update: Ralph brings up that we need to get disco-publish fully supported in jabberd 2. I missed that piece. Thanks.
Using a client
Jabber clients are not anywhere near what they could be. There is not a single Jabber client which does not have one of these problems:
- it’s ugly
- it doesn’t implement very much
- it crashes a lot
- it’s hard to use
- it lets the Jabber protocol dictate its interface
There’s not much that can be done about interfaces simply because I’m becoming increasingly convinced that there are few people in the world who really get interface design. If you think your client is good, think again. It’s not. Let me repeat that: not a single Jabber client out there is actually good enough to compete with the likes of MSN Messenger, AIM, or Yahoo Messenger—and those aren’t exactly examples of good user interfaces.
So, what can be done? Well, for starters, just realize that your client is not perfect. Be willing to change it and accept criticism. But remember that users don’t want what they think they want and “the user is not like me.” While I don’t expect most client authors to do full-on Contextual Inquiries (though it would be really really cool if they did), I do think you can at least try. Learn how to do a “Think Aloud” usability study—there are resources out there. They don’t take all that much time and they’re relatively easy to do. They’ll help iron out the most obvious issues.
There’s a lot more that can be done interface-wise if the right people are found (there is a lot of talk among the Gnome community of this), but I don’t trust us to do those things just yet. The fact of the matter is that a lot of IM clients are/were popular in spite of their user interfaces, not because of. So other things can be done. (Don’t let that stop you from doing Contextual Inquiries and Think Alouds, though. I will praise you if you do.)
Oh, and a word about “cross-platform clients”: no. That’s not what we should be focusing on. Let’s stop starting new clients and fix what’s out there.
Moving forward
The biggest issue with Jabber clients is that once people use them they say, “I don’t see how this is any better than anything else.”
Ouch. What Jabber needs to do is get its act together. We need to implement the following components to get us up-to-speed with current IM systems, and then we need to implement a couple of things to demonstrate beyond a doubt that Jabber is capable of more than AIM or MSN could realistically pull off quickly.
Avatars
What a mess. I’m partially responsible for this one. We had some ideas for a protocol, and rather than implementing, we decided to try to get it worked out. The Jabber Council decided that it wasn’t worth it to go forward with the ideas we had because publication/subscription services would be coming soon. Here we are, about 4 years later, and we still don’t have avatars worked out.
We’re still waiting for a complete pub/sub implementation so avatars can be implemented “properly.” In the meantime, we have all sorts of people implementing avatars in all sorts of different ways. This is why we need people helping out with idavoll. As soon as we have enough done, I want to see people installing it on public Jabber servers, and I want to see client authors agreeing on and implementing a pub/sub-based avatar protocol.
Create new things
Back in the day, it was the client author’s role to implement new things. They would come up with something that they think users might want, then implement a test protocol, and then they’d talk to other client authors about standardizing it.
Client authors today do not get involved with this at all. They always complain about things not moving forward, but do little to move things forward themselves. If you have a good idea, implement it in your own temporary namespace. Yes, just implement it. Don’t talk to other people and figure out the be-all-end-all protocol, just get it implemented and see how it works. If it works out well, then you talk to others about whether it’s useful and needs standardizing. Then you can go and write up a JEP. I’ll re-emphasize: writing a JEP first is silly. Don’t bother.
If you are a client author, it is your responsibility to figure out what new or useful things people will need or want. You figure it out and you extend the protocol to implement it. It’s not hard!
Jabber mailing lists
An idea that I’ve had for a while that I would like to see implemented is Jabber-based mailing lists. Use pub/sub to set up groups which people subscribe to, then sending a regular message to the address sends to all the people on the list. This would be similar to MUC except act more like a mailing list and less like IRC. I’d love to see client authors implement this. It would be an excellent demonstration of how Jabber can differ from other IM systems, and other than avatars is a great way to get this pub/sub stuff finally off the ground. See what I said above and see what you can do. Once you get it working, then we can talk about JEPs.
Help
In summary: Help Jabber. Pick one of these things and contact me or the person in charge of that project. Get things done. You’ll notice that nowhere in this document did I say you should continue creating new JEPs which depend on things which haven’t even been implemented yet.
+5 on the ‘Moving Forward’ section, +10 to the ‘Create New Things’ in particular!
+1 to everything else. :)
The latest version of ejabberd which is included in Erlang REPOS includes a much improved pubsub-component: http://freshmeat.net/projects/repos/ So, there exists a good pubsub-component :-)
I’m iffy about considering Python/Twisted mainstream enough for a serious component… I’m not going to consider Erlang mainstream enough.
I appreciate the work that’s been done, but let’s not pretend that it’s for everyone.
They had the same objections for XUL, and see how mainsteam Mozilla and Firefox are nowadays…
Hi, I’ll spend your bandwidth with a really long post:
1. Learning about Jabber — Community site
This isn’t new. The last attempt is JabberCentral. Much of what you comment was already discussed there, maybe you can ‘reuse code’ :)
Wiki
Mailing list
MUC logs
JabberCentral.org (does not work now)
I think this project is mostly sleeping now.
Interestingly, there are a lot of community sites in languages different than english. I’m cofounder of JabberEs (site for Jabber advocacy, news, documentation and public Jabber server), webmaster and the main content contributor until now. I think that site looks and contains exactly what people need to start using Jabber. It can be improved, as everything, but it’s better than nothing.
You may know other examples that are not completely integrated/focused/complete, like amessage.info, jabberpl.org and jabberfr.org.
So, how can it be that there’s no english spoken Jabber community site? Go ask native english speaking Jabber advocaters :P
Registering an account
This isn’t new, again. There was some discussion on JabberCentral about this topic, and it was clear that a web form to register the account is a really good idea.
Example: JRT.jabberes.org.
You may want to take a look to Jabber Registration Tool to get ideas for your new script.
Using a client
I completely agree. I use Tkabber, I’m happy with it and it’s a good and complete client, but I know it can’t be used by Average Boy. Tk widget is not a good solution to make cool UI (Coccinella is probably the best looking Tk app).
When people ask me what client to use, I recommend Psi, Exodus, Pandion, Gaim… but they all lack one feature or another.
Connecting to a server
For the same reason Tk is not the best solution to make cool and nice looking clients UI, maybe C/C++ is not the best solution to make stable and reliable servers. Never again say never to Ejabberd (stpeter’s blog entry), powered by Erlang (wikipedia) ;) .
Of course, one thing is flawlessly administrate a stable and reliable server and another is coding in a language you have not used before, that nobody knows about, and nobody offers help, courses, books, etc. It seems we can’t have both of them right now. The willing coder can wait until C is a language aimed to code fault-tolerant long-running applications or take ten Erlang lessons and start hacking.
Publication/subscription service
You say: This is why we need people helping out with idavoll. As soon as we have enough done, I want to see people installing it on public Jabber servers.
It’s interesting that, since Ejabberd includes a Pub/Sub component, there are a lot of Jabber servers out there with Pub/Sub enabled. When that component is complete, then you’ll have pubsub-enabled servers already out there. When new Ejabberd servers are deployed, they instantly have Pub/Sub (and MU-Conference, and HTTP-Poll) ready, without having to deal with additional configurations, make installs, etc.
So yes, let’s hope Idavoll and Ejabberd embedded pubsub component are completed soon.
Jabber mailing lists
Ah, I thought about this same component some months ago.
For the rest of the post, I completely agree.
And for the rest of your blog, I’d link to thank your for the interesting hci stuff you publish from time to time.
Sander, there are comments about Mozilla and Firefox on the cross-platform article that is linked to. Take arguments about that there. The only reason Firefox has become so popular is because they managed to mimic Windows really well. A lot of Mac OS X users still hate it.
As for Badlop.. you assume too much. I’m well aware of JabberCentral and I was working on Jabber before JabberCentral was created. JabberCentral is dead. It also never lived up to what I’m claiming a community site should be.
If Erlang and ejabberd start shipping with mainstream Linux distributions, then I’ll change my mind. Right now, ejabberd is not good enough. I really don’t care to get into language wars about this—that’s the same problem Jabber has had since the start. If people want to learn Erlang, then they can hack on ejabberd. For everyone else, I wish they would hack on jabberd2 and idavoll. Those two are the ones that most production installations look at. If you tell a corporation they need to install Erlang they’re just going to look at you funny and say no.
Despite your claims, there cannot be enough ejabberd installations deployed because client authors aren’t bothering to implement all these protocols which are on top of pub/sub!
On the question of Servers, What about Jive Software’s Messenger. It’s Java so it’s slightly more mainstream than even Python. GPL, and has a company behind it. They also have a very easy to use Jabber Client API called Smack. Both are extendable so a new feature can be thrown in without changing the entire code base. The user interface to the server is cross platform since it is web based but it looks good. I personally think that this server is a direction to look in.
TC Out
“If Erlang and ejabberd start shipping with mainstream Linux distributions, then I?ll change my mind.”
Erlang is at least shipped with: Gentoo, FreeBSD ports, Debian (I think all versions), Arch Linux and Crux.
ejabberd:
-port for FreeBSD available
-Package appeared in Debian Sid some weeks ago
-Crux also has a port for ejabberd
-binary for Windows (it’s quite difficult to get it in the next Windows version as you know; for the moment only BSD guys have reached this ;) )
-Erlang REPOS which includes ejabberd can be used under Windows, MacOS X, Linux distributions and *BSD’s…this is all done with the *same* CDROM/USB Stick and *without* the need to install anything (Erlang included): just mount the CDROM/USB Stick/… under your OS and start ejabberd, if you like it, you can easily copy it to your hard disc…this is probably easier than installing the Java-server Jive Messenger as you need to install Java first (which even isn’t (easily) possible under all *BSD-systems!).
“Right now, ejabberd is not good enough. I really don?t care to get into language wars about this?that?s the same problem Jabber has had since the start. If people want to learn Erlang, then they can hack on ejabberd. For everyone else, I wish they would hack on jabberd2 and idavoll. Those two are the ones that most production installations look at.”
At least for installations under Windows I would *not* recommend to use Jabberd 1.4.X or 2: the only GPL options are Jive Messenger and ejabberd.
“If you tell a corporation they need to install Erlang they?re just going to look at you funny and say no.”
Corporations will be probably better off with Erlang REPOS or the Windows binaries of ejabberd and Erlang than a buggy, old, not-at-all XMPP compliant and leak Windows binary of Jabberd-1.4.2 or the source of a newer 1.4.3.1 or *patched* 2.0s4 (s4 and previous includes a remote buffer overflow as you know) and the need to install Cygwin.
Look, the part where I ask for help with servers is the smallest part of the document and the one I clearly cared the least about. Most people running larger-scale servers out there are running *nix-based servers, so your Windows arguments are moot. I’m glad Erlang is starting to be included in a lot of Linux distros, that’s good and means ejabberd has a larger market than I was expecting.
Nowhere did I say jabberd 1.4 was an acceptable option. This was a call for help. I want people to start focusing on helping existing projects rather than starting a ton of different servers. Regardless of Erlang’s popularity, I would like to see jabberd2 in a better state than it is. It can only get there with people helping.
I wish people would focus on the point of my article rather than arguing minor points about servers. This is not an article recommending what the best server to use right now is—this is asking for help to get things into the state they should be in.
“Most people running larger-scale servers out there are running *nix-based servers, so your Windows arguments are moot.”
I said that because you said: “If you tell a corporation they need to install Erlang they?re just going to look at you funny and say no.”
What I guess is that this kind of corporations use Windows and not *nix-based servers, if they do it is probably no problem for them to compile ejabberd if there is no package available. But if they can’t, even then they can use an easy method to use ejabberd: Erlang REPOS.
“I want people to start focusing on helping existing projects rather than starting a ton of different servers.”
I don’t see such a problem: AFAIK no new server was created the last year (ejabberd exist already since the end of 2002 as well as Jabberd14, Jabberd2, Jive Messenger, OpenIM and WPJabber do. But maybe I am wrong?
Hi,
I would also like to add a few more shortcomings of the Jabber network,
1) Transport Shortcomings
Many users rely on the Jabber transports to communicate with other legacy IM networks, such as ICQ, AOL, MSN and Yahoo. However, most of those transports are not very stable and complete. In fact, many of those transports are no longer supported or actively maintained.
Some of them also do not good support for different codepage. For example, I am still unable to send a Chinese ICQ message on my Chatopus client.
2) Server Instability
We rarely see a downtime in those public IM providers, such as ICQ, MSN. However, many Jabber servers’ downtime is quite significant that users can easily notice. While the distributed server architecture of the Jabber network is great, each Jabber server should also have a certain degree of stability. Ideally, they should have fault-tolerance and fail-over between servers.
For example, the jabber.org server has been going up & down quite frequently, especially in the past few months.
3) Where is voice?
VoIP is getting extremely hot these days. Look at Skype. It has become such a popular application.
But where is voice for Jabber?
Tony Cheung
Julian, please don’t mix Jabbercentral with Jabber Community Site.
The old Jabbercentral is dead, yes. But for a few months, we have been trying to create a new community site for Jabber ( http://jcs.jabberstudio.org/ ). Of course, it’s still in-progress work, and we don’t have much time to dedicate to this task (and most of the jabber community seems totally uninterested in it, or at least don’t want to help), so it’s moving slowly. But it’s moving !
Please read the links that badlop provided and send us comments on the mailing list !
Lucas, I understand that Jabber Community Site is separate from JabberCentral, but Badlop mentioned JabberCentral.
Tony, I agree about transports and stability, but our first steps need to be taken in the directions I argue above. Once we actually have a core server that’s easily installable we can start looking at transports again—but it’s clear Jabber is stretched far too thin right now. We clearly had a lot more people actively working on it back when the transports were developed.
As for server backups and fallover—jabber.org is at the maximum limit of an audience it was ever built to handle. People need an easy way to register with and use other servers. Once we actually have the core server work done (as I said above), then we can start looking into all this fall-over measures. Unless, of course, you have money to donate to get jabber.org the necessary hardware.
“The willing coder can wait until C is a language aimed to code fault-tolerant long-running applications.”
What’s the Apache httpd written in? The Linux kernel? Languages are a preference, but I never got my head around the aversion to C.
Anyway, thanks for getting this out there, Julian; you echo a lot of what I’ve been feeling from the sidelines. Nothing pisses me off more as a Jabber user than to see fifteen JEP updates a day coming down my RSS reader from Jabber Planet, but maybe one a week from Jabber Studio. The “how is this better than anything else” argument is spot-on, and it’s killing Jabber; it’s why my own Jabber server has basically deteriorated into a way for me personally to get onto the Other Systems via transports.
Again, I’m saying this as a fan, not a coder (at least not a particularly capable coder), but I’m more than willing to help with the web stuff, docs, whatever; drop me a line.
Growl vs Jabber?
Sometime last week I discovered remote growl, which looks to be really useful. I’d like to have some cron jobs on the Debian boxes that I use as servers, and have them report stuff to my PowerBook via growl. A few days later I discovered this post o
Yep, it all sucks. And now that Rob and myself have quit, this means Aleksey is the only productive OSS coder remaining. It’s a shame too, because with some decent funding we could have had Jabber finished in no time. Instead it will be 5 years. Oh well, nothing surprising.
Well said, Julian. You’re not the only one who’s disappointed: http://www.sauria.com/blog/computers/internet/1153 points to your entry and I’ve commented there as well. We all bear our share of the responsibility, but I do think that getting more people involved in contributing code patches, docs, translations, bug reports, feature requests, and maybe even money would help (heck, there are lots of big companies using Jabber servers and clients internally, but I don’t see them helping out despite their much more significant resources). A software certification program might not hurt, either.
What we are missing in Jabber
In some parts of this blog I will reference to Julian’s Jabber Vision.
As I go along with julian’s paradigm of “implement something and if it works publish it” I’ve done my pubsub experiments. The hardest part for me as a non-programmer was to…
Better late than never I guess…
I wrote up some thoughts on how a pubsub forum would work on the Blackboard Forum: http://blackboard.unclassified.de/268,1#1823
If cross-platform clients aren’t the way to go, does that imply that the Psi project is wasting its time? It seems to be the best client out there, though, and is only cross-platform because it’s written on top of Qt.
Perhaps this counts as single platform, then, where the “platform” is Qt. Sort of like all Java applications are really single-platform since they only run on Java. ;-)
You hit on it. Psi’s not really cross-platform. Qt only goes so far on Mac OS X and only goes so far on Windows (though much further than it does on Mac OS X).
Psi is unique in that there does exist a certain class of people who would really like a Psi-like interface. So Psi should certainly continue.
What people should not do is pretend that Psi is for everyone and we therefore don’t need clients that are actually easy to use.
While QT does only go so far on OSX, it should probably be noted that someone’s done a reasonable amount of work on Psi’s OSX-ness recently.
On the “What people should not do is pretend that Psi is for everyone and we therefore don’t need clients that are actually easy to use.” front, I don’t think we should pretend that Psi cannot be easy to use. Sure, there’s a bucketload of things wrong with the UI at the moment. Bucketload. But the devs know this. If the only thing going against Psi is the UI, then please go to the forums and start suggesting what would fix it for you (you=the readers, not just Julian). I don’t understand what, in the general sense, is wrong with the Psi UI, it seems to use the same general principles as other clients from what I can tell. Suggestions?
Most of us realize the things that are wrong in the current situation. One of the most important things is reaching new users, which depends on a very usable, good looking client. While Psi has a history of being an LICQ clone and being for power users only, the devs are very eager to do a lot of improvement on this front in the very near future. I personally am convinced this can be a very easy to use, handy, and good looking client, on _any_ OS. You just need people dedicated to accomplishing this.
The biggest problem i see in the current situation is the whole registering with a transport situation (having to authorize each contact etc.). The PyMSN-t developer reported this earlier, and was trying to work to a solution (but had a lot of problems convincing the rest of the community). Until this whole situation is fixed, i don’t see much point in trying to make people convert.
Creating an application and then going back to design the interface is completely backwards and rarely results in an interface acceptable to the majority I’m talking about. That is why I don’t really have faith in Psi’s ability to “become” more usable. From everything taught in design classes, human-computer interaction classes, and even some of the more enlightened software engineering classes, that’s just backwards.
Firefox came about because someone with usability know-how got into power and made the right decisions. He made hard decisions and developers listened to him. He helped design a new application from the ground up and then got the backend implemented (using existing Mozilla components, but not necessarily allowing them to dictate the user interface).
Gnome made large leaps in usability from 1.4 to 2.0 because they practically threw away everything and redid it all. They’ve only been inching forward since then. They probably won’t have another sizable leap until they throw away things again.
“If the only thing going against Psi is the UI, then please go to the forums and start suggesting what would fix it for you”—this is the wrong attitude and not how truly usable software is made. The “only” problem being “the UI” is the same thing as saying the only problem with a new car is that the steering wheel is facing the wrong direction. You don’t fix that by making minor adjustments to the existing frame. You can use the same engine with some modifications, but the frame has to go.
Maybe you misunderstood what I was saying, we basically are prepared to throw away bits of the interface that don’t work and start again. I was asking what was wrong with the current UI for when the new stuff gets written. Your analogy doesn’t quite hold true, because in the case of a badly configured wheel, the transmission will be screwed too, but holding with the analogy, what I’m looking for is for someone to say “The steering wheel needs to be facing the opposite direction”. We can work with that. The work resulting from it may not be fun, but it can be done. It’s not enough to just say “That car’s not good, make a new one”, it needs to be “Make a new car, and this time point the steering in the other direction”. We’re not looking to dump it over a version, but the UI’s modular enough to do complete UI rewrites of one major component at a time with the same result, and that’s what’s planned. I’ll honestly listen to anything someone has to say about the new UI except “you can’t fix it”. I’m not pigheaded about the Psi UI and believe you’re wrong about it not being suitable, I simply don’t understand. There are many things that I think need to be ripped out and rewritten in the UI, but I still feel the general feel is similar to other IM applications, Gabber included. You obviously believe differently, so I’m just asking for help. What is it about Psi that’s so terrible that isn’t in other IM apps? Please?
You’re right, I’ve not been specific enough to Psi’s case and you are being nice. I’m sorry, my issues with Jabber and usability have been building up over a long time and I in know way mean to be taking it out on you.
The general assumption that Psi and other Jabber clients make is that users “speak Jabber”—they know what things like “Resource”, “Roster”, and “Transport” mean. That’s a pretty bad assumption to make; both for people who have not been as exposed to IM and for IM users in general.
As a first step I’d take a step back and see what exactly a user has to know in order to set up Psi for the first time. What does the user have to know to start adding people to their contact list? Which pieces of terminology is it assumed that they understand? Look through this list and figure out which ones you’re comfortable with requiring them to know. You’re wrong. They shouldn’t have to know those either. ;) Really try to get the terminology into a state where users coming from no IM experience can understand it… and then try to make Psi usable without even understanding most of that. The best first-run interface is one in which the user needs to know nothing to get it running. The state of Jabber as a system isn’t where it needs to be for us to do that, but we can try to minimize it.
The second step is looking at the logical flow of the application: How many possible choices are there at each step? Does the typical user really need that many? Most features Jabber clients offer really aren’t needed/wanted by anyone other than hardcore Jabber users. There should be clients for hardcore Jabber users, yes, but there should also be clients where we don’t have 100 different smilies for a user to pick from and assume everyone organizes their list into groups.
To be honest, my largest complaint with Psi is that its look is wrong for anyone but the audience it currently has. It doesn’t have a simplistic, clean look to it. It looks complicated and utilitarian (like ICQ). Obviously people who want “lots of features” and love having something that feels like a leatherman will like Psi’s look, but most people would be put off by it. Saying “oh that’s ok, it has skins” is the wrong answer. A good client to fill the gap I’m talking about most likely wouldn’t even have skins. If it did, it wouldn’t be a primary feature used to solve all problems.
Ok, thanks. The terminology was one of the things that’s down to be overhauled in the very next version already (it won’t be enough, but it’ll be a start).
With the second flaw, of Psi just being too complicated, I guess there’s nothing to be done about that, I believe it can be worked around though, although many people are certain to disagree. Psi won’t be optimal for completely novice users ever, and I realise this, because we won’t sacrifice the leatherman power. As I say, however, I believe it can be worked around.
Taking an unnamed Word Processor with which everyone is probably familiar. In many ways it has horrible UI features (menus that change depending how long you have them open? Yuck) and it certainly has more features than any sane person can use (as well as missing some fairly crucial ones) but, it loads up and people can just start typing and not care. I believe we can get Psi to this stage, where novice users can start up, and use the basic features without hassle, and this is my aim.
Forcing people into grouping contacts was something I hadn’t considered, thanks.
As for skins, I agree entirely. I’m keen for Psi to *not* support skinning.
Well, if your aim is to be like Word, I would believe you could do that. Just remember that most people can’t use most of Word’s features—even when they need to. Word really needs to be divided up into a bunch of special-purpose apps with the same core (which is almost what they’re doing with the new “Notebook mode”—it actually removes a lot of Word’s features and only has the ones needed for taking notes).
If you can correctly identify the core features of IM and make them easy enough to use, you could certainly be the Word of Jabber clients.
“What is it about Psi that’s so terrible that isn’t in other IM apps? Please?”
Some points I see (I’m using Psi but I’m planning to migrate to Coccinella):
* slow release cycle
* difficult to test as you always need to compile the code
* no MUC
* no tabbed chat
* no whiteboard
* no statiscics gathering support
* no x:data support (and I heard the new version will not support that 100%)
* no typing notifications
* …
Right, thanks for the feedback.
* Slow release cycle. I’m trying to do something about this, but it’s not easy.
* You only have to compile code for CVS on linux, on windows there’s various builds reasonably frequently, and I’m looking for nightlies. On OS X there’s nightlies.
* no MUC. This is planned for the next release (discounting the one that’s about to be deployed)
* no tabbed chat. Yeah, this is a killer, but it’s way down on the priorities after things like muc and pubsub.
* Whiteboard. I had never considered this a killer feature, thanks for the headsup.
* I don’t understand what you mean by statistics gathering :/
* x:data. Is supported for services but not chats in the currently pending release.
* Typing notifications are in the currently pending release.
I’m not trying to persuade you away from switching, just saying that we’re not dead yet, and we’re trying to fight on, so please check back in 6 months or so and you might like what you see.
I don’t think that things are nearly as grim as this blog entry makes them out to be. Instead, I think that the notion of what much of the community wants Jabber to be is somewhat outdated. Specifically, I don’t think that a “Jabber network” to compete with AOL, MSN, etc is very viable or probable.
Instead, XMPP the protocol is starting to show up in all kinds of interesting places — in enterprise group chat, IM for internal networks, presence services, and online support. Instead of a website for consumer-level end users, I’d love to see a commercial-friendly website for protocol implementors much like sipforum.org. The focus of the community should be on trying to get developers to adopt the protocol and not to reach out to end users — that’s for client and server authors to do. There are a couple of steps that can help to accomplish this:
* Phase out “Jabber” in favor of “XMPP”. It’s the IETF name for the protocol and it’s a fact that the only commercial company using “Jabber” is Jabber Inc. It damages the community as a whole to have a commercially encumbered name. I can already anticipate all the counter-arguments, so don’t bother. It’s just a suggestion and not the critical part of my argument. :)
* Create an entity or expand the JSF to provide a certification entity for XMPP products. The Open Source side of XMPP will always be at the core of the community, but there needs to be a way to promote and encourage commercial developers as well.
On the client side — I think Trillian is doing a great job with their XMPP support and UI. Better UI in all XMPP clients would only help though.
So, although what “Jabber” is seems to be changing, from my perspective things are heading in the right direction.
Regards,
Matt
“If you tell a corporation they need to install Erlang theyâ��re just going to look at you funny and say no.”
I think you are missing a point somewhere: Erlang has been created by the industry for the industry. It is not an academic language and is already used by corporations.
–
Mickaël Rémond
http://www.erlang-projects.org/
Maybe so, but the point of this article was not to discuss Erlang and the viability of ejabberd.
For the record …
I’ve just finished setting up an internal jabber server at my work. After a whole bunch of looking around the *only* jabber server that I could find that had a decent web site and enough documentation to get going in a reasonable amount of time was ejabberd.
Now I have to admit that I was initially put off by the fact that it was written in Erlang but the fact that it was trivial to install and configure ejabberd (apt-get install ejabberd), get it integrated with our LDAP servers and setup shared rosters … has won me over.
This is the third time I’ve looked at setting up a jabber server for one purpose or another and is the only time when I’ve found a server which wasn’t so colossally annoying to learn anything about that I gave up in disgust.
Adam.
Yeah, since posting all of that I’ve tried setting up jabberd2 several times… and warmed up to ejabberd. :)
Didn’t had problems setting up jabberd2 but the last one … well that’s a different story :)
I should sat that most of us realize the things that are wrong in the current situation. One of the most important things is reaching new users, which depends on a very usable, good looking client. While Psi has a history of being an LICQ clone and being for power users only, the devs are very eager to do a lot of improvement on this front in the very near future. I personally am convinced this can be a very easy to use, handy, and good looking client, on _any_ OS. You just need people dedicated to accomplishing this.