As far as modern social networks go, I was a relatively late adopter. I wasn’t in college when Facebook was new and exciting, only joining when they finally opened it up to the masses in 2006. I didn’t understand Twitter for a long time after hearing about it, mostly ignoring it before finally relenting and joining in December 2007. For the first few months, I had barely any activity on the site.
At some point the light went on for me with Twitter and it became where I spent the majority of my time online. Completely enthralled with it, I started paying a lot of attention to why it worked the way it worked. I scrutinized every change Twitter made and how it impacted how people used the service. I’ve tracked my followers and unfollowers at varying level of details over time to try to understand what behaviors influenced other people’s behaviors within the network (and admittedly, serve my own vanity as a bonus).
When new social networks come out now, I jump on them as fast as I can. I’m mostly interested to see how they solve problems differently than existing networks and what kind of uptake they get. No one has done better on the whole than Twitter and Facebook. Someone will, but nothing has yet.
Now that app.net is a thing (despite being pretty unclear what kind of thing it is exactly) they have an opportunity to take all of the things we’ve learned from the established networks and build something new and hopefully better. My hope is that they don’t box themselves in by approaching problems only through the lens of Twitter. A lot has changed between when Twitter started and now and there’s no reason they should be hamstrung by Twitter’s schizo decision making over the years.
(A quick aside: if broad consumer adoption is what they’re after they should copy the Twitter API verbatim as a starting point so all clients could simply change a root API URL to point to the new service. Once a critical-enough mass is reached, then start extending the API with new features. Classic embrace and extend strategy. I don’t believe they’re after broad consumer adoption and after using the Alpha a bit, I hope that’s not the future for the service. My greedy goal is that it replaces what I used to get from Hacker News: good links and high-quality discussions.)
If you were starting a social network today starting from The New Default (the minimum functional baseline most experienced users expect), what would you do differently? My proposals are below. And yes, other networks like Google+ have done many of these things (though I’m barely familiar with its API, so I don’t know how much of it is available at that level) and to their credit, I think they got a lot right.
Here’s what I’d do differently if I were running app.net:
Might as well start off with something that’s far more plausible behind a pay wall. Keeping mentions out of the main timeline is really only necessary if spam is a problem. If every stream you request has powerful enough filtering capabilities, creating a /mentions equivalent would be easy, but the main timeline should include the ability for clients to easily show all activity related to you from one API call. For those people with a lot of replies, an option to only include the people you follow would narrow it down. In fact, filtering streams like this should be a global concept…
Smarter Filtered Streams
I want to be able to view any stream (main timeline, hashtags, searches, etc.) with different levels of granularity: show me everyone, just friends of friends, just my followers, just who I follow, etc.
Global Exclusion Filters
I proposed a version of this as far back as 2009 and with election season ramping up, desperately want it on Twitter. You should be able to block any term, tag or person from appearing in any stream universally. Blocking someone should be implemented as a global exclusion filter. No need for separate blocking semantics behind the scenes and the client UI can work as expected. Add expiring filters and global muting is now easy to implement as well.
Probably the biggest functional gap on app.net so far (and also the one with the most discussion for how it should be handled) is providing a way for people to react to a post beyond a reply. My proposal is to allow for three types of reactions to any given post: Share, Star or Save.
Share is to re-broadcast a post to your followers. Since people appear to love adding comments to retweets, this should just be built in, leaving it up to client UI to handle how the shared status and the accompanying comment are displayed. As far as the API goes, this should look like any other status update, just with the requisite metadata to attach it to the original.
Star is for expressing public approval of a post. Can also optionally have an accompanying text comment, again generating a timeline event.
Save is for bookmarking/read later/archiving. This deserves it’s own separate mechanics since Twitter favorites have been overloaded by users to serve two purposes, both haphazardly. I think this should be a private event not shared to the timeline, but the aggregate number of saves should be made available.
We don’t need lists or circles, just let me tag people. And searches (hashtag inception). And saved posts. Then I could create highly-customized streams from relevant people AND topics.
You can simulate this in Google+ by turning down the dial on certain circles, and Friendfeed supported this natively. No reason for the software to create awkward social situations. Give people cover. Could probably also be implemented as a global filter.
Flexible Private Messaging
Let me define which tagged people I can message and if I send someone a private message outside those groups, let them respond. I won’t go into this too much because it’s mind-numbingly obvious how this should work and private messages don’t yet exist on app.net anyway.
New Mention Syntax
Some people will probably get riled up about this because @ isn’t exclusive to Twitter, but I think there should be some distinguishing syntax. I like /johnsheehan because it’s unobtrusive and matches the URL :) When doing a straight reply the recipients should be in metadata, not the text of the reply so that you don’t have to resort to .@ nonsense. .@ is Twitter thinking at its worst.
Original Source of Content
Since I work for a company whose service lets you automate things, I’ve thought a lot about this. It’s not enough to know what client posted something to distinguish if it was generated by a human or not. Clients should have enough information to determine if something is original content or just a re-post of something else. I think there should be some construct to say that if a status is cross-posted from another network, what the original source of that content is. Then clients can prioritize what is displayed according to what the user prefers. I still don’t know exactly what this would all look like but I know there should be more data available and API clients will all benefit from everyone else providing that data.
URLs in metadata
This is tricky, and t.co link handling is evidence that this is hard to get right. I think URLs should be moved to metadata with markers left for display purposes, but I think they should incur a hit against the length limit more than the marker length. For instance, a useful display length is the domain plus some amount of the path and whatever that useful display amount is, that’s what should be counted against the post length limit.
200. 140 sometimes feels short, though I feel like it’s done a lot for helping me communicate more succinctly. 256 (app.net’s limit) feels a little long to scan. Split the difference.
This is what the next generation social stream service looks like to me. Super flexible data streams that give clients a lot of options for how they’re presented. Add annotations to this to let client developers expand updates even further and I think it’s a pretty compelling service that solves a lot of long-standing issues we’ve grown to tolerate on Twitter. It likely won’t be popular with the masses, but it doesn’t need to be for a long time, if ever.