What functions should an eMail client have?
Status: Alpha
Brought to you by:
phryzer
Menu
▾
▴
Hey there,
TFT is about to become the Open source E-Mail client. Now, you have the chance to decide, which functions it should have (some day). So please feel free, to discuss, which functions you need or want to see in a next release of TFT.
Have fun,
- Phryzer
Heyas,
I saw the listing for an interface designer. Thought I'd check out the project and see if it was further interesting.
One of the biggest problems I see with email clients right now is that they've kind of stagnated on the old netscape email view paradigm. That is to say that there's a list of boxes, a list of messages, and a preview pane(maybe). I'd like to see something implemented like smart lists, something that would allow you to have a context menu with predefined (and customizable) categories (search) parameters that would give you the ability to mouse over a list of boxes, and have the list of messages returned ala google % score based on those parameters in a list that just floats above the interface. This would enable you to replace the list of messages with a hidden interface and utilize that space with other items on your desktop, or if maximized letting you see the message in it's entirety.
Also, you should be able to root a message in an object metaphor to the application, let's say that I receive a message that states that the new design changes are due on 8/29/01 and the person sending the message is my boss Frank. I want to be able to take that email out of my normal 'box' metaphor and place it in a priority bin. This priority bin could then be set up to remind me that there are unresolved items in the bin every so often (customizable). Also, there could be intelligent sensors (searches) on items in those boxes, things that look for dates contained, or certain catch phrases (ie: sentances containing the words 'due by' or 'need help') That would be presentable in any manner through the interface as simple data headers.
Also, I know that if I'm trying to find an email, I'll often sort by date. This should be an entirely seperate view, one that would be limited further by a Visual Studio-esque search bar so that you could limit searches to a single person. I'd like to see an actual timeline, or other graphic representation of the time as it's progressed. This could also incorporate a nice graphing feature that would tell you how often you spent working with email. It would be nice to actually have a hard version of the time spent 'err-wasted' in email and be able to output that data to some other useable form (excel etc.) This would be immensly helpful in calculating consult charges for pay jobs. But then again, that's just a thought.
Lastly, everything in the interface should be tear-off-able(tm) There's nothing worse than some gargantuan app that takes up your whole desktop. I think that given the current state of 'most' communications applications, it almost seems that the whole point to using a computer is to conduct in email ;) I'd like to see that change.
Of course the app would be completely skinnable and the font selection would use any available system fonts. (Toolbar icons, size, scroll size and distance, column height width color [perhaps even build in an event system to be able to tie different events to the column headers],...many others)
Let me know if this is the kind of thing you are looking for.
mh
Hi Phryzer, MagnetHead
I have tried several e-mail clients and have rejected all of them. Currently I am interested in an e-mail for OS/2, called REXXMAIL, which I intend to try out.
In my opinion an e-mail client should be:
- a receiver
- a filter
- a sender
- a viewer
- a composer
Yes, that is all!
The "receiver" will get the e-mail from the e-mail server and store it in a folder "Mailbox".
The "filter" will scan the received e-mail in the "Mailbox" folder and distribute the e-mail to other folders in accordance with the filter rules.
The "composer" will allow the user to compose an e-mail. The composed e-mail will be stored in a folder "Outbox". Composed e-mails, not ready for sending will be stored in a folder "Drafts".
The "sender" will send all the e-mails which are stored in the "Outbox" folder and move them to the "Mailbox" folder.
The "viewer" will allow the user to read any received/sent/drafted e-mail from any folder that the user may look into.
Note: When I refer to folders then I am refering to normal folders/directories and not to a special file containing the e-mail. I prefer to be able to use Explorer (in Windows) to open a folder with e-mails and from there read the e-mails.
Ok, short from me, what do you think? Comment are welcomed ;)
Regards, John, Latvia
Hey Thomas (magnethead),
your thoughts are quite interesting. That was something I was looking for. TFT should become a so called next-generation E-Mail client which includes a completely new design of the GUI.
It was really interesting to read through your posting.
Btw, would you be able/willing to do some design work or implementation regarding your proposed interface?
John, you said something about e-mails in 'normal' system folders, what did you mean with that? E-mails stored as plain text files, or something like that?
We could discuss E-Mail storage systems here. That's what I wanted to do, though. I'll start a new thread for that purpose.
Cya,
_Phryzer_
Andreas
My capacity as a programmer would be limited to windows programming at this point, sadly. I don't have access to a linux box and previous attempts to run a dual boot system have been less than successful.
I am fairly proficient in java however, which would afford a program of this type a great deal of interoperability, especially if we dealt more with the filesystem instead of loading large 'databases' of email into memory. I have been thinking also of the way that Gimp works, in that thumbnails get generated to a subfolder of the image itself. We could easily use this sort of process to store application data, almost simulating a mapi type of situation where the files could be on any external/remote device and loaded in that manner.
I'm just getting home from work, I'll post more on this later.
mh