Just Plain Stupid Design

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Just to warn you, this is a bit of a rant. The complaint below is aimed at the Evolution and OpenOffice.org combination that just screwed me, but is equally applicable to Outlook/Word since I’ve done the same thing there. This is an instance of just plain piss poor design, IMO.

Maybe you’ve done this too: you receive a document via email which you’re supposed to edit and make changes to. When you go to open it, the document launches seamlessly and in a second or two you’re happily editing away. Unbeknownst to you, the copy you’ve just opened is not a permanent file per se, but rather a temporary version typically located in a temp file directory located under the email client directory. Thinking you’re being very conscientious, you save then exit. The bad news? That document that you saved is as likely as not to be lost when you come back, because the temp directory you saved it to axed it.

I didn’t lose a dissertation or anything, but I did lose about an hour and a half’s work on a document with an upcoming due date. While the situation was clearly preventable, as I know how this works, I shouldn’t have to. There are two obvious approaches: don’t open documents for editing in a temp directory (or at least provide a warning), or have the office suite look for a temp directory on save and provide a warning then. Because while I know just where I went wrong, I have to believe there are thousands of people out there that don’t know how this works, and believe that their work has somehow just vanished into the ether.

I don’t care who solves this problem – PIM or office suite or both – but it really needs to be solved. The fact that this occurs on multiple products on multiple platforms, to me, is just sad.

Anyway, sorry for the rant. Just really frustrating.


  1. I had the same issue with Thunderbird. I don't remember Outlook having this problem because it does not clean up the file on exit. You can still find it by opening up the editor and opening it from the recent documents list on the file menu. I will never make that mistake again. The best solution I see is to pop a warning saying "changes will not be saved" for those who have not had the lesson seared into our memory. Otherwise, all the client applications would have to know what directories to warn the user before saving in.

  2. To be fair, Lotus Notes does something similar. If you double-click an attachment in a note, it opens it in a cryptic temp directory. One good thing though is that Notes doesn't seem to delete these documents for quite a while so it's relatively easy to find your doc.

    I've just gotten into the habit of always manually saving documents to specific directories if I intend to edit the doc. If you think through possible solutions for how email clients might deal with this problem and the only feasible albeit ugly solution is to prompt the user to save a local copy when the user tried to open the document which makes sense from the "edit" case but not from the "I just want to read said document" case.

  3. Seth: it's been a while since i made this mistake last, and i don't really have an excuse for not having learned my lesson, but all i can do is plead exhaustion.

    Bill: ah, Lotus too? stop the madness.

    i'm in agreement that popping a warning up even for things you just want to read is not ideal, but it's a problem that's just bitten too many people not to be fixed. maybe it's a configurable option that says "open all my documents in this directory" or maybe it's the option to right click and select edit which tells the PIM not to open it in a temp file but rather My Documents or some other preconfigured permanent directory.

  4. One solution that just popped into my head would be to create the document with a "read-only" attribute set. This setting is filesystem/OS specific rather than application specific, so you wouldn't have to worry about app compatibility. And in many cases the default behavior when you try to save a modified read-only document is to either propmpt you to "save a copy" or to warn you that you're confirm that you want to overwrite a read-only file, which would set off a red flag in the user's mind.

    Both the "Edit context menu item" and "working directory preference" ideas are both good from a technical perspective, but I wonder how many users would discover and make use of those features?

  5. Oh, the woes of having to live with filesystems. While I agree that this issue should be "fixed" (or at least considered) by PIM/office apps, I think this a great example of how current filesystems are starting to show their age and becoming a hindrance to usability. Wouldn't be nice to have a saved search/virtual folder/document query for all documents you have edited in the past day, all attachments, or better all attachments that were recently edited?

    I have not had a chance to play with Spotlight yet, but I have played around with Beagle. I for one can't wait until productivity apps and desktop environments start to work with and build on top of these systems. It may be quite a technical challenge to get this metadata/tagging functionality integrated from the bits of the filesystem all the way to the ui (WinFS, chuckle.. kudos to Apple), but do we really have to have such a broad indepth solution to get most of the benefits of such a system? Couldn't we just create a document metadata API for applications to use and then throw some quick and dirty database implementation behind that API (and we could make the implementation better in the future).

    I think that the most important here is not the fancy technical way of storing metadata, but rather the integration and ui work. What if every open/save dialog box had folder browsing and a searching mechanism. What if every application would add its own metadata when saving a document . Why not add a the hip folksonomy buzz word to this as well and be able to tag your documents just like del.ic.ious?

    I'm not saying that we should get rid of our hierarchical filesystems, but add some nice (and simple) metadata layers on top. It can't be that hard to have a bit of both right?

  6. I had to educate my partner about this feature recently (that was via Outlook+Excel).

    Here's the thing. After you use an IDE like IDEA, you wonder why you have to save documents at all. Ever.

  7. Why don't all these programs take the approach ye old Eudora did? Whenever it got an attachment, it downloaded it directly into the… wait for it… "Attachments" directory. If you open, edit, then save the attachment, you don't lose your changes, because its not in some funky temp directory. You can also easily find it to re-attach it to a new message and send it on its way.

    Why try and seperate the file system from the application? Outlook stores all this stuff in some funky proprietary format god knows where. It's clearly a file, why not store it that way?

    Just my .02… At least SOMEONE out there has got the right idea.

  8. timmfin: agreed with pretty much every suggestion in there. it's ideas like that that indicate to me that collaboration, relegated by some to commodity status, is ripe for further innovation.

    Bill: couldn't agree with that more. it's not just the IDE's, either: note taking solutions like OneNote on Windows or Tomboy on Linux also highlight the value of not having to manually click save all the time.

    Chris: i've never been a Eudora user, but seems like they have absolutely the right approach.

  9. Frankly speaking I'm one of those who didn't know how it works. Now I understand it a bit but I can't understand one thing: why do we need these temp directories at all?

  10. Damn! This just happened to me for the 2nd time this month, and probably the 100th time in my life.

Leave a Reply

Your email address will not be published. Required fields are marked *