CSSquirrel A look at web development and web design by Kyle Weems

:

Posts Tagged ‘biz stone’

Comic Update: Grilled Shark and Twitter

Tuesday, May 26th, 2009

Over the weekend I moved to a new apartment. After this, it was Memorial Day on Monday. As a result, this week’s comic is a day late, and accompanied by only a brief post.

It wasn’t my intent to discuss Twitter back to back. After all, there’s all sorts of important web development topics just ripe for plunder. But I couldn’t pass this one up.

Twitter is working on a TV show. No, really. Or working with people working on a show. Whatever. I can’t imagine how I’d react to hearing this in person from one of Twitter’s higher-ups if I worked with them, although today’s comic attempts to recreate such a scenario. However, both Eric Meyer and Jeff Croft managed to craft suitable tweets that sum things up fairly well, here and here (respectively).

I appreciate the tool that is Twitter. I’ve kept in contact with people met elsewhere thanks to it, met new people with similar interests over it, and made good use of it in keeping up to date on interesting information in my industry. I’m not really sure, though, that a 140-character micro-blog requires a televised show.

About the only way you could jump the shark more is, well, to be Fonzi.


Seriously, why is he water-skiing in a leather jacket AND the shortest shorts ever? If this was cool in the 70’s, I’m glad I was only 3 when they ended.

Comic Update: Twitter Under Fire

Monday, May 18th, 2009

If you’re one of the few people who read my blog but haven’t heard of Twitter, you may be unaware of the firestorm that started last week when the company decided to alter a feature of their service last week.

Today’s comic (featuring Biz Stone, Doug Bowman, and Eric Meyer with a Star Trek flair) pokes fun at the brouhaha that resulted. It also highlights the dangers of running any sort of social networking site and trying to make feature changes.

As the creators of Facebook have learned in the past, people have opinions. Build a site based on people sharing with one another, then make a change, any change, and you’re going to find that people are going to use your site to share negative opinions about those changes. If they’re loud enough, or numerous enough, you’ll find yourself suddenly struggling with an unanticipated PR disaster over what seems to be the most minuscule issues.

In this case, the big issue was Twitter deciding to remove the optional setting that allowed you to see a reply from one user to another, even if you weren’t following that other user (tweets known as conversational fragments). For quite some time Twitter has had the option of letting you hide those from yourself, so that your chattier friends’ conversations with strangers doesn’t drive you bananas.

However, removing this option angered the people who liked that feature, allowing for what they call “serendipitous discovery”. What better way, for example, to expand your list of industry colleagues that you get useful tips from then to watch who professionals in your field are talking to? (More than a few people now on my follow list I learned about from stalking the tweets of people likeĀ  Meyer and Andy Clarke).

To sidestep the limitation, in protest Eric Meyer (and many others) started adding > prior to every reply. The catch, of course, was that you couldn’t filter those out, so then suddenly everyone on Twitter was seeing a lot more replies than they actually used to when they had an option.

Thankfully, less than twenty-four hours later this was changed. Unfortunately, you now need a flow chart to determine how your tweets are being seen (here’s one by ReadWriteWeb.) I’m not even going to try to explain it, other than to say some of your replies are visible to others who choose to see them, and some aren’t.

I don’t understand why it was so important for them to make this change, nor am I sure that I understand their new compromise position. (Biz explains the issue more clearly here) What I do know is that any web service (especially a social networking one) should think twice (or heck, three times) before removing a feature from their service that users are actually using, and incapable of reproducing on their own through workarounds.