Results tagged “apis”
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.
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.
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.
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.
|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.|
|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.
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.
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.
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.
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.
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.
- 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.
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?
It’s inspiring to know Twitter’s pursuing SO many different ways to suck faster.Takes some serious vision to ruin something this awesome.— Merlin Mann (@hotdogsladies) July 1, 2012
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:
So all the folks pushing the women in tech issue are equally committed and supportive of men in nursing, right? twitter.com/tapbot_paul/st…— Paul Haddad (@tapbot_paul) May 25, 2012
Here's Twitter's statement on the topic from last week:
We are working with Girls Who Code, a new program that will empower high school girls to pursue a career in technology. blog.twitter.com/2012/06/workin…— Twitter (@twitter) June 26, 2012
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.
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.
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.
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.
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.
- 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.