Closed Bug 24846 Opened 25 years ago Closed 14 years ago

[FEATURE] font preference UI in prominent startup page/tab

Categories

(SeaMonkey :: UI Design, enhancement)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: erik, Assigned: jag+mozilla)

Details

Default font size is one of the more important settings in an Internet browser.
It is suggested that we have a very simple UI to set default font faces and
sizes, in the installer. Here is an excerpt from the discussion:


    The sizes and fonts of text in Web pages are
    often based on your preferences. Select your
    preferred text sizes and fonts, making sure
    all sizes remain legible:
     __________________________________________
    | This is "medium" text. 0123456789&ABCD |A|
    | This is "small" text. 0123456789&ABCDE | |
    | This is "x-small" text. 0123456789&ABC |x|
    |_This_is_"xx-small"_text._0123456789&AB_|V|
    [<]_x__________________________________[>]
                    ________   _________
                   [_Larger_] [_Smaller_]  16
                    ____________________
            Serif: [_Times_New_Roman____]  (x)
                    ____________________
       Sans-serif: [_Arial______________]  ( )

                               _______    ____
                              [_Reset_]  [_OK_]



Note the word "often" in the setup. And larger/smaller buttons accompanied
by a counter showing state - the px value on "medium". All onclick events
update the preview. Larger/smaller buttons decrement the counter by 1px
below 16px, and increment it by 2+px above 16px.
This is an enhancement, marking as such. Other solutions were discussed in the 
newsgroups that do not involve the installer, and I've never seen an installer 
that sets such trivial preference details. Default font size should be set 
based on some relation to the user's preferred system font size.

Further more I believe it's mostly the Unix folk having font size issues and we 
don't have an installer for Unix.
Severity: major → enhancement
I don't think it's mostly Unix folk.  The problem is a basic one on the web. 
Web "designers" believe that users never change the default font size, so they
write all their pages to *lower* the font size from the default, since they
think the defaults look to big.  This causes problems for users for whom the
default isn't too big.  If this were part of the UI of a major browser, then
designers would start assuming that users set their font size as they want it
and stop trying to mess with it.

IMO, font size is the MOST important part of the UI of a browser.  The most
common complaints I hear about using the web from people my parents age are that
all the fonts are too small, and they can't read anything.  Many of these people
don't know how to change the default font size.
I agree very strongly with David. This is not a "trivial preference detail." It is as essential as any 
other particular captured in the profile setup. It's the "do you read me/can you read this?" 
question, properly prior to any further communication. There are no XP system preferences for 
"medium" text size anyway - only for specific OS contexts like window or icon labels. Please 
review the relevant threads and reconsider.

Visit your favorite high-traffic site and determine the percentage of the source HTML size 
responsible for setting the font size to something lower than the obscure user preference size, 
presumedly left at the 12pt default (16px at  the Windows default). My investigations turn up 
figures between 10 and 30%. Consider the speed (to say nothing of usability) benefits if font-size 
UI is rescued from its present obscurity and authors begin to respect the user font-size 
pr
adding selmer to the CC: list in case this could be better dealt with within the 
profile manager.
Status: NEW → ASSIGNED
Target Milestone: M17
Whereas preferences are, in fact, stored in the profile, profile manager does 
not manage preferences.  The preference manager does that.  In any case, the 
fundamental decision would be whether to bulk the initial startup with this 
added dialog.  If this gets added to the installer, it must be controlled with a 
config.ini setting so it can be turned off at need.  

The profile manager would not be the place to implement this dialog.

It's also not clear to me why Edit|Preferences|Appearance-Fonts is too hard to 
discover.  Isn't that the standard place to find such a thing with ANY app?
It's perfectly clear to you and me, but not to 90% of users.  Therefore, web
"designers" believe that they should design web pages assuming that users never
change the default preferences.  Since the default fonts are too large for their
(young) eyes, web "designers" make pages that reduce font size.  Some of these
set fixed font sizes.  This makes web pages even harder to read for older users
than they would be if they just had the default.

Web pages are about reading text.  The size of that text is one of the most
important usability aspects of the browser.
Reassigning to German, we obviously need this looked at from a UE perspective.

The install wizard is *not* the right place for this as it knows nothing about 
profiles plus the wizards are platform native and can't show what Mozilla is 
going to show.

The Profile Creation code could do this, but it seems mighty odd to special 
case this one preference (though I can see your point).

Or we can admit the default font size is wrong and adjust it based on the 
screen size or something. Or make an additional preference that sets a minimum 
font size, or which says "ignore font size settings", or ...?
Assignee: ssu → german
Status: ASSIGNED → NEW
I would also not be sure why to single out this preference, I am sure other will 
make the case for other things to add to the installer. Why not have a start page 
when the browser gets loaded the first time that show the fonty choices more 
accurately. 
Keep in mind that:
- the installer is all native and does not have any awareness of how Gecko 
renders fonts
- the installer should be kept to a bare minimum to minimize the initial download
- users will likely not have the patience to walk through multiple setting 
dialogs before they can finally use the product.
Therefore my vote goes to doing this in an  intelligent startup XUL/HTML page. 
Frowarding to Don to look at possible implementations...
+ G
Assignee: german → don
German's "smart startup page" sounds like a sound approach to me. The point was never 
really to get this pref in the installer, but to get it "front and center" someplace in the 
configuration process
Adding myself to cc list.
If we do anything, it will have to be done in consideration of the 
install/startup/activation experience.

thx,
kevin
Move to M20 target milestone.
Target Milestone: M17 → M21
Can we agree that installer is the wrong place? I think a preference chrome 
loaded in the sidebar on first run would probably work, and we do have bugs 
about useful preferences in the sidebar [it'll never happen].

Asa should we move this somewhere else?
Keywords: ui
I like german's suggestion.  I would further suggest that if someone decides to
bring this font choice to "front and center" either in the installer, the
sidebar or a startup page that it would probably be a good idea to disucss this
in the newsgroups and look for some consensus before spending significant
resources on it.
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy
Assignee: don → vishy
Changing obsolete M20+ milestones to closest equivalent, "Future"
Target Milestone: M21 → Future
-> default owner
Assignee: vishy → dveditz
QA Contact: gbush → bugzilla
Target Milestone: Future → ---
Thought this was dead long ago. Let one guy in and everyone will want to be set
in the install.
Status: NEW → ASSIGNED
If someone wants to re-word the summary so it doesn't sound like an Installer
request and reassign to XPapps then feel free to reopen. Since blaker just
reassigned this out of the XPapps group I'm assuming they don't want to do it
either.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
I think blake just did a mass-reassign of vishy's bugs to the default owner.
Status: RESOLVED → REOPENED
Component: Installer → XP Apps
Resolution: WONTFIX → ---
->XPApps
Assignee: dveditz → trudelle
Status: REOPENED → NEW
QA Contact: bugzilla → sairuh
Summary: [FEATURE] font preference UI for installer → [FEATURE] font preference UI in prominent startup page/tab
Target Milestone: --- → Future
I agree, we should have something like was originally suggested by Erik. I also
suggest on platforms that have font families (Like on X) we should be trying to
look for Microsoft's free ttf fonts. (Yes, I know its Microsoft, but they look
very good) From what I've seen (atleast at 75dpi font (_not_ 72dpi))
monotype-arial of serif, monotype-times new roman as sans-serif, and
monotype-courier new as monotype. With, of course, proportional set as serif @
16, and monospace set as 12, with a minimum font size of 10.... that whole setup
looks _alot_ like msie, and imho looks very good. However, I dont know what msie
uses for cursive and fantasy by default, but they are probably monotype or
microsoft family fonts.
Product: Core → Mozilla Application Suite
Assignee: trudelle → jag
Priority: P3 → --
QA Contact: bugzilla
Target Milestone: Future → ---
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago → 14 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.