I want to clarify that my question wasn't about changing double-click behavior, it's about reducing/removing the delay for single click behavior. Right now, there is 1/2 a second delay before loading an email preview, presumably to prevent redundant loading of the email when that click was the first of an intended double-click.
If reducing server load is more important than reducing end-user waiting, it makes sense. At our site, we'd rather use more servers and deliver a more responsive application.
One thing that we've discovered is that if you don't schedule the single click behavior and just call it immediately on click, auto-loading the next message after dragging one to the trash won't work. (When "flag_for_deletion" = false). However, if you schedule it for 0 microseconds later, it still works.
Can anyone think of other problems with reducing the dblclick_time?
Thanks, Ziba
On Thu, 14 Aug 2008 16:43:02 -0400, ziba ziba@umich.edu wrote:
Hi,
I'm wondering what the purpose(s) of dblclick_time are as used in program/js/app.js:this.msglist_select
It seems clear that it will prevent the message preview from loading while the user is about to hit their second click to open the full message screen. There is some nice economy there. However, if they are just single clicking with the intent to see the preview it adds 0.51 seconds before the preview is shown.
Are there other reasons for waiting dblclick_time + 10 after a single click to show the preview? If not, I'd side with the faster preview time over the economy of not loading the preview before loading the whole message. --
Ziba Scott Web Application Developer Web/DB Team, Information Technology Central Services The University of Michigan
List info: http://lists.roundcube.net/dev/
Ziba Scott wrote:
I want to clarify that my question wasn't about changing double-click behavior, it's about reducing/removing the delay for single click behavior. Right now, there is 1/2 a second delay before loading an email preview, presumably to prevent redundant loading of the email when that click was the first of an intended double-click.
I understand your opinion and I suggest to reduce the wait time to about 200ms. The delay is not only important when double-clicking but also when the user scrolls the list with the cursor keys. There's no need to load every message that is highlighted fur just a few ms.
If reducing server load is more important than reducing end-user waiting, it makes sense. At our site, we'd rather use more servers and deliver a more responsive application.
I think we need the best solution for both worlds...
~Thomas
List info: http://lists.roundcube.net/dev/
200ms sounds like a reasonable compromise for now. In the future, perhaps something could be implemented which has a more context dependent delay. For example if you hit the down arrow once, there is very little delay. If you hit down again within x ms there is a larger delay because you are probably holding the key down.
Thanks, Ziba
Thomas Bruederli wrote:
Ziba Scott wrote:
I want to clarify that my question wasn't about changing double-click behavior, it's about reducing/removing the delay for single click behavior. Right now, there is 1/2 a second delay before loading an email preview, presumably to prevent redundant loading of the email when that click was the first of an intended double-click.
I understand your opinion and I suggest to reduce the wait time to about 200ms. The delay is not only important when double-clicking but also when the user scrolls the list with the cursor keys. There's no need to load every message that is highlighted fur just a few ms.
If reducing server load is more important than reducing end-user waiting, it makes sense. At our site, we'd rather use more servers and deliver a more responsive application.
I think we need the best solution for both worlds...
~Thomas
List info: http://lists.roundcube.net/dev/
-
Thomas Bruederli -
Ziba Scott