Tweetstorms have been around for a while, but have recently gone meta with a lot of discussion about their problems and merits. Including, of course, tweetstorms about tweetstorms. Some folks have presented solutions for making their creation easier (e.g. Dave Winer’s Little Pork Chop), but the problem is much more about their consumption. Although people often appreciate their content, Tweetstorms are widely regarded as obnoxious and intrusive. The comment that captured it best was one by @kirklove, who likened them to the “loud person at a cocktail party”.
The other problem is that using the reply mechanism to connect the tweets is causing issues with Twitter’s UI for threading replies. And even if that wasn’t the case, the more replies there are to individual tweets in the storm, the more difficult it gets to follow the storm.
Emergent features aren’t always good ideas, but in this case it does seem that Twitter has been presented with an opportunity to break out of the 140 character limit without losing the beauty and simplicity of constraining an individual thought to 140 characters. Tweetstorms are limited, but they can summarize a topic, lay out the logic of an argument or convey a narrative.
From a user experience perspective, the fundamental thing that Tweetstorms long for in Twitter’s model is a way to create relationships between tweets, other than the reply mechanism. Were Twitter to add this to the model, here’s how it might work. I’m going to use one of Fred Wilson’s recent tweetstorms as the example.
I will start with the consumption experience. Here’s what you will see in your timeline when Fred posts his Tweetstorm:
The only way this is different from any other tweet is the “1 of 7″ on the top right. Clicking or tapping that element will expand the storm and you will see the following:
Each tweet now reflects its position in the storm with a number at the top right. You can collapse the storm from the last tweet. The important thing to note here is that the individual tweets behave exactly the way they do today. For example, you can reply to individual tweets and “View conversation” expands the reply thread for that tweet.
Here’s how Fred would create the storm. First, he writes a single tweet:
That “+” is the only new element, and it is only seen by Fred, the author of the tweet. Clicking or tapping the “+” opens the post form and the new tweet Fred creates becomes the second one in the storm. He then sees the following:
Now both tweets are numbered. Fred can tap the “+” on the second tweet to add a third. He can also another tweet to this storm by tapping the “+” on the first tweet and the new tweet will be inserted between the two existing ones. Deletion of any tweet in the storm, including the first one, just reorders the remaining tweets.
Fred doesn’t have the ability to collapse his own tweetstorm in his timeline.
This is a crude mockup and far from a complete solution. The main point I’m trying to illustrate is that the core of the tweetstorm is a new type of relationship between tweets, and the challenge is to make this relationship easy to create and (more importantly) consume. I think the goals of any solution should include these two:
- Lower the impact of the storm on the consumption experience. I’m doing that above by collapsing the storm by default. As a consumer, it is my decision to allow the storm to take over my timeline.
- Minimize the impact of the solution on the current mechanics of individual tweets. Aside from being collapsed under the first tweet by default, every tweet in the storm above is a first class tweetizen.
Just in case I have given the impression that adding a new type of relationship between tweets will be relatively easy to do — it won’t. To a system operating at massive scale like Twitter does, even small changes have far reaching consequences. And isn’t a small change. Not to mention all the edge cases and unintended consequences in the user experience that need to be considered. For example, one key challenge will be to resolve confusion between tweet storms and reply threads (this is a weakness in my mockup above).
Finally, apologies to the Twitter design team for brutalizing their UI with this mockup. I love Twitter as a product and there is no disrespect intended.
Posted: July 2nd, 2014 under The Social Web.