Twitter – rc3.org

Tag: Twitter (page 1 of 3)

APIs and accountability

I love Twitter, but I’ve been unhappy with the company since they made the decision to stop supporting third party clients that compete with their own native clients. There are still some good ones available, but Twitter has actively discouraged the development of new clients by not adding third party API support for many new features, and by limiting the supply of API keys to client developers.

In the meantime, Twitter has let the native OS X Twitter application languish. Here’s Jason Snell:

If Twitter doesn’t have the resources or inclination to properly support platforms like the Mac (or, quite frankly, iOS and Android), perhaps it should rethink the decisions made by the prior regime and find a way to let other developers apply their expertise to the problem. Alternately, maybe Twitter should figure out how to use its huge team of app developers to create first-class native apps for not just iOS and Android, but the Mac and Windows too.

It’s not a coincidence that Twitter’s updates to its OS X slowed when they decided to cut off third-party clients. The third-party client market provided two things Twitter desperately needs, competition and free research and development. When the Twitter client market was healthy, there were dozens of development teams coming up with cool new Twitter features that the company could roll into its platform. Many of the features that are core to Twitter now originated in the Twitter community.

A fully functional API that third parties can use imposes a sort of accountability on a company’s engineering team. Giving users a choice of clients or tools demands that the product team at Twitter builds applications that can succeed on their own merits. Competing with third-parties on their own platform is the sort of exercise Twitter needs to stay in shape for the bigger fight with Facebook, Instagram, and whatever else comes along in the future. Killing off that competition has enabled Twitter to be lazy and complacent.

A counterargument one might make is that supporting a full-featured API for third parties is expensive, but I’m not sure that’s the case. Twitter already has, in addition to its Web site, iOS and Android apps, and an OS X app as well. What this means is that Twitter already provides private APIs for all its features that support multiple independent client implementations. In other words, the hard work is already done. Given Twitter’s size, chances are they’ve already put a lot of thought into API usability and written decent documentation for these APIs as well.

The risks of providing robust APIs are minimal. A relatively small number of users are going to seek out and install third-party applications even if they are great. The tangible and intangible benefits are large. Twitter needs to get back into being a platform provider for its own sake.

Dalton Caldwell on the near future of Twitter

November 17, 2012 / Rafe / 1 Comment

Twitter is pivoting

Dalton Caldwell looks at some recent Twitter moves and tries to predict the company’s upcoming strategy. Here’s what he argues that it’s about:

The Discover tab is the future. Rather than forcing normal users to make sense of a realtime stream, they can see what content is trending.

Here’s what I don’t get. You can facilitate the mode of usage that Twitter may envision for everyday users without hurting the power users that have made it what it is. How did celebrities and “brands” figure out how to engage on Twitter? By watching the pioneering users of the service build a following. And many of those users have become celebrities in their own right in the context of Twitter. If Twitter put me on their board (and they should), that’s the advice I’d give them. Passive users may contribute most of the revenue, but the power users contribute most of the energy.

Twitter finally rejects their all-JavaScript approach

May 29, 2012 / Rafe / 2 Comments

When Twitter launched “new Twitter” in 2010, a lot of people decried it as a bad idea. The big change was sending every request to the site to one URL, which hosted a JavaScript application that requested the appropriate data and then converted it to HTML within the browser. Here’s Tim Bray explaining exactly why Twitter’s approach was wrongheaded.

About a year ago, Twitter platform engineer Dan Webb wrote an article rejecting hash-bang as well, which made it pretty clear that Twitter would be moving away from this architecture.

Today, Dan Webb has posted an official announcement that Twitter is dumping the “render everything in JavaScript” approach for performance reasons:

Looking at the components that make up this measurement, we discovered that the raw parsing and execution of JavaScript caused massive outliers in perceived rendering speed. In our fully client-side architecture, you don’t see anything until our JavaScript is downloaded and executed. The problem is further exacerbated if you do not have a high-specification machine or if you’re running an older browser. The bottom line is that a client-side architecture leads to slower performance because most of the code is being executed on our user’s machines rather than our own.

It feels good to see terrible ideas die, even when it takes awhile.

Why Twitter ought to keep supporting third-party clients

December 9, 2011 / Rafe / 1 Comment

John Gruber has posted a lengthy review of the new Twitter client for iOS that was released yesterday. Just as the new Gmail disappointed a lot of longtime Gmail users, the new Twitter client has disappointed a lot of longtime Twitter users. How big are the changes? Here’s how Gruber describes them:

This is more than an update. It’s a serious rethinking of the entire concept of Twitter.

I’m sure the goal of the new redesign is to make Twitter more engaging to new users and to people who’ve signed up for Twitter in the past but have never really gotten into the flow of things. Rather than working to make things better for the people who are already addicted to Twitter, they’re experimenting with new ways to create more addicts. My gut feeling is that the experiment will be a failure this time around, mainly because the interface is rather muddled in the ways that John describes, but I would expect Twitter to continue to experiment in this direction over time.

The other reason for the redesign is that Twitter wants to make more money. That seems to be the reason the Discover tab has been added — not everything on it is stuff that someone is paying Twitter to show you, but that’s the part of it that matters to Twitter. I don’t begrudge them that, either. It’s clearly a case, though, where Twitter is trading off usability for cash. This goes to a point that Maciej Ceglowski made earlier this week, which is that free services have their own set of costs. The one he focuses on is that the risk of a free service being acquired and disappearing along with your data is high. The other, though, is that when a service is funded through advertising or sponsored content, making money and making the product better for end users are in a constant state of tension.

Twitter once had a thriving ecosystem of third party clients that made the constant tweaks Twitter makes to its Web site mostly irrelevant. You could use your favorite client and ignore Twitter’s user interface mishaps. Unfortunately, Twitter seems to be committed to killing off the third party application market. If Twitter were only worried about its first set of concerns — making Twitter more engaging for new users and old users who aren’t taking advantage of the service — then they’d have no reason to shut out third party clients. New users could try out Twitter as designed by Twitter, and the rest of us could use the clients that make sense to us. A diverse client base makes it more likely that power users will stick around — even if the default interface doesn’t work, they can probably find one that will.

The other side, though, is that third-party client developers don’t really care about shoving sponsored content at users. Indeed, the ability to hide or deemphasize sponsored content could be a killer feature for a third-party client. So inside Twitter, a user switching from an official appa third-party app represents lost revenue.

I’d argue that Twitter should support third-party clients anyway. Twitter, like all social sites, derives nearly all of its value from a network effect. Nobody would use Twitter if other people couldn’t read their tweets. For Twitter, it’s better for a user to abandon the official Twitter client for a third-party client than it is for a user to abandon Twitter for Facebook or Google+. A robust ecosystem of third-party clients is a strong competitive advantage for Twitter against other social sites.

Secondly, the intramural competition helps Twitter. When the official apps are losing market share to third-party alternatives, it’s a good indication that they need to put more work into improving their official apps. Third-party apps provide free R&D for Twitter. They can always incorporate the best ideas from third-party apps into the official apps. And finally, developers of third-party apps provide a solid base of talent from which Twitter can recruit.

Twitter’s two key advantages relative to other social sites have always been that it is simpler than the others, and that it is a platform rather than just a Web site. Unfortunately, Twitter seems committed to erasing both of those advantages. The service continues to gain complexity, and Twitter’s management seems bent on reducing the flexibility of Twitter as a platform. I think both are big mistakes, but it’s not too late to rectify either of them.

Not migrating Twitter scripts to OAuth

September 12, 2010 / Rafe / 11 Comments

I have a number of scripts I’ve written that send updates to Twitter automatically. They are Perl scripts that run database queries and then post to Twitter using curl. Unfortunately, since Twitter turned off basic authentication they’re all dead.

Twitter ended support for basic authentication in order to prevent third party applications from asking Twitter users for their passwords. Phishing for Twitter passwords is rampant, and it’s harder to combat phishing when legitimate sites are asking Twitter users for their usernames and passwords.

While I was working on this blog post, John Udell beat me to the punch by posting about the good and bad aspects of migrating to OAuth and a technical guide to the migration.

My use case is simple, I just need to come up with an equivalent to the following code that actually works:

exec("curl -s -u $username:$password -d status=\"$tweet\" 
http://twitter.com/statuses/update.json");

When updating command line scripts to use OAuth, there are three steps. The first is registering the application with Twitter. The second is obtaining an OAuth token that the script can use. The third is updating the script to authenticate using OAuth.

Twitter’s recommendation in this case is that I stop using curl and migrate to an OAuth or Twitter library instead. To be frank, this sucks. Our servers run Red Hat Enterprise Linux and my systems administrator doesn’t like to install random Perl modules. In researching how to solve this problem, I decided to start with Net::Twitter, which has the following dependencies:

DateTime [requires]
Data::Visitor::Callback [requires]
DateTime::Format::Strptime [requires]
Net::OAuth [requires]
Moose [requires]
JSON::Any [requires]
Try::Tiny [requires]
Moose::Role [requires]
URI [requires]
namespace::autoclean [requires]
Moose::Exporter [requires]
JSON [requires]
MooseX::MultiInitArg [requires]

Those dependencies each have dependencies of their own as well. So I’m looking at moving from a script that is dependent only on the curl command line tool, which is already installed, to a script that requires dozens of Perl modules to be installed in order to work. That’s a deal breaker. As an aside, when I tried to install Net::Twitter on my Mac, the installation failed because the tests for the module didn’t pass.

Before I can even bother with registering my silly 15 line Perl script with Twitter as an application and authorize it for the account to which I submit these status updates, I have to rewrite it to use a library that I was unsuccessful in installing on my laptop and probably can’t install on the server, or I can write my own OAuth implementation from scratch to avoid getting caught in the mire of dependencies.

My Twitter script is just dead for now.

Twitter has traded simplicity for the potential for greater security. The emphasis is on the potential, because the tough part isn’t getting third party sites to migrate to OAuth, but teaching users not to give their passwords to sites that ask for them. Just because sites don’t need your password any more doesn’t mean that third parties can’t still ask for passwords or that users won’t continue to enter them when asked.

Update: My scripts started working again a few hours ago with no changes on my end. Has Twitter reenabled basic authentication temporarily?

Twitter integration with @Anywhere

April 14, 2010 / Rafe / 5 Comments

Twitter has launched a new feature for third party Web sites, @Anywhere, automatically converts Twitter usernames to links with a hover effect that provides information about their Twitter account. I’ve added it to the blog. Here’s an example: @rc3dotorg.

If you’re a Twitter user, feel free to use your Twitter username (with the @) in the Name field in the comment form. Then people will see a link to your Twitter page.

If it slows things down or sucks in any other way, I’ll get rid of it.

Rick Bayless on Twitter

October 2, 2009 / Rafe / 0 Comments

Top Chef Masters winner Rick Bayless explains what he likes about Twitter:

On Twitter, I can do three things: I share photos of what’s going on in the restaurant (behind the scenes as well as finished dishes I’m really excited about); I share photos of cool food (and food-related things) I find outside my restaurant (markets, restaurants, events either in Chicago or away from home), and I answer some of the questions that are posted to my Twitter account.

Because I love being able to more fully open my world to folks through the Twitter portal and because I love being part of the community Twitter can create, I’ve decided to devote 15 or 20 minutes to it each day. That amount of time is typically what I can find while I’m waiting on a meeting to start or waiting for an elevator or drinking a cup of coffee.

Bayless, who is no doubt incredibly busy running three popular restaurants, writing cook books, and creating a television series on regional Mexican food, seems to have endless energy for answering questions of all kinds for people on Twitter. His output is impressive.

Twitter everlasting

September 28, 2009 / Rafe / 4 Comments

Tyler Cowen on Twitter:

Think of it as Google focused on one time-slice and giving the weight of crowd opinion no more than linear force. If an opinion is more common it will receive more tweets but otherwise your search brings up the splat, ordered by chronology, and thus it is more idiosyncratic than the first Google search page and often in a good way.

What’s interesting to me about Twitter is that it is different things to different people. Some people get lots of value from Twitter search — I hardly use it. But I find Twitter to be invaluable as a place to sound out ideas and keep in touch with people in my network. And I have very good luck seeking advice on Twitter.

rc3.org

Strong opinions, weakly held