Tag: text messages

Missing BRacket

Last night then-classmate now-colleague Baada and I were having a long bitchy conversation, mostly carried over text messages (SMS). As the conversation developed and grew in intricacy, several threads developed. This is not unusual for a conversation with Baada – it usually takes on several dimensions, and it always helps having a mechanism to keep track of all the threads simultaneously.

That’s when we realized how much we miss BRacket, the local instant messaging system we had at IIMB (a version of DBabble). I might have written this before but the beauty of BRacket was that conversation was “offline”. There was no chat window, and you would reply to individual messages, like you would in email. While on one hand this allowed “offline conversation”,i..e. the conversation didn’t die if one person respond immediately like it can happen in Y!M/GTalk, the more important thing was that by having conversation history in each thread, this allowed for some serious multithreaded conversation.

While instant text messaging offers the former feature (you can reply to a message several hours later and still continue the conversation), the latter feature is lost. There’s no way to keep track of threads, and like a bad juggler you soon end up losing track of half the threads and the conversation peters out.

I don’t know if DBabble is still widely used elsewhere but it’s death knell in IIMB was sounded when Sigma (the student IT club) in its infinite wisdom allowed for a “chat mode”. Along with the conventional offline messaging system, it also gave the option of Y!M style chat windows. And having been used to Y!M, batches junior to mine started using this chat feature extensively. The immediate rewards of using it were huge – no need to hit “send” (I’ve even forgotten the keyboard shortcut for that), no need to open a new message each time it arrives, and so on.

While we held up the virtues of “old BRacket” (like i used to refuse to reply when juniors pinged me in chat mode. A notable exception being the famous “Pichai files”) there was no one to do that after we graduated. I’m told that the incoming batch of 2006 exclusively used chat mode. The two major advantages that BRacket offered over “window chat” were gone. GTalk came up sometime around then, and with its better and faster servers (the IIMB network was notoriously slow) it could easily offer as good if not better services than BRacket. It was clear then that BRacket would die.

I’m told that now no one uses BRacket. I don’t even have it installed on my last two computers. Unfortunately no other “offline-messaging” technology has quite caught on since then. And so I miss multithreaded conversation. It’s very sad, I tell you. I wonder if even DBabble is still used extensively.

It’s fascinating how some technology dies. You come up with a purported “improvement” which offers short-term gains, and catches people’s fancy. While people flock to the “improved version” in hordes, it turns out that the features that made  the original version so popular are now lost. And this new version has competition, and so the technology itself gets killed. All because of some purported “innovation”.

Relationships and the Prisoner’s Dilemma Part Deux

Those of you who either follow me on twitter or are my friends on GTalk will know that my earlier post on relationships and the prisoner’s dilemma got linked to from Cheap Talk, the only good Game Theory blog that I’m aware of. After I wrote that post, I had written to Jeffrey Ely and Sandeep Baliga of Cheap Talk, and Jeff decided to respond to my post.

It was an extremely proud moment for me and I spent about half a day just basking in the glory of having been linked from a blog that I follow and like. What made me prouder was the last line in Jeff’s post where he mentioned that my blog post had been part of his dinner conversation. I’m humbled.

So coming to the point of this post. Jeff, in his post, writes:

Some dimensions are easier to contract on.  It’s easy to commit to go out only on Tuesday nights.  However, text messages are impossible to count and the distortions due to overcompensation on these slippery-slope dimensions may turn out even worse than the original state of affairs.

I argue that it is precisely this kind of agreements that leads to too much engagement. The key, I argue, is to keep things loosely coupled and uncertain; and this, I say, doesn’t apply to only romantic relationships. I argue in favour of principles, as opposed to rules. Wherever the human mind is concerned, it is always better to leave room for uncertainty. Short term volatility decreases the chances of long-term shocks.

So if you contract to date only on Tuesday nights, and on a certain Thursday both of you get a sudden craving for each other. In a rule-based system, you’d have to wait till Tuesday to meet, and that would mean that you’d typically spend the next five days in high engagement, since you wouldn’t want to let go given the craving. There is also the chance that when you finally meet, there has been so much build-up that it leaves you unsettled.

The way to go about this is to not make rules and just make do with some simple principles regarding the engagement, and more importantly to keep things flexible. If you have a “I won’t call you when you’re at work” rule, and there is something you really need to say, this leads to wasted mind space since you’ll be holding this thought in the head till the other person is out of office, and thus give less for other things you need to do in that time.

You might ask me what principles one can use. I don’t know, and there are no rules governing principles. It is entirely to do with the parties involved and what they can agree upon. A simple principle might be “if I don’t reply to your text message it doesn’t mean I don’t love you”. You get the drift, I suppose. And the volatility, too. (ok I’m sorry about that one)

The mechanism design problem for scaling down that Jeff talks about is indeed interesting. His solution makes sense but it assumes the presence of a Trusted Third Party. Even if one were to find one such, and that person understands Binary Search techniques, it might take too much effort to find the level of interaction. I wonder if the solution to scaling down also is the Bilateral Nudge (will talk about this in another post).