[thelist] Higher Screen Resolutions

Barney Carroll barney.carroll at gmail.com
Fri May 21 05:32:16 CDT 2010


@Felix

We're getting into the notion of abstract sizes now, which is interesting
and controversial ground :)

I have personally stopped using ems for quite some time now, based on the
notion that a) in practical terms, ems are a shorthand for a given
pixel-based width and b) I don't personally believe a significant enough
proportion of IE6 users expect to alter page zoom with the mousewheel. In
short I think they're a bit of a false dichotomy — I still almost
exclusively use multiples of 12px to define my layouts (by and wide the base
font-size people try to establish for the em), but I specify them in pixels.
For one, my bitmap images can't be defined in ems, and also when dealing
with block level bordered elements I would rather have, say 1px border with
11px padding, than .8333em border and .1667em padding (1px, not 0 or 2).

There is the notion that pixels are too abstract a measurement of space. I
would say that this is false — everything else is abstract and pixels are
the only thing we have to work with. The user may end up magnifying that in
their browser setting, which is their own affair, but eventually all I have
to go on is the relativity of those initial pixel values. As far as actual
metric screen real-estate, computer monitors are by and wide at either 96 or
120 pixels per inch. Which of the two it is is, again, the user's affair —
their OS chrome will usually have text sized at 12 or 13 pixels regardless,
their screen will be somewhere in the vicinity of 25 inches away from their
eyes, but in all honesty I have no determinable clues as to how I should
best interpret or even deal with actual perceived size then the pixel. The
myriad possible user preferences in HCI are practically determined on their
end. There may be a niche of users out there who enjoy flicking their gaze
over 15 inches on a regular basis to interpret the page or application in
front of them, but I've certainly not heard about them and am definitely not
going to give up the established comfort zone of established wisdom for
their sake. For most sites, I will be trying to approximate what most people
feel comfortable and are familiar with — something emulating an A4 (~US
letter) width and scale; 'coffee table book' sites — highly stylised,
media-rich experiences which are meant to be sensual and immersive in their
own terms rather than quickly and easily legible and digestible for the sake
of achieving tasks or retrieving information — or again, as in Hassan's
example, applications designed specifically to represent very specific,
non-malleable data forms — may dictate their own arbitrary conditions; but
by and wide that won't be the case and some sense of proportion is still
necessary. This is why books come generally in given sizes, even if they
contain extra large print or braille — people don't want massive interfaces.
In a scenario where project-defined considerations aren't glaringly
unavoidable, I think the status quo of established readable width abides.

There is the issue that mobile devices are nowadays packing incredibly high
pixel-per-inch ratios — for instance the latest HTC phones have 252ppi (more
than twice normal desktop resolution) — at which point you have to
reconsider your pixel scaling. This doesn't mean you're better off with ems
or percentages, because ems are still going to be defined based on pixels
and percentages can't cope with disparity (my 20%-60%-20% 3 column grid that
looks acceptable on PC isn't going to look too great packed into something
just over 2inches wide). So in the situations I'm running into the issue
that 480 pixels would possibly allow a two-column layout on my desktop, but
that's not viable for smartphones. At this point, I have to cater
specifically for the new form factor and conduct some form of UA sniffing.
But this is the exception — and even then (especially so) I am in no way
more comfortable dealing with ems, and certainly not any happier dealing
with 1024px+ layouts ;)

Regards,
Barney Carroll

barney.carroll at gmail.com
07594 506 381


On 21 May 2010 10:42, Felix Miata <mrmazda at earthlink.net> wrote:

> On 2010/05/21 10:05 (GMT+0100) Barney Carroll composed:
>
> > People don't get screens
> > that wide so that applications can fill the whole thing, they do it for
> > having several applications show at once.
>
> Yes, and no. Many have no comprehension that resolution exists, and only
> care
> what a "bigger" screen can offer. There are two primary things a bigger
> screen can offer:
>
> 1-space for more things to fit
>
> 2-bigger things
>
> Some want the first, some want the second, and some want some combination
> of
> both. By limiting size to some arbitrary width defined in px, you defeat
> the
> purpose of most or all of those wanting the second who don't know about
> resolution, and some of those wanting the second who do comprehend
> resolution.
>
> > When you get bigger than 1020px,
> > you get to the point where the eye has to move to be able to take in the
> > whole thing.
>
> For some that's true, for others false. To be correct, one must say
>
>        when you get bigger than X wide, you get to the point...
>
> The meaning of X depends on the physical size of each px, and on distance
> between eyes and display, and on the viewer's comfortable field of view. If
> that value is Y wide at a distance of Z, then the better answer would be a
> function of how many characters fit in the Y space, typically somewhere in
> the vicinity of 60em to 90em, regardless of Z, however many px are required
> to achieve it. Limiting width to Xem instead of Xpx that's exactly the
> result, regardless of resolution or screen size.
> --
> "The wise are known for their understanding, and pleasant
> words are persuasive." Proverbs 16:21 (New Living Translation)
>
>  Team OS/2 ** Reg. Linux User #211409
>
> Felix Miata  ***  http://fm.no-ip.com/
> --
>
> * * Please support the community that supports you.  * *
> http://evolt.org/help_support_evolt/
>
> For unsubscribe and other options, including the Tip Harvester
> and archives of thelist go to: http://lists.evolt.org
> Workers of the Web, evolt !
>


More information about the thelist mailing list