Jon’s Radio Comments

November 20, 2006

Why can’t Johnny download?

Filed under: Uncategorized — jonsradiocomments @ 5:33 pm

The original item is here.

Advertisements

23 Comments »

  1. 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

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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


  9. 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

  10. 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

  11. 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

  12. 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


  13. 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

  14. I use http://yousendit.com/

    Comment by Rick — November 21, 2006 @ 12:56 pm | Reply

  15. 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

  16. 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

  17. 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

  18. 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

  19. 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

  20. use filefront.com…the d/l speed is superb

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

  21. 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

  22. 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


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: