Results tagged “apis”

The Internet of Tweets

July 11, 2015

Everybody’s got advice on what Twitter needs to do at its current crossroads. The answer might lie in revisiting the moment they first broke geeks’ hearts.

I took it as a bad sign that Will.I.Am was hanging around backstage at a conference for software developers.

It was hard to understand why nobody’s favorite rapper was in the building, since he had expressed no particular interest in software engineering prior to that moment. To be fair, Will.I.Am’s interest in technology has become clearer in recent years; he recently put out a smartwatch called PULS, which is a good alternative to the Apple Watch for people who prefer a smartwatch that doesn’t work. But back in 2010, Am’s inexplicable presence at a technology conference was a good indicator that things were changing in a way that didn’t necessarily favor the folks who were there to hear stories about Apple apps, not apl.de.ap.

We were at Twitter’s first developer conference, an event called Chirp. And indeed, Will.I.Am’s armchair interview was just one of a few clear indications that Twitter really wasn’t just for geeks anymore. Instead, Twitter had suddenly blossomed into a company that aspired to be a player in media and entertainment and advertising, with its eye focused on becoming the giant, publicly-traded company it is today. Twitter began to take its first tentative steps away from its geeky roots, which set the stage for a nerd backlash that still hasn’t fully abated.

But the business types whom Twitter had been courting as its new BFFs turned out to be just as mercurial as the early geeks once the company finally did go public. Investors and pundits have taken issue with everything from the company’s CEO to its often-desultory product direction to its lackluster growth in the number of active users logging into the service each month. This led to a precipitous recent drop in its share price, the delivery of a 360-tweet-long diagnosis of the company’s ailments from shareholder/cheerleader Chris Sacca, and culminated in today’s announcement that Twitter CEO Dick Costolo is stepping down from his position.


While the Internet has never shied away from offering unsolicited advice to Twitter’s leadership, it has perhaps never faced such impassioned arguments about how the company can get its mojo back from some of its closest supporters. While many businesses would envy the fact that Twitter has pretty huge revenues and a user base that is enormous in comparison to almost anything except Facebook, it’s become conventional wisdom that the company needs to work to find its bearings again.

And oddly, getting Twitter back on track may mean taking another look at one small bit of news that got overshadowed by a Black Eyed Pea on that day five years ago.

Chirp logo

Let’s Get It Started

In the spring of 2010, Twitter was just graduating from being the hottest startup in tech to being a genuine cultural phenomenon. Chirp was the company’s first big conference, a glitzy coming-out for the company and its leaders. Advertised as its “first annual” event (there have been none since), Chirp showed that Twitter was a big enough institution to be able to command the attention of a theater full of geeks and press. I found myself there as a sort of legacy admission, thanks to the fact that I’d been working on building some apps on top of Twitter’s platform, and had known the founders of the company back when they were just ordinary geeks.

Twitter’s spate of announcements at Chirp included big news like Dick Costolo announcing the company’s first real foray into offering advertising. But within the tech industry, the real headlines started the night before with a low-key announcement that Twitter would be buying or making its own Twitter-branded apps for smartphones. (As absurd as it seems now, until that point, searching for “Twitter” on most devices wouldn’t yield a Twitter app that you could just use to read or post tweets. Instead, a confusing array of Twitter “clients” offered a selection of blue bird icons and terrible portmanteau names beginning with “tw-”.) At Chirp, Twitter made clear it would be offering its own, official app, just like Facebook and all the other popular services.

Ev Williams at Twitter's Chirp eventThen-CEO of Twitter Evan Williams at Chirp, explaining the biggest challenge facing Twitter as a company. (Photo by Scott Beale/Laughing Squid)

The announcement of Twitter’s first-party mobile apps, coming just on the eve of Chirp’s start, rankled some of the most influential developers in the crowd, despite the obvious logic of the company’s rationale. These developers were independent coders who now faced the challenge of competing with the very company whose service made their products possible. From the standpoint of the market, or of regular users, Twitter was right to dismiss the complaints of these developers at the time. Twitter’s decision to make its own client apps did yield a significant simplification of the experience for normal users, and set the stage for the company to be able to display ads on the service, which might have been impossible through third-party client apps.

But unfortunately, this dismissal of developer concerns, however legitimate, would leave a lasting mark on the company’s relationship with the geeks who had first embraced the service. Even though the vast majority of programmers who built tools on top of Twitter weren’t making client apps, the mood of the entire developer community was led by those who were. And once the developers got upset, their disgruntlement informed the attitudes of the entire early-adopter tech community. Later announcements to these same geek audiences would be plagued by vague messages, unclear goals, or accurate communication of actual bad decisions on the company’s part. All of this merely confirmed the suspicion of many developers that Twitter didn’t love them anymore. For nerds, Chirp could be seen in retrospect as marking the official end of Twitter’s Good Old Days.

Where is the love?

Twitter’s struggle to win over investors is mostly due to the fact that most folks on Wall Street don’t really have a nuanced view of how social networking and social media platforms work. The market wants metrics, but picks and chooses which metrics they care about pretty arbitrarily, based on the whims of not-exactly-Zuckerberg pundits like Jim Cramer, or by looking at the numbers of other services like Facebook’s much-vaunted Monthly Active User (MAU) count — the number of people who log in to use the service each month.

The thing is, MAU numbers are a pretty arbitrary measure of the utility of a media-based service like Twitter. Google’s investor briefings almost never ask about how many YouTube users are logged in each month — they care about how many videos are watched, and how many ads are seen, and maybe they care a little about the fact that YouTube is the second most popular search engine on the Internet after Google itself.

By contrast, relatively few users go to Facebook to do a search on a news story or to find a particular video. And being measured against Facebook really only makes sense if there’s a zero-sum game where people are replacing one service with another. For example, in the photo-sharing realm, Flickr’s lead a decade ago has been almost completely supplanted by Instagram’s dominance today. In that context, a user-for-user comparison makes sense.

But when Anita Baker and Cheryl Lynn have beef on Twitter, it’s only on Twitter. And a ton of people are going to read about it by seeing their tweets embedded on a blog or news site, just like they discover YouTube videos that are embedded on those same sites. Whether they’re logged in to the service or not is irrelevant. (The fact that no ads are displayed along with those embedded tweets certainly is relevant.)

So what about some non-MAU metrics? Would that appease? What about shifting the conversation entirely? Other companies have been able to broaden focus from their ad-based businesses by getting into nascent markets that hold a lot of promise. This is where we encounter things like wearable 3D goggles and smartwatches, but R&D-intensive hardware folly is generally the domain of much bigger (and richer) tech titans like Apple and Microsoft and Google. And, uh, Will.I.Am.

When Will.I.Am DJed the afterparty for Twitter’s Chirp conference, he literally followed Don’t Stop Believin’ with Sweet Child o’ Mine, which is hard to read as anything but contempt for the conference’s attendees.

I Gotta Feeling

The funny thing about many developers being convinced that Twitter doesn’t care about them is that it’s pretty clear that Twitter is better to its developers than almost any other social networking or social media company. I was at Chirp because I’d helped built a tool that relied on Twitter’s data, not as a client app but for analyzing and understanding a user’s activity on the service.

Lots of other companies went that route, too—with a number of them selling for hundreds of millions of dollars as “enterprise analytics services”, and many more getting lots of funding for the apps they’d built on top of Twitter. That’s a striking contrast to the ecosystem around, say, Instagram or Pinterest, which have almost no similar success stories. In fact, if we look at the landscape of major social networks or messaging applications that developers could have relied upon in the years since Chirp, a striking pattern emerges:

  • Google: They launched Google Buzz (hey, remember that one?) and then mercy killed it a few years later. They’re about to do the same thing with Google+. There has never been a meaningful client app for Google+ from any developers outside of Google.
  • Instagram: There are a few third-party tools that do specific tasks like regramming images or making collages, and some reading apps for platforms like iPad where Instagram was late. Still, Instagram hasn’t really spawned many successful full-featured client apps. A handful of analytics apps exist, but none of them have gotten that huge.
  • Tumblr: The few attempts at building client apps or services have generally been stymied by the company. Almost none of the analytics services built for Tumblr have been very successful.
  • LinkedIn: There used to be a few ways to build apps and services around LinkedIn, but almost all of them were shut down over the past year.
  • Pinterest: The company promised an interface for developers for years, but has only shipped a limited release of some tools for brands to be able to interact with the service. There are no Pinterest client apps.
  • Snapchat: Pretty much nothing.
  • WhatsApp: Same deal, you take what they give you.
  • Facebook: They’re not too bad, providing access to a lot of useful data, but recent privacy improvements for users have meant fewer features for developers that were relying on previously-accessible data.

The truth of it is, when compared to other social networking companies, Twitter ends up looking like one of the most developer-friendly big platforms.

As a developer trying to build on top of all of these services, most of the ones that were of the same vintage as Twitter screwed us. The newer ones don’t care about third-party developers at all. None of these companies have ever cared about enabling developers to make a client app. Yet none of them has earned the same scorn or derision from developers as Twitter has.

This may be changing a bit, as we see a generational split amongst developers, with newer coders unaware of Twitter’s polarizing past. Indeed, Twitter’s recently made available a whole new suite of developer tools to simplify everything from displaying ads to keeping track of what’s making a mobile application crash on your phone. It’s still early, but every indication is that these new developer tools are already becoming popular, and that the developer services that Twitter acquired haven’t lost any credibility by becoming part of the company’s portfolio.

Enough years have passed that some of the older disgruntled developers may either have mellowed over time, or simply may not be relevant in shaping community opinion anymore. It’s actually possible that Twitter has another chance to make its core platform appealing to developers again, if it can find the right tools to offer them.

Scream & Shout

If we go back to that day in 2010, we can find out exactly what kind of things excited Twitter’s first wave of developers.

The start of the Chirp conference was a flurry of speeches from top execs, and of course the headlining Will.I.Am appearance. But by afternoon, the splashier news had passed, and it was time to get down to nuts-and-bolts developer conversations. The highlight for coders was a preview of an upcoming developer feature that seemed incredibly promising: Annotations. This nerdy new capability promised that developers would be able to pack more information into each tweet.

Annotations promised to upgrade tweets from being a 140-character postcard to being a 140-character message written on the outside of an envelope. What was inside the envelope? Whatever a developer could imagine.
At the time, this idea for Annotations was radical. Twitter’s core service had only just begun to stop displaying the fail whale, a whimsical and all-too-common illustration that popped up whenever the service was too overloaded to respond. To imaging going from not just being able to deliver tweets in realtime to anyone in the world, but to delivering almost any message in realtime to anyone in the world was a shocking leap forward.

Reaction from developers was immediate, and ranged from enthusiastic to downright rhapsodic: "Twitter Introduces Annotations; Hash Tags become Obsolete"

Even some of the more sober analyses of Annotations saw the potential for Twitter to be transformed as a service. And the excitement over the feature was clearly justified — many of the ideas that developers immediately suggested for Annotations, such as including photos or videos in tweets, have become indispensable parts of the platform’s current success.

Even Twitter’s most interesting newer features, like the “cards” in tweets that show excerpts and thumbnails of linked stories, or the experimental “buy” button that the company has been testing to enable e-commerce, are all things that Annotations had promised to make possible years ago. These capabilities were hinted at in the first reviews of the feature written back in 2010.

But more exciting than the ability to add new little buttons or links within Twitter is what Annotations could enable outside of Twitter. But that potential was never discovered, because the company soon stopped talking about the upcoming feature, and eventually abandoned the effort altogether without even so much as a tweet marking its demise.

#thatPower

One of the fastest growing categories in consumer technology these days are smart devices, which take ordinary household items and connect them to the internet. Each one usually comes with its own app. One app will tell you when your smart lightbulb is going to burn out, and another app for your smart toaster will tell you when it’s going to burn your toast. Each of the individual gadgets is pretty cool, but all of this noise on top of the nonstop barrage of notifications that light up your phone during the day seems like a recipe for message fatigue. It’s not difficult at all to make the argument that these notifications would be a better experience as delivered in Twitter’s signature stream.

Delivering these notifications is already done regularly by developers today, but each has to reinvent the wheel when it comes to handling tons of users or building the necessary code to support features on each new phone or device platform that comes along. If a smart device is fortunate enough to succeed, its makers get to face the same kind of fail whales that plagued Twitter for years. Piggybacking on Twitter’s infrastructure and could solve a lot of these issues, especially if they relied on an updated version of the features that Annotations promised.

This concept already exists for coders — it goes by name like a “messaging bus” or a “message queue”, though these services tend to be far more complex and expensive than it is to simply send a tweet. More to the point for developers, Twitter’s also a lot more fun than using an “enterprise message bus” service.

There’s a more subtle point here, too: Twitter enables connections between accounts. What exists today as a social network between people who follow and reply to each other could tomorrow expand to be an information network between devices that could follow and reply to each other. Telling your smart smoke detector not to set off the alarm when the smart toaster has said it’s about to burn the toast is currently a task for only the most stalwart geeks. There’s no reason that kind of connection couldn’t be a new use for the “follow” button.

But the point here isn’t to outline every possible interesting feature that can come from a fully-networked Internet of Things. Hell, I don’t even know what the most interesting capability would be. The key here is that Twitter is the best service to offer these features. It’s simple, fun, familiar, and available already on every device that matters. None of those things are true about the other “Internet of Things” platforms that have been announced.

Twitter could charge apps or devices (or humans!) that send high volumes of messages with Annotations, diversifying its revenue stream from simply being advertising-based, and building trust with any developers who still had lingering concerns about Twitter’s developer strategy by making these new features sustainable.

Chris Sacca at Chirp

Chris Sacca speaking at Twitter’s Chirp conference in 2010.

Boom Boom Pow

The thing is, it’s easy to write fan fiction imagining all kinds of features being invented by Twitter. I want a pony! And a new CEO who’s from an underrepresented community!

But most of the smart suggestions are probably already on Twitter’s roadmap, including those on Chris Sacca’s list. These suggestions tend to assume, though, that the only audience that matters are Twitter’s mainstream, non-technical users. This is an odd assumption given that many of Twitter’s most engaging signature features were pioneered by its early adopter nerds.

And it’s essential for Twitter to get out of the MAU metrics game with investors. We can imagine a hundred different ways to juke the stats and try to distract fickle financiers, but revisiting Annotations may be one of the few ways to do so in a way that’s based on substance — actually providing the kind of meaningful platform innovation that developers actually want.

There’s something unique and distinct in being an information network instead of just a social network. Twitter has been that network, and can be again.

Revisiting Annotations wouldn’t be a magic bullet. But it could be a way to reconcile Twitter’s past and its future, to appease both developers and investors. And it might be a chance to rekindle some of the unqualified enthusiasm that so many saw for the company at its coming out party half a decade ago, before it’s 2000-and-late.

On Location with Foursquare

August 6, 2013

There's a great, deep story by Austin Carr in Fast Company today giving a broad overview of where Foursquare is headed, as a product and as a company. I was quoted a few times in the piece, and spent a good bit of time talking to Austin, and I thought it might make sense to explain the non-obvious parts of my perspective on Foursquare.

It makes sense to start at the end:

Crowley is a rare breed of founder obsessed with the problem he's trying to solve. "The thing I fear, which would be devastating for the industry, let alone Dennis, is that he gets rushed and Foursquare can't monetize, they can't raise [another round], and they have to sell to Facebook or Google or whoever," Dash says. "And then at 40, Dennis has to start over. Because he'll do it again—there's no question. But then the world will have to wait another goddamn 10 years for this thing."

This articulates what may be the two most important points underpinning my opinion of Foursquare:

  • There's undoubtedly going to be a location layer to the Internet. It's too powerful of an idea, and too valuable of a technology, for it not to come into existence in the next few years.
  • Dennis Crowley has incontrovertibly been obsessed with this idea for over a decade.

Now, simply being a person obsessed with a particular class of problem doesn't always mean that someone will be the one who brings it to large-scale adoption — just ask Nikola Tesla. But my bet is that Foursquare cracks the code on this before anyone else. To understand why, let's take a look at what Foursquare really does today.

Everywhere You Want To Be

Foursquare's initial story was about the trappings through which it encouraged engagement — its badges and leaderboard, and the broader concept of recording one's location in the quantified self sense. Though I am happy to count both Dennis and Naveen as friends, I've never spoken to the company's cofounders about Naveen's departure from the company. My take on it, separate from any discussion they may have had within the company, is that Foursquare switched from primarily being concerned with the game-based rewards around engagement and the recording of people's whereabouts to a broader mission that builds on that base to be about location as a core capability of the Internet.

With Naveen building new projects around the smartest parts of what's considered "quantified self", that leaves Dennis leading Foursquare to focus on that location layer. [Update: Naveen and others clarify that both cofounders worked on all the aspects of what Foursquare does.] And in that regard, they've accomplished something no one else has done before: Almost every important app that uses location connects to Foursquare.

4sq-connected-services-crop.png

When you post an image to Instagram, you tag its location using Foursquare's venues data. Put up a video on Vine? Foursquare locations. Share a story on Path? It'll prompt for a Foursquare venue. Even Flickr, Yahoo's venerable photo service which popularized geo-encoding on the web in the first place, now lets you tag uploaded photos with Foursquare's venue data.

Keep in mind, Instagram is owned by Facebook and Vine is owned by Twitter — Foursquare is acting as the neutral third-party here that's trusted by both of these otherwise-constantly-battling social giants. Only Google, Apple and Microsoft, which each have invested hundreds of millions in location, don't rely on Foursquare on an ongoing basis for location. And countless independent third-party apps build on Foursquare as well. (Incidentally, this is why I think Yelp board member Keith Rabois' public petulance about Foursquare is so foolish — there may be some great value Yelp could get by connecting to Foursquare, but the product team there probably can't consider it for fear of earning the scorn or antagonism from their own board.)

powered-By-Foursquare-gray.png

The trick, then, is whether Foursquare can capture some value from this network of apps connected to its data. My gut sense is that the "Powered by Foursquare" branding within these apps is a little bit like looking at search results on Yahoo did around the turn of the century: There was a little logo link, all the way at the bottom of the search results, which said "Powered by Google", and it became pretty obvious very quickly that something important was going on.

Finding Its Way

To turn its network of client apps into a web-scale business, Foursquare will have to create a two-way exchange of value with the apps that are currently getting a one-way deal of data for free. What could be worth the exchange? The obvious idea is that Foursquare could expand its current advertising offerings in a way that they might be embedded within other apps, perhaps along with some sort of revenue sharing. More broadly, there might be ways of connecting commerce offerings such as Foursquare's deals in a way that was exposed through third-party apps. To extend the Google analogy, this is going from simply powering search on other sites to delivering text ads along with those search results.

Of course, partners like Facebook and Twitter already have their own self-service ad platforms, so what would it take for Foursquare to convince them to enable a more reciprocal relationship? Probably two things: value and credibility. The issue of value is straightforward, if not simple: Foursquare must provide a form of monetization that improves the experience for end users of mobile apps, whether its own or from a third party. That's clearly what the Foursquare team must be hard at work to do.

But the second requirement, credibility, is where I think people underestimate Foursquare. They've simply done more work, at a deeper level, to really understand the problems around location and location-enabled apps. Astoundingly, for all the public paranoia about online tracking, Foursquare's never made any mistakes that have caused a panic about the way they collect and share data. And its team is respected by other startups and media companies as being authoritative on nearly every important aspect of location-based technology on the Internet. Perhaps most importantly, its position as a neutral third party offers all of these partners an option which doesn't empower the competitors they actually fear.

The truth is, aside from simple mapping apps, nobody has truly built a large-scale consumer technology business around the potential of location. As I noted when discussing the importance of public traffic data, there is enormous value to be created by understanding how people move around: Both Bill Gates and Jack Dorsey's first companies were based on data about how people move around through cities. If Foursquare's given enough time to keep iterating on the incredible success it's had as a platform, and its first few steps toward driving revenue through ads make it stable enough financially, there's no reason it can't be the company that taps into the value of being the location layer of the Internet.

Going Further

Back in March, I interviewed Dennis as a keynote interview at SXSW. Though the conference seems to have never posted the video, there's a pretty good fan-shot video of the session:

(See part two of the interview.)

Based on that interview, Wired offered a brief overview of where Foursquare's headed:

Shoot a video in Vine, scribble a reminder in Evernote, make a post on Path, or snap a photo in Instagram, and you can place-tag it. When you do, you’ll see a little banner pop up that says “Powered by Foursquare.”

Any app developer can pull from this vast collection of place names. The company has become a powerhouse data provider to the internet at large, a sort of utility service for geographical information.

“That place-data that’s baked into those other apps — that’s Foursquare’s ‘Like’ button,” says Dash.

Similarly, TechCrunch wrote its take on the interview which focused on the potential to upgrade mapping for everyone:

At the end of the day, the data that Foursquare has is the ability to provide more personalized maps than what is available today. Crowley said that maps haven’t really changed that much since people started making them, but now that we have certain amounts of trending data or interest data, Foursquare could help make the places that people see more meaningful to them.

This column I wrote for Wired last year actually addresses the point of founders being obsessed with a particular kind of problem by quoting Dennis:

“The love for the space should manifest itself through the product,” Crowley says. “Artists do this all the time: pick a theme, explore it, reinvent it, explore it again. When you look at art in hindsight, you can usually see a linear progression through the work.”

And almost a year and a half ago, I named the company the best-executing startup. I still maintain that the quality of the software and design shipped by the company are a model for others to follow — we never hear about users in an uproar about changes, and even the introduction of advertising has been handled without the frustration or contentiousness that nearly every other platform faces with these types of launches. It'll be interesting to see if that remains true as Foursquare begins to extend its reach to the network of apps that connect to its services.

Rebuilding the Web We Lost

December 18, 2012

We have the obligation to never speak of our concerns without suggesting our solutions. I've been truly gratified to watch the response to The Web We Lost over the last few days; It's become one of the most popular things I've ever written and has inspired great responses.

But the most important question we can ask is: How do we rebuild the positive aspects of the web we lost? There are a few starting points, building on conversations we've been having for years. Let's look at the responsibilities we must accept if we're going to return the web to the values that a generation of creators cared about.

  • Take responsibility and accept blame. The biggest reason the social web drifted from many of the core values of that early era was the insularity and arrogance of many of us who created the tools of the time. I was certainly guilty of this, and many of my peers were as well. We took it as a self-evident and obvious goal that people would even want to participate in this medium, instead of doing the hard work necessary to make it a welcoming and rewarding place for the rest of the world. We favored obscure internecine battles about technical minutia over the hard, humbling work of engaging a billion people in connecting online, and setting the stage for the billions to come. To surpass the current generation of dominant social networks and apps, which have unsurprisingly become arrogant and inflexible during their own era of success, we'll have to return to being as hungry and as humble as we were when the web was young. Because last time, we were both naive and self-absorbed enough that we deserved to fail.
  • Don't just meet the UX standards, raise the bar. Obviously, the single biggest reason that the new era of social apps and sites have succeeded where the early efforts did not is because of their massively superior user experience, from the front-end user interfaces to the back-end performance. The expected thing to do would be to hope that a new generation of user-respecting apps came along and matched the best that Facebook and Twitter and Pinterest to have to offer. But actually, due to the profound entrenchment that these platforms already have across culture, the new apps have to be an order of magnitude better in user experience. The good news is, as the rest of the web transitions from making pages to making streams, they'll all be revisiting the tools and technologies they use to connect, and that'll form a big opportunity for new players to participate.
  • Rethink funding fundamentals. As we've seen over and over, the giant social networks seem to inevitably piss off their user bases by changing product features and terms of service in ways that catalyze huge waves of user-generated discontent. But the fundamental reason these sites refused to accommodate so many user demands is because of economics. Those sites make their revenues on models dictated by the terms of funding from the firms that backed them. But as we've discussed before, it's possible to fund contemporary startups either without venture capital, or with a level of efficiency that allows mom and pop startups to reach web scale. To be clear, venture funding powered much of the first wave of social startups and were a big reason they were able to achieve many of their successes, so VC will be part of the ecosystem in the next wave as well. But the terms and dynamics can be profoundly different, supporting startups that are intentionally less efficient, perhaps even making use of the skills of blue collar coders to provide a lot of people will good, solid middle-class jobs instead of optimizing, as current companies do, for making a small number of people enormously wealthy.
  • Explore architectural changes. One of the fundamental reasons that the economics of doing a startup at web scale are different is because of the proliferation of cloud computing and very, very high-performance, reliable open-source components that provide advanced functionality which was prohibitively expensive a decade ago. Instead of backing up a truckload of Dell servers to a data center and then installing a few hundred thousand dollars worth of Oracle software, we can pick and choose a few components off the shelf to get started. More importantly, consumers will start to be able to use the cloud themselves, which removes the current constraint around having to build single, centralized services to provide a great consumer experience. Today, big social apps have to spend millions of dollars handling DMCA takedown requests and FBI investigations into illegal content and in general fighting the web's fundamental desire to be centralized. New apps don't need to obey those constraints.
  • Outflank by pursuing talent outside the obvious. The current wave of the social web doesn't just demonstrate its arrogance through its product decisions. The people involved in creating these platforms are hired from a narrow band of privileged graduates from a small number of top-tier schools, overwhelmingly male and focused narrowly on the traditional Silicon Valley geography. By constrast, the next wave of apps can harken back to many of the best of the early social startups, which often featured mixed-gender founding teams, attracted talent from geographically diverse regions (Flickr was born in Canada!) and were often created by people with liberal arts degrees or even no degree at all. Aside from being the responsible thing to do, having a diverse team generates a variety of unexpected product features and innovations that don't come from the groupthink of homogenous cultures.
  • Exploit their weakness: Insularity. Another way of looking at the exclusionary tendencies of typical Silicon Valley startups is by considering the extraordinary privilege of most tech tycoons as a weakness to be exploited. Whether it's Mark Zuckerberg's unique level of privilege limiting his ability to understand why a single, universal public identity might ruin people's lives, or the tendency to launch apps first to a small, clubby circle of insiders, new startups don't have to repeat these mistakes. And by broadening their appeal from the start, new apps and networks can outflank the big players, paying attention to audiences that hadn't been properly respected last time. That insularity even extends to the tech industry typically ignoring the world of policy and regulations and government until it's too late. While the big tech players have formed their own RIAA, the best case is that they'll focus on overall issues like spectrum policy and net neutrality, ignoring the coming reality of policy changes that will try to protect regular users.
  • Dont' trust the trade press. Another essential step for breaking out of the current tech industry's predictable patterns will be for entrepreneurs and creators to educate themselves about the true history of the tech industry and its products. Our business tends to follow a few simple, repeating cycles, like moving from centralization to decentralization and back, or from interoperable communications to silos and back. But as we've discussed, you can't trust the tech press to teach you about the tech industry, so you'll have to know your shit. Fortunately, a lot of us old-timers are still around, and still answer our emails sometimes, so it's possible to just ask. Imagine if Instagram had simply asked the folks who used to work at Flickr, "Did you ever change your terms of service? What freaked people out?" And even better, we can blog our own progress, because if you didn't blog it, it didn't happen. In that way, we form our own community of practice, our own new peer review process for what we learn about making the web work the right way.
  • Create public spaces. Right now, all of the places we can assemble on the web in any kind of numbers are privately owned. And privately-owned public spaces aren't real public spaces. They don't allow for the play and the chaos and the creativity and brilliance that only arise in spaces that don't exist purely to generate profit. And they're susceptible to being gradually gaslighted by the companies that own them.

Overall, there are lots of ways that the current generation of social sites are vulnerable. There are users that the current tech industry considers undesirable, and technology choices that are considered taboo, and traditions around hiring and product strategy that force them to concede huge opportunities right out of the gate.

As is obvious from the responses I've gotten, many, many people care about a social web that honors certain human and creative values. As I've spent years thinking about the right way to write for this blog, and to build ThinkUp, and to sit on the board at Stack Exchange, and to advise clients at Activate, and to work on all the other stuff I do, I just keep running into the fact that there's a huge opportunity to make a great new generation of human-friendly apps with positive social values.

These new companies will be recognizable in that they'll impact culture and media and government and society, and that they'll invent great new technologies. They'll still make a bunch of money for the people who found them. But they'll look different, both in terms of the people who make them, and the people they serve. And they'll be more durable, not optimized based on current fashions in financing, but because they're built on the accurate belief that there are people who care deeply about the web they use, the works they create, the connections they make, and the humans on the other side of those connections.

What Developers Want

September 24, 2012

There are lots of different ways to measure how friendly a company is toward developers, and whether a tech company complies with the values that its developer community cares about. I'm a big believer in what I earlier called "radical institutional empathy". What this entails is not being an apologist for any one company or institution, but rather trying to understand its decisions within the context of what the people who work there must be trying to do.

The problem is, it's hard to do that in the current world of tech writing; people want to bring their own biases (things like whether a company is "good" or "bad", or whether a particular technology or strategy is "open") rather than applying a fairly consistent set of evaluations to all the players in a space.

jobs-iphone-quadrants.jpg

One useful recent example is the conversations about Twitter's APIs. When I wrote What Twitter's API Announcement Could Have Said, people both mistook it to be my personal feelings about what the company could have said, or my literal interpretation of what Twitter was trying to describe. It was neither. Instead, it was an attempt to show a developer community that's largely abandoned any attempt at logically understanding a platform's changes and is now fully in the throes of emotional responses to anything that happens. Now, I understand that Twitter's own communications have been part of the reason there's been that breakdown, but all big companies are bad at communicating. That's just a fact. So we have to have a more reasonable way of reading the tea leaves.

Comparing Oranges

Let's try applying a reasonably consistent set of commonly-held developer values to the flagship platforms of two of the tech world's favorite companies, Apple and Twitter. Obviously, the companies are wildly different in the audiences they serve and in what they provide to developers, but this is a useful comparison precisely because the loudest developer voices on both platforms comprise many of the same people.

Policy

Twitter API

Apple iOS

IP Practices

Has introduced the Innovator's Patent Agreement, an extensive new effort ensuring its software patents will only be used defensively, which makes developers optimistic. Has a history of aggressively pursuing patent protections, which even when justified open the door to ever-more-expansive interpretations of software patents, leading even sympathetic developers to worry.

Content Censorship

The company fought tooth-and-nail to avoid giving over a user's private information, defending the case against the government to the maximum of their legal abilities. The company refused to allow news to be published on its platform because it was "not useful".

Roadmap for Third Parties

Published an obtusely-worded but generally reasonable set of guidelines for third-party developers on its platform, without explaining how those guidelines align with its business model. There is no documented process of appeal for apps which are cut off. Publishes a concisely worded and clear set of extremely restrictive guidelines which are subject to change regularly. Has a well-documented process of appeal for apps which are cut off.

Competing with Developers

Told third-party developers to focus on analytics and value-add instead of read/write clients two years ago; Reiterated this recently. Hasn't shipped any apps that compete in other categories, but is tightening restrictions on apps in the read/write category. Provides no guidance beyond the platform terms as to which areas apps should avoid, but has expanded to digital wallet, voice search, podcasting, video chat, reminders, reading, game networking, and other apps in competition with third-parties that had released earlier apps on the platform.

Turning the Table

I understand that these comparisons are necessarily imperfect, and selective in their focus. Apple is very different from Twitter in that it plays the role of a payment middleman. (I find the defense that Apple allows ways around its platform shortcomings through use of the web to be spurious; If we grant it for Apple, then we'd have to grant it for Twitter. The web doesn't have these weaknesses.)

My point here is not to defend Twitter or Apple, though partisans of either company will undoubtedly say I'm being unfair to their favored platform. But rather, we should look fairly at their stances on important issues like free speech, intellectual property rights, self-expression of users and stability of developer opportunity when evaluating them.

Given that the most prominent pundits who've opined on the merits or weaknesses of these platforms often develop for both, I'd be curious to see how they interpret these facts about the company's positions in the context of how the companies see themselves and their goals.

Authentication

We can rightly be frustrated at Twitter having targeted some apps in its upper-right quadrant; Rather than simply waving off client developers, Twitter could have said "it'll get increasingly expensive and difficult to compete in that market" and it would have had the same chilling effect without being punitive. But if we are frustrated at that, then certainly we should consider that the majority of popular iOS applications which aren't games are in Apple's virtual upper-right quadrant. Maybe that's fine. If so, then it should be fine on any platform.

And if we think changing the rules of the game as developers are playing it is unfair, then clearly neither of these companies, nor any major platform company, can be considered to be fair. As I make the decisions for how my own company will invest in these various platforms, I feel reassured again and again that the open web is the safest long-term bet for retaining control over my own destiny.

What Twitter's API Announcement Could Have Said

August 16, 2012

A few years ago, I wrote about the Law of Fail: Once a web community has decided to dislike a person, topic, or idea, the conversation will shift from criticizing the idea to become a competition about who can be most scathing in their condemnation.

This is relevant today because Twitter announced some upcoming API changes. From my standpoint, these are mostly pretty reasonable, and in fact should have almost no impact on any normal Twitter user. Naturally, super-geeky developers are incensed. And of course, the people who most eagerly participate in the pile-on usually have the least skin in the game — they just want to complain.

But to be fair, a valid annoyance for developers is that the communication from Twitter about these kinds of changes has been vague enough to leave them uneasy. Combine the tech blogosphere's Law of Fail behavior with the tendency that crowds have toward assuming the worst rumors in any given situation must be the truth, and you have a recipe for panic.

So, as an exercise in radical institutional empathy and the real-time exploration of alternate histories of the tech industry, I wrote my own version of the Twitter API 1.1 announcement.

My goal is to communicate the exact same points, but with the clarity that would inspire the least amount of user-generated discontent possible. It's also shorter by about 500 words and omits the 2×2 grid of API clients. Edits, corrections or criticisms are welcome!


Our biggest Twitter API upgrade ever

We have awesome news for Twitter developers: Today we're announcing the upcoming release of the biggest new set of features and changes to the Twitter API ever, which we're calling Twitter API version 1.1. We know change is scary, so we'll talk about what's new, why we're making these changes, and when you can expect to see them. Don't worry — it'll be worth it!

The TL;DR version of what's new:

  • More API calls for almost every kind of app, with per-endpoint rate limits
  • Better security by extending OAuth to all APIs
  • A clear roadmap for Twitter app developers to know what's encouraged, including detailed instructions on how to show tweets and timelines
  • A few new restrictions for people making traditional Twitter clients
  • When version 1.1 is officially released, you'll have six months to migrate from API version 1.0

Huge increases in API call limits:

In today's API 1.0, we limit authenticated API requests to 350 per hour. Good news: We're going to blow that limit away for your apps providing 60 calls per hour per endpoint - so you can literally hit every different endpoint every minute and not go over the rate limits. Endpoints that are really in demand, like Tweet display, profile display, user lookup and user search go all the way up to 720 calls per hour.

This is a big increase for almost every kind of app, and we'll give you the full details of the new extra-legroom limits when API 1.1 is released.

All Auth Everything


The big new API call limits come with only a minor change in what's required from you: You'll have to use OAuth for all of your API requests. This shouldn't be a big deal because it works the same way as the OAuth requests you're already making. (If you are not yet using OAuth, OMG shame on you, you've got until March 2013 to get with the program.)

An awesome side bonus of this new auth regime is that people who are abusing the Twitter ecosystem we all share by scraping or writing spammy bots or other annoying behaviors will be able to be reined in using their auth tokens, instead of the brute-force block-by-IP method we're stuck with now. Here's crossing our fingers for less spam!

We Love Your App!


Sure, there's been some hand-wringing about what direction we're headed with our API, and whether third party developers are "safe" working on Twitter. Good news: Your app is welcome here, and we appreciate you developing on Twitter.

In order to make sure we don't ever get the community worried again (and to hopefully stamp out some of the scarier rumors that pop up in the ever-reliable tech press), we want to give some detailed outlines of how to make sure you're in the clear while working on the Twitter API.

Obviously, our greatest wish is that your app is hugely successful on Twitter, and we of course need to make sure to support our business model, including promoted tweets and sponsored tweets and whatever else we come up with.

So, the first thing we're doing is offering up detailed documentation of how tweets and timelines have to be displayed when using the new 1.1 API. This is mostly to ensure a consistent, simple interface for users who are hopefully switching between lots of cool Twitter-powered apps, including yours. But this also cuts down on apps that introduce confusing buttons or UI to try to pull people out of their Twitter experience, and makes sure the advertisers who actually pay for this whole thing to run get what they're expecting, too.

You can read the guidelines on your own, but the bottom line is that Tweets will start to look really consistent everywhere. That also means that apps which deliberately try to change the way Tweets or the Twitter UI looks can be shut down, so don't do that.

Oh, and if you need a lot of user tokens (like, more than 100,000), get in touch with us and we'll take care of you personally. If you try to make that volume of calls without a special request, you might get shut off.

A Note On Traditional Twitter Clients

The only kind of Twitter app which has real constraints under API 1.1 is traditional Twitter posting clients -- ones that offer the basic reading and writing experience and little else. While we appreciate these apps (our own official Twitter clients started out as one of these!), the reality is it's going to take more effort for third parties to maintain these apps than it has in the past, because we're going to be very strict about requiring updates to make sure your clients are in compliance with the user experience standards we set in our own first-party apps.

Put simply: If you have made a traditional Twitter client, you're going to be expected to hew very closely to our new display guidelines and will regularly be asked to make updates about the way you display content, sometimes with short notice. We recognize that might cause additional costs or stresses that make it less rewarding or more frustrating for this small but important community of developers, but this is essential for building a robust, successful Twitter business to support us all, and for us to shut down the small but persistent number of developers who use this kind of access to make spammy apps that degrade the Twitter experience for everybody. Client apps that don't keep up with these standards or that fail to immediately reflect changes that are required will have API access cut off.

That being said, many third-party Twitter clients have dedicated user communities and passionate developers, and with focus on keeping in step with our evolution, they should continue to thrive with their audiences.

People making stats apps and analytics tools and social media marketing platforms all have absolutely nothing to worry about -- the vast majority of Twitter client apps will move to the new 1.1 API with no changes expect better auth and higher API limits.

More To Come!

We're excited about the apps you're going to build on the new APIs, and we'll be unveiling even more powerful features for you to incorporate features like Twitter Cards which will make your apps and sites even more engaging. In the meantime, if anything in this announcement is unclear, let us know in the forums or by @replying to us on Twitter, and we'll answer any questions you have.

Stop Publishing Web Pages

August 14, 2012

Most users on the web spend most of their time in apps. The most popular of those apps, like Facebook, Twitter, Gmail, Tumblr and others, are primarily focused on a single, simple stream that offers a river of news which users can easily scroll through, skim over, and click on to read in more depth.

Most media companies on the web spend all of their effort putting content into content management systems which publish pages. These pages work essentially the same way that pages have worked since the beginning of the web, with a single article or post living at a particular address, and then tons of navigation and cruft (and, usually, advertisements) surrounding that article.

Users have decided they want streams, but most media companies are insisting on publishing more and more pages. And the systems which publish the web are designed to keep making pages, not to make customized streams.

It's time to stop publishing web pages.

But I'm Reading This On A Web Page Right Now!

Obviously, I've written this in an old-style content publishing system, and this piece lives on my website as an old-fashioned HTML page. But if I had my preference, I'd write up an article like this, and it'd seamlessly glide into a clean, simple stream of my writing, organized by topic and sorted with the newest stuff on top. Blogs have always worked this way, but they were shoehorning this stream-like behavior into the best representation possible under the old page model.

I don't have a tool I can use to run my website which will output a stream that works the right way. "What about using Tumblr to publish your blog?" you ask. Well, besides the fact that my site would have to run on their infrastructure, individual tumblr-style blogs don't allow you as a reader to personalize or customize the types of content in the stream, the way you would be choosing people to follow on Tumblr, Facebook or Twitter. You can't choose to follow just the music-related posts on my blog, ignoring the ones about technology.

This isn't just about how the content looks, it's also about how it works. The smart, responsive, dynamic apps most of us use on the web everyday have all kinds of subtle but powerful bits of functionality which appear as we hover or click on items in a stream. Meanwhile, our pages are still piling a row of awkward-looking share-button cruft at the bottom.

Also: Dollars

The vast majority of advertising online is dependent on a page-view model that users have overwhelmingly decided to abandon. Facebook, Twitter, Tumblr and others will succeed by making in-stream advertisements that fit in with the native content of their networks. Meanwhile, page-based sites are cramming every corner and bit of white space on their sites with ads that only ever decrease in effectiveness until they are made even larger and more intrusive every few years.

Stream-based content naturally flows across different devices and media, from tiny phones to tablets to giant desktop monitors, with an adaptivity that works naturally hand-in-hand with responsive design. Page based ads basically have to be reimagined on each platform, and fundamentally don't work in mobile form factors.

Streams of content can easily be read in friendly native apps on mobile platforms with the content flowing through simple APIs. Pages get squeezed into faux-mobile app experiences that look just enough like native apps to be frustrating and annoying when they don't perform correctly. Pages tell users there's no mobile version of this story available, or accidentally redirect an interested user to the site's homepage, from where they quickly depart. Pages stop your flow.

Pages vs. Streams

Let's Fix This

So: Start publishing streams. Start moving your content management system towards a future where it outputs content to simple APIs, which are consumed by stream-based apps that are either HTML5 in the browser and/or native clients on mobile devices. Insert your advertising into those streams using the same formats and considerations that you use for your own content. Trust your readers to know how to scroll down and skim across a simple stream, since that's what they're already doing all day on the web. Give them the chance to customize those streams to include (or exclude!) just the content they want.

Pay attention to the fact that all the links you click on Twitter, on Facebook, on Pinterest, all take you to out of the simple flow of those apps and into a jarring, cluttered experience where the most appealing option is the back button. Stop being one of those dead-end experiences and start being more like what users have repeatedly demonstrated they prefer.

And if you're smugly thinking "oh, we're an app — he's only talking about publishing content, so we don't have to pay attention", then you should get to work, too. Except for power tools which need to make use of the screen in a particular way, most of our other apps are going to be rearranged into streams, too.

Further Reading

  • From ten years ago, Stories and Tools (Michael Sippey, now Twitter's head of consumer product, liked this piece so much back then that he republished it.)
  • At Activate, we created a presentation called "What Matters" at the end of last year; It starts by offering some data about use of page-based sites vs. stream-based sites by web users.

Why Your Complaint About Twitter Is Wrong

July 2, 2012

I know I usually try to be a thoughtful tech writer, but sometimes, holy shit you guys.

Twitter, because of their API, actually was a real-time protocol to connect various services in a novel way. I had debates with my other tech-nerd friends about whether Twitter could be one of the fundamental building blocks of the Internet via their powerful API. ... In this scenario, Twitter would have turned into something like a realtime cloud API company.

That's Dalton Caldwell (with my emphasis added), who is a very nice guy, but does nothing to break the pattern that everything I read on the Svbtle network exists solely to infuriate me for no good reason. I even tend to agree with him, and that's why it's worth questioning our conventional wisdom.

Here's the thing: I love the idea of a realtime cloud API company! I'm that dude. I write long, rambly blog posts about it, just like I did about Twitter itself, back when it was young. I love this kind of idealism.

But. Nobody wants a realtime cloud API company. I mean, I want one, but speaking from a statistical standpoint, that isn't what any normal person wants. For those who are geeky enough to want something, it ends up looking like Urban Airship or any one of the many other delivery as a service startups. Those realtime delivery thingys are awesome, but nobody would argue that they become the kind of household name brands that one represents entirely with a pictographic bird logo.

So why are smart folks like Dalton writing things like this? Why is Nova Spivack talking about a Twitter API problem? Because, in addition to some worthwhile technical requests, they're lamenting that Twitter isn't just for geeks anymore. This isn't some nefarious plan by the tyrannical cabal that controls Twitter to create a Horrible Commercialized Network For Kardashians; It's a result of the fact that so many normal people showed up to use the service.

Geeks are lamenting that they don't dominate and control this network, and expressing it in the only way we know how: Through technological triumphalism. If the culture of a giant network doesn't resemble the culture we prefer, then it must be a problem that can be solved by making the network more technically complicated.

What About The Open Web, Maaan?

Don't get me wrong; I would love if it made sense for Twitter to be some hippie utopian open protocol that also happened to support a multi-billion dollar company. That'd be great. But the amount of Kremlinology and hand-wringing over one short blog post from Michael Sippey that I've seen in the past few days reveals that people's concerns are not about what Twitter is doing, but rather the core technical community's own feelings about the fact they don't determine what Twitter is anymore.

Now, full disclosure, Michael Sippey's a friend and we worked together for more than half a decade. I haven't talked to him about his blog post, but this is a guy who was onstage with Steve Jobs at the original launch of the app store for the iPhone. He's not some crazy kid who doesn't understand how platforms work!

Yet we've got a lot of people using Aaron White's post as an example of Twitter's new clampdown on developers. I'll say this, because it's not Aaron's day job and he has other projects going on: His app TweetFavor should be shut down. It's an app for prompting others to robo-tweet about a project. It encourages people to repost crappy, spammy tweets, and that's when it's working properly. Now, Aaron did it as a quick hack to show off some tech, so I understand he was just scratching an itch, but man am I glad I don't have to read what that app would output in my timeline.

The other big example being used to raise alarms about Twitter's new direction? The disconnection of tweets from LinkedIn. Okay, show of hands, who loves that LinkedIn tweet integration? Who's gonna say Twitter sucks for taking away that awesome read-tweets-in-LinkedIn experience?

I'm no expert, but I didn't think Merlin was that big a fan of LinkedIn. Huh.

It's about the ecosystem!

The most insidious and wrong-headed objections to Twitter's not-yet-disclosed future moves is the idea that somehow Twitter's moves are affecting the diverse and flourishing ecosystem around Twitter's API. Now, to be clear: The company needs to address uncertainty and doubt around their API intentions in order to make developers feel safe.

But diversity of the developer community? Let's take a look. Lots of people keep pointing to Tweetbot as an example of the kind of great third-party development that encourages a diverse ecosystem of Twitter developers.

Here's geek-beloved Tweetbot developer Paul Haddad on the diversity he wants to see from the developer community:

Here's Twitter's statement on the topic from last week:

Yes, why indeed isn't Twitter taking hints from this community about how to encourage more diversity amongst developers? If you want a diverse set of applications in an ecosystem, you have to have a diverse community of developers. Right now, the apps championed as innovators in the narrow, legacy tech community around Twitter are visibly fighting against those new voices entering the community. Is it any wonder why?

Sure, Twitter's made lots of mistakes with their ecosystem. But their track record of keeping it vibrant and growing is a lot better than most of the critics, and reflects a user focus that few other companies have. They can absolutely do a better job of making their branding consistent, but I'd rather have a few dusty corners in some Twitter apps than be cobbling together a hodgepodge of apps from developers who want to close the door behind themselves.

Readability And Intention

November 17, 2011

The latest launch I'm ecstatic to share with you all: My friends at Readability (whom I advise) announced their amazing new platform! Though it's best known as a simple way to clean up the formatting of an article that you're reading on the web, there's an incredible depth to what Readability now offers:

  • A terrific service that integrates with any web browser to make reading more pleasant either now or whenever you have time to read — and now that service is free!
  • A brand new HTML5 web app that lets you read on the go on any platform, soon be joined by a beautiful iOS app that will let you read on your iPhone or iPad
  • A robust and inspiring API that powers the entire Readability platform, which is already starting to upgrade some already-amazing apps like Reeder and TweetMag

But as cool as all that news is, I'm even more excited about what's in store in the future for Readability, and I thought I'd explain why.

Things Can Be Beautiful

Just one small, wonderful detail about the upcoming Readability apps for iOS epitomizes why I can't wait for Apple to approve them: Every time you're reading in the new apps, you're seeing typography by Hoefler & Frere-Jones. I'm certainly no designer, but even from a layman's perspective, I know what a big deal it is to be the first app to have this level of type expertise be applied to the reading experience.

It's not just the font-hipster value of reading a headline set in Gotham or body copy in Whitney; What I'm struck by is the sheer commitment to quality in an app experience down to the finest level of detail. The Readability team teamed up with Teehan + Lax to make what I'm comfortable calling the best-designed, most attractive mobile apps I've ever seen. In a world where every Apple blogger is wringing their hands over skeuomorphism, it's delightful to see a family of apps go the other way into pure, beautiful function.

A Real Platform

The geek in me cares about what's under the hood, though, too. And as no less an authority than Dave Winer noted, Readability's new API is formidable. I frankly didn't get it a few years ago when Dave was always so excited about OPML and reading lists, but these days I understand that a simple, synchronized list of the content that matters to you is something that should almost exist at the operating system level. It should just be baked into everything you do.

The experience of an "it just works" synching system in the cloud is powerful. For files, I get that experience from Dropbox. For notes, I wanted that experience from Evernote, but always got too much other crap. (Note: Evernote's a very nice app, and I know lots of people love it, but I just want things to be clean and simple and not full of all kinds of bells and whistles for tasks as important as reading.) Managing that type of synchronization across all my phones and tablets and laptops and desktops and other systems is a significant task, and it's impressive that Readability is poised to do that for me not just in all the Readability apps, but even across my other apps as well.

That's not to say that the basic "let's clean up this page" capability of apps like Evernote isn't valuable — it's great! But that much is built in to the browser on my phone these days. What I care about is having the information that I want to read be available wherever I am, in the format that's most readable. It's a capability that I firmly believe will be baked in to all of my most commonly-used tools and apps in the years to come. And it's a vision that's much bigger than any one app.

Trust and Values

Of course, as I noted yesterday, I also care a lot about owning and controlling my data. Readability's API makes it very easy for me to manage and maintain a list of what I'm reading without giving up my ownership of that list. I can take my ball and go home, but just as importantly, I can take my list and plug it in to whatever else I'm doing.

That's critical because, as I'd noted at the beginning of this year when I first joined Readability as an advisor, reading is a profound and meaningful experience, and in my opinion is among the most valuable things we can do with our time on the Internet. I need it to be everywhere that I am, and I need to trust that the platform which powers my reading online shares those values. Even for simple things, like not sharing my reading behavior without my express permission.

The best way I can show the character of the team behind Readability and the community around it is by talking about who's not working with Readability's platform — yet. Marco Arment, creator of Instapaper and a former fellow Readability advisor, had a thoughtful and respectful note about the fact that he and the Readability team have gone their separate ways now that their respective apps are slightly more competitive with one another.

I don't mean to tell tales out of school, but I know the Readability team respects Marco as much as he respects them, and the fact that innovative, creative entrepreneurs can work together (or work apart) in such productive ways is why I'd feel safe as a developer building on Readability's platform. And I hope to see Instapaper and the Readability platform (both of which I happily pay for) work together at some point in the future.

But, for that matter, I hope to see Readability baked into Google Chrome and Microsoft Word and iBooks and all the other apps I use every day, too.

Read Later

There's a lot more I can say about Readability because I'm so excited by the platform's potential. But for now, there are a few key points I'd start with if you want to explore more:

  • Readability's API is going to be one of the most meaningful tools that developers can bake into their apps in the months to come. It really does remind me of the early days of Twitter's API, in the feeling that it inspires in me to want to spend a weekend hacking on it.
  • Readability is also one of the key APIs that support this year's NYC BigApps challenge, where you can win your share of $50,000 in prizes as a developer. I think this year's apps are guaranteed to be the best ever in a BigApps contest.
  • You may want to revisit Reading is Fundamental, where I mentioned earlier this year the ideas that made me so passionate about Readability and its potential.
  • CNN has an odd, but sort of charming, look at the new Readability. I preferred Ben Popper's take at Betabeat.
  • And, going back more than four years, To Read is To Be Human, when I first started reflecting on the optimism and idealism that's captured in the simple action that so many of us do every day when we save an article with the intention of reading it in the future.

Cloudtop Applications

September 14, 2010

One interesting pattern I've noticed popping up around my favorite new apps these days is that they follow what I'd call a "cloudtop" design. I thought I'd share my own notes on this pattern primarily so that people I'm talking to know what I'm prattling on about, but also in case anybody else finds the concept useful.

Great web apps like Dropbox (affiliate link) and Evernote aren't merely web services that happen to have APIs, or simple desktop apps; They live in a sort of new in-between state that seems to be delivering the promise of past hype like Microsoft's "Software Plus Services" slogan.

The key traits of a cloudtop app are:

  • The app is designed with the assumption that you work and live across multiple devices, with broadly varying capabilities.
  • While the app performs synchronization tasks, there's no "synching" action, its handles that function (often alongside version control and conflict resolution) automatically.
  • Cloudtop apps are delivered as native code on nearly every supported platform, from desktop computers to smart phones, with an interface that scales appropriately.
  • While the app may have a web interface, that's largely a convenience and is not usually the primary way in which you interact with the app.
  • These apps often adopt a freemium model, with payment introduced in a very obvious way based on usage.
  • Though they have native first-party clients, APIs allow for the app to become a platform for other developers, as with the Elements text editor or AirDropper uploads for Dropbox, or any of the apps listed in the Evernote Trunk directory.

In this pattern, iTunes isn't really a cloudtop app, despite having native clients on iPhone and on Windows and Mac, because it doesn't easily, let alone automatically do synchronization of libraries between those platforms. Netflix, despite starting as a disc delivery service, is rapidly evolving into what feels like a cloudtop platform — my library is available anywhere with great native apps on many devices, and it syncs my history and queue automatically.

Twitter may evolve into a cloudtop platform if its native clients win on every platform, but the fact that its primary use is far and away through its HTML web interface, it doesn't seem as if that's likely, and other aspects like a freemium business model or really robust synching (all my clients show a different subset of my DMs) don't seem to be a priority. Cloudtop apps seem to use completely proprietary APIs, and nobody seems overly troubled by the fact they have purpose-built interfaces.

One last, interesting note about this class of apps: They have social functions like sharing, but they're not really fundamentally social apps. I can share a Dropbox folder or Evernote notebook with you, but that's not the primary means of discovery. Word of mouth is what drives adoption, and there's little to no integration with networks like Facebook or Twitter, with the apps relying instead on good old-fashioned email for a lot of their social function. I'm not quite sure what that means, but there's some lesson there, especially given that these apps are very popular with a lot of mainstream, non-techie users.

Blackbird, Rainman, Facebook and the Watery Web

October 9, 2007

I've seen a number of people make reference to Facebook's application platform without knowing a lot of background about some historical examples that might be useful to learn from. So, since I remember a good bit of info about these things, I figured I'd share it for future reference.

In 1995, Microsoft believed that its proprietary development tool, codenamed "Blackbird" would be the dominant platform for creating rich online experiences. While it would eventually evolve into a tool that created reasonably standard HTML, Blackbird's ability to make attractive and pleasing aesthetic experiences for MSN was considered a no-brainer to replace regular HTML for anything that needed to seem polished. It wasn't an unreasonable assumption at a time when most browsers were showing ugly text on a plain grey background with almost no advanced layout or design.

In 1999, AOL believed that its proprietary development tool, called RAINMAN (Remote Automated INformation MANager) would be the dominant platform for creating rich online experiences. While it would eventually be replaced by tools that created reasonably standard HTML, Rainman's ability to make attractive and pleasing aesthetic experiences that integrated seamlessly into the AOL client was an effective replacement for HTML for tens of millions of users who wanted a polished and social first experience on the Net in the late 90s as they first got online. This wasn't an unreasonable constraint to impose on the experience at a time when having a rich interactive experience meant downloading complicated browser plugins for video, or configuring temperamental client software just to read email.

AOL was always secretive about Rainman, and remains so to this day, even though Rainman has been largely retired in favor of standard HTML, which has let AOL open up much of its proprietary content to the public web. But Microsoft really wanted to get the word out about Blackbird. There were even conferences for developers, to promote Blackbird for their applications. Ironically, MSN would reverse direction from Blackbird almost immediately after launch, eventually building much of its original content around a small vector plugin called FutureSplash. One big reason you have Flash in your browser right now is because MSN aggressively distributed millions of copies of the FutureSplash plugin with all of their client software, and eventually, with Windows itself. But that's a whole 'nother story.

Back in late 1995, the venerable Release 1.0 newsletter offered an analysis of Blackbird that's well worth reading in its entirety. Some highlights:

Microsoft's challenge is to make MSN flourish soon, so that it won't be eclipsed by more open systems, making Blackbird irrelevant, or at least obsolescent. ... The question at hand is whether Microsoft's networked-application architecture makes it beyond MSN's walls and becomes more commonly used. The innovations Netscape is introducing, described above, make this a difficult task. This is where the battle between proprietary operating systems and the Internet is being fought.

...

Microsoft wants Blackbird to be an inviting environment for third-party tools. The pace of technological change will help. Connectivity will change all standalone applications, making many obsolete. With Blackbird, Microsoft is attempting to offer traditional Windows applications a viable path to re-create and re-validate themselves in the networked world. ... Blackbird has its own representation format, the Blackbird Markup Language (BML), which is a variant of HTML enhanced to be OLE 2.0-aware.

In 2007, Facebook has released its proprietary development platform, codenamed F8. Blackbird was to provide better presentation, and Rainman promised better social abilities, than open standards of their time made possible. F8 promises a combination of both aesthetic and social capabilities, with the key feature of the platform (presented as an "innovation") being the social APIs for friends lists. F8's ability to create broadly-distributed social applications that integrate seamlessly into the Facebook environment offers an experience that, for now, exceeds what publicly-available social APIs can do. It's not an unreasonable behavior that people are building and using applications on the platform today.

  • Just like Blackbird, Facebook's APIs offer more features than the available open standards do today.
  • Just like Blackbird, Facebook's APIs have inspired conferences and development toolkits and a lot of reactive responses in the industry.
  • Just like Rainman, Facebook APIs offer native integration with social functions like buddy lists.
  • Just like Rainman, the user experience for integrating those applications is far easier than the equivalent behavior on the open web.
  • Just like Rainman, Facebook's APIs support applications that have millions of users, users that the conventional wisdom says could never be displaced.

It's not true to say that Facebook is the new AOL, and it's oversimplification to say that Facebook's API is the new Blackbird, or the new Rainman. But Facebook is part of the web. Think of the web, of the Internet itself, as water. Proprietary platforms based on the web are ice cubes. They can, for a time, suspend themselves above the web at large. But over time, they only ever melt into the water. And maybe they make it better when they do.

Some links:

  • We're opening up the Social Graph. Six Apart, where I work, is committed to helping create, promote, develop for, and popularize the open standards that will be needed for helping grow social platforms from Facebook or anyone else.
  • The O'Reilly Radar Research Report on Facebook's application platform. Interestingly, given the Release 1.0 report I quoted above, that publication has evolved into Release 2.0, which is now an O'Reilly publication.
  • Jason Kottke on "Facebook vs. AOL". He covers much of the fundamentals that I've discussed here, and helped inspire me to offer some more concrete examples of the history of these sorts of efforts.
  • Somehow I'd missed it at the time, but Scott Heiferman had drawn the analogy to Rainman first. I still feel people aren't very familiar with that point in web history.
  • Graphing Social Patterns, the conference on Facebook and its applications that Dave McClure is currently hosting.
  • The circle of web life, another similar historical lesson.
1