Universal Screen Unit
Universal Screen Unit(I know I wrote about this somewhere else on WikiWiki, but couldn't refind it.)
In writing HMTL output, or any GUI design, I find it difficult to specify a sizing unit that is universal and lasting. Often "pixel" is used in practice, but I suspect that actual addressable monitor pixels will keep increasing over time such that relying on "pixel" will make stuff shrink too small. In MooresLaw-style, by rough estimation, pixels per screen width double approximately once every 5 years.
Text will just grow larger relative to pixel and addressable monitor resolution will be so small aliasing problems will become less of any issue. Aliasing problems, and related blurring, have been the biggest stumbling block against abandoning pixel-matching fonts. Addressable monitor resolution is getting near the threshold where aliasing and blurring are no longer bottlenecks.
Thus, we need something more "stable" than "pixel".
On a smaller scale, "points" is often used because it's based on the display of fonts, whose size should stay the same over the time because its limited by human eyes, not technology.
However, points don't work well on a larger scale since they are designed with typography in mind. For example, HTML tables.
Percent of screen is one possibility, but screens are also growing larger and/or longer, and are sometimes set up to wrap to a second screen.
After thinking pondering this for a while, I've come up with a possible solution. I call it "Normal Paragraph Width" (NPW). This is the size of a "friendly" paragraph. It corresponds to roughly 10 to 15 average words long and is based on the concept that readability is considered maximized around this size. Publication experts sometimes talk about this width limit also. Short paragraphs and long paragraphs are both hard on the eyes for extended reading time.
Thus, NPW is based on human WetWare, not so much on technology, and thus will generally be stable, outside of technology change.
--top
Isn't "Normal Paragraph Width" entirely dependent on font size? Or is it meant to be dependent on font size?
It would depend on the user's setting for a "normal" font for them.
Why is "Normal Paragraph Width" abbreviated "NPI"?
fixed.
You say points don't work well on a larger scale, which is true, but there are picas. A pica is 12 points.
I've tried that, they were inconsistent across browsers. Plus, it's an absolute unit according to Wikipedia. (See below.)
We also have handy, pre-existing units like millimetres, centimetres, decimetres, metres, inches, feet, etc.
But those are absolute coordinates. One cannot tell what actual size a given screen will render something. That info is not available to web servers. And somebody with good eyes may use a smaller font than somebody with poor eyes. We want the unit relative to the reader's useful unit.
Ah! It's a relative unit! I didn't realise that. The top section doesn't make clear that it's a relative unit.
The idea was to state the problem, not necessarily the solution, up front. In my initial analysis, the solution seems to be a relative unit, but I'm not excluding the possibility that an absolute one may also do the job.
This does not serve a useful function for non-text display - how does one define a border line in NPW units? A gradient of color?
"Percent of screen is one possibility, but screens are also growing larger and/or longer, and are sometimes set up to wrap to a second screen."
Percent of screen is obviously unusable. What's wrong with percentage of browser window? Which, of course, we have now. Presumably, if the browser is set up to wrap to a second screen, it's that way because that's how the user wants it.
Then on a smaller device, such as a netbook or iPhone, you'd get very squishy proportions. And, resizing one's browser between different sites that follow the standard and ones that don't could be a pain.
That's why portable and handheld devices typically provide a virtual screen, larger than the physical screen, into which the browser can be expanded. I don't know what standard you're referring to.
Browsers understand ems, which are font-size relative. An 'ideal line length' of about 30em (give or take 5) should give something in the area of NPW.
I've had problems with em's in the past when I went about testing the HTML/CSS list of units while seeking a reliable standard. Perhaps newer browsers fixed those since. I'll report back if I find any again.
I've been designing web sites and web applications for the last decade (as of Jun 2010) using em spacing nearly exclusively. Works pretty well on all the browsers I have used for testing.
Do you also use them for vertical spacing? That's where I remember the most problems.
The following doesn't work in IE 7:
<table width="30em"><!-- ... -->It interprets it as pixels. It works if one uses CSS instead, but CSS is often too verbose and indirect in my opinion. But it does show that "em" is otherwise a 2nd-class citizen.
Visual Studio also told me that "em" wasn't an accepted unit for certain CSS elements per stated standard. I'll supply the message text the next time I encounter it.
Printer Analogy
Somebody in a blog I happened upon made an interesting analogy to printers. The pixel size of printed pages has shrank to sub-eye levels in some cases, yet monitors have yet to go on a similar shrinking curve even roughly resembling MooresLaw. We wouldn't need technologies such as MS's Clear-Type if (addressable) pixels approached printer-levels because at that size the eye can't see aliasing stair-stepping on letters. We've been stuck at around 1500 to 2500 monitor pixel width for almost a decade. Perhaps it's because OS's and apps have yet to switch to vector graphics and there's no "vendor race" ad campaign to spark it.
True vector graphics would mean a return to CRTs, which is not going to happen for a number of reasons. In general, displays become significantly more expensive as the pixel size decreases and/or pixel count increases. I have a phone with a 640x480 display that delivers approximately 200dpi, but obtaining a 19" display at 300dpi -- to approach even cheap laser printer resolution -- would be prohibitively expensive for most consumers.
That's partly my point: there has not been much of a price reduction for quite a while. I suspect it's because there has yet to be a demand, not that sales pressure wouldn't reduce the cost. I should point out that physical pixel and addressable pixel don't have to be the same. Even printers from a few years back may say something like "600dpi actual resolution and 1200dpi virtual resolution". It would simply average or round for the target size for the actual printout, sometimes using tricky algorithms to avoid aliasing artifacts if it only had black-and-white. But for gray scale the averaging should be easier.
There is a demand for very high resolution, primarily for medical imaging, commercial art & graphics, and probably (eyes roll) porn. Manufacturing costs are still very high, particularly because of the technical difficulties involved in producing large, high resolution displays without an unacceptable number of flaws. Note the price on this beastie: http://www.bhphotovideo.com/c/product/516906-REG/Toshiba_P56QHD_4_P56QHD_4_56_Ultra_High_Definition.html
Essentially MS chose to focus on font clarity, and altered the shape of fonts to better fit the actual screen "grid" closer, while Apple chose to be "true to the font", resulting in slighter blurrier, but be truer to the actual appearance and shape of the font, and be more consistent ("consistently-blurry" one might say) rather than mixed clean-and-blur that MS ended up with.
http://www.joelonsoftware.com/items/2007/06/12.html
[Note that monitor prices have dropped like a brick over the last two years; Tiger Direct has an Acer 27" LCD that goes 2048 by 1152. Price? Four and a half bones. Can't beat that with a stick.]
Maybe "the curve" is starting to kick in. It would be interesting to see a price-per-addressable-pixel plot over the years. But there's also the issue of existing software being able to use the resolution in a way that's consistent across apps.
[Hmm. Is addressable pixels really something that we want our applications worrying about? Shouldn't they instead be concerned with mapping vectors and triangles and such things? Like, the system tells the application what is the smallest triangle that can be mapped to the screen and the app cuts off rendering below that level? Something like that.]
I use the term as a reference resolution, not necessarily as a goal. That being said, it would be nice to have the option of addressing screen pixels directly for apps or drivers that need to be CloseToTheMetal.
The Image Bottleneck
One problem with relying on non-pixel units is that it can result in blurry graphics. If you size based on say em's, then you also have to size graphics based on em's if you want proportional scaling of all items. However, this means that the graphic pixels and screen pixels don't "line up".
Older browsers did "truncation" interpolation (nearest pixel), which resulted in "blocky" graphics. Newer versions use linear interpolation (average the neighbors' values based on closeness), which improves the situation (assuming users bother to upgrade their browsers) but still results in blurring. Pixel-based images in general simply look better if they match hardware pixels. Now perhaps in the future when screens approach printer resolutions, it will grow into an insignificant problem as the width of "blur problem" shrinks below the visible or noticeable level. But graphics and layout designers have to focus on the here and now. The blurrier your images appear, the lower your product is graded.
See: TheProblemWithIcons
EditText of this page
(last edited January 27, 2011)
or FindPage with title or text search