Re: Exchange
How many times do we read this?
And why? Because email clients are badly designed. Their defaults for handling read mail are unhelpful to non-existent. To some extent it's because email clients originally started out as message handling systems. Usually they now manage to link messages into threads but all to often that seems to be an afterthought and not a core function (see 3 below).
How about something fairly simple:
1. The inbox is a list of unread messages. The moment a message is read it is removed from the inbox and cannot be replaced.
2. The Trash is a queue of messages or threads waiting to be deleted according to some set of rules - time or quantity related doesn't matter so much. Once the criteria are met it's gone for good. While it's in there any message or thread can be retrieved.
3. The unit of interest is not the message, it's the thread/discussion/conversation/call it what you will. Messages are their components. A singleton message - one with, as yet, no reply - is simply a component of a thread with one item; all threads start this way. Placing sent messages in a separate "Sent" folder where they won't get matched up with their replies or the messages to which they themselves are replies is just stupid.
4. By default all sent and all read messages initially get placed in a common folder. We'll call it something such as "Current". The contents of Current are presented as threads, not individual messages (see 3 above).
5. We don't want Current to grow indefinitely (the clue's in the name) so we'll have some sort of ageing rules to move threads that haven't been added to or read for some time into less current folders. The ultimate such folders will be archives, probably on a yearly basis.
6. In addition to such core management the user can devise any additional organisation they please, hierarchical, cross-referenced or whatever. For extra points such folders can be represented in the OS filing system. That means that if you cave a folder for Project Rhubarb you can drag the email client's folder of email threads relating to Project Rhubarb into it as a sub-folder. Or when you opt to create such a folder in the client you can elect to place it there.
7. Some of 6 could be automated by rules - all emails from example.com addresses can be set up to go into Example Inc's folder. All emails from the banks' email addresses go into the relevant bank's folder in the Finance folder and so on. There's a mass of possibilities for helping and guiding the user to good practices.
8. Nothing described above need represent the actual storage of the threads and the messages which are their components. That can be done by using a plain old database. The client's folders are just pointers into the data. The "threads" in the OS folders are just files that contain sufficient information to tell the client where to find them on a read-only basis.
9. If the users really want to shove a file back into the Inbox to deal with later and can't, then maybe a Pending tray could be provided.
