6.0.0-beta1
9/17/25

[#2212] Inconsistent folder refresh location
Summary Inconsistent folder refresh location
Queue IMP
Queue Version HEAD
Type Bug
State Not A Bug
Priority 1. Low
Owners
Requester kevin_myer (at) iu13 (dot) org
Created 07/01/2005 (7383 days ago)
Due
Updated 07/06/2005 (7378 days ago)
Assigned 07/01/2005 (7383 days ago)
Resolved 07/03/2005 (7381 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
07/06/2005 11:45:03 PM Chuck Hagenbuch Comment #15 Reply to this comment
I get too much mail for that to be feasable (unless Virtual Inbox
supports choosing which folders to include in the Inbox).
Virtual Inbox shows all new messages in folders you're polling for new 
mail. You can always create a different virtual folder with only the 
folders you want.
07/06/2005 09:45:29 PM kevin_myer (at) iu13 (dot) org Comment #14 Reply to this comment
Yes, but I have lots of experience that says normal users don't think
that way.
I'll still maintain that if I CHOOSE to have my refresh take me to a 
new message, it should.  For all the normal users you have a 
experience with, the mailbox_start value would be set to Do Nothing (a 
new value I just created for the sake of keeping the refreshed view 
the same).  But I have a reasonable workaround.
I posed the scenario to my wife. She thinks it'd be rude if you were
automatically pulled away from your current view, and made a comment
about something similar that Gmail does that bugs her. She's
frequently shot down my own ideas, and is a pretty astute beta
tester. She's savvier than most, but certainly not technical. FYI.
You always have the chance that your message view is going to get 
rearranged on a refresh (especially in Thread mode, where "Horde 
frameset" is treated the same as "Horde Frame Set", but that, I think 
is the topic for an RFC enhancement to the IMAP THREAD extension).



But Jan's comment about using the Folder menu will do the trick.  I 
could have sworn, not too long ago, that the folder menu got reset to 
INBOX, regardless of what folder you were in, which would force you to 
navigate to find the current folder.  But it appears to be sticky now, 
so, with an AccessKey N, that should do a Refresh and JumpTo new mail.
Maybe you want to be using the Virtual Inbox or something like it?
I get too much mail for that to be feasable (unless Virtual Inbox 
supports choosing which folders to include in the Inbox).  I think the 
AccessKey N should work (and that either accidentally or intentionally 
coincides with other programs Next message command).  Although I just 
had WHUPS generate a _New ticket, when my focus was on IMP in another 
tab..  Have to see if that was a fluke or is reproducible.
07/04/2005 01:52:13 PM Chuck Hagenbuch Comment #13 Reply to this comment

[Show Quoted Text - 9 lines]
Yes, but I have lots of experience that says normal users don't think 
that way.



I posed the scenario to my wife. She thinks it'd be rude if you were 
automatically pulled away from your current view, and made a comment 
about something similar that Gmail does that bugs her. She's 
frequently shot down my own ideas, and is a pretty astute beta tester. 
She's savvier than most, but certainly not technical. FYI.



Maybe you want to be using the Virtual Inbox or something like it?
07/04/2005 01:11:59 PM kevin_myer (at) iu13 (dot) org Comment #12 Reply to this comment
If you go and read one of those messages, and are ready to move onto the
location of the next unread message, how do you do that?
I'll posit that this is an entirely different issue than how the
refresh icon behaves. You want a direct way to go to the next unread
message. Using the INBOX icon or a refresh is a developer-like
workaround IMHO, not normal user behavior. A normal user wants a
button for it.
Not necessarily.  I know that if I open a folder, I can expect  to be 
taken to the first unread message (or the end of the messages, if I 
have no unread messages).  I'm looking at a generalized implementation 
of the behavior of the INBOX icon and since you've already got a 
Refresh, rather than take up any more screen real estate, roll the 
functionality into refresh.  I'll grant that there will likely be 
users who dont' set mailbox_start to first unread, but who would still 
use a navigation feature to go to the next unread message.  But I 
still think that Refresh should incorporate the mailbox_start 
preference.
That's a not unreasonable feature request. It's sometimes going to be
tricky to define the "next" new message, but the sort order should
handle it. If we can figure out a good UI/flow for it and someone
writes the code, I have no problem including it.
Wouldn't it be using the same logic to determine which screen to 
display when you initially open a folder?  The message you initially 
were taken to is now read (if you chose to read it).  So getting the 
next unread message would be the same as choosing a folder, no?
So, if one of your "normal users" is looking at a specific set of
messages in the mailbox view, and an automatic refresh happens, and
they're taken to new mail and they then have to go *find* the
messages they were looking at  I don't think that will ever be
intuitive, even for someone who checked off "always show me new
mail". They *might* make the connection, but they'll still be annoyed.
Its happened to me on more than one occasion, with some annoyance, 
granted.  But the fact of the matter is that I believe most mail 
clients, when they refresh, will reset the state of your view.  I find 
myself trying to figure out how to get to next screen with an unread 
message way more often than I find my screen getting refreshed when 
I'm reading senders and subjects.  If I configure a mail client to 
take me to new mail, thats a choice I make, and I realize a mail 
client can't possibly know what my conscious thought stream is and 
elect not to refresh a screen, if I happen to be looking at it :)


07/04/2005 12:24:00 PM kevin_myer (at) iu13 (dot) org Comment #11 Reply to this comment
Maybe because whats intuitive to developers may not be intuitive to
normal end-users, and vice versa?
Let me clarify that.  It wasn't intended to be a flame.  I think from 
time to time we all get tunnel vision.  Developers make decisions 
based on what they think or want.  Admins configure software with 
settings that, after testing, reveal that they need to be changed, 
based on user-feedback.  And users want features (now) that do XYZ 
because they see XYZ elsewhere, or because thats the way they've 
always done things.  Why these decisions are oft-times unintuitive is 
a) developers don't always fully vette their ideas with real 
non-technical end-users, b) admins don't use a wide-enough audience in 
determining initial settings, and c) end-users have unreasonable 
expectations about what it takes to develop software, and in some 
cases, the way they do things is just plain wrong.  Hence, from time 
to time (not intended to be a blanket statement) what's intuitive to 
one group is not intuitive to another.

[Show Quoted Text - 10 lines]
Not intended to be insulting, and again, not intended to be a blanket 
statement, as clarified above.  That will learn me to wait until I'm 
not so frustrated, to respond, so that the proper modifiers and 
qualifiers make it into a statement.
Obviously, I must be the only one in the world who has run into this
problem,
as obviously I must be the only one in the world who thinks the fetchmail
behavior is inconsistent too (2211).  It isn't quite noone, but onlyone (who
has taken the time to document and report it).
Uh, 2211 is open.
Yes, just making light of the fact that I don't think that using the 
argument that noone has reported it is a valid argument.  I can 
certainly see where noone else may agree with an idea, in which case 
it either dies or is refined.  But the fact that noone has reported it 
doesn't mean a lot.  Thats a little bit insulting to first time bug 
reporters, who take the time to formally document a bug.
07/04/2005 03:29:17 AM Chuck Hagenbuch Comment #10 Reply to this comment
Maybe because whats intuitive to developers may not be intuitive to
normal end-users, and vice versa?
Alright, obviously you're frustrated. However:



a). I'd say that more than 50% of your requests/suggestions/etc. have 
been implemented, if not better.



b). The above is downright insulting. Sometimes developers are out of 
touch with users, but most of the core developers use IMP as their 
primary and/or only email client. I fix crap all the time in IMP and 
other Horde apps because it bugs me - as a user. We respond to 
requests from users - like you - all the time. ...
Obviously, I must be the only one in the world who has run into this problem,
as obviously I must be the only one in the world who thinks the fetchmail
behavior is inconsistent too (2211).  It isn't quite noone, but onlyone (who
has taken the time to document and report it).
Uh, 2211 is open.
07/04/2005 03:15:30 AM Chuck Hagenbuch Comment #9 Reply to this comment
If you go and read one of those messages, and are ready to move onto the
location of the next unread message, how do you do that?
I'll posit that this is an entirely different issue than how the 
refresh icon behaves. You want a direct way to go to the next unread 
message. Using the INBOX icon or a refresh is a developer-like 
workaround IMHO, not normal user behavior. A normal user wants a 
button for it.



That's a not unreasonable feature request. It's sometimes going to be 
tricky to define the "next" new message, but the sort order should 
handle it. If we can figure out a good UI/flow for it and someone 
writes the code, I have no problem including it.
I believe the behavior of a refresh should honor whatever value I
choose for mailbox_start, whether that refresh is automatic, forced,
or implied, by clicking on a folder.  Which really amounts to
mailbox_start being expanded to be "When opening or refreshing a
mailbox, which page do you want to start on?", which I think is a
logical, useful extension.
So, if one of your "normal users" is looking at a specific set of 
messages in the mailbox view, and an automatic refresh happens, and 
they're taken to new mail and they then have to go *find* the messages 
they were looking at  I don't think that will ever be intuitive, even 
for someone who checked off "always show me new mail". They *might* 
make the connection, but they'll still be annoyed.
07/03/2005 09:53:14 PM kevin_myer (at) iu13 (dot) org Comment #8 Reply to this comment
Or select the folder directly from the drop down list.
WIth 200+ folders, the same pain of finding and scrolling to the 
folder I want exists, as expanding the folders in the left side bar.
Noone else seem to believe this, at least noone else requested such
behaviour in the past and two developers already considered such a
behaviour unintuitive.
Maybe because whats intuitive to developers may not be intuitive to 
normal end-users, and vice versa?  Obviously, I must be the only one 
in the world who has run into this problem, as obviously I must be the 
only one in the world who thinks the fetchmail behavior is 
inconsistent too (2211).  It isn't quite noone, but onlyone (who has 
taken the time to document and report it).



I've used IMP as my primary email client for the past four years so 
I'm not up to speed on how some of the fat clients behave but a quick 
glance reveals that most, if not all of them, have an easy way to get 
to the next unread message (CTL-N in Thunderbird, shift+. in 
Evolution, for example).  And as new messages come in, and your screen 
is refreshed, they'll take you to and display the new message (I don't 
like the display part, I may not want to read the message, but I do 
like having the message subject and sender shown to me).
07/03/2005 08:56:40 PM Jan Schneider Comment #7 Reply to this comment
next unread message, how do you do that?  If the folder is the INBOX,
you can use the INBOX icon to get an updated message count and move
to the next unread message location.  If its not the INBOX, you have
to expand your folder structure and choose the folder, then click on
it.
Or select the folder directly from the drop down list.
I believe the behavior of a refresh should honor whatever value I
choose for mailbox_start, whether that refresh is automatic, forced,
or implied, by clicking on a folder.  Which really amounts to
Noone else seem to believe this, at least noone else requested such 
behaviour in the past and two developers already considered such a 
behaviour unintuitive.
07/03/2005 07:06:34 PM kevin_myer (at) iu13 (dot) org Comment #6 Reply to this comment
All in all, kind of frustrating if you're trying to always have IMP 
jump to the first unread message in a folder.  Take a non-hypothetical 
situation, such as this:  1000 messages in a folder, sorted by any 
criteria.  Most of the time, new messages will show up at either the 
end or the beginning of the view, depending if you sort ascending or 
descending.  But you'll get a fair number of stray messages dispersed 
throughout the index too.  If you go and read one of those messages, 
and are ready to move onto the location of the next unread message, 
how do you do that?  If the folder is the INBOX, you can use the INBOX 
icon to get an updated message count and move to the next unread 
message location.  If its not the INBOX, you have to expand your 
folder structure and choose the folder, then click on it.  Or skip 
from screenful of message to screenful of messages, and keep skipping 
until you find the next unread message.  Whereas if the refresh was 
both a refresh and a jumpto function, a quick Accesskey R would get 
you there - no folder navigation and expansion necessary, no wasted 
time trying to find the next unread message.  Software should provide 
functionality to process messages more quickly, not force me to wade 
to find the next message to process.



I believe the behavior of a refresh should honor whatever value I 
choose for mailbox_start, whether that refresh is automatic, forced, 
or implied, by clicking on a folder.  Which really amounts to 
mailbox_start being expanded to be "When opening or refreshing a 
mailbox, which page do you want to start on?", which I think is a 
logical, useful extension.
07/03/2005 03:25:52 PM Chuck Hagenbuch Comment #5
State ⇒ Not A Bug
Reply to this comment
Yes. the intent is not to replicate the Inbox icon. It's to refresh 
the current view.
07/03/2005 10:20:39 AM Jan Schneider Comment #4 Reply to this comment
I agree with Chuck.
07/02/2005 12:15:06 PM kevin_myer (at) iu13 (dot) org Comment #3 Reply to this comment
But then both the auto-refresh and the refresh icon really amount to a 
message index refresh (which is fine).  If the intent is to have them 
behave differently than the INBOX icon, thats fine.  It basically 
serves the function of new mail notification only, either with audio, 
or with an incrementing number.  I just thought it would be useful to 
also take you to the new message(s), because I'm going to have to 
click on the INBOX icon after a notification anyway.  Why not roll 
that into a refresh?
07/01/2005 11:15:57 PM Chuck Hagenbuch Comment #2
State ⇒ Feedback
Reply to this comment
The refresh icon specifically stays on the page you're currently on. 
I'm not sure that changing that would be any more intuitive.
07/01/2005 10:19:53 PM kevin_myer (at) iu13 (dot) org Comment #1
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ Inconsistent folder refresh location
Queue ⇒ IMP
State ⇒ Unconfirmed
Reply to this comment
If mailbox_start=1:



If you use the refresh link for the folder that's display (the 
circular arrows icon), you're not taken to the first unread message, 
but the message index is updated.  Same thing if you have auto-refresh 
configured for IMP.  If you click on the INBOX icon in the menu, you 
are taken to the first unread message.



Any refresh should honor the value you have set for mailbox_start.

Saved Queries