Open Bug 489999 Opened 11 years ago Updated 2 months ago

new look & feel for account central

Categories

(Thunderbird :: Mail Window Front End, enhancement)

enhancement
Not set

Tracking

(blocking-thunderbird3.1 -)

ASSIGNED
Tracking Status
blocking-thunderbird3.1 --- -

People

(Reporter: andreasn, Assigned: squib)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [b3ux][needs review][needs more design love][has l10n impact])

Attachments

(18 files, 32 obsolete files)

196.92 KB, image/png
Details
114.75 KB, image/png
Details
33.84 KB, image/png
Details
89.61 KB, patch
Details | Diff | Splinter Review
6.82 KB, patch
Details | Diff | Splinter Review
348.86 KB, patch
Details | Diff | Splinter Review
161.04 KB, image/png
Details
77.83 KB, patch
Details | Diff | Splinter Review
53.03 KB, patch
Details | Diff | Splinter Review
204.44 KB, image/png
clarkbw
: feedback+
Details
425.35 KB, patch
davida
: feedback+
Details | Diff | Splinter Review
15.53 KB, image/png
Details
80.51 KB, image/png
Details
128.89 KB, image/png
Details
85.21 KB, image/jpeg
Details
83.40 KB, image/png
Details
28.28 KB, image/png
Details
88.51 KB, application/x-xpinstall
Details
Attached image mockup (obsolete) —
Bug for tracking visual changes for account central.
Wanted something that matched the message you see when you open TB, so I've reused the skyline from the website. Also did icons that are closer in size to the text.
Will open bugs to track the work for this for pinstripe and aero as well.
Attached file account central icons (obsolete) —
Feels to me like we should rethink that page from a UX point of view first.  In particular, it feels like a particularly odd selection of features to highlight.  The search dialog in particular is not something I'd promote.
Duplicate of this bug: 433024
Here's what I've gathered about the Account Central.

We have a minimal usable area of about: 640 x 480
With a test profile I believe it's a little less than that if the client is running 800x600 however it's a scrollable area so I'm not too worried.

I'm envisioning this as a two column layout with two rows and each section provides different details on the account.

General layout being something like this where I'm ordering the items that remain consistently important over time (read/write) at the top and items that degrade in importance over time like settings.  With the Disk area I think we'll use a graph to draw enough attention to it.

+-----------------------+
|           |           |
|   Read    |   Write   |
|           |           |
|-----------------------|
|           |           |
|   Disk    | Settings  |
|           |           |
+-----------------------+

=Read=

For the Read section I think we could probably focus on the Inbox and there's room to provide a couple other options as well.  Listing out items like this:

  Inbox (#)
    - for (msg in msgs)
      if (msg > 5) break;

=Write=

For the Write section I think we want to focus on who you might compose a message to, so listing out your most frequent contacts for this account.  And then your Drafts folder seemed like the next logical area to present the number of Draft messages you have and display the most recent 3 or so.

  Write To
    - (peep in peeps)
      if (peep > 5) break;
  Drafts (#)
    - (draft in drafts)
      if (draft > 3) break;

=Disk=

For the Disk section I think we could use a pie chart (don't tell asuth!) that gives a breakdown of space usage per folder in the account.  With other obvious items like totals for the account.  We should also include an indicator that says if "AutoSync is $ON_OFF" and links to the Sync section of the account options for fiddling with the settings.

=Settings=
Can you 
Finally for the Settings section I think we could show some of the main account settings.  Items like Your Name, Email, Reply-To, Organization, and Signature are probably most important with a "Edit Settings" link that opens the Account Settings dialog.

Andreas, do you want to work with this?  You could just insert some junk data that provides some HTML layout and the right palette.  We can do the usual of start with gnomestripe and spread from there.

I'll see what we can do to get that page put together underneath as it seems like a mess.  My initial plan is to make this new "Account Dashboard" be used when looking at an email account and use current Account Central when looking at anything else.  There seems to be a lot of if (account == newsgroup) happening that I don't want to deal with just yet.  Maybe philor can help me out...
Sounds pretty good, except for the settings area. Why would anyone want to look at that stuff? Maybe it could be a "tip of the day" area instead...
Yeah, we could possibly layout the settings info at the top.  I just wanted to give a sense of what the account was for by showing that stuff but I think you're right that it doesn't need an entire section of it's own.  We could also try to pull in some news updates from mozillamessaging ( http://en-us.www.mozillamessaging.com/en-US/about/press/archive/ ) or something.
"Andreas, do you want to work with this?  You could just insert some junk data
that provides some HTML layout and the right palette.  We can do the usual of
start with gnomestripe and spread from there."

Sure, sounds like a great challenge!
Should I change the Assigned status to myself?
yeah, take it!
Also take a look at davida's new thing for the message pane space, I think it's pretty relevant to this.  ( http://ascher.ca/blog/2009/05/08/getting-insight-into-ones-own-email/ )
Assignee: nobody → nisses.mail
davida: did you have some code to lend andreas that would get him started on this?
No, but I think it does make sense for me to take some of the framework from the folder summary and apply it here.  I'll try to whip up a draft patch, that Andreas can then iterate on. 

Andreas, I'll "take" this bug for now, and reassign to you when the patch is ready.  But feel free to do simple HTML mockups if that helps you!
Assignee: nisses.mail → david.ascher
David: ok, sounds good!
Attached patch protovis patch (obsolete) — Splinter Review
This is a prerequisite for the next patch (keeping it separate because I use it in a few bugs)
Attached patch WIP v1 (obsolete) — Splinter Review
This, combined w/ the previous patch, is a bit of a framework for andreas to work on from a design POV.
Attached image screenshot (obsolete) —
andreas, this is what it looks like for me so far.  I'd love to see some mockups, but feel free as well to tweak the css in accountSummary.css.

(I'm not putting the CSS file in a theme directory so far so that we can work on the same file for now -- when we get close to done or when we need to make per-theme files, I can do the changes needed to make 3 copies, etc.
getting this on the blocking radar
Status: NEW → ASSIGNED
Flags: blocking-thunderbird3+
OS: Linux → All
Hardware: x86 → All
Whiteboard: [b3ux][needs updated patch]
Target Milestone: --- → Thunderbird 3.0b3
Attached image mockup wip v1
Here is a first mockup. Nothing fancy and good looking now, just some alignment fixes and some initial ideas:

I wanted to get rid of as many boxes as possible to create a more clean look. At first I aimed at achieving this with clever alignment and whitespace only, but it didn't work out, especially since pixels are expensive if we aim for 800x600. Therefore I went for a kind of checkboard approach.

The header would stick to the roof and walls and I wanted something to weight up things in the right top a bit. Not sure if Edit Account makes sense, but it would be cool to have something here that aligns with the tip of the birds tail (more on the bird further down).

I changed most of the headings to contain the more useful information that was earlier in the subheaders. This saves us some precious vertical space that is good to have if we aim at 800x600 without scrolling.

Under Space Usage, I moved the tags to the side instead of inside the pie. We can afford this space-wise, very small areas don't get covered all in text and horizontally placed text is more readable than vertically or 45° tilted text.

At the bottom I placed a bird (a Thunderbird?). This makes it sticks out from the other information on the page, as it's about the application rather than your e-mails. It also makes the message feel more personal and it might put a smile on people's faces.
Very nice.  I like it all.

I'm not sure how starring the messages on the right will work, but we should definitely try it.  Note that those are starred messages, not starred contacts.

I like the idea of the bird a lot.  It might be good to have one with a bit more expression, and/or a bit friendlier.  But a definite +1 on the idea.

Also -- such impressive literary contacts you have, Doris!
David: I placed the star on the left to maintain a straight left line between the header and the bread text. Are those messages recently read messages in your inbox, or the last five messages that landed in your inbox? If it's the latter, I wonder how common it is to have them starred already.
I think the "reading" list should be the messages most likely to be of interest, which I define as "last N unread or starred messages", where starred messages only show up if you have less than N unread.  So I think stars are fairly likely (by selection), but that doesn't mean stars on the right is a problem.
Attached patch WIP v2 (obsolete) — Splinter Review
checkpointing.
Attachment #377624 - Attachment is obsolete: true
Attached patch Pretty clean patch (obsolete) — Splinter Review
The layout is not finished, as andreas owns that, but I think the functionality is pretty good.  This needs protovis 2.2, which i'll attach as a secondary attachment. I'll also attach a screenshot.

It'd be good to start the review process, as the layout changes should not overlap with this much at all, except for CSS and HTML (and maybe DTD/properties).
Attachment #378494 - Attachment is obsolete: true
Attached patch patch adding protovis 2.2 (obsolete) — Splinter Review
Attachment #377623 - Attachment is obsolete: true
Attached image Screenshot
Attachment #377625 - Attachment is obsolete: true
A couple of notes:

1) the header css is wrong, but I didn't bother fixing it until we get a final layout.

2) the iframe currently points to ascher.ca, but obviously we need to get a mozillamessaging URL setup. I've filed bug 494090 to track that.
Depends on: 494090
Whiteboard: [b3ux][needs updated patch] → [b3ux][needs review][needs more design love]
dmose is delegating the review of the main patch to asuth.

the protovis patch will be discussed by peers.
Attachment #378742 - Flags: review?(bugmail)
TODOs:

- "recent correspondents" isn't accurate, need to express frecency

- capitalization of headings is off.

- animation is probably not worth it, but maybe we could have an easter egg

- "read inbox" button needs theming

- consider adding "new mail" button to match?

- confirm that we don't want buttons for filters, search dialog, subscription, offline.

- figure out where we want to place the "this account couldn't be reached" bit that's being discussed in another bug.

(not all of these block b3, IMO)
I'm not sure we're going to be able to express 'frecency' very well in the title.  Of other choices "Important Correspondents", "Top Correspondents", and "Frequent Correspondents" I think frequent is the closest since that's what this is minus people from way back.

I think you just want to change 'Your email patterns' to "Email Patterns".  Also lose all the trailing colons on the headers.

In the Account Summary I'd change 'edit account' to use whatever is the l10n string for Account Options or Account Settings.  Just use CSS to make it all lowercase via "text-transform: lowercase;"

Animations are worth it.

I think the ( Read Inbox ) probably needs to go.  Drafts has a similar problem and I think it'd be nice to solve them in similar ways.  Perhaps giving the count of messages or unread messages for drafts and inbox respectively.  Then offering a link to open the folder with the inbox/drafts folder icon next to it.

Drafts (#)                           (*) Open Drafts
----------------------------------------------------

Inbox (#)                             (*) Open Inbox
----------------------------------------------------

Alternate where we also try to show how many in total are starred.

Inbox (#) (# starred)                (*) Open Inbox
----------------------------------------------------

Maybe the Frequent Correspondents could have a similar feel as the inbox and drafts headers.

Frequent Correspondents              (*) Compose New
----------------------------------------------------

For buttons for filters, etc. I wonder if we could drop them in as a bottom row just before or after our system message space.

+----------------------------------------+
| Account Summary: $                     |
+----------------------------------------+
|                   |                    |
|                   |                    |
|                   |                    |
|                   |                    |
+----------------------------------------+
|                   |                    |
|                   |                    |
|                   |                    |
|                   |                    |
+----------------------------------------+
|   Filters  |  Search  |  Subscription  |
+----------------------------------------+

For the disconnected notification I was thinking we could add in a  notification like bar just below the account summary header.

+----------------------------------------+
| Account Summary: $                     |
+----------------------------------------+
| Notification space (offline / errors)  |
+----------------------------------------+
|                   |                    |
|                   |                    |
|                   |                    |
Attached patch new headings (obsolete) — Splinter Review
inbox button removed
inbox, drafts, and compose sections now have icons & clickable links, as per clarkbw.
padding on drafts fixed

wording changes made, except "frequent correspondents" is too long given the layout, so just "correspondents" for now.  I think this 2x2 grid doesn't really work right yet.

I haven't done anything about the extra buttons or the 'notification' area yet.

Note: the "Compose New" button exposes a bug in the composition dialog code -- the first time it's invoked before any folder views are setup, it fails to initialize.  I haven't figured out why yet.
Attachment #378742 - Attachment is obsolete: true
Attachment #379066 - Flags: review?(bugmail)
Attachment #378742 - Flags: review?(bugmail)
Hm sorry, but from which patch do I get this summaryUtils.js? I want to try this, but If I apply the protovis patch and the headings patch and than try to build Thunderbird I get an error:
"RuntimeError: file not found: content/summaryUtils.js"
Attached patch patch w/ summaryUtils.js (obsolete) — Splinter Review
Sorry, forgot that file!
Attachment #379066 - Attachment is obsolete: true
Attachment #379144 - Flags: review?
Attachment #379066 - Flags: review?(bugmail)
Attached patch and the dtd file (obsolete) — Splinter Review
Attachment #379185 - Flags: review?(bugmail)
Attached image Long subject and email address (obsolete) —
It seems to me the file content/loader.gif is also missing. With my own loader.gif it builds just fine, so seems to be the last missing part. And it looks nice (excepting my own ugly loader.gif :D ). I really like it.
One thing I found is, that if the subject or the email address is long then it is hard discontinued.
Attachment #379144 - Attachment is obsolete: true
Attachment #379144 - Flags: review?
Comment on attachment 379185 [details] [diff] [review]
and the dtd file

This is a fantastic piece of functionality.  I haven't nitted every location, but have tried to point out stylistic inconsistencies within the same file.  If you could do a pass on your patch to just normalize squiggly braces to be same line and double-check semicolons, that would be great.

I'm going to r- this because I need to do another pass and there are some things that I think need to be resolved one way or the other (ex: skin issues), but it looks very good.

Also, loader.gif is missing, as per nomis.

>diff --git a/mail/base/content/accountSummary.css b/mail/base/content/accountSummary.css
...
>+ * The Initial Developer of the Original Code is
>+ *   David Ascher <dascher@mozillamessaging.com>
>+ * Portions created by the Initial Developer are Copyright (C) 2009
>+ * the Initial Developer. All Rights Reserved.
>+ *
>+ * Contributor(s):
>+ *
>+ * Alternatively, the contents of this file may be used under the terms of

I am under the impression that MoMo gets to be the initial developer and you get to be a contributor.  This needs to be changed in multiple places, although it's okay in some too...
http://www.mozilla.org/MPL/boilerplate-1.1/index.html

>+/* XXX MAKE GENERIC SOMEWHERE! */
>+.star {
>+  width: 16px;
>+  height: 16px;
>+  margin-right: 0.5em;
>+  display: inline-block;
>+}
>+
>+.starred  .star {
>+    background-image: url("chrome://messenger/skin/icons/flaggedmail.png");
>+/*  background-image: url("chrome://messenger/skin/icons/flag-col.png");  linux/win */
>+}

I'm okay with the XXX, but what's with the commented out bit?  Is that for when this gets propagated across the skins?


>diff --git a/mail/base/content/accountSummary.js b/mail/base/content/accountSummary.js
>+/* note: this is in main chrome, it is not executed within the context of
>+  accountSummary.xhtml (primarily so that it has access to globals) */

Thank you for this comment!  I wish more files explained what they were up to.

>+/**
>+ * Open an email composition window, given an email address, and an
>+ * nsIncomingServer
>+ *
>+ * @param fullAddress
>+ *        a full email address (name + email)
>+ * @param server
>+ *        the nsIncomingServer from which we'll get the default identity
>+**/

Doc block style 2 of 3.

>+function _sendMailTo(fullAddress, server)
>+{
>+  var fields = Components.classes["@mozilla.org/messengercompose/composefields;1"]
>+    .createInstance(Components.interfaces.nsIMsgCompFields);
>+  var params = Components.classes["@mozilla.org/messengercompose/composeparams;1"]
>+    .createInstance(Components.interfaces.nsIMsgComposeParams);
>+  if (fields && params)
>+  {
>+    fields.to = fullAddress;
>+    params.type = Components.interfaces.nsIMsgCompType.New;
>+    params.format = Components.interfaces.nsIMsgCompFormat.Default;
>+    params.identity = accountManager.getFirstIdentityForServer(server);
>+    params.composeFields = fields;
>+    msgComposeService.OpenComposeWindowWithParams(null, params);
>+  }
>+}

It seems like this method's callers and msgHdrViewOverlay.js' SendMailToNode could use the same core code?  Perhaps refecator SendMailToNode to use this method, giving the method a public name and migrating it out of this file?

>+/**
>+ * Given a nsIMsgDBHdr, find it in the currently selected view, and select it.
>+ * 
>+ * @param message
>+ *        an nsIMsgDBHdr
>+**/
>+/* XXX This stuff should be in a global selection manager */
>+function _selectMessageInCurrentView(message) {
>+  OpenInboxForServer(GetSelectedMsgFolders()[0].server);
>+  gDBView.selectFolderMsgByKey(message.folder, message.messageKey);
>+}

This is an example of a case where being able to 'morph' a tab would be awesome.

The call to gDBView.selectFolderMsgByKey should be "gFolderDisplay.selectMessage(message);" once bug 474701 folder display layer lands (which may be after this lands).

>+/**
>+ * Given an nsIMsgDBFolder, find it in the currently selected view, and select it.
>+ * 
>+ * @param folder
>+ *        an nsIMsgDBFolder
>+**/
>+/* XXX This stuff should be in a global selection manager */
>+function _selectFolder(folder) {
>+  ShowThreadPane();
>+  gFolderTreeView.selectFolder(folder);
>+}

I think this should only be a call to gFolderTreeView.selectFolder(folder)?  Definitely after 474701 lands this function should not exist and that call should just be directly made.

>+function temperature(time, value) {

Suggest changing the name to something like "makeColorForTimeOfDay" if you are going to keep this in the global namespace.  Otherwise, push it into AccountSummary.

>+AccountSummary.prototype = {
...
>+  _enumerateFolders: function(server) {
...
>+  },
....
>+  _addSubFolders: function(folder, folders)
>+  {
....
>+  },

Since you already have to end up using fixIterator, using listDescendents would probably be faster overall...
http://mxr.mozilla.org/comm-central/source/mail/components/search/content/searchCommon.js#347
  
>+  summarize: function(server, contentDoc)
>+  {
...
>+    heading.innerHTML = "Account Summary: " + this._server.prettyName; // XXX l10n

XXX l10n...
  
>+    if (!inbox) { // Local folders, news, don't have inboxen
...
>+    } else {

else on new line.

>+      // find all messages in inbox
>+      let messages = [];
>+      for each (message in fixIterator(inbox.messages, Components.interfaces.nsIMsgDBHdr)) {
>+        messages.push(message);
>+      }
>+      this.idoc.getElementById('inboxCount').innerHTML = messages.length;
>+      let inboxButton = this.idoc.getElementById('inbox');
>+      let _server = this._server;
>+      inboxButton.addEventListener('click', function() OpenInboxForServer(_server), true);
>+      // sort them by date
>+      messages.sort(function (a,b) a.date < b.date);

If all you want is the 5 most recent messages, that could arguably done in a streaming fashion with a much lower memory impact.  In theory you could even use a DBViewWrapper to open the inbox, sort it, and then only expose the 5 headers you care about to XPConnect/garbage-collection hassles.  In fact, the DBViewWrapper is likely to be much faster about it too... (the one difficulty is that it currently will try and do an updateFolder on IMAP folders without fail, but that is an easy change.)  I'd ask bienvenu about what to do here.

As an aside, sort takes a compare function:
messages.sort(function (a,b) b.date - a.date)

>+  _lengthyBits: function()
>+  {
...
>+          for each ([i,email] in Iterator(emails))
>+          {

you're mixing squiggly brace styles again...

>+            // compute a score for this person based on the age of the email
>+            // For now, the score is 5 / number of elapsed days since the email
>+            // we might want something more refined.

This comment is confusing.  numDays has a minimum value of 5 because of the use of Math.max, but if the message is older than 5 days old, that will dominate.  The result is that the score for each recipient is boosted by 1 if the message was sent in the last 5 days, but decays with the inverse for older messages.

>+            let numDays = Math.max(5, ((new Date()).getTime() - (message.date/1000)) / (24*60*60*1000));

You can just use Date.now() instead of (new Date()).getTime()

>+            recipientScores[email] += 5/numDays;


>+    // we want to display the highest-scoring individuals
>+    foundRecipients.sort(function(a,b) recipientScores[a] < recipientScores[b]);

foundRecipients.sort(function(a,b) recipientScores[b] - recipientScores[a]);

>+  _showFactoids: function()
>+  {
...
>+    if (biggestFolderInN)
>+    {
...
>+      factoid.innerHTML = escapeXMLchars(this.strings["folderWithMost"] + biggestFolderInN.prettiestName + " ("+ biggestFolderSizeInN + ")");

80-character columns, please.  and below as well.

>+  _computeFolderSizes: function()
>+  {
....
>+      category */
>+    folderSizes.sort(function (a,b) a[1] < b[1])

folderSizes.sort(function (a,b) b[1] - a[1]);
note: semicolon

>+  _displayDrafts: function()
>+  {
>+    // We also look for pending drafts in specially designated folders
>+    let messages = [];
...
>+        for each (message in fixIterator(folder.messages,
>+                                         Components.interfaces.nsIMsgDBHdr))
>+          messages.push(message)
>+      }
>+
>+    // We sort the drafts by date, to get the most recent ones
>+    messages.sort(function (a,b) a.date < b.date);

the drafts folder should be small enough that I'm okay with this idiom in this case.

sort function again should be a comparator

>+  /**
>+   * Display a histogram showing the distribution of the times at which a
>+   * message was sent.
>+   * @data:
>+   *          a list containing 48 histogrammed bins of counts, mapping from
>+   *          midnight to midnight.
>+   **/

Doc block style 3 of 3...

>diff --git a/mail/base/content/accountSummary.xhtml b/mail/base/content/accountSummary.xhtml
...
>+ <!--  move to skin -->
>+    <link rel="stylesheet" media="screen" type="text/css"
>+          href="chrome://messenger/content/accountSummary.css"/>

Move it or avoid incriminating yourself...

>+  <div id="mozupdate" class="section">
>+    <iframe src="http://ascher.CA/test/test.html"
>+            style="height: 100px; width: 100%; border: 0px; overflow: hidden;"
>+            type="content-targetable"></iframe>
>+  </div>

I see bug 494090 exists to create the MoMo URL.  That needs to happen before this patch can land.

>diff --git a/mail/base/content/mailWindow.js b/mail/base/content/mailWindow.js

>+function summarizeCurrentFolder(doc)

Please add a doxygen comment to summarizeCurrentFolder that explains that it is called from within accountSummary.xhtml, providing that document as its argument.

>+{
>+  try {
>+    let selectedServer = GetSelectedMsgFolders()[0].server;
>+    if (!gAccountSummary)
>+      gAccountSummary = new AccountSummary()

semicolon demanded

>+    gAccountSummary.summarize(selectedServer, doc);
>+  } catch (e) {
>+    dumpExc(e);
>+  }
> }


I think you got yelled at in the multi-message summary patch too about dumpExc.  Given that error reporting can be lousy and only I run with my awesome error patch, I accept the necessity of something like dumpExc.  I propose you add a file called "errUtils.js" with your dumpExc (that gets sucked into the global namespace) and then we can fight about what dumpExc should actually be in some other bug.

>diff --git a/mail/base/content/summaryUtils.js b/mail/base/content/summaryUtils.js

Everything in this file save for _makeMessageDiv feels like it wants to be in a more generic utilities file.  Perhaps uiUtils.js.

This file mixes same-line function braces with next-line.  Please resolve; I suggest same-line given the current TB JS trend.

>+function makeSizeText(numBytes)

Needs doxygen.

>+/**
>+ * the equivalent of jQuery's addClass.  Avoids duplicates, nothing fancy.
>+ *
>+ * @param node
>+ *        any old DOM node
>+ * @param classname
>+ *        a string, which will be added as a CSS class
>+ */
>+function _mm_addClass(node, classname) {

"Add a CSS class to a DOM node if it does not already exist.  Equivalent to jQuery's addClass." sounds better.

>+/**
>+ * the equivalent of jQuery's removeClass.  Doesn't freak if the class name
>+ * isn't in the class attribute.
>+ *
>+ * @param node
>+ *        any old DOM node
>+ * @param classname
>+ *        a string, which will be removed from the class set.
>+ */
>+function _mm_removeClass(node, classname) {

"Remove a CSS class from a DOM node if it exists.  Equivalent to jQuery's removeClass." sounds better.

>+/**
>+ * Given a message, and a document in which to operate  (and an onclick handler),
>+ * create a structure like so:
>+ *
>+ * <div class="message">
>+ *   <div class="star">
>+ *   <div class="subject_and_author">
>+ *     Subject of the email (author of the email)
>+ *   </div>
>+ * </div>
>+**/
>+
>+// XXX investigate using E4X to make it sweeter
>+
>+function _makeMessageDiv(message, doc, onclick, justsubject)

This should be in some form of javascript namespace construct, not top-level.

>diff --git a/mail/locales/en-US/chrome/messenger/accountSummary.dtd b/mail/locales/en-US/chrome/messenger/accountSummary.dtd
>diff --git a/mail/locales/en-US/chrome/messenger/accountSummary.properties b/mail/locales/en-US/chrome/messenger/accountSummary.properties
...
>+firstmidnight=midnight
>+lastmidnight=midnight

Localization notes, please, including a brief overview at the top of each file.  It's probably okay to link to a brief description of the feature on the wiki (which other could then augment).  For example in terms of desired specific notes, the difference between firstmidnight and lastmidnight is not really obvious.

https://developer.mozilla.org/En/Localization_notes

>diff --git a/mailnews/base/util/colorUtils.jsm b/mailnews/base/util/colorUtils.jsm
>+function hex2rgb(hexString)
>+function Color(r, g, b, a) {
>+Color.prototype = {
>+  toHSV: function () {
>+  toHSL: function () {
>+  lighter: function (aStep) {
>+  darker: function (aStep) {
>+  brighter: function(aStep) {
>+}
>+function hsla(hue, saturation, lightness, alpha) {
>+function hsva(hue, saturation, value, alpha) {

These functions / methods are exposed but lack doxygen-ish documentation.
Attachment #379185 - Flags: review?(bugmail) → review-
Attached image updated bird look
Spent quite a while drawing a new iteration of the bird last night and failed.
Apparently my girlfriend felt sorry for me, for she saved the day with a sketch for this bird that I found added to the sketch paper this morning. :)
Made the sections use a table layout (still using divs though, but appear as a table, so not evil to people who use screen readers etc.) and some other small changes (some hackish as it's calls some files on my server).
Attachment #379696 - Attachment is patch: true
Attachment #379696 - Attachment mime type: application/octet-stream → text/plain
Attached patch patch for review v2 (obsolete) — Splinter Review
Thanks for all the great review comments.

I think I've handled all of them, except for:

1) URLs still need fixing when the dependent bug lands
2) there's one call that needs changing if this lands after the folder display patch
3) I haven't yet talked to bienvenu about:

----

>+      // find all messages in inbox
>+      let messages = [];
>+      for each (message in fixIterator(inbox.messages, Components.interfaces.nsIMsgDBHdr)) {
>+        messages.push(message);
>+      }
>+      this.idoc.getElementById('inboxCount').innerHTML = messages.length;
>+      let inboxButton = this.idoc.getElementById('inbox');
>+      let _server = this._server;
>+      inboxButton.addEventListener('click', function() OpenInboxForServer(_server), true);
>+      // sort them by date
>+      messages.sort(function (a,b) a.date < b.date);

If all you want is the 5 most recent messages, that could arguably done in a
streaming fashion with a much lower memory impact.  In theory you could even
use a DBViewWrapper to open the inbox, sort it, and then only expose the 5
headers you care about to XPConnect/garbage-collection hassles.  In fact, the
DBViewWrapper is likely to be much faster about it too... (the one difficulty
is that it currently will try and do an updateFolder on IMAP folders without
fail, but that is an easy change.)  I'd ask bienvenu about what to do here.

----

I've also included most of andreas's css fixes (the patch as listed seemed to strip out more than i think intended, and some of the padding didn't look right on pinstripe.

I've tweaked it to use css in skin/, but so that all include a shared common css file, so we can tweak what's needed in very short per-theme files.  

Note: after talking to philor, i'm reluctantly bringing in the "makeSizeText" call inside of AccountSummary, as l10n makes it impossible to do in a utility function apparently.
Attachment #379185 - Attachment is obsolete: true
Attachment #379836 - Flags: review?(bugmail)
Attached patch patch for review v3 (obsolete) — Splinter Review
a minor tweak to force fixIterator to return nsIMsgFolders always (showed up as a bug against gmail accounts)
Attachment #379836 - Attachment is obsolete: true
Attachment #379840 - Flags: review?(bugmail)
Attachment #379836 - Flags: review?(bugmail)
Looks nice. But one quetsion. In my (own) german version I used for the editaccount.label capital letters and lower case letters. But in the application the label consists only of lower case letters. Is this consciously?
(In reply to comment #40)
> Looks nice. But one quetsion. In my (own) german version I used for the
> editaccount.label capital letters and lower case letters. But in the
> application the label consists only of lower case letters. Is this consciously?

That's part of the patch, I didn't want the settings link to stand out too much on the page.
Depends on: 495109
(In reply to comment #41)
> (In reply to comment #40)
> > Looks nice. But one quetsion. In my (own) german version I used for the
> > editaccount.label capital letters and lower case letters. But in the
> > application the label consists only of lower case letters. Is this consciously?
> 
> That's part of the patch, I didn't want the settings link to stand out too much
> on the page.

OK, than it's not a Bug, it's a feature :D 
But in some languages this will look a little curious...
After applying "patch for review v3" I can't read emails from my inbox anymore in the standalone window. If I doubleclick on an email in my inbox I only get the error message:

XML-Verarbeitungsfehler: nicht wohlgeformt
Adresse: chrome://messenger/content/messageWindow.xul
Zeile Nr. 96, Spalte 125:                oncommand="SendMailToNode(findEmailNodeFromPopupNode(document.popupNode, 'emailAddressPopup').getAttribute("fullAddress"))"/>
----------------------------------------------------------------------------------------------------------------------------^

(Sorry, I only have this german error message)
oops!  Thanks for that bug report, will fix right away.

On the lowercase thing: if it really looks wrong because of particular linguistic constraints, then from my POV it's fine if the localizer decides that it needs to be capitalized.  In English, it's acceptable for it to be lower case.
Attached patch patch for review v4 (obsolete) — Splinter Review
fix for the bad quoting causing the problem in the last comment.
Attachment #374475 - Attachment is obsolete: true
Attachment #374476 - Attachment is obsolete: true
Attachment #379203 - Attachment is obsolete: true
Attachment #379696 - Attachment is obsolete: true
Attachment #379840 - Attachment is obsolete: true
Attachment #379999 - Flags: review?(bugmail)
Attachment #379840 - Flags: review?(bugmail)
(In reply to comment #40)
> Looks nice. But one quetsion. In my (own) german version I used for the
> editaccount.label capital letters and lower case letters. But in the
> application the label consists only of lower case letters. Is this consciously?

From a localizers (German) point of view, we should/must _not_ only use lowercase letters. So if in en-US lowercase is desired, IMHO this should be implemented in the *.properties/*.dtd files - not in CSS.
Alexander: good point -- can you file a bug & assign it to me, please?  thanks!
Depends on: 495485
Attached patch patch for review v5 (obsolete) — Splinter Review
1) get rid of _mm_addClass/etc., as they've landed
2) make lowercase decision in the DTD, not in CSS, to let localizers do what's right for their locales
3) get rid of loader, as it's not actually animating when the JS thread is chugging along, so it fails as an indeterminate progress notification.  Alternatives would be welcome.
Attachment #379873 - Attachment is obsolete: true
Attachment #379999 - Attachment is obsolete: true
Attachment #380896 - Flags: review?(bugmail)
Attachment #379999 - Flags: review?(bugmail)
Don't know if this is relevant, but after displaying the new account summary page (uses patch 4), I get an AttributeParseWarning in the error console about an unexpected value NaN in accountSummary.xhtml

Warnung: Unerwarteter Wert NaN beim Parsen des Attributs width.
Quelldatei: chrome://messenger/content/accountSummary.xhtml
Zeile: 0

and

Warnung: Unerwarteter Wert NaN beim Parsen des Attributs height.
Quelldatei: chrome://messenger/content/accountSummary.xhtml
Zeile: 0
Attached patch latest version (obsolete) — Splinter Review
mostly css fixes
Attachment #380896 - Attachment is obsolete: true
Attachment #381192 - Flags: review?(bugmail)
Attachment #380896 - Flags: review?(bugmail)
I have an account with no emails in the Inbox, no emails in the drafts folder, no emails in the Templates folder, one email in my sent folder and no emails in the trash. But the summary page says me in the Space Usage part, my largest folder is the Inbox with 2.5 MB (but its empty). And inside the blue curl I see a value of "2.5 MB" instead of "0 MB".
It seems this patch is now bit-rotten, because mail/base/content/mailWindow.js and mailnews/base/util/Makefile.in failed to apply (and one other, but I don't remember).
(In reply to comment #50)
> Created an attachment (id=381192) [details]
> latest version
> 
> mostly css fixes

Confirming bitrot of this patch as reported by Nomis101. I'd leave to davida to obsolete it. :)
Attachment #381192 - Attachment is obsolete: true
Attachment #381192 - Flags: review?(bugmail)
Attached patch De-bitrotted patch (obsolete) — Splinter Review
Comment on attachment 384976 [details] [diff] [review]
De-bitrotted patch

trying this out
Attachment #384976 - Attachment is patch: true
Attachment #384976 - Attachment mime type: application/octet-stream → text/plain
Attached patch updated account3 patch (obsolete) — Splinter Review
updated this a little bit and made sure it works on linux.  should also work on windows but I think the icons will be broken right now.

you still need the latest protovis patch applied, attachment 378744 [details]
Attachment #384976 - Attachment is obsolete: true
(In reply to comment #56)
> you still need the latest protovis patch applied, attachment 378744 [details]

except the protovis patch is attachment 378743 [details] [diff] [review], that other one is a screenshot... do not apply!
despite being the one who began the work on bug 468751 ... i did not pay attention to the comments and screwed this patch up on Vista because of it.

This fixes the account central for Vista and has some added CSS to make the correct icons show.  I didn't test this in XP (as usual) so I'll leave that up to davida because he loves XP :)
Attachment #385164 - Attachment is obsolete: true
Some initial xhtml+css for the bird and some other small fixes.
David, we wouldn't actually hold beta 3 for this, would we?  If that's correct, please re-target to b4.
Moving out to b4, as per drivers discussion.  If it happens to land in time for b3, great!
Target Milestone: Thunderbird 3.0b3 → Thunderbird 3.0b4
Some look and feel fixes to apply on top of Bryans patch.
* Gradient in header, like attachment #382159 [details] [diff] [review] for bug #454829
* Added the inbox icon and fixed the star for gnomestripe
* Background from website
* Updated mozilla update (need to find somewhere to host these)
* Indent all the items 16px to the left so starred messages don't get pushed to the right.
One unresolved issue is that the inbox area is getting a bit wide and breaks into rows easy, so we still need to figure out exactly what's the best way to do that is. Either cut the name or the address, or always break it into two rows. Opinions?
Attached patch WIP v2Splinter Review
This incorporates some security fixes, and deals w/ recent bitrot.
Attachment #378743 - Attachment is obsolete: true
Whiteboard: [b3ux][needs review][needs more design love] → [b3ux][needs review][needs more design love][has l10n impact]
Most likely won't make the 3.0 cut, but luckily there's a 3.1 after that.
Flags: blocking-thunderbird3.1+
Flags: blocking-thunderbird3-
Flags: blocking-thunderbird3+
Target Milestone: Thunderbird 3.0b4 → ---
We'd love to get this, but given 3.1's focus on being a soft landing pad for Tb2 users at major update time, I don't think we'd hold 3.1 for this bug, so marking blocking- and wanted+.

David, do you still want to own this bug, or would it make sense to open it up for anyone who is interested in hacking on it?
blocking-thunderbird3.1: --- → -
Flags: blocking-thunderbird3.1+ → wanted-thunderbird+
Assignee: david.ascher → nobody
Component: General → Mail Window Front End
QA Contact: general → front-end
Status: ASSIGNED → NEW
Duplicate of this bug: 573211
Duplicate of this bug: 404335
Attached patch unbitrotted patch "WIP v2" (obsolete) — Splinter Review
I was curious if this old patch still works with current trunk. So I've unbitrotted it. And yes, it still works (exclusive of the bird). :-)
The most bitrotted part was msgHdrViewOverlay.js. In the old patch it was

-function SendMailToNode(emailAddressNode)
+function SendMailToNode(emailAddress)

and now it is

-function SendMailToNode(addressNode)
+function SendMailToNode(emailAddress)

I hope this doesn't break something. I've attached the unbitrotted patch (applies to current trunk), so everyone who is willing to work on this doesn't need to bitrot it first.
Thanks, Nomis!
Severity: normal → enhancement
(In reply to comment #70)
> Created attachment 482513 [details] [diff] [review]
> unbitrotted patch "WIP v2" 
> I hope this doesn't break something. I've attached the unbitrotted patch
> (applies to current trunk), so everyone who is willing to work on this doesn't
> need to bitrot it first.

Nomis do you feel that you could complete the bug so we can get this into the tree ?
(In reply to comment #72)
> (In reply to comment #70)
> > Created attachment 482513 [details] [diff] [review]
> > unbitrotted patch "WIP v2" 
> > I hope this doesn't break something. I've attached the unbitrotted patch
> > (applies to current trunk), so everyone who is willing to work on this doesn't
> > need to bitrot it first.
> Nomis do you feel that you could complete the bug so we can get this into the
> tree ?

Depends on what "complete" means. I can make that the current patch applies, works, and looks good on curent trunk. But I can't modify it in a broad way.
(In reply to comment #63)
> Created attachment 386242 [details]
> screenshot of patch in action
> 
> One unresolved issue is that the inbox area is getting a bit wide and breaks
> into rows easy, so we still need to figure out exactly what's the best way to
> do that is. Either cut the name or the address, or always break it into two
> rows. Opinions?

David, Andreas or Bryan, could you please make a statement of what's needed before we can consider this patch complete? The comment above seems to point out the latest remaining issue but I haven't followed the discussion closely, so there might be other items left that we need to fix before considering this done.
In terms of what needs done, I'm pretty sure that Nomis101's update will break sending mail as it is now (specifically, SendMailToNode is broken). Some of the bitrot in that function is from me, so I could take a look at this and get the remaining issues fixed if Nomis101 doesn't want to. Alternately, I can provide guidance for how to fix stuff (once we know what needs fixed, of course).
We'll also need ui-review (Andreas or Bryan can probably speak to what's needed for that) as well as automated tests for this functionality, and then reviews.
(In reply to comment #75)
>  so I could take a look at this and get the
> remaining issues fixed if Nomis101 doesn't want to. 
This would be nice, because I'm a bit bussy currently and have no idea how to write automated tests.
I also have a unbitrotted patch that applies and merged "WIP v2" + "css and html fixes" + "some look&feel stuff", I will test with this patch if it breaks sending mail.
The breakage will probably occur if you click an address in the message header and select "Compose Message To".
(In reply to comment #78)
> The breakage will probably occur if you click an address in the message header
> and select "Compose Message To".

Yes, you are right. This is broken with the patch. But account central looks very nice with the merged patch.
Since we started this work, we've tried to do a lot of experimenting on UI in add-ons.  I don't recall the state of this code, but would it be hard to turn the existing patch into an add-on that could be iterated on more easily than in trunk?
Attached patch This is what I currently have (obsolete) — Splinter Review
This is the current merged patch I have, applies to current trunk, account central looks OK and works (on OS X), but "Compose Message To" is broken. Thats all I can do here at the moment, sorry...
Attachment #482513 - Attachment is obsolete: true
Attached patch Finish up fixing bitrot (obsolete) — Splinter Review
This should fix the rest of the bitrot. I also changed the formatting of the names for the inbox message to use the FormatDisplayName function from bug 474721 for consistency.

Taking this for now, since it'd be nice to get this into 3.3...
Assignee: nobody → squibblyflabbetydoo
Attachment #501138 - Attachment is obsolete: true
Status: NEW → ASSIGNED
:clarkbw, do you have any opinions on attachment 386242 [details]? (See comment 63 and comment 82 for more info.)
Here's just an idea (compare to attachment 386242 [details]): use theme-dependent colors where possible in the account summary. Note that there's a weird change in the colors on the bottom panes. That's from the background image at the bottom of the window. It's present in the earlier attachment too, but it's more obvious now because the bottom-left pane uses a mostly-transparent background.

Some other notable changes in this that will be in the next patch I upload (though they may of course end up getting removed later if people don't like them):
* Long email subjects get truncated
* Mail addresses in the reading pane are always on a separate line
* Uses -moz-linear-gradient instead of gradient images
* The little speech bubble at the bottom is pure CSS now (I had to get clever
  with this one)
Attachment #508084 - Flags: feedback?(clarkbw)
Comment on attachment 508084 [details]
Use theme-dependent colors

looks awesome!
Attachment #508084 - Flags: feedback?(clarkbw) → feedback+
Updated patch. Just so everything is in one place, here are all the changes I've made:

* Theming should work on all platforms
* Themes now depend on OS color scheme
* Uses -moz-linear-gradient instead of gradient images
* Mail addresses in the reading pane are always on a separate line
* Inbox messages, correspondents, and drafts use xul:labels to get trailing
  ellipses (maybe one day text-overflow:ellipsis will work...)
* The speech bubble at the bottom is pure CSS now
* The HTML is slightly more semantic (uses h1, h2, ul instead of just divs)
* Better handling of mostly-empty accounts (i.e. add some placeholder text)

Stuff left to do:
* Pull out more theme-specific styles from the global CSS file
* Make things behave better on tiny screens
* Do something friendly for completely empty (i.e. probably brand-new) accounts
* Make graphs depend on OS color scheme too
* Make the mozupdate speech bubble actually do stuff
* Tests!

:davida, since you worked on this originally, I'm asking for feedback from you (esp. on the todo list), but feel free to pass that on to anyone else if you think they'd have better advice.
Attachment #507707 - Attachment is obsolete: true
Attachment #511149 - Flags: feedback?(dascher)
Wow, totally impressed.  I'm really happy to see you picking this up.

I think the one thing I'm worried about is that I suspect various bits of the math are wrong, and/or the design is really not polished enough.  In particular:

* the timeline needs checking -- my histogramming code isn't tested at all, and I fear it likely has lots of off-by-one errors.

* the pie chart may or may not be useful, and/or imply the wrong thing for people.  In particular, I don't recall how I deal with hierarchical folders, and I don't even remember what size metrics we're using -- I suspect I'm just adding up the message sizes -- it's not clear to me that that's accurate for folders that haven't been compacted in a while (recently found an INBOX that was >1G, and then <100k after compacting).  We probably want clicking on the folder names to open the folder in a tab or something.

* we probably want to update protovis to a more modern version, but that's likely tracked in a separate bug

In general -- don't take the design that I worked on as gospel -- we should feel free to explore different tweaks.

Have you considered how hard it'd be to make an add-on out of this, to allow for people to give feedback before it lands?

But overall, I'm stoked.
Attachment #511149 - Flags: feedback?(dascher) → feedback+
Sounds reasonable. I've got a basically-working version of this as an extension that (theoretically) is compatible with 3.1 (maybe even 3.0!) that I'll upload to this bug this weekend. Once I'm reasonably confident that it at least mostly works and that I have everything set up to make it easy to drop this back into Thunderbird proper, we can probably release it as an experiment.
Attached file The above patch as an extension (obsolete) —
Here's the above patch as an extension, with a few minor bug fixes. It should be compatible with Thunderbird 3.1+ (maybe it even works with 3.0, but I didn't bother trying that). If anyone wants to try it out and at least do a first pass over it to make sure nothing is horribly broken, that'd be nice. Then we can get this published to the Mozilla Labs site for more people to look at it.
Oh, note that the little bird and the speech bubble are just hosted on my personal web space at the moment, so that should probably get changed before we actually publish this.
Ha nice, in this moment I was builing a TB version with your patch to see how it looks on Mac. Now I better used your extension. Looks nice on Mac (but need localization) and works good with my TB 3.3, in my quick look test. Do you need a Mac screenshot?
Tried the xpi here in tb3.3 looks nice.
Observations:
I wonder if total HD space available could be somehow included in the "space usage" section.

Feeds and Newsgroups are just as important as mail accounts to me. Could the view be extended there also.

The "sent" folder is always one that I forget to cleanup. Maybe give that a special place in the "pie" Likewise for "trash"

Email patterns only tell me that I'm stayin up way too late some nights :)
(In reply to comment #91)
> Ha nice, in this moment I was builing a TB version with your patch to see how
> it looks on Mac. Now I better used your extension. Looks nice on Mac (but need
> localization) and works good with my TB 3.3, in my quick look test. Do you need
> a Mac screenshot?

Sure, screenshots couldn't hurt.

(In reply to comment #92)
> Tried the xpi here in tb3.3 looks nice.
> Observations:
> I wonder if total HD space available could be somehow included in the "space
> usage" section.

I don't know if that's necessary here, but I think there are plans to do something like that in the prefs when you configure autosync and such. It's already there in the migration assistant.

> Feeds and Newsgroups are just as important as mail accounts to me. Could the
> view be extended there also.

Eventually, that's the plan, but I'm probably going to work on the folder summaries (bug 492158) before that, since that will probably affect more people.

> The "sent" folder is always one that I forget to cleanup. Maybe give that a
> special place in the "pie" Likewise for "trash"

Maybe a menu where you can select folders that should always appear and folders that should never appear would be useful. It would also let Gmail users hide the "All Mail" folder if they so choose.
with the "patch as extension" xpi and today's nightly build I get
Error: Permission denied for <resource://overview> to call method UnnamedClass.toString
and
Error: uncaught exception: unknown (can't convert to string)

and screen per screenshot
Mozilla/5.0 (Windows NT 5.0; rv:2.0b13pre) Gecko/20110306 Thunderbird/3.3a3pre ID:20110306030111
Works fine here.
I'm getting an empty view for the email pattern and no error message in the error console that might relate to that.

clicking on the feedback link doesn't work.

Do you take the archive folder into account as I have 4 years of mostly facebook mail archived and the  Space usage doesn't say anything about it, while I'm sure those folders are pretty big.
Attached image Some observations on UI
Thanks for that feature. It's rock!



clicking on the feedback link doesn't work.
+1

Not feeling all right
---------------------------
When I select "Local Fodlers" and there is a message (no Inbox found), there is still link Open Inbox.



I want to see
----------------------

Can I see how much MB every folder is?
Attached image More UI observations
Sorry for flooding, but IT will be great if I can see info for ALL my folders. I am using shared Folders with my Kolab server and It will be very helpful if I can see size of all folders NOR switching to folder mode with proper information.

Thanks for the great job again.

//Bogo
(In reply to comment #96)
> I'm getting an empty view for the email pattern and no error message in the
> error console that might relate to that.

Nothing at all, or "no statistics available"? If the latter, it can't find your sent folder.

> clicking on the feedback link doesn't work.

It's not meant to (yet). The speech bubble is just a mockup hosted on my personal web space, so it doesn't actually work at the moment. That's why it's still talking about the "upcoming" Thunderbird 3. :)

> Do you take the archive folder into account as I have 4 years of mostly
> facebook mail archived and the  Space usage doesn't say anything about it,
> while I'm sure those folders are pretty big.

I do, but the size is non-recursive (as far as I know), so if your archive folder has lots of subfolders, it won't count those for the size of the general archives folder.
(In reply to comment #97)
> When I select "Local Fodlers" and there is a message (no Inbox found), there is
> still link Open Inbox.

Good catch.

> Can I see how much MB every folder is?

(In reply to comment #98)
> Sorry for flooding, but IT will be great if I can see info for ALL my folders.
> I am using shared Folders with my Kolab server and It will be very helpful if I
> can see size of all folders NOR switching to folder mode with proper
> information.

These probably won't happen here, since that could get unwieldy fast, but I do think it'd be useful to show the size of a folder in the folder properties (when you right-click).
(In reply to comment #99)
> (In reply to comment #96)
> > I'm getting an empty view for the email pattern and no error message in the
> > error console that might relate to that.
> 
> Nothing at all, or "no statistics available"? If the latter, it can't find your
> sent folder.

It says When you send email
        
        
          
          
            
            of the emails you send are replies

On my three accounts (2 are gmail ones, one is a local pop one)



> > Do you take the archive folder into account as I have 4 years of mostly
> > facebook mail archived and the  Space usage doesn't say anything about it,
> > while I'm sure those folders are pretty big.
> 
> I do, but the size is non-recursive (as far as I know), so if your archive

ok so that's the reason.
(In reply to comment #94)
> Created attachment 517325 [details]
> account summary screen shot
> 
> with the "patch as extension" xpi and today's nightly build I get
> Error: Permission denied for <resource://overview> to call method
> UnnamedClass.toString
> and
> Error: uncaught exception: unknown (can't convert to string)
> 
> and screen per screenshot

the above is my laptop. things going on in that machine
a) account summary for imap accounts shows only inbox message count; no space usage, no drafts count, etc.
b) my accounts are defined with Sent message saving to Inbox, FWIW
C) local folders summary appears and displays space usage, but no message counts (including Inbox, but that's OK because Inbox folder is missing from my local folders. blwh)
d) I often disable and reenable global search on this laptop - so perhaps that is related.  The account settings are otherwise similar to my work machine, where accountsummary.xpi where account summary works [1].


[1] work machine:
* account summary displays fine for all account types
* folder summary does not display, don't see why. nothing in error console
* my accounts are defined with Sent message saving to Inbox, FWIW (same as laptop)
Attached image Screenshot on Mac
(In reply to comment #93)
> (In reply to comment #91)
> > Ha nice, in this moment I was builing a TB version with your patch to see how
> > it looks on Mac. Now I better used your extension. Looks nice on Mac (but need
> > localization) and works good with my TB 3.3, in my quick look test. Do you need
> > a Mac screenshot?
> 
> Sure, screenshots couldn't hurt.

On my 13" MacBook with the extension it looks like this, in full screen.
For deeper folder analysis we also had bug 492158 for a single folder summary.
Attachment #517325 - Attachment description: account summary screen shot → bad looking account summary screen shot
Compose New  lacks an icon


(In reply to comment #87)
> * we probably want to update protovis to a more modern version, but that's
> likely tracked in a separate bug

namely Bug 517978 - Upgrade Protovis to 3.0.
v3.2 is current release http://vis.stanford.edu/protovis/docs/releases.html
See Also: → 517978
(In reply to comment #105)
> Compose New  lacks an icon
> 
> 
> (In reply to comment #87)
> > * we probably want to update protovis to a more modern version, but that's
> > likely tracked in a separate bug
> 
> namely Bug 517978 - Upgrade Protovis to 3.0.
> v3.2 is current release http://vis.stanford.edu/protovis/docs/releases.html

protovis has largely been obsoleted by d3 at this point; unless there are known deficiencies with the version of protovis currently shipped in Thunderbird, I would suggest not bothering to update it.  I think our version has some minor modifications to make it friendlier to living in mozilla and debug builds, so it's not just a straightforward thing to drop in a new version.
This patch fixes a couple minor bugs, gives the header position:fixed (like the multimessage summary header), and restructures quite a bit of the internals.

I don't know if it will fix anyone's issues since I'm not actually sure what's causing them, but it might make it easier for people to debug (I got rid of some try blocks that just dumped the errors to the terminal instead of letting them go in the error console).
Attachment #517297 - Attachment is obsolete: true
Question for everyone: what do you think should be focused when you click on one of the inbox items in the summary?

1) The folder pane (this is how it currently works, and it seems wrong)
2) The thread pane
3) The message pane (instinctively, I prefer this one)
Message pane !
The buildings graphics seems to create a line cutting through the two lower panes. Will fix that graphics to have it include some kind of gradient at the top to make it look a bit smoother.
(work machine)
with v2, one of my 5 accounts is not displaying space usage and email patterns.
no idea why. 
happens also on a second machine.
nothing in the error console.
This is looking slicker and slicker; nice work guys.  For what it's worth, for at least one of my accounts, I'm seeing 3 of the 4 panels not filled in, and this in the error console:

Error: authoNnode is not defined
Source File: chrome://accountsummary/content/accountSummary.js
Line: 781
Error: authoNnode is not defined
Source File: chrome://accountsummary/content/accountSummary.js
Line: 781 
here too. don't know how I missed it earlier
Whoops, that happens when you have a draft with no subject. Fixed in this version. Also, I fixed the "Open Inbox" link, which was broken, and I changed the threshold for the top folders chart. Now it shows up to the top 5, but only shows folders that take up at least 2% of the total space.
Attachment #517626 - Attachment is obsolete: true
(In reply to comment #92)
> I wonder if total HD space available could be somehow included in the "space
> usage" section.

+1

> Feeds and Newsgroups are just as important as mail accounts to me. Could the
> view be extended there also.

+1 

> Email patterns only tell me that I'm stayin up way too late some nights :)

+1: for me is less usefull: maybe is better to use this section to display other informations. For example use this sections to enlarge "correspendents", or section "Inbox", or to add section with lightining tasks (when lightnining is installed)...

In anyway is a very great work! Thanks Jim :-D
minor issue (on extension v.3):

* when compact operation is performed and account summary is displayed, the "disk usage" section should be updated
Can you bump the maxVersion of your extension to 3.3a4pre, so it works with latest nightlys?
Ok, updated. I improved the text wrapping on the headings so that things fail a little more gracefully on small screens and also changed the wording of the main heading.
Attachment #517816 - Attachment is obsolete: true
Who should I talk to about putting the iframe with the little speech bubble somewhere on mozillamessaging.com? I assume that's where we'd want it to go, anyway.
(In reply to comment #119)
> Who should I talk to about putting the iframe with the little speech bubble
> somewhere on mozillamessaging.com? I assume that's where we'd want it to go,
> anyway.

Sancus or Gozer would handle that, I think.
(In reply to comment #120)
> 
> Sancus or Gozer would handle that, I think.

I can find a place for it if you point me to the right file/patch -- might want to create another bug for that as this one seems to have a lot going on in it. Feel free to assign to me.
Hm, it looks like that falls under bug 494090. Since I'm not 100% sure what the page should contain yet, I'll hold off on that bug for the moment...
Attached file Extension v5: add folder summary (obsolete) —
I've updated the extension to include the folder summary from bug 492158. Screenshots are available in that bug. The code for loading the folder summary is a bit scary, so I encourage people to test it. There are some helpful dump statements to make sure that we're only loading the folder summary once.

Up next, I'm going to put this on bitbucket (or maybe github), fix up a few issues, get the snippet iframe hosted on mozillamessaging.com somewhere, and then hopefully release this to the public for broader testing.
Attachment #519600 - Attachment is obsolete: true
Works as described on my Mac. :-) Is localizing the extension also planed?
All the strings are (or should be) defined as localizable entities, so any bilingual users with an interest in seeing this in their language can send me patches (or pull requests when I get the public repo set up). Unfortunately, I only know English and bits of Latin, so I'm not much help here.
(In reply to comment #123)
> Created attachment 524327 [details]
> Extension v5: add folder summary
> 
> I've updated the extension to include the folder summary from bug 492158.
> Screenshots are available in that bug. The code for loading the folder summary
> is a bit scary, so I encourage people to test it. There are some helpful dump
> statements to make sure that we're only loading the folder summary once.
> 
> Up next, I'm going to put this on bitbucket (or maybe github), fix up a few
> issues, get the snippet iframe hosted on mozillamessaging.com somewhere, and
> then hopefully release this to the public for broader testing.

With this version installed I take a huge performance hit when clicking any of my folders for RSS feeds or newsgroups.  I'm guessing the freeze is while it loads all the statistics for the folder summary.  For comparison some of these folders have upwards of 15k or 20k of messages in them (maybe I should clean them out).  Even my 4k Bugzilla folder on my mail account loads a bit slow, however.

Also, I don't show the message pane (and therefore the folder summary), maybe you should bail out early if the message pane isn't shown?

It looks really awesome though! Keep up the good work. :)
(In reply to comment #125)
> All the strings are (or should be) defined as localizable entities, so any
> bilingual users with an interest in seeing this in their language can send me
> patches (or pull requests when I get the public repo set up). Unfortunately, I
> only know English and bits of Latin, so I'm not much help here.

Of course, no problem, I will send you the german localized files in a few days. :-)
(In reply to comment #126)
> With this version installed I take a huge performance hit when clicking any of
> my folders for RSS feeds or newsgroups.  I'm guessing the freeze is while it
> loads all the statistics for the folder summary.  For comparison some of these
> folders have upwards of 15k or 20k of messages in them (maybe I should clean
> them out).  Even my 4k Bugzilla folder on my mail account loads a bit slow,
> however.

I'm going to change this around to let the message processing yield to other Javascript "threads". I figure I can probably process about 500-1000 messages at a time without anyone noticing hangs. I've mostly finished this already, though now I probably need a "loading..." message for big folders.

(In reply to comment #127)
> Of course, no problem, I will send you the german localized files in a few
> days. :-)

Thanks, I'll merge this in.
The lag in accumulating data for the folder summary can be quite long.
With this low end P3 machine and an 82,000 message newsgroup it took about 1 minute (dead ui in the process)
The data was interesting, even for newsgroups, so I hope you can get some "thread yielding" working. Otherwise maybe a way to ignore newsgroups (or just analyze the last x number of messages.)

The 2nd problem is that Go>>Mail start page no longer works on non-default locations. I use that feature to get my local weather forecast. There appears to be web activity loading the url, but the page never renders.
(I'm mentioning non-default locations because I thought I saw the default work on another PC today, but just on initial TB startup)
(In reply to comment #129)
> The lag in accumulating data for the folder summary can be quite long.
> With this low end P3 machine and an 82,000 message newsgroup it took about 1
> minute (dead ui in the process)
> The data was interesting, even for newsgroups, so I hope you can get some
> "thread yielding" working. Otherwise maybe a way to ignore newsgroups (or just
> analyze the last x number of messages.)

I've already got it working, I just need to make a little "loading..." box so people aren't confused when it takes a while. :)

> The 2nd problem is that Go>>Mail start page no longer works on non-default
> locations. I use that feature to get my local weather forecast. There appears
> to be web activity loading the url, but the page never renders.
> (I'm mentioning non-default locations because I thought I saw the default work
> on another PC today, but just on initial TB startup)

The start page is probably going away (the original patch in bug 492158 removed it entirely), but you'll be able to do something similar with the iframe in the account/folder summary (that's the thing with the cartoon bird). I just haven't hooked it up to a pref yet.
Can I suggest that you limit the number of messages you look at, for large folders? E.g., if there are 80000 messages, only look at the last 10000? If you really want to look at all of the messages, you could populate the rest of the data at a much lower priority.
Is there any guarantee on the order of messages from nsIMsgFolder::messages? Ideally I'd be able to get the N most recent messages.
the guarantee is that EnumerateMessages goes in order that the messages were added to the folder, and ReverseEnumerateMessages starts at the end and works its way back.
Attached image bugs-in-action
Thanks for implementing it: it's very nice.
With v5, I have a little issue: (see bugs-in-action attached):
STR:
1. go into Inbox and select a non collapsed message [A];
2. go into another folder: v5 show folder summary;
3. when return into Inbox where message [A] is select, preview pane is in "collapsed threads" mode


Another question: if Tag section show tags and his related occurrences, for me is unclear the section with colored "points": is redundant
(In reply to comment #134)
> 1. go into Inbox and select a non collapsed message [A];
> 2. go into another folder: v5 show folder summary;
> 3. when return into Inbox where message [A] is select, preview pane is in
> "collapsed threads" mode

This works for me. I'm assuming you mean when you've explicitly expanded all threads with * right? Otherwise, things behave like they did before: previously-expanded threads are collapsed except for when the previously-selected message is reselected (if you toggled that pref as recommended, then you'll see all threads collapsed, but you can select the last-selected message in the summary and get back to how things were for that thread).

> Another question: if Tag section show tags and his related occurrences, for me
> is unclear the section with colored "points": is redundant

I'm not sure what you mean here. Could you be more specific?
Attached image Top-Tags redundance
(In reply to comment #135)

> > Another question: if Tag section show tags and his related occurrences, for me
> > is unclear the section with colored "points": is redundant
> 
> I'm not sure what you mean here. Could you be more specific?

See attached Top-Tags-redundance (it's a trivial question of course):
In this section we have a number of colored points that is the number of tagged messages (see the green rectangle).
Under this sequence of points, we have the tags in use with their occurrence (see red rectangle): I think that is better is folder summary show only red rectangle and not also green rectangle
(In reply to comment #136)
>I think that is better is folder summary show only red
> rectangle and not also green rectangle

I'm sorry Jim in my previous post I have changed red rectangle with red: my right question is:

show only *green* and not show *red*
Ah. The red section is there to show how the tags are distributed. It's not very useful for you, since you only have one tag at a time, but it's useful for people who use multiple tags per message. The green section is there because counting lots of little dots is hard. :)
(In reply to comment #138)
> it's useful for people who use multiple tags per message. 

ah ok: you are right! ;-)
(In reply to comment #128)
> (In reply to comment #127)
> > Of course, no problem, I will send you the german localized files in a few
> > days. :-)
> 
> Thanks, I'll merge this in.

Cool, I hope you received my email. :-) Is it also possible to make the <em:description> in install.rdf localizable? This and the birds text are the onliest parts I couldn't localize.
Attached file Extension v6: batch message processing (obsolete) —
Barring the stuff in bug 494090, this is probably more-or-less ready to be released to a wider audience now. Notable changes include:

* The extension's name and uid have been changed to reflect that this isn't 
  just an "Account Summary" anymore. Be aware of this when installing the xpi!
* Message processing for the folder summary is done in batches of 500, pausing
  at the end of each batch to let the UI respond
* A maximum of 10,000 messages are processed in the folder summary (this can
  be altered with the pref extensions.mailsummaries.max_messages
* Virtual folders can now be summarized
* There's now a German localization, which hopefully works and is correct
  (thanks to Nomis101!)
* The iframe snippet's location can be changed with
  extensions.mailsummaries.snippet.url
* Resizing the message pane horizontally will resize the tag dots visualization

I've also put the code up on Bitbucket here: <https://bitbucket.org/squib/mail-summaries>, but unfortunately, the version history got wiped when I stupidly corrupted my repo. I didn't feel like reassembling the latest changes on top of a backup, so there we are. People are welcome to file issues over there, since that's probably where I'll point people when this is finally released.
Attachment #524327 - Attachment is obsolete: true
(In reply to comment #141)
> Created attachment 525642 [details]
> Extension v6: batch message processing

attached file is a patch or an extension?

I can install only download source from <https://bitbucket.org/squib/mail-summaries> and save it as *.xpi
Attachment #525642 - Attachment is patch: false
(In reply to comment #141)
> * There's now a German localization, which hopefully works and is correct
>   (thanks to Nomis101!)

The localized files are in the locale folder, but it seems you have forgotten to add the new locale to chrome.manifest.
Attachment #525642 - Attachment filename: mailsummaries.xpi → x-xpinstall
(In reply to comment #142)
> (In reply to comment #141)
> > Created attachment 525642 [details]
> > Extension v6: batch message processing
> 
> attached file is a patch or an extension?
> 
> I can install only download source from
> <https://bitbucket.org/squib/mail-summaries> and save it as *.xpi

It should be the extension, but the mimetype wasn't detected properly. Hopefully it works now.


(In reply to comment #143)
> (In reply to comment #141)
> > * There's now a German localization, which hopefully works and is correct
> >   (thanks to Nomis101!)
> 
> The localized files are in the locale folder, but it seems you have forgotten
> to add the new locale to chrome.manifest.

I've fixed this on bitbucket. If you want to try it out there to make sure everything looks good, that would be helpful.
(In reply to comment #144)
> I've fixed this on bitbucket. If you want to try it out there to make sure
> everything looks good, that would be helpful.

Looks good. :-)
I can't seem to find the XPI either on bitbucket or the v6 attachment.
Attachment #525642 - Attachment filename: x-xpinstall → mailsummaries.xpi
Attachment #525642 - Attachment mime type: text/plain → application/x-xpinstall
The attachment is the XPI. Apparently I didn't actually fix the mimetype earlier, but it has always been the XPI.
OK got the XPI
The 10000 message limit works fine here about 5-6 seconds on my low end (purposefully) machine.

For the iframe snippet to be useful as a "start page" you would at least have to set overflow on the iframe.
Try this url for example:
http://forecast.weather.gov/MapClick.php?site=aly&FcstType=text&zmx=1&zmy=1&map.x=82&map.y=102&site=ALY
(In reply to comment #148)
> For the iframe snippet to be useful as a "start page" you would at least have
> to set overflow on the iframe.
> Try this url for example:
> http://forecast.weather.gov/MapClick.php?site=aly&FcstType=text&zmx=1&zmy=1&map.x=82&map.y=102&site=ALY

I've updated the code on bitbucket to automatically resize the iframe to fit its contents. That should make it easier to use other pages for the snippet (or to use the default on small screens).
looking pretty darn sharp. two things:
- I'm seeing some errors of the sort 
Warning: Unexpected value Infinity parsing height attribute.
Source File: chrome://mailsummaries/content/folderSummary.xhtml
Line: 0
- F6 pane navigation is broken. eg. click a folder, hit F6 should take you to messages list, and under normal circumstances would focus a message, and of course display it.  I haven't followed the bug closely, so I don't know what the intended behavior is in this situation.

And I tested with two folders of 60k messages and virtual of 120k messages. Performance/results are fine. However, it would be good I think to indicate somewhere that extensions.mailsummaries.max_messages was hit and the displayed summary is partial results. And perhaps a nice touch to be able to click it to get full results?
I just installed this extension on Miramar 3.3a4pre and I have to say it is very slick.  Very nice job indeed.

I would like to offer a suggestion.  Under the disk usage the little colored square to the left of the folder name is clickable to that particular folder.  How about making the actual folder name clickable too?
(In reply to comment #150)
> looking pretty darn sharp. two things:
> - I'm seeing some errors of the sort 
> Warning: Unexpected value Infinity parsing height attribute.
> Source File: chrome://mailsummaries/content/folderSummary.xhtml
> Line: 0

Should be fixed on Bitbucket. I also fixed a few more related issues with the tag dots chart.

> - F6 pane navigation is broken. eg. click a folder, hit F6 should take you to
> messages list, and under normal circumstances would focus a message, and of
> course display it.  I haven't followed the bug closely, so I don't know what
> the intended behavior is in this situation.

I think this is a Thunderbird bug, since the same thing happens with the multi-message summary without the extension installed.

> And I tested with two folders of 60k messages and virtual of 120k messages.
> Performance/results are fine. However, it would be good I think to indicate
> somewhere that extensions.mailsummaries.max_messages was hit and the displayed
> summary is partial results. And perhaps a nice touch to be able to click it to
> get full results?

I added a note indicating that not all messages were summarized, but I don't think I'm going to add a link for full results, since people who want that can set extensions.mailsummaries.max_messages to -1 (and with the processing happening in batches, performance shouldn't be an issue).

(In reply to comment #151)
> I would like to offer a suggestion.  Under the disk usage the little colored
> square to the left of the folder name is clickable to that particular folder. 
> How about making the actual folder name clickable too?

Fixed on Bitbucket. I had to modify Protovis to do it though (partly because I didn't want to update to the latest version; maybe I should do that instead).
Attached file Extension v1.0b1 (obsolete) —
Alright, I'm essentially done with this now (that is, version 1.0 of the extension). Attached is an XPI for the people who haven't been following the Bitbucket and keeping up-to-date themselves. If anyone is interested in testing this out, now's your chance! With any luck, this will be released properly in a few days.

For the curious, here's a list of notable things that have changed since I last posted in this bug:

* Account/folder summaries now keep themselves up-to-date with changes, so no
  need to refresh them.
* The iframe snippet is gone. Note that this means there's nothing like the
  start page anymore. In the short term, you can use something like Web Tabs;
  in the long term, the home tab will probably have something like this.
* The last selected message in the folder summary is gone (it took up too much
  space and wasn't that useful). I'll probably write an add-on to restore this
  as a proof of concept for extending the mail summaries.
* Added french localization.
* Recent messages widget in folder summary now includes read/unstarred messages
  (but unread or starred messages get higher priority).
* mailnews.remember_selected_message is now set/reverted on install/uninstall.
* Plus lots of bug fixes and optimizations
Attachment #525642 - Attachment is obsolete: true
Attachment #538740 - Attachment description: Extension v1.1b1 → Extension v1.0b1
Oh, and one more thing:

* The tag dots in the tag widget are clickable now, and will take you to that
  message (they also have a tooltip showing the message subject)
(In reply to comment #153)
> Created attachment 538740 [details]
> Extension v1.0b1
> 
> If anyone is interested in
> testing this out, now's your chance! With any luck, this will be released
> properly in a few days.

Do you mean properly as an extension, or properly as a core feature...


> * The iframe snippet is gone. Note that this means there's nothing like the
>   start page anymore. In the short term, you can use something like Web Tabs;
>   in the long term, the home tab will probably have something like this.


I think one must take care in assuming that enhancements such as this, can over-ride or displace previous features in a no-loss fashion.
Short term...long term, if it lands in core, it's gone for now. There are no metrics AFAIK for "mail start page" usage, and that there is a negligible use case there.

Don't see much action on "Web Tabs" lately, but https://addons.mozilla.org/en-US/thunderbird/addon/wat-webapplicationtab/ seems to work nicely.
(In reply to comment #155)
> (In reply to comment #153)
> > Created attachment 538740 [details]
> > Extension v1.0b1
> > 
> > If anyone is interested in
> > testing this out, now's your chance! With any luck, this will be released
> > properly in a few days.
> 
> Do you mean properly as an extension, or properly as a core feature...

As an extension.

> I think one must take care in assuming that enhancements such as this, can
> over-ride or displace previous features in a no-loss fashion.
> Short term...long term, if it lands in core, it's gone for now. There are no
> metrics AFAIK for "mail start page" usage, and that there is a negligible
> use case there.

That's why this is an extension right now. Nevertheless, web tabs - or something like them - would probably be a better fit for most use cases.
I am running the latest version and noticed that when clicking on an e-mail subject listed under the Inbox section, it just opens up the inbox instead of opening up the e-mail that I clicked on.
What is the "latest version"? The one attached here, or the latest source from Bitbucket? What version of Thunderbird? Account summary or folder summary? IMAP/POP3?

In any case, I can't reproduce this at all.
Wait... do you have the message preview pane hidden or something?
(In reply to comment #158)
> What is the "latest version"? The one attached here, or the latest source
> from Bitbucket? What version of Thunderbird? Account summary or folder
> summary? IMAP/POP3?
> 
> In any case, I can't reproduce this at all.

Latest version being the one in comment 153.  Thunderbird is version 7.0a1 Shredder.  IMAP.  Account summary.


(In reply to comment #159)
> Wait... do you have the message preview pane hidden or something?

Yes, I do not use the message preview pane.  I have Thunderbird configured to open messages up in a new window.  I guess that is not supported by this extension.  That is fine, I just thought it was a bug.
(In reply to comment #160)
> (In reply to comment #159)
> > Wait... do you have the message preview pane hidden or something?
> 
> Yes, I do not use the message preview pane.  I have Thunderbird configured
> to open messages up in a new window.  I guess that is not supported by this
> extension.  That is fine, I just thought it was a bug.

I've filed a bug for this, but I'm going to hold off on it until after 1.0 is released to fix it.

One final question to everyone following this bug before I consider 1.0 "finished": what do people think of the background image in the summaries? I just inherited that from the original patch, but I know clarkbw has suggested removing it. I'm undecided. For reference, see attachment 386242 [details].
(In reply to comment #161)
> but I know clarkbw has suggested removing it

+1
(In reply to comment #161)
> One final question to everyone following this bug before I consider 1.0
> "finished": what do people think of the background image in the summaries? I
> just inherited that from the original patch, but I know clarkbw has
> suggested removing it. I'm undecided. For reference, see attachment 386242 [details]
> [details].

I think they should be removed.
Attached file Extension v1.1pre (obsolete) —
I'm about to release version 1.1 of this add-on to AMO, but I'd like to get a bit more testing before I submit it. Here's a preview build for folks to try out. Aside from restructuring most of the internals to be faster and less polluting of global scope, here are the interesting changes:

* Ctrl-click opens items in new tabs where appropriate
* Open inbox messages in a tab if preview pane is hidden
* Shift-clicking compose links opens with non-default format (HTML vs text)
* Top authors/correspondents will pick up address book display names
* Improved layout of folder summary when vertical layout is selected
* Better formatting of large numbers (yay commas!)
Attachment #538740 - Attachment is obsolete: true
Attached file Extension v2.0pre
For those of you still following this, here's a preview build of version 2.0 of the add-on. If you could test it out and report bugs at <https://bitbucket.org/squib/mail-summaries/issues/new>, that would be much appreciated.

Here's a mostly-complete changelog:

General

    Improved handling for small screens
    Overflowed items now show tooltips on hover
    Added context menus (not yet supported by Thunderbird, though)
    Opening messages in new windows by default works now
    Composing messages to newsgroups works as expected now

Account Summary

    Remove useless items in folder space summary
    More info shown for draft messages 

Folder Summary

    Show top recipients (instead of top authors) in outgoing folders
    Top correspondents list now works with non-Latin characters
Attachment #546459 - Attachment is obsolete: true
Sorry, context menus *are* supported by Thunderbird, but only in recent nightlies.
Blocks: 465568
From the screenshots attached, this looks pretty slick.

Jim, what do you need to be able to finish this? I would love for this to get in TB 38.
(In reply to Josiah Bruner [:JosiahOne] (needinfo > CC) from comment #168)
> Jim, what do you need to be able to finish this? I would love for this to
> get in TB 38.

That all depends on just how finished we want it to be. The hard part is supporting NNTP/RSS, but I'm working on that in the add-on: https://bitbucket.org/squib/mail-summaries/wiki/Home

There's also the folder summary, which is closer to being finished: see bug 492158
See Also: → 493043
See Also: → 529499
Depends on: 1180462
Blocks: 492158
You need to log in before you can comment on or make changes to this bug.