Now, when we have threads implemented, it's more important to do this well. Currenlty when a new message arrives: in list mode it is displayed on top of the list, in threads mode the whole list is reloaded.
To make the behaviour consistent and intuitive I propose to add an option "Add recent messages on top of the list". If enabled, new messages will be placed on top as now in list mode. Here I've got a one doubt. In threads mode a message (non-root, which is a part of some thread) also could be placed on top, but there would be a problem with threads counter also this may be not so intuitive. With this option disabled, new messages would be placed in their places. So, e.g. if user has opened let's say a 10th page of the list he will get no new records. Also in threads mode new messages should be placed in their places and if so, some threads may change a placement on the list according to sorting order, but we shouldn't reload the whole list.
What do you think?
On Thu, 08 Apr 2010 09:53:15 +0200, "A.L.E.C" alec@alec.pl wrote:
Now, when we have threads implemented, it's more important to do this well. Currenlty when a new message arrives: in list mode it is displayed
on top of the list, in threads mode the whole list is reloaded.
To make the behaviour consistent and intuitive I propose to add an option "Add recent messages on top of the list". If enabled, new messages will be placed on top as now in list mode. Here I've got a one doubt. In threads mode a message (non-root, which is a part of some thread) also could be placed on top, but there would be a problem with threads counter also this may be not so intuitive. With this option disabled, new messages would be placed in their places.
So, e.g. if user has opened let's say a 10th page of the list he will get no new records. Also in threads mode new messages should be placed in their places and if so, some threads may change a placement on the list according to sorting order, but we shouldn't reload the whole list.
What do you think?
The "Add recent messages on top of the list" could easily make the current view inconsistent both in non-threaded mode (e.g. mailbox might be sorted with oldest mails first, but then a new mail arrives and is put at the top of the list), and in threaded mode (same problems, and messages that are part of a thread aren't inserted into the thread). The main benefit of adding recent messages to the top of the list is that you can find them easily. So how about not adding this option, but making new messages easy to discover another way. For example, add a hyperlink above the message table "1 new message", and then clicking on it would select the new message.
Regards, Chris
List info: http://lists.roundcube.net/dev/
Chris January wrote:
The "Add recent messages on top of the list" could easily make the current view inconsistent both in non-threaded mode (e.g. mailbox might be sorted with oldest mails first, but then a new mail arrives and is put at the top of the list), and in threaded mode (same problems, and messages that are part of a thread aren't inserted into the thread).
But if this will be an option user will have a possibility to disable this "inconsistent" behaviour. Now, he can't.
The main benefit of adding recent messages to the top of the list is that you can find them easily. So how about not adding this option, but making new messages easy to discover another way. For example, add a hyperlink above the message table "1 new message", and then clicking on it would select the new message.
I don't know if we need a new feature while we have now a filter with "Unread" position.
But if this will be an option user will have a possibility to disable this "inconsistent" behaviour. Now, he can't.
Why does this inconsistent behavior exist at all? I guess I missed that earlier :) I think the discussion shouldnt be about options to make this user changeable, but about eliminating the whole problem. Sorting a new msg on top if im sorted anything but new->old is just weird and wrong. Thats going to cause massive confusion. I assume it's a performance issue about having to refetch/reorder all msgs?
Cor
List info: http://lists.roundcube.net/dev/
Cor Bosman wrote:
Why does this inconsistent behavior exist at all? I assume it's a performance issue about having to refetch/reorder all msgs?
I gues it's because of simplicity and better performance, but now I'd like to make this right. I also don't need this feature, but can imagine that some users will want it. +1 from me to get rid of "place recent messages on top" feature.
On Thu, 08 Apr 2010 14:52:05 +0200, "A.L.E.C" alec@alec.pl wrote:
Cor Bosman wrote:
Why does this inconsistent behavior exist at all? I assume it's a performance issue about having to refetch/reorder all msgs?
I gues it's because of simplicity and better performance, but now I'd like to make this right. I also don't need this feature, but can imagine
that some users will want it. +1 from me to get rid of "place recent messages on top" feature.
+1 for me too to get rid of "place recent messages on top".
-- Less is more! _______________________________________________ List info: http://lists.roundcube.net/dev/
On Thu, 08 Apr 2010 10:35:55 +0200, "A.L.E.C" alec@alec.pl wrote:
Chris January wrote:
The "Add recent messages on top of the list" could easily make the current view inconsistent both in non-threaded mode (e.g. mailbox might be
sorted
with oldest mails first, but then a new mail arrives and is put at the top of the list), and in threaded mode (same problems, and messages that
are
part of a thread aren't inserted into the thread).
But if this will be an option user will have a possibility to disable this "inconsistent" behaviour. Now, he can't.
Sorry, if it wasn't clear, I was proposing removing the feature altogether (as you and Alain have already +1'ed). Then no option is needed.
The main benefit of adding recent messages to the top of the list is
that
you can find them easily. So how about not adding this option, but
making
new messages easy to discover another way. For example, add a hyperlink above the message table "1 new message", and then clicking on it would select the new message.
I don't know if we need a new feature while we have now a filter with "Unread" position.
If, like me, you leave lots of messages unread in a mailbox then the Unread filter is not sufficient to take you to new messages.
Regards, Chris
List info: http://lists.roundcube.net/dev/
If, like me, you leave lots of messages unread in a mailbox then the Unread filter is not sufficient to take you to new messages.
That's why I proposed to implement 'by date' search filters. They are native to IMAP, and help a lot. _______________________________________________ List info: http://lists.roundcube.net/dev/
On Thu, Apr 8, 2010 at 14:52, A.L.E.C alec@alec.pl wrote:
Cor Bosman wrote:
Why does this inconsistent behavior exist at all? I assume it's a performance issue about having to refetch/reorder all msgs?
I gues it's because of simplicity and better performance, but now I'd like to make this right. I also don't need this feature, but can imagine that some users will want it. +1 from me to get rid of "place recent messages on top" feature.
I also agree that we should get rid of it. Initially it was me who implemented it that way but since I usually have my messages sorted by date it'll not change anything for me. Also reloading the entire page is IMO not too much of a performance killer because it only happens when there are potentially new messages waiting to be listed. Let's just reload the current page in any case and then see if there's any need for performance improvements.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
Thomas Bruederli wrote:
I also agree that we should get rid of it. Initially it was me who implemented it that way but since I usually have my messages sorted by date it'll not change anything for me. Also reloading the entire page is IMO not too much of a performance killer because it only happens when there are potentially new messages waiting to be listed. Let's just reload the current page in any case and then see if there's any need for performance improvements.
Yes, this will be simpler, but we must add some code to not unselect selected messages on the list (or re-select them) and to not remove already viewed message in preview pane. Something more?
-
A.L.E.C -
Alain Nussbaumer -
Chris January -
Cor Bosman -
Thomas Bruederli -
Vladislav Bogdanov