Hi, I have some designs for a new message reader / view pane. First, I'm going to refer to this as the Message Reader, the thing that lets you read a message. The basic principle involved here is to pull all message related content and actions into the message itself. Note in the expanding headers example where additional headers are filled in as the person clicks "details" http://clarkbw.net/designs/msg-reader/std-msg-reader-w-expanding-headers.html Headers, more headers, and buttons are located directly on the message itself. The current message view pane only has scrolling for the message body itself while the headers and actions are treated separately without scrolling. This new view places an outset and rounded border around the edge of the message to give it some depth and scrolls all the elements together. I'll be creating a wiki page for the message reader, replacing the current ( http://wiki.mozilla.org/Thunderbird:Message_View ) one of examples and using it for more definitions and bullet points instead.

AFAICT, this probably depends on the auto-height iframe, assuming in particular that we want to keep the header stuff in trusted content (e.g. an iframe with chrome privileges) and the message body in an untrusted iframe.

Let's talk about this once bug 80713 is fixed.

That makes sense if that bug indeed blocks this one. Ben, can you confirm that it does?

Yes, it does.

How can I vote against this bug? I don't want the headers to disappear when I scroll the message.

(In reply to comment #5) > How can I vote against this bug? Not sure it's possible. You might have to file a feature request against bugzilla. > I don't want the headers to disappear when I > scroll the message. Why don't you want the headers to be in the message? They are still there when you scroll back up and much of the information is also mirrored in the thread list.

(In reply to comment #6) > (In reply to comment #5) > > How can I vote against this bug? > > Not sure it's possible. You might have to file a feature request against > bugzilla. yeah, bug 48570, I've voted for that one, but AFAICT there isn't much being done about it. In 2006 latest, the devs were debating whether it would be a useful feature or not. Seems to be in the fridge since then. > > > I don't want the headers to disappear when I > > scroll the message. > > Why don't you want the headers to be in the message? They are still there when > you scroll back up and much of the information is also mirrored in the thread > list. > The thread list is much less detailed, it isn't there when I'm viewing the message in its own window, it doesn't include, for instance, the useragent string (which about:config allows me to include in the displayed headers if present), it also doesn't include links to the email addresses (which I can right-click, then "Copy Email Address" to get them into the clipboard). As it is, a mere flick of the eyes is enough to show me the header info I want, however far down in the message I might be. If I have to scroll, I lose my place down the text and have to find it again. If ever you decide to include this (mis)feature, _please_ make it possible to disable it.

Hooray! In general this is just what I wanted in the older bug. However, there are some benefits to also being able to keep the headers at the top. I don't think it is black and white, but possibly a small checkbox to "lock headers" somewhere is in order... or maybe there is something cleverer that can be done....

Just FYI, it was always intended to make the message headers scroll. The fact that this was implemented differently was only due to technical constraints. In other words, that message headers scroll was always a bug, not a feature. I understand that some people consider it useful to have the headers always visible. It will be hard to make that optional, as we'll change the window structure, but it may be possible with CSS tricks like position: fixed.

Correction: I meant "that message headers *do not* scroll" of course.

Yes, this new design isn't to solve the problem of scrolling headers; even though it helps with that. But we could have just addressed that bug by itself. As for always having the headers visible I think we can address the issues individually with the new design. It's not perfect or finished yet but I think it will be a great improvement over the current view.

To be blunt, this new design is probably unacceptable for people who dislike webmail because it looks just like webmail, I don't understand why I should even use Thunderbird or SeaMonkey if what I get looks just as sucky as webmail does.

Robert, being blunt isn't all that it's cracked up to be. It would be good if you could explain, beyond "looks", what you don't like about the design. There is more here than looks. Also, words like "sucky" really don't help.

This so-called bug is all about looks and nothing else. What _I_ don't see is what you think is so great in having the headers go away as soon as you scroll the text; and phrases like "it was always intended" really don't help -- at least, they aren't going to help me understand your POV.

Tony: Please read the history of bug 9942 to get some background. It is not about looks. In brief summary: - the headers take up a lot of screen space that is only useful occasionally (most of the time one is reading the message body, not the headers). - you cannot select and copy the headers, or even just names from the headers - it is more common with other mail clients (hence expected) However, there may be some scenarios where headers always present are better. Please *explain* them, don't just flame about this change being bad.

Tony, it's crystal-clear that many, if not most people prefer the header pane to scroll. That's what bug 9942 is about. There are many comments there, and some reasons for it mentioned, and even a screenshot: https://bugzilla.mozilla.org/attachment.cgi?id=116330 To sum up: - The main window may be so small (screen size, window size etc.) that the msg body gets almost no size (after folder, thread and header pane). - The headers may be so big (due to "show all headers" - see screenshot - or just lots of recipients or recipients with long names and email addresses - see bug 56825) that the msg body gets almost no size. - Many people feel that once they read the headers, they don't need to constantly see it and would prefer to have a larger visible area for the text display. You may disagree, and I accept that, and as I said, if I implement scrolling headers, I will try to keep your concern in mind and allow the headers to be optionally fixed (non-scrolling), so I don't see a need to argue over this point. But there are serious technical problems with the current solution that all would be fixed very seamlessly and without UI hacks by making headers scroll with the body. (FWIW, my personal opinion is somewhere in the middle.)

Maybe this discussion would be better served in a newsgroup, but here are a few comments: NC 4.x scrolled headers with the message body, and I don't remember many folks having a problem with that. Tony, Everybody has there own special workarounds and use cases. If I am interested in headers (support groups etc) here is what I do: Expand headers in the preview pane. Open the message in a "new standalone" window. That way you see no headers in the standalone window, and a simple click shows them in the preview pane. Clark, I am assuming the samples are "concept only" So the new reader would be 100% of the viewport..Yes? Would it be applied to the preview pane, standalone message pane..both? What would you do when there are many image attachments ? Another overflow auto situation with a fixed height. Would you be computing the image thumbnail sizes per image. Percentage won't work here, someone is going to attach a jpg right out of his camera at native resolution. What about the menu bar and toolbar, do you plan to try to incorporate some/all into the new view. View->attachments->inline should always be kept as an option.

Correction: Sorry Bryan for that name snafu (I have a few friends with the first name Clark)

Yes, it's intended to use the entire viewport space. What is shown in the concepts would be about the size for an 800x600 thunderbird window. It's intended to be used as the standard way to view a message. For many image attachments we'll need to have an algorithm for stopping the inline display so the message doesn't run on too long. Also some work needs to be done on the attachments group action area such that it has a reasonable set of actions that can be done to the group of attachments as a whole. The image sizing problem is one that lots of web sites (social networks) face and the general solution is that you take a hard line on the dimensions. With the max-(width|height) CSS styling you can generally control things. Also, one more thing to bring up about image sizing is that it's worthwhile to use a larger preview of single attached image. This is about looks, but also usefulness; if someone sends a singe image attached we might as well allow it to take up a larger portion of the message space with the preview. Much of the toolbar items are going to be redundant to the actions available in this new message reader so that will have to be looked at. But the toolbar changes, if any, should be a separate bug. That's about the only integration points I see with the toolbar and menu bar. Just to note that there are other designs up: http://clarkbw.net/designs/msg-reader/ Some are not as far along as others like the attachments display being worked on. ( http://clarkbw.net/designs/msg-reader/std-msg-reader-w-image-attachments.html )

(In reply to comment #15) > Tony: Please read the history of bug 9942 to get some background. It is not > about looks. In brief summary: > - the headers take up a lot of screen space that is only useful occasionally > (most of the time one is reading the message body, not the headers). - The boundary between message list pane and preview pane is movable - in the message window, the lack of screen space is not so extreme (and IIUC, the preview pane is just a frame with a message window in it: AFAICT anything that applies to the one applies to the other, except the binding with the selected message in the message list pane) > - you cannot select and copy the headers, or even just names from the headers oh but I can, in Thunderbird 2.0.0.17pre and SeaMonkey 2.0a1pre both: drag the mouse then hit Ctrl-C, or right-click a name then "Copy Email Address". I even mentioned this in comment #7. This is of course in the not-yet-scrolling headers above the message body, not in the message list pane. Here are the builds I just tested it with: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.17pre) Gecko/2008081103 Thunderbird/2.0.0.17pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a2pre) Gecko/20080811001340 SeaMonkey/2.0a1pre > - it is more common with other mail clients (hence expected) the only non-mozilla non-netscape mail client I ever used (not including webmail) was Outlook Express on W98 many years ago, and IIRC it didn't have headers that scrolled away either > However, there may be some scenarios where headers always present are better. > Please *explain* them, don't just flame about this change being bad. > I try not to flame; in comment #7 (second half) already I mentioned several arguments. In reply to comment #17: In the standalone message window I _most certainly_ want to see the headers at all times; there there isn't such a lack of real-estate.

P.S. See attachment #333333 [details] and bug 9942 comment#153 showing why IMHO scrolling headers are not really needed. (When I want the full headers including received-lines and everything, which isn't that often, I use View Source.)

There are a lot of different use cases for what headers should be shown. Some people want one set of headers, while others want a different set of headers. It's hard to determine what headers people will want to see in a message. Likely there could be something to configure what headers show when the details are expanded.

I can't comment on the visual designs, but making this a whole HTML based interface will solve a lot of accessibility problems with many of the headers such as accessing them, getting the header type properly associated with the header's content, and getting easy access to the attachments. A few requests: - Make each header focusable (tabstop). - Make each address a link or something similar so actions on it can be performed easily and it can be focused. - Make the message body easily discoverable. many screen readers offer ways to navigate to headings. So if it is made sure that the subject always preceeds the message body in the markup, make it a heading 1 from a markup pov, so screen reader users can quickly jump to it, skipping all header information if they're not interested in them right now. - Make other parts also be exposed as headings, for example the Attachments section.

I don't think it's planned to make the headers HTML-based. The headers will still be chrome and XUL like they are now, just scroll with the message and maybe have a bit different layout.

While I see the argument of "real estate" in the 3-pane view, I'd definitely agree with retaining the headers visible all times in the stand-alone message window. The thread list in the main window gives the reference to the message currently viewed, whereas there is no such reference in the stand-alone window at all, thus causing ambiguities. For its relevance in the main window, keep in mind that most people would look at the messages with Headers > Normal setting, and the addresses are collapsed to a single line by default when opening the message, thus this case would only apply for the expanded headers. > (comment #0) and buttons are located directly on the message itself. > The current message view pane only has scrolling for the message body itself > while the headers and actions are treated separately without scrolling. Well, the fact that action buttons are "floating" with the message in many web mail applications is what I particularly dislike, due to the lack of a fixed reference point. Right now, when I want to delete a message or reply to it, I know where that button is and would find it with closed eyes (almost). If you make that part of the message, you start searching for the action buttons as their locations are moving based on message size and any scrolling = not good.

Sorry about comment #12, non-constructive comments are not what such a bug needs. 1) Duplicating the functionality that we already have in a toolbar in the mail body sounds redundant and therefore unneeded to me. 2) Displaying our own UI stuff (headers, delete attachment, buttons, etc.) in the HTML body pane instead of XUL where the normal theme applies is confusing as it looks like this would all be stuff the sender of the mail created, and it's _very_ easy to forge and do bad things there. Not to mention that if people want such a non-native-themed look of their mails they can use webmail all along and don't need Thunderbird or SeaMonkey at all. 3) Not displaying headers like From/To by default is confusing because even if the threadpane is shown (which doesn't have to be the case, see e.g. standalone message window), it only shows parts of that info, while the full Name+address for both, in addition to e.g. CC is important to determine e.g. if this was directly to you or as a part of a mass mail or just goes to you for notice (CC). Also, I have people in my communication that use several email addresses (e.g. home/work) and determining from which of those they sent can be important for determining the relevance of the mail. There are a few interesting ideas that come with this, like placing functionality like reply/forward (I guess "Archive" is thought to be instead of "File v" with some naming inaccuracy) nearer to what they apply to, but there are a number of potential problems with the current design, I esp. think that mixing UI and content that heavily calls for major problems in terms of forging and user confusion, not to mention themability.

> if people want such a non-native-themed look of their mails they can > use webmail all along and don't need Thunderbird Bryan and David A., that's something to seriously consider. Webmail is considerably easier to set up, faster to use etc.. If we want to convince people to use Thunderbird, we need to be *clearly*, also *visibly* better. Better also means different. For me, the native widgets and UI were always a prime reason to use local client. It's much clearer to me, faster to see with one glance all the important info, much more efficient window handling etc.pp. I don't want to argue against any particular proposal, just against the idea of making Thunderbird look like webmail. It should be vastly different and vastly better, on the first glance. That may well involve stealing some ideas from webmail, but not outright copying things that webmail does because it's a webpage. Thunderbird should not look like a webpage. I do think that a Reply button in the header pane makes sense. It's closer to the message, i.e. visually connected to what it applies to.

Sorry, should have read KaiRo to end before replying. I completely agree with everything he said, apart from 1).

Is the plan to remove the action buttons, like 'reply', from the main toolbar? I would have a problem with that, because for a lot of mails, I have to scroll to halfway through them. That's where the content ends. The rest is quoting of old mails. But in that case, the action buttons are gone at the moment that I need them.

(In reply to comment #27) > > if people want such a non-native-themed look of their mails they can > > use webmail all along and don't need Thunderbird If people do in fact want the Webmail look (and it's not clear to me that they do) perhaps this concept could be developed as an alternate selectable theme. ... but not outright copying things that webmail does because it's a > webpage. Thunderbird should not look like a webpage. I think you might mean "webmail window" here ? because certainly Gmail does *not* render messages as in a webpage. The Gmail message window will not even paint a background color on an html composition, which makes for some interesting problems for text visibilty. Thunderbird's strength is it's ability to truly render the message in the the format that the "viewer" desires. View message body as..Options provide those nicely. Plaintext, Simple html, Original html. Gmail uses JS to show you a sanitized view, with very few options. > I do think that a Reply button in the header pane makes sense. It's closer to > the message, i.e. visually connected to what it applies to. > I agree, that would be handy.

http://clarkbw.net/designs/msg-reader/std-msg-reader-w-expanding-headers.html Some concrete proposed changes to: 1. (most important) What's called "details" should be the default. That solves a lot of the problems mentioned above. It also avoids the 3-times folding: minimal headers -> details -> momo details (22 headers still not shown) -> view source 2. Remove "mailed by". I don't think it helps a normal user, even I'd have limited use for it. It's a good idea for a "more details" view, though, if you can automatically and reliably (!) pick the last server before mine. 3. Date in ISO "Thursday, 2008-10-23 23:10" (is easier to read), or "yesterday 23:10"/"today 14:13" 4. Keep the email address small in all cases, even when not in addressbook yet. Makes the whole recipients easier to read, but still shows it. 5. Remove most of the buttons. 5.1. Do not put buttons in two places and styles, that was confusing me (Reply/Forward vs. Redirect etc.). 5.2. "View source" is only interesting to people who routinely use the menu. 5.3. What does Archive do? How is it different from "Move"? How does it know which folder to move to? Or does it keep the msg in the same folder, with a flag? 5.4. "Move" and "Copy" don't really work in a user-friendly way, esp. if you have many folders, because you'll need to select a folder, maybe even in a hierarchy. Drag&drop is much more efficient here. 5.5. As an alternative, maybe do put in a "proxy icon" (like the favicon in the browser) which I can drag, though! The proxy icon could replicate what we show in the thread pane, just bigger: whether it has attachments, whether I replied etc.. This is important information. 5.6. "Edit as new..." is very rarely used, no need for a toolbar button. 5.7. "Redirect" is needed only for very few people and should only be used internally. Most people won't understand the difference to Forward. Better allow toolbar customization. In any case, don't put it in by default, potential for confusion and abuse ("No, I didn't send the mail to that guy, I swear!") is too big. 5.8. Delete should stay, but be bigger. 5.9. Mark as Junk should be added, in a way that I can't accidentially click. 5. Summary: Keep only Reply, maybe Forward, Delete and Junk buttons. Add a proxy icon instead of Move, Copy. Remove or make clearer what Archive does. 6. If I replied to a mail, add a link to the reply. Also add a link to the parent (the msg this one is a reply to). That probably depends on "gloda", though (being able to open an arbitrary message in the store, no matter in which folder it is). 7. The S/MIME / GPG "signed" marker must be next to the sender. a) because that's what it verifies and b) I completely missed it unless I saw "S/MIME" in the description and searched for it.

(I forgot:) I would not replicate the list of attachments at the top, though. If we have a proxy icon showing that there *are* attachments, and showing them at the bottom, that should be enough. After all, physical "attachments" always come after the cover letter. Same as with the message buttons - I actually count 3 places now, there should be only one place, below the headers in the header pane. What I like about it: - The border with rounded corners, although I'd make it only around the body, not the headers. - Still grey background behind the headers, makes it clear that it's different from content and added by the app. - As said, having the most important action buttons for a message right next to the message is very good GUI. - The small email address are a good idea. They visually unclutter *a lot*, make it much easier to parse with the eyes, but still keep the information there without extra work. - Attachments Showing the details and actions right next to the inline image is a great idea, again great GUI (same as with Reply button). I want to save *this*, not hunt for the filename and context menu somewhere else.

(In reply to comment #25) > Well, the fact that action buttons are "floating" with the message in many web > mail applications is what I particularly dislike, due to the lack of a fixed > reference point. Right now, when I want to delete a message or reply to it, I > know where that button is and would find it with closed eyes (almost). If you > make that part of the message, you start searching for the action buttons as > their locations are moving based on message size and any scrolling = not good. So, I think perhaps we should be making it more obvious that there are hotkeys available for many of these actions. Like, aggressive tooltips over the buttons that spell out "you can push control-R to reply" until it's clear the user knows them. (And ideally dropping the control-key modifier.) I think people are more likely to become adept at locating a key on the keyboard with their eyes closed than toolbar items with a mouse which aren't at the edge of the screen. (also in reply to comment #29) > I would have a problem with that, because for a lot of mails, I have to scroll > to halfway through them. That's where the content ends. The rest is quoting of > old mails. But in that case, the action buttons are gone at the moment that I > need them. This is a very good point. The good news is that it is within our power to detect the quoting and collapse it.

(In reply to comment #33) > (In reply to comment #25) > > Well, the fact that action buttons are "floating" with the message in many web > > mail applications is what I particularly dislike, due to the lack of a fixed > > reference point. Right now, when I want to delete a message or reply to it, I > > know where that button is and would find it with closed eyes (almost). If you > > make that part of the message, you start searching for the action buttons as > > their locations are moving based on message size and any scrolling = not good. > > So, I think perhaps we should be making it more obvious that there are hotkeys > available for many of these actions. Like, aggressive tooltips over the > buttons that spell out "you can push control-R to reply" until it's clear the > user knows them. (And ideally dropping the control-key modifier.) I think > people are more likely to become adept at locating a key on the keyboard with > their eyes closed than toolbar items with a mouse which aren't at the edge of > the screen. I disagree with this. Some people just are not adept at using/remembering hotkeys. Some people are for certain things but not others e.g. I use hotkeys all the time in emacs when I'm developing, but I very rarely use hotkeys in an email client. This is possibly because its generally been a mouse driven program, but some people will still use it that way. Using webmail where you have to scroll to the start or end of the message to get to the buttons just sucks. I'd also like to know the reasoning of why we're removing these from the toolbars? and/or what will the toolbars/menus be used for in the end. I don't think we should impose using a specific method of interaction with our program. Offer a few, balanced ways, whilst keeping the UI simple. Keyboard for accessibility/those who can remember all the buttons/have time to learn the options, mouse for those who are more visual and a mixture for those who like to do both depending on what they are doing. Making mouse actions harder, and saying use the keyboard, IMHO will discourage people from using it.

(In reply to comment #34) > I disagree with this. Some people just are not adept at using/remembering > hotkeys. Some people are for certain things but not others e.g. I use hotkeys > all the time in emacs when I'm developing, but I very rarely use hotkeys in an ... > I don't think we should impose using a specific method of interaction with our > program. Offer a few, balanced ways, whilst keeping the UI simple. Keyboard for > accessibility/those who can remember all the buttons/have time to learn the > options, mouse for those who are more visual and a mixture for those who like So, I'm not saying that Thunderbird should require keyboard usage. But I think it is useful to help users gradually learn potentially faster ways to do things. Right now, you find out about the keyboard shortcuts if you go to the menu and find "reply". But most people are only ever going to click on the "reply" button on the toolbar (whose tooltip says nothing about the hotkey, at least by default). They won't be exposed to the hotkey, they don't have the opportunity to learn about the hotkey, fulfilling the prophecy that people don't use hotkeys.

(In reply to comment #35) > So, I'm not saying that Thunderbird should require keyboard usage. But I think > it is useful to help users gradually learn potentially faster ways to do > things. Right now, you find out about the keyboard shortcuts if you go to the > menu and find "reply". But most people are only ever going to click on the > "reply" button on the toolbar (whose tooltip says nothing about the hotkey, at > least by default). They won't be exposed to the hotkey, they don't have the > opportunity to learn about the hotkey, fulfilling the prophecy that people > don't use hotkeys. Now that I do agree with. Though I'd still like to see a discussion about the placement of the buttons, and I've just realised a good example, bugzilla. How many times do I want to go onto a different saved search or open a search page etc and I'm not at the top or bottom of a page... My right hand is on the mouse, my left hand tends to stay on the left side of the keyboard and doesn't make it across to the home/end/page up/down buttons.

I don't think the placement of the buttons, them scrolling away, is so much a problem, because we don't need to make them scroll away. Currently, headers are fixed. This can't be changed until bug 80713 is fixed anyways, and even then we may conclude that it's better to keep at least the most important headers (full subject, sender, maybe date, and the reply and delete buttons) visible at all times, i.e. non-scrollable. I'd like that. I'd also want to have the recipients list and maybe a few others visible by default, but that may scroll (and it has a good reason to, because it may be long). The only problem I see with that is that we'd then have some headers scrolling and some fixed, which is very strange and inconsistent. That's why I don't know how to do it in the UI.

wow, lots of stuff! (In reply to comment #23) Marco, thanks so much for the feedback! I think the best thing we can do to keep moving forward is to keep posting early layout designs so we can be sure that we're moving in the right direction as we create the new layout. (In general to toolbar vs. inline actions) Locating the buttons directly on the message they are affecting vs. another area is a generally good move. When the action buttons are insensitive/sensitive depending on where the focus has moved is confusing to many people and wastes space that could be used for better instruments. (Toolbar redundant) Having the actions on the message does tend to make the actions on the toolbar redundant. However until we've fully resolved a decent making the actions on messages available enough we can't focus on the toolbar. But I do think removing the message action buttons here will allow us more space for better things. {further discussion for later and likely in another bug} (Headers XUL vs. HTML) I'm not sure which way the technological choices are going to move, I think those decisions need to be based of pure engineering reasoning based off what we think is best for our users. I think it's a dangerous trap to trust that XUL is a more secure display format than HTML for our users. A message can be created with parts that look like XUL in it and most users won't know the difference because they don't understand the difference. Themeing support is something that certainly needs attention as we work towards a new solution and I think that using HTML parts will make themeing different, but not impossible. This is an engineering decision, if we can create the type of view we want for our users and not use HTML then that's what we do. (Showing specific email from address) I think we can work out ways to make the email address a message is coming from more obvious. If you've seen the latest version of the expanding headers you'll see how they've been incorporated into the details view. There is a solution here that isn't difficult. (The web mail look) I don't think there's a "web mail look", if you examine msn, hotmail, yahoo, and gmail they all have different views and looks for many different pieces. Even if there was a specific look I don't think it's what we want to aim for. We are not copying any one of these systems, we may look at pieces they use, but it would be ridiculous to attempt to copy any one of these systems. Thunderbird has a goal of representing messaging or communication to people in an understandable way; that does not necessarily translate into Thunderbird needing to look like a client application (or web mail). Our goal is to serve the users, whatever look we choose is for their benefit not the computer or operating systems. (What headers to show) I think we can have a separate bug to determine what headers are important for a details type view. I chose some I thought were interesting, however I admit the list I chose does not have much thought in it. Most of my time was spent on the collapsed view and would love to defer the important headers to someone more knowledgeable in that area. (Archive button) I think we can create a system for archving mail in thunderbird. This bug isn't the place to discuss it's objectives, in the mockups it's meant to show another type of message specific action like trash, reply, and forward. (Access keys) I've been trying to develop a better system for access keys. Take a look at the following for a possibility. (scroll to bottom) http://clarkbw.net/designs/msg-reader/std-msg-reader-w-access-key-buttons.html Of course this (like the others) isn't a final layout but a discussion point for change. A great point is made about access keys and how they aren't discoverable unless people open up the menus. I'd like to see us create a system where people can learn access keys as they use Thunderbird by showing them the access keys that perform actions as they are performing them. There seems to be some kind of CSS bug that doesn't render my :first-letter { text-decoration: underline; } properly. Otherwise you'd be able to see the modifiers on the link actions. (Duplicate Buttons) I'm using two sets of buttons for each message because it's important to not have buttons distracting from the content up at the top of the message where a person's eye is going to scan. Therefore at the top I placed link actions to make certain primary actions more available. Obviously we don't want to require that everyone scrolls to the bottom of every message in order to reply, but for many people (especially those who are socially emailing and not in a very large discussion thread) I believe the bottom of the message is going to be an excellent place for these buttons. The buttons provide an obvious visual break from the message (which they would destructively do at the top) and allow people to find the buttons they might not have seen at the top. (Buttons unavailable in the middle of a message) I think there is a solution here that isn't reverting back to the existing view. Obviously keyboard access keys are going to be available at any point while viewing a message so it's during mouse motion on the message that we need to think about a new way to make a set of primary actions visibly available. I'm wondering what others have for ideas here, I have one of my own that I'm working on. I'm glad there's lots of discussion happening here and it's all moving in a positive direction. Obviously what I have in HTML mockups isn't finalized... there are still many bugs with the current message view. :) But it's good to talk about what we can do better.

(In reply to comment #27) > I do think that a Reply button in the header pane makes sense. It's closer to > the message, i.e. visually connected to what it applies to. (If and) when SeaMonkey gets drag-droppable buttons like Fx & Tb, it ought to be no big deal to give the message pane a customizable toolbar. (In reply to comment #31) > 3. Date in ISO "Thursday, 2008-10-23 23:10" (is easier to read), or "yesterday > 23:10"/"today 14:13" Currently, the date format is governed by the locale, which IMHO is a GoodThing™. I can launch the mailer as "LC_TIME=en_DK Thunderbird" to get ISO dates, or as "LC_TIME=en_GB Thunderbird" to get DD/MM/YYYY, or I can choose other settings to intentionally get weekday names in some language which isn't my computer's default. (Note: This is on Linux. I don't know whether Thunderbird checks the LC_TIME environment variable on e.g. Windows but I think it might be a nice touch.) -- A few "config editor" settings allows three formats for datestamps: e.g. "hh:mm" for today, "Weekday hh:mm" for this week, "yyyy-mm-dd hh:mm" for other than that (assuming en_DK). No "Yesterday" yet though but is that so important?

oops, I got confused. It _already_ ought to be no big deal to give the Tb message pane a customizable toolbar.

> Most of my time was spent on the collapsed view Yes. But I think it doesn't show what people need to see, specifically the full list of recipients (which has important social implications) etc.. Because of that and because of the layout (it's *good* when the headers are visually different from the body), and because of 4 levels of "expanding", I argued that the details view should be the default. See comment 31, first sentence.

Tony: date format: Agreed, following locale should be OK.

Clark: What you have not addressed yet (and what I one of my main concerns) is the forgery problem with mixing UI and content (inlining _any_ UI _in_ the message calls for those problems right away, people _need_ to be able to determine what's message content and what's UI from the application). What are your thoughts about that?

(In reply to comment #41) > But I think it doesn't show what people need to see, specifically the full > list of recipients (which has important social implications) etc. This is why I filed bug 381491 after 1.8.1 releases came out, which is still unconfirmed, but I figured it's embarrassing to confirm it myself now. ;-) The full details view may be overdone, but it certainly would be helpful already if expanding the headers would "stick" and applied to subsequent messages, so that the full list of recipients can be seen. Or, make it configurable as I suggested in that bug. (In reply to comment #38) > Locating the buttons directly on the message they are affecting vs. another > area is a generally good move. When the action buttons are > insensitive/sensitive depending on where the focus has moved is confusing to > many people and wastes space that could be used for better instruments. I don't quite see the confusion factor here, the buttons are at specific locations on the toolbar and become active or inactive as needed. This is commonly done in many other applications. The idea in comment #39 to treat the header section as toolbar, thus to allow users to move any buttons they would like to see closer to the message and scroll with it there themselves. The default should IMO be that they remain in the main toolbar as has been, to avoid too much confusion when people switch to the new version and find them at unfamiliar locations. > (Comment #43) forgery problem with mixing UI and content I just wanted to get to this, mid-air collision with KaiRo. Spammers are already spoofing broken-image icons to make people click on them for hardening spam status or directing to malicious web sites, so that would be inviting.

(In reply to comment #41) > > Most of my time was spent on the collapsed view > > Yes. But I think it doesn't show what people need to see, specifically the full > list of recipients (which has important social implications) etc.. Because of > that and because of the layout (it's *good* when the headers are visually > different from the body), and because of 4 levels of "expanding", I argued that > the details view should be the default. See comment 31, first sentence. There needs to be continued work on the indications of who a message was sent to, right now it isn't in a state I'm happy with either. However to me this does not mean that we need to create a strong visual break of headers from the message or expand the headers by default. It may mean that we need an alternate layout of the headers from what exists now. (In reply to comment #43) > Clark: What you have not addressed yet (and what I one of my main concerns) is > the forgery problem with mixing UI and content (inlining _any_ UI _in_ the > message calls for those problems right away, people _need_ to be able to > determine what's message content and what's UI from the application). What are > your thoughts about that? There is a clear and distinct white space break from the message and the headers at the top. As well as the message content and the buttons at the bottom. These could use some improvements and will likely be modified as we iterate. However there isn't any mixing of UI with the message content in current mockups. Also the message content can never replace the UI elements that wrap it around the top and the bottom. I can understand a worry that buttons near the message content could confuse people, but the threat is just as real now as it would be in a new view. An assumption that because our buttons are in the toolbar means people couldn't be tricked by buttons appearing in the message is a false one. The problem of forgery will continue to exist and the distance of buttons from the message content is not proportional to the security against forgery it provides. That is a different set of difficult problems to solve.

> I can understand a worry that buttons near the message content could confuse > people, but the threat is just as real now as it would be in a new view. No, it's not. In current Thunderbird, the message header pane and esp. the toolbar buttons are very clearly and visually separated from the message body. I think that's a concept that will get across to even users with little background. If you routinely put the buttons and headers next to the body, and don't make the visual separation extremely clear, and ideally do it in a way that can't be forged, you're opening the users to confusion that phishers can use. Right now, it's almost impossible to phish in the mail client directly. All phishing tries to target the browser. I think it has something to do with the UI, too, and that you're now making it much easier for phishers to pose for mail UI and confuse people with buttons like "Reply" etc.. As said, I think putting Reply button near the msg is a good idea. But please don't confuse mail reader UI with message content. They should be clearly separate and distinguishable. Anything else is just confusing for users, even without outright attacks, because it blurs concepts, which always leads to confusion.

(In reply to comment #44) [...] > The idea in comment #39 to treat the header section as toolbar, thus to allow > users to move any buttons they would like to see closer to the message and > scroll with it there themselves. The default should IMO be that they remain in > the main toolbar as has been, to avoid too much confusion when people switch to > the new version and find them at unfamiliar locations. [...] Yes, that's what I meant when I made that proposal: have the buttons at top (like now) by default, but allow the user to move them, maybe not to the header bar itself (there might not be enough space, especially when collapsed so that Subject, From and Date appear side-by-side) but to a toolbar just below it, and whose default background would be toolbar-like of course, and themable, not white by default like the message content. Of course, sleazy HTML mails can change their BG color any way they like: that's where it might be important to have several distinct readily-available themes: you can match the default theme maybe (though not necessarily on Windows, Unix and Mac at the same time -- I'm not sure how much the default theme varies from platform to platform) but it ought to be hard bordering on impossible to match all available themes at the same time. I still agree with KaiRo (and a few others) that the header area should _not_ scroll with the message, and all the more so if we (or some user) put buttons on the header area above the message: it's after having read the full message (and got to its end) that I want to maybe reply, or maybe proceed to the next unread message. Of course I can use Ctrl+R or Ctrl+Shift+R to reply, or N for Next unread, but as has been repeatedly pointed in comments above, not everyone is keyboard-minded.

(In reply to comment #46) > > I can understand a worry that buttons near the message content could confuse > > people, but the threat is just as real now as it would be in a new view. > > No, it's not. In current Thunderbird, the message header pane and esp. the > toolbar buttons are very clearly and visually separated from the message body. > I think that's a concept that will get across to even users with little > background. You aren't looking at this from the point of view of someone who doesn't understand the elements that make up Thunderbird. The visual separation is not the point. We could even install physical reply buttons on peoples keyboards and if an evil message placed a reply button inline then people would click on it. Once an evil button appears in the message we have lost the security game. It doesn't matter where the buttons are placed, nor does it matter if the buttons look like they were on a toolbar. A toolbar and it's colors can be faked inside a message. We cannot claim our security comes from our users understanding the difference between buttons on toolbars and buttons not on toolbars. But this point is starting to drag on, if people want to discuss this issue further we need to take this to the thunderbird newsgroup so this bug can stay focused on the reader as a whole.

> Once an evil button appears in the message we have lost the security game. I agree. Means turning on "Simple HTML" by default, which we currently don't. But even then: > We cannot claim our security comes from our users understanding > the difference between buttons on toolbars and buttons not on toolbars. Sorry, but this is strict not true. There can't be security when people confuse application UI with content. That's a lesson we learned for the browser. People must be crystal clear about the origin about certain information (whether it's the app or the content, and if the content, and from whom), otherwise you can't provide any security (because you can e.g. forge the "signed" icon etc.pp., or just *say* it's signed). Of course there'll always people who believe everything, but you can reduce/increase the number 10-fold by making it clear or ambiguous.

(In reply to comment #45) > I can understand a worry that buttons near the message content could confuse > people, but the threat is just as real now as it would be in a new view. An > assumption that because our buttons are in the toolbar means people couldn't be > tricked by buttons appearing in the message is a false one. Please talk to people working on such issues in the Firefox browser UI. The same concepts that work for HTML in the browser can probably applied to HTML (which is what we show by default) in the message UI. There are many similarities there and even if it's different applications, we should learn from our colleagues in the browser space. I guess beltzner, who does UI review for FF, can be a good contact person. Oh, and I don't fully take your argument about forging UI in the current design, as not even the currently common Windows versions have the same theme look, not to speak of other OSes or custom themes, so making a forgery that looks perfect for one system looks awkward for a huge number of other users. And people can easily be educated that anything inside the message pane is content created by the sender of the mail. Once you have things that actually are UI items in there, this gets _very_ difficult.

(In reply to comment #49) > > Once an evil button appears in the message we have lost the security game. > > I agree. Means turning on "Simple HTML" by default, which we currently don't. Right, imo it should be as simple as having displaying inline ui and displaying rich content that can emulate that inline ui be mutually exclusive settings, with a "open fancily formatted msg in separate frame" available or something. That's still a source of some blurring the line, but perhaps not too badly. As for the hints of security defeatism ;) I'd be inclined to run screaming from any ui that would by default on the most mainstream platform, language, and theming be likely able to fool me (or, say, you, you, and you (sorry if I left anyone out)); despite the most-spoofable 80% of the potential userbase being arguably more important, I suspect you all rather feel the same way on that :) Regarding theming or ui language as protection, I think that's pretty weak -- targeting a few of the most common combinations with close enough apperances surely makes for an interesting enough total for mass attackers, modulo marketshare. Diversity can help a bit but it's definitely not something to be relied on at all.

Switching for b1 flags to target milestones, to avoid flag churn.

http://clarkbw.net/designs/msg-reader/v2/msg-reader.html uploaded some new style designs, like the others, these don't yet take a correct palette into consideration. Main point of these changes are to provide an even more distinct visual separation between the headers, toolbar, and message content. The headers and toolbar have also been made wider than the message by design such that the contents of the message can never assume to be the same as the chrome bits. More work needs to be done on the collapsed headers, expanded headers, quick action buttons, and bottom toolbar as many pieces are acting as placeholders.

Bryan, thanks, that's much better. A few comments: - Background color of headers is much better. (I'd avoid changing from white to black font foreground color, though.) - The selection of buttons is much better. - Please keep the buttons all in one place. You currently have 3 places for buttons associated with the message. That's *way* too much and confusing. I think the problem of wanting to click Reply at the end of the msg is solved when we don't make the collapsed headers scroll, but still make the extended headers scroll. I'd recommend to have the first set of buttons on the top right of the collapsed headers, and if you want to hide some buttons, put them on the extended headers, again on top right. This means they are at least close to each other. - I really liked, in your earlier design, having the email addresses in smaller font and grey color, in extended headers. - What happens in the collapsed headers when there are many (dozens) of recipients? This happens quite often in business communication. - I assume the expanded headers "expand" state persists between msgs. That's of critical importance for those people who want to see them.

I still think a fixed place for buttons (i.e. not scrolling) is a good idea. Ben mentioned about making the collapsed headers not scroll. I'm guessing there's a lot of people that do want them to scroll, and a lot that don't. So I think this is one place we do want to allow a pref? It could make writing it interesting, but I think there are likely to be two clear sets of users. Also, what happens if you want to adjust the list of people you're replying to? (or even when forwarding) - that's unclear from your demo.

(In reply to comment #55) > I'm guessing there's a lot of people that do want them to scroll, and a lot > that don't. So I think this is one place we do want to allow a pref? It could > make writing it interesting, but I think there are likely to be two clear > sets of users. Well, I know that this probably isn't "popular/vocal" opinion, but I've always felt like one of TB's main drawbacks was that it has to many options because it tries to please everyone (hence the lack of extensions). So I know its probably not popular opinion, but what's the say on killing the expanded headers view in the messenger window entirely? Make the "details" button open the message in a new window and show expanded headers in a sidebar or some fancy listbox/richlist there? Then just keep a small non-scrolling header + new buttons box (which I like a lot) in the main UI?

(In reply to comment #56) [...] > So I know its probably not popular opinion, but what's the say on killing the > expanded headers view in the messenger window entirely? Make the "details" > button open the message in a new window and show expanded headers in a sidebar > or some fancy listbox/richlist there? Then just keep a small non-scrolling > header + new buttons box (which I like a lot) in the main UI? > Wesley, please! If, as you yourself admit, "it isn't popular", it shouldn't be made mandatory for everyone, even if "you" like it a lot. This said, this kind of discussion would probably be better suited for a newsgroup, e.g. mozilla.dev.apps.thunderbird on the news.mozilla.org server.

(In reply to comment #54) > - Background color of headers is much better. > (I'd avoid changing from white to black font foreground color, though.) I think we're going to try to keep with the theme color palette here, but like I mentioned to dmose I want to do a bit of a gradient and make the header look raised above the message; via a drop shadow or something equivalent. The font colors will likely have to match whatever the theme provides, as long as we are different than the message. > - Please keep the buttons all in one place. You currently have 3 places for > buttons associated with the message. That's *way* too much and confusing. > I think the problem of wanting to click Reply at the end of the msg is > solved > when we don't make the collapsed headers scroll, but still make the extended > headers scroll. > I'd recommend to have the first set of buttons on the top right of the > collapsed headers, and if you want to hide some buttons, put them on the > extended headers, again on top right. This means they are at least close to > each other. I think we need to have a set of smallish "quick" buttons at the top such that the most common actions are always available when a message is first loaded. The additional buttons (currently view source, save as...) at the bottom of the detailed header view could be changed into another form. People who always want the detailed view (it should be remembered as it is now) probably don't want those buttons creating such a large visual break. The fuller set of larger buttons at the bottom is necessary such that we don't require everyone to hit such small mouse targets only up at the top. As well as having a set of buttons at the bottom allows people who've read the entire message to act on it with out scrolling up to the top. > - I really liked, in your earlier design, having the email addresses in smaller > font and grey color, in extended headers. I'm looking into doing something like this again, but I'm not sure what the best method is. We want the contact labels to be small but showing the email address can be valuable; I'm not sure what kind of design that leads to. > - What happens in the collapsed headers when there are many (dozens) of > recipients? This happens quite often in business communication. This is a concern for both the detailed and summary view. In the summary view we need to truncate as much as possible. I'd like to show the names of a set of people who are your contacts and then I think we'll need to give a number of recipients if it's very large. In the detailed view I think we'll need to use a similar algorithm and hide the full list when it's larger than some set of contacts, like 10. If we provide something like the details link that says "Show all $# recipients" we can expand the header to show everyone. > - I assume the expanded headers "expand" state persists between msgs. That's of critical importance for those people who want to see them. Exactly, just like it currently does. (In reply to comment #55) > I still think a fixed place for buttons (i.e. not scrolling) is a good idea. I don't think this is necesarily true. I think we need to work to solve the problem that a person may want to act on the message when the scrolled headers aren't visible. But I think there are plenty of interfaces out there (where content is most important) that have shown you don't need to always have the action buttons visible the entire time. Vimeo is a video player that has video action widgets that are only available when the mouse is hovering over the video. I'd like to investigate something similar to this. http://vimeo.com/1561578?pg=embed&sec=1561578 Right now i'm trying to work a mockup such that the bottom row of buttons is visible when the mouse is moving over the message view, but fade out when the mouse stops moving. (similar interactions to the video players) These interfaces have been found to be very usable by many people and allow for the content (which is most important) to have the most window space available. We can see how this turns out. > Ben mentioned about making the collapsed headers not scroll. I'm guessing > there's a lot of people that do want them to scroll, and a lot that don't. So > I think this is one place we do want to allow a pref? It could make writing it > interesting, but I think there are likely to be two clear sets of users. I think we can look into that in future versions. But I'd like to have people try having the headers scroll and then hear what the exact issues are with not having the headers always visible. Then we could determine how to fix those individual problems by making that kind of pref or with alternate solutions. > Also, what happens if you want to adjust the list of people you're replying > to? (or even when forwarding) - that's unclear from your demo. The reply / forward functions are just toys. This bug is only about the message reader right now and not about the composition. That would be a large set of work beyond this to take on. When thunderbird has this message reader in place we'll just open up the composition window when a person chooses reply or forward.

[buttons] I understood your reasoning, but I think 3 different places for buttons for the msg is way too much. It looks cluttered, disorganized, illogical, confusing. [full recipients list] > In the detailed view I think we'll need to use a similar algorithm and > hide the full list when it's larger than some set of contacts, like 10. Actually, we don't need to anymore once the expanded headers scroll. We currently have to collapse them, because the header pane was fixed (for technical reasons). One of the nice things about making the expanded headers scroll is that we can show the full list of recipients, and the full name and email address of each, without further widgetry.

(In reply to comment #59) > [buttons] > > I understood your reasoning, but I think 3 different places for buttons for > the msg is way too much. It looks cluttered, disorganized, illogical, > confusing. You had me at cluttered :) It will only be 2 different places, like I said, the buttons in the detailed headers can be rendered in a different manner than a table of buttons. Since I want to avoid a static toolbar (for a number or reasons clearly stated: content is king) the only way to make progress would seem to be offering other ideas that align well within those contraints. > [full recipients list] > > In the detailed view I think we'll need to use a similar algorithm and > > hide the full list when it's larger than some set of contacts, like 10. > > Actually, we don't need to anymore once the expanded headers scroll. We > currently have to collapse them, because the header pane was fixed (for > technical reasons). One of the nice things about making the expanded headers > scroll is that we can show the full list of recipients, and the full name and > email address of each, without further widgetry. I'm concerned, even though the space will scroll, about having an email sent out to 50 people causing the header to expand to an extremely large height. I don't want to add additional widgets but I think we'll need to limit the height somehow.

(In reply to comment #58) > > - What happens in the collapsed headers when there are many (dozens) of > > recipients? This happens quite often in business communication. > In the detailed view I think we'll need to use a similar algorithm and hide the > full list when it's larger than some set of contacts, like 10. If we provide > something like the details link that says "Show all $# recipients" we can > expand the header to show everyone. This is why bug 381491 was filed. The current behavior is restricted to a single line (not configurable) of recipients per address header, and the user has to manually expand that list. This does not stick between messages and not even for the same message if revisited. > > - I assume the expanded headers "expand" state persists between msgs. > > That's of critical importance for those people who want to see them. > Exactly, just like it currently does. Well, it currently doesn't, as explained above. Thus, making a full expansion of the addresses stickable would help here for these use cases. > (In reply to comment #55) > > I still think a fixed place for buttons (i.e. not scrolling) is a good idea. I still agree with that, the toolbar is always there. Not convinced yet about any buttons floating with the message for the various reasons stated... > try having the headers scroll and then hear what the exact issues are with not > having the headers always visible. A compromise might be to have the compact presentation at a fixed location as a reference and the expanded headers scroll with the message to avoid blocking any real estate in the message window by potentially large address lists. (In reply to comment #60) > I'm concerned, even though the space will scroll, about having an email sent > out to 50 people causing the header to expand to an extremely large height. Yes, this is why Netscape 4.x had it limited to 15 entries per address header, and the (retired) mailnews.max_header_display_length pref could configure that for the collapsed address twisties up to Thunderbird 1.5.

(In reply to comment #60) [...] > I'm concerned, even though the space will scroll, about having an email sent > out to 50 people causing the header to expand to an extremely large height. I > don't want to add additional widgets but I think we'll need to limit the height > somehow. Maybe allow several addresses per line (as it is now in SeaMonkey's Message pane and window, not sure about Thunderbird) and have them become scrollable when there are more than, let's say, four lines of addresses?

This is a work-in-progress patch for the first chunk of message reader changes. It still needs some cleanup, and the CSS changes still need to be ported to the qute theme. It does the following things: * most of the expanded header box changes * "edit draft" & "remote images" changes Either this patch or a subsequent one will need to do various visual cleanup bits: * rounded corner issues when "edit drafts" is in use * email address twisties barely visible (suggested color?) * focussed native buttons have an odd border color to show focus (suggested color?) * edit drafts box doesn't go away on an empty folder (arguably edit drafts wants to be part of the msgNotification bar) * transparency problem with the twisty in the collapsed pane After the part 1 patch lands, another patch can do: * collapsed header changes * make collapsed header default * gradient effects The remaining work after that tends to shrink the amount of content that fits in the message pane (font changes, visual narrowing, attachments in the header, footer bar, etc.), so they are going to want to wait until we get the scrolling headers iframe fixes from bug 80713. Will post various screen captures for the ui-review momentarily.

Comment on attachment 337550 [details] [diff] [review] part I (WIP), v1 >diff --git a/mail/locales/en-US/chrome/messenger/msgHdrViewOverlay.dtd b/mail/locales/en-US/chrome/messenger/msgHdrViewOverlay.dtd >+<!ENTITY toField2.label "to "> >+<!ENTITY fromField2.label "from "> >+<!ENTITY senderField2.label "sender "> >+<!ENTITY organizationField2.label "organization "> >+<!ENTITY replyToField2.label "reply-to "> Is there a specific reason why those (and others) are changed to lower case? This completely breaks the UI style we're having everywhere else that has everthing with a capital first letter, and additionally, you're mixing those two text styles all over the place, as the screen shots show, which doesn't look too consistent to me. One other thing I saw: The theming is currently pinstripe-only, and this might even be OK there, but in general be careful to avoid hardcoded colors in themes and use generic (OS) theme colors instead, as else we'll run into interesting problems with dark vs. light themes, etc. Overall, I actually like the screen shots you posted better than the experimental stuff linked in this bug, but I wonder if this patch is going far enough for the people who liked that...

3.0b1 flag is going away in favour of 3.0 flag and milestone combination.

Comment on attachment 337550 [details] [diff] [review] part I (WIP), v1 looks good so far

(In reply to comment #68) > (From update of attachment 337550 [details] [diff] [review]) > >diff --git a/mail/locales/en-US/chrome/messenger/msgHdrViewOverlay.dtd b/mail/locales/en-US/chrome/messenger/msgHdrViewOverlay.dtd > >+<!ENTITY toField2.label "to "> > >+<!ENTITY fromField2.label "from "> > >+<!ENTITY senderField2.label "sender "> > >+<!ENTITY organizationField2.label "organization "> > >+<!ENTITY replyToField2.label "reply-to "> > > Is there a specific reason why those (and others) are changed to lower case? This is as per the mockups, and is intended to de-emphasize the headers. > This completely breaks the UI style we're having everywhere else that has > everthing with a capital first letter, and additionally, you're mixing those > two text styles all over the place, as the screen shots show, which doesn't > look too consistent to me. Where else in the UI do we have lists of headers that are not in menus? > One other thing I saw: The theming is currently pinstripe-only, and this might > even be OK there, but in general be careful to avoid hardcoded colors in themes > and use generic (OS) theme colors instead, as else we'll run into interesting > problems with dark vs. light themes, etc. A good point. I'll have a look, but I suspect this is going to be difficult, given what we're doing here. > Overall, I actually like the screen shots you posted better than the > experimental stuff linked in this bug, but I wonder if this patch is going far > enough for the people who liked that... This is just a step on the way towards the mockups; see the comments I posted with the patch.

I still need to do a little more cleanup before it's ready for review (just the remaining YYY comments, really). However, there shouldn't be any more visual changes between now and landing, so requesting ui-review from clarkbw.

Also need to port the CSS to Qute, but that should be quick.

(In reply to comment #38) > wow, lots of stuff! > > (Archive button) > I think we can create a system for archving mail in thunderbird. This bug > isn't the place to discuss it's objectives, in the mockups it's meant to show > another type of message specific action like trash, reply, and forward. Is there a place where archive is being discussed?

(In reply to comment #72) > Created an attachment (id=338590) [details] > part I (WIP), v2 It looks nice but it would also be great if users (and theme developers?) had more CSS control of specific fields in the headers pane. For example, I'd like to use my userchrome.css to make the Subject text bold with a bigger font, and I also like to distinguish the Date field from the To/CC fields, etc. This wasn't easy with Thunderbird 2.x and, with an uneducated look at the WIP, it seems that we might have even less control of these things now? Please consider giving us some header-specific IDs or classes that we can reference from our userchrome.css files, at least for the Subject and Date fields, and maybe a single general rule for all fields that contain email addresses? In addition, it would be nice if the labels like these: From: Subject: To: Date: would automatically adapt their height if the Subject text, for example, has a bigger font than the others. Maybe this already works. Please also consider the bug request where we want to be able to wrap the text of the Subject field so we can see the whole Subject on the screen at once. I'm not suggesting to implement that in this bug, but to please consider it as you design this patch, if possible.

(In reply to comment #78) > It looks nice but it would also be great if users (and theme developers?) had > more CSS control of specific fields in the headers pane. For example, I'd like > to use my userchrome.css to make the Subject text bold with a bigger font, and > I also like to distinguish the Date field from the To/CC fields, etc. My XBL CSS fu isn't strong, but the following should work: #expandeddateBox .headerName { font-size: bigger; } > This wasn't easy with Thunderbird 2.x and, with an uneducated look at the WIP, > it seems that we might have even less control of these things now? No worse than before, from my reading. > Please also consider the bug request where we want to be able to wrap the text > of the Subject field so we can see the whole Subject on the screen at once. > I'm not suggesting to implement that in this bug, but to please consider it as > you design this patch, if possible. From my basic introspection, that's a change in someplace completely different. Now, in response to the WIP: 1. I'm not entirely happy with the background color (it sticks out too much to me), but that looks like a one-liner (more or less) in userChrome.css, so I'll not complain too much. 2. Surprisingly, the lower-case label names seem to work well. I'll have some more comments as I look into the patch more, but I've got to run now...

(In reply to comment #79) > 2. Surprisingly, the lower-case label names seem to work well. Unfortunately, this is something that will and can probably only work in English, perhaps a small number of other languages. German e.g. has almost all those labels with a capital start character as the words themselves also are written that way in in normal sentences (all nouns are capitalized), and e.g. Asian languages are yet another story, I guess. If we want general de-emphasizing of those labels, lowercase does not work for most languages (I'll leave out the argument of inconsistency with the rest of our UI as it sounded not important in previous comments).

I have to say I don't find the lower-case header labels very nice either, but I think it's even worse for the buttons, those should definitely be Upper Case imo.

Comment on attachment 338593 [details] screenshot of message with edit drafts bar obsoleting, this has no content

This time, for sure!

I plan to file a spinoff bug (if there's not one already) about making the Subject line wrap. It took me a bit to get used to the lower-case button names, but now that I have, I like them. It feels to me like they work for English, anyway. The hope is for the expanded header to include a gradient in an upcoming iteration. It's also possible that we'll switch colors as well. Also, note that this is really just a starting point for more iterations, as per comment 63.

I tried the patch and have two remarks. When the header is collapsed, we have to use the twisty to expand. In expanded mode, the twisty isn't visible and must use a button on the opposite side of the twisty. When I only want to expand/collapse for a short moment, I have to move the mouse over a long distance. Isn't it be better to only use the twisty in both modes? The "Hide Details" Button makes the header bar also higher than needed. The "mark as junk", "reply..." and "forward..." buttons should also have a mode, where only icons are displayed like the trash button. On small screens almost the whole header is filled with buttons.

(In reply to comment #77) > Is there a place where archive is being discussed? bug 451995 is for archive button discussion

Comment on attachment 338590 [details] [diff] [review] part I (WIP), v2 dmose: can you make the button order be (reply $X...) (forward...) (mark as junk) ($D) I want to group the junk / trash button together away from the reply button Other than that things look good.

Addressed Bryan's ui-review comments; carrying that forward.

This is the look on my Linux build (centos), I've not seen a screenshot of windows at the moment, but it certainly doesn't look as polished. - The from is displayed as a link (rather than on hover?) - I think there's too much space between the lines - The newsgroups are cut off (if I add more tags, you see more of the newsgroup names).

Some things I noticed: - The blue email links are not visible. - "Important" and the links aren't rendered well, because I understand Cleartype doesn't work that well with dark text on a dark background. - The system default font should be used, and not Arial

Comment on attachment 338811 [details] [diff] [review] part I (WIP), v3 In addition to my previous comments on the Linux/Windows display, some general style comments first: - In the expanded view, the overall balance of the message header view doesn't seem quite right. The message header text is smaller than the buttons, and the contrast makes it feel strange. - There's a lot of empty space above the header details on the expanded view. - The background is quite dark compared to the rest of Thunderbird. - The contrast of the default tag colours and the dark background doesn't seem quite right. - As someone already comment, having the expand and collapse for the header view at different sides of the screen just doesn't work right. You could keep them as they are, but add a collapse function in the top-left corner as well and we'll probably get away with it. The above comments I think are not significant enough to stop this patch going in, especially as we need to get the strings in place. Though I do think we may want to look at them before b1 code freeze. With respect to the lower-casing of labels, I think it looks reasonable. Let's get the patch out with them for b1 and get some feedback. These items I think we should fix before the patch goes in: - On the collapsed view, the text on the labels/values is misaligned. - If you have a "to" field with lots of addresses, the buttons disappear off the screen. - Select the "mark as junk" button, the message is marked as junk, but the text on the button doesn't change. If I click it again, then it does the "not junk" job. >+// XXXdmose need to decide if we want to keep the special elements for these >+// headers. If so, we'll need to write code that actually uses the below >+// array. If not, we should get rid of the array as well as the XUL elements >+var extraExpandedHeaderList = [ {name:"sender", outputFunction:OutputEmailAddresses}, >+ {name:"references", outputFunction:OutputMessageIds} ]; > I think you should also state that this items are effectively disabled now. >@@ -755,17 +759,17 @@ function updateHeaderViews() > } > > function ToggleHeaderView () > { > gCollapsedHeaderViewMode = !gCollapsedHeaderViewMode; > // Work around a xul deck bug where the height of the deck is determined by the tallest panel in the deck > // even if that panel is not selected... > document.getElementById('msgHeaderViewDeck').selectedPanel.collapsed = true; >- >+ > UpdateMessageHeaders(); nit: we don't want this whitespace change >diff --git a/mail/base/content/msgHdrViewOverlay.xul b/mail/base/content/msgHdrViewOverlay.xul >--- a/mail/base/content/msgHdrViewOverlay.xul >+++ b/mail/base/content/msgHdrViewOverlay.xul >@@ -1,53 +1,52 @@ > <?xml version="1.0"?> >+<!-- ***** BEGIN LICENSE BLOCK ***** >+ Version: MPL 1.1/GPL 2.0/LGPL 2.1 >+ >+ The contents of this file are subject to the Mozilla Public License Version >+ 1.1 (the "License"); you may not use this file except in compliance with >+ the License. You may obtain a copy of the License at >+ http://www.mozilla.org/MPL/ Apparently the # version was originally done to save (probably small amounts of) The indentation and lack of - is actually different to the boilerplate: http://www.mozilla.org/MPL/boilerplate-1.1/mpl-tri-license-html for consistency I think you should fix that. Doing this change also means the file doesn't need preprocessing, so please drop the * from the start of the relevant line in mail/base/jar.mn. > > <!-- the message pane consists of 3 'boxes'. Box #2 is the expanded headers view (the default view) --> Isn't this 4 boxes now? >- <hbox id="expandedHeaderView" flex="1"> >+ <hbox id="expandedHeaderView" flex="1"> Nit: unnecessary whitespace change. >+ <mail-multi-emailHeaderField id="expandedfromBox" >+ label="&fromField2.label;" >+ collapsed="true"/> >+ >+ <spacer id="fromAndToolbarSpacer" flex="1"/> Nit: lots of whitespace on the blank line that we don't need. Please also check through the rest of the changes in this file - there's some whitespace on blank lines and the odd space on the end of some lines. >+ <!-- XXXdmose need to move these commands to a controller, either >+ on the header view, the message pane, or the default controller >+ --> >+ >+ <!-- XXXdmose need to audit our shortcut/a11y setup and make sure >+ these buttons are doing the right thing --> >+ >+ <button id="replyButton" label="&replyButton.label;" >+ oncommand="MsgReplyMessage(null);" observes="button_reply" >+ class="msgHeaderView-button"/> >+ <button id="forwardButton" label="&forwardButton.label;" >+ oncommand="MsgForwardMessage(null);" >+ observes="button_forward" class="msgHeaderView-button"/> >+ <button id="junkButton" label="&junkButton.label;" >+ observes="button_junk" class="msgHeaderView-button" >+ oncommand="goDoCommand('button_junk')"/> >+ <button id="trashButton" tooltiptext="&trashButton.tooltiptext;" >+ class="msgHeaderView-button" observes="button_delete" >+ oncommand="goDoCommand(event.shiftKey ? 'cmd_shiftDelete' : 'cmd_delete')"/> >+ </hbox> >+ </hbox> I think these buttons should have access keys, or are you leaving that until after beta? > <hbox id="attachmentView" collapsed="true"> > <description selectable="true" id="attachmentList" flex="1" > seltype="multiple" disableKeyNavigation="true" >- onclick="attachmentListClick(event);" ondraggesture="nsDragAndDrop.startDrag(event,attachmentAreaDNDObserver);" >+ onclick="attach\mentListClick(event);" ondraggesture="nsDragAndDrop.startDrag(event,attachmentAreaDNDObserver);" I think we don't want this change. > <!-- Phishing Bar --> >-<!ENTITY phishingBarMessage1.label "Suspected Email Scam"> >+<!ENTITY phishingBarMessage2.label "This may be an email scam."> How about "This email may be a scam."? I think it flows better (I'm open to persuasion though). May have to change reportPhishingError.label as well if we did that. >diff --git a/mail/themes/qute/mail/messageHeader.css b/mail/themes/qute/mail/messageHeader.css >--- a/mail/themes/qute/mail/messageHeader.css >+++ b/mail/themes/qute/mail/messageHeader.css >+#msgHeaderView-button { >+ min-width: 1px !important; > } msgHeaderView-button is a class not an id. >diff --git a/mailnews/base/resources/content/mailWidgets.xml b/mailnews/base/resources/content/mailWidgets.xml >--- a/mailnews/base/resources/content/mailWidgets.xml >+++ b/mailnews/base/resources/content/mailWidgets.xml >@@ -200,17 +200,17 @@ > </content> > </binding> > > <binding id="mail-emailheaderfield"> > <content> > <xul:hbox class="headerNameBox" align="start"> > <xul:label class="headerName" xbl:inherits="value=label" flex="1"/> > </xul:hbox> >- <xul:mail-emailaddress anonid="emailAddressNode"/> >+ <xul:mail-emailaddress class="headerValue" anonid="emailAddressNode"/> > </content> > I don't see the point of this change. mail-emailheaderfield is only used for expandedSenderBox, which I believe you've now disabled. I'm also concerned it may affect SeaMonkey.

Another thought: I like the lower case header labels, but don't like the lower case button labels and menu items.

The lower-case buttons look fine in the rounded buttons, but somewhat odd in the Linux and Vista versions. Along with the localization issues of capitalization being relevant in a lot of languages, another voice for retaining upper-case letters at least for the buttons. In general, the buttons are a bit too dominant for my taste and occupy a lot of space (e.g., attachment 338861 [details]). While realizing that this is work in progress, I hope that the presence (or non-presence) of those buttons will be configurable like the toolbar buttons in the future...

(In reply to comment #89) > Created an attachment (id=338861) [details] > Linux Screenshot > > This is the look on my Linux build (centos), I've not seen a screenshot of > windows at the moment, but it certainly doesn't look as polished. Yeah, lots of polish work to do. In combination with a couple of soon-to-be-filed bugs, ongoing iteration on this stuff will be tracked at <https://wiki.mozilla.org/User:Dmose:Message_Reader_Polish>. Despite sharing a theme, Linux looks less similar to Windows than I'd hoped. I don't have a Linux VM at the moment, looks like I'll need to get one set up. :-/ > - The from is displayed as a link (rather than on hover?) Will fix. > - I think there's too much space between the lines Added to the list of "Polish needed for beta 1" on the above-mentioned wiki page. > - The newsgroups are cut off (if I add more tags, you see more of the newsgroup > names). I'll fix this before re-requesting review. (In reply to comment #91) > - "Important" and the links aren't rendered well, because I understand > Cleartype doesn't work that well with dark text on a dark background. Added to the "fix for beta 1" list > - The system default font should be used, and not Arial Moving away from some of the system defaults is intentional; this is one of those cases. This does have accessibility implications, however, so I've added an item to the "Needed for Tb3" list to figure out what to do about that. (In reply to comment #92) > - In the expanded view, the overall balance of the message header view doesn't > seem quite right. The message header text is smaller than the buttons, and the > contrast makes it feel strange. It's hard for me to tell if the text is actually smaller just from looking; I'd need to go in with DOMI. I've added a "verify reasonable proportions" to the "fix for beta 1" list. Note that in Windows/Linux, the header names were incorrectly bolded; I've now fixed that. > - There's a lot of empty space above the header details on the expanded view. Above the from header, you mean? This seems to be a problem on Mac more than elsewhere, at least given the current buttons. Added to the "fix for beta 1" list. > - The background is quite dark compared to the rest of Thunderbird. True, though this is as per the mockups. I'll let clarkbw add something to the polish page if he thinks this should change. > - The contrast of the default tag colours and the dark background doesn't seem > quite right. Added to the "fix for beta 1" list. > - As someone already comment, having the expand and collapse for the header > view at different sides of the screen just doesn't work right. You could keep > them as they are, but add a collapse function in the top-left corner as well > and we'll probably get away with it. Agreed, this makes for a crummy interaction. Added to the "fix for beta 1" list. > These items I think we should fix before the patch goes in: > > - On the collapsed view, the text on the labels/values is misaligned. Doesn't happen on mac, will fix on the other platforms. > - If you have a "to" field with lots of addresses, the buttons disappear off > the screen. All the headers have this problem, and it does indeed suck. I'll try and fix this before landing, but it's not yet clear to me how much work it's going to be. > - Select the "mark as junk" button, the message is marked as junk, but the text > on the button doesn't change. If I click it again, then it does the "not junk" > job. Will fix. > I think you should also state that this items are effectively disabled now. They _might_ actually just work as a generic extended header if someone has added them to the pref; I haven't tested. Updated the comment to be clearer. > The indentation and lack of - is actually different to the boilerplate: > http://www.mozilla.org/MPL/boilerplate-1.1/mpl-tri-license-html for consistency > I think you should fix that. Fixed. > Doing this change also means the file doesn't need preprocessing, so please > drop the * from the start of the relevant line in mail/base/jar.mn. What does that change have to do with preprocessing? > I think these buttons should have access keys, or are you leaving that until > after beta? This can wait until after beta, I think, since all the functionality here should already be available from menus and therefore keyboard-accessible. Added to the "fix for tb3" list. > > <!-- Phishing Bar --> > >-<!ENTITY phishingBarMessage1.label "Suspected Email Scam"> > >+<!ENTITY phishingBarMessage2.label "This may be an email scam."> > > How about "This email may be a scam."? I think it flows better (I'm open to > persuasion though). May have to change reportPhishingError.label as well if we > did that. Agreed; will change both. > I don't see the point of this change. mail-emailheaderfield is only used for > expandedSenderBox, which I believe you've now disabled. I'm also concerned it > may affect SeaMonkey. Quite correct; I've gotten rid of this change for now. That said, I still think it's the Right Thing.

(In reply to comment #94) > The lower-case buttons look fine in the rounded buttons, but somewhat odd > in the Linux and Vista versions. In general, the buttons are a bit too > dominant for my taste and occupy a lot of space (e.g., attachment 338861 [details] > [details]). Yes, the buttons on Windows & Linux don't look good. This is on the radar to make at least somewhat better before checkin, but I could also imagine it slipping to"fix for beta1" list. > Along with the localization issues of > capitalization being relevant in a lot of languages, another voice for > retaining upper-case letters at least for the buttons. I'll defer to clarkbw on this. > While realizing that this is work in progress, I hope that the > presence (or non-presence) of those buttons will be configurable like the > toolbar buttons in the future... Considering whether to do that is on the "look at before Tb3" list.

Updated patch. This has all the stuff on the "easy" fix before landing list done. There remaining items are in the "possibly less easy" list may make it in the tree today in separate patches, or may slip to "need to be fixed for b1".

(In reply to comment #97) > Created an attachment (id=338941) [details] > part I, v4 <popup id="copyUrlPopup" popupanchor="bottomleft"> <menuitem label="&copyLinkCmd.label;" accesskey="&copyLinkCmd.accesskey;" oncommand="CopyWebsiteAddress(document.popupNode)"/> - <menuitem label="&copyLinkCmd.label;" accesskey="&copyLinkCmd.accesskey;" oncommand="CopyWebsiteAddress(document.popupNode)"/> + <menuitem label="&copyLinkCmd.label;" accesskeys="&copyLinkCmd.accesskey;" oncommand="CopyWebsiteAddress(document.popupNode)"/> </popup> Should be accesskey (no s on the end). + <hbox align="baseline"> + <mail-multi-emailHeaderField id="collapsedfromValue" + class="collapsedHeaderDisplayName" + label="&fromField2.label;" + collapsed="true" flex="1"/> This change (i.e. to "baseline") doesn't seem to have any effect on the "from" field, but the subject field is now ok (discussion on irc says we'll leave this as not worth fixing due to rearranging of collapsed view post-beta 1. mailWidgets.xml You seemed to miss removing this.

Review comments addressed; carrying forward r+ and ui-r+.

Patch as checked in. With Standard8's permission, I put back the headerclass buglet fix in mailWidgets.xul.

Just pointing out a few more bugs :) - "This is a draft message" and "Edit..." are displayed with the system default font, and "Edit..." is capitalized. - Buttons get pushed off the edge of the window. (this is already covered on the polish wiki page) - The left and right edges look weird.

(In reply to comment #101) > - Buttons get pushed off the edge of the window. (this is already covered on > the polish wiki page) I just want to mention that this is probably most noticeable when the non-default "vertical view" is used.

All the major changes that we're going to take for b1 are in now. The polish fixes related to the stuff that's already landed that we're going to take for b1 are being tracked in bug 455801. Retargeting the rest of this bug for b2.

I read much of this bug, but not all, so please excuse if these issues have been addressed already: 1. Has there been any discussion on the actual (as opposed to theoretical) benefit, or even necessity, of having all these buttons on the already too large header? I want the header smaller, not larger. I also don't like the buttons scattered all over the application. 2. The background color of the header (dark teal?) (WinXP) looks incongruous with the rest of Thunderbird, and it makes many of my tag colors hard to read (too little contrast). 3. Could you please remove the "To" row? 99% of e-mails are to *me* anyhow. Telling me an e-mail in my inbox is to me is kinda redundant. And, most importantly, it wastes valuable vertical space. 4. I think the "Subject" should be in the *first* row (not the "From") because *what* is being talked about is more important than *who* is talking. All-in-all I think the current changes are making things worse, not better. BTW: This has bugged me for years: For the collapsed header: The "From" is way too far to the left. It should be much closer to the date, in order to maximize the Subject's available space.

> 2. The background color of the header (dark teal?) (WinXP) looks incongruous > with the rest of Thunderbird, and it makes many of my tag colors hard to read > (too little contrast). The colors aren't final, so constructive suggestions are welcome. Bug 455801 has an effort to work on the look of tags. > 3. Could you please remove the "To" row? 99% of e-mails are to *me* anyhow. > Telling me an e-mail in my inbox is to me is kinda redundant. And, most > importantly, it wastes valuable vertical space. Do you mean remove the row when it's sent to only you? The to: line will also show the other people an email could have been sent to. I don't think we can remove the to: line sometimes, but there might be another way to format an email that is from one person to you (one person). > 4. I think the "Subject" should be in the *first* row (not the "From") because > *what* is being talked about is more important than *who* is talking. This is debatable, I think either could be a more important value depending on the type of email or person receiving it. Ultimately I choose the from at the top because it should always have a "real" value of the sender. A subject doesn't always have a good value, often people can't think a good subject for an email and so they just write something. Sometimes emails have no subject at all. Like I said, debatable, I don't think there is definitely proof out there that one is always more important than the other. > BTW: This has bugged me for years: For the collapsed header: The "From" is way > too far to the left. It should be much closer to the date, in order to maximize > the Subject's available space. The collapsed header is being changed, but as noted above hasn't been changed yet for this release.

In e-mails with a digital certificates the cert icon will cause all buttons to shift left. (is unstable unpredictable UI) (In reply to comment #105) > The colors aren't final, so constructive suggestions are welcome. The background color should be what it was before. Please only change it *after* you have something better. Why change it anyhow? > I don't think we can remove the to: line sometimes, The CC and BCC lines are removed sometimes (i.e., only shown when they are non-empty). Hopefully the To-line can also be shown/hidden based on a similar rule (i.e. when "To = only me").

The header's text size no longer respects the user's chosen text size (WindowsXP: Display Properties / Appearance / Advanced / Item: Message Box).

Small nit for the polish category: With mailnews.headers.showUserAgent set to "true", the User-Agent string (if present) is truncated quite early for longer entries, which was shown across the complete message-window width before.

> > I don't think we can remove the to: line sometimes, > > The CC and BCC lines are removed sometimes (i.e., only shown when they are > non-empty). Hopefully the To-line can also be shown/hidden based on a similar > rule (i.e. when "To = only me"). What would we do for people with more than one account? So if an email was sent to clarkbw@example.com and another was sent to clarkbw@example.org. Both received by me, but to different identities of me. Do those still get hidden? > Small nit for the polish category: > > With mailnews.headers.showUserAgent set to "true", the User-Agent string > (if present) is truncated quite early for longer entries, which was shown > across the complete message-window width before. Quick DOMi inspection... The spacer inside the #otherHeadersAndButtonsBox looks to be flexing over that header and squishing it when the to field isn't longer than the user agent field.

couple of small bugs (should it be in related bug for polish?) -Lclick on a contact in from or to is bringing the context menu. Maybe good or not, but not expected -twisty show aside msg-id/in-reply-to twisting "1" to the "<ab79x43>" ? useless?(all headers) -click on msg-id is (obviously) useless -draft could fall inline for the collapsed header? Without button, just "Draft" as link..

I'd like to make couple of suggestions. But first, -Does it have to be dependent on bug 80713 ? Does it have to fall into the iframe? Is it not ok with a xul box to scroll and leave the iframe only for body? Just wondering .. (excuse my possible misunderstanding if ..) -is this, or should be, considered in conjunction with a "data miner"? I've considered also the [what I wish to be] expmes with gloda and that may just serve to solve some of the issues, while bringing up others maybe .. I say that cause much trouble is about what to show, how to customize, and redundancy. Also have to consider the extensions that use the header space like ThreadVis (and data miner steps in, otherwise ..) 1. About how much and how to customize, an expmes panel could just contain headers or all headers while one can use that miner or not. Let's call it move the overload to it's own space outside msg area. Maybe that means to allow a miner aside msg in a new window or tab also. 2. Having such in a separate thing can ease the check or small arrows aside fields to just move them into the header. Rclick menu is always a good idea to have "remove from header" (vs "add to header" in expmes). Drag would do also, but not alone, may not be as obvious. Or rclick "customize header content" could do with a list of things to check.. 3. This may solve a header always visible issue. Though having hover video like buttons may be better. About that, hover or click on msg is not like video as it may serve for text select, link click etc. I was thinking about sort of header just show when mouse in upper several px or lower for attach. That is not quite a solution also considering that I may select text and scroll while .. Or just that it will pop when I wanna do something else on that text. 4. Drag the msg instead of move button may be better, indication about thread up/down related may also do (c#31). Or just having the clear icon for replied/forwarded as in threadpane and leave those to pop on click on that specific icon and alttext on hover.. 5. Key usage is not essential IMHO for most users (c#33, c#35). I use that extensively in other apps, but not much in TB. Cause I don't use it on essential management actions, and here probably most TB actions are about that. May be weird case, but consider also that some extensions may even propose some key usage to interfere .. (saw that) 6. Do consider collapsing quote and such. Detecting from where is that quote [and label it, connect it to thread/expmes visually, reverse quote -where it shows that a part of text is quoted in another mail etc] would be another discuss x. Generally I find it interesting though it's scary at first (had to step back and say, "ok, we're testing here ..") Screen real estate is an issue and I favor using most for content and changing proportions in respect to usage. Redundancy and customization is an issue that probably has to be treated in relation to other elements, toolbar, miner etc Web face is not quite a problem. Using webmail vs desktop I find it a bit of a false UI problem. There are deep differences IMHO. [offline vs portability, speed, safety, customization etc]

Make sure to check out attachment 339386 [details] for the latest version from bug 455801 > -Lclick on a contact in from or to is bringing the context menu. Maybe good or > not, but not expected AFAIK this was the behavior from at 3.0a1 as well. (what I have to test) > -twisty show aside msg-id/in-reply-to twisting "1" to the "<ab79x43>" ? > useless?(all headers) that does seem useless to have that twisty and the message id isn't styled correctly > -click on msg-id is (obviously) useless Hmm, this does seem pretty useless as well. For me it just collapses the twisty. > -draft could fall inline for the collapsed header? Without button, just "Draft" > as link.. That could make it looks a little nicer. There hasn't been any work on the collapsed view yet, but that's something to keep in mind.

(In reply to comment #112) > Make sure to check out attachment 339386 [details] for the latest version from bug 455801 did that, better, tags ok, still the twisty instead of hide would do > > -Lclick on a contact in from or to is bringing the context menu. Maybe good or > > not, but not expected > > AFAIK this was the behavior from at 3.0a1 as well. (what I have to test) it is the behavior even in tb2, I think it only occurred to me now as a not so ok thing. probably not worth touching now.. > > -twisty show aside msg-id/in-reply-to twisting "1" to the "<ab79x43>" ? > > useless?(all headers) > > that does seem useless to have that twisty and the message id isn't styled > correctly and what's with the "1"? > > -click on msg-id is (obviously) useless > > Hmm, this does seem pretty useless as well. For me it just collapses the > twisty. not here in vista, does nothing > > -draft could fall inline for the collapsed header? Without button, just "Draft" > > as link.. > > That could make it looks a little nicer. There hasn't been any work on the > collapsed view yet, but that's something to keep in mind. And still, the buttons make the header bigger than the text lines need it. that is rather xul box nesting thing mostly related to buttons (taller) in same line with text but I think there is some padding/margin also. Eh, if I'll think of something constructive I'll say ..

I follow interested the work of the new message reader / view pane. But I don't understand the sense to have a few buttons twice now. I've ever had the buttons for "Replay", "Forward" "Junk" and "Delete" in my toolbar. Now I have it a second time in the new message reader / view pane. Will it be possible to customize the new pane in the final version?

(In reply to comment #89) > Created an attachment (id=338861) [details] > Linux Screenshot > - The newsgroups are cut off (if I add more tags, you see more of the newsgroup > names). I see this if newsgroup is on line 3 of header display. But not if it's on line 4.

Note that the hide details button is the only one that responds to all 3 mouse clicks. Unfortunately the rclick also brings the usual menu. Minor .. Intended?

I consider the following to be REGRESSIONS caused by this bug: 1. Subject line no longer the first line. 2. Subject line no longer bold. 3. User-chosen text size no longer respected (Comment #107). 4. Pane's background color no longer respects OS system's color. I don't think this bug should change #1 and #2. This should first be discussed more extensively before someones changes UI that has been around and proven for over a decade. For instance, (keeping in mind that e-mail is more prevalent than newsgroups.) I suspect that most users will much more often correspond with the same person about multiple topics, rather than multiple persons corresponding about the same topic. Thus, the subject is more relevant than the sender.

Comments on current state: - Subject not in first line (regression) - Subject not bold (regression) - Trash icon seems slightly taller than other icons - User-chosen text size no longer respected (Comment #107) - Pane's background color no longer respects OS system's color. - "other actions" and "hide details" are not buttons. Why? - Too much space on left of "from", subject", etc. Intentional? Necessary? - Accidentally clicking on the star to add to addressbook cannot be undone. - digital signatures cause UI to move to left. Moving UI = bad!? - all buttons and labels are lower case. - Old display (bold labels, non-bold text) was easier to parse & read!?

Comments on current state: - Subject not in first line (or in front) (regression) - User-chosen font & text size no longer respected (Comment #107)? - Background color no longer respects OS system's color. - Digital signature not shown. There's enough space after sender's name!? - Accidentally clicking on the star to add to address book cannot be undone. - No labels ("Subject:", "From:") - Much more useful than the original collapsed pane! :-)

For reference.

For reference.

Peter, if you could take each of these issues and file bugs, and then mark this bug as dependent on them, then we can track each issue separately, that'd be much easier than in this already too-long bug.

(In reply to comment #117) [...] > For instance, (keeping in mind that e-mail is more prevalent than newsgroups.) > I suspect that most users will much more often correspond with the same person > about multiple topics, rather than multiple persons corresponding about the > same topic. Thus, the subject is more relevant than the sender. I have the opposite impression. I rarely discuss several topics at once with the same person in different but parallel conversations (except in mailing lists & newsgroups, but see below); when I get something from my lawyer, or from my special friend from across the world, the subject she chose is immaterial, what imports to me is, "Ah! it's from her!" On mailing lists, messages are threaded by subject, and a number of mails about a single subject will follow each other in the List pane. Once I've opened one of them, "who is speaking" is an important datum when it comes to following the conversation. The subject, being constant, is not so important in the Message pane or window. (It is important in the List pane but that's not what this bug is about.)

In order to facilitate tracking of individual issues rather than have one huge bug, I've cloned this bug to a new tracker bug (456814), and we'll track each issue in a separate dependent bug. Everyone cc'ed on this bug is cc'ed on the new bug. I'll go through and pick out issues pointed out above and make new bugs. When I think I've captured the issues, I'll resolve this bug.

I think I've gotten the bulk of the issues in dependent bugs on the tracker bug, so closing this one.