Why can’t Johnny download?

November 20, 2006

Why can’t Johnny download?

Filed under: Uncategorized — jonsradiocomments @ 5:33 pm

The original item is here.

Comments (23)

23 Comments »

Hmm, the following shouldn’t be too difficult to implement. Don’t change anything about the user experience at either end, both sender and receiver, but implement something at the SMTP or email client which strips the attachments and replaces them with a link to a URL and hangs the file on the web at that URL. The receiving email client or POP3/IMAP server (upon user’s request) can fetch the file. The Lazy Web could probably mash up a Thunderbird extension/add-on to use one of the free hosting providers.

Comment by Chaim — November 20, 2006 @ 6:16 pm | Reply
problem: “URL” is geek-greek to people who don’t know how to download a URL. need some textual explanation on the page to say something like: “the file i want to give you is located at this web address. by pressing “go” you will download it to your hard drive.”

or something.

Comment by mackinaw — November 20, 2006 @ 6:19 pm | Reply
Will you post the source for this?

Better yet, has anyone done a Mac Automator workflow for moving a file to a server and creating a URL for it?

Comment by SKD — November 20, 2006 @ 6:21 pm | Reply
John – why not sniff the user agent and only present the instructions that apply to the browser that is visiting the page?

By the way–you are right that this is a problem. Another one is that the MIME types of an URL are sometimes not what I prefer (media file that starts playing in my browser that I actually wanted to download). For this reason, I keep a temp.html file on my desktop that I change the href of when I want to get a download link instead of automatic playing.

So even someone who thoughtfully sends a link instead of an attachment actually ends up creating a little work for me. I can’t imagine how non-programmers deal with this. I write code all day.

Comment by Phil Thompson — November 20, 2006 @ 6:49 pm | Reply
I completely understand the need for a contextual page. But I don’t think you’ve solved the problem with this particular page. People are still being asked to enter an URL into a box and/or being given a direct link to the resource. I can see why you’re presenting people the option to enter an URL but it seems like a corner case for any of the major mailer/browser combinations. And the url in the mail is longer than the original url, thus more likely to be wrapped & therefore broken.

A better end-to-end experience: someone receives a short URL – not necessarily as tiny as tinyurl, perhaps based on filename, for instance: “http:///down?dabble1”. “dabble1” is a tinyurl-like abbreviation generated when you uploaded the file (or social-bookmarked it.) Note that the lack of an extension makes it clear that this is not a file itself. Upon visiting this URL they’re given step 2 *immediately*, which should contain:
* a link to directly view it in a new window (or the same if you’re concerned about people getting confused by windows. My mother-in-law is baffled by multiple windows.)
* an iconic representation of what this file probably is (spreadsheet, web page, picture, etc) – based on analysis of the extension and more
* instructions to right-click and Save As in various browsers, with *their current browser highlighted*
* a link that they can copy & paste to send this to someone else [which is just the URL in the browser of course]
* an input box to the side which allows them to enter any URL and generate a page like this for that URL

You’ll probably find that the more you think about what people need from URL assistance, the closer you’ll get to gmail’s attachment handling! But your limited information about off-site attachments might keep you from doing it exactly that way.

As Chaim implies above, I’m surprised that mail apps themselves are not making this more of a priority. But when he talks about building a Thunderbird extension I think he may have missed the point of such a page 😉

Comment by Steve — November 20, 2006 @ 6:59 pm | Reply
Seems like a lot of fuss and trouble when there’s http://www.dropload.com out there….

Comment by Jill — November 20, 2006 @ 7:11 pm | Reply
I have a script on my server that sets the correct MIME-type and starts the download immediately after you click the URL of this form: http://mydomain.com/dl/name, where is either a name of the file in a special directory on my server or a URL of the resource somewhere on the net. I wrote this to be able to download files on my Clie UX50 PDA. But now I use it for sending files to other people.

Comment by George Sudarkoff — November 20, 2006 @ 7:41 pm | Reply
FYI: this doesn’t seem to work with IE7…
“line 28, object doesn’t support this property or method”

Comment by Guy Kelsey — November 20, 2006 @ 8:29 pm | Reply
problem: “URL” is geek-greek to people who don’t know how to
download a URL

Point taken. Terminology is at least half the battle.

Will you post the source for this?

Already did. Just View Source on dowloadHelper.html 🙂

why not sniff the user agent and only present the instructions that
apply to the browser that is visiting the page?

Perhaps I should. A bad reason is laziness. A possibly-defensible
reason is that enumerating the methods side-by-side may have some
reference value.

By the way, you are right that this is a problem. Another one is that
the MIME types of an URL are sometimes not what I prefer (media
file that starts playing in my browser that I actually wanted to
download). For this reason, I keep a temp.html file on my desktop
that I change the href of when I want to get a download link instead
of automatic playing.

Whoa.

So even someone who thoughtfully sends a link instead of an attachment
actually ends up creating a little work for me. I can’t imagine how
non-programmers deal with this. I write code all day.

Mostly, they don’t.

You’ll probably find that the more you think about what people need
from URL assistance, the closer you’ll get to gmail’s attachment
handling!

That’s a /really/ good point.

But your limited information about off-site attachments might keep
you from doing it exactly that way.

Precisely.

As Chaim implies above, I’m surprised that mail apps themselves are
not making this more of a priority.

Agreed. In that context you could assist both the sender and the
receiver in different-but-appropriate ways.

Seems like a lot of fuss and trouble when there’s
http://www.dropload.com out there…

Ah, thanks for that pointer. I was hoping to discover some solutions
like that. Are there any that one need not register to use?

I have a script on my server that sets the correct MIME-type and
starts the download immediately after you click the URL of this form:
http://mydomain.com/dl/name, where is either a name of the file in a
special directory on my server or a URL of the resource somewhere on
the net. I wrote this to be able to download files on my Clie UX50
PDA. But now I use it for sending files to other people.

“Correct MIME-type” is of course, as noted above, in the eye of the
beholder. This sounds like an excellent solution for those of us who
control our own servers. Have you shared it, or would you?

FYI: this doesn’t seem to work with IE7…
“line 28, object doesn’t support this property or method”

Crap. Sorry. Fixed now.

Comment by Jon Udell — November 20, 2006 @ 9:28 pm | Reply
we use Yousendit.com a lot at librivox. works pretty well – you don;t have to register yourself, but you effectively register the person you are sending to… by giving yousendit.com their email address.

Comment by mackinaw — November 20, 2006 @ 9:58 pm | Reply
As a sysadmin in a small business, there are two main reasons I’ve observed people send files as attachments and not URLs:

1) Permanence. Email is often used as a delivery method for the final version of reports to clients. Sending the file with the email confirms that the client has got the document, and means you don’t have to worry about uploading the file to a server, where you have to worry about access control and making sure the file remains there – if the recipient loses the file, they can always re-save the attatchment, whereas the URL is more likely to have expired.

2) Lack of integration. In an internal network, linking directly to the network filesystem is quite hard. Dragging and dropping a file will probably attach it, not just a link, and copying and pasting the path has to be done at both ends. Apparently Sharepoint can integrate a bit, but ugh, sharepoint.

Comment by James — November 21, 2006 @ 2:05 am | Reply
http://www.ietf.org/rfc/rfc2183.txt
http://support.microsoft.com/kb/260519

Comment by Gavri Fernandez — November 21, 2006 @ 3:55 am | Reply
Ignoring file size limitations, isn’t it more efficient to send by email? That way the file only has to go over the net once.

Comment by Joe Landau — November 21, 2006 @ 5:43 am | Reply
http://www.ietf.org/rfc/rfc2183.txt
http://support.microsoft.com/kb/260519

You are a person of few words, er, URLs, Gavri. Anyway, thanks for the reference, I was always vague on how a server can make a browser raise a file download dialog directly (as George discusses in comment #7).

If you upload to a server that does this, and if the MIME type works out according to the expectations of the sender and receiver, it’s all good.

But many/most servers to which people upload aren’t configured that way. Nor would that make sense, really, because I might wish to directly view a .MOV file that you would instead wish to download.

A more precise problem statement might be: Person A uploads a file to vanilla HTTP service H, transmits the URL to B, and wishes person B to be able to either launch or download the file, at B’s discretion. Neither person A nor person B is a geek. Service H is not necessarily under the control of A or B.

Comment by Jon Udell — November 21, 2006 @ 7:05 am | Reply
I use http://yousendit.com/

Comment by Rick — November 21, 2006 @ 12:56 pm | Reply
WARNING: Pedantic nitpicking.

It’s “a URL”, not “an URL”, since “U” is pronounced “you” — it has a consonant sound at the beginning.

And if you pronounce it “earl” instead of “you-are-ell”, that’s like nails-on-a-chalboard. 🙂

Comment by Joe Grossberg — November 21, 2006 @ 3:49 pm | Reply
Joe Grossberg:

Unless you also say and “are ay em” for RAM and “gee you eye” for GUI, you should admit to yourself you’re going to lose this pronounciation battle. It’s a win for the web that URL is being reduced to a single syllable with a leading vowel sound. Join the revolution, already.

ObTopical:

Would it be too much to hope for that the Content-Disposition header on a 30X redirection response be respected by a web browser with regard to the redirection target URL, such that it would be possible to have a click-to-download redirection service like:

[video src="http://clicktosave.com/http://weblog.infoworld.com/udell/screenroom/dabble.flv" /]

???

Perhaps this already works — haven’t yet had a chance to test.

Comment by Gordon Mohr — November 21, 2006 @ 5:04 pm | Reply
I have been using lite.myfabrik.com for this exact thing. Soo much easier to send the URL than to attach to an email. And no registration required.

Comment by Cyrano — November 22, 2006 @ 5:41 am | Reply
I’ve used:

http://www.sendthisfile.com/info/sendthisfile.jsp

in the past. Free, requires reg, no filesize limit but time window and other limits apply.

Comment by Jamie — November 22, 2006 @ 5:10 pm | Reply
For Mac OS X users, another option is FileChute, which uses your *own* FTP or WebDAV site for the file. Details are at http://www.yellowmug.com/filechute/

If it’s 100 MB or less, I use email and my Tuffmail account, which allows 100 MB attachments. I used to be a don’t-send-files-via-email person, but now I’m a use-email-for-everything person!

Comment by Nancy McGough — November 22, 2006 @ 5:56 pm | Reply
use filefront.com…the d/l speed is superb

Comment by Joan — November 23, 2006 @ 4:22 am | Reply
John

Have you ever used the YouSendIt.com service for transferring files? It’s a free service with a 1GB limit (I think) and the download expires after 7 days. I think it is exactly the idea you are trying to convey with your sample application.

http://yousendit.com/

Comment by Eric — November 23, 2006 @ 11:19 am | Reply
I think, Jon, your quest for a simple and transparent URL delivery mechanism is quixotic.

For the people who don’t use this, it seems to me that the logic chain breaks down this way:

1). Mostly, they are non-technical. The Web does a pretty good job of hiding technical information from such people, so they’ve learned to use the Web. And, for the most part, non-technical people don’t aspire to becoming technical;

2). E-mail attachments work and are the simplest mechanism for sending bulk information. It’s the first thing a naive client is likely to hit upon;

3). So these non-technical clients are using the time-tested rule of “Do the Simplest Thing That Could Possibly Work”. There’s nothing really wrong with that;

4). They are also following standard exception processing rules. In other words, do what you think is right until you have a problem, then treat the problem as an exception. You don’t need to do a whole lot of pre-checking; handle it as a post-processing exception condition instead.

One of the things that make me think this? Most clients I deal with aren’t even aware of the size of their information package. They frequently don’t know how to get size information, and having gotten it, have no context into which to place this information (“Megabyte? Is that big?”).

Comment by Brian — November 23, 2006 @ 6:36 pm | Reply