Some ideas for Expanding and Contracting the Email Addressing fields in 0.7

Basic premise is to add some text-based widgets to expand and contract both the number of fields (now that we have cc and bcc) as well as the size of each field (the # of addressees we display in each field.) Expansions and contractions should persist.

Caveat In order for the +/- # of recipients feature to work, we probably need "scrolling in the entire detail view" to work, otherwise, if you can invitation that was sent to 100 people, expanding the recipient list would blot out the whole detail view. We could hack around it in 0.7 (ie. limit it up to 3 lines of recipients, etc, but in the long run, we'll need a more scalable solution.)

• font size: XS font size: 10 pt on the Mac
• + and - signs should be bolded as well
• +/- cc: and bcc: are left aligned with the text fields
• there is a space between the +/- sign and cc: and bcc:, but no space between +/- and the number of recipients
• there are 3 spaces between +/- cc: and +/- bcc:
• +/- cc: and bcc: should be 4 pixels below the address field
• +/- # of recipients should be 4 pixels to the right of the address field
• +/- # of recipients should bottom align with to: cc: and bcc:
• nice to have: address fields right-align with the pulldown border of the from: field above (if +/- # of recipients is needed) otherwise, address fields right-align the way they do today.

• The addressing fields should expand automatically when the user is "typing in the addresses". However, they should always have the option to contract the list, even on unsent, outgoing mails.

• In the image to the right, all address fields are showing, with the option to close the cc: and the bcc: fields
• However, the address fields are contracted to show only a single line's worth of recipients

• Here, the bcc: field has been closed, with the option to either close the cc: field or open up the bcc: field again.
• But both the to: and cc: fields have been expanded to show all of the recipients

Issues / Questions

• (Bryan) A few comments:
  • The limiting factor on toggling between single-line (horizontally-scrolled) edit fields and multiline fields (sized vertically to fit their contents) is determining the height necessary for the multiline field. We face the same issue with the Notes body (not toggling; just determining the "necessary" height) to be able to scroll the whole detail view; doing one implies being able to do the other. Your idea to toggle between one and three lines in the short term is certainly doable, though.
  • Lining up the right edges of editfields with the "From" popup's pulldown border is problematic: we don't have the ability to ask the widget for this measurement in the current theme on each platform. MimiYin sigh Yeah I figured as much. Never hurts to ask ;o)
  • Minor: Do we need the colons after the toggle labels (" - cc: + bcc:") when we don't have colons on the actual labels, and the labels on the toggles aren't actually preceeding anything? MimiYin Good point. When I tried it without the colons, they looked funny. We can try it without them.
  • Really minor: The cc/bcc toggle controls are separate blocks (so the space between them would be expressed in "pixels", not "spaces") MimiYin Oh, then let's say 10 pixels

• (MarcGibeault - 12 Jan 2006) My comments:
  • I really don't like these signs and numbers around the fields... It looks like code left behind by mistake. What if the field would be large enough for two or three adresses (most usual number), then expand to two and three lines if there's more. The field name would be a button that opens a windows where we could see all the adresses if there's even more. It could be used to select from a list of contacts.

• MimiYin I'm realizing we also need to add a Date field for when the email was received underneath the last addressing field I'm proposing we leave the Date field editable for now, see what people do with it.

• Reid's comments - 01 Aug 2006:
  • How about using something more graphical like this instead of the textual +/-?
  • 
  • Isn't repeating bcc/cc in a separate place a bad idea?
  • Of course, when a field is missing, there would be a green plus:
  • 

• HeikkiToivonen
  • I don't think we should have those +n followed by the fields; I think they are unnecessary and confusing.
  • I suggest adding a small +/- or >/v symbol left of the field to expand/collapse the field. The size expanded should be automatic, but no more than 3 lines or so I would think (we could have some smarter logic that detected how much we could really display while still showing body)