Birdhouse is for twitter writing what MarsEdit is to blog writing.
I don’t know if I buy it, but it makes about as much sense as Amazon being suddenly homophobic.
This is quickly turning into a PR coup for Amazon. The gist of this is that most of the books labeled as “adult” and made hard to find on Amazon’s site are lesbian, gay, transgender or bisexual-themed, or even just LGBT-friendly. This is extremely bad form on the part of Amazon, as not showing up on best-seller lists or search pages can cripple the sales of a book. One of the books affected is “Unfriendly Fire” by Nathaniel Frank, which now doesn’t show up on bestseller lists on Amazon.com despite it’s selling of more copies than the entire Twilight series.
The #amazonfail tag on Twitter is spreading very quickly in response to this, and I encourage the use of it.
Adding features to applications is a constant trade-off between opposing forces. Sometimes adding to or changing software can be a hinderance both to the user and the developer in several ways.
Ego, Garrett Murray’s excellent iPhone application, was blocked by Google Analytics yesterday. Since support for GA is one of Ego’s advertised features, paying users are understandably upset. Garrett is a good developer, and I’ve been using his software for years (his application xPad was one of the first non-Apple bits of Mac software I ever purchased) but I think much of the user reaction to this issue was predictable and preventable.
Unlike many of the other stat-tracking widgets used in Ego, Google Analytics does not have an official API with which developers can retrieve data for use in applications. This means that to get the data at all, Ego has to use what I’d (not at all disdainfully) classify as a “hack”; Getting at useful information in an unsupported way. The problem with this is that the average user has no reason to suspect that Google Analytics portion of his $2 iPhone application may stop working without any prior warning. This is a case of the classic “stopped working for no reason” that developers hear all the time. There is a reason, and it’s a pretty simple one, but the user has no frame of reference for it. What’s more,the user has absolutely no reason to know the reason. It’s not their job. They just saw a feature list and clicked buy.
Here’s a screen shot of the features section of the Ego application page on the iTunes store:
You can see here that the Google Analytics feature is listed right next to services with officially supported APIs, such as Feedburner and Twitter.
What this says to the user is “these features are equal, and just as likely to work” which we now know isn’t the case. A lot of applications do things like this, and the intent isn’t malicious- the average user just genuinely doesn’t know and doesn’t need to know what an API is, or what has one and what doesn’t.
Since there is no “official” way to include Google Analytics data, the GA widget is a trade-off between feature set and usability. Unofficial means that it’s more likely to stop working “for no reason.” Unofficial means that Google can change whatever they like whenever they like, and you just have to eat it, like Garrett is doing now.
He’s is obviously a smart guy, and I’m sure he weighed the pros and cons of including support for Google Analytics in the first place, but I’m also pretty sure he’s second guessing that decision at least a little bit today. This isn’t to say that he made the wrong one- I don’t think he did- but that the way in which application features are presented to users create expectations for those features that may have unintended consequences for developers.
Apparently, the co-writer of “Never Gonna Give You Up” has made a total of about 16 dollars from YouTube views of the song’s video. The article doesn’t say how much he’s made from other revenue streams. I find it impossible to believe that the Rickroll meme didn’t make him plenty of money from things like increased radio play, sales on iTunes, and so forth.
Aristotle Pagaltzis suggests some changes to John (and my) implementation of the DiggBar block.
As a big fan of telling people when they’re Doing It Wrong, I’m happy to announce Diggbarred. Diggbarred is a new plugin from myself and Shawn Medero, using John Gruber’s original blocking code in an easy-to-activate form. You can fork, modify, or otherwise mutilate the code on Github.
John Gruber has a decent solution for blocking the DiggBar on his site, Daring Fireball, if you’d like to completely block all Digg traffic.
I’m going to whip up a WordPress Plugin for this today.
The AP threatens an AP affiliate for embedding videos from the AP’s own YouTube account. It’s like watching a drunk vomit on himself.
The Associated Press announcement addresses pricing, licensing, and legal threats. There is no statement made about the credibility of the information being published through these online channels, nor whether the act of aggregating and disseminating news this way has an impact on its accuracy or accountability.
I agree, entirely. What is at issue here is the attitude. My favorite writers right now (such as John Gruber, Merlin Mann, Andy Baio) are my favorites precisely because they care about one thing: creditability. They want their opinions and ideas to be credible not due to their stature as people, but due to the strength of their ideas and words themselves. This matters.
Ken Plume and Doc Hammer bullshitting for 80 minutes is far more entertaining than you might think.
This is a pretty big deal. Amazon selling download codes for XBLA games is a good step for retailers getting in on the downloadable action, which will get more exposure to download-only games, which will get everybody paid more. I hope.
Tim Schafer’s advice regarding wether you should care about game sales figures: If you don’t have money on the line, don’t sweat it.
URL shortening has been the subject of much discussion recently, and there is one big reason: Twitter. Twitter has exploded in usage in the last 6 months, and with that has come a sharp increase in both the number of and use of third-party URL redirection services. Bit.ly, TinyURL, Twitpic, and the rest, are just some of the major players in the space. All of them provide similar functions but suffer from the same problems, some of which are outlined below.
The purpose of this isn’t to indict these services, all of which grew out of the need for something very much like what they are. I think that by outlining the issues and benefits, we can gain a better understanding of why we need URL shortening / redirection, and what can be done to improve the practice.
Problems that URL Shorteners Solve
This is what they’re good for.
The Problem of Memorability.
The removal of many “slash”es and a “tilde” makes this URL much more accessible. When spoken aloud, the URL is easy to keep in mind. “go to this page.”
The Problem of Awkward or Ugly
The link is now more aesthetically pleasing, won’t be as confusing to the tech-unsavvy, and won’t give most URL formatting scripts headaches.
The Problem of Length
It’s now shorter, and affords the writer more space on Twitter or in an SMS to comment on the link. The Amazon link in the second example, with a total of 181 characters, wouldn’t even fit in an SMS, or Twitter message.
These are legitimate problems, and each pops up in different circumstances. Memorability is primarily an issue when using free webhosts that do not provide each user a unique domain name, with sensible URLs. Awkward/ugly is an issue with many online shopping services that collect tons of referral and other link data. Length becomes an issue when using a micro-blogging or SMS service, like Twitter. These problems often “stack”, and co-exist.
Problems That URL Shorteners Create
Reliance On A Third-Party
What happens if your URL shortener of choice goes out of business, or changes their URL format some day? It is not out of the realm of possabiltiy that TinyURL, Bit.ly or any of the major players in URL reduction could go the way of 1000s of other web companies. As of today, TinyURL.com claims to have created over 200 million shortened URLs. 200 million is a lot of dead links that could be avoided. Even if the service goes down for a short time, these are visitors and readers and customers that need not be lost.
One of their prime drawbacks of URL shorteners, this is used for comedic effects by some. The spread of the Rick Roll might not have gone so well if not for the semi-anonimity created by these services. In recent years some (TinyURL, for one) have provided a “preview” mode to guard against obscene or otherwise untoward usage. This is fine, but it isn’t a solution to the real problem. Without context, a URL that starts with http://tinyurl.com/ could literally go ANYWHERE on the internet. Even with a custom name (e.g. http://go.to/thispage) there simply isn’t enough context to know what kind of thing you’re clicking on.
Unnecessary Strain On Networks
This is one is a bit less of an issue right now, but it is gaining steam: The dozens of free, url redirection services are causing network congestion by adding an extra HTTP request to every URL that is processed by them. One by one these are not problems, but by the millions they can make a notable dent in networking throughput, strain on hardware, and eventually, increased costs of keeping networking hardware healthy. Compounding this problem is the recent trend of Twitter clients to “expand” shortened URLs and provide the user with the destination URL, which creates even more unnecessary networking overhead.
My Solution To Some of The Problems Presented Above
Obviously, I can’t just say “stop using URL shorteners”. Nobody would listen, and besides, sometimes URL shortening is necessary or just convenient. What I’m proposing is that you provide your own shortened URLs.
Use my WordPress plugin la petite url, or another short URL plugin. There’s a Django app, too. Providing a Twitter/SMS-friendly URL format for your visitors and users gives context to your links that would otherwise be lost. The URL
http://extrafuture.com/msfxe is not as context-rich as
http://extrafuture.com/2009/04/08/on-url-shortening/ but it is markedly better than
http://tinyurl.com/ck9df4 or even
http://tinyurl.com/onurlshortening. At least the user an idea about where the link they’re seeing might take them.
This is not a perfect solution, and I’m aware of that. If your web site’s URL is especially long, then serving shortened URLs from it will not be useful. In most other cases, serving your own shortened URLs is an option can solve the problems of third-party reliance, length, and obfuscation quite nicely.