User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021202 Chimera/0.6+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021202 Chimera/0.6+ Navigator:Preferences:Appearance:Fonts Confusing item #1: Default font preference is in the per-region "advanced" sheet, but it is a global preference that sets font.default. The option should either be set per region (my preference) or the widgets should be somewhere other than the per-region "advanced" sheet. Confusing item #2: If a naïve user wants, say, Helvetica as the default font, they will quite likely navigate to the "Fonts" tab and change Times to Helvetica. What they've really just done is changed their serif face to sans. Try it, then click the Advanced button. Starting from a default Western setup, you wind up with Helvetica as both the serif and sans-serif face. (And the monospaced font isn't even adjustable from the Advanced sheet.) Confusing item #3: Why can the default only be set to serif or sans-serif? It doesn't really make a difference to me, and I'm sure "tradition" or "because it's simpler that way" will be the answer, but it doesn't make sense when users can set five typefaces per region but only select from two of them as the default. Confusing item #4: Clicking the dot to change the font doesn't match any UI convention I'm aware of. It's confusing. Offer a drop-down with faces appropriate for each region, plus a size drop-down. Kind of like how the Advanced sheet is now. Confusing item #5: Why can the base size be set independently for fixed and variable-width fonts, but not for the other face classes? Fonts viewed at similar sizes tend to complement each other best; why is the default Western proportional size 16 and the default fixed-with size 13? Courier 16 matches Times 16 better than does Courier 13. Either a size setting should be provided for each font to compensate for minor differences, or a single per-region setting should be provided. Given the unnecessary complexity of the former option, the latter probably serves everyone's needs while maintaining simplicity. On the other hand, Mail.app takes the size-per-font approach. Confusing item #6 (already filed elsewhere, check Bugzilla): Chimera lets users change the style of the proportional and monospaced faces, but does not save these changes. Given these confusing items, I propose that the fonts tab be reorganized, and the Advanced sheet be eliminated. I propose the tab be arranged as follows: Region: [ Western |I] Font Selection _____________________________________ Serif: [ Times |I] (*) Use as default Sans-serif: [ Helvetica |I] ( ) Use as default Cursive: [ Apple Chancery |I] ( ) Use as default Fantasy: [ Gadget |I] ( ) Use as default Monospace: [ Courier |I] ( ) Use as default Sizes ______________________________________________ Base size: [ 16 |I] Minimum size: [ 12 |I] Here, [ xxx |I] represents a drop-down menu and ( ) represents a radio button. Each font drop-down would list only typefaces containing characters from the appropriate region, or a disabled control if no matching faces are available. The monospace drop-down should have the appropriate constraint that only fixed-width typefaces are available for selection, unless none are available, in which case any available proportional-width faces are listed. I believe that this layout addresses the bulk of the confusion with the existing font preferences, and allows the user to quickly see what's happening and make changes. I'm not filing this as an RFE because the confusing items are bugs; the proposed layout is only a suggestion for overcoming them. Mark Reproducible: Always Steps to Reproduce:

Hmm. I actually find your proposal even more confusing ;-) But I do agree that the panel needs improvement (though I believe that nobody would *dis*agree).

>...navigate to the "Fonts" tab and change Times to Helvetica. What they've really just done is changed their serif face to sans. Actually, what they have done is changed their "Proportional (Serif)" font to a typeface without serifs. If, in "Advanced" they select a preference for "Sans-serif", then the label changes to read "Proportional (Sans-serif)". In other words, if their advanced option is for Sans-serif fonts, then they are asked to select a default sans-serif font. It's kind of backwards since you have to drill deeper to get to the general option (serif vs. sans serif), which has redundant controls for selecting an actual font. > (And the monospaced font isn't even adjustable from the Advanced sheet.) It is adjustable on the main page, but is also the one type of font not redundantly specified in "Advanced". The advanced option is too select the default in more general terms (serif or sans-serif, mono is not an option for default), and the main preference is more specific (which font do you want to represent "serif", for instance). That said, I think Mark's suggested arrangement is much better than what we have now. It is easier to understand and use, and is more compact (does not require 3 different pages of selections like we have now). Here is a different, but similar arrangement (-V- is a disclosure triangle, and below the --- shows even when it is closed): For this alphabet: [Western ^v] When font is not specified in page, use: (x) Serif: [Helvetica ^v] ( ) Sans-Serif: [Times ^v] -V- Other Font Associations Monospace: [Monoco ^v] Cursive: [Apple Chancery ^v] Fantasy: [Gadget ^v] --- Minimum Font Size: [7] points I think it is important to say "points", if that is what we are talking about, since there are other type measures that Web page designers can use. This arrangement also assumes that we are trying to save users from themselves by not allowing cursive, fantasy, or monotype to be their default font. > ...Offer a drop-down with faces appropriate for each region I strongly agree (see above). The font panel is a kind of wizzy, cool cocoa feature, but is inappropriate here, especially since it requires you to select a specific face, but really only cares about the family. >...Why can the base size be set independently for fixed and variable-width fonts Base font size should be editible in user.prefs text file only. Making it a UI option only makes it more likely that a page design will render incorrectly from what the page designer intended. If it is not so easily changed by novice user, then designers will have more predictible results and everone will benefit. Users can always increase the size of all type on a page using View>Bigger Text, which is plenty enough control (especially if someday the menu includes an option to return page to 100% text size).

> > What they've really just done is changed their serif face to sans. > Actually, what they have done is changed their "Proportional (Serif)" font to a typeface without serifs. And therein lies the confusion! I like Brad's proposed layout, but would prefer seeing a base font size setting in the UI unless the "bigger/smaller" function is retained and applied to all documents across window closures-openings and application quit-starts. That's probably more trouble than it's worth. There are plenty of people out there that can't read too-small text, and plenty that like to cram as much text as possible into as tiny a space as possible. Not to mention, there are physical and perceptual differences between displays that should be consistently accounted for. 16pt looks great on my 17" wide-screen iMac at 100px/", but I need to drop to 14pt to get approximately the same physical dimensions on my 15" PowerBook at 91px/". Mark

New proposal, things are clearly separated. I have kept the same window size and popup sizes. The preview changes to show the current focus (blue highlight) or nothing if the focus is somewhere else than on the left side (5 fonts + 2 sizes). In current build 1210, the Apple Font palette is useless because the settings kept are only for Font and Size, the rest even if you can choose them, is lost. So no need of that ugly Apple Font Palette.

Add a (localizable) T letter sample for Serif/Sans-serif which is a not well known concept.

Stephane, that's better than what we have, but I see problems with it still. For one, I think having two previews will add more confusion than clarity. If the letter "T" does not match the actual font chosen, users will wonder why. Perhaps if the serifs (or areas lacking serifs) were circled in light blue, it would be more illuminating. "Non-Proportional" and "Monospace" are pretty much synonymous. I am assuming you are dividing them up this way in order to minimize code changes so that monospaced fonts can continue to have a different size. It would certainly be easier to understand if they were not divided into 2 groups like that. In your proposal, a user might very well think that the size could only be changed for Serif and Monospace, but not the others (since the size menu is right next to those menus). Also, I would move your right side to the left, so that the panel begins with the general and simple on the left and has the more specific "tweaking" part on the right.

Brad, I made several tests with 'circles', it's not good at all, too crowded. Dividing P and NP on the contrary avoids confusion. Moving size 14/13 at the end of P/NP lines will require more height to avoid making it too crowed. The 'advanced' features are on the right, the main on the left. NF5 took me 5 hours, it's the best I can make if I don't want to enlarge the size of the window. I made dozen of layouts and they are always confusing and unclear. I'll try more if I get some positive feedback from a developer.

V8: moved sizes 14/13 at end of P/NP fonts, cleaner sample, bigger gaps between items.

I like the new db. A few comments: * I understand the min. size will stay as a pref edit, and not be added to the db? * What letter would the preview show for non-roman characters sets? * Are we going to have a pref in the db for our preffered characters set? (see bug 153150 as well)

I can see some problems with setting the fantasy and script fonts to the same point size as the serif and sans fonts; script fonts in particular typically have an incredibly small x-height. I would put the dividing line between the serif and sans fonts and the rest; it makes little sense to have a divider for one item out of five. I agree that there should only be one preview, and the preview should be in a well, not set a gainst a grey background. Perhaps if the serif and sans fonts were in their own section, we could simply put radio buttons next to them to choose the default font.

Comment 9, min size is there ?! The preview letter (T) is a localizable item. (1) The mockup redesign the current controls, no new function. Comment 10. a. see (1) above b. no, must be clear, it has nothing to do with Proportional fonts, having just one is not a good reason and without that division it's a real mess to have a balanced design. c. S/SS I've tryed dozen of layout during more than 5h, all are messy, this one is the best I can do, for the T preview can be removed without problem.

I don't think the 'T' letter will be confusing but if you think so. The preview background should not be in a well, it's to drag-and-drop an image. See SysPrefs Intl-Date/Hour, perhaps the gray background can be lighter, like those in Date/Hour.

The goal of the existing font panels was to make the panel as simple as possible, and reuse existing cocoa functionality (the font panel). The suggested panels look very complex in comparison.

smfr: But the current panel *is* confusing. Two examples: it says "Proportional (Serif), like Times" per default. The "(like Times)" is shown in the actual Times font, e.g. as a serif font. Click on "Advanced", and change the "Default font" setting to "sans-serif". Now it says "Proportional (Sans-serif): (like Times)" Times still looks the same ( ;-) ), but at the right, the sans-serif font is now being used. So there are three wrong things here: Times is a proportional font, but it isn't sans-serif, so it's a bad example for a "Proportional (Sans-serif)" font. Second: "Proportional (Sans-serif)" suggests that "Sans-serif" is a synonym to "Proportional", which it isn't. Third: Why is what apperas to be the same thing called "Default font" in the advanced panel, but "Proportional" in the other? Stephane: at the bottom of your "NewFont08.png" image, it says "37 pixels bigger than current window". I find that quite ironic considering that at the first look, it appears twice as tall as the current window. Stuffing a panel with lots of controls is a very, very bad idea. The average user is "lost" in your panel and will switch to the next one instead and just hope the font settings per default are fine.

> Times still looks the same ( ;-) ), but at the right, the sans-serif font is now > being used. > > So there are three wrong things here: Times is a proportional font, but it isn't > sans-serif, so it's a bad example for a "Proportional (Sans-serif)" font. There's another bug on that. > Second: "Proportional (Sans-serif)" suggests that "Sans-serif" is a synonym to > "Proportional", which it isn't. The reason the font prefs are as complex as they are is because of the way HTML (and Gecko) handles font specifications. The "Proportional" font is the default font used for body text, when no other specifications apply. Some pages use <font> tags or CSS to specify "serif" or "sans-serif" fonts (which are both proportional), so we have prefs to allow the user to choose serif and sans-serif fonts. Hence, they get to choose whether their default font should be serif, or sans-serif. That's what the "(Serif)" indicates after the proporitional label. > Third: Why is what apperas to be the same thing called "Default font" in the > advanced panel, but "Proportional" in the other? In the main panel, "Proportional" is used to contrast with "Monospace". The advanced panel uses "Default"" for brevity, but could, I guess, say "Default proportional" or something.

I think that what's at issue here is that while we all understand how the current font preferences work either through practice, having it explained, or intuition, this is Chimera. There is plenty of room for confusion in the current implementation, and probably plenty of room for the same in each of the proposed implementations. Most users probably don't even realize that the font panel does what they think it does. Just because Chimera's based on Gecko doesn't mean that it needs to be as confusing as Gecko.

> Just because Chimera's based on Gecko doesn't mean that it needs to be as > confusing as Gecko. Agreed, but the UI of the fonts panel has to reflect the way that gecko handles font prefs, otherwise user expection won't match reality.

*** Bug 175681 has been marked as a duplicate of this bug. ***

The latest version with what's currently in Chimera. Cursive and Fantasy samples are using another font, they are installed only if Classic is installed. The P and NP separations are intentional to make the things clear, without them the layout become confusing.

With all sizes as a lot of users complain that Cursive and Fantasy need a different size to make them readable. Of course both 09 files can be made on a bigger window, they have been made trying to (almost) fit in current window size. Moving the 2 items (Def+Min) on NewFont09.png to the bottom of the dialog will make it more balanced.

This is much improved. The best yet. But I still think that the simple choice (sans serif vs. serif) should be first, not last. Choosing the exact fonts to represent serif or san serif or the more obscure cursive and fantasy are the more advanced settings. If you think "serif" is too advanced a term, the default representative selections (and preview) make it more clear. Most people will be going to this preference pane to choose the default font, and the two choices of serif vs. sans serif is simpler than choosing the font to represent each.

I should also mention that having the samples right along side the selections like that is especially nice in making this pane clear. Is having the pane a little bigger a problem? Will it not adjust its size automagically?

Stéphane's attachment 110566 [details] looks to be the best yet. The one complaint I could foresee is that it's unnecessarily cluttered with all of those size specifications. In that case, I'd propose a single drop-down that sets the size for all type classes of a region. When using halfway-decent type to view halfway-decent sites, that seems to provide the most consistent view overall. The default, which pits Times 16 against Courier 14 (or is it Times 14 and Courier 16?) always looked horribly mismatched to me. Factoring in comment 21, I'd like to see 09allsizes without the individual size options, and "Default font" and "Base size" controls at the top. If the minimum control can't be made to fit, it will be the least missed of all. Let the user set this in user.js, and in the absence of an explicit setting, enforce the minimum at 60% of the base size but never less than 9 - this corresponds roughly to xx-small per CSS2's suggested scaling indicies, puts the minimums squarely where I think most people would expect them given the default base size, and doesn't penalize people who prefer a slightly smaller base size. See also bug 183932, the default fonts are inappropriate for a Cocoa application on Mac OS X (although the appropriate choices are not always clear, unless someone can get inside Apple typography's collective head). Mark

The UI in 110566 won't work. The backend uses a single font size for "variable" (proportional) fonts for a region, and a single size for "fixed" (monospace).

Simon- It seems like it would work with the modifications in comment 23. Mark

Josh please take a look

How is something like this (or is it too cluttered/too big)? It builds on the NewFont09-series and the "recent" comments.

I think that looks very good, better then what we have now. It's not cluttered, though you might give it some more room at the bottom like you do at the top. Other than that I think it looks as good as it could get. Though it would need some major re-write of the pane.

(In reply to comment #28) > though you might give it some more room at the bottom like you do at the top. Glad you like it, Jasper. It was a just a quick hack job on that prefpane's nib, so the spacing is probably off all over. The "preview boxes" aren't aligned very well yet, for instance. Also, the %@ is the (shorthand?--as seen on the existing "Advanced" sheet) for the locale/encoding, so that bottom line will have to be adjusted for real-life length (everything's more clear after some rest). > Though it would need some major re-write of the pane. I wish I could volunteer and do it, but, alas, I can't even AppleScript my way out of a paper bag. :(

Here's a new version that hopefully addresses both Jasper's comments and my self-critique, in case anyone was interested.

This explains some of the "strange" blank space. E.g. "Advanced settings..." has all that blank space because %@ is apparently the shorthand for the actual encoding group and, given the width of the drop-down at the top, these might get quite long when localized...Traditional Chinese is the longest one in English and it barely takes up half of the drop-down.) This might suggest other text labels will need more space when localized.

This panel is looking good (although we still don't really know Josh's thoughts yet). Some minor items: -I think "Proportional Width" and "Fixed Width" are more descriptive than "Proportional" and "Non-Proportional." -There is no definition for the font size drop lists. They could be preceded by "Default Proportional Width Font Size: [ 14 |I]" and Default Fixed Width Font Size: [ 12 |I]." If these labels and drop lists are then moved below the separators, the separator line can extend across the dialog box width and segregate the font sample boxes as well. -For consistency, include a separator for the "Advanced Settings..."

I don't know much about fonts, how they should be used, configured... It would take me some time to educate myself on the subject so I could productively weigh in on this. I think the font prefs are the biggest thing that need to change content-wise as opposed to pref organization, so it would probably be best to continue developing a good system here and then begin work after the rest of the pref rewrite has been done.

Here are some refinements to (hopefully!) reflect the suggestions in comment 32. I wasn't quite sure exactly what was meant in the suggestions for moving the divider lines and renaming the "headings." The font settings are a hiearchy with some parallelism; this has influenced my separator and headings decisions. Here is an outline based on what I think I understand about how CSS and Gecko set these up. I. Region/Encoding A. Default fonts for styles and sizes for font-types for this Region/Encoding 1. Proportional fonts a. Default size for this all styles of this font-type b. Default fonts for each style of this font-type i. Serif ii. Sans-serif iii. Cursive iv. Fantasy 2. Fixed fonts a. Default size for this all styles of this font-type b. Default fonts for each style of this font-type i. Monospace B. Default font style and minimum size for this Region/Encoding 1. Default font style (can only be Serif of Sans-serif) for this region (when the page does not otherwise specify a default font or style) 2. Minimum point size for this Region/Encoding (do not let any font size on pages in this Region/Encoding be smaller) II. (Repeated for next Region/Encoding via drop-down box) ... In the real world/CSS p-o-v, there's no reason why A1 and A2 couldn't be merged into one list of five "styles" except Gecko has different default sizes for proportional and non-proportional "font-types" only (comment 24) and we should probably respect that. Hopefully I'm mostly correct on this :-) Perhaps there should be a line the complete width of the "beveled area" to further emphasize the "parallelism" between A and B and their subordination to I?

Smokey's comment 34 takes care of my comment 32, but I should be careful what I wish for: now the panel seems to be really busy. Mea culpa. Since the panel clearly separates and identifies proportional and fixed width font settings, maybe just say "Default Size: [ 12 |I] Point" Then line up all the drop lists to make it pretty again.

This is just a quick change to smokey's mockup. I don't have a nib or patch.

The preceding two images are two variations on Warren's suggestions in comment 34 and comment 35. Better? Worse? I thought the size boxes looked a little strange in attachment 165558 [details] and made the left size look a litte crowded/heavy. So in attachment 165652 [details] (NewFont10d.png) I aligned the size drop-downs with the right sides of the font drop-downs. I also wondered if, now that we've adjusted the "font-type" language a bit and added the "Default Size" label, we could move the font size boxes back on the same line as the "font-type" headers (proportional/fixed-width). That's attachment 165653 [details] (NewFont10e.png). But I'm not convinced this is better, with or without the word "point." I missed the change to the "Advanced Settings for [Region/Encoding]:", but the reason I don't have it on the same line as the separator is because the region/encoding names are of very different lengths and will the leave too much of a gap with certain encodings. But that raises the question: do we need the regional label down below, too? Is it clear enough (now that all the font prefs are in one window) that the advanced settings apply per region just like the fonts?

Figure 11-7 of the HIG illustrates left-alignment of stacked drop lists, so I lined them up accordingly in attachment 165558 [details]: http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGLayout/chapter_11_section_2.html I agree the dialog should clearly associate all the settings, including "Advanced," with the encoding. Perhaps group boxes around the font settings with the encoding selection floating above would help the user make the connection. You might then eliminate the encoding notation in the advanced pref group.

A mockup using Interface Builder to illustrate grouping the font preferences.

The group box idea was brilliant, Warren! And the pointers to the AHIG were helpful, too. I think NewFont10g manages to hit all of those requirements while also fitting within the existing width of the Prefs window and not decreasing the size of the font drop-downs. At this point the differences between yours and mine are very small; yours is cleaner and mine retains more of the existing "extra info". Are the "like Times" helpful?

I meant to post "my" nib so no one else would have to start from scratch re-creating. I used a copy of the actual Appearance.nib from the Appearance.prefpane, so presumably if the devs like this (or NewFont10z if that's how far we go!), it could be dropped back in to Camino with only a little bit of cleanup/reconnecting and save the work of redoing the alignment, etc.

Attachment 165782 [details] nib looks good. Change "Fixed-width fonts" to "font" (since mozilla only allows one monospace pref)?

There is one BIG problem with this nib and that is that the color tab now will be as big as the font tab. The main reason why we now have a sheet is to over come this issue. Is there perhaps a solution for this?

Oof, I forgot all about the Colors and Links tab :( The choices right now are: -Leave the fonts dialogue the way it is, awkward and confusing -Add some other colors and links to customize on the other tab and balance out the height :) -Go back to something like NewFont09.png (which is already a line or two taller than Colors) and make it a couple of lines taller to line up the previews and move the "Advanced" options below. This would also eliminate the "like Times" stuff currently in Camino that I asked about in comment 42. Then tweak the spacing on Colors/Links to account for 2-3 new lines. I'll see what I can do for the third one.

Well, I think this is the best we can do without removing the text previews or sticking with the "unbalanced" look of NewFont09.png (and I'm not sure the "1 box for all previews" is technicaly feasible) or making no changes. Unless someone sees something I'm missing or part of the AHIG linked in comment 40 that I'm misinterpreting. Unfortunately, this ends up adding about 5 lines, making everything from "Fixed-width font" and below blank on the Colors & Links tab. If we applied group boxes to the Colors/Links tab, that might buy some more space, but then users and HIG gurus would wonder why group boxes weren't also used on the Fonts tab (and elsewhere in the Camino prefs)!

I don't fear added white space in the "Colors and Links" pane. Even Section 11 of the HIG recognizes white space can be your friend. Yes, the location and grouping of the "Colors" prefs will need to be revisited, but not at the expense of getting the best results from the Fonts pane.

A mockup of possible Colors and Links appearance pane for consistency with Fonts pane. Spreading things out a bit would allow the Fonts pane to follow the HIG without shuffling around to save space. I post this with caution as I don't want to hijack this bug into a complete pref rewrite.

A post over on the MozillaZine forum alerted me to a new option/layout--which is maybe not quite as "polished" as the design we've been refining here, but it has the advantage of being just about the same size as the existing Colors & Links pane (*and* it apparently fixes the "nasty" Carbon/Cocoa issue in bug 175651 [bug 175651 comment 14] too). A Japanese Camino user has written "Camino ExtraFonts" prefpane <http://www.fan.gr.jp/~sakai/moz.html>. Perhaps the devs can work with him to include this in Camino to replace the existing Fonts pane? It's already MPL licensed. Maybe a bit more cleanup (and get it to read/write prefs.js instead of user.js)? Of course I think the one we've been working on here is prettier and more polished, but solving two nasty font bugs for the price of one is really more important :-) (And even without the extra "polish" we put in that took up the extra space, ExtraFonts seems very clear and useable) :-)

It seems that Appearance is now the only prefpane with tabs; all of the other tabbed prefpanes have been broken up. Any chance of that happening to Appearance so that we can switch Fonts to the "taller" layout in NewFont10g.png (attachment #165781 [details]), which seemed popular and more AHIG compliant?

I swear we've talked about breaking up this pref pane into two multiple times on #camino, but apparently none of that discussion ever made it over here. We should re-discuss this for 2.0. I'm all in favour of breaking it up into two panes, probably called "Appearance" and "Fonts".

Note that, among other things, 595px is not very much room to add yet another pane, particularly for certain languages. The plan here is that when murph fixes bug 391076, we'll fix bug 422576 and basically obsolete this bug. (In fact, we may want to simply WF or dupe this one right now.)

That sounds like a plan to me. I'll forward-dupe this to 422576.