The other side of the moon

Alex Limi has an excellent post on the overuse of checkboxes in Firefox's preferences screen. It reminded me of something Nat mentioned during his talk with Miguel de Icaza back at Linux Bangalore 2003 about Gnome. They mentioned several UI idioms including checkboxes and disabled menu items, but the gist of it was, every time you give the user a decision to make, you're making their lives harder. As the domain expert for this product, it's your job to pick sane defaults and not bother the user with these choices.

We took this to heart on the Ayttm project. At the time ayttm probably had over 200 user modifiable configuration options in the preferences screen, and each plugin could add its own. It was way past the point of violating one of our primary design requirements, that it should be easy enough for Colin's mum to use. We had a bit of a dilemma though. While our target audience was definitely non technical, we had a significant number of geeky early adopters who really wanted the ability to modify everything.

Over the next few days we stripped out almost every configurable option from the Preferences screen, however, we left them all in the config file on disk. Any user that really wanted to modify the options could edit the config file in their favourite text editor and make the changes themselves. This made everyone happier. Our technical users were happy that they didn't have to click through too many screens to change all their options, and our non technical users had a preferences screen where the most they'd have to do was enter their account information, and the type of smileys they wanted.

The Gnome Human Interface Guidelines cover a lot about designing intuitive interfaces, so go read that.

An Introduction

In late April 2008, we received an email^[1] on the ayttm-users mailing list. It was from George, which wasn't a name I'd ever seen on the list before, and it was about something called Puppy Linux^[2], a distribution I'd never heard of before. He started out with a description of the distro, stating that he was a user, and had picked up ayttm^[3] based on the suggestion of the creator of Puppy Linux on their chatroom.

As part of his introduction, he included this paragraph:

I am very new to all this. Although I was a programmer years ago, I was away from computers for about 20 years. I have been on the internet for about 14 months - with no previous internet experience. I got Puppy Linux up and running less than 6 months ago - no previous linux / unix experience. I've been using chat rooms about two months - again with no previous experience. I only use irc.FreeNode.net and I access almost exclusively the Puppy Linux chat rooms.

I need to give you this background so that you will know that there is a very good chance that I will think the program needs work when the truth is that the user's inexperience is the real problem.

He proceeded to explain how he uses IRC, first with xchat^[4], and then with ayttm. He went into great detail, starting from how he launched the program to how he got to his final intended task, how much time it took him to cover each task, the problems he saw along the way, the kind of internet connection he was using, and finally some suggestions and opinions. For each of them he explained how it would help him and others like him, and how important it was to him relative to the other problems he saw.

He closed telling us that he was really happy with ayttm, inspite of the problems he faced, and if we could fix the problems he listed, it could become a core part of the Puppy Linux distribution.

... I am amazed at the level of functionality you have put into a small package. Please keep up the good work.

I hope you find something of use in all this,

George

In all, his email worked out to 5 printed pages.

I thanked him for his report. It was easily the best problem report we'd ever received on ayttm. All past reports read something like, "Foo doesn't work for me", and were typically no longer than 3 lines, and included no description of the environment under which it was run.

George's message included a lot of detail of the problem itself, but it was composed in a very friendly, almost self-deprecating tone, suggesting that it's quite possible that all the problems he sees are really PEBKACs^[5]. He never once sounded condescending, or as if he was doing us a service by writing up this report, and he threw just enough flattery to make us feel good, but not too much that we felt he was trying to play us. Most importantly, he'd by far put more effort into writing the report than any other bug reporter had.

He didn't pester us further to find out whether we were going to implement what he asked, or when it was going to be done, but he stayed in touch on the fringe, playing ayttm representative on the puppy linux forums.

In the meanwhile, Barry, the author of Puppy Linux sent us a few patches.

I should mention here, that since ayttm implemented the Yahoo! Messenger protocol, and I was (and still am) employed at Yahoo!, I couldn't contribute any code to the project (I'd worked on ayttm from the start before joining Yahoo!), however, as all the problems George reported related to IRC, an open protocol that predated Yahoo! by a long time, it was deemed okay for me to support this part of the effort with design comments, code reviews and some amount of requirements analysis. This meant that Siddhesh, the only developer at the time, could spend all his time hacking.

Siddhesh spent some time rewriting all of IRC support, and passed on an alpha to George and Barry to test. About a week later, George got back to us with a complete log of his IRC session running ayttm in debug mode. It was now early June.

Rejection

We also started chatting on IRC around that time, and he said he wanted to do more than just file bug reports and send in debug logs. He used to be a programmer, and though the language was different, the logic's more or less the same.

I told him which source file he could look at to find the feature that bugged him the most, and he sent in his first patch a little while later. It looked like this:

- /* get list of channels */
-       ret = sendall(ila->fd, "LIST\n", strlen("LIST\n"));
- 
+ /* get list of channels  commented out GWB per PST 7Jun2008
+  *    ret = sendall(ila->fd, "LIST\n", strlen("LIST\n"));
+  * 
+  * and following line added
+  */
+    irc_finish_login(ila);

Not a big deal you might think. It actually cuts out a feature in fact. But what it really does, is allow someone to use ayttm for IRC without timing out. So, sure, he used spaces instead of tabs for indentation, but that was fine. The most important thing is that he was now so invested in this, and he'd got his foot in the door, he didn't want to stop.

His patch was not accepted, and Siddhesh explained why (it broke the room list dialog), but Siddhesh also had an alternate fix for the problem that he asked George to test.

Come back

Many new developers get turned off at this point. It takes a lot of effort to create your first patch, and a lot of self-confidence to group of people that you know only by their mystical handles and semi revere for doing things that you can't. Getting a rejection at that point can set you back on both counts. Not George. We chatted some more, and he set to work on the next thing that bugged him. This is what he posted to the list:

... I have made some changes to offline_queue_mgmt.c. The diff file is attached.

Bluesmoon says that with my changes he always gets auto logged in. My own results are more random, although I sometimes get autolog. I suspect Ayttm? recognizes bluesmoon by his keyboard touch and remembers him fondly ( he is a former Ayttm? developer ), and treats him better than me.

Again, there's that bit of humour in there that suggests he's having fun doing this. Happy developers write good code. His patch got in.

Now in mid-June, he sent an update^[6] on the status of his tests, this time addressed at Siddhesh:

Siddhesh,

As you know, I have been downloading the latest source and testing it almost as quickly as you commit. I have been testing your tagged branch libirc-mod. I thought I'd take a minute to document the current Ayttm? status....

The name

Apart from his first email to us, George always put a question mark at the end of Ayttm. He now suggested that we add the question mark permanently as part of the name as an allusion to what it stands for ("Are you talking to me?"). Neither Siddhesh, nor I thought it was a good idea because as it turns out, many fonts use the ? character when they don't have a glyph to display for a particular character (others use a box), and we didn't want to confuse users with this. Another rejection of George's ideas, but he realised that while we were turning down his ideas, we weren't turning him down.

One thing that a lot of individuals forget about when communicating over email, IM or IRC, is that the person with the idea is not the same as the idea. This holds for both, the individual with the idea, and the individuals reacting to it. I've seen too many cases where either the person proposing an idea was attacked because the idea wasn't liked, or the person proposing the idea took a rebuttal of their idea too personally and thought that everyone hated them. George didn't have these notions, and his attitude in email made it impossible for us to feel any animosity towards him.

The Pup

In July, George posted this message^[7] to the list:

This was just posted on the Puppy Linux lead developer's blog.

Ayttm will be builtin in the next alpha release of Puppy Linux.

Feels like a big win to me - I don't know why - I didn't write it.

Indeed, George was way more pleased than we were. I'd guess it had to do with seeing two projects that he cared deeply about getting so closely coupled. Almost like watching two of your close friends getting hitched. The ayttm dev team still knew very little about Puppy Linux (I was a RHEL & Ubuntu user, and Siddhesh worked at RedHat). George, on the other hand, made it happen.

George turned into our liaison on the Puppy Linux forums. He'd collect bug reports from Puppy Linux users, verify them and then pass them on to the ayttm bug tracker on sourceforge. We chatted quite a bit over the next few months about new features he wanted to add and bugs he wanted fixed, what he thought of the changes. At one point I suggested that he speak about his experiences with ayttm at a conference^[8] in India. Siddhesh and some of the other developers were doing talks of their own. He considered it, but decided against it because of his age.

It was only then that I found out how old he was. I won't reveal that here since it was in a private conversation, but I have a fair way to go before I get there, and I hope I'm as enthusiastic as he is when I do.

I haven't heard from George in a while, but I've also stopped monitoring the ayttm bug tracker, so perhaps he's active there.

I should also mention as an afterthought, that even though I've referred to George as "he" throughout this post, I don't actually know if I was speaking with a man or a woman. It never came up, it was never important, and knowing it wouldn't have changed anything. I assumed he was a man because George is most commonly a man's name. Back in India, the only time I'd ever heard of George as a girl's name was in Enid Blyton's Famous Five^[9]. And in that, I learnt another lesson from George.

When it comes to hacking on opensource software, none of age, gender, race, country of origin, or how you look matters. All that matters is a pleasant attitude to your fellow developers, a willingness to keep at it and learn as you go, the drive to not give up when things don't go your way, and the ability to tell the difference between an idea and the one who has it.

Thanks George. To answer your first email, yes I did find much of use in this.

References

1. George's first email to ayttm-users. Yes, we use sourceforge. It's not pretty, but it's all we had at the time.
2. Puppy Linux, a small, fast and easy to use linux distro
3. Ayttm - Are you talking to me? A universal instant messenger for unix
4. xchat an IRC chat client for X.
5. PEBKAC in the Jargon File.
6. George's update on June 19, 2008.
   
7. Ayttm on Puppy Linux. In July, George announced that ayttm had become part of Puppy.
8. FOSS.IN - India's largest community run conference on free and opensource software.
9. Enid Blyton, The Famous Five. 1942-1963.

If you use the jabber service on ayttm, you may notice the main window appears to freeze up at times turning completely white. You can still chat, and clicking on the main window makes contacts visible, but it just doesn't refresh on its own.

This happens because of a problem with the jabber module and I haven't had a chance to figure it out yet. What I do know, is that you can unlock the application without restarting it, but you need to resort to a teeny weeny bit of geekery.

First, find out the pid of the running ayttm process:

   ayttm_pid=`ps -u philip | grep a[y]ttm | cut -f2 -d' '`

(I use [y] instead of y in ayttm so that the grep process doesn't show up in the list).

Once you have your pid, start gdb telling it to attach to this pid. Different versions of gdb have different ways to do this, so check the man page, but two common ways are:

   gdb ayttm $ayttm_pid

or

   gdb ayttm -p $ayttm_pid

Ok, so pretty much anyone could have told you how to get this far, it's going forward that needs a wee bit of knowledge of the source.

I'll save you the trouble and tell you that you need to look into jab_recv. File descriptor for the jabber socket (stored in j->fd) has closed, but the code is stuck on an infinite read. You need to set a breakpoint on jab_recv, and close the ayttm end of the fd:

   bt jab_recv
   cont
   n
   n
   p close(j->fd)
   deta
   ^D

That's about it. You'll get an alert telling you that the jabber server closed the connection. Click Ok, and proceed as if nothing happened.

Update:
Finally, there's really no reason for you to do all that. Here's the one liner shell script (broken for readability) to do it for you:

   echo -e '\n\n\nb jab_recv\ncont\nn\nn\np close(j->fd)\ndeta\n' | \
      gdb ayttm `ps -waux |  grep a[y]ttm |  cut -f2 -d' '` &>/dev/null

One of the things that drew me to Everybuddy, its USP really, was fallback messaging. I haven't seen any other client (other than eb's offspring -- ayttm and eb-lite) implement this feature, which is why I've never switched to another client.

So, what is fallback messaging?

Consider two friends who communicate via various network oriented means (IM, Email, SMS, etc.), we'll call them bluesmoon and mannu (because they are two people who communicated this way for several years before meeting IRL). Now, said friends are extremely tech savvy, and have accounts on virtually every server that offers free accounts, and then some.

So, you've got them on MSN, Yahoo!, AOL, ICQ... um, ok, not ICQ because ICQ started sucking, Jabber, and that's just IM. They prolly have 3 or 4, maybe 5 accounts on each of these services, ok, maybe just one on AOL. Then they have email accounts. The standard POP3 accounts, 3 gmail accounts, a Yahoo! account for every yahoo ID, and likely no hotmail accounts (even though they have MSN passports) because we all know that hotmail is passé.

These guys also have lj accounts and one or two cellular phones on different service providers.

Ok, now that we have our protagonists well defined, let's set up the scene.

Act 1, scene 1

Mannu and bluesmoon are chatting over, umm, we'll pick MSN to start with. So mannu and bluesmoon are chatting over MSN, when all of a sudden <insert musical score for suspense here> a message pops up:

The MSN server is going down for maintenance, all conversations will now end

Sweet. So MSN decides that we're not allowed to talk anymore.

What are our options? Oh well, Yahoo!'s still online, so switch to Yahoo!. It's much nicer too because you can chat while invisible too. MSN (officially) doesn't let you do that.

So, they switch to Yahoo!, but... what the heck were they chatting about when the server went down? Context lost. They need to start a new conversation, most likely centred around cursing MSN. What's worse is that the earlier conversation was being archived because they may have needed it as a reference later. The new conversation can also be archived, but it's a pain to merge all these different archives later.

Anyway, they plough ahead. The conversation veers back on topic, ... but now the main net connection goes down. The only things that work are websites and email. What do you do? What do you do? Ok, Dennis Hopper I am not, so let's forget I said that.

The easiest option would be for bluesmoon to send a mail to mannu saying, "Hey dude, my net connection went down, gotta end the convo here.", or he could send the same in an SMS. But to do that he's gotta start yet another program and type out stuff out of context again, or worse, type out an SMS that he has to pay for!

So, here's where fallback messaging comes in.

Act 1, Scene 1, Take 2

<jump back to the MSN chat>

Where were we? Oh yeah, the MSN server goes down. Now, what if the chat client we were using was smart enough to figure this out, and do something about it. What's that something you say? Switch to the next available service. So, in this case, the chat program would automatically and seamlessly switch to using Yahoo!

There's several user centric pluses here. The people chatting do not need to know that a server went down, leave alone care about it and figure out what to do. Archives will be maintained across sessions. The context of the conversation will be preserved. Mannu and bluesmoon can go on chatting as if nothing happened.

If all the IM protocols go down, the chat client could switch to Email or SMS. Of course, mannu should have to tell it explicitly to use one of these, because the conversation will no longer be online. There's gonna be delays between sending the message and getting a response, so the chatters need to know about this.

So, how does your chat client know that you have buddies on multiple services, and about their email address and phone number?

Well, the chat client would have to group accounts on various services into a single contact. This kind of grouping also has other benefits.

Two people chatting with each other now don't have to think about user names and different services and what not. Mannu wants to chat with bluesmoon, he just selects bluesmoon from his buddy list. He doesn't have to care whether bluesmoon has an account on MSN, Yahoo!, AOL or whatever. Why should he care? So, I'd be chatting one to one with another person, without caring about what happens behind the scenes. Isn't that what makes for a good play?

Well, at some point mannu would have to care about services and user names, because he'd actually have to manually add and group all these accounts into one. Perhaps he could also set preferences of the order in which to fallback. That's all a one time set up. For the continuous ease of use to follow, I'd say it's worth it.

Final questions...

Is this really possible? Yeah, sure it is. You can thank Torrey Searle for that. Torrey implemented everybuddy to do just this, and threw in loads of sanity checking - thanks for that dude. It's what drew me to use and then work on the project for so long.

So, is this really possible? Probably not until IM companies decide that the network is just a transport, and it's the value a user derives from using that transport that makes them choose one service over another. It's why we choose the Mumbai-Pune expressway over NH4 that runs through the ghats, even though there's a toll.

Update I did a talk on fallback messaging at Linux Bangalore 2004