Closed Bug 184102 Opened 22 years ago Closed 16 years ago

Font preferences (appearance prefpane) are confusing

Categories

(Camino Graveyard :: Preferences, defect)

Product:
Camino Graveyard
Component:
Preferences
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 422576
Milestone:
Camino2.0

People

(Reporter: mark, Assigned: bugzilla-graveyard)

References

Details

Attachments

(2 files, 15 obsolete files)

NewFont11.png (trying to shrink height)
60.17 KB, image/png
Details
Colors and Links Appearance Pane
42.55 KB, image/png
Details 
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).
Component: General → Preferences
>...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
Attached image NewFont05.png (obsolete) — 
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.
Attached image NewFont06.png (obsolete) — 
Add a (localizable) T letter sample for Serif/Sans-serif which is a not well
known concept.
Attachment #109290 - Attachment is obsolete: true
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.
Attached image NewFont08.png (obsolete) — 
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.
Assignee: saari → sfraser
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Status: NEW → ASSIGNED
Summary: Font preferences are confusing :( → Font preferences are confusing
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.
QA Contact: winnie → sairuh
*** Bug 175681 has been marked as a duplicate of this bug. ***
Attached image NewFont09.png (obsolete) — 
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.
Attachment #109309 - Attachment is obsolete: true
Attachment #109343 - Attachment is obsolete: true
Attached image NewFont09allsizes.png (obsolete) — 
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. :(
Attached image NewFont10.png (better spacing?) (obsolete) — 
Here's a new version that hopefully addresses both Jasper's comments and my
self-critique, in case anyone was interested.
Attachment #163414 - Attachment is obsolete: true
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?
Attachment #165382 - Attachment is obsolete: true
Attachment #165386 - Attachment is obsolete: true
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.
Attached image A mockup for comment 35 (obsolete) — 
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.
Attached image Mockup for comment 40 (obsolete) — 
A mockup using Interface Builder to illustrate grouping the font preferences.
Attached image NewFont10g.png (obsolete) — 
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?
Attachment #110565 - Attachment is obsolete: true
Attachment #110566 - Attachment is obsolete: true
Attachment #165652 - Attachment is obsolete: true
Attachment #165653 - Attachment is obsolete: true
Attached file Zip of edited Appearance.nib (obsolete) — 
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)!
Attachment #165558 - Attachment is obsolete: true
Attachment #165719 - Attachment is obsolete: true
Attachment #165781 - Attachment is obsolete: true
Attachment #165782 - Attachment is obsolete: true
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?
Target Milestone: --- → Camino1.1
QA Contact: bugzilla → preferences
Target Milestone: Camino1.1 → Camino2.0
Summary: Font preferences are confusing → Font preferences (appearance prefpane) are confusing
Blocks: 278820
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".
Hardware: Macintosh → All
Assignee: sfraser_bugs → cl-bugs-new
Status: ASSIGNED → NEW
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.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: