Tuesday, March 09, 2010
Button order in web browsers and phones
Saturday, November 17, 2007
Semi-synchronous telephony with call invitations
Consider the relative advantages of text messages and phone calls:
- For activities requiring actual dialogue rather than notification, text messaging is incredibly inefficient: the interface is terrible and an exchange requiring N round trips requires 2N text messages, each of which requires that a human being fiddle with a phone and compose a new message. On the other hand, text messages do not require that the person on the other end be instantly available in order for the message to be received.
- Conversely, phone calls are excellent for negotiation: an exchange requiring N round trips can be conducted within the space of 1 phone call. However, if the person on the other end isn't instantly available, then you are stuck either leaving voice mail (leading to the possibility of phone tag) or calling repeatedly, which is also incredibly annoying.
What's needed is a technology that merges the best of both worlds: the ability to do rapid synchronous dialogue, and the ability to initiate that dialogue without the human having to play phone tag or to call repeatedly.
As it happens, voice mail and calling repeatedly correspond exactly to the two usual mechanisms that computer communication protocols use when one process wants to receive a communication from another process but doesn't know when that communication will be ready. For the nerdy people who care, voice mail is registering a callback, and calling repeatedly is polling. But never mind the jargon: the important observation here is that computers already know how to do this sort of thing, and do it all the time, so it's stupid to make human beings do it.
Therefore I propose the semi-synchronous phone call, or "call invitation" for short. Here is how it works:
- Alice wants to talk to Bob. She sends him a call invitation.
- The invitation goes into both Alice and Bob's invitation inboxes. An invitation has two possible states for each user: "available" and "busy". By default, all invitations are initially available for the caller and busy for the callee.
- Bob now has three choices:
- Bob can do nothing, which leaves it in his invitation inbox.
- Bob can refuse the invitation, which deletes it from the system.
- Bob can mark himself "available" for that invitation.
- Alice has the same three choices, except that she's initially available for the invitation. She will have to mark herself "busy" if she starts doing something that would stop her from talking on the phone.
- At any time, either Alice or Bob can toggle their status (available or busy) for the invitation. Talking on the phone implicitly toggles you busy for the duration of the call.
- If, at any time, both Alice and Bob have marked the invitation available, they receive a phone call connecting them.
Now, no doubt many similar proposals have been made in the past. I'm specifically aware of proposals in the ubiquitous computing community for communication devices that act differently when you're available than when you're busy. Some of the fancier proposals involve the device or the environment sensing (via sound, motion, or whatever) when you're doing an "interruptible" activity, and automatically marking you available or busy.
However, I am not familiar with any proposal that works exactly the way I propose, and I claim that even small deviations from exactly the above design would result in a system that people would hate.
To begin with, in my proposal, people explicitly mark their availability information. I believe that availability must be volitional. Imagine if your phone decided on its own whether to ring, and whether to vibrate or ring audibly. Or imagine if your front door decided when to open in response to a knock based on your past behavior towards that person. On a deep, primate level, humans do not feel emotionally secure when their social approachability is outside their control. Implicit signals like body language work for controlling approachability in face-to-face interaction only because humans can volitionally and unambiguously broadcast these signals, and because other humans react instinctively with extremely high fidelity.
Furthermore, in my proposal, availability is relative to each message. It is not a universal property of the user: there's no such thing as "your" availability, only your availability reacting to a given message. This is important for several reasons. First, you never have to think about your availability when no invitations are pending in your inbox, which means you're not constantly toggling your phone into "available" or "busy" mode. Second, you're never broadcasting any information about your availability, which preserves your privacy.
Some proposals make a user's availability relative to a priority: you can say you're available for "high priority" calls, but not "regular priority" or "low priority" calls. Other proposals make availability relative to a user and a caller: you can put someone on your whitelist, which means that you always accept calls from them.
Such priority schemes sound like a good idea, but they would fail to solve the problem for two reasons. First, no code-based priority scheme could deal with the complexities of actual human interaction. Second, such priority schemes actually force the recipient to expose more information, with the putative aim of increasing privacy; this gets the problem fundamentally backwards. Consider the problem of setting your availability for calls from your in-laws, or someone you just started dating.
Every successful interpersonal communication technology leaves room for ambiguity in social interactions. Why didn't you answer the phone the other day? Maybe you were busy, or maybe you didn't want to talk to that person, or maybe you wanted to take the call but you're playing hard to get. Why didn't you respond to my text message/email/Facebook note? Maybe you haven't logged on lately, or maybe you can't stand me. Like it or not, human beings prefer the ability to deceive each other socially. My proposal preserves social deception in a way that priority schemes do not.
In fact, if there's any flaw in my proposal, it's this: I seriously think that many people choose media like text messaging, instant messaging, email, and social networking sites precisely because they do not want to talk, even when it would be more efficient. Talking on the phone forces you to interact even more instantly than instant messaging. It also exposes the vast amount of sub-verbal information that carries through your human voice whether you want it to or not, including, first and foremost, your emotional state. In the end, voice communication may be growing rarer precisely because it's not good enough at helping us conceal our true selves from each other.
Monday, October 30, 2006
Weaknesses of non-dictatorial community software projects
As an inveterate user and observer of open source, I've read many criticisms of open source software development that simply don't hold water. This post is about one criticism that I believe does hold water.
In contrary to the straw man often erected by anti-open source pundits, most open source projects have a relatively formal management structure wherein one person or a committee exercises strong top-down control over the project's canonical source code repository. That dictatorial hand may be felt lightly or heavily, but at the end of the day decisions must be made, and priorities set, and the project will follow the dictator/committee's decisions.
(Or --- in the case of a fork --- not, but nobody likes forks and ultimately each half of the fork generally assembles some sort of management structure.)
However, not all open source projects have a dictator. A few projects manage to survive with only informal technical governance structures. The largest and most successful of these is probably KDE, a desktop environment. KDE has a number of associated formal legal entities responsible for things like legal and marketing issues, but the technical direction of the project is not managed by either a benevolent dictator or a committee.
There are good things and bad things about this. Here is one of the bad things: this KMail wishlist item has been in the bugs database since December 2000. It is the top vote-getter on the most requested features list. But nobody has tackled it. A couple of people have made gestures in the direction of implementing it, but no bug-closing patch has been committed to the trunk.
In an open source project with a dictatorial or committee-led governance structure, somebody would long ago have cracked some heads and gotten this feature implemented. In a commercial software project, open source or non-, some engineer would be assigned ownership of this feature; and goddammit, if that feature didn't get implemented and maintained, that engineer would be fired and the feature would be assigned to someone else. But KDE's headless. It's less like a mammal with a central nervous system than an enormous amoeba whose various pseudopodia ooze tropically in the direction of "developer itches" and "coolest implementation hacks" (hence the recent proliferation of "hugely ambitious infrastructure refactoring" subprojects like Plasma or Solid) rather than unsexy, annoying-to-implement features that merely provide value to end users.
Now, as a by-product of this process, you often end up with a lot of excellent software. I use KDE every single day, and on balance I prefer its interface to both Windows and Mac OS X for intensive use.[0] But this software process isn't rationally optimized to serve the end-user, and so there will always be these frustrating little blind spots.
Which isn't to say that commercial software processes are rationally optimized to serve the end user either, but that's another whole series of posts waiting to be written.
(See also: Bug 8333, Bug 55777.)
[0] Yes, that's right --- not the code, not the customizability, not the Free and open source license, but the user interface of KDE is preferable, for a heavy user, to either of the big consumer operating systems. Windows XP and Mac OS X ---especially the latter --- are both highly polished and acceptable for casual use. However, when I'm juggling several terminals, eight or nine Emacs windows, and a half-dozen Firefox windows, the extra features of KDE's window manager simply destroy even Mac OS X's. Ironically, some of KWin's best features were in the classic Mac UI, and were dropped in OS X. (I first got hooked on windowshading when I was an undergrad Silicon Alley web production intern, juggling BBEdit, Photoshop, and multiple versions of Netscape. Ah, the old days...) Other features, like window gravity, have been pretty standard in Unix window managers for years, but have somehow never cracked consumer OSes even though they seem like no-brainers.
Monday, February 13, 2006
Random bitching about email software
Notice to all email software developers: one of the primary functions of email is to pass around URLs. You may not like it, but it's simply a fact of life. I'd guess that 90% of the email that I send or receive contains some form of URL, even if only in the sig. Therefore, any email client that "helpfully" word wraps URLs at 80 characters (or any other fixed width), when sending or forwarding or doing any other operation on email, is utterly broken. Designing email software with this misfeature is like designing a cell phone that sometimes randomly hangs up the phone when somebody says the word "hello". It's like designing an automobile that sometimes randomly stalls when it's at a red light that changes to green. It is, in short, completely absurd.
I use a mixture of Pine, KMail, and GMail for my email clients, and none of these has ever word-wrapped a URL on my behalf. Bless you, Pine/KMail/GMail developers. However, I still receive a fair amount of email, via mailing lists especially, that contains word wrapped URLs, and I am so freaking pissed at those anonymous software developers, somewhere out there, who are responsible for all the times that I have had to copy and paste bits of these URLs manually into a web browser. Come on! As Stephen Colbert would say, you're on notice.

