Status Putting something together to discuss this week (May 22, 2005) with the Apps team.

Typography

High level issues to address

1. How visually polished does 0.6 calendar need to be? I can easily imagine doing 12-15 rounds of visual polish on the calendar in order to get it to the level of Apple iCalendar. Is there an existing app out there that we can point to as a benchmark for where we need to be by 0.6?
2. Depending on the answer to Q1, what is our process for reviewing and iterating on visual design? a When are bugs officially closed? a Who can close a bug? a How regularly should the app be reviewed for visual polish? a Should visual polish bugs be logged with the feature? or as a separate bug?
3. How does visual polish affect our schedule?

• Proposed philosophy
• Make it so there are no glaring mistakes in the calendar (ie. Mac toolbar)
• Iterate on what we can control to make it visually polished, but we don't need to be obsessive about it in 0.6

Font size

There are 4 font sizes: The pixel heights are measured from the top of the highest ascender (ie. f or h), to the bottom of the lowest descender (ie. q or p)

• (L) Large: A lot bigger than default size and bold (ie. 17 if default is 11)
• (M) Medium: A little bigger than default size (ie. 12 if default is 11)
• (S) Small: Default size
• (XS) Extra-small: A little smaller than default size and bold (10 if default is 11)

Font face

• Windows and Linux: I think the default is Arial
• OSX: Lucida Grande is the default
• In the future, when we do email, we can consider using something more like Verdana for the notes field.

Font color

There are 2 font colors:

• Standard: Use whatever default font color is set by the OS
• Greyed out: 50% lighter than the default font color

Leading

There are 3 types of leading:

• Standard: Leading (the vertical spacing between 2 rows of text) should be determined by font size.
• Grouped together: 75% of standard leading.
• Separated: 125% of standard leading.

MimiYin this needs to be verified because I don't actually know how the leading is set on each platform.

Margins and gutters

• Pane margins should be 7 pixels all around
• Gutters should be 5 pixels
• Calendar lozenge margins are special cased:
  • Left margin: 4 pixels
  • Top margin: 3 pixels
  • Right margin: 3 pixels
  • Bottom margin: 3 pixels

Borders, dividers, and other line-based visual adornments

• Pane border colors should be selected by the OS
• The following colors are specified, if the default OS color is black:
  • Mini-cal dividers: 80% grey
  • Main-cal: Everything is 80% grey except for:
    • Half-hour lines: 90%
    • Vertical lines: 90%
    • Timeline between 9-5PM: 50%
    • Selected timeslot: 95%

Selection colors

• Should be selected by the OS
• The "not-the focus" selection should be 50% "lighter" than the focus color.
• win32_visual_polish.png:
  

• mac_visual_polish.png:
  

Comments

Philippe - 06/07/05

On the High Level Issues paragraph first, Polished UI is the 2nd tenet in the 0.6 Vision so 0.6 needs to be as polished as we possibly can. We (the Apps team) are making a significant human investment in it for 0.6. So Visual Polish does not "affect" our schedule, it's part of it really. Now, how we go about it is debatable. Going through 12-15 rounds of tweaks through a design/dev dialog seems to me unrealistic (someone is going to have a nervous breakdown...). On the other hand, I understand that we certainly do that amount of tweaks to get it right! With that understanding, we (the dev team) need to put together something (editable resources for instance) so that designers can play with the elements listed in this spec (fonts, font size, color, gutter, etc...) all they wish: it will be faster, will allow to experiment more with different design and will save everyone's sanity. We're also more likely to get to a satisfactory result in the end.

As far as an app that we could use as a benchmark for visual quality, I'd point to "Thunderbird". It's not a calendar but it's a "1.0 open source cross platform desktop app" like Chandler so it sorts of set the bar to what we should shoot for.

For the bug process, we follow the Bugzilla process: bugs are closed by QA (not dev), QA should certainly consult with design on visual bugs before closing them. I also think we should open visual bug separately from feature work (i.e. task) as soon as the task is deemed completed (fixed and closed).

Font face: we should use Verdana on Windows, not sure on Linux (what's GNOME default font?)

Color: the formula for greying out won't work. A black text (most common case) has a brightness of 0 so reducing it by 50% won't do much... For a colored font, we need to reduce the saturation too or the color won't feel "greyed" but "darkened". I think "greying out" should be going toward the (v=50%, s=0) point of the grey line. Something like: h' = h; s' = s/2; v' = 50%.

I think there is a similar problem with the "not the focus" color computation.

It would be better if you could provide us with a set of example pairs of what you visualize (for both greyed fonts and "not the focus") for different colors and we will deduce a color transformation law from them.

Bryan - 06/13/05

• I sent the message below to Mimi one month ago today; I guess I should've written it here, so I'm pasting a slightly-edited version here...)

I've just gone through a bunch of rework to implement a font-size strategy across platforms, since point size means different things on different platforms.

I didn't implement platform-specific point-size specs - when I proposed this, I got lots of negative feedback from others, and I've come around to their point of view. Instead, I implemented a strategy that "normalizes" the point size for the platform you're on - if the app asks for an "11 point" font, the user will see the default UI font size on that platform. (It's "11 point" because that happens to be the default UI font size on Mac - there, the user will actually get an 11-point real font). On Windows, that "11 point" request will get mapped to an 8-point font, because that's how big the default UI font is on Windows. Asking for something bigger gets you something proportionally bigger, and smaller gets you smaller.

As it happens, we're currently never specifying a font family other than "Default", so we get the appropriate family for the platform. This is a good thing - if we start specifying particular families, we'll get into trouble with different themes.

This works out especially well if the user changes their default size: everything should get proportionally bigger or smaller. This isn't just a matter of personal preference; it's important for those with visual impairment. Also, if we don't size things relative to the default UI size, users would have to change each size specification manually, and how would they do it if they couldn't see it? (We have more work to do to make this happen: right now, most things in the app aren't sized based on the fonts of the text that occupies them, but this is where we're going.)

I have no idea whether we have anti-aliasing control, by the way; it doesn't appear to be part of the API provided by wxWidgets.

• Also, I coulda sworn I asked Mimi about "gutters", but can't find my message. What's the difference between "gutter" and "margin"?

• Finally, re Philippe's color-math comment: The checked-in code for the String attribute editor (which is what's behind the "location" field in the detail view, for instance) uses a gray that's 50% between the normal text color (wx.SYS_COLOUR_WINDOWTEXT, black everywhere I've looked) and the control's background color. This seems to work pretty well: it works out to be a shade of gray on mac, and a shade of brown on Windows XP. (Look for "__shadeBetween" in AttributeEditors.py to see what it's doing.)

John - 06/20/05

• Applications on Windows and Linux don't specify absolute values for fonts, colors or sizes as described here -- they are part of your system settings. So it's inappropriate for us hard-code the setting as proposed in here. First you need to understand how the various each of the platforms specify visual design information and then modify your proposals to take this into account.

Mimi

Here's an example of Outlook overriding system preferences for font size in the Calendar.

• unknown.jpg:
  

Top Priority Visual Fixes for 0.6

Mimi and Sheila have put togther a list of top 3 priority visual things to fix for 0.6. The tasks per section have also been listed in order of priority.

• 1. Beveling - Better defining the outlines/margins of panes and making them consistent will have a significant visual impact on the app.
  • Details:
    • Add 1 pixel outlines to all of the panes (this means the faint grey outline that appears around all the panes)
    • Remove dark bevel on the Mac (this is the black line that display down the left side of the summary table view and across the top pane below the toolbar)
    • Remove outline around toolbars on Mac (this may be dependent on the widgets work to fix the toolbar)
    • Add bottom line to mark-up bar on PC
  • Next Steps:
    • Assign dev owner - Jed???
    • Schedule meeting with Mimi, Jed, Philippe to discuss tasks/research required to address items above.
• 2. Font-size issues
  • Our primary goal for 0.6 is to have the app look good for default font setup on all 3 platforms. This does not mean hard-coding fonts but figuring out how to specify the relative size so it looks correct on the default setup.
  • Details:
    • Medium size font in the sidebar
    • Small size font in the mini-cal
    • Small size font in the timeline
    • Small size font in the event lozenge
    • XS size font for the time in the event lozenge
    • Larger large size font for calendar month header
  • Next Steps:
    • Assign a dev owner
    • Better spec from design
• 3. Anti-aliasing
  • Details:
    • Turn on anti-aliasing on the PC
  • Next Steps:
    • Assign dev owner
    • Research issue

Visual Iterations

I wanted to list a few specific areas that Mimi would like to have the opportunity to iterate on with the developers. In most cases, it makes sense for the developers to complete most of the work spec'd out since it's difficult to make subtle decisions about color etc before all the functionality is in place. This is more intended as an FYI so people know that Mimi would like to have the ability to work them once we have reach the appropriate point in development.

1. Color of text in the calendar lozenge. Once we have all the different scenarios handled for selected/activated events and calendars, we can look at the text for all combinations and decide if anything needs to be changed.
2. Shape of the logenze in the calendar view. As in the above case it probably makes sense to look at this once we have all the different types events, events statuses and combinations of selected/activated etc. implemented.
3. Sidebar icons. This mostly applies to the checkboxes but it doesn't make sense to iterate on this until the checkboxes have the appropriate color of the calendar.