XP preferences, user stylesheet UI, etc.
Todd Fahrner
user CSS. Initially I brought them up in a MacIE mailing list (Mac users
suffer most from such problems), but I'm interested in a cross-UA, XP
solution:
Apologies for the thin documentation. Let's build some here!
Followups to netscape.public.mozilla.layout , please.
--
Todd Fahrner The printed page transcends space and time.
mailto:fah...@pobox.com The printed page, the infinitude of books,
http://www.verso.com/agitprop/ must be transcended. THE ELECTRO-LIBRARY.
- El Lissitzky, 1923
Braden N. McDaniel
news:7950ok$ne...@secnews.netscape.com...
>I've been noodling some UI ideas that would relate to XP font issues and
>user CSS. Initially I brought them up in a MacIE mailing list (Mac users
>suffer most from such problems), but I'm interested in a cross-UA, XP
>solution:
>
>http://style.verso.com/cssui/
>
>Apologies for the thin documentation. Let's build some here!
Interesting. A few questions...
Under "A Proper CSS Browser's Prefs", why the radio buttons for ppi?
Shouldn't this simply be a function of the current monitor size and
resolution?
And what exactly does "pixel object scaling threshold" do?
Braden
Todd Fahrner
<bra...@shadow.net> wrote:
> Todd Fahrner <fah...@pobox.com> wrote in message
> news:7950ok$ne...@secnews.netscape.com...
>>http://style.verso.com/cssui/
> Under "A Proper CSS Browser's Prefs", why the radio buttons for ppi?
> Shouldn't this simply be a function of the current monitor size and
> resolution?
OS's typically don't know this, so users/UAs must step in. Users may have
good reasons for not wanting "True WYSIWYG" anyway, so it should be
discretionary. As for why the dialogue doesn't solicit display dimensions
and pixel counts directly - probably the same reason printers are sold as
"1200dpi" rather than " 11"x17"x13200x20400 " Brevity, clarity, habit.
I think the XP default should be 96ppi, in concession to the reality that
there are a whole lot of Windows-based authors who don't know the difference
between a point and 1.33333 pixels.
> And what exactly does "pixel object scaling threshold" do?
As you and I have discussed, Braden, CSS1 recommends that UAs scale pixels
when the output medium resolution varies "significantly" from that of a
"typical" computer display. It goes on to suggest a "reference pixel" of
1/90" as the basis for scaling to the new device resolution.
"Pixel object scaling threshold" sets the point at which this scaling kicks
in.
So if you're using a 180ppi display in 4 years, and you're viewing a
1996-99-era GIF-and-table HTML confection, and you've got your scaling
threshold set to 199%, your UA should scale all pixel objects by 200%.
Similarly, when you print said page to a 300dpi printer (even today), each
GIF/table pixel should translate to 3.3333 printer pixels.
If you wanted to print the GIF/table thing at the printer's resolution, you
could crank the pixel scaling threshold up to 900% or so, or override in
some print dialogue or other.
But it's not just to get ready for sci-fi display scenarios or control-freak
printing.
In addition to the preference dialogs, there must be handy top-level UI to
adjust a page's visual scale. But for performance and visual quality
reasons, it will not be desirable to scale all page objects by small,
arbitrary intervals - certainly not before we're in vector graphics land.
No, what people want to do most of the time is crank the font size up or
down a little - that's all.
So the top-level UI would affect only font sizes *until* the adjusted font
size reached the specified pixel-object scaling threshold. At which point
all page objects would scale, to help keep the layout from breaking.
Option-accessing the same UI element could override the current
pixel-scaling threshold and magnify everything by the desired factor. Like
Opera's zoom function.
Braden N. McDaniel
>In article <795faq$ne...@secnews.netscape.com> , "Braden N. McDaniel"
><bra...@shadow.net> wrote:
>
>> Todd Fahrner <fah...@pobox.com> wrote in message
>> news:7950ok$ne...@secnews.netscape.com...
>
>>>http://style.verso.com/cssui/
>
>> Under "A Proper CSS Browser's Prefs", why the radio buttons for ppi?
>> Shouldn't this simply be a function of the current monitor size and
>> resolution?
>
>OS's typically don't know this, so users/UAs must step in.
That, in itself, doesn't answer my question. Even if the OS can't do font
scaling, surely it can be queried--transparently--by the browser for the
monitor settings and specifications.
> Users may have
>good reasons for not wanting "True WYSIWYG" anyway, so it should be
>discretionary.
What exactly is meant by "WYSIWYG" in this context?
Why would a user want to use a pixel scaling that is inconsistent with the
current display resolution? Why not just change the display resolution (and
have the browser appropriately change its scaling dynamically)?
>I think the XP default should be 96ppi, in concession to the reality that
>there are a whole lot of Windows-based authors who don't know the
difference
>between a point and 1.33333 pixels.
Why should there be an XP default??? I don't think author ineptitude is
sufficient cause for such a draconian (and probably hopelessly unenforcible)
measure.
>> And what exactly does "pixel object scaling threshold" do?
>
>As you and I have discussed, Braden, CSS1 recommends that UAs scale pixels
>when the output medium resolution varies "significantly" from that of a
>"typical" computer display. It goes on to suggest a "reference pixel" of
>1/90" as the basis for scaling to the new device resolution.
Yes, I figured it had something to do with this, but the relationship wasn't
totally lucid.
>"Pixel object scaling threshold" sets the point at which this scaling kicks
>in.
>
>So if you're using a 180ppi display in 4 years, and you're viewing a
>1996-99-era GIF-and-table HTML confection, and you've got your scaling
>threshold set to 199%, your UA should scale all pixel objects by 200%.
I don't understand how it would identify the objects it is supposed to
scale.
>Similarly, when you print said page to a 300dpi printer (even today), each
>GIF/table pixel should translate to 3.3333 printer pixels.
In that case, *every* pixel measurement send to the device should be scaled
accordingly. In the case you're talking about, only selected content would
get scaled for the device (the monitor). How is that content selected?
>If you wanted to print the GIF/table thing at the printer's resolution, you
>could crank the pixel scaling threshold up to 900% or so, or override in
>some print dialogue or other.
>
>But it's not just to get ready for sci-fi display scenarios or
control-freak
>printing.
>
>In addition to the preference dialogs, there must be handy top-level UI to
>adjust a page's visual scale. But for performance and visual quality
>reasons, it will not be desirable to scale all page objects by small,
>arbitrary intervals - certainly not before we're in vector graphics land.
>No, what people want to do most of the time is crank the font size up or
>down a little - that's all.
>
>So the top-level UI would affect only font sizes *until* the adjusted font
>size reached the specified pixel-object scaling threshold. At which point
>all page objects would scale, to help keep the layout from breaking.
All this sounds too complicated for Joe User to understand.
Braden
Todd Fahrner
<bra...@shadow.net> wrote:
>>> Under "A Proper CSS Browser's Prefs", why the radio buttons for ppi?
>>> Shouldn't this simply be a function of the current monitor size and
>>> resolution?
>>
>>OS's typically don't know this, so users/UAs must step in.
>
> That, in itself, doesn't answer my question. Even if the OS can't do font
> scaling, surely it can be queried--transparently--by the browser for the
> monitor settings and specifications.
Ideally, perhaps. But again, this assumes that the "real" physical
resolution - such as would deliver true WYSIWYG - is the only valid choice.
>> Users may have
>>good reasons for not wanting "True WYSIWYG" anyway, so it should be
>>discretionary.
>
> What exactly is meant by "WYSIWYG" in this context?
That any physical measure - "12pt", for example - specified in CSS or
derived from some default setting must measure 12 literal points (1/6") on
the display surface unless explicitly "zoomed" in or out. I assert that this
sort of WYSIWYG is of questionable value as a default, reflecting the
concerns of desktop publishers more than of Web users. Especially today's
Web, whose authors still tend too often to think they're desktop publishers.
<g>
> Why would a user want to use a pixel scaling that is inconsistent with the
> current display resolution? Why not just change the display resolution (and
> have the browser appropriately change its scaling dynamically)?
Because changing display resolution is comparatively tedious, and affects
more than the application at hand, and the choices are often few, and dredge
up issues like refresh rate and color depth and pincushion and so on. Or am
I misunderstanding?
>>I think the XP default should be 96ppi, in concession to the reality that
>>there are a whole lot of Windows-based authors who don't know the
> difference
>>between a point and 1.33333 pixels.
>
> Why should there be an XP default??? I don't think author ineptitude is
> sufficient cause for such a draconian (and probably hopelessly unenforcible)
> measure.
There's no such thing as a draconian default, provided there's decent UI to
override where desired.
An XP default means that any variance from said default may be assumed to
result from express user preference. Such variances will command better
authorial respect for "the user environment". In contrast, gratuitous,
non-user driven XP differences and weak, ill-conceived UI concerning fonts,
sizes and colors encourage presumptuous authoring practices such as <font
size="-1"> for body copy, terrabytes of spurious GIFtext, and generally
anemic markup.
Excesses aside, a desire for XP-consistent rendering is not always a sign of
author ineptitude, but often simply an artifact of weak visual design tools
- almost inevitably pixel-based. Whenever live text and "pixel objects" -
graphics, table cells, etc. - must maintain a consistent visual
relationship, the choices are few and grim in HTML. The compromises tend to
favor the majority audience: Windows users - users with a 96ppi default
logical resolution and no powerful UI to adjust font size. And the result is
that Mac and X11 users are finding it increasingly hard to read on the Web.
Of course I hope this will change over the next several years as CSS is
deployed, but in the meantime there's a messy Web to browse, and
commercially viable browsers to develop. A browser that will let Mac and X11
users comfortably read HTML documents saved out of MS Word for Windows at
"8pt" would be nice. Setting the default logical resolution to 96ppi would
go a long way toward this.
>>So if you're using a 180ppi display in 4 years, and you're viewing a
>>1996-99-era GIF-and-table HTML confection, and you've got your scaling
>>threshold set to 199%, your UA should scale all pixel objects by 200%.
>
> I don't understand how it would identify the objects it is supposed to
> scale.
All rendered objects with either a specified or inherent measure in pixels,
such as raster graphics, presentational HTML bits like table cell widths and
borders, etc. Type and other vector objects would simply be redrawn at the
same factor. Your basic zoom. But I suspect I'm missing something in your
question. (Not much sleep.)
> All this sounds too complicated for Joe User to understand.
So is internal combustion. On the one hand you don't trust authors not to
abuse XP-consistent defaults; on the other, you don't think Joe User can
deal with a powerful UI.
Finally, Joe User doesn't need to understand all these issues. Joe User just
clicks the bigger/smaller buttons as desired, and something reasonable
happens because the default settings are reasonable. The dialogues I've
mocked up can be broken into easier chunks, with better wording. The kid
down the street can show him the "option click" trick, and explain what a
serif font is if he's curious. Meanwhile, authors can relax their grip on
CSS pixels and points and start using user-friendlier size keywords and
relative measures, secure that even casual users need little help setting
the size of "medium" text, no matter what font.
Todd Fahrner
<hec...@netscape.com> wrote:
> Thank you for doing an example UI; it makes some of these issues clearer
> to see an actual proposed preferences interface. I'm going to take the
> position of a naive user unfamilar with the details of CSS1, etc. (This
> is a role which comes quite naturally to me.) Here are my comments from
> that point of view (expect me to stumble occasionally on terminology,
> feel free to correct me):
Understood. I should say that I don't offer this UI as a paragon of clarity
or good looks. At this point I'm concentrating on *what* I hope the user
will fundamentally be able to do, and what the UA should be able to do for
him/her. I'm not yet attached to any model of *how*.
> But a minor nitpick: You're relying on the user to know what a serif
> font is vs. sans-serif vs. monospace, and so on. (From my minimal CSS
> reading I recall that these are the actual CSS1 terms that you'd see in
> a style sheet, correct?)
Right.
> Communicator 4.5 instead uses the terms
> "Variable-width font" and "Fixed-width font"; I know that's
> inappropriate in this context because it doesn't, e.g., distinguish
> between serif and sans-serif, but it is arguably more comprehensible to
> the naive. So leave "serif", etc., in the UI, but I think it would help
> if the list of fonts could actually show what the fonts look like as
> you're selecting one; then the user could better infer what "serif",
> "sans=serif", etc., mean based on the visual appearance common to all
> the fonts they see presented in the list for their selection.
Yes - that's what I meant with that cramped little text sample. It should
update live to show what effect the various settings have. Colors too, from
some other panel. I think this would be even more instructive than the old
"proportional/monospace" bit.
> 2. The "default" setting under "Preferred fonts" seems just a tad
> unclear; it took me a moment to figure out what it did. I presume it's
> intended to select the default font to use if no font or font category
> (correct term?) is specified for the page (or whatever -- I'm not
> familar with the rules of style inheritance). It seems that the UI
> would be more understandable if the setting was headed "default
> <something>" or "font to use if <something>", but I have no idea how
> better to word this.
CSS authors can specify a list of preferred faces for something. But because
they generally rely on those fonts being installed on the client, they can
also specify a generic font descriptor such as "script". It's then up to the
UA to apply a "script" face. Fonts, UAs, and OS's aren't always so
communicative, so the user should have a chance to participate in this
decision.
As for the rest of the confusion, chalk it up to poor visual grouping. No
contest - too much stuff going on in that space.
> 3. The checkbox "Use only my preferred fonts" is reasonably clear, but
> might be clearer if it was expanded to read "Use only my preferred
> fonts, overriding document-specified fonts" or words to that effect.
Ditto: space, haste, etc. I'll limit my comments to points of *functional*
misunderstanding going forward.
> 4. The list of text samples at the various sizes is useful. However
> it's unclear exactly what preferences they're supposed to be associated
> with. It looks as if you're trying to make the samples do double duty:
Yep. It's sort of important that they do: the suitability of these settings
can't properly be judged in isolation, as different fonts look radically
bigger or smaller at the same nominal point sizes. It's especially important
to observe what effect the base size of "medium" has on the smallest
"xx-small" rendering.
> 5. The purpose of the input field labelled "'Medium' text size" is again
> reasonably but not totally clear. Perhaps it might improve things a bit
> to expand the wording of the label a bit, perhaps to something like
> "Actual size to use for 'medium'-size text". (I'm naively presuming
> that this really is intended to be an "actual" size, i.e., an absolute
> size for text as displayed on the screen or printed; however given all
> the subtleties of this general topic I certainly could be wrong, in
> which case it would be helpful to know what this really means.)
Don't get me started on what size it "really" is on screen or in print -
it's a messy issue. The important thing is that Web pages typically indicate
levels of relative logical importance by font size changes. Presumably, the
whole range of these sizes should be legible. CSS authors have many powerful
unit systems from which to choose in establishing visual heirarchy among
typographical elements on a page, but among the most potentially useful and
user-friendly is the keyword system. It extends from xx-large to xx-small,
with "medium" in the middle.
Unlike CSS's other, more precise unit systems, keywords have the potential
advantage of meaning what the user wants them to mean, or what the UA
developer knows will result in a well-articulated range of legible font
sizes. This dialogue, in short, lets the user optimize how this range will
appear in pages by changing the middle "medium" value.
In Mosaic-derivative browsers like Navigator and IE, the initial value of
the "medium" value has been 12pt. On the Macintosh (72ppi), 12pt looks
rather smaller than it does elsewhere. In fact, virtually no font is legible
below 9pt on Mac. So figure: if "medium" is 12pt, and there remain three
keyword sizes below 12pt to render distinctly, this is the only possible
mapping:
medium: 12pt
small: 11pt
x-small: 10pt
xx-small: 9pt
These aren't very distinct from one another. When the user sees this in the
preview, the user might choose to select a larger "medium" size, for better
articulation of the smaller sizes, and have a better Web experience.
> 6. As a naive user I have no idea why I should have to specify "96 ppi"
> or "72ppi" or whatever. (As a naive user I don't even know whether
> "ppi" means "pixels per inch" or "points per inch" or whatever.) I
> agree with Braden McDaniel that this at least _seems_ like something the
> browser should be able to figure out for itself, or at least make an
> educated guess.
The user would see the effect of adjusting this in the text preview area,
and in fact the given 96- and 72-ppi choices would effectively toggle
between "Windows-size fonts" and "Mac-size fonts". Mac users would discover
that many currently illegible corners of the Web become legible with
"Windows-size" fonts.
If the browser were to ask the OS for the resolution, the OS would probably
lie, and the user would be cheated of a useful choice.
I don't suppose it would be very XP-hip to offer a "Windows-size" font
choice in a Mozilla dialog, but that's basically what the 96ppi choice
represents.
> Isn't at least screen resolution
> obtainable _somewhere_ on all of Windows, Mac, and X?
Ha! Liars, every one. <g> Cynically speaking, the resolution reported by
the OS is the one at which typical print documents created by apps on that
OS happen to look best. It's less helpful for Web documents. The "real"
resolution is something else, and not as relevant as commonly asserted.
Even if the OS tried hard, it couldn't know about the state of the analog
controls on your CRT. These can affect real resolution very significantly.
> 7. As a naive user I have no idea what a "pixel object scaling
> threshold" is. If there isn't any way to explain this or illustrate it,
> then I'd either get rid of the concept or hide it in an "advanced"
> dialog.
Fine. I hope the other explanations accumulating around this thread address
the question.
> 8. As a naive user I also am not real clear on what "adjust font sizes
> to look like my default" means? Does it mean, for example, that if the
> document specified that "medium"-size text is actually 10 points then
> I'd override that setting with my setting of 12 points (or whatever)?
The setting would apply a simple algorithm to fonts other than the default,
scaling them up or down slightly from their specified size so that they look
about the same size as the default. This algorithm and its effects are
explained (with illustrations!) in CSS-2, here:
http://www.w3.org/TR/REC-CSS2/fonts.html#propdef-font-size-adjust
> If so, then perhaps you should change the wording for the "'Medium' text
> size" field (from item 5 above) to something like "Default size to use
> for 'medium'-size text"; in other words, use the actual word "default"
> in both places, in order to associate them in the user's mind.
I agree that is clearer. I must say these GIFs are getting uglier and uglier
to me by the minute....
> 9. I'm also not 100% clear on what "reset to defaults" means. Does it
> mean to reset the value of the "'Medium' text size" field, PPI value,
> etc., to some set of "factory-specified" values built into the browser?
Factory settings, yes.
Frank Hecker
> I've been noodling some UI ideas that would relate to XP font
> issues and user CSS. Initially I brought them up in a MacIE
> mailing list (Mac users suffer most from such problems), but I'm
> interested in a cross-UA, XP solution:
>
> http://style.verso.com/cssui/
Thank you for doing an example UI; it makes some of these issues clearer
to see an actual proposed preferences interface. I'm going to take the
position of a naive user unfamilar with the details of CSS1, etc. (This
is a role which comes quite naturally to me.) Here are my comments from
that point of view (expect me to stumble occasionally on terminology,
feel free to correct me):
1. The way to set the "preferred fonts" seems reasonably understandable:
these are the exact fonts you want to use for serif, sans-serif, etc.
But a minor nitpick: You're relying on the user to know what a serif
font is vs. sans-serif vs. monospace, and so on. (From my minimal CSS
reading I recall that these are the actual CSS1 terms that you'd see in
a style sheet, correct?) Communicator 4.5 instead uses the terms
"Variable-width font" and "Fixed-width font"; I know that's
inappropriate in this context because it doesn't, e.g., distinguish
between serif and sans-serif, but it is arguably more comprehensible to
the naive. So leave "serif", etc., in the UI, but I think it would help
if the list of fonts could actually show what the fonts look like as
you're selecting one; then the user could better infer what "serif",
"sans=serif", etc., mean based on the visual appearance common to all
the fonts they see presented in the list for their selection.
2. The "default" setting under "Preferred fonts" seems just a tad
unclear; it took me a moment to figure out what it did. I presume it's
intended to select the default font to use if no font or font category
(correct term?) is specified for the page (or whatever -- I'm not
familar with the rules of style inheritance). It seems that the UI
would be more understandable if the setting was headed "default
<something>" or "font to use if <something>", but I have no idea how
better to word this.
3. The checkbox "Use only my preferred fonts" is reasonably clear, but
might be clearer if it was expanded to read "Use only my preferred
fonts, overriding document-specified fonts" or words to that effect.
4. The list of text samples at the various sizes is useful. However
it's unclear exactly what preferences they're supposed to be associated
with. It looks as if you're trying to make the samples do double duty:
I presume they're primarily illustrating the actual point sizes of
"medium", "small", etc., text. However at the same time they could also
be taken as showing the appearance of text using the preferred fonts
chosen in the settings immediately above; a _really_ naive user might
then come to the incorrect conclusion that the samples are also showing
the visual appearance of serif, sans-serif, monospaced, etc., text. (I
know, this seems foolish; but I suspect users have believed things just
as foolish or even worse.)
I think it might be better if the list of size samples were included
wholly within the "size and scaling" section of the dialog box; I think
that would make it more clear that they are intended to illustrate
size-related appearance and not font-related appearance. If you then
also included actual samples as part of the font selection lists (as
suggested above), I think the distinction would be even clearer.
5. The purpose of the input field labelled "'Medium' text size" is again
reasonably but not totally clear. Perhaps it might improve things a bit
to expand the wording of the label a bit, perhaps to something like
"Actual size to use for 'medium'-size text". (I'm naively presuming
that this really is intended to be an "actual" size, i.e., an absolute
size for text as displayed on the screen or printed; however given all
the subtleties of this general topic I certainly could be wrong, in
which case it would be helpful to know what this really means.)
6. As a naive user I have no idea why I should have to specify "96 ppi"
or "72ppi" or whatever. (As a naive user I don't even know whether
"ppi" means "pixels per inch" or "points per inch" or whatever.) I
agree with Braden McDaniel that this at least _seems_ like something the
browser should be able to figure out for itself, or at least make an
educated guess.
For example, on Windows isn't this inferable from a combination of
screen resolution and exact monitor type, as specified in the "Display"
control panel? I know the user might have specified a generic monitor
type, but still... As a naive user I probably can be relied upon to at
least know whether I have a 14-inch monitor vs. a 15-inch monitor, etc.
(Presumably I remembered this from when I bought it, or I could just
measure it -- in which case it would help if the UI told me it was a
diagonal meaurement.)
Perhaps the user could enter just the monitor size on this main dialog
box, and the browser could get the screen resolution from the OS, and
thence compute the PPI for me? Isn't at least screen resolution
obtainable _somewhere_ on all of Windows, Mac, and X? Maybe this
wouldn't work in all cases, but for the cases where it wouldn't you
could have a separate "Advanced" dialog box where more sophisticated
users could specify an exact value for PPI.
7. As a naive user I have no idea what a "pixel object scaling
threshold" is. If there isn't any way to explain this or illustrate it,
then I'd either get rid of the concept or hide it in an "advanced"
dialog.
8. As a naive user I also am not real clear on what "adjust font sizes
to look like my default" means? Does it mean, for example, that if the
document specified that "medium"-size text is actually 10 points then
I'd override that setting with my setting of 12 points (or whatever)?
If so, then perhaps you should change the wording for the "'Medium' text
size" field (from item 5 above) to something like "Default size to use
for 'medium'-size text"; in other words, use the actual word "default"
in both places, in order to associate them in the user's mind.
9. I'm also not 100% clear on what "reset to defaults" means. Does it
mean to reset the value of the "'Medium' text size" field, PPI value,
etc., to some set of "factory-specified" values built into the browser?
If so, perhaps this needs better wording. Also, why don't you have such
a button for the "Preferred Fonts" section? Or is this button intended
to apply to both sections? (If so, it should be outside the "Size and
scaling" section.)
That concludes my comments on the first dialog box. I have some other
comments on the other two UI samples ("View -> Scale" menu and "More
Scale Options" dialog), but I've run out of time and this seems like a
good place to stop.
Frank
--
Frank Hecker Pre-sales support, Netscape government sales
hec...@netscape.com http://people.netscape.com/hecker/
Frank Hecker
> I should say that I don't offer this UI as a paragon of clarity
> or good looks. At this point I'm concentrating on *what* I hope
> the user will fundamentally be able to do, and what the UA should
> be able to do for him/her. I'm not yet attached to any model of
> *how*.
I understand this is only a rough sketch of a UI, and not meant as a
finished polished interface. However I thought it was definitely worth
commenting on, especially as I think the issues of "what" and "how" are
very interrelated; that is, it's much easier for me (and I suspect other
naive users) to understand what it's possible to do if the model of how
to do it is refined and clarified.
Re setting preferred fonts:
> Yes - that's what I meant with that cramped little text sample. It
> should update live to show what effect the various settings have.
> Colors too, from some other panel. I think this would be even more
> instructive than the old "proportional/monospace" bit.
I think we're agreed on this point then: in the UI to select the
preferred fonts, display live text samples using the font. However I
disagree that the samples here should reflect color as well; I comment
more on the overall "text preview" issue below.
> CSS authors can specify a list of preferred faces for something.
> But because they generally rely on those fonts being installed on
> the client, they can also specify a generic font descriptor such
> as "script". It's then up to the UA to apply a "script" face.
Understood; an explanation like this seems appropriate for inclusion in
the online help.
> > 4. The list of text samples at the various sizes is useful.
> > However it's unclear exactly what preferences they're supposed
> > to be associated with. It looks as if you're trying to make the
> > samples do double duty:
>
> Yep. It's sort of important that they do: the suitability of these
> settings can't properly be judged in isolation, as different fonts
> look radically bigger or smaller at the same nominal point sizes.
> It's especially important to observe what effect the base size of
> "medium" has on the smallest "xx-small" rendering.
OK, I understand this. Some comments then:
* Minor nit: The control to set the default size for "medium" text
should probably be a combobox rather than a simple input field, so the
user can easily select 10, 12, 14, 18, etc., as choices, while still
being able to enter an arbitrary point size.
* Unlike the case of selecting the preferred fonts, you don't view the
samples here directly in the context of the control setting the default
text size for "medium" text; instead you change the default size, and
that change is reflected in the appearance of the sample text somewhere
else. That to me says that this sample text should probably be in a
separate display-only section of the dialog box, headed "Text Preview"
or something similar. The appearance of the text would then reflect all
the choices made in the other sections: preferred fonts, default size
for "medium" text, scaling, color, etc.
* In your example the text in the sample for "medium", "small", etc.,
presumably would be displayed in the serif font chosen as the default
font for the serif font category, for the reason you mentioned re
variability of font appearance at different point sizes. However this
same argument also applies to the other font categories: sans-serif,
monospace, etc. So I would argue that the text preview area I proposed
above should also contain samples of text in the default fonts for those
categories as well.
But if you do that and at the same time retain samples for bold text,
italic/oblique, bold italic, etc., then that makes for a lot of text
samples at a given size. The number of combinations should probably be
reduced to a manageable number, but I can't presume to say exactly what
that number should be.
> Don't get me started on what size it "really" is on screen or in
> print - it's a messy issue.
I didn't mean to, honest :-)
> Unlike CSS's other, more precise unit systems, keywords have the
> potential advantage of meaning what the user wants them to mean,
> or what the UA developer knows will result in a well-articulated
> range of legible font sizes. This dialogue, in short, lets the
> user optimize how this range will appear in pages by changing the
> middle "medium" value.
OK, I think that's understandable, and I also agree that terms like
"medium", "x-small", etc., are intuitively understandable to naive users
by analogy to clothing sizes, etc.
> So figure: if "medium" is 12pt, and there remain three
> keyword sizes below 12pt to render distinctly, this is the only
> possible mapping:
>
> medium: 12pt
> small: 11pt
> x-small: 10pt
> xx-small: 9pt
>
> These aren't very distinct from one another. When the user sees
> this in the preview, the user might choose to select a larger
> "medium" size, for better articulation of the smaller sizes, and
> have a better Web experience.
OK as far as it goes, but I'm beginning to lose you here, especially
considering the next topic of "ppi". (To foreshadow my comments below,
your argument here would lead me to conclude that you're advocating that
the browser built-in setting for "Default size for to use for
'medium'-size text" should actually be, say, 14 points for the Mac
instead of 12 as it would be for Windows. But I don't think that's
really what you're saying, correct?)
> The user would see the effect of adjusting this in the text preview
> area, and in fact the given 96- and 72-ppi choices would
> effectively toggle between "Windows-size fonts" and "Mac-size
> fonts". Mac users would discover that many currently illegible
> corners of the Web become legible with "Windows-size" fonts.
Understood; a couple of comments then:
* To a naive user it seems like what you're saying is something like
"You can use the 'standard' way to size text assumed by your system, or
you can make it be sized like it would on Windows, in which case it may
be more readable." So maybe this would work better in the main dialog
box as a simple checkbox with brief explanation, leaving the discussion
of PPI and the more complex settings to an "Advanced" dialog box.
Here's a (very) crude example of what I mean:
Many authors design documents so that the text is most legible
when viewed on a particular operating system, such as Windows
+-+
|X| Scale fonts to appear sized as they would display on Windows
+-+
And (blasphemy coming up...) wouldn't it make sense for this to be
checked by default? Not to mention, not have this control at all on
Windows, where it's presumably not needed?
* Are setting the assumed PPI and setting the default size for "medium"
text really just two ways of doing the same thing from the naive user's
point of view (i.e., making text more legible)? Given the complexity of
the problem I suspect the answer is "no", but I think both I and the UI
could definitely benefit from some additional clarification.
> I don't suppose it would be very XP-hip to offer a "Windows-size"
> font choice in a Mozilla dialog, but that's basically what the
> 96ppi choice represents.
Call me un-hip then, but that's exactly what I'm suggesting be done.
> Cynically speaking, the resolution reported by the OS is the one
> at which typical print documents created by apps on that OS
> happen to look best. It's less helpful for Web documents. The
> "real" resolution is something else, and not as relevant as
> commonly asserted.
That seems another argument for keeping all discussion of resolution,
screen sizes, PPI, etc., in an "Advanced" dialog box.
> > 7. As a naive user I have no idea what a "pixel object scaling
> > threshold" is. If there isn't any way to explain this or
> > illustrate it, then I'd either get rid of the concept or hide
> > it in an "advanced" dialog.
>
> Fine. I hope the other explanations accumulating around this
> thread address the question.
Not quite yet, but I'll reread your discussion and see if I can restate
it in naive user terms.
> > 8. As a naive user I also am not real clear on what "adjust font
> > sizes to look like my default" means? Does it mean, for
> > example, that if the document specified that "medium"-size text
> > is actually 10 points then I'd override that setting with my
> > setting of 12 points (or whatever)?
I think from your response here the answer is "no", this control means
something other than what I thought.
> The setting would apply a simple algorithm to fonts other than the
> default, scaling them up or down slightly from their specified
> size so that they look about the same size as the default. This
> algorithm and its effects are explained (with illustrations!) in
> CSS-2, here:
>
> http://www.w3.org/TR/REC-CSS2/fonts.html#propdef-font-size-adjust
That helps somewhat, though I'm still not 100% clear. To test my
understanding, I think that what this setting really means is something
like "Adjust the size of other fonts to match the apparent size of your
preferred fonts". Am I getting warm?
> > 9. I'm also not 100% clear on what "reset to defaults" means.
> > Does it mean to reset the value of the "'Medium' text size"
> > field, PPI value, etc., to some set of "factory-specified"
> > values built into the browser?
>
> Factory settings, yes.
OK, then I believe that this should be a control separate from the other
sections and applying to all of them. Its implied meaning to the naive
user is something like "Reset all these preferences to the original
default values".
Thanks for your responses to my comments and, again, thanks much for
working up this "strawman" UI.
Todd Fahrner
<hec...@netscape.com> wrote:
> * Minor nit: The control to set the default size for "medium" text
> should probably be a combobox rather than a simple input field, so the
> user can easily select 10, 12, 14, 18, etc., as choices, while still
> being able to enter an arbitrary point size.
You know, it might be desirable simply to cut the "ppi" knot in one stroke
by offering the "font size" choice not as a point size, but as a pixel size.
Unlike points, pixels don't suffer from arbitrarily variable XP rendering
semantics. And make the XP default 16 pixels (=12pt on Windows). This was in
fact my first approach to the problem. Pixels generally offer more granular
control than points anyway.
But I remember now why I modified this approach: it doesn't address the
problem of Web pages that specify text size in points (which is an extremely
regrettable though commmon practice). By letting users get at the assumed
resolution directly, they can recover from the damage of point-speced type
quite powerfully.
> .... That to me says that this sample text should probably be in a
> separate display-only section of the dialog box, headed "Text Preview"
> or something similar.
Agreed.
> * In your example the text in the sample for "medium", "small", etc.,
> presumably would be displayed in the serif font chosen as the default
> font for the serif font category, for the reason you mentioned re
> variability of font appearance at different point sizes. However this
> same argument also applies to the other font categories: sans-serif,
> monospace, etc. So I would argue that the text preview area I proposed
> above should also contain samples of text in the default fonts for those
> categories as well.
That's a lot of fontage. I envisioned, instead, that the current sample
would show whatever the currently selected "default" choice is. But I agree
that that's another one of those confusing "double duty" cases.
> But if you do that and at the same time retain samples for bold text,
> italic/oblique, bold italic, etc., then that makes for a lot of text
> samples at a given size. The number of combinations should probably be
> reduced to a manageable number, but I can't presume to say exactly what
> that number should be.
It's a biggish number. There's always scrolling, but that's sort of beside
the point of a "live preview".
>> These aren't very distinct from one another. When the user sees
>> this in the preview, the user might choose to select a larger
>> "medium" size, for better articulation of the smaller sizes, and
>> have a better Web experience.
>
> OK as far as it goes, but I'm beginning to lose you here, especially
> considering the next topic of "ppi". (To foreshadow my comments below,
> your argument here would lead me to conclude that you're advocating that
> the browser built-in setting for "Default size for to use for
> 'medium'-size text" should actually be, say, 14 points for the Mac
> instead of 12 as it would be for Windows. But I don't think that's
> really what you're saying, correct?)
The end result of my proposal would be similar to what you describe in many,
but not all cases.
Leaving the default size at "12pt" (as it has been from time immemorial),
but also defaulting to 96ppi logical resolution XP will give you the same
result as if you were to ship Windows with a 12pt default, Mac with a 16pt
default, and X - I don't know what. The real meaning of a point size, from a
usability POV at today's common display environments, depends on the nominal
underlying ppi. When it's the same XP, points mean something usefully
consistent. When it's not, they don't.
>> The user would see the effect of adjusting this in the text preview
>> area, and in fact the given 96- and 72-ppi choices would
>> effectively toggle between "Windows-size fonts" and "Mac-size
>> fonts". Mac users would discover that many currently illegible
>> corners of the Web become legible with "Windows-size" fonts.
>
> Understood; a couple of comments then:
>
> * To a naive user it seems like what you're saying is something like
> "You can use the 'standard' way to size text assumed by your system, or
> you can make it be sized like it would on Windows, in which case it may
> be more readable." So maybe this would work better in the main dialog
> box as a simple checkbox with brief explanation, leaving the discussion
> of PPI and the more complex settings to an "Advanced" dialog box.
I fear that might be over-naive, however. While Windows currently defaults
to 96ppi, users may change this setting between boots, making "Windows size"
a bit of a fib. For instance, when a Windows user chooses "Large fonts" from
a control panel, the nominal resolution changes to 120 ppi.
So it's always least misleading to deal with the numbers directly.
> Here's a (very) crude example of what I mean:
>
> Many authors design documents so that the text is most legible
> when viewed on a particular operating system, such as Windows
>
> +-+
> |X| Scale fonts to appear sized as they would display on Windows
> +-+
>
> And (blasphemy coming up...) wouldn't it make sense for this to be
> checked by default? Not to mention, not have this control at all on
> Windows, where it's presumably not needed?
See above - it's not really this simple. But yes, make the "factory
settings" such that Web pages - unstyled, or styled with point units -
rasterize consistently XP.
> That seems another argument for keeping all discussion of resolution,
> screen sizes, PPI, etc., in an "Advanced" dialog box.
Fine by me. The initial values are the main thing.
>> > 7. As a naive user I have no idea what a "pixel object scaling
>> > threshold" is. If there isn't any way to explain this or
>> > illustrate it, then I'd either get rid of the concept or hide
>> > it in an "advanced" dialog.
>>
>> Fine. I hope the other explanations accumulating around this
>> thread address the question.
>
> Not quite yet, but I'll reread your discussion and see if I can restate
> it in naive user terms.
Briefly restated:
I think there need to be two kinds of top-level "size adjustment" UI. One of
them affects only type sizes - much like Navigator or IE's affordances
today. The other is a true "zoom/magnify with reflow" feature, as in the
Opera browser. I propose having both functions accessible through one
general "scale" UI element. So when Joe User clicks it a few times, the
fonts get bigger. But after a certain number of steps, the whole page gets
magnified - graphics too. The point at which this occurs is the pixel
scaling threshold. A modifier key could temporarily override the current
scaling threshold.
>> http://www.w3.org/TR/REC-CSS2/fonts.html#propdef-font-size-adjust
>
> That helps somewhat, though I'm still not 100% clear. To test my
> understanding, I think that what this setting really means is something
> like "Adjust the size of other fonts to match the apparent size of your
> preferred fonts". Am I getting warm?
Smokin'.
> Thanks for your responses to my comments and, again, thanks much for
> working up this "strawman" UI.
Thanks for your feedback!
Frank Hecker
> You know, it might be desirable simply to cut the "ppi" knot in
> one stroke by offering the "font size" choice not as a point size,
> but as a pixel size. Unlike points, pixels don't suffer from
> arbitrarily variable XP rendering semantics. And make the XP
> default 16 pixels (=12pt on Windows). This was in fact my first
> approach to the problem. Pixels generally offer more granular
> control than points anyway.
>
> But I remember now why I modified this approach: it doesn't
> address the problem of Web pages that specify text size in points
> (which is an extremely regrettable though commmon practice). By
> letting users get at the assumed resolution directly, they can
> recover from the damage of point-speced type quite powerfully.
I thought of another possible issue as well: If I changed the "Default
size of 'medium'-size text" setting from (say) 12 points to 14 points,
and the document I'm viewing is using "medium", "small", etc.,
consistently, and not using absolute point sizes, then shouldn't that
setting also affect the size of text in the document as printed? (In
other words, this would be the desired behavior, right? Example: I want
to print out a large-print version suitable for people with impaired
vision.) If so, then presumably I want to specify the "default size of
'medium'-size text" in points rather than pixels, because "size in
points" is a reasonably well-defined notion for printed text, whereas
size in pixels would get confusing when we're talking about printed text
(e.g., 300dpi printer vs. 600dpi printer).
Assuming I'm correct in my supposition above, shouldn't this issue of
"default size of 'medium'-size text" be considered separately from the
issue of what sort of scaling is done for on-screen text to make it more
legible (i.e., the ppi problem)? In other words, these settings are
addressing separate problems: the problem of mapping keyword sizes to
actual sizes in points (applicable to printers and any other situation
where point size is a reasonable notion and there is cross-platform
consistency in output) and the problem of mapping point sizes to
on-screen display sizes in pixels (applicable mainly to displays because
of the lack of cross-platform consistency). If so, then presumably
there should be two separate sets of preferences, the first applying to
all possible output devices and the second applying only to the
on-screen display; that is, you'd need to retain both the "default size
of 'medium'-size text" preference as well as whatever ppi-related
preferences we come up with. Am I way off base here?
> Leaving the default size at "12pt" (as it has been from time
> immemorial), but also defaulting to 96ppi logical resolution XP
> will give you the same result as if you were to ship Windows with
> a 12pt default, Mac with a 16pt default, and X - I don't know
> what. The real meaning of a point size, from a usability POV at
> today's common display environments, depends on the nominal
> underlying ppi. When it's the same XP, points mean something
> usefully consistent. When it's not, they don't.
Agreed. My assumption is that point size is a consistent notion XP for
printers, but not for displays.
> > * To a naive user it seems like what you're saying is something
> > like "You can use the 'standard' way to size text assumed by
> > your system, or you can make it be sized like it would on
> > Windows, in which case it may be more readable." So maybe this
> > would work better in the main dialog box as a simple checkbox
<snip>
> I fear that might be over-naive, however. While Windows currently
> defaults to 96ppi, users may change this setting between boots,
> making "Windows size" a bit of a fib. For instance, when a Windows
> user chooses "Large fonts" from a control panel, the nominal
> resolution changes to 120 ppi.
Ah, more complications... So in this case, if you're using Windows and
"Large fonts" is turned on, text specified at "14 points" will display
on-screen at a larger size (i.e., more pixels) than if "Large fonts"
were not turned on (the default case). (Actually it's worse than you
wrote, because the Windows Display control panel allows you to set the
nominal ppi at any arbitrary value, Display -> Settings -> Custom.)
Incidentally, does this also affect text as printed? (I could check
this myself but haven't yet.)
Let me see if I can read the mind of a naive user again, and also keep
the UI XP at the same time. If I'm a naive user on Windows it seems I
have the following possibilities:
W.1. I haven't messed with "Display -> Settings -> Font size", so my
nominal ppi for display of text is still 96ppi. The current (and
probably future) state of the web is such that most text will look OK
(in terms of legibility) on screen, and the browser should be set by
default to maintain that state. In other words, assume 96ppi by default
for display of text by the layout engine, with the naive user not having
to set any preferences in the browser UI.
W.2. I've messed with "Display -> Settings -> Font size", setting it
either to "Large fonts" (120ppi) or to some arbitrary ppi value;
presumably I did this because I found the standard "Small fonts" too
hard to read. My naive assumption is that this change should carry
through all applications, including the browser. In other words, hav
the default ppi setting in the browser match that which I set for
Windows in the Display control panel, assuming this is technically
possible to do. If it's not possible (say, because MS doesn't document
any API to discover this), then allow me to set a "Font size as
displayed" setting in the browser, with choices of "Large fonts", "Small
fonts", and "Custom" like I'm used to seeing in the Display control
panel.
(Actually, if the browser can read the Windows ppi setting and set its
own ppi for the display based on that, then case W.1 reduces to case
W.2.)
W.3. For some reason the user cares about what a particular document or
set of documents would look like on a typical Mac or Unix/X system; for
example, I might be creating personal web pages and want to do a quick
check to gauge whether my pages would be legible for a typical Mac or
Linux user. In this case I'd want to be able to vary the nominal ppi to
something other than the Windows setting from the Display control panel,
and to a naive user the logical choices for alternatives would be
something like "Typical Macintosh display" (i.e., 72ppi) or "Typical
Unix/X display" (i.e., whatever ppi the browser developers have
arbitrarily chosen as "typical" - 100ppi?). If I were a little less
naive I'd learn that ppi can vary on Unix/X displays, and then I'd want
to be able to set the nominal ppi to an arbitrary value; but this could
be in an "Advanced" dialog.
If I'm a naive user on Macintosh I have the following possibilities:
M.1. My system is using the Mac-standard 72ppi when displaying text.
However a lot of text on the web will look too small from my point of
view, because the documents in question are designed for display on
Windows. I'd probably want one of two things to happen:
M.1.a. The browser defaults to 96ppi, so web pages magically look better
without my having to do anything, or...
M.1.b. The browser defaults to the standard 72ppi, so text sizes look
comparable to what they would in other Mac applications. However in
this case I'd still like an easy way to get things "looking like
Windows" vs. "looking like the Mac".
I'm going to go out on a limb and guess that most naive users would
prefer M.1.a to M.1.b. However enough might disagree to warrant
providing an easy way to switch between "typical Mac" and "typical
Windows".
M.2. My Mac is set to something other than 72ppi for display of text. I
presume this is not possible. However if it is, it should be treated
like case W.2 above: Reflect the system ppi setting into the browser as
the default if possible; if not possible, provide a way in the browser
for the user to set the browser settings like the system settings, using
similar UI and terms of reference if possible.
M.3. I care about what documents look like on typical Windows or Unix/X
displays; same example as in W.3, checking out web pages for XP
legibility. I'd probably see the following as the logical alternatives:
"Windows display (small fonts)", "Windows display (large fonts)", and
"Typical Unix/X display", corresponding to 96ppi, 120ppi, and
<whatever>ppi respectively. Again, a more sophisticated user would want
to be able to set ppi to an arbitrary value, but doing it in a separate
dialog box would be OK.
I have no idea what a typical ppi is for Unix/X, nor do I have any idea
how that might be specified and if/how the browser could detect that
value; so I'll confine myself to the following skeletal cases:
U.1. Same as W.1 and M.1: user hasn't fiddled with any settings, but for
display of web text assume 96ppi as a default.
U.2. Not sure how this case plays out for Unix/X; is it more like
Windows (user can change nominal ppi for text display on a system wide
basis, and the browser should use that setting) or Mac (user probably
can't do anything about the nominal ppi at the system level).
U.3. Very similar to M.3: user would want to see at least choices of
"Windows display (small fonts)", "Windows display (large fonts)", and
"Macintosh display" in order to gauge legibility on those platforms.
Notice that in the above discussion I'm making some sort-of-implicit
assumptions:
* If a user wants and needs fonts to be bigger _as a general rule_ (most
likely, because they have problems viewing small type)
then they will probably have arranged for some sort of system
configuration to accomplish that. For example, they set Windows to
"Large fonts", they use 800x600 for their X display instead of 1024x768,
and so on. All other things being equal, the browser should respect the
system-wide ppi setting if possible. (In other words, this particular
preference _in the browser_ is not primarily intended to solve the
problems of this user.) But unfortunately, all other things are not
equal, because...
* The user might have problems with legibility just for web documents,
because they're using Mac or Unix/X and the documents are sized for
Windows. The natural choices then become "respect system settings" or
"make it look like it would on Windows", and which should be the default
is arguable. Thus whatever default is chosen it should be easy to
switch between these two alternatives.
* Naive users have at least some reason to care about what documents
look like on platforms other than their own.
Got to run now, but my brief conclusion: The initial dialog box should
offer something like the following choices (e.g., in a select list):
Scale fonts to appear sized according to
* System settings
* Windows display (small fonts)
* Windows display (large fonts)
* Macintosh display
* Typical Unix/X display
where some of these choices might be suppressed on some platforms.
Other settings (i.e., to an arbitrary ppi) would be done in an
"Advanced" dialog.
Frank Hecker
> The initial dialog box should offer something like the following
> choices (e.g., in a select list):
>
> Scale fonts to appear sized according to
> * System settings
> * Windows display (small fonts)
> * Windows display (large fonts)
> * Macintosh display
> * Typical Unix/X display
>
> where some of these choices might be suppressed on some platforms.
> Other settings (i.e., to an arbitrary ppi) would be done in an
> "Advanced" dialog.
Sigh. I knew I'd get into trouble trying to switch from naive user to
would-be UI designer. I can think of cases where this scheme would not
be very intuitive to the naive user.
Maybe the best way to approach this problem is to
a) Standardize on a Windows-style nominal 96ppi for displaying web
content on all platforms, with a separate ("advanced"?) option on Mac
and Unix to change back to the old (4.5) way of doing things.
(Obviously you wouldn't need this option on Windows.) This ppi setting
would affect only the display, not printing.
b) Implement a separate control to let the user choose the equivalent of
the Windows systems settings "small fonts" (assumed 96 ppi), "large
fonts" (assumed 120ppi), and "custom" (i.e., arbitrary assumed ppi).
Again, this would affect only the display, not printing.
Also, maybe this option is not necessary on Windows, given that the user
can accomplish the exact same thing in the "Display" control panel.
(And not having it on Windows would simplify things, because otherwise
you'd have to consider how the Windows setting and the Mozilla setting
would interact.)
(I haven't got any good ideas on how either of these options should be
worded.)
The underlying principles I'm trying to follow:
1. Keep this whole set of options confined to text as displayed
onscreen, and independent of options that also affect text as printed
(like "default size of 'medium'-size text").
2. Make the shift to a consistent XP nominal ppi for text appearance at
a given "point size", with Windows as the reference platform. Consider
allowing users to switch back to the old behavior on platforms where it
was different in previous releases.
3. Give users a simple way to permanently and consistently make web text
larger as displayed, especially if their system does not allow them to
do that already at the OS level.
4. Allow the sophisticated user to set the nominal ppi to whatever they
want. Incidentally, Windows has an interesting feature in this regard:
the Display -> Settings -> Font Size -> Custom dialog has an on-screen
ruler marked in "inches", and you can manipulate the ppi value by
dragging one end of the ruler to expand or shrink it. By sizing the
ruler so that the length of a "inch" onscreen matches the actual length
of an inch on a physical ruler, you can set the nominal ppi to the value
that gives you true WYSIWYG font sizes as displayed on screen. (For
example, on my laptop this value is 85ppi.)
That's a good place to stop, before I further betray my ignorance of
this whole subject.
Todd Fahrner
<hec...@netscape.com> wrote:
> I thought of another possible issue as well: If I changed the "Default
> size of 'medium'-size text" setting from (say) 12 points to 14 points,
> and the document I'm viewing is using "medium", "small", etc.,
> consistently, and not using absolute point sizes, then shouldn't that
> setting also affect the size of text in the document as printed?
Presumably.
<tangent>
CSS (including user CSS) has media-specific facilities, so the prefs UI
could read/write its values to a user stylesheet for screen, print,
projector, etc. Or "all". Any user familiar with CSS and a text editor could
modify or extend the same rules exposed in the UI. <drool/>
In fact, that's the major subtext of this proposal: the preferences UI that
overlaps CSS's problem space should be conceived as a lightweight user CSS
editor. Otherwise the interaction of user and author CSS with user prefs
will continue to be undefined, and quite probably at loggerheads.
I'm mighty impressed with how Mozilla is leveraging XML, stylesheets, and
DOM in other areas. Would be a pity to have presentation prefs in a
conflicting system. [John McMullen - is this one of those "architecture
issues", or are we still cool?].
</tangent>
> (In
> other words, this would be the desired behavior, right? Example: I want
> to print out a large-print version suitable for people with impaired
> vision.) If so, then presumably I want to specify the "default size of
> 'medium'-size text" in points rather than pixels, because "size in
> points" is a reasonably well-defined notion for printed text, whereas
> size in pixels would get confusing when we're talking about printed text
> (e.g., 300dpi printer vs. 600dpi printer).
Not necessarily. W3C suggested 1/90" as the value of a "reference pixel" in
1996, to provide a consistent basis for scaling when necessary. So to print
"15px" text to a 600dpi printer, you'd be asking the printer to use 100 of
its dots (600/90 x 15 = 100). This works out to 1/6", aka 1 pica, aka 12
points.
Navigator has used a 1/120 virtual pixel in the past, starting in 1997 I
believe. *sigh*
> Assuming I'm correct in my supposition above, shouldn't this issue of
> "default size of 'medium'-size text" be considered separately from the
> issue of what sort of scaling is done for on-screen text to make it more
> legible (i.e., the ppi problem)? In other words, these settings are
> addressing separate problems: the problem of mapping keyword sizes to
> actual sizes in points (applicable to printers and any other situation
> where point size is a reasonable notion and there is cross-platform
> consistency in output) and the problem of mapping point sizes to
> on-screen display sizes in pixels (applicable mainly to displays because
> of the lack of cross-platform consistency). If so, then presumably
> there should be two separate sets of preferences, the first applying to
> all possible output devices and the second applying only to the
> on-screen display; that is, you'd need to retain both the "default size
> of 'medium'-size text" preference as well as whatever ppi-related
> preferences we come up with. Am I way off base here?
Need more time to chew on some of these points. I'm fighting the urge to say
"smells like media-specific blocks in the user stylesheet." But CSS as
specified doesn't provide a means to attach an explicit value to, for
instance, "small". You need some kind of lookup table. Like, for instance:
keywords Hn fontattr rel tag em 72ppi 96ppi
-----------------------------------------------------------
xx-large H1 2.000em 24px 32px
H2 size=7 +4 1.667em 20px 27px
x-large H3 size=6 +3 1.500em 18px 24px
H4 size=5 +2 1.250em 16px 20px
large H5 size=4 +1 big 1.125em 14px 18px
medium H6 size=3 1.000em 12px 16px
small size=2 -1 small 0.916em 11px 14px (fudged)
x-small size=1 -2 0.833em 10px 12px (fudged)
xx-small 0.750em 9px 9px (fudged)
>> The real meaning of a point size, from a usability POV at
>> today's common display environments, depends on the nominal
>> underlying ppi. When it's the same XP, points mean something
>> usefully consistent. When it's not, they don't.
>
> Agreed. My assumption is that point size is a consistent notion XP for
> printers, but not for displays.
At the same time, I take it as given that before Mozilla's present
foundational work must be retired, display technologies will advance to the
point where the line isn't always so clear. In fact, there might be a causal
relationship between these two future events. So I'm wary of short-term
solutions, such as too pervasive a concern for the "naive user's"
intellectual security might encourage.
>> I fear that might be over-naive, however. While Windows currently
>> defaults to 96ppi, users may change this setting between boots,
>> making "Windows size" a bit of a fib. For instance, when a Windows
>> user chooses "Large fonts" from a control panel, the nominal
>> resolution changes to 120 ppi.
>
> Ah, more complications... So in this case, if you're using Windows and
> "Large fonts" is turned on, text specified at "14 points" will display
> on-screen at a larger size (i.e., more pixels) than if "Large fonts"
> were not turned on (the default case). (Actually it's worse than you
> wrote, because the Windows Display control panel allows you to set the
> nominal ppi at any arbitrary value, Display -> Settings -> Custom.)
only some video systems/drivers support this....
> Incidentally, does this also affect text as printed? (I could check
> this myself but haven't yet.)
I don't believe so. It shouldn't. Though it may be used as such, it's not
intended as a general magnification facility; instead, it is ostensibly to
keep point and other physical measures "true WYSIWYG" as the pixel density
of the display varies.
Playing with this feature too much is a great way to bust your average Web
page, btw. For browsing the current mess at grossly atypical scalings
(>150%), a "zoom" approach is more robust than fiddling with logical
resolution.... Again, see the Opera browser's zoom function for a test drive
on "Top 100" sites. Sucks at small factors - nifty at simple whole number
ratios (3/2, 2/1, etc.)
<snip>
> W.3. For some reason the user cares about what a particular document or
> set of documents would look like on a typical Mac or Unix/X system; for
> example, I might be creating personal web pages and want to do a quick
> check to gauge whether my pages would be legible for a typical Mac or
> Linux user.
Not really a good idea - assumes too much. The author/user taking this
approach will almost inevitably optimize for the presumed majority: Windows,
800x600 maximized, and worse. The tragic thing is that such authors - and
their paying clients - have a point, at least as long as said majority can
be assumed to have weak UI concerning fonts, sizes, colors, etc.
If, conversely, Mac/Win/X users can be assumed to possess real user agents,
then CSS kewords like medium, xx-small, 'serif' etc. can be trusted to have
optimum though different meanings everywhere, so there's less need to
second-guess.
> If I'm a naive user on Macintosh I have the following possibilities:
<snip>
> M.1.a. The browser defaults to 96ppi, so web pages magically look better
> without my having to do anything, or...
>
> M.1.b. The browser defaults to the standard 72ppi, so text sizes look
> comparable to what they would in other Mac applications. However in
> this case I'd still like an easy way to get things "looking like
> Windows" vs. "looking like the Mac".
>
> I'm going to go out on a limb and guess that most naive users would
> prefer M.1.a to M.1.b.
I agree.
> However enough might disagree to warrant
> providing an easy way to switch between "typical Mac" and "typical
> Windows".
Sounds like a good way to start a war. Why canonize some dubious notion of
difference between platform camps - the same notion you're simultaneously
trying to make irrelevant - when you can just expose the numbers and, most
importantly - show the results? Maybe even hide the numbers for the "non
advanced" dialogue and just provide a slider that happens to stick at
certain spots....
> M.2. My Mac is set to something other than 72ppi for display of text. I
> presume this is not possible.
Correct. I heard something about this maybe changing in OS X, but that's
future music.
<snip>
> Notice that in the above discussion I'm making some sort-of-implicit
> assumptions:
>
> * If a user wants and needs fonts to be bigger _as a general rule_ (most
> likely, because they have problems viewing small type)
> then they will probably have arranged for some sort of system
> configuration to accomplish that. For example, they set Windows to
> "Large fonts", they use 800x600 for their X display instead of 1024x768,
> and so on. All other things being equal, the browser should respect the
> system-wide ppi setting if possible.
This is tough, but I think I need to disagree. Some old-time religion: the
network is the computer. The browser is the system. The internet is the
platform. Key to softening the blow here is to make certain that the UI to
override the XP-uniform defaults is in every user's face. Button bar real
estate or equiv, with fine, granular control - not just 2-3 jolts. Walk
users through the "friendly version" scale settings as part of building a
profile.
> Got to run now, but my brief conclusion: The initial dialog box should
> offer something like the following choices (e.g., in a select list):
>
> Scale fonts to appear sized according to
> * System settings
> * Windows display (small fonts)
> * Windows display (large fonts)
> * Macintosh display
> * Typical Unix/X display
>
> where some of these choices might be suppressed on some platforms.
> Other settings (i.e., to an arbitrary ppi) would be done in an
> "Advanced" dialog.
How about, for the "lite" version:
Font/page scale:
bigger
* "medium" text sample here
| "small" sample text
<*> "x-small" sample
| "xx-small" sample
*
|
*
|
*
smaller
matis...@netscape.net
> In article <36B75242...@netscape.com> , Frank Hecker
> <hec...@netscape.com> wrote:
>
> > I thought of another possible issue as well: If I changed the "Default
> > size of 'medium'-size text" setting from (say) 12 points to 14 points,
> > and the document I'm viewing is using "medium", "small", etc.,
> > consistently, and not using absolute point sizes, then shouldn't that
> > setting also affect the size of text in the document as printed?
>
> Presumably.
>
> <tangent>
> CSS (including user CSS) has media-specific facilities, so the prefs UI
> could read/write its values to a user stylesheet for screen, print,
> projector, etc. Or "all". Any user familiar with CSS and a text editor could
> modify or extend the same rules exposed in the UI. <drool/>
>
> In fact, that's the major subtext of this proposal: the preferences UI that
> overlaps CSS's problem space should be conceived as a lightweight user CSS
> editor. Otherwise the interaction of user and author CSS with user prefs
> will continue to be undefined, and quite probably at loggerheads.
>
It is not undefined in my mind. User prefs always win out over author css.
But I am also more of a user than a content developer so I might be a bit
biased.
>
> I'm mighty impressed with how Mozilla is leveraging XML, stylesheets, and
> DOM in other areas. Would be a pity to have presentation prefs in a
> conflicting system. [John McMullen - is this one of those "architecture
> issues", or are we still cool?].
> </tangent>
You just about hit the arch. issue on the head. The XPApps team does not
want the preferences (UI) code to know anything about manipulating style
sheets. What we do want is a way to reflect our javascript preferences into
CSS. There was some question in the meetings on how exactly this would work (
ie how would something like always use my colors work I believe was one example
) but thats an implementation detail. There are not that many CSS attributes
that are going to be exposed in the UI ( mainly fonts and colors ). If at some
point in time some one wants to impliment a full scale CSS editor, I don't
think the perferences UI would be the right place for that to live.
I think scaling would be a really cool, low cost feature to add in. I
don't know about the advanced stuff like storing per web site/page settings,
but by just messing with twips and the transform matrix basic scaling should be
a snap to implement but I am by no means a Gecko expert.
--
David Matiskella
Braden N. McDaniel
There's no reason it should be; if this is the case, petition your OS vendor
to improve usability in this regard. Attempting to solve this problem ad hoc
in a particular application is the Wrong Way.
> and affects
>more than the application at hand,
I still don't see why this would be a problem. *Why* would I want to run
just one app in a different resolution?
> and the choices are often few, and dredge
>up issues like refresh rate and color depth
Why do you say this? Many OSes offer dynamic zooming (by changing the
resolution) with a single keystroke). You're trying to address an inadeqacy
in *some* OSes--that is a *platform-specific* problem--with a
*cross-platform* solution!
No... Fix the lacking OS functionality--don't penalize every other platform
by shackling an XP UI with such redundancy.
> and pincushion and so on.
Pincushioning shouldn't have anything to do with resolution, aside from the
fact that one needs to fine tune one's monitor accordingly. This is, IME,
usually handled by controls native to the monitor--not the OS.
>>>I think the XP default should be 96ppi, in concession to the reality that
>>>there are a whole lot of Windows-based authors who don't know the
>> difference
>>>between a point and 1.33333 pixels.
>>
>> Why should there be an XP default??? I don't think author ineptitude is
>> sufficient cause for such a draconian (and probably hopelessly
unenforcible)
>> measure.
>
>There's no such thing as a draconian default, provided there's decent UI to
>override where desired.
I didn't mean that the notion of a default itself was draconian, but the
notion that there should be a decree to the effect that all pertinent
applications on all platforms should use a particular default--in a
situation where many usability issues remain unresolved--is draconian.
>An XP default means that any variance from said default may be assumed to
>result from express user preference. Such variances will command better
>authorial respect for "the user environment".
Why do you think so?
> In contrast, gratuitous,
>non-user driven XP differences and weak, ill-conceived UI concerning fonts,
>sizes and colors encourage presumptuous authoring practices such as <font
>size="-1"> for body copy, terrabytes of spurious GIFtext, and generally
>anemic markup.
I don't see why the naive authors who make such presumptions wouldn't be
expected to similarly ignore user divergence from an "XP default".
>Excesses aside, a desire for XP-consistent rendering is not always a sign
of
>author ineptitude, but often simply an artifact of weak visual design tools
>- almost inevitably pixel-based. Whenever live text and "pixel objects" -
>graphics, table cells, etc. - must maintain a consistent visual
>relationship, the choices are few and grim in HTML. The compromises tend to
>favor the majority audience: Windows users - users with a 96ppi default
>logical resolution and no powerful UI to adjust font size. And the result
is
>that Mac and X11 users are finding it increasingly hard to read on the Web.
But we're dealing with CSS here, which has ems and such--not just HTML.
Fundamentally flawed authoring practices should be exposed, not coddled to
the detriment of the browser UI!
>Of course I hope this will change over the next several years as CSS is
>deployed, but in the meantime there's a messy Web to browse,
Fully accommodating broken content is a measure that is not compatible with
contributing to changing this fact.
> and
>commercially viable browsers to develop. A browser that will let Mac and
X11
>users comfortably read HTML documents saved out of MS Word for Windows at
>"8pt" would be nice. Setting the default logical resolution to 96ppi would
>go a long way toward this.
Fix what's broken. Change WinWord.
>All rendered objects with either a specified or inherent measure in pixels,
>such as raster graphics, presentational HTML bits like table cell widths
and
>borders, etc. Type and other vector objects would simply be redrawn at the
>same factor. Your basic zoom. But I suspect I'm missing something in your
>question. (Not much sleep.)
No, I don't think you missed anything... I just somehow thought there would
be some discrimination going on in the content, when, in fact, you weren't
describing any such thing. I think I understand now.
>> All this sounds too complicated for Joe User to understand.
>
>So is internal combustion.
Internal combustion is simplified to a gas pedal in the Car UI. You have not
described a gas pedal.
> On the one hand you don't trust authors not to
>abuse XP-consistent defaults; on the other, you don't think Joe User can
>deal with a powerful UI.
Wrong. I don't think Joe User can deal with a *complicated* UI. Complicated
!= Powerful.
And furthermore, the author is *expected* to be knowledgable about
authoring! The user is not.
>Finally, Joe User doesn't need to understand all these issues.
Then they don't belong in the UI.
Braden
Todd Fahrner
wrote:
>> In fact, that's the major subtext of this proposal: the preferences UI that
>> overlaps CSS's problem space should be conceived as a lightweight user CSS
>> editor. Otherwise the interaction of user and author CSS with user prefs
>> will continue to be undefined, and quite probably at loggerheads.
>
> It is not undefined in my mind. User prefs always win out over author css.
It helps enormously if your prefs speak the same language as authors. Can't
win an argument until you can commonly fix upon a point of dispute.
> But I am also more of a user than a content developer so I might be a bit
> biased.
You are aware that CSS comprises conflict resolution (cascading) rules
between author and user? And that users do in fact have the final say? But
unless users can express their preferences and requirements in a common
namespace with authors, none of this matters much.
> You just about hit the arch. issue on the head. The XPApps team does not
> want the preferences (UI) code to know anything about manipulating style
> sheets.
It's hard not to feel a little disappointed to hear this, even though I
don't pretend to understand the XPApps team's problem space.
Todd Fahrner
<bra...@shadow.net> wrote:
>>Because changing display resolution is comparatively tedious,
>
> There's no reason it should be; if this is the case, petition your OS vendor
> to improve usability in this regard.
I can convince myself that you're serious, but then I think "but surely
Braden is a more reasonable guy! hm. Perhaps he's really telling me politely
to bang my head against a wall, or jump in a lake."
I'll fire off a letter today and tell you how it turns out in ten years.
It seems to me that application software has been leading the development of
OS's for a long time. When important apps have to work around limitations of
the OS, the OS's change to provide global solutions. Sounds like you'd raise
the system requirements for a good user experience to some very high plateau
of market obscurity, and wait for the masses to beat a path up.
At this point in display history, people don't generally want bigger or
smaller pixels: they just want a pleasing number of them per rendered object
(mostly glyphs).
<snip> more about how convenient it is for users of Xenox-9 to manipulate
their display systems by telepathy <sarcasm/> </snip>
>>An XP default means that any variance from said default may be assumed to
>>result from express user preference. Such variances will command better
>>authorial respect for "the user environment".
>
> Why do you think so?
Faith in the general goodwill of humanity? User intentional
difference=important : OS coincidental difference=*poof*
>>logical resolution and no powerful UI to adjust font size. And the result
> is
>>that Mac and X11 users are finding it increasingly hard to read on the Web.
>
> But we're dealing with CSS here, which has ems and such--not just HTML.
> Fundamentally flawed authoring practices should be exposed, not coddled to
> the detriment of the browser UI!
I think the UI ideas I'm pushing would go quite a long way toward exposing
flawed authoring practices. They would also help users recover from the
existing damage.
>>users comfortably read HTML documents saved out of MS Word for Windows at
>>"8pt" would be nice. Setting the default logical resolution to 96ppi would
>>go a long way toward this.
>
> Fix what's broken. Change WinWord.
I can't, Braden. Can you? Would you propose to enlist all users of Mozilla
into a decade-long hunger strike against seminally flawed Web authoring
paradigms? Hunger strikes just can't last that long.
>>> All this sounds too complicated for Joe User to understand.
>>
>>So is internal combustion.
>
> Internal combustion is simplified to a gas pedal in the Car UI. You have not
> described a gas pedal.
So I'm a sucky UI designer - it's a few hours' work. How about the gas pedal
slider given in my last exchange with Frank H.?
>> On the one hand you don't trust authors not to
>>abuse XP-consistent defaults; on the other, you don't think Joe User can
>>deal with a powerful UI.
>
> Wrong. I don't think Joe User can deal with a *complicated* UI. Complicated
> != Powerful.
I'm all for simpler packaging, so long as the packaged item is no less able
to expose and neutralize the XP differences concerning the legibility of Web
pages.
>>Finally, Joe User doesn't need to understand all these issues.
>
> Then they don't belong in the UI.
I suppose we should can all the protocol helper and file mapping stuff, too
- acronyms are confusing. And the security and the cache settings and
whatever else some significant portion of Joe User might not grok right
away.
Lars Hallberg
What about two combo boxes
on specifing default medium font size in points, affekting printing
and
screen view (Default document font size?).
on specifing default medium font size in pixel, affekting only screen
view (Default screen font size). This value is calculated from the
default document font size and the curent ppi. If this value is
changed
the curent ppi is recalculated.
In this way the user sets print and screen preferenses in terms they are
used to. It also alows the browser to use the OS ide´ of curent ppi as
default and alow the user to overide that if needed whithout him knowing
what ppi is! This change shuld affect all screen rendering of ellement
specifide whit points, in CSS or elsewhare....
If the default document medium size is changed, the default screen
medium
font size shuld probably be recalculated acording to curent ppi.
Sorry for my pore english.
/Lars
Frank Hecker
> What about two combo boxes
>
> on specifing default medium font size in points, affekting
> printing and screen view (Default document font size?).
>
> on specifing default medium font size in pixel, affekting only
> screen view (Default screen font size). This value is calculated
> from the default document font size and the curent ppi. If this
> value is changed the curent ppi is recalculated.
I think I see what you are saying: first specify the point size, and
then separately specify a pixel size, with the two values taken together
then determining a ppi value.
> In this way the user sets print and screen preferenses in terms
> they are used to.
For points, yes; most users know roughly how big 14-point text is, ditto
for 9-point, 24-point, etc. However I'm not sure that they have
intuitive understanding of pixels, and how big a 15-pixel character
would be, for example, vs. a 40-pixel character.
> It also alows the browser to use the OS ide´ of curent ppi as
> default and alow the user to overide that if needed whithout him
> knowing what ppi is!
I agree that most users don't want to know about ppi, and if they were
told about it would not really understand how it works.
That's why I actually like Microsoft's approach to this in Windows
(Display control panel, Settings -> Font Size):
1. Set a standard default ppi (96) that "just happens" (i.e., the user
doesn't know or care).
2. For the casual user, have a system-wide "large fonts" option that
effectively changes the nominal ppi (to 120), but without the user
having to know or care that that's what it does.
3. For more sophisticated users, have a "Custom" dialog to allow "larger
fonts" to be specified using a percentage value (e.g., "font size" is
160% of "normal font size").
4. For truly sophisticated users, have a draggable ruler feature to
allow WYSIWYG matching of on-screen font sizes to real-world dimensions.
Note carefully that nowhere in their interface does Microsoft allow
users (even sophisticated ones) to directly set either ppi or pixels per
character; ppi is reported only as an output value resulting from your
settings, for anyone who cares about it (and some small number of users
will). Given the amount of money Microsoft spends on formal user
testing, I am willing to believe that this approach is the one that will
work best with the vast majority of users.
Lars Hallberg
>
> I think I see what you are saying: first specify the point
> size, and then separately specify a pixel size, with the
> two values taken together then determining a ppi value.
Most often the other way arond: Take the curent effektiv
(by 'dumb' default or OS intelegens) ppi and calculate
the screen size in pixels from the point size. Only if
the user overides the pixelsize the ppi value vill be
recalculated.
> I (Lars) wrote this:
> > In this way the user sets print and screen preferenses
> > in terms they are used to.
>
> For points, yes; most users know roughly how big
> 14-point text is, ditto for 9-point, 24-point, etc.
> However I'm not sure that they have intuitive
> understanding of pixels, and how big a 15-pixel
> character would be, for example, vs. a 40-pixel
> character.
True, but they vill only change this if they are
unhappy about the curent screen fonts. They find a
combibox with the label "medium scren font size" and
a value - say 15, If they want biger fonts they will
change it to say 18 and bee happy. In the process they
have changed the ppi setings and the rendering of
everything discribed in points to ther own preferens.
/Lars
John McMullen
> > You just about hit the arch. issue on the head. The XPApps team does
> > not
> > want the preferences (UI) code to know anything about manipulating
> > style
> > sheets.
>
> It's hard not to feel a little disappointed to hear this, even though I
> don't pretend to understand the XPApps team's problem space.
Preferences are used to control a lot more than appearance of browser
windows. They include information such as email address, whether to close
mail windows on a delete command, where to store the mail directory, etc.
Preferences UI is a UI for talking to the preferences API. The preferences
API is an interface for storage, caching and retrieval of data. Neither the
preferences UI code nor the preferences API should know anything about the
"meaning" of the data it deals with. The preferences UI code displays a
boolean value as a checkbox, and stores the state after the user changes it.
If changing this value is supposed to cause any action, such as a visual
change, to occur elsewhere, then that is done through another mechanism.
Namely, the interested party (eg, the layout code) registers a callback
function in order to be notified that the value has changed. The interested
party is the one that knows about the "meaning", and must do the work.
Therefore, the preferences architecture does not know, does not need to
know, and should not know or take any specific action other than storing the
changed value and notifying interested parties.
--
John R. McMullen
Mathematician, Software Critic
Netscape Communications Corp.
Frank Hecker
> True, but they vill only change this if they are
> unhappy about the curent screen fonts. They find a
> combibox with the label "medium scren font size" and
> a value - say 15, If they want biger fonts they will
> change it to say 18 and bee happy. In the process they
> have changed the ppi setings and the rendering of
> everything discribed in points to ther own preferens.
I agree with your analysis here, except that where you have the user
seeing an initial value of 15 pixels per character, and then setting it
to 18 to have bigger text, I would have the user seeing an initial value
of "100%" and then setting that to "120%" to get bigger text.
I think the two approaches are really equivalent "beneath the surface",
but expressing it in percentages in the UI is much easier for the
typical user than expressing it in the UI as pixels per character. This
is the approach Microsoft has taken in the Display control panel, as I
previously mentioned, and I believe it makes more sense.
Todd Fahrner
<hec...@netscape.com> wrote:
> Lars Hallberg wrote re pixels per character:
>> True, but they vill only change this if they are
>> unhappy about the curent screen fonts. They find a
>> combibox with the label "medium scren font size" and
>> a value - say 15, If they want biger fonts they will
>> change it to say 18 and bee happy. In the process they
>> have changed the ppi setings and the rendering of
>> everything discribed in points to ther own preferens.
>
> I agree with your analysis here, except that where you have the user
> seeing an initial value of 15 pixels per character, and then setting it
> to 18 to have bigger text, I would have the user seeing an initial value
> of "100%" and then setting that to "120%" to get bigger text.
Percentages imply relativity to some base value. If the base value is also
expressed as a percentage (100%), confusion ensues.
I have proposed that there be, in addition to a preference panel, some sort
of persistent, "one-click" UI to make page, site, or session-specific scale
adjustments. I believe that the best unit system for this top-level
affordance is percentage, especially if it would become a zoom function
beyond a certain threshold of deviance from the initial value.
Consider: if the preference panel lets a user set the initial font size,
ppi, or other relevant parameters to "125%" of "100%", what should the
initial state of the top-level affordance be? 100%? or 125%? And how many
ways could you argue the correct meaning of either expression?
So I feel strongly that the initial value, captured in a prefs panel, should
be some nonrelative expression: pixels, points, milliradians of visual
angle, etc. Or even just an anonymous number representing some more complex
set of parameters.
MS may indeed invest a lot in user testing. While I certainly have issues
with Internet Explorer's font-size UI, I do appreciate that they've got this
duality going between the prefs dialogue font size choices:
smallest
small
medium
large
largest
...and the choices exposed in the persistent "font button" in the toolbar:
smallest
smaller
medium
larger
largest
Note that the first set's got "small" and "large" (absolute keywords), while
the second has "smaller" and "larger" (relative). Again, I have problems
with some things - these terms are too subtle, ambiguous, and few - but in
the fundamental relationship between absolute and relative terms I think
IE's UI is right on.
I would start with a similar balance between absolute and relative terms,
but add more granular and wide-ranging choices:
The prefs dialogue, to define the value of "medium" in, say, pixels:
20
18
16 < XP factory setting
14
12
__ other
...and the "local override" persistent UI choices:
200%
150% < pixel scaling above this point; font size changes alone below
112%
100%
91%
83%
75%
__ more...
Braden N. McDaniel
>In article <7990ul$6t...@secnews.netscape.com> , "Braden N. McDaniel"
><bra...@shadow.net> wrote:
>
>>>Because changing display resolution is comparatively tedious,
>>
>> There's no reason it should be; if this is the case, petition your OS
vendor
>> to improve usability in this regard.
>
>Braden is a more reasonable guy! hm. Perhaps he's really telling me
politely
>to bang my head against a wall, or jump in a lake."
My point is that you're proposing a cross-platform solution to a
platform-specific problem. That is not good design.
>At this point in display history, people don't generally want bigger or
>smaller pixels: they just want a pleasing number of them per rendered
object
>(mostly glyphs).
>
><snip> more about how convenient it is for users of Xenox-9 to manipulate
>their display systems by telepathy <sarcasm/> </snip>
>
>>>An XP default means that any variance from said default may be assumed to
>>>result from express user preference. Such variances will command better
>>>authorial respect for "the user environment".
>>
>> Why do you think so?
>
>Faith in the general goodwill of humanity?
Well, you know how the road to hell is paved. But intentions are irrelevant:
we're talking about raw, unadulterated incompetence.
> User intentional
>difference=important : OS coincidental difference=*poof*
Doesn't make a difference now; I don't see any reason to expect that authors
will be any more courteous in the future. Have you tried using a user style
sheet lately? Noting the number of pages that come up severely botched for
often
undiscernible reasons is amusing at first, but gets old rather quickly.
>>>logical resolution and no powerful UI to adjust font size. And the result
>> is
>>>that Mac and X11 users are finding it increasingly hard to read on the
Web.
>>
>> But we're dealing with CSS here, which has ems and such--not just HTML.
>> Fundamentally flawed authoring practices should be exposed, not coddled
to
>> the detriment of the browser UI!
>
>I think the UI ideas I'm pushing would go quite a long way toward exposing
>flawed authoring practices.
Why? It looks to me like the functionality under this UI is designed to
coexist with author incompetence. Authors won't improve if they don't have
to.
>> Fix what's broken. Change WinWord.
>
>I can't, Braden. Can you?
Not directly. But I think we can foster an environment on the Web that would
encourage Word and applications with similar shortcomings to do a better
job.
> Would you propose to enlist all users of Mozilla
>into a decade-long hunger strike against seminally flawed Web authoring
>paradigms? Hunger strikes just can't last that long.
I'm inclined to think that the Mozilla community has more effective means at
its disposal for fostering an environment that discourages bad authoring
practices.
>>>> All this sounds too complicated for Joe User to understand.
>>>
>>>So is internal combustion.
>>
>> Internal combustion is simplified to a gas pedal in the Car UI. You have
not
>> described a gas pedal.
>
>So I'm a sucky UI designer - it's a few hours' work. How about the gas
pedal
>slider given in my last exchange with Frank H.?
I suppose, but I still don't see any good reason to expose ppi equivalencies
in the browser UI. And I think doing so is going to be confusing for users
unaccustomed to the CSS rules for pixel scaling, no matter how it is
presented.
CSS1 recommends a reference pixel size, and that in a context with a
significantly different pixel size, content should be scaled accordingly.
Why not just follow this rule?
>>>Finally, Joe User doesn't need to understand all these issues.
>>
>> Then they don't belong in the UI.
>
>I suppose we should can all the protocol helper and file mapping stuff, too
>- acronyms are confusing. And the security and the cache settings and
>whatever else some significant portion of Joe User might not grok right
>away.
These things do not require a Web page authoring or computer programming
background to understand.
Braden
Todd Fahrner
<bra...@shadow.net> wrote:
> My point is that you're proposing a cross-platform solution to a
> platform-specific problem. That is not good design.
What do you see as the platform-specific (Mac?) problem? That the OS can't
adjust its logical ppi to match the physical ppi of the display?
Suppose that an OS/UA really could sense the physical dimensions of the
display. Suppose it could even get at the state of the analog controls.
Suppose, for the sake of argument, that each of the pixels happened to be
exactly 1/6" square (like the display in Times Square). 6ppi. And suppose
that the user of said system sets his/her preferred font size to 12pt. Or is
using a Mosaic-derivative browser, where this is the XP default. Or said
user merely encounters a Web page in which fonts are specified as 12pt.
You know how tall the letters must be, in order to be accurate? 1 frigging
pixel high, that's how tall.
Similarly, it is not necessarily the case that a Mac, with its fixed 72ppi
logical resolution, renders point or other physical measures "inaccurately".
Rather, it renders them in fewer pixels relative to, say, what 99% of
Windows users' see: 96ppi.
So I assert that correctly matching a display system's physical
resolution with its logical resolution is of vastly overestimated importance
here. It's a red herring. It (almost) doesn't matter how big or small one's
pixels are: what matters is that there are enough of them per glyph to
assure legibility, or something of the aesthetic character desired by
author/user. Generally speaking, the more, the better: often literal
inaccuracy is precisely what is needed.
In short, the problem with asking the OS to synch up the physical ppi with
the logical ppi is that there's a risk of accuracy. UIs that solicit
adjustments to the logical resolution (such as some Windows boxen) using a
ruler metaphor are similarly ill-conceived, IMO.
That is why, in my proposal, I expose to the user the logical ppi rather
than ask the system to figure it out. The user should be encouraged to pick
some inaccurate value if that's what legibility requires.
Lars' "combi-box" solution seems to me a novel way to accomplish the same
thing.
* * *
I think the "pure", author-driven solution to the problem is *never to
specify size in point/pica/inch/cm in either author or user CSS* for the
screen media type. Nor, IMO, should a UA's UI solicit the desired font size
from a user in point units. (We currently suffer XP under a near-universal
12pt default, whether this is made explicit in UI or not). CSS1 nearly says
as much, though it requires some conceptual unpacking:
Absolute length units are only useful when the physical properties of
the output medium are known.
At one point I tried to get physical measures such as points declared
invalid for the screen media type in CSS-2. The suggestion was dismissed
immediately. Naive users and their toolmakers have no plans to abandon the
notion that toads come in knots, larks come in exaltations, and fonts come
in points (see the current, typical thread in
comp.infosystems.www.authoring.stylesheets, "All I want is 8pt arial!"). I
am beginning to accept this. Call me defeatist.
* * *
So if points are here to stay, even for the screen media type, it is
necessary to provide the user with compensatory mechanisms - the tools
necessary to cause points to render "inaccurately" with minimal upset to
dependencies. I think these are letting the user pick the ppi (with a
default near the "reference" res of 90ppi: 96ppi) - and a general zoom
function when said ppi varies more than n% from 90ppi.
So I am not proposing cross-platform solution to a platform-specific
problem. Intead, I am proposing an XP solution to the global problem that
most people believe and will continue to believe that fonts are measured in
points, that this unit of measure is appropriate regardless of the pixel
density of the rendering medium.
>>>>An XP default means that any variance from said default may be assumed to
>>>>result from express user preference. Such variances will command better
>>>>authorial respect for "the user environment".
>>>
>>> Why do you think so?
>>
>>Faith in the general goodwill of humanity?
>
> Well, you know how the road to hell is paved. But intentions are irrelevant:
> we're talking about raw, unadulterated incompetence.
There's no helping that. So give the user the power to recover. The
prominent presence of such remedies (arbitrarily variable ppi, zoom) will
have an instructive effect on some authors, at least.
>> User intentional
>>difference=important : OS coincidental difference=*poof*
>
> Doesn't make a difference now; I don't see any reason to expect that authors
> will be any more courteous in the future. Have you tried using a user style
> sheet lately? Noting the number of pages that come up severely botched for
> often
> undiscernible reasons is amusing at first, but gets old rather quickly.
This is a tangent to an already over-long thread. Some other time.
>>I think the UI ideas I'm pushing would go quite a long way toward exposing
>>flawed authoring practices.
>
> Why? It looks to me like the functionality under this UI is designed to
> coexist with author incompetence. Authors won't improve if they don't have
> to.
The XP deployment of variable ppi and zooming UI will send stronger hints to
authors on all platforms that Newtonian WYSIWYG just ain't to be had on the
Web. Sounds to me like you would prefer the message to come to clueless
authors through the continued vocal frustration of powerless users. That's
not good for users, because it won't work, neither short-term nor long.
You're right, Braden: there will always be clueless authors. So route around
the damage.
> I suppose, but I still don't see any good reason to expose ppi equivalencies
> in the browser UI.
See above.
> And I think doing so is going to be confusing for users
> unaccustomed to the CSS rules for pixel scaling, no matter how it is
> presented.
I don't buy it. Surface the novice-accessible bits, bury the rest in
"advanced" areas. It is better to have a somewhat challenging UI that solves
a very real, very hard problem than an easy blunt instrument that misses the
real issues.
> CSS1 recommends a reference pixel size, and that in a context with a
> significantly different pixel size, content should be scaled accordingly.
> Why not just follow this rule?
That's part of the solution - the pixel scaling threshold/zooming function.
It's not sufficient.
>>>>Finally, Joe User doesn't need to understand all these issues.
>>>
>>> Then they don't belong in the UI.
>>
>>I suppose we should can all the protocol helper and file mapping stuff, too
>>- acronyms are confusing. And the security and the cache settings and
>>whatever else some significant portion of Joe User might not grok right
>>away.
>
> These things do not require a Web page authoring or computer programming
> background to understand.
I believe that as more and more information is shared globally by electronic
textual means, an understanding of electronic textual display issues becomes
more and more fundamental a part of literacy. The UI of a user agent for the
WWW should foster, not impede such understanding.
15-20 years ago, as "WYSIWYG" word processing and desktop publishing started
to become popular phenomena, many people were confronted for the first time
with such things as "font menus" and "point sizes". For a time,
typewriter-centric concepts like "10-pitch" and "double spacing" and
"carriage return" coexisted uneasily with the new concepts, usually to the
detriment of effective usability. As UIs evolved, so did user understanding.
Now, just as "10 pitch" is beginning to sound quaint to us, we are
challenged to deal with yet another typographic paradigm and its essential
vocabulary - that of the Web page. Point units and other print concepts such
as page numbers are no longer so pertinent. In fact they are often hurtful.
And this time, the division between author and user responsibility for the
final rendering(s) is interleaved. The user must engage the
author/designer's vocabulary in order to have the least helplessly
submissive experience - to interact. It needn't happen all at once, but it
must begin. CSS keywords, unit systems, font families - even the box model:
I believe these are destined to enter popular consciousness over the next
several years, starting now.
Todd Fahrner
Thanks, John. I think I understand. It's not that you have narrow ideas
about what kinds of choices and values the UI should handle - it's that you
don't perceive it as your team's problem to respond to/process to the
collected data in any sophisticated way. Sounds like a reasonable position.
So if not you - who? Layout? Does layout disagree?
I will try to formulate what I see as architectural requirements for a
CSS-centric UI concerning presentation. Will post URL when ready. Though I
probably have a quirky understanding of "architecture". As a Web
enthusiast/developer/designer rather than a source-savvy engineer, my
meaningless stream of booleans is likely to require postprocessing for
naivete.
Todd Fahrner
> I think scaling would be a really cool, low cost feature to add in. I
> don't know about the advanced stuff like storing per web site/page settings,
> but by just messing with twips and the transform matrix basic scaling should
be
> a snap to implement but I am by no means a Gecko expert.
Note also that unlike the really cool, hard stuff like XML, CSS, DOM et al.,
this feature could enhance the presentation of legacy content. Doesn't
require a progressive-minded author to make a nice demo. Again, Opera's
implementation seems right on to me - I'd apply the sincerest form of
flattery.
Todd Fahrner
> I will try to formulate what I see as architectural requirements for a
> CSS-centric UI concerning presentation. Will post URL when ready.
followup: I've sketched this out in my 25 February post to the n.p.m.layout
thread "The browser style sheet: who needs it?" Ascii art and everything.