Why doesn’t the mail image resizer check the image size before offering to resize?


Commenter Igor lambastes the image resizer dialog that appears when you select Send To Mail Recipient. (And people think I'm the one with the social skills of a thermonuclear device.) This dialog pisses him off so much, he complained about it again.

The root of the diatribe appears to be that the image resizer dialog appears, even if it turns out the resizer won't do anything. For example, the resizer dialog appears even if the images are already small, or if the files have a .jpg extension but aren't actually JPG images, Why is it so idiotic that it fails to check these simple things before offering to do its work?

Because checking these simple things before showing the dialog is even more idiotic.

One of the grave errors when doing work with files is accessing the file before the user asks for it. This is a grave error because accessing the file can take an excruciatingly long time if the file is stored on a server halfway across the world over a slow network connection, or if the file has been archived to tape.

This particular code path is sensitive to the file access time because the user has just picked a menu item. Suppose the dialog box went ahead and opened the files to confirm that, yes, they really are images, and yes, the dimensions of the image are larger than what the dialog offers to resize them to. You select 1000 small images on a slow server, right-click them, and pick Send To... Mail Recipient.

Then you wait 30 minutes while the dialog box goes off and does something like this:

shouldOfferResize = false;
foreach (file in selection)
{
  if (file.IsJPGThatIsNotCorrupted() &&
      file.IsWorthResizing()) {
    shouldOfferResize = true;
    break; // can early-out the loop once we find something
  }
}

Opening each file, parsing it to verify that it is a valid JPG file that decodes without error, and extracting its dimensions takes, say, 2 seconds per file. (The file is slow to access, say, it's on a network server or on a slow medium like a CD-ROM or a tape drive. Or the file is large and it takes 2 seconds to read it off the disk and parse it to verify that there are no decoding errors.)

After about 15 seconds with no response, you give up and say "I hate computers." and go off and do something else, frustrated that you were unable to email your photos.

And then in the middle of working in your word processor, this dialog box suddenly appears: "Windows can resize the pictures you send in e-mail so that they transfer faster and are easier to view by the recipient."

Gee thanks, Windows, for finally getting around to asking me about that thing I wanted to do a half hour ago.

Idiot.

And then when you click No, Windows has to go and decode the files a second time in order to print them. (Unless Igor's recommendation is to cache the decoded bits from the first pass. Then you'd complain that selecting 1000 files and clicking "Send To... Mail Recipient" causes your computer to run out of memory. As Igor is fond of saying when insulting the Windows team: "Looks like this feature was designed without any adult supervision.")

Sidebar: A good fraction of these blog entries are just elaborations on very simple concepts. When I toss an entry onto the "I should blog this" pile, it usually gets a short remark of five to ten words which captures what I want to say. Then when it floats to the head of the queue, I expand those ten words into a 300-word entry. The short version of today's entry: "That would hit the disk."

Comments (70)
  1. Anonymous says:

    You could do the check on a worker thread that the user could cancel, and see the progress of.

    If the files are slow then they could be cached to disk locally, rather than read into memory. Presumably the user hasn’t selected an absolutely huge amount of files as they’re going to email them (and if they have a warning could be displayed before going further).

    Those things obviously add a lot more work, though. Maybe it’s not worth it. But it’s not impossible to solve the problem in a way that still works well, unless I’ve overlooked something.

  2. Anonymous says:

    Snarky comment: if you would just tweet the ten-word entries, we wouldn’t need to read the blog.

  3. Anonymous says:

    "early-out" the loop? Is that MS Speak?

  4. Anonymous says:

    Assuming that the user actually intends to email the selected files, they will have to be read into memory shortly anyway. Thus, the only reason to avoid hitting the disk is to give the user an opportunity to cancel the operation because they really meant to email the 30k thumbnail, not the 300MB TIFF on the server in Australia.

    Keep in mind, that probably 90% of the time the user has only selected a single file, the file is on a local disk, and the user does not want to cancel. All other cases are fringe cases which must still work and not frustrate the user, but not annoying the user 90% of the time is a big win.

    One possible solution then is to look to see what resolution the file is. If the operation completes quickly, show the resize dialog when the image is bigger than some threshold. If the operation takes longer than, say, 500ms, assume that the file(s) are going to take a while to email and show the dialog.

    An alternate possibility is just to add up the size on disk of all the files (which should already be available, or at least cached). If the total size is bigger than some threshold (or any particular file is above some size), show the dialog.

  5. Anonymous says:

    @Leo: Using a worker thread is a great idea.

    @Peter: to prevent users forgetting what they asked and clicking again, you could pop up a dialog with a progress bar which says “Deciding whether to show you a dialog…Please wait”

    [Alex, is that you? Sounds like you’re trying to drum up more content for The Daily WTF. “Please wait while Windows decides whether to show you a dialog”?!? -Raymond]
  6. Anonymous says:

    Is it possible to check ahead of time whether the file is on the server?  i.e.:

    if (file on local disk – better yet is latency low)

    {

      do checks agains file type and sizes

    }

    else

    {

      nevermind

    }

  7. Anonymous says:

    Why isn’t there a function that will, given a path, tell you yes or no, in X milliseconds or less, whether it will most likely take longer than Y milliseconds to get the file info open the file and read the first Z bytes of it? (for some suitably small X-Y-Z). It seems like that would be the answer to all the variations on this.

    Maybe that’s too specific a thing to want, and requiring too much behind-the-scenes complexity, to be worth having as a standard function. But do the building blocks for such a thing even exist?

  8. Anonymous says:

    @Random832

    I thought about something like that too, but that’s a pretty complicated problem. Say your network server is on a very fast connection that usually gives you response times < 100 ms, but that server happens to go down or the network happens to be flooded at the moment. How is this function supposed to know? Are we going to be maintaining connections to this server continually just to see what the latency is? That’s a lot of resource cost and server load for not a whole lot of benefit.

  9. Anonymous says:

    The other simon is right, Explorer probably already read the file into memory. Also sending 1000 JPGs in a single mail from a slow server is an edge case. The common case is (my estimate) 1-10 pictures from the local disk. It’s feasible to check 10 pictures!

    And yes, Windows should show a progress dialog. That improves usability because then Windows shows an immediate reaction to the users action.

    What a cheap answer, Raymond…

  10. Anonymous says:

    @Simon: "That improves usability because then Windows shows an immediate reaction to the users action."

    It’s funny how this edge case (lots of files on very slow media) is allowed to determine action for all cases.  Why does "This would hit the disk" trump "This would annoy the user".  

    A worker thread / and progress dialog with a cancel button would vastly improve the user experience and — get this — allow the user to decide what does and doesn’t take too long.

  11. Anonymous says:

    How about a "never show this again" checkbox?  I always want to send the image unmodified.

  12. Anonymous says:

    @Simon: The other Simon is right about the other other Simon being right.

  13. Anonymous says:

    seems like the simplest thing is to change the wording of the dialog to something like "resize the image(s) if necessary?"

    analyzing the images first, even if it was totally simple, has such a small benefit that it’s best to just make the message clearer that it doesn’t know anything about the images yet.

  14. Anonymous says:

    What bugs me more about image resizing is interpolating images that shouldn’t be interpolated when zoomed at four times their size. Or more precisely, not offering an option not to interpolate them (quick view, windows photo gallery).

    A related pet peeve of mine is that most picture controls have no option "center if smaller than the control, resize if bigger".

    But I have to admit this has little to do with the Windows shell.

  15. Anonymous says:

    @Leo Davidson

    The post responded to both those possibilities, before you even wrote anything! *

    For the worker-thread thing, OK, the system doesn’t hang while it does its thing – but if storage access takes time, you get a popup later on, while you’re working on something else. Worse, many users respond to something not working by clicking on it a few more times. Five minutes later, after everything’s finished thrashing what with a bunch of threads fighting over the same data, they’ll get 20 dialog boxes asking them to resize the images. Cue the "why didn’t I stick with Windows for Workgroups?" complaints.

    As for caching, the system should gracefully handle the largest amount possible, and it’s very simple to do so with as little caching as possible. You’ve traded better performance in one edge case for problems in another, and the whole thing is more complicated. Given that each side has roughly equal benefits and drawbacks, and one is less complex, the smart design is to go with the less complex option.

    *Raymond should probably apply for James Randi’s famous million dollar prize for demonstrated psychic talent, now that I think about it. He seems to have this uncanny ability to respond to questions before they’re even asked.

  16. Anonymous says:

    I would argue that image resizing should be a feature of the email client rather than the shell.

  17. Anonymous says:

    In my understanding, explorer shows the dialog because you are about to send a certain (huge) amount of data over a slow connection. This operation might take too much time (or the sender/recipient is not able to handle too big data properly). So the only relevant information (wether to show a dialog or not) is the overall size of all selected files. This information can be gathered without accessing the files at all. How about an advanced user setting where everyone might adjust his personal preference for "Ask me to compress attached images if overall size exceeds … bytes".

    However, personally i don’t see a true reason for this kind of feature at all (-90 points), i am not annoyed about this dialog at all.

  18. Anonymous says:

    I really dislike this kind of answer from a software development team.

    User: This feature really annoys me.

    Developer: I can’t think of a better way.

    User: That doesn’t annoy me less.

  19. Anonymous says:

    Explorer does retrieve the dimensions of images and create thumbnails but only if it happens quickly. If its on a slow medium it does not.

    The reality though is that this would be best fixed with a checkbox that says don’t show this again because the target user is the person who wouldn’t otherwise know how to or think of resizing the image. They take the picture with their digital camera and now want to email it to someone.

    As for the jpg checking, if you truly are storing your zip files with an extension of jpg you are asking for trouble. What possible use case could their be for a zip file to have a .jpg extension?

  20. Anonymous says:

    Ignoring the check that a .JPG file is actually a JPG file (I have a hard time believing mismatches like this are common), then Explorer has *already* pulled the file size info to local memory. If you point out that file size and image dimension are not the same, then I’ll counter with the fact that Explorer automatically displays image dimensions when a folder contains nothing but images, and I presume that the windows folks have figured how to do this efficiently (or at least when it can be done quickly). Even if you absolutely have to open a file to determine the dimensions, you only need to read the image header, found within the first few bytes of the file; and while you’re at it, you can verify that the file really is a JPG! :-)

  21. Anonymous says:

    Matt:

    I don’t think that anyone wants to store .jpg files with .zip or other wrong extensions but sometimes they’re forced to or it happens by accident.

    For example, there are image-hosting websites that assume/require everything is .JPG. That can result in apparent oddities like "animated jpegs" and "transparent jpegs" :)

    Saying that, I can totally forgive programs that don’t behave in the ideal way when file extensions are wrong. Assuming the extension is correct is often a sensible optimisation.

    (In my own viewers I try to be pragmatic. If the media is considered slow I’m more likely to take the extension’s word for it. If the media is fast I might check the file headers as well or instead. Depends on the format/situation.)

  22. Anonymous says:

    @Leo

    I’d say there is a pretty big difference between a .gif/.png with .jpg extension and a .zip with .jpg extension.

    In the case of a gif wearing jpg clothes you can logically wait until you do the resize before checking what type of image you have because you’ll need to read the file anyway.

  23. Anonymous says:

    This is an interesting problem, and I don’t think there will ever be a cure all solution.  The file copy dialog introduced in vista is a good example of how improvements can be made for common tasks. I still believe there are clever solutions to help with this and similar workflows. 1) accumulate as much info as possible to help make decisions (I know the point of the article is this is the problem, so make a check box that opts-out of a preview behavior. 2) allow the user to describe as many of the behaviors at the same time (this includes time-outs, and how to deal with anomalies).  3) Highlight potential problems with a template Sanity Check. 4) allow user to customize sanity check 5) report on errors and have ways of correcting these problems without starting over.

    There are definitely pitfalls to any of these solutions.  But if another software has the feature and it works 95% of the time, you might be chasing the wrong design.

  24. Anonymous says:

    What about if  file.IsWorthResizing() just checked the file’s length in bytes? Is that information already loaded by explorer?

    I agree checking the whole file to see if it’s a valid JPG is OTT. Just offer the option of any of the images are ‘big’ (say 1MB or over).

  25. Anonymous says:

    A more complete list of slow-disk cases:

    * Local but slow media: CD/DVD, HD that is spun down.

    * Remote Server with high latency. Note that it may be mapped as a network drive, so StartWith(@"\") is not enough.

    * Server with slow authentication. For example, domain-joined laptop accessing a home computer, thus trying the inaccessible DC first, and failing only after timeout.

    * Backup to tape, as mentioned above.

    * Stuff added to Shell namespace by 3rd-party extensions. For example, Nokia PC Suite adds your phone to the shell namespace, and it can get quite slow through Bluetooth (USB is faster though). Given that most modern phones have cameras, Send To Mail from there seems like a fairly mainstream case.

  26. Anonymous says:

    The filesize of the image has very little to do with the dimensions of the image. We’ve all seen the 1600×1200 JPEG in 15k that looks fine because it’s an easily-compressed image, and we’ve all seen the 800×600 150k JPEG that looks awful because of compression artifacts.

  27. Anonymous says:

    Note to self: Don’t go head-to-head with Raymond.

  28. Anonymous says:

    On the other hand, explorer already DOES pull out the contents of the file when you select it. That preview box in the panel on the left, forgot how it’s named. There’s more: when thumbnails are on, it pulls out the whole 1000+ pictures. So it’s not like it would be something unexpected and new if the explorer decided to pull these things out on another occasion.

    And, then again, as already mentioned by many, if one solution works for one case and another works for another, then just use different solutions for different cases. Answering this way is like saying “I shouldn’t wear anything at all because wearing only pants or wearing only jacket would certainly seem funny”. No problem, just wear a full set of clothes.

    “Every feature starts with minus 100 points” rule might kick in here, but that’s another story. Nobody sane would argue with that improving something requires work.

    [Explorer gets the other data in the background, so it doesn’t interfere with the primary workflow. But in the picture case, getting the data *is* the primary workflow. While it’s true that you can use different solutions for different cases, it also introduces complexity and makes the feature harder for users to understand. “Why do I sometimes get asked if I want to resize large images, but sometimes not?” And of course as you noted the minus 100 points rule is always in play. -Raymond]
  29. Anonymous says:

    Raymond,

    You should really stop dwelling on marginal cases like offline files (and keep in mind that tape support is being phased out, too). GetFileAttributes() tells you that the file is offline, so you can skip pulling those (and I suspect this is what Explorer does).

    The software should not make the user unhappy in 99.9% cases at a cost of making him marginally happy in 0.1% cases (offline file will still keep him unhappy anyway).

    Listen to the users. Otherwise you will sound like developpers of one (habitualy bashed around) mail client, which they claim is not an email client at all, but a database client, and that for them excuses extremely lousy and inconsistent UI.

    [GetFileAttributes hits the disk too. And 0.1% of users is a lot of users, for example, everybody who works at this unnamed large multinational corporation. -Raymond]
  30. Anonymous says:

    It really seems like we’re losing sight of the original issue. One of the driving UI goals for Windows 7 (and now a marketing tagline) was "fewer clicks," which is at the heart of the complaint that prompted Raymond to write this entry.

    Rephrased for this specific scenario: requiring a user to click through a dialog that asks a non-question and results in the same action regardless of the user’s response is just plain dumb, and no littany of technical excuses changes that.

  31. Anonymous says:

    "You select 1000 small images on a slow server, right-click them, and pick Send To… Mail Recipient."

    And sometime shortly later your mail admin and/or your server admin come around and strangle you with DAT tape while explaining why this is really not a good idea.

    YMMV

  32. Anonymous says:

    @Peter,

    Your reply to mine is just like Raymond’s post. Yes, if you solve a problem in a really stupid way then you’ll create bigger problems.

    There’s more than one way to solve the problem though. Maybe the stupid way you’ve thought of isn’t the only way. It wasn’t what I had in mind, at least.

    "For the worker-thread thing, OK, the system doesn’t hang while it does its thing – but if storage access takes time, you get a popup later on, while you’re working on something else."

    I mentioned showing a progress dialog so that the user knew what was happening and could cancel it if they wanted to. That dialog would obviously appear when the worker thread starts (or after 1 second or so, if you want to avoid it appearing for worker threads that finish very quickly), not when it finishes.

    Right now you get a dialog as soon as you start the operation. With my suggestion it would be no different, except the dialog would have a worker thread and show progress as it worked out the details of the files. Details it has to work out before the email can be sent anyway.

    The user is shown no more dialogs than with the original implementation. They’re shown them just as quickly. The time when the data is processes, and how the user can interact with that processing, is just moved around so it’s more intelligent.

    "Worse, many users respond to something not working by clicking on it a few more times."

    They wouldn’t because the progress dialog would appear immediately (based on the simple "are there any .jpg etc. files selected" check that happens now).

    "Five minutes later, after everything’s finished thrashing what with a bunch of threads fighting over the same data, they’ll get 20 dialog boxes asking them to resize the images."

    "

    I never said that all the image files should be processed in parallel. I never said that each file should be treated individually instead of as a batch, either. Both would be stupid when the purpose is attachment to an email.

    "You’ve traded better performance in one edge case for problems in another"

    What problems?

    The only problems are if you implement my suggestion in a really dumb way. If you do things properly then you get something that works very well in both cases and doesn’t annoy the user with a dumb UI like it does now.

    "and the whole thing is more complicated"

    Obviously, but that’s programming. I said it was more work to do this and some may not consider it worth it. The reason for my reply was to point out that Raymond’s post seemed to be saying it was *impossible* to improve on the thing that was criticised without making it worse, which I feel is not true. It’s perfectly possible.

    "He seems to have this uncanny ability to respond to questions before they’re even asked."

    Funny, I tohught that about my own post when reading your reply.

  33. Anonymous says:

    In general, yes, you don’t want to read a file before it needs to be read.  But, as someone pointed out, if the file is going to get inlined into the e-mail message anyway, then it has to be read in.  Even if it has been archived to tape.  

    So I don’t see what the point here is.  A good argument for NOT asking the question goes along the lines of … "And now, to demonstrate our superior intelligence, we will proceed to ask you a question you can’t answer".  Well, that’s not exactly parallel, but it’s not a good idea to ask questions that you don’t NEED to ask.  

    "One of the grave errors when doing work with files is accessing the file before the user asks for it."  But the user HAS asked for it.  The user has asked for the file to be sent in an e-mail message.  So that is an error, but it doesn’t apply to this case.  

    The answer many people will come up with to the "should Windows resize the file" question is "I don’t know".

  34. Anonymous says:

    I think Raymond is reaching to far for an explanation here.  I doubt the originators of this dialog gave any thought to network servers or tape drives.  That gives them way too much credit.  Sounds more like a feature advertising itself:

    http://www.joelonsoftware.com/items/2003/06/20.html

    If this is the case, either resize the images or don’t (maybe with a checkbox buried in the prefs somewhere), but don’t interrupt what I’m doing to ask me about it.

    I’m perplexed by the idea that we are apparently talking about Explorer.  If true, commenter Brian has said all that needs to be said.

  35. Anonymous says:

    There are two conflicting requirements:

    (1) immediate feedback

    (2) avoiding clicks

    The current behavior can be described (using EBNF) as follows:

    ask_user show_progress {[shrink_file] attach_file}

    The feedback is immediate, but the "ask_user" dialog is not optional in case there are any images in the selection data. In order to avoid asking the user, one needs to start attaching files as long as there is no shrinkable image encountered:

    show_progress {attach_file} [ask_user] {[shrink_file] attach_file}

    In case a shrinkable image has been seen (and the progress dialog has not been canceled), the "ask_user" dialog has to be displayed, then (if this dialog does not get canceled) the remaining files have to be attached, now possibly shrinking images.

    The second version is more complicated to implement.

    The "Mail Service" object is implemented by the sendmail.dll, this has not necessarily to be considered a part of explorer itself. It works even if the mail client does not support compressing images.

  36. Anonymous says:

    [GetFileAttributes hits the disk too. And 0.1% of users is a lot of users, for example, everybody who works at this unnamed large multinational corporation. -Raymond]

    Before GetFileAttributes hit the disk, FindFirstFile/FindNextFile loop in the file open dialog already went through all the directory entries. They’re now cached. Moreover, ShGetFileInfo retrieved file icons for them (not reading actual icons from OFFLINE exe files, too). You’re not saving anything. You’re reading the files, anyway, to attach them.

  37. Anonymous says:

    @Ben L

    “The file copy dialog introduced in vista is a good example of how improvements can be made for common tasks.”

    It’s a good example how a good intention can be screwed up. It seems fixed in Win7, though. Why does it have to tell me in the window title “Calculating time required”, instead of just saying “Copying files” without time estimate? Why does it sometimes come up with absolutely ridiculous times? And why it was slower than XP? Not that XP file copy is ideal; for some reason it seems to work slower (or miscalculates time estimation) when the progress dialog is in the background. Was it intentional? Did marketroids think that I want to watch the damn progress bar for a large copy, to make it as fast as possible?

    [I’m always baffled by the people who immediately assume that everything they don’t like is some sort of conspiracy. -Raymond]
  38. Anonymous says:

    This is easy.  There should be a "Send To…  Mail Recipient" and "Send To…  Mail Recipient (with image resize)"

    Now you don’t have to guess at what the user wants or whether they expect to wait on a slow network connection to get the resizing done.

    Simple.  Problem solved.

  39. Anonymous says:

    "Simple.  Problem solved."

    Great. Next on "the old new thing" – why do I have to have so many cluttered menus? Why does every command come with a different menu for a bunch of different options that I don’t care about? Can’t you just have a dialog? Simple. Problem solved.

    In the real world, if you care that damned much about having a perfect user experience, go use Linux, and then you have the power to implement all the "simple" solutions you want. If you want to use Windows, you need to appreciate that when you have a hundred million users, it is actually not possible to have a perfect design that is customised for every last one of them.

    Even if you stick in a configuration dialog with twenty thousand pages and five hundred options per page, someone will complain because they can’t find the option they care about and someone else will complain about having a terabyte of hard drive space devoted to code for all the options they don’t personally use.

    And then some bastard in a country we’ve never even heard of will complain about a gramatically incorrect translation in some obscure combination of options.

    The "solution" is for some complainers to grow up. Simple. Problem solved.

  40. Anonymous says:

    [I’m always baffled by the people who immediately assume that everything they don’t like is some sort of conspiracy. -Raymond]

    The slowdown is not a result of conspiracy, but, as usual, a bad result of good intentions. "Let’s make sure the background copy process doesn’t impede I/O of the foreground process". I’m quite sure that was the case.

  41. Anonymous says:

    [I would argue that image resizing should be a feature of the email client rather than the shell.]

    I completely agree; the e-mail client have to access the files in order to send them, so while reading them it can check if they can be optimized.

  42. Anonymous says:

    Doesn’t explorer get the file when I right-click on it?

    In my computer, it seems every time I right-click a file in a remote server, it takes a really long time until it shows the menu.

    Or maybe this is some shell extension I have installed?

    Do you know of any tools I can use to determine if a shell extension is responsible for slowing down my right-click menu, so I can get rid of them?

  43. Anonymous says:

    @Andres

    A shell extension installed by a well known ZIP program seems to parse files (such as self-extracting archives) to see if it can show a custom menu for them.

  44. Anonymous says:

    Why not bring up the dialog window, then start looking at the images in the background, and take down the dialog window if they’re all small enough they don’t need resizing?  In the normal case where it’s 1/10th of a second to check (because the start of the file is already in memory) you won’t even see it.

    [Short answer: “Because that would require work.” -Raymond]
  45. Anonymous says:

    As a complex webapp developer, I gotta say that I’m baffled by some of the things being said here, including the post itself.

    First off, Peter’s response:

    "Worse, many users respond to something not working by clicking on it a few more times. Five minutes later, after everything’s finished thrashing what with a bunch of threads fighting over the same data, they’ll get 20 dialog boxes asking them to resize the images. Cue the "why didn’t I stick with Windows for Workgroups?" complaints."

    I’m trying to think of the last time I had to program something that was straightforward for a client that didn’t involve dozens of edge cases and things that I as a developer had to worry about that would never occur to the client unless they saw it malfunction and then would cry out that it’s "obviously broken". These range from minor nuisance to plain old unusable (e.g. dynamically drive "required" select box which can have one or zero items).

    The point being: queueing to a worker thread, and dealing with that queue is multi-tasking 101. Anytime I animate an interface action (be it in Cocoa or Ajax), I have to do a bunch of bookkeeping that makes it so that fading in and then fading out before the animation elapses does the right thing (stopping and flushing the queue, resuming from where the previous animation left off).

    All this to say, in raymond’s ten words: it’s not rocket science to make a worker thread work properly.

    And for Raymond’s post: hitting the disk. I’ve seen many examples, even in Windows, that handle this case very well. Select 50 files in Explorer, right click and hit "print", and explorer will respond with "Are you sure you want to do that? It might take a while".

    So, why not just warn that attaching a the contents of a CD to an email is not a good idea instead of saying "might hit the disk" and dismissing it.

    I gotta say that I fully agree with Igor on this one. Sometimes, the solution isn’t obvious and sometimes it’s internally ‘ugly’, but externally, it’s the Right Thing ™ to do. This is the thing I learn and re-learn the more I gain experience working for my clients: they are often right. Even if I think it’s a "stupid" thing to do, or if I think it’s "ugly", they are often right. Being annoying by a message box is a problem requiring solving.

    My 2 c.

  46. Anonymous says:

    Sounds like a case where the user experience is being penalized to accommodate an edge case.

    Seriously, a server ‘half way across the world’? A file on tape?  Yes! I know these are exaggeration to illustrate a point.  But everything is slow in that case. I mean, did you try this?  It does take a long time to attach file to a mail, and I think they may be copied over locally already.

    I’m filing this one as optimizing-for-edge-case.

    [It’s not “optimized for” the edge case so much as accommodating it. You have to be careful you don’t over-engineer your solution. Besides, “Send to email recipient” was clearly a quick feature (it has the feel of a powertoy), and probably no more than 1 day of development time was budgeted for it. If you make it too complicated, it’ll go over budget and get cut. If a simple solution addresses both cases, then that’s a good trade-off. -Raymond]
  47. Anonymous says:

    @mpbk [There should be a "Send To…  Mail Recipient" and "Send To…  Mail Recipient (with image resize)"]:

    How would commenter Igor comment on your second option if the current selection is a file containing a *small* image?

  48. Anonymous says:

    Memet: "I’ve seen many examples, even in Windows, that handle this case very well. Select 50 files in Explorer, right click and hit "print", and explorer will respond with "Are you sure you want to do that? It might take a while".

    Memet, what you’re saying "works very well" is precisely the same situation that Raymond’s described here which you are arguing against! Explorer doesn’t check to see how long it would actually take to print all those items!

    (@Raymond: no, I’m not Alex, but I love that site)

  49. Anonymous says:

    why does the image need to be resized? it’s funny how people create unexistent problems…

  50. Anonymous says:

    What it can do is show a log file or dialog box showing errors that occured during resizing. Image 010.jpg was smaller than the specified size, Image 011 was not a valid image and so on. I’m sure the sender won’t be mad for an additional dialog or balloon popup being shown to him but be grateful that the shell notified him of errors that occurred for particular files.

  51. Anonymous says:

    "I’ve seen many examples, even in Windows, that handle this case very well. Select 50 files in Explorer, right click and hit "print", and explorer will respond with "Are you sure you want to do that? It might take a while".

    Btw if you are current with Windows, you’d realize that only happened till the great Windows XP. Vista and Windows 7 deny any context menu action outright for 15+ files instead of giving choice to the user. Another shell annoyance. Please bring the old behavior back and LET THE USER DECIDE whether he wants to do the operation on dozens of files using the GUI.

  52. Anonymous says:

    Update: It looks like the feature already shows errors that occurred but not all other issues like the file size was already smaller so it didn’t resize.

  53. Anonymous says:

    One more thing it can do is remember the last setting the user used. If he used "Original/Unmodified" make that the default the next time the user wants to resize so he can just click OK, Continue or Attach right away. Also, why is the resizing eXPerience when doing "Send to Mail Receipient" not the same as the Resize powertoy shell extensions (which contains additional options like setting a custom size, Make pictures smaller but not larger, Resize the originals)??

  54. Anonymous says:

    Raymonds’ expounding on how an idea formed within his own mind eventually travels into his blog as an entry reminds me a bit of how a photon formed within the Sun eventually finds its way to Earth.

    Truly spectacular.

  55. Anonymous says:

    [“Hitting the disk” is the #1 cause of Explorer hangs. Strange but true. -Raymond]

    1. Not just hitting the disk. Badly written shell extensions hitting the disk.

    2. Another source is Explorer doing mysterious housekeeping, thrashing the disk around, at the user’s login. Or that’s an antivirus?

    The whole topic of trying to fing an excuse for a lousy featurerather than saying plainly it’s lousy, stinks big time. The picture resizing does really belong to the email client, not to Explorer. The email client fetches the files (“hits the disk” in Raymond’s parlance) anyway. What’s the point then?

    And, of course, there is FILE_FLAG_OPEN_NO_RECALL to prevent fetching those dreaded offline files (which are not supported anymore, anyway, in 2008R2).

    [I don’t believe I claimed that the current interface is good; just that the proposed alternative (checking all the files before displaying the dialog) is worse. -Raymond]
  56. Anonymous says:

    "As Igor is fond of saying when insulting the Windows team: "Looks like this feature was designed without any adult supervision."

    Hey, that’s the saying I "borrowed" from Dr. Joe M. Newcomer. He’s much grumpier than I.

    And this saying is true. Many times it seems the code was checked in without a senior programmer review. Then the junior programmer writes to the MS internal forum or asks Raymond directly "what’s wrong with it?". And annnoys the hell out of Raymond, making him write another blog entry about that.

  57. Anonymous says:

    @Lawrence: I think you didn’t get the point I was making. Explorer doesn’t warn users unconditionally that it might take long. It warns them if a certain constant number is exceeded. (unless I’m really wrong and it’s actually divining that it might be slow).

    The point was that:

    a) given that emails are not a good medium to send 50 files over to begin with

    b) that a worker thread *can* be made to do this kind of work

    I can say that with the protection against a), I can make a reasonably well performing b) and in the process deal with 98% of usage patterns.

    In this entire discussion, just keep in mind that webmail is more and more the defacto interface by which people do emailing. And accidentally including a CD worth of files on a webapp is just not a possibility. Yet, people seem to be using things like gmail more and more. So, it would seem that anecdotally, people’s tape drives starting up unbeknownst to them isn’t as pervasive an issue as we might be imagining here on this blog.

    The only real issue we have to watch out for is the user committing a self inflicted DOS attack by selecting 200 files and instantly warning them that this might not be a good idea. The rest is, imo, completely banal interface design mechanics.

  58. Anonymous says:

    PS. I’m generally keen on hearing people with years of experience in software design and the little things they’ve figured out over the years. But seriously, “would hit the disk” is not acceptable for me. It really isn’t.

    And I really don’t need to bring out the heavy artillery here. Just look at why OSX is winning over Windows – again, imo – it is stuff like spotlight and quicksilver. Instant response UIs are the things that blew XP out of the water. Yet, spotlight isn’t doing anything crazy. It is something *basic* that, for some reason, Microsoft refused to do for ages.

    It’s a whole can of worms topic, but the gist is: I, as a user, don’t care if my results aren’t initially complete or correct, I want *instant* results as a user. Just like I don’t really mind if by the time I’ve gone to the 20th page on a google search, the contents of the 15th page have changed slightly.

    This antiquated kind of “would hit the disk” thinking is really reminiscent of Motown way of building cars.

    Disk tapes? Yes, let’s demand ever more powerful computers to power our ever more resource hungry operating systems while totally unexplainably supporting legacy hardware from the past century and expecting that regular users will scan through terabytes of backed up data that is likely stored in bangladesh.

    I’m kind of bewildered that my tone is likely going to come off as aggressive here.

    [“Hitting the disk” is the #1 cause of Explorer hangs. Strange but true. -Raymond]
  59. Anonymous says:

    >>The root of the diatribe appears to be that the image resizer dialog appears, even if it turns out the resizer won’t do anything.<<

    No — the root problem is that there is *no option to disable it* if I don’t want it to offer me the resizing option at all.

    >>Because checking these simple things before showing the dialog is even more idiotic. <<

    You could modify a dialog to include a progress bar, an estimate, and a "Skip checking" button.

    >>One of the grave errors when doing work with files is accessing the file before the user asks for it.<<

    Shows what I know huh? And I thought that right-clicking on a file and selecting "Send To|Mail Recipient" counts as *asking for a file operation*, because, you know, you clicked on a *FILE* in the first place and _asked_ Windows Explorer to *do* something with it.

    >>…accessing the file can take an excruciatingly long time if the file is stored on a server halfway across the world over a slow network connection, or if the file has been archived to tape.<<

    You know, there is this paradigm in programming called *timeout*, not to mention that in a "modern operating system" there should be a way to determine whether some file is stored locally or not, and act accordingly.

    Btw, your pseudo-code is wrong — dimensions should be checked first because they are in the image file header.

    If the image is small (or the header is corrupted), you don’t need to verify further nor to offer a resize — instead just pass it through to the email client.

    Moreover, what was considered big before, now it is not because of ever-growing broadband speeds. If you are offering some functionality you need to make it *functional*, like check for the Internet link speed and then decide what may be too big for sending.

    Bottom line — if you cannot bother to do it right, then please don’t include such half-assed hacks, especially not without making them optional.

    Igor

  60. Anonymous says:

    Igor, why do you even use Send To | Mail Recipient?  That feature isn’t for you.

    I don’t mean generally, I mean that feature is not for YOU, specifically.

    I may not be clear enough: during the design meeting for this, brief as it was, someone said "Igor would want to skip this dialog" and there was actually a long discussion and investigation into it, and it was decided that you weren’t the target of the feature. Literally tens of millions are, but it was specifically decided that when Igor used this feature and got upset, that was OK.

    This is great news, don’t use it. Use your email client. Done!

  61. Anonymous says:

    >>Igor, why do you even use Send To | Mail Recipient?  That feature isn’t for you.<<

    I will ignore your rather unsuccessfull puns and tell you that I use it because it is more accessible. Here is some pseudo-code for you to prove the point:

    if (NotOpen(email_client)) {

       email_client = OpenEmalClient();

    }

    if (MinimizedToTray(email_client)) {

       RestoreFromTray(email_client);

    }

    CreateNewMessage();

    if (Impaired(user) || ShittyTouchPad(computer)) {

       AttachFilesButton(images, email_client);

       BrowseForFiles(); // slow

    } else {

       DragDrop(images, email_client); // requires precision

    }

    Contrast the above with:

    SelectFiles();

    RightClick();

    @Gabe:

    Your point is moot — the person who is sending the files should know the netiquette and not send large files to other people unless they ask for them or otherwise agree to receive them. It is not your computer’s responsibility to know the speeds of other people’s internet connections.

    All I am saying is that if it is so impossible to implement this in a better and less obrtusive way, then it shouldn’t be implemented at all.

    [What if you actually want to shrink the pictures? Most email clients don’t have a “shrink this attachment” feature. (BTW, feel free to write your own “Igor-friendly” version of this feature. Sorry you don’t like it. Other people do.) -Raymond]
  62. Anonymous says:

    To properly implement Igor’s feature of checking the Internet link speed before email a file, the computer would need to check the link speed not only of the user sending the file, but also of *all* the recipients.

    The fact that MS has failed to implement such a feature that takes so few words to describe means that they must have not done so on purpose.

  63. Anonymous says:

    Igor: "No — the root problem is that there is *no option to disable it* if I don’t want it to offer me the resizing option at all."

    Umm, the very first option for the search term "disable image resize dialog on Send To" in Bing will give you instructions (like most things, just a registry key). I’m sure this took me less than a tenth of the time it took you to write your psuedo code on why it’s so bad. "Don’t be helpless".

  64. Anonymous says:

    >>What if you actually want to shrink the pictures?<<

    I’ll do it by using the “Resize” option in any of the gazillion free image viewers available on the Internet and get a better picture quality and finer control over the file size.

    [News flash: Most people are not control freaks who say, “You know, for this message, I want to use JPG compression quality 62.” Hey, how about this: If you don’t want to shrink the pictures, then open a new email message, and then drag/drop your pictures into it.]

    >>(BTW, feel free to write your own “Igor-friendly” version of this feature.>>

    Now you sound like a true open-source evangelist — you offer me to fix the problem myself.

    [Oh, the “you can fix it yourself” excuse doesn’t work any more? Then why do people keep using it? -Raymond]

    Sure, right after I finish writing my own “Igor-friendly” version of Windows operating system. :)

    >>Sorry you don’t like it. Other people do.<<

    Do you have any statistics that go with this claim?

    @Lawrence:

    Why yes, changing MIME datatypes to blank values in the registry thus affecting the whole system is really *much* better than patching the DLL to disable the check which is what I did looong time (like 3 years?) ago.

  65. Anonymous says:

    @Me: My point was that Igor was claiming there was no way to circumvent this dialog. You and I have already identified two ways, although admittedly neither are perfect, but the fact is that Send To is not the only way to send email with an image attachment [not even the most common!], there are dozens of others) so I just don’t see the big deal.

    And you don’t have to write your own solution. As you say you’re already using "one of the gazillion free image viewers available", most of them have replacement "Send" functionality in their menus anyway. Just use that!

  66. Anonymous says:

    >>News flash: Most people are not control freaks who say, “You know, for this message, I want to use JPG compression quality 62.”<<

    News-flash: We were talking about *RESIZING* as in *RESAMPLING*, not changing compression ratio.

    Compression ratio applies only to JPEG images, other image types (GIF, BMP, PNG) can be resized only by _resampling_ or by recoding to JPEG.

    Btw, even MSPaint has resize option (it is in Image menu, and it is called Stretch), you don’t even need 3rd party programs.

    >>Hey, how about this: If you don’t want to shrink the pictures, then open a new email message, and then drag/drop your pictures into it.<<

    As I said, drag/drop is an accessibility nightmare when you are working with touchpad, not to mention if you have only keyboard at your disposal.

    Furthermore, current functionality is discriminating — those who want it get the most convenient way to insert attachments, and those who don’t need resizing have to do everything manually as you suggested.

    I am horrified by sheer idiocy of the algorithm used which can be described as follows:

    if (FileIsImage()) { // regardless of content

       TryToReduceSize(); // even if it is small

    } else {

       IDontCare(); // if it is 10GB ZIP

    }

    What about other file types? Why not repacking ZIP into RAR or 7Z? They offer better compression than ZIP. And StuffIt can pack JPEG files by additional 30% losslessly.

    >>My point was that Igor was claiming there was no way to circumvent this dialog<<

    There is no legitimate way (as in GUI option or group policy), nor a safe way (changing MIME types and patching OS files doesn’t count as safe) so in effect there is no way to circumvent resizing other than not using the Send To which is otherwise really convenient feature especially when accessibility is concerned.

    >>most of them have replacement “Send” functionality in their menus anyway. Just use that!<<

    That means one more program to start in addition to Windows Explorer or Total Commander.

    That also means special-casing:

    if (SendingImages()) {

       StartImageViewer();

       NavigateToFiles();

       SelectThemAndSendUsingViewer();

    } else {

       UseSendTo();

    }

    I am telling you — you simply cannot find a good excuse for a poor design. Resistance is futile.

    [You’re the one who said “get a better picture quality and finer control over the file size.” To me this says “control freak.” (I do keyboard-only drag/drop a lot. Ctrl+C, then switch to the email message and Ctrl+V.) It occurred to me that I got suckered into this discussion. The issue I was addressing was “Why does it ask if you want to resize the images before checking their sizes (items #3 and #4)?” In the comments to this posting, on the other hand, you appear to be questioning the value of the feature at all. That’s not the issue that I’m addressing in this article. Maybe I’ll get around to that topic in a few years. -Raymond]
  67. Anonymous says:

    >>You’re the one who said “get a better picture quality and finer control over the file size.”<<

    I was just pointing out that the feature is redundant.

    >>…you appear to be questioning the value of the feature at all.<<

    I do because random people are saying that the feature has value even in such a broken shape — I have the right to disagree with them, no?

    [The issue was not whether this is a worthwhile feature. The issue is why the feature behaves the way it does (i.e., whether the feature is worthwhile is, for the purpose of the discussion, a foregone conclusion). Whether the feature has value is not the topic for the article.]

    The only value I see is the ability to quickly attach files unless they are images. If there was an option not to discriminate images, or if the resize feature has been done right, then it would be an all-around usefull feature even for me. This way it sucks.

    >>Ctrl+C, then switch to the email message and Ctrl+V.<<

    That also requires opening email client and creating a new message beforehand.

    [So? You said it couldn’t be done – I showed you that it can. It may be more cumbersome (keyboard interfaces usually are for operations involving direct manipulation), but it’s still doable.]

    As for the source code, I was under impression that DragQueryFile() is for drag/drop operations, not for shell context menu extensions like sendmail.dll for which the source code was asked.

    [DragQueryFile is is for accessing HDROPs. You can get HDROPs from many places, not just from the WM_DROPFILES message. Sounds like you need to become more familiar with Win32 programming. I’m not going to bother looking it up, but I get the impression this is not the first time one of your complaints is based on a false assumption. -Raymond]
  68. Anonymous says:

    >>Oh, the “you can fix it yourself” excuse doesn’t work any more?<<

    No, it doesn’t work if we are paying for the product — it is your¹ job to fix it, not ours.

    Btw, feel free to give me the source code for sendmail.dll so I don’t have to rewrite it from scratch and I will fix it for you free of charge.

    ¹- not literally.

    [If you don’t want to do any manipulation of the contents, then it’s trivial. DragQueryFile to get the number of files, create a MapiMessage with nFileCount=the number of files, then in a loop, call DragQueryFile to get the file name and put it in the MapFileDesc. Then call MapiSendMail. Here I wrote it for you:
    MapiMessage message = { 0 };
    message.nFileCount = DragQueryFileA(hdrop, 0xFFFFFFFF, NULL, 0);
    message.lpFiles = calloc(message.nFileCount, sizeof(MapiFileDesc));
    char *files = malloc(message.nFileCount * MAX_PATH);;
    for (i = 0; i < message.nFileCount, i++) {
      DragQueryFileA(hdrop, i, message.lpFiles[i].lpszPathName = files + i * MAX_PATH, MAX_PATH);
    }
    MapiSendMail(0, hwnd, &message, MAPI_DIALOG | MAPI_LOGON_UI, 0);
    free(message.lpFiles);
    free(path);
    

    Fill in some error checking, clean up the readability, and you’re set. -Raymond]

  69. Anonymous says:

    >>The issue is why the feature behaves the way it does<<

    So in essence, I was asking why the “feature” is SO BADLY BROKEN while proving it with disassembly and analysis, and you are telling us 3 years later that it is “by design”?

    Truth to be told, I wasn’t expecting you to sink this low.

    Instead of looking for a better solution or at least admitting that the current solution sucks, you are actively defending it as if it is the only right thing to do.

    As for the HDROP, last shell extension I wrote which was using it was written in January 2004 so you will excuse me if after 5.5+ years I do not remember the details, after all it is your area of expertise, not mine.

    I bet you don’t know x86 instructions as well as I do, but I still don’t go around rubbing your nose with that fact.

    Can you please discuss this without being condescending, without giving irrational examples (such as users sending 1,000 files by email), and without ad hominem attacks?

    [As I’ve explained probably three times by now, the issue under discussion in the article is not whether the feature is a good feature or not. The issue is how the feature should be implemented, ignoring whether it’s a good feature or not. You do realize that Windows has to work even when people do irrational things. I have the hang reports to support this point. (Or maybe you’re saying it’s okay to hang when people do irrational things? Man, that would make my job a lot easier.) But fine, here’s a non-irrational example: You visit a network share. While deciding which picture to send, somebody unplugs the server. You select ONE picture to send via email. Boom, hang. (By the way, you’re the one who started with the ad hominem attacks months ago; I ended up having to add a new Ground Rule just for you.) -Raymond (P.S. I miss the days when I could assume my readers knew what an HDROP was and where to get one.)]
  70. Anonymous says:

    "You visit a network share. While deciding which picture to send, somebody unplugs the server. You select ONE picture to send via email. Boom, hang."

    There are, like, thousand places in Explorer where it has to read a file attributes and header. It’s a routine operation for a file management GUI. The "hang" can happen in all those scenarios. Consider it a cost of doing business with network files. Trying to optimize it out of a single particular rare scenario is a case of preliminary optimization, which, as you know, is a root of all evils.

Comments are closed.