Generally, the presence of brands and their representatives on social sites is well-tolerated. Everyone is used to the fact that brands are jumping in. We consumers have large, high-res displays and we’re great at building selective blindness. When brands participate in social media, though, we don’t necessarily need that blindness. They’re automatically invisible unless we want to see them.

The Honeypot

A honeypot is an attractive trap used to embargo a threat. In information security, a dummy server might be placed on the periphery of a network and left somewhat hackable. The dumber crooks break into the honeypot, thinking they’ve silently compromised a network, only to be kept at arm’s length and watched. A thriving, sensitive network might exist right behind the honeypot, but the attacker never knows. He’s satisfied with himself for breaking in and stealing (what he thinks are) the keys to the castle.

On social sites, we only engage with brands if and when we want to. We don’t bother following @zappos if we don’t want to interact with Zappos. The model keeps the power dynamic shifted the way it should be: in the favor of the consumer.

In a way, a brand presence on Twitter is the antithesis of display advertising. Rather than covering every visible surface in a shotgun effort to sneak into the minds of consumers, social media advertising is more passive.

Twitter and Facebook are honeypots for brands, keeping consumers protected from the annoying noise we see everywhere else. We reach in and pull them out when we want, but otherwise keep them at bay.

Twitter is better at this role than Facebook because Twitter lacks display ads. I think that fact alone makes us love Twitter, where we simply tolerate Facebook.

An Olive Branch

So, to brands, I say, welcome. Don’t screw it up, and don’t speak unless you’re spoken to. You’re not “going where the conversation is happening” – you’re going where people are, and letting them talk to you if, when, and how they prefer. Play by the rules and you will, over time, build a community. You’ll earn a voice. Just don’t be insulted if we tune in and out at will. It’s better for all involved.

An Example

Ok, so R/GA is about to bring Taco Bell all up in our grills on Facebook and Twitter. God save us from the chalupa and volcano nachos.

Luckily, I can opt out by not opting in. We all can.

It feels good, doesn’t it?

Currently, systems deliver recommendations (like search results, products, or compelling content) based on two types of user input: explicit and implicit.

What You Tell the Robots

Explicit input is what you do to purposefully tune a system. You might opt out of tech news and opt in to sports. You might type in a couple of your key stock symbols. Explicit input is configuration. The cynical idea behind configurable services is that users will interact more with a tool they’ve spent time customizing. This can be true, but it can also alienate non-tinkerer audiences. More importantly, forcing someone to create their own portal removes any kind of authority from the service in question. It exposes the robot behind the curtain.

The Robots are Watching You

Implicit input is what you do without knowing you’re tuning a system. Where you click, what you search for, and what you ignore all contribute. Coming into a magazine site from a particular Google search might change the content you see on the page. Banner ads are usually served based on what you’re reading and what the ad network knows about you. On Amazon, anything you look at feeds into the recommendation system that shows you products that (may) interest you. In fact, I love pranking people by sending links to enema kits on Amazon. It pollutes their recommendations for a while. This is implicit input at work.

The Robots are Watching Everyone

An additional way that sites make recommendations is based on the stuff you tell them you want (explicit input), the stuff you show them you want (implicit input), and the input from other people like you. There are some sweet algorithms out there for determining that people are alike and using the tendencies of members in a group to recommend things to other members in the group.

In theory, the idea is compelling. Unfortunately, most of these algorithms end up turning individuals into caricatures of themselves or of their demographic group. It’s infeasible for a system to know enough about an individual to make consistently great recommendations. No computer will ever be able to recommend a book or a date or a pair of shoes with the same accuracy as a friend. More importantly, they can’t deliver the same accuracy as a casual acquaintance.

Humans can fill in gaps and infer rich meaning from subtle body language, tone, and personal experience. Those factors are noticeably absent in most online recommendation, search, and content delivery systems.

The Perfect System

I don’t think people want to interact much with systems to find information. Weird view, I know.

Some systems are certainly popular (Google) and and very successful (Amazon), but the affinity people feel for those systems is a form of Stockholm Syndrome.

What we all want is to have our grandfather (or an equivalent symbol of infinite wisdom and no-bullshit-taking) sitting on our shoulder, pointing us in the right direction at all times. We don’t need confidence in recommendations (of content, purchases, people) as much as faith. We want to Ask Jeeves, but we want Jeeves to have a clue – not a hundred page slush pile of possible hits.

Bad or boring recommendations lead to a lack of faith in recommendation systems in general and contribute to an overall fatigue. Recommendations need to inspire either confidence or faith. Confidence comes when you’re 100% accurate at all times. Faith comes when I feel like you understand me. Your “you might like…” recommendations are something I care about because I empathize with you. Confidence is for robots. Faith is for humans.

Enter Social Networks

There is a lot of potential in the networks of people we curate online, the reviews we write, the reservations we make, the choices we make on the spot in stores. The data doesn’t say who we are and how we feel, and no machine can step in to fill in the gaps and make the proper inferences.

The best system will have hints of the “#lazyweb” approach to Twitter. I ask my curated audience for advice. Even if I don’t know them all personally, and thus have little confidence in their individual experience and knowledge of my personality, I have high faith in the mechanism. I ask, and I receive. From people.

It’s a model as old as language. Until computers can empathize, algorithms need to shift their focus. Instead of attempting to make recommendations, technology should attempt to facilitate recommendations.

Twitter is on the right track with the new focus on search. I’ve long maintained that the best source of purchase advice is Twitter search. Twitter is a barometer. Nobody searches Twitter to find out definitive, high-confidence information. Instead, we search to get a feel for what people seem to know. We read short statements and either empathize with them automatically or shut them out. We have faith in our ability to read between the lines and derive answers. We use personal brands as clues to authority, bias, and brilliance.

It’s very personal and all too human.

With the insanity around the Yahoo and Bing/Microsoft relationship, I wonder if Twitter – or an app built around it – won’t become the search and recommendation tool we all really want.

For those not in the know, Twitter uses an incrementing integer as an identifier for each message on the site. On June 12, 2009, a message crossed the maximum integer value that could be stored in a 32-bit signed integer (2,147,483,647).

All messages created after that moment had integer values that would overflow the space allocated to the id.

This wasn’t a problem on Twitter.com. They’re surely on some rockin’ 64-bit systems and are continuing along as always.

The problem is with third-party applications using their API. When an application requests a list of status messages from Twitter, it receives the data in a format like XML or JSON. All values are stored as strings in those formats.

When the response is parsed, the string representing the status message id will be converted to a number. Applications that still use signed 32-bit integers will not be able to properly convert the string to an integer and will probably crash.

This problem is hitting a few Cocoa Touch applications. Tweetie seems immune, but the current release of Twitterrific and the in-beta Birdfeed both suffer. This is through no fault of either Craig Hockenberry or Buzz Andersen, though.

Buzz’s app, Birdfeed, is still in beta. Those of us testing it understand that beta means beta. He’s cracking on a fix now.

Craig preemptively fixed his issue well in advance, but – as I understand it – Apple is sitting on it instead of pushing it into the App Store.

This is just one of many ways Apple continues to please developers endlessly with their transparent, fair, open distribution channel.

Lots of folks want to blame Twitter, or shift some of the blame to them.

This is not a Twitter problem. They adapted their system and encouraged developers who use the Twitter API to remain in parity.

It’s probably true that Twitter could have made a bigger deal of the issue, but I think they did a solid job of keeping people informed.

Most people had ample time to update their code, and many of them did.

Daniel Jalkut suggested that Twitter might have provided an endpoint for the API that simulated large integer values, so application developers could test against the newer ids. I heard similar statements by folks attending WWDC.

I think this exposes a slightly dirty secret in the Cocoa world: most Cocoa and Cocoa Touch devs avoid automated testing. Unit tests are few and far between. From what I hear, Apple doesn’t even enforce units.

When you see regression bugs in Cocoa apps, you can assume the issue is in a lacking test suite.

The Cocoa community should learn two things from the Twitocalypse:

1. Write your units.
2. Submit to the App Store at least time * infinity in advance.

I’m about 50% on having test suites in my (admittedly, unreleased) iPhone apps. The half that have tests have strong coverage, though. Those that don’t are from the early SDK days, when the only way to test was with the Google Toolkit.

I understand the irony of complaining impotently about an impotent complainer, naturally. Hey, that’s what blogs are for, right?