Monday, October 1, 2012

Thinking Out Loud: Clients For Twitter And For GitHub Notifications

Twitter's too useful not to use at all, but I can't use it as intended, either. I get a lot of unanticipated communication on Twitter. I also get a lot of unwanted communication on Twitter. The first major problem of Twitter usability is differentiating unsolicited communication from unwanted communication.

A few years ago I came up with a plan for fixing this: a Twitter summarizer which, in addition to screening out any tweets from people who I don't follow, would also recognize similarity within tweets and summarize highly similar tweets, making each one optionally visible but hidden by default.

For instance, if 100 people you follow all tweet a link to the same blog post, all you really need to know is the link and how many people retweeted it. You might also want to know some of the specific individuals in that crowd, but you absolutely don't need to see that same link 100 separate times. This feature would be even more useful in eliminating the annoyance inherent to seeing the same joke or witticism retweeted or rephrased countless times.

That feature is definitely worth building. But banning tweets from people you don't follow -- that's a very blunt instrument. A superior alternative might be segregating people you don't follow in a kind of quarantine, or subjecting them to negativity screening -- i.e., filter those tweets through sentiment analysis, and only show tweets from strangers when those tweets meet or exceed minimum levels of politeness or positivity.

When your friends are mad at you, you need to know about it. When some random Internet dickbag has a grudge against you, the absolute most information you might need is a temperature-like ambient Internet hate meter.

If the hate gets truly severe, you might want to take a peek to find out what people are so worked up about, but nine times out of ten it's not worth any attention at all.

Basically, most people who design Twitter clients work on the assumption that they're building windows onto a stream of data you want to watch. I think the best way to design a Twitter client is to build a robot receptionist.

Much of the above applies to GitHub notifications, but there are special considerations for GitHub. First of all, if I'm cc:ed in a GitHub notification, that notification does not currently receive any special highlighting within GitHub's UI. I have many many times missed GitHub notifications intended for me personally due to the overwhelming volume of other GitHub notifications in the same project.

Second, GitHub allows you to turn off notifications by project, but this is a coarse-grained solution. I'm guessing plenty of people out there need to know every single thing about one branch of a project and nothing at all, ever, about another branch of a project. You have access to project, branch, message text, filenames, dates, and languages; if I'm only interested in JavaScript notifications for a given project, or if I'm only interested in notifications on X branch but not Y branch, or I want to see messages which mention me by name in a special prioritized box, this all should be trivial information to obtain, and trivial UI to implement.

Imagine for the sake of argument a GitHub notifications API, with all this data contained in JSON objects. You hit the API, you pull your notifications, and then your lovely little robot butler reads through all these notifications, searching for indicators that you are likely to give a shit.

Perhaps it's difficult to accept this, but the appropriate response to nearly all Internet communication is "fuck off and stop bothering me." This is an unpleasant thing to say in real life, which is why you should instead have software doing it for you.

In every form of Internet communication, the number of messages you give a shit about is always much smaller than the total number of messages you receive. Software design for messaging clients virtually never acknowledges this fundamental and consistent reality.

The cult of inbox zero is a ship of fools. It is the information-age equivalent of a slave religion, where you glorify the most obedient slave to an insane master. You should not get a high five and a merit badge every time you get to a state where you can calmly and intelligently choose what to do next; being able to calmly and intelligently choose what to do next should be your default state.

People really need to design messaging systems around the obvious reality that give-a-shit is a precious and rare treasure. For some insane reason, this is not what we do; most software is designed with the utterly bizarre assumption that all incoming communication receives a standard, uniform, and equal subdivision of give-a-shit. This is why your email inbox looks like Hacker News, instead of Hacker Newspaper.

The newspaper model of information design uses typography both to maximize legibility but also, and more importantly, to communicate hierarchy.

It's very, very easy to infer from this newspaper design the relative priority of the stories it presents. Twitter, GitHub notifications, and email should all look like this.

Update: the option to route different organization's notifications to different email addresses in the new GitHub notifications system is definitely awesome.