I love Product Design. As consumer tech has matured, I think the most interesting challenges have largely moved from pure technology problems in to more general interface problems - helping a user get real value from a product while also creating real value for the company.
On Friday, there was a good discussion on Twitter questioning whether Twitter should treat links as content or meta-data. If you're wired like me, it was a real barn-burner; a smart conversation packed with interesting thoughts about the future of Twitter.
Twitter treats links as content, why?
Twitter was built with mobile in mind, and was designed for complete compatibility with SMS. This decision has defined the product in many major ways, for example, tweets are limited to 140 Characters so they can allow 20 characters for appending a username while still fitting under the 160 char limit of SMS.
Another big influence SMS has had is the simple design of what a tweet is; the amount of meta-data attached to a tweet is very limited (username, time, originating client and location). Everything else in the tweet is text-only and considered content. If you need more room or want to include anything other than text, you host it elsewhere and place a link to it in the tweet.
What this means is that when you are sharing a link, you actually have to include the link in the content of your tweet. The text address of that link is content, so it counts against the character limit of your tweet.
On Friday, Sean Parker took issue with that and told Jack Dorsey about it (with a tweet of course, pictured above). What ensued was a great public discussion on how twitter should treat links. Several talented product people chimed in with their thoughts. That link is a storify containing some of the main points of the tweets, so you can get the gist of the discussion (it is in no ways a complete log of the discussion).
It is amazing that this debate is now available publicly. Not long ago, access to discussions like this was only available to a handful of people working at 3am in an office together.
If you want to excercise your product design muscles, ask yourself, how would you solve this problem?
Working to come up with an answer to that question, one you're proud of and can defend intelligently, will let you engage in discussion with people who feel differently. That logical argument will help you become a better product designer. Feel free to post your answers in the comments.
Here's how I would solve it.
Twitter creates value for their user base in many ways:
- enabling people to share more information (especially people who couldn't share before)
- enabling people to share more quickly
- enabling people to access more information (especially info they couldn't access before)
- enabling people to have mutually-interesting direct conversations.
If you view how Twitter handles links under this light, there are several benefits to handling links as meta-data:
- Remove the need for users to "hard-code" cues for different types of information
- Increases the readability of a tweet, by splitting contextual information and the user's reaction (helps new users understand how to use it)
- Decrease the barriers to entry for composing a tweet
- You can now allow people to share more by attaching more meta-data per tweet (a collection of links, a group of photos, etc.)
New UI constructs would be needed to show the attached meta-data, but the effects above sound positive to me.
They improve the core experience of Twitter and help Twitter appeal to a wider base of people by simplifying the experience.
Content is for user-created, meta-data is for reference material.
I would argue that the best user experience is for a user to use the tweet to provide their context (their voice). Everything else is essentially supporting material and can be attached.
This is why users re-post something someone else said and put a "RT" in front of it, despite the existence of a twitter designed retweet function. People often want to communicate their reactions AND be able to reference what prompted those reactions.
Using meta-data to attach things to a tweet would allow tweets to become information dense, without increasing the size of the "content," which has many benefits.
The most confusing question is whether @names are content or meta-data. I lean toward @names being content (who a user replies to is context they've created). I could be persuaded that it's meta-data though.
There are negatives to change.
I'd be silly to suggest that making this change wouldn't have some potential costs. The SMS experience is core to Twitter's success, and interoperability with this standard is key in some of the most important use cases Twitter has. SMS access is used heavily by international users and by those of modest means. Impacting those users would have a huge negative effect, and any impact on these group needs to be neutralized (or at least heavily mitigated).
SMS users are dramatically impacted, because there is little room to send meta-data over SMS. Right now only a little meta-data sent is the username (up to 20 char), as the tweet takes up to 140 characters. That makes sure that all the tweets received via SMS come in as only one text message.
Adding link meta-data to this would take the meta-data count up to ~35 characters. I think the majority of messages received would still be under the 160 character limit of each text message (usernames are often less than 20 characters, tweet content is often less than 140 characters).
However, a non-trivial amount of tweets sent over SMS would be greater than 160 characters.
Here's my solution:
- Make adding links the same as today, simply copy the URL in to the tweet composer
- Stop counting URLs against the character limit
- Strip all links out of tweets, start including them as meta-data on a tweet
- Use t.co to host links to permalink page of tweets w/ attached meta-data
- On the permalink page, include the tweet content and all meta-data (username, location, any links, any media attached for pics.twitter.com, # of retweets, any replies, etc.)
- Append the t.co link after the tweet in all tweets fetched via SMS or API, remove the t.co link from Twitter built interfaces
- Build a new UI for mobile and web apps, show meta-data in the tweet experience (right hand pane on web/tablet, individual tweet page on mobile app)
- If the new UI negatively affects clicks, explore integrating meta-data into the feed view (Clickable text? Potentially use the [PIC] and/or [LINK] construct that exists in the community today)
Here's how you can protect SMS users:
- For cases when username + content + t.co link is > 160 characters, let the user decide whether to receive multiple SMS messages or whether to truncate the last few characters of the tweet (which they can view on the t.co link if so desired)
- Allow SMS users to reply to any tweet with 'more' and receive all attached URLs (probably shortened) via a second sms message
- Optimize permalink sites to load quickly, with low data usage and on feature phones