I run a small web hosting business and we just switched from
SquirrelMail to RoundCube. Overall, our clients love it. The polished
interface is so nice coming from the previous app.
The biggest problem people moan about is multi-select. It is not
intuitive to use a key modifier like Shift or Control to select
multiple messages. In addition, in IE7 when you control-click it
opens the message in another tab, so if you control-click 10 messages
to delete them, you now also have 10 tabs to close.
Is there something I am missing on this problem? Is there a setting
where I can enable an old school checkbox column for people to use in
multi-select?
Joel Clermont joel@orionweb.net 262-377-9930
List info: http://lists.roundcube.net/dev/
Joel Clermont wrote:
The biggest problem people moan about is multi-select. It is not intuitive to use a key modifier like Shift or Control to select multiple messages.
What is not intuitive in this behavior? All apps behave like this.
In addition, in IE7 when you control-click it opens the message in another tab, so if you control-click 10 messages to delete them, you now also have 10 tabs to close.
This is a problem currently not solved because IE7 does not allow the javascript to cancel the event. And here we have a conflict between two different points of view: some people want to have the message subject as real link in order to open the message in a new tab by ctrl-clicking it and others want to select multiple messages using ctrl-click.
Is there something I am missing on this problem? Is there a setting where I can enable an old school checkbox column for people to use in multi-select?
We don't have checkboxes and there won't be any checkboxes at all. And please don't start yet another endless discussion about this!
The only solution I see is to tell the users that they should not click the message subject (but another col or whitespace) when selecting multiple messages with ctrl.
~Thomas
List info: http://lists.roundcube.net/dev/
I appreciate your response. I didn't realize I was stoking a fire on
the checkbox question :-) I will promptly drop it.
I will have to give this some more thought. I think we can probably
solve this with training. Thank you again.
Joel Clermont joel@orionweb.net 262-377-9930
On Sep 10, 2007, at 9:20 AM, Thomas Bruederli wrote:
Joel Clermont wrote:
The biggest problem people moan about is multi-select. It is not intuitive to use a key modifier like Shift or Control to select
multiple messages.What is not intuitive in this behavior? All apps behave like this.
In addition, in IE7 when you control-click it opens the message in another tab, so if you control-click 10 messages to delete them, you now also have 10 tabs to close.
This is a problem currently not solved because IE7 does not allow the javascript to cancel the event. And here we have a conflict between
two different points of view: some people want to have the message
subject as real link in order to open the message in a new tab by ctrl- clicking it and others want to select multiple messages using ctrl-click.Is there something I am missing on this problem? Is there a setting where I can enable an old school checkbox column for people to use in multi-select?
We don't have checkboxes and there won't be any checkboxes at all. And please don't start yet another endless discussion about this!
The only solution I see is to tell the users that they should not
click the message subject (but another col or whitespace) when selecting
multiple messages with ctrl.~Thomas
List info: http://lists.roundcube.net/dev/
Although I advise users to switch to Firefox, I worked around the issue by allowing "alt + click" to behave the same as "ctrl + click".
To implement it, change line 130 in program/js/common.js from:
opcode += (e.ctrlKey && CONTROL_KEY) + (e.shiftKey && SHIFT_KEY);
To:
opcode += (((e.altKey == true) ? e.altKey : e.ctrlKey) && CONTROL_KEY) + (e.shiftKey && SHIFT_KEY);
If this doesn't cause any problems, maybe it should be added to trunk?
Rich
Thomas Bruederli wrote:
Joel Clermont wrote:
The biggest problem people moan about is multi-select. It is not intuitive to use a key modifier like Shift or Control to select multiple messages.
What is not intuitive in this behavior? All apps behave like this.
In addition, in IE7 when you control-click it opens the message in another tab, so if you control-click 10 messages to delete them, you now also have 10 tabs to close.
This is a problem currently not solved because IE7 does not allow the javascript to cancel the event. And here we have a conflict between two different points of view: some people want to have the message subject as real link in order to open the message in a new tab by ctrl-clicking it and others want to select multiple messages using ctrl-click.
Is there something I am missing on this problem? Is there a setting where I can enable an old school checkbox column for people to use in multi-select?
We don't have checkboxes and there won't be any checkboxes at all. And please don't start yet another endless discussion about this!
The only solution I see is to tell the users that they should not click the message subject (but another col or whitespace) when selecting multiple messages with ctrl.
~Thomas
List info: http://lists.roundcube.net/dev/
Did you test it yet? Sure looks like it would get the job done.
Is there anything else you "changed"?
On 9/14/07, Rich at Whidbey Telecom richs@whidbey.net wrote:
Although I advise users to switch to Firefox, I worked around the issue by allowing "alt + click" to behave the same as "ctrl + click".
To implement it, change line 130 in program/js/common.js from:
opcode += (e.ctrlKey && CONTROL_KEY) + (e.shiftKey && SHIFT_KEY);
To:
opcode += (((e.altKey == true) ? e.altKey : e.ctrlKey) && CONTROL_KEY) + (e.shiftKey && SHIFT_KEY);
If this doesn't cause any problems, maybe it should be added to trunk?
Rich
Thomas Bruederli wrote:
Joel Clermont wrote:
The biggest problem people moan about is multi-select. It is not intuitive to use a key modifier like Shift or Control to select multiple messages.
What is not intuitive in this behavior? All apps behave like this.
In addition, in IE7 when you control-click it opens the message in another tab, so if you control-click 10 messages to delete them, you now also have 10 tabs to close.
This is a problem currently not solved because IE7 does not allow the javascript to cancel the event. And here we have a conflict between two different points of view: some people want to have the message subject as real link in order to open the message in a new tab by ctrl-clicking it and others want to select multiple messages using ctrl-click.
Is there something I am missing on this problem? Is there a setting where I can enable an old school checkbox column for people to use in multi-select?
We don't have checkboxes and there won't be any checkboxes at all. And please don't start yet another endless discussion about this!
The only solution I see is to tell the users that they should not click the message subject (but another col or whitespace) when selecting multiple messages with ctrl.
~Thomas
List info: http://lists.roundcube.net/dev/
--
Rich Sandberg richs@whidbey.net Whidbey Telecom Network Operations _______________________________________________ List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/
Oh yes, we're using it in production now. Didn't have to change
anything else.
It should be noted that "Alt" does toggle a menu toolbar in IE 7, so
each time a message is selected, the menus either appear or
disappears. It's less annoying than closing popups at least.
Rich
On Sep 14, 2007, at 3:07 PM, till wrote:
Did you test it yet? Sure looks like it would get the job done.
Is there anything else you "changed"?
On 9/14/07, Rich at Whidbey Telecom richs@whidbey.net wrote:
Although I advise users to switch to Firefox, I worked around the
issue by allowing "alt + click" to behave the same as "ctrl + click".To implement it, change line 130 in program/js/common.js from:
opcode += (e.ctrlKey && CONTROL_KEY) + (e.shiftKey && SHIFT_KEY);
To:
opcode += (((e.altKey == true) ? e.altKey : e.ctrlKey) &&
CONTROL_KEY) + (e.shiftKey && SHIFT_KEY);If this doesn't cause any problems, maybe it should be added to
trunk?Rich
Thomas Bruederli wrote:
Joel Clermont wrote:
The biggest problem people moan about is multi-select. It is not intuitive to use a key modifier like Shift or Control to select
multiple messages.What is not intuitive in this behavior? All apps behave like this.
In addition, in IE7 when you control-click it opens the message in another tab, so if you control-click 10 messages to
delete them, you now also have 10 tabs to close.This is a problem currently not solved because IE7 does not allow
the javascript to cancel the event. And here we have a conflict
between two different points of view: some people want to have the message
subject as real link in order to open the message in a new tab by ctrl- clicking it and others want to select multiple messages using ctrl-click.Is there something I am missing on this problem? Is there a setting where I can enable an old school checkbox column for people to
use in multi-select?We don't have checkboxes and there won't be any checkboxes at
all. And please don't start yet another endless discussion about this!The only solution I see is to tell the users that they should not
click the message subject (but another col or whitespace) when selecting
multiple messages with ctrl.~Thomas
List info: http://lists.roundcube.net/dev/
--
Rich Sandberg richs@whidbey.net Whidbey Telecom Network Operations _______________________________________________ List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/
Ah, right. In IE7, correct?
If you have tested this with all browsers (IE6/7, firefox and safari), I'd say, commit away.
Maybe send me a link to your diff (trac.roundcube.net) so I can implement it on devel-vnext.
Good job!
Thanks, Till
On 9/15/07, richs@whidbey.net richs@whidbey.net wrote:
Oh yes, we're using it in production now. Didn't have to change anything else.
It should be noted that "Alt" does toggle a menu toolbar in IE 7, so each time a message is selected, the menus either appear or disappears. It's less annoying than closing popups at least.
Rich
On Sep 14, 2007, at 3:07 PM, till wrote:
Did you test it yet? Sure looks like it would get the job done.
Is there anything else you "changed"?
On 9/14/07, Rich at Whidbey Telecom richs@whidbey.net wrote:
Although I advise users to switch to Firefox, I worked around the issue by allowing "alt + click" to behave the same as "ctrl + click".
To implement it, change line 130 in program/js/common.js from:
opcode += (e.ctrlKey && CONTROL_KEY) + (e.shiftKey && SHIFT_KEY);
To:
opcode += (((e.altKey == true) ? e.altKey : e.ctrlKey) && CONTROL_KEY) + (e.shiftKey && SHIFT_KEY);
If this doesn't cause any problems, maybe it should be added to trunk?
Rich
Thomas Bruederli wrote:
Joel Clermont wrote:
The biggest problem people moan about is multi-select. It is not intuitive to use a key modifier like Shift or Control to select multiple messages.
What is not intuitive in this behavior? All apps behave like this.
In addition, in IE7 when you control-click it opens the message in another tab, so if you control-click 10 messages to delete them, you now also have 10 tabs to close.
This is a problem currently not solved because IE7 does not allow the javascript to cancel the event. And here we have a conflict between two different points of view: some people want to have the message subject as real link in order to open the message in a new tab by ctrl- clicking it and others want to select multiple messages using ctrl-click.
Is there something I am missing on this problem? Is there a setting where I can enable an old school checkbox column for people to use in multi-select?
We don't have checkboxes and there won't be any checkboxes at all. And please don't start yet another endless discussion about this!
The only solution I see is to tell the users that they should not click the message subject (but another col or whitespace) when selecting multiple messages with ctrl.
~Thomas
List info: http://lists.roundcube.net/dev/
--
Rich Sandberg richs@whidbey.net Whidbey Telecom Network Operations _______________________________________________ List info: http://lists.roundcube.net/dev/
Hi Rich, Till
I'm not sure if switching to ALT is the best solution. The users should learn that web-apps behave the same as regular desktop apps do and the selection thing with shift/ctrl is a quasi standard. We should not break this as come up with something different again.
Also the IE7 menubar toggeling can be annoying and will surely cause another post here or a bug ticket. IMO we should keep the ctrl-behavior and either remove the link on the subject again (this was requested to improve the usability for handicapped people and to allow "open in new tab") or we wait and hope that IE7 will allow us to cancel the click-event one day as other browsers do.
~Thomas
Rich at Whidbey Telecom wrote:
Although I advise users to switch to Firefox, I worked around the issue by allowing "alt + click" to behave the same as "ctrl + click".
To implement it, change line 130 in program/js/common.js from:
opcode += (e.ctrlKey && CONTROL_KEY) + (e.shiftKey && SHIFT_KEY);
To:
opcode += (((e.altKey == true) ? e.altKey : e.ctrlKey) && CONTROL_KEY) + (e.shiftKey && SHIFT_KEY);
If this doesn't cause any problems, maybe it should be added to trunk?
Rich
List info: http://lists.roundcube.net/dev/
You are correct - as usual. :)
I agreee that the RoundCube should aim to behave like desktop applications. I am guessing there has to be a way to "disable" the new window/tab triggering when you click on this. It's a tad annoying. But I guess we'll figure it out some time.
I am guessing preventDefault (if that is what it's called - I don't recall right now) does not work in IE?
Till
On 9/16/07, Thomas Bruederli roundcube@gmail.com wrote:
Hi Rich, Till
I'm not sure if switching to ALT is the best solution. The users should learn that web-apps behave the same as regular desktop apps do and the selection thing with shift/ctrl is a quasi standard. We should not break this as come up with something different again.
Also the IE7 menubar toggeling can be annoying and will surely cause another post here or a bug ticket. IMO we should keep the ctrl-behavior and either remove the link on the subject again (this was requested to improve the usability for handicapped people and to allow "open in new tab") or we wait and hope that IE7 will allow us to cancel the click-event one day as other browsers do.
~Thomas
Rich at Whidbey Telecom wrote:
Although I advise users to switch to Firefox, I worked around the issue by allowing "alt + click" to behave the same as "ctrl + click".
To implement it, change line 130 in program/js/common.js from:
opcode += (e.ctrlKey && CONTROL_KEY) + (e.shiftKey && SHIFT_KEY);
To:
opcode += (((e.altKey == true) ? e.altKey : e.ctrlKey) && CONTROL_KEY) + (e.shiftKey && SHIFT_KEY);
If this doesn't cause any problems, maybe it should be added to trunk?
Rich
List info: http://lists.roundcube.net/dev/
till wrote:
I am guessing preventDefault (if that is what it's called - I don't recall right now) does not work in IE?
Have fun with trying this out. I already spent hours to find a way but without success: http://trac.roundcube.net/trac.cgi/ticket/1484399
The event is passed to rcube_event.canel() which does
- preventDefault()
- stopPropagation()
- cancelBubble = true
- returnValue = fals
But this all does not prevent IE 7 from executing the default event action.
~Thomas
List info: http://lists.roundcube.net/dev/
I have some support tokens available from Microsoft. I will use one
of them this week and talk to their IE7 team and see what their
official answer is to this.
I will report back once I have some information.
Joel Clermont joel@orionweb.net 262-377-9930
On Sep 17, 2007, at 5:20 AM, Thomas Bruederli wrote:
till wrote:
I am guessing preventDefault (if that is what it's called - I don't recall right now) does not work in IE?
Have fun with trying this out. I already spent hours to find a way but without success: http://trac.roundcube.net/trac.cgi/ticket/1484399
The event is passed to rcube_event.canel() which does
- preventDefault()
- stopPropagation()
- cancelBubble = true
- returnValue = fals
But this all does not prevent IE 7 from executing the default event
action.~Thomas
List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/
Since I am new to RoundCube and this list, I thought it might be
beneficial for me to summarize my understanding of this issue before
I contact Microsoft and research a solution. Please read over my
summary and feel free to edit it or add to it as needed.
Round Cube uses common desktop conventions for multiple message
selection: control-click or shift-click. Round Cube also makes the
subject text a link for accessibility reasons. When the subject text
is control-clicked or shift-clicked, Round Cube acknowledges this as
a multi-select activity and cancels the click event on the subject
text link after marking the message as selected. However, in IE7,
control-click is an existing reserved event for "open this link in a
new tab". Using all the techniques for canceling a click event do not
work for a control-click in IE7. The message selection event works,
but you also have a needless new tab spawned in the background.
As it stands now, the workarounds for IE7 are to control-click in an
area other than the subject text, or to simply close the extra tabs
when you are done.
The goal is to find a way to successfully cancel the click event in
IE7 when control-click is used.
Does that sound about right?
Joel Clermont joel@orionweb.net 262-377-9930
On Sep 17, 2007, at 5:20 AM, Thomas Bruederli wrote:
till wrote:
I am guessing preventDefault (if that is what it's called - I don't recall right now) does not work in IE?
Have fun with trying this out. I already spent hours to find a way but without success: http://trac.roundcube.net/trac.cgi/ticket/1484399
The event is passed to rcube_event.canel() which does
- preventDefault()
- stopPropagation()
- cancelBubble = true
- returnValue = fals
But this all does not prevent IE 7 from executing the default event
action.~Thomas
List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/
Sounds "right" to me. Thanks for taking the time to summarize this.
On 9/17/07, Joel Clermont joel@orionweb.net wrote:
Since I am new to RoundCube and this list, I thought it might be beneficial for me to summarize my understanding of this issue before I contact Microsoft and research a solution. Please read over my summary and feel free to edit it or add to it as needed.
Round Cube uses common desktop conventions for multiple message selection: control-click or shift-click. Round Cube also makes the subject text a link for accessibility reasons. When the subject text is control-clicked or shift-clicked, Round Cube acknowledges this as a multi-select activity and cancels the click event on the subject text link after marking the message as selected. However, in IE7, control-click is an existing reserved event for "open this link in a new tab". Using all the techniques for canceling a click event do not work for a control-click in IE7. The message selection event works, but you also have a needless new tab spawned in the background.
As it stands now, the workarounds for IE7 are to control-click in an area other than the subject text, or to simply close the extra tabs when you are done.
The goal is to find a way to successfully cancel the click event in IE7 when control-click is used.
Does that sound about right?
Joel Clermont joel@orionweb.net 262-377-9930
On Sep 17, 2007, at 5:20 AM, Thomas Bruederli wrote:
till wrote:
I am guessing preventDefault (if that is what it's called - I don't recall right now) does not work in IE?
Have fun with trying this out. I already spent hours to find a way but without success: http://trac.roundcube.net/trac.cgi/ticket/1484399
The event is passed to rcube_event.canel() which does
- preventDefault()
- stopPropagation()
- cancelBubble = true
- returnValue = fals
But this all does not prevent IE 7 from executing the default event action.
~Thomas
List info: http://lists.roundcube.net/dev/
I have been working with someone on the IE team from Microsoft for
the last 2 days on this issue. They are saying that a ctrl-click in
IE7 does not even fire the onclick event at all. It appears that they
are correct. This is why none of the code cancels the event, it's not
even technically being fired.
Does this make sense to anyone here? I setup a sample page to
demonstrate the problem: http://orionweb.net/joelstuff/click.html
If you look at source, you will see i have a simple alert call in the
cancel function. It never gets called when doing a control-click in
IE7. Before I go back to Microsoft, I wanted to get some input from
the list.
Also, he asked the following question: Are you looking for a
scripting solution/workaround to this only? Are you open to using C+
- code with writing some kind of COM plugin?
I haven't answered yet, but my initial thought is that we want a pure
script solution, not some plugin hack. Thoughts?
Finally, is there any documentation you are aware of that I could
show the IE team stating it is bad practice to take low-level
ownership of a user-initiated click event? It seems like common sense
to me, but I'd love something official making a more solid point.
Thanks in advance. I will wait to hear back, and then I'll continue
working with MS tomorrow.
Joel Clermont joel@orionweb.net 262-377-9930
On Sep 17, 2007, at 12:54 PM, till wrote:
Sounds "right" to me. Thanks for taking the time to summarize this.
On 9/17/07, Joel Clermont joel@orionweb.net wrote:
Since I am new to RoundCube and this list, I thought it might be
beneficial for me to summarize my understanding of this issue before I contact Microsoft and research a solution. Please read over my summary and
feel free to edit it or add to it as needed.Round Cube uses common desktop conventions for multiple message
selection: control-click or shift-click. Round Cube also makes the subject
text a link for accessibility reasons. When the subject text is control- clicked or shift-clicked, Round Cube acknowledges this as a multi-select
activity and cancels the click event on the subject text link after marking the
message as selected. However, in IE7, control-click is an existing
reserved event for "open this link in a new tab". Using all the techniques for
canceling a click event do not work for a control-click in IE7. The message
selection event works, but you also have a needless new tab spawned in the
background.As it stands now, the workarounds for IE7 are to control-click in
an area other than the subject text, or to simply close the extra tabs
when you are done.The goal is to find a way to successfully cancel the click event
in IE7 when control-click is used.Does that sound about right?
Joel Clermont joel@orionweb.net 262-377-9930
On Sep 17, 2007, at 5:20 AM, Thomas Bruederli wrote:
till wrote:
I am guessing preventDefault (if that is what it's called - I don't recall right now) does not work in IE?
Have fun with trying this out. I already spent hours to find a way
but without success: http://trac.roundcube.net/trac.cgi/ticket/1484399The event is passed to rcube_event.canel() which does
- preventDefault()
- stopPropagation()
- cancelBubble = true
- returnValue = fals
But this all does not prevent IE 7 from executing the default
event action.~Thomas
List info: http://lists.roundcube.net/dev/
Joel Clermont wrote:
I have been working with someone on the IE team from Microsoft for the last 2 days on this issue. They are saying that a ctrl-click in IE7 does not even fire the onclick event at all. It appears that they are correct. This is why none of the code cancels the event, it's not even technically being fired.
Thanks so far. I've never thought of this, actually.
Does this make sense to anyone here? I setup a sample page to demonstrate the problem: http://orionweb.net/joelstuff/click.html
No, it does not make sense at all because it's a click and when I assign an "onclick" handler I expect it to fire when somebody actually clicks.
Also, he asked the following question: Are you looking for a scripting solution/workaround to this only? Are you open to using C++ code with writing some kind of COM plugin?
LOL! This sounds like a typical microsoft-style answer to me. Tsss....
I haven't answered yet, but my initial thought is that we want a pure script solution, not some plugin hack. Thoughts?
Right. We want to make a pure cross-browser web-application. I don't see any reason why to start writing COM plugins only to make IE behave like the other browsers. If we start doing this, we can also start writing a desktop app.
Finally, is there any documentation you are aware of that I could show the IE team stating it is bad practice to take low-level ownership of a user-initiated click event? It seems like common sense to me, but I'd love something official making a more solid point.
I didn't find anything yet. Looks like we're the first coming up with this problem. IMO a click is a click and the whole event-firing behavior should not change when holding down the Ctrl-key. Ctrl is just an event modifier and should be detectable like Alt and Shift keys are. It is even detectable and cancelable in click events from other elements than links. Why should links behave differently?
When comparing the behavior of Firefox, Safari and Opera I would call it best-practice when the four major browsers all behave the same.
Thanks in advance. I will wait to hear back, and then I'll continue working with MS tomorrow.
Thanks a lot for your effort!
~Thomas
List info: http://lists.roundcube.net/dev/
Hey Joel,
On 9/19/07, Joel Clermont joel@orionweb.net wrote:
(...) Thanks in advance. I will wait to hear back, and then I'll continue working with MS tomorrow.
Thanks for the hard work - we really appreciate it!
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
No problem. I'm glad to be able to give something back. My previous
open source project has died, so I have been looking for a new one to
contribute to. I think this is it :-)
My support engineer is waiting for a response back from the "higher
level" IE engineer. I'll report back when I hear anything.
Joel Clermont joel@orionweb.net 262-377-9930
On Sep 20, 2007, at 4:29 PM, till wrote:
Hey Joel,
On 9/19/07, Joel Clermont joel@orionweb.net wrote:
(...) Thanks in advance. I will wait to hear back, and then I'll
continue working with MS tomorrow.Thanks for the hard work - we really appreciate it!
Till
List info: http://lists.roundcube.net/dev/
-
Joel Clermont -
Rich at Whidbey Telecom -
richs＠whidbey.net
-
Thomas Bruederli -
till