Or at least as they are currently implemented. (Rambling rant alert!)
Almost every IM client on the planet has the concept of a group. You create a group, give it a name, and populate it with your contacts. At first glance, this is useful.
Having used IM clients since the latter years of AIM’s domination, I have consistently struggled with the best way to group my contacts. To this day I have no solution. Why?
Because the group model is inherently broken in that every major IM client out there allows one group per contact. This assumes that each person I know has exactly one type of relationship to me. A contact cannot be a friend, coworker, family member, and developer. You must pick one.
This problem is exacerbated by multi-protocol clients. Not through any specific fault of their own, but when they support connecting to many different services, you suddenly wind up with an overwhelming number of groups with no coherent purpose. If you didn’t name your groups exactly the same, or you used a different grouping paradigm, you are SOL and must merge the groups somehow. This becomes an impossible mess when the service on the other end (Facebook, for example) allows contacts to be in multiple groups. Which group they wind up in on your IM client may as well be random, and may not even be the same each time you connect. (Edit: Since writing this I have discovered that the XMPP server operated by Facebook does actually indicate to clients when contacts are in more than one group. Pidgin honors this.)
What we need is a cross-service “tagging” mechanism that lets me say “this person is a coworker at X company, and worked with me on Y open-source project.” Then, whether I am looking for coworkers at X or codevelopers on Y, this person shows up. Rules could be established so that “coworker at X company” membership implies “coworker” membership. This may at first glance seem like nested groups, but it is very different. It is completely free-form, and allows me to model my contact structure after how I interact with people in real life. Not some bizarre mutually-exclusive set of too-shallow or too-specific relationships.
Multi-protocol clients should then support tag equivalency, so that service-mandated groups can be rolled into a differently-named tag. Or ignore one account’s groups entirely, with everyone being rolled into one tag, with the possibility of local memorization of extra tags.
But the way things stand now, having groups at all is actually a hindrance to my communication. “Did I put that person in friends or coworkers? Or are they still in the service-specific default friends/buddies/oxygen-converters group?”
In lieu of a real solution to this problem, I want to disable groups entirely. Except… whoops… Pidgin doesn’t even let me do that.
I welcome everyone’s thoughts on this issue.
Ha this is one of my pet peeves. I solved it by grouping them into “Friends”, “Close Friends” and “BFF” s.
I hate them too
A friend of mine uses a similar “priority-based” grouping system. The model I present could be extended by allowing tag values, or tag forms such as “priority:5” and then allowing a sort based on the presence/value of a tag.
I personally think that they should be automatically sorted based upon usage. The people I chat with most should be available from the drop down menu in the tray. The next most should be visible when I open a buddy list of some sort. The last groups should be available only via search. Basically, the computer should tell me who my best friends are. The other relationships are interesting, but it should optimize for usage (also, usage is easy to implement; wc -l on the logs).
Oh, also annoying… A single person listed once per protocol. Why should I care what protocol is being used. I should be able to say “this person has the following accounts” and it should merge them automatically. It should also suggest merges to me.
@Nathaniel:
Pidgin can sort buddies “by recent log activity.” This doesn’t put them in the tray popup menu, but it will move them to the top of your list. Pidgin can also group accounts into one contact (I use this feature extensively) but it’s not automatic.
I understand where you are coming from. I tend to take the approach of, what is the contact first and foremost, that’s what group they go in.
Or, in what capacity do you most interact with them as, then that’s the group they go in.
Kadu – an open source client for polish IM network GaduGadu has this feature exactly. Groups are like labels and contact can have multiple groups.
It totally rocks.
The way I solved this in a game editor I made was to have each art piece (IM contact in your case) have a tag, but allow tags to have a category. When you go to add a tag, they are sorted by category and the categories also have an All option during filter (but not when assigning).
So in your case you’d have tags that look like
Work >> X Company
Open Source >> Project Name
I find you never really need more than one grouping layer for the tags, and it also allows adding filtering tags Work >> All, Open Source >> All, etc.
Oh, you’d also have automatic Service >> AIM, Service >> Facebook, etc.
I also think that tagging is THE way of sorting contacts.
am soooo frustrated that I’ll probably will develop my own IM.
does any of you know an open source IM ?
@Diego: Pidgin (http://www.pidgin.im) is one of the best F/LOSS IM clients around. I suspect that introducing tagging to the core would require quite a bit of work though.
I was googling for a pidgin plugin to do exactly what you are suggesting. I saw some project notes about the development of such a plugin to allow a label system as opposed to a group system for contacts in pidgin, but it has since seems to have faded into the ether. I hope someone picks it up and tries again to develop this. I agree with you wholeheartedly.