As the creator of Delicious, Joshua Shachter knows a thing or two about urls and how they should be archived. So I am glad he hates url shorteners as much as I do.
I have never liked them and the only time I have ever used them is on Twitter, where you kind of have to. But I also make sure I feed my Twitter stream back into this blog which then grabs the original url and archives it so I make sure I can always get back to the original information.
The other thing I hate is a frame at the top, and I fear the new url shorteners are bringing this back into the mainstream, especially since Digg is now doing it also with its diggbar .
Joshua sums up nicely all the major arguments against the use of shorteners and I agree with every one of his points and pose this question: how many of these url shortener services do you think will still be around in two years? How about five? My guess, not very many, taking with them a large part of the usefulness of the twitter archive in the process.
Latest Updates from this link
Well, that's one way to get a potential investor's attention. I'm either impressed or creeped out.
A few months ago, I traveled to New York City to participate in Rhizome's Seven On Seven which paired artists and technologists and challenged them to develop something new. The New York Times wrote about the event.
Seven on Seven: Trailer
Seven on Seven: Monica Narula & Joshua Schachter
The data was gathered using the Mechanical Turk . I didn't really have enough time to talk about data, so here is actual dataset .
I've posted presentation as well.
I haven't really written anything for this blog in a while.
There are a variety of reasons for this, but I'm generally pretty sensitive to my tools, and I haven't been thrilled with either what I am currently using or what I might use in the future. Do I want to use Wordpress on a virtual machine at some hosting provider? Do I want to write something custom on AppEngine? Or one of a dozen dozen other choices? It makes me want to lie down.
It occurs to me that the tools we have available each do a large variety of things, and that there's no good reason for these functions to be bound together into one application. For example, Maciej's recent article on why not to have a public of Wordpress (and more details ) shows that serving the website and editing it can be very separate pieces. The original ancient Blogger software also used to push a copy up to your site via FTP.
There are a number of separable pieces in the system:
Authoring - the actual role of editing a blog entry is usually just a big text field, but several tools use FCKEditor and other nice javascript-based editors. Google Documents could fill this role too. Current weblog APIs allow this part to be decoupled, for the most part, usually for desktop or mobile clients.
Storage - a simple database would suffice. Not much metadata is required, nor is complicated indexing. Amazon S3 and Google Docs both fit the bill here.
Templating - The system that turns the raw blog posts from the storage engine into the pretty HTML version. There's nothing that really fits this bill in the current systems
Hosting - there's no need for the system that runs the blog authoring and storage software to serve the raw HTML pages. Amazon S3 would also suffice here, IF it dealt with directory index pages in a useful manner. (Currently, a url ending in a slash cannot map to a document on S3, so far as I know.) RSS/Atom feeds would also be served from the same system.
Feeds - as standards change over time, it would be nice to be able add the appropriate functionality. Feedburner already does some of this.
Comments - there are several solutions for hosting comments outside the blog applications: Disqus, Intense Debate, JSKit, and so on. I think moderation outsourcing and aggregating comment behavior will be increasingly necessary due to spam issues. Nor do I think that publishers should own comments, but that's a matter for another article.
I wonder if there is a way to define loose interfaces between these systems so that they could both work together but also not set APIs in concrete solid enough to stop innovation. Because the various pieces of the systems currently are all tightly bound together, it is very hard for the parts to move forward separately. For example, I've wanted to be able to specifically reply to comments in place in a visually differentiated way as the publisher, rather than just as another commenter. But this feature hasn't emerged, and if I hacked it into one platform via plugins, I'd be stuck with it forever.
It would also be nice if these systems could work together without all being client-side embeddable widgets. This usually slows down page loads tremendously.
What else have I left out?