Posts Tagged ‘michael sippey’

The Savage Beatings Anti-Pattern

Monday, October 1st, 2012
CSSquirrel #102: The Savage Beatings Anti-Pattern

Just so we’re clear, in no way do I think that Jeremy Keith (one of today’s guest stars) would actually do any violence to Michael Sippey (the other guest star) or any other person in real life. I do, however, share Jeremy’s well documented rancor about the email notification anti-pattern. Which, among many other shameful companies, Twitter is notorious for its participation.

For those precious few of you who haven’t been victims of it, the anti-pattern in question is as follows:

  1. A site creates a new notification/email/spam.
  2. An option is created for their existing users to sign up for this further bloat to their in-boxes.
  3. As a “convenience”, it is set to “yes” by default.
  4. If for some reason (Heaven forfend!) you don’t like spam, you must then follow a link to their site, log INTO said site, and then un-click the offending “Yes” that’s on an item labeled something patently false like “Emails You’ll Really Want”.

This isn’t a customer service. They know it. And we know it. It’s force-feeding end users in the desperate hopes of squeezing extra profits out of our bloated corpses.

So what do we do about it?

I’m going to suggest we follow Jeremy’s advice.

Document (aka, blog) the situations when they occur, so there’s a greater awareness for new startups entering the space that this type of interaction and marketing is unwanted and hostile to users.

We probably shouldn’t threaten them with bats, but I suggest communicating directly with offenders. They may not change from one voice, or ten, or a hundred. But if enough people complain, maybe they’ll get the picture.

Also, participate in efforts to proactively communicate what web patterns suck, such as pointing people to Harry Brignull’s Dark Pattern Wiki (which doesn’t currently have this anti-pattern listed on it, but certainly should.)

Those are the best ideas I’ve got. Documentation, mockery, notification and education.

Got your own? Let me know via one of the response methods below. Or, heck, if you actually like being signed up for spam without your prior consent, please let me know. You’re likely the last of your kind and belong in a museum.

It’s People!

Monday, August 20th, 2012
CSSquirrel #95: It's People

In addition to being a guest in today’s comic, Michael Sippey is the Director of Consumer Product at Twitter.

He’s also the author of a post over at the Twitter Developer Blog that you may have already heard about: Changes coming in Version 1.1 of the Twitter API.

In it, Michael reveals that Twitter is really tired of people using other (better) “traditional” Twitter clients instead of their own website and apps, and that they’re going to be making it a lot harder for those to exist in the future. Between changing Display Guidelines to Display Requirements, sharply limiting the amount of client tokens a client app can serve and requiring such client apps to go to Twitter to “work together”, it’s apparent that Twitter is continuing its campaign to shut “traditional” Twitter clients down.

I wish I could feign surprise, but the fact is that such ungrateful, brutish behavior has become the norm for social media companies. First they rely on third party developers to make their service more popular by extending functionality and drawing in users while the service is fragile and young. Then they steal those features for their native experience. Lastly they eventually shut down the third party clients to force their service’s users back into the native client so they can cram ads down their throats.

It’s the way of the web. It shouldn’t be, and I’d love to see some other model come to dominate the space, but at present I’m only ever shocked when a popular web-based service doesn’t screw over the partners that helped them get to where they are.

There’s a different level of dick behavior that I’d like to address, however. It’s how Twitter is using this dicking of their developer “partners” to further dick their users.

In his post, Michael encouraged developers to move away from the traditional client apps and towards other types of applications with the following chart:

This chart has four quadrants. The upper right one, which contains virtually any app that you, I or any other user of the Twitter service would typically use, is what they’d prefer developers to shy away from. The other three, which turn the users into products, are what they want to see more developer engagement with.

Let’s let that sink in. They want developers to focus on turning us into products.

This isn’t a shock. After all, ever since the advent of advertisements we users of a given service have been little more than eyeballs that can be sold in everything from newspapers to television networks that specialize in shows featuring orange midgets copulating in hot tubs.

Ultimately I’m aware that Twitter needs to make money. Which, when your whole service is letting people blather about the contents of their breakfast for free, is a bit of a challenge. So I get it (but don’t like it) when promoted tweets end up in my Twitter stream.

But to me there’s a stark difference between feeding themselves and encouraging an entire ecosystem to become a bunch of frenzied human-eating services that exist not to serve the user experience, but instead to transform users into a product for companies to exploit and consume.

Apparently “Director of Consumer Product” means exactly what it sounds like. It turns people into product.

I’ve been pondering (without any success) how web services that don’t sell products (whether physical like toilet paper or digital like MP3s) are supposed to make income without putting their users through the wood chipper and selling them on a platter to interested parties. I’m thinking that Kickstarter is pointing in the right direction (consider Penny Arcade’s Kickstarter project to get their ads off their site). But just because I don’t have a solution yet doesn’t mean that I like the status quo, and I think it’s a major step backwards in consumer relations for Twitter to be essentially forbidding its developers from building any product with their API that actually serves to us, instead of serving us up.

Am I quitting Twitter? No. Too much of my personal social ecosystem is currently on that platform, and for better or worse I’m going to continue to play the role of Internet chum for the circling marketing sharks until something better comes along (I know, I’m too late for a timely Shark Week reference). But when a better option does come along, there’s a good chance I’ll jump if it looks like it will get traction. And any plans I had on building any Twitter API-based projects are going the way of the dodo.

Bad form, Twitter.