Why can't Johnny download? Because he's stuck in a semantic muddle.

By far the biggest conversation starter here, since I switched on comments a few months ago, has been Why can't Johnny download? In that item, I presented a little download assistant that can be used standalone or in combination with a target URL. It aims to provide a single context for two different uses of an URL:

1. To load a resource into your browser
2. To save a resource to your local disk

Although I talked in the original item about transmission of data by value (e.g., emailing an attachment) versus by reference (e.g., emailing an URL), the ensuing conversation helped me clarify that, while the distinction between those two modes is indeed a perennial source of confusion, my helper isn't really intended for end-to-end transfer. It's just tries to make the essential load/save duality of a hyperlink, which I take for granted, more understandable to folks who don't.

For example, I'm sometimes asked to "send" someone one of the various audio or video files I've posted to the web. Similarly my wife, who is an artist, is often asked to "send" someone one of the image files that she's posted to the web. To me, the obvious and natural thing to do in these cases is email an URL. But, particularly in my wife's case, the recipients are often unsatisifed by this response. She has more than once had to download one of these files, and then email it as an attachment, in order to satisfy the expectations of the recipient.

I think there are two (related) reasons why this happens. First, the procedure to open or save an URL transmitted in the body of an email message is nothing like the procedure to open or save an attachment. Second, the load/save duality of hyperlinks is just not well understood, period. What I'm looking for is a way to contextualize and document the open-or-save-via-URL procedure.

Let's look at an URL in the context of a web page:

http://jonudell.net/udell/screenroom/dabble.mov

I take it for granted that I can a) click to load, or b) right-click to save. But this opportunity for dual use is not widely appreciated, partly because the semantics of right-click-to-save differ among browsers. With this contextualization of the target URL I'm trying to show that there are two things you can do with this URL, as well as explain how to do the second and less-obvious thing.

Of course it's hard (maybe impossible) to solve any problem in this domain without creating a new one. In this case, as several folks rightly pointed out, the contextualizing URL is an unwieldy thing that email clients are likely to mangle. Shortening it is an obvious solution which, in turn, creates yet another new problem.

A subtler problem is the very thing I've stated as a goal: to clarify the opportunity for dual use. Choice itself is sometimes the enemy. In a context where the intended use of an URL is to save the resource, not load it, should the latter choice simply be hidden? That's the purpose of a server-transmitted HTTP header like:

Content-Disposition: attachment; filename="dabble.mov"

When you request a download from, say, SourceForge, or YouSendIt, or many other services that are explicitly for downloading rather than loading/viewing resources, they use such a header to raise a Save As dialog box in your browser.

And yet...these services are rarely confident of their ability to hide the dual-use nature of the URL. Hence the familiar idiom:

If your download does not begin shortly, you can use this direct link.

Which link is, of course, the very thing whose dual-use nature was meant to be hidden.

There are valid arguments on all sides of this issue. The lively discussion attached to the earlier entry shows that it's far from settled, and not likely to be settled anytime soon.

It's interesting to speculate on the role of language here. Suppose that instead of this:

We'd always had this:

...where Action was any one of Save Target As or Save Link As or Download Linked File, but always the same one everywhere. We'll never know, and it's very unlikely that we'll ever be able to synchronize the terminology now, but this semantic muddle is clearly an ongoing problem.

Former URL: http://weblog.infoworld.com/udell/2006/11/29.html#a1568