On 4/7/09 16:09, Felix Miata wrote:
> On 2009/07/04 10:13 (GMT+0100) Benjamin Hawkes-Lewis composed:
>
>> On 2/7/09 17:07, Felix Miata wrote:
>
>>> Zoom, minimum text size and magnifiers are defense mechanisms. The
>>> basic problem is the pervasive offense - not respecting users'
>>> font size choices by incorporating them at 100% for the bulk of
>>> content. Thus, an even better way to address presbyopia is to design
>>> to make defenses unnecessary in the first place.
>
>> I'm dubious about the rhetoric here:
>
> That you call it rhetoric doesn't make it so.
>
> Too small text is #1 user complaint:
> http://www.useit.com/alertbox/designmistakes.html

That's not quite what the article says. "Bad fonts" was the biggest complaint from Nielsen's readers, but that category includes "frozen font sizes" and "low contrast", not just "small font sizes".

> W3 recommends 100%: http://www.w3.org/QA/Tips/font-size

"Recommends" has a technical sense when it comes to W3C, and this isn't a formal recommendation:

"While the tips are carefully reviewed by the participants of the [Quality Assurance Interest] group, they should not be seen as anything else than informative bits of wisdom, and especially, they are not normative W3C technical specifications."

> As do others, e.g.:
> http://tobyinkster.co.uk/article/web-fonts/
> http://www.xs4all.nl/~sbpoley/webmatters/fontsize.html
> http://informationarchitects.jp/100e2r/?v=4
> http://fm.no-ip.com/auth/bigdefaults.html
> http://www.cameratim.com/personal/soapbox/morons-in-webspace#hard-to-read-fonts

The claims I was trying to question were:

Claim 1: Browser defaults always represent "user choice".

Claim 2: Acceptance of publisher font size suggestions is not a valid "user choice".

Claim 3: Publisher font size suggestions are an "offence" against user choice in some way that typeface and color suggestions are not.

Most of the authorities you cite agree with Claim 1 but none offer any argument for Claims 1 or 2.

Most contradict Claim 3. In Nielsen's survey of his readers, a third complained about poor color contrast. Oliver Reichenstein discusses how bad contrast can reduce legibility, and your own article says "to be legible, text needs enough contrast". Toby Inkster and Stephen Poley both discuss how typeface choice can render text hard-to-read. Tim Seifert's excellent diatribe says "[d]aft colour schemes are a pain" and "[s]etting a page to use particular fonts … can make a page difficult, or impossible to read".

>> * Why should we treat browser default font size settings, which many users
>> seem not to realise that they can change,
>
> Whether individuals know how [snip] is irrelevant

Can you make a choice if you do not realize you have options?

Of the users who do realize they can force font size but choose not to, why assume their choice is to use the default size with all designs rather than supplying a default size when publisher suggestions are absent? Why assume users are always trying to use that browser setting to do something it doesn't claim to do?

> You as designer aren't there, so you can't possibly know that what
> they have isn't acceptable or even perfect, much less improve their
> experience by deviating from the default.

Both users and designers operate from a position of ignorance. Users who adjust their default font size don't know how their adjusted default font size will work with different colors and typefaces; designers know how common default font sizes will work with their suggested colors and typefaces, but not how the user's adjusted size will work. Because of these areas of ignorance, it is possible for designers to happen to suggest a more legible size. (The more users who don't adjust their default font size, the more likely this is.)

> Personal computers are not made by morons, but by humans who have
> preselected defaults designed to make the majority of users happy with
> most things just as they found them, ready to use as received. To
> think that an eagle-eyed web page designer biased by her giant
> tax-deductible worktool display can impose some other size in order to
> make things better for the majority is a preposterous supposition.

I think the default styles used by popular browsers mainly aim at a mix of:

1. Making websites look similar to how they look in other popular browsers.
   2. Making website controls look similar to those in the desktop widgets.

They aren't designed from scratch to maximize usability by themselves or to maintain usability when combined with publisher styles.

Maybe the original design decisions that underpinned these styles were good ones. (I don't buy the notion that default font sizes for body text are too big, at any rate.) It's certainly true that web designers often make bad design decisions, but it doesn't follow that their design decisions are invariably worse than the design decisions behind the basic styles. These styles come as a package. As soon as web designers start suggesting colors and typefaces, the legibility characteristics of the browser default font size change.

>> If users want to force a font size everywhere, they can and that is
>> indisputably a user choice.
>
> Users should not routinely need to force an override,

It would be better if browsers enforced a higher minimum font size by default, but that might break too much existing content.

> Defenses (e.g. forcing via minimum size) characteristically have
> drawbacks, which in these cases typically means overlapping or hidden
> text, and/or inappropriate line lengths, and/or horizontal scrolling.

This would come into the class of "the use of publisher styles that … [p]revent user acceptance of publisher styles with reservations". But in fact this problem is orthogonal to publishers or users setting or not setting font size.

For example, if the user has a narrow viewport, and the publisher suggests a container width in em, the user might have to scroll horizontally to see the whole line.

Or, a publisher might attempt to translate content higher in the page than it is in the source by relatively positioning upwards a given number of em, not realizing that at a different default font size or with a fallback font, the line count of prior content (and thus the number of "em" required) changes, so that the positioned content ends up overlapping other content.

>> * Why should we characterize user acceptance with reservations of
>> publisher styles for the page, the web, or their entire system as a
>> "defensive" measure?

[snip]

> Do you not know that web browsers did not always have minimum size
> or zoom functions? It's true! These features were requested of UA
> suppliers by users, as defensive measures, because web site authors,
> who were given CSS with which to totally disregard visitor preferences
> (px, pt), and more power to shrink the preferences (unlimited em& %
> instead of just size=-2& size=-1), used the power of CSS to transform
> most of the web into imitation magazine pages full of hard to read
> (undersized WRT defaults) text. As long as designers insist that
> defaults are wrong by applying sub-100% sizing to body or primary
> content containers, users will need to battle (defend against) to undo
> designer imposition (offense).

Or, to use different language, browsers improved their featureset for partnering user viewing choices with publisher suggestions.

>> Would you describe publisher typeface and color suggestions as an
>> "offence" against user choice? If no, then why not?

[snip]

> The relatively recent trend of #333 or lighter text on a white or less
> contrasty background is no small problem, but it pales in comparison
> to the basic issue of text size.

I don't think "pales in comparison" is supported by the evidence:

Nielsen (2005, my emphasis):

"I asked readers of my newsletter to nominate the usability problems they found the most irritating. … Bad fonts won the vote by a landslide, getting almost twice as many votes as the #2 mistake. About two-thirds of the voters complained about small font sizes or frozen font sizes; /about one-third complained about low contrast between text and background/."

http://www.useit.com/alertbox/designmistakes.html

> I don't consider typeface such a big deal. There are very few
> universally installed fonts.

Doesn't stop web designers suggesting fonts with a smaller install base, and won't stop them offering them for download.

> Sure they vary in apparent size, but generally as long as those
> selected are used at the user's selected size, reasonable legibility
> is a given.

I asked why you wouldn't "describe publisher typeface and color suggestions as an 'offence' against user choice". I find it difficult to follow your answer, but it seems to be that they more rarely cause illegibility than font size suggestions? If I've got that right, this answer isn't very satisfying. Why is an instance of suggesting font size that does not produce illegibility for a particular user an offence against the user's choice when an instance of suggesting a color or typeface that does produce illegibility is not?

I think "user choice" is a flawed way to frame an argument against the all-too common practice of publishers suggesting tiny font-size values for body text. Once you start down the road of saying a given publisher style suggestion is an offence against user choice, it's hard not to conclude that the only legitimate role for publisher styles would be layout hints for semantics that don't exist in (X)HTML (for example, alignment for table columns with different data types). Publishers and end-users have too much investment in the web as a varied aesthetic experience for that idea to win wide acceptance.

A better way to frame the argument IMO is to say that tiny font-size values are too small for most people to read, so they're a stupid publisher suggestion.

--
Benjamin Hawkes-Lewis


*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
*******************************************************************

Reply via email to