Closed Bug 452440 Opened 16 years ago Closed 15 years ago

Message Pane should never be blank

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 492158

People

(Reporter: rebron, Assigned: clarkbw)

References

(Blocks 1 open bug)

Details

The message pane should never be blank and same with the message view window.  There should be a message in both or perhaps the message pane should default to the mail start page.
Flags: wanted-thunderbird3?
Totally true, I was just looking at ways to fix this last night and I don't think it will be too difficult.  Here's what I was looking at.

Essentially I think we should be showing a summary like page for new messages.  The blank message view is often caused by switching folders.  When changing folders Thunderbird doesn't know what message to highlight, it could focus the last message (which has some advantages) but then it often means hiding any new messages that have arrived (a common reason for checking folders).

So a summary page could hopefully have a bit of both those worlds in it.  

I think we can show the user a list of message headers (hopefully with some snippets of the body) displaying the last message you were looking at along with this list of new messages in the folder.  This means as you click into the folder you get a summary of what's new in the folder and what you were doing last in the folder.  Making each message listed clickable allows a person to open that message in the message view.

This would also help to remove the preference of remembering the last messages you looked at, see bug 448694.  This can also fix issues that would be caused by implementing bug 218935 ( scroll to new messages after getting messages ), which I think would be a nice feature to have.

I believe there's also a lot of possibility for showing other kinds of meta data information or actions in that summary area.
Flags: wanted-thunderbird3? → wanted-thunderbird3+
There is a case where the message pane going blank, or displaying default content, happens when a User delets a message and the screen change action is the confirmation of the deletion. I have seen quite a few questions from Users in Tb support "Why is the deleted message still showing in the message pane?"

Basic answer is: "At that point Tb does not know what to display next" and is waiting for new User input such as selecting a new message. So I agree, a smarter behavior is desired.  A Tb "Help Tip of the day" page would be a nice option for new installs.
OS: Mac OS X → All
Hardware: PC → All
Here's my summary area ascii art / pseudo code mockup.  This is just a start, I think we can begin including other elements as well beyond the last viewed message and new message.  I've talked with people about a Biff summary, i.e. "New Messages Since You Last Looked".  

.-----------------------------------------------------.
|  if ( last viewed message exists ) {                |
|  Last Viewed Message                                |
|  {Conversation Display}                             |
|     {Message Display}                               |
|  }                                                  |
|                                                     |
|  if ( new conversations exist ) {                   |
|  New Messages                                       |
|  foreach(new conversation) {                        |
|    {Conversation Display}                           |
|    foreach(new message in conversation) {           |
|      {Message Display}                              |
|    }                                                |
|  }                                                  |
|  } else {                                           |
|  /No New Messages!/                                 |
|  }                                                  |
|                                                     |
'-----------------------------------------------------'

The {Conversation Display} is just the Subject of the Message.
The {Message Display} is in the format $PERSON | $BODY_SNIPPET | $NICE_DATE.  The "|" is just indicating columns where the sender and date get enough room to fit and the body snippet fills in the rest.

Here's an example of the layout effect on a single thread message:

Bug 452440 - Message Pane should never be blank
  Bryan Clark  Snippet of the comment...  2 hours ago

Here's an example of what could be done for a busy thread with many replies happening at different levels.  

Message Reader
  Bryan Clark  Snippet of the reply...    1 day ago
  /10 older replies/
  Joe Fox      Snippet of joe reply...  2 hours ago
  Jill Fox     Snippet of jill reply...   2 min ago

This would be a good place to experiment with different ways of summarizing a mailbox and displaying messages.  Also other additions such as "Next Message" could make sense in the delete scenario that Ronald mentioned.
Currently A User has a choice in Options/Preferences General Tab to activate a Start Page, and if done to insert there own URL if they do not want the Tb defaflt  "welcome" page.

I would like to see any new concept like Comment #3 offered as a choice on a 
Drop Down list in the manner of Fx 2.0x. That the list offer about:blank, about:config, other about: items, as well as the traditional Start Page in addition to the new concepts. I feel We should keep the existing URL box as it can pull in a page from a web server.

That said, here is another concept. Split the message pane up into a set of <iframe> zones and permit a user to assign a URL to each zone. That way they can tile static and dynamic content. Perhaps a favorite blog together with the Mail Summary info.
xref: bug 454829 - thread summary page on collapsed threads

in bug 454829 comment 2 I'm starting to refer back to this bug where the folder is just a selection of messages which need a summary in the message reader.
Blocks: 454829
No longer blocks: 454829
I'd like to state that I strongly disagree with the premise of this bug.  Why is a blank pane so undesirable?

The pane should represent the message selection.  If one message is selected, that should appear in the message pane.  If no message is selected (I run with "Remember last selected message" turned off), the pane should be blank.

If multiple messages are selected, see my comment at bug 451251.

There are a number of old bugs about the pane failing to blank when the selection is cleared for whatever reason -- bug 68524, bug 192870, bug 364289, maybe others.


(In reply to comment #1)
> This can also fix issues that would be caused
> by implementing bug 218935 ( scroll to new messages after getting messages ),
> which I think would be a nice feature to have.

I don't understand how this follows.  What if the "last selected message" you're so fond of remembering is buried deep in the pane, but when you select the Inbox there are new messages?  Then you've got a message displayed with no visible selection.

xref bug 364896.
(In reply to comment #6)
> I'd like to state that I strongly disagree with the premise of this bug.  Why
> is a blank pane so undesirable?

Why is it so desirable?

> The pane should represent the message selection.  

Precisely!

> If one message is selected,
> that should appear in the message pane.  If no message is selected (I run with
> "Remember last selected message" turned off), the pane should be blank.

I'm not really following your logic at this point.  Taking your first premise, "The pane should represent the message selection".  It would seem to follow (IMO) that if multiple messages were selected the pane would represent that.
IMO a blank preview pane is desirable because it avoids "information overload".  Some of the suggestions in this bug would duplicate much of the information that's already available in the message list (e.g. Senders, Subjects) into the preview pane.

I think it would be better to leave the preview pane alone and concentrate on improving the message list (e.g. having it automatically scroll to new messages, show the first sentence of each email after the Subject (like Gmail does), etc.).

I don't think the preview pane should do two different things (i.e. show the current message sometimes and show a folder summary other times).  If you're going to show a folder summary then it seems better to have it replace both the message list and the preview pane like how the Account Summary fills the screen (when you click on Local Folders or an account name).

Also, when a user has selected multiple messages, he is most likely very aware of the content of those messages and intends to mark/move/delete them.  I don't see any benefit of trying to summarize what the user already knows.  I like Mike's suggestion to show a selection count, but even that would be better put in the status bar IMO.

I also wouldn't want to see a summary for a folder that contains no messages (even if its children contain messages).

In any case, please make the proposed behavior optional.
(In reply to comment #8)
> IMO a blank preview pane is desirable because it avoids "information overload".

a non-blank screen doesn't have to display a lot of information


> I think it would be better to leave the preview pane alone and concentrate on
> improving the message list (e.g. having it automatically scroll to new
> messages, show the first sentence of each email after the Subject (like Gmail
> does), etc.).

no necessary to choose only one focus
 

> I don't think the preview pane should do two different things (i.e. show the
> current message sometimes and show a folder summary other times).  

It bothers me that often preview is blank when something is should be there and I am waiting, until I realize "oh, it's not working".  Often this is the result of a bug or transient protocol failure, but it does bother me.  If the space was never blank when nothing is in progress, i.e. content when "idle" then there would be less question as to whether something really is in progress. 


> If you're
> going to show a folder summary then it seems better to have it replace both the
> message list and the preview pane like how the Account Summary fills the screen
> (when you click on Local Folders or an account name).
> 
> Also, when a user has selected multiple messages, he is most likely very aware
> of the content of those messages and intends to mark/move/delete them.  I don't
> see any benefit of trying to summarize what the user already knows.  I like
> Mike's suggestion to show a selection count, but even that would be better put
> in the status bar IMO.

that's too far out of view IMO
(In reply to comment #7)
> (In reply to comment #6)
> > If one message is selected, that should appear 
> > in the message pane.  If no message is selected (I run with
> > "Remember last selected message" turned off), the pane should be blank.
> 
> I'm not really following your logic at this point.  Taking your first premise,
> "The pane should represent the message selection".  It would seem to follow
> (IMO) that if multiple messages were selected the pane would represent that.

You seem to be reading my "no message is selected" as equivalent to "multiple messages [are] selected."  I mean, when ZERO messages are selected, the pane should be blank.  I'm not interested in any "home page" display or anything like that; and that is why I disagree with the "never" in this bug's summary.

Also, as stated (in agreement with comment 8), I don't like having the last selected message "remembered."  So, for me, often there will be zero messages selected.  See also bug 353057.

I'm completely in favor of some sort of display in the pane when multiple messages are selected, so long as that display is distinguishable from a single selected message.
Just wanted to make a note that this summary page becomes a great place to show other folder information like size and total message count.  Also we can offer actions for viewing the folder properties dialog.

Another point from IRC was that from this summary page you could launch a dialog for viewing all the folders size usage (similar to the outlook dialog).
(In reply to comment #11)
> Just wanted to make a note that this summary page becomes a great place to show
> other folder information like size and total message count.  Also we can offer
> actions for viewing the folder properties dialog.

How much redundancy of size and counts will exist with this proposal?  We currently have Cols in Thread Pane and Folder Pane by use of the Col Picker widget. I will say, this may resolve some issues of Bug 297853 where l10n text translations make Col Header labels "..." not the label.
> How much redundancy of size and counts will exist with this proposal?  We
> currently have Cols in Thread Pane and Folder Pane by use of the Col Picker
> widget. I will say, this may resolve some issues of Bug 297853 where l10n text
> translations make Col Header labels "..." not the label.

Those columns are only exposed if you select the option in the Advanced section of the preferences; then add the size and count columns to the tree.  That could be redundant for some, but no for many; certainly not for everyone.  In the folder summary page this display could be available for everyone to see.  Likely it will not be bold, large, and on top but it should always be available.
(In reply to comment #13)
> > How much redundancy of size and counts will exist with this proposal?  We
> > currently have Cols in Thread Pane and Folder Pane by use of the Col Picker
> > widget. 
> 
> Those columns are only exposed if you select the option in the Advanced section of the preferences;

True for Account level numbers.  The Thread Pane can show Cols per thread and is not subject to the Options > Advanced pref checkoff.

> the folder summary page this display could be available for everyone to see. 
> Likely it will not be bold, large, and on top but it should always be
> available.

Things like Bold, italic, etc. are userChrome tweaks if the properties are exposed.
Blocks: 327828
I think should probably be a duplicate of either bug 492158 (folder summary) or bug 454829 (multiple selection) as they are moving forward and this bug is more like a meta bug to each of those.  suggestions?
could dupe it to 492158 since it looks like the work is being done there.
done
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.