Hm, didn't know he's still a developer of Horde, no commits from him 
for really long time.

Because of Michael's reasoning.

Why it was rejected? :(

By the way, this can happen also now (it just happened to me): I 
opened a message and while reading it, several new messages arrived. 
Opened message ends down so it wasn't in message list. The close 
button in preview should be added anyway (in current implementation, 
it will just close/deselect the opened message not the whole preview).

Attaching example of close button on the preview part (upper right 
corner of the preview).

Very easy solution - create a button in preview part which will close 
the preview and deselect the message (in simple words a standar close 
button). It will just call the same JS as is called when you deselect 
the message in the list.

Using tabs should by cool but, as you already said, it's not going to 
happen in near future. Your argument "feature X is bad because feature 
Y is better but it will never be implemented" is really not convincing 
me to fotget about this. Why not implement something small (i don't 
believe such a change will be much work) which will get at least 
little benefit to users until final solution is created (which we know 
is not going to happen any soon, maybe in several years) ?

Toggling between no preview screen and a preview screen every time you 
select/deselect a message?  That sounds like terrible UI.  At the very 
least it would give you a headache.  This is a *VERY* jarring UI 
transition.  Having this transition happen every time I delete a 
message or switch a mailbox?  Yikes.

Not to mention that what happens when the message you select is in the 
area where the preview should be?  The message list should never be 
scrolled because that is very confusing - the user doesn't know where 
they are in the list (automatically scrolling a list when an item is 
selected is a sure fire way to make users angry).  But the alternative 
is that now the message that is selected is nowhere to be seen, so the 
user doesn't know where they are in relation to the rest of the 
mailbox (or a thread) - part of the benefit of a split-preview view 
(the ability to relate the current message to the context of the 
mailbox).

And I don't see the benefit of having a longer message list.  Not only 
is it harder to process - as the number of rows visible increases, it 
becomes increasingly difficult to pick out individual rows - but there 
is very little gained to the user by providing them this list.  Almost 
all messages that a user typically is interested in appear at the 
beginning/end of the mailbox (i.e. new and/or recent messages).  So 
you are essentially showing more messages, that users are not normally 
interested in, while making it more difficult to read.

The blank preview space is not a major issue since the majority of the 
time the space is not empty - there is a message loaded.  It's not 
about packing the maximum amount of data possible on the screen.   
We've learned in the past (and I have been guilty of this) that this 
is NOT what users want.  There's a reason why our new UI utilizes more 
whitespace and has less information displayed on any given page.

As I mentioned previously, the correct solution would be to implement 
a tabbed interface that would allow people like you to view a message 
fullscreen in the current window at the maximum possible size.  This 
should be the goal we should work towards.

Michael, so what about to change current behavior to one suggested 
here? What is the point of empty message preview part anyway? (=when 
no messages are selected)

It would look like this (attaching images).

I stand by what I said before: I really don't want to see this.  A 
tabbed interface is the way to go instead.  No need to waste effort 
when this is not an ideal solution.

And speaking from a coding point of view - this *is* an entirely 
different view.  viewport.js would have to be heavily reconfigured to 
support.

I think this idea has some charm. It's not a different view, just some 
automatic preview toggle.

I wasn't talking about the new view/mode but only about message 
preview in dynamic mode.

Difference is that popup window is much slower.

Ok, what about to only make a configuration option which will change 
behavior of current message preview? Something like 'show preview only 
when message is selected'.

I have zero interest in maintaining a third view.  And I don't see how 
this proposal is any different than the popup view of the message, 
other than the fact it is not in a different browser window.

The better solution is what has been planned for many many years, but 
nobody has stepped up to fund yet: a tabbed view that does away with 
popup windows for messages (popup compose windows are tremendously 
useful, however, and would remain).

There are two options for message preview in dynamic mode at the moment:
1.) Preview is shown
This is very cool and fast way how to work with emails. Unfortunately 
preview is too small so reading long messages is a pain or it is 
taking too much space when no message is open.

2.) Preview is hidden
Working with emails is slower but you can see lots of them on one page 
in message list.


In other words - both options has it's disadventages. What about to 
make another option, some kind of hybrid preview:
It will be hidden when no message is open, so you can see lots of 
message on one page. Preview will be opened only when you click on any 
message (and will hide again when no message is selected). What do you 
think? I think there's no need for preview to be shown when it is not 
displaying any message.