In regards to the attachment-icon idea, I would prefer we move in the opposite direction. I think that clicking anywhere on the message list should only highlight the message, rather than performing any action. This is the way that thundebird, outlook and pretty much any other windows mail application works. I propose we remove the function of the compose window coming up when one clicks on the from address in the message list. The can already compose an e-mail to that person by highlighting the message and clicking the reply button. Right now we are stuck half way between gmail and thunderbird, with regards to the message list behavior, and I would prefer we move towards thunderbird rather than gmail.

-Charles

On Tue, 17 Jan 2006 13:51:58 +0100, Sjon roundcube.net@spider007.net wrote:

After loosing an important mail composed under Roundcube (just pushed the send-button, 'something' went wrong and the email was lost forever) I have thought of ideas to avoid this. I think the following might be feasible: currently mails are send in the background; a failure means the message disappears. Might it be an idea not to use an AJAX backgrounded thread for sending the email, but staying on the foreground; only to return to the inbox once the message has succesfully been send?

Some other stuff I thought of:

• move the current overflow-scrollbar style from the table to the tbody.

This would leave the thead always visible, while currently it will disappear when scrolling

• make the attachment-icon (singleclick) in the messagelisting jump

directly to the message-attachment. Currently it is just an icon without any link

• a javascript prompt before any actual delete action, for example in the

addressbook page

• could we merge the _auth (GET) and sessid (COOKIE) into 1 sessionID?

Comments welcome :)

Regards, Sjon

On 1/17/06, Charles McNulty charles@charlesmcnulty.com wrote:

In regards to the attachment-icon idea, I would prefer we move in the opposite direction. I think that clicking anywhere on the message list should only highlight the message, rather than performing any action. This is the way that thundebird, outlook and pretty much any other windows mail application works. I propose we remove the function of the compose window coming up when one clicks on the from address in the message list. The can already compose an e-mail to that person by highlighting the message and clicking the reply button. Right now we are stuck half way between gmail and thunderbird, with regards to the message list behavior, and I would prefer we move towards thunderbird rather than gmail.

-Charles

I actual prefer the feel of gmail for a webmail app than Thunderbird, or any of the desktop email programs. I use Thunderbird as my primary email system, and love it. But I don't want the Thunderbird/desktop experience on the web - I want a small, fast, email app. I don't like the double-clicking on a message to open it - on the web you use hyperlinks, and single clicking is the defacto standard. I would prefer a streamlined interface in this sense. Just my $.02.

On Tue, 17 Jan 2006 13:51:58 +0100, Sjon roundcube.net@spider007.net

wrote:

...

After loosing an important mail composed under Roundcube (just pushed

the

...

send-button, 'something' went wrong and the email was lost forever) I

have

...

thought of ideas to avoid this. I think the following might be feasible: currently mails are send in the background; a failure means the message disappears. Might it be an idea not to use an AJAX backgrounded thread

for

...

sending the email, but staying on the foreground; only to return to the inbox once the message has succesfully been send?

While on the subject of gmail, an implemented "autosaving" draft would alleviate a lot of these types of problems. Or even further, a deal where a sent email is saved as a draft, and when sucessfully sent deleted from a drafts folder. Maybe that is essentially what gmail does anyway, just automatically every few minutes. I can't tell you how many times something has happened on any webmail system where I've crafted an email and sent it, only to have a connection drop or something and lose that email!

Some other stuff I thought of:

...

• move the current overflow-scrollbar style from the table to the tbody.

This would leave the thead always visible, while currently it will disappear when scrolling

• make the attachment-icon (singleclick) in the messagelisting jump

directly to the message-attachment. Currently it is just an icon without any link

• a javascript prompt before any actual delete action, for example in

the

...

addressbook page

• could we merge the _auth (GET) and sessid (COOKIE) into 1 sessionID?

Comments welcome :)

Regards, Sjon

Thomas Bruederli wrote:

Sjon wrote:

...

After loosing an important mail composed under Roundcube (just pushed the send-button, 'something' went wrong and the email was lost forever) I have thought of ideas to avoid this. I think the following might be feasible: currently mails are send in the background; a failure means the message disappears. Might it be an idea not to use an AJAX backgrounded thread for sending the email, but staying on the foreground; only to return to the inbox once the message has succesfully been send?

Usually, RoundCube shows the compose page with all submitted form data again, if sending failed. Don't know what went wrong in your case... but you're right, sending the message in the background (mails are currently sent in the "foreground") would be a better solution.

I think we agree that an email should never be lost if sending it failse; I don't know what the exact solution should be for that.

...

Some other stuff I thought of:

• move the current overflow-scrollbar style from the table to the tbody. This would leave the thead always visible, while currently it will disappear when scrolling

If somebody can provide CSS code that works in all common browsers (yes, including IE) we will not hesitate to implement it. I already spent hours on this but did not succeed.... I recently found this but did not try it out because it's a real hack: http://groups.google.ch/group/Web-Development-Room/browse_thread/thread/70c7...

A colleague of mine was saying it was rather easy; so I'll ask him for some good example code :)

...

• make the attachment-icon (singleclick) in the messagelisting jump directly to the message-attachment. Currently it is just an icon without any link

And what should happen, if there are more than one attachments?

Interesting point. How about jumping to the #attachment in the message?

...

• could we merge the _auth (GET) and sessid (COOKIE) into 1 sessionID?

The _auth hash is an additional security feature. It contains the session-id (from cookie) as well as the client IP and these are checked on request. To steal someones session you have to fetch to cookie, the hash and fake your hosts IP.

Then what is the real use? :) I think almost all web applications are secured with a single sessionID which (I think) has always found to be secure enough. What is the actual security-addition here? I think we should drop it :) If we would like to check for IP-changes store the IP-address in the _SESSION to check for (even thought IP-changes are sometimes valid)

On Wed, 18 Jan 2006, Robi wrote:

The next step we can call the "smart save" method, where there would be a bit of JS to look for pauses in typing or a simple 30 sec interval, and do an autosave with a timestamp. This way one can have multiple autosaves, that update each other and if anything happens in the long run, you still have the most recent draft available. This periodic save should also keep the session active longer while one is in compose mode, and eliminate the session timeout problem.

This is what was done on the lifetype blog software project 

(lifetype.net), and it works quite nicely. I didn't write that bit of code, but I am a developer on that project, so I might be able to figure it out for roundcube. Haven't gotten into the RC code yet though.

Jon Daley http://jon.limedaley.com/

Abandon it. -- Frank Lloyd Wright, on being asked how he would go about improving Pittsburgh

Just creating the manual save should probably be the first priority. If done properly most of the code used for a manual save could be reused for an automatic save. Keep in mind that an automatic save should never overwrite a manual save.

I've never heard of an e-mail program that saved multiple versions of an e-mail as it's being composed. My feeling is that if the automatic save overwrote itself rather than keeping multiple copies it would save a lot of coding that would hardly ever get used. Most of the time, hopefully, the backup copy will never be used at all, and of the times it is used, the vast majority of the time the user is just going to want the most recent copy before disconnection. The challenge would be to include lots of checks to make sure that something hasn't gone wrong before performing the auto-save.

-Charles

Mark Dehus wrote:

That is a good suggestion. I think there should also be a save button added. That way the user has an option to save without worrying about that XX second gap before autosave.

Mark

Robi wrote:

...

For the lost emails when sending problem,

My suggestion is to go at it in two steps.

First would be to save every message ready to send, and if it fails, not delete it from the draft directory or whatever the case will be. This means that the textbox input with whatever it contains upon clicking the send button gets saved. This will not help in cases where one types a long email for an hour and then the browser crashes for example and the email is lost. Lets call this step the "dumb save" method.

The next step we can call the "smart save" method, where there would be a bit of JS to look for pauses in typing or a simple 30 sec interval, and do an autosave with a timestamp. This way one can have multiple autosaves, that update each other and if anything happens in the long run, you still have the most recent draft available. This periodic save should also keep the session active longer while one is in compose mode, and eliminate the session timeout problem.

thoughts?

-- Robi

On Wed, 18 Jan 2006 14:36:08 -0600, Charles McNulty charles@charlesmcnulty.com wrote:

Just creating the manual save should probably be the first priority. If done properly most of the code used for a manual save could be reused for an automatic save. Keep in mind that an automatic save should never overwrite a manual save.

I've never heard of an e-mail program that saved multiple versions of an e-mail as it's being composed.

Squirrelmail did this, and frustrated the hell out of me.

recent copy before disconnection. The challenge would be to include lots of checks to make sure that something hasn't gone wrong before performing the auto-save.

Again, Squirrelmail had a plugin, some javascript that would 'save' a msg every so many seconds. It was cool, if you navigated away from the page and came back then you'd get the popup, and the text would automatically be repopulated if you said you wanted it.

http://www.squirrelmail.org/plugin_view.php?id=8

P

-Charles

Mark Dehus wrote:

...

That is a good suggestion. I think there should also be a save button added. That way the user has an option to save without worrying about that XX second gap before autosave.

Mark

Robi wrote:

...

For the lost emails when sending problem,

My suggestion is to go at it in two steps.

First would be to save every message ready to send, and if it fails, not delete it from the draft directory or whatever the case will be. This means that the textbox input with whatever it contains upon clicking the send button gets saved. This will not help in cases where one types a long email for an hour and then the browser crashes for example and the email is lost. Lets call this step the "dumb save" method.

The next step we can call the "smart save" method, where there would be a bit of JS to look for pauses in typing or a simple 30 sec interval, and do an autosave with a timestamp. This way one can have multiple autosaves, that update each other and if anything happens in the long run, you still have the most recent draft available. This periodic save should also keep the session active longer while one is in compose mode, and eliminate the session timeout problem.

thoughts?

-- Robi