|
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:
- To load a resource into your browser
- 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://weblog.infoworld.com/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:
| Internet Explorer |
Firefox |
Safari |
|
Save Target As
|
Save Link As
|
Download Linked File
|
We'd always had this:
| Internet Explorer |
Firefox |
Safari |
|
Action
|
Action
|
Action
|
...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.
Comments
| 
NEWS 
