Meanwhille, due to ages of low resolution screens, many Microsoft Windows users were forced into the habit of frequently hitting the infamous maximize window button (sic) in a most obsessive compulsive fashion. These users, great as they are by number, sometimes feel annoyed by gray, white, coloured or patterned margins to the right side of the page design. This is probably what brought centred page layouts into fashion: to spread out the effect to both sides of the screen.
Fluid
The style which probably reflects the look of early 90's page designs most is the fluid page layout. Until the late 90's, fluid page layouts were still wildly popular, because they made the most efficient use of both (s)vga and xga screens. Further increase of resolution (and thus window size: people work full screen) made the designs look ugly, as by increasing the line length, the font size does not increase and the magic relation between x-height and line length is lost. The human eye only has so much tolerance for being able to find the beginning of each next line, after having traveled a screen wide from right to left.
The big breaktrough of content management systems also called for more designs based on a fixed page width. After all, one desires to have some degree of control over the way graphics and advertisments do mix with text on the end user's screen.
These are a few of several good reasons why people switched to static page designs.
The mysterious exception
Let's take a look at the expectation of the grown up web surfer. Is he actually bothered by trivial technicalities such as pixels, page width and screen resolution? Most people whom I know, are not. According to the end user: web pages are pages and pages have a certain width, just like most other kind of pages that people work with.
Think of it: other page handling applications like Microsoft Word or Adobe Acrobat (Reader) all offer the possibility of automatically scaling the page to the width of the window it is drawn in, regardless the physical width of the page itself in either inches, centimeters or pixels. Talking of which, units would become totally irrelevant. Just like in DTP applications. A page width of 21 centimters in Quark express doesn't mean anything for the page view on screen. The application doesn't know, nor care, what the physical dimensions of the users's viewing area are. Pages may be scaled to to window height or window width or every desired zoom percentage.
So why can't web browsers be the same? Admittedly, Opera already offers the possibility of up- or downscaling web pages, but as a fixed setting in percentages. Adding an option for automatic zoom to width of page, plus an adequate scaling algorithm would do the trick and it would turn, the already great Opera browser, into a real killer application. Listen to this Håkon!
Browsers on the Mac OS X platform could use quartz to do the actual work beautifully. Also Microsoft's upcoming Windows Vista will feature some powerful scaling technology, ready to be utilised for useful features such as scaling web pages instead of more eyecandy. That would turn the ugly duckling into a real swan.
Other recent articles:
-
Dealing with Labels by Cornelis G. A. Kolbach — February 1, 2009
Read more...As suggested in the article Form Follows Function and Achieving Thereof, every input element on a form should ideally have a label. Labels give more meaning to input elements and makes them accessible. This article dives into dealing with labels and input fields for postal addresses on forms.
-
Form follows function and achieving thereof by Cornelis G. A. Kolbach — February 1, 2009
Read more...Forms can be dreadfully tricky to style and structure properly. Several articles that are out there focus on best practises for building forms using HTML en CSS. This article focusses in a non technical fashion on the use of meaningful nomenclature and how form semantics relate to elements that current markup standards have to offer. It may help you recognise structural patterns and to compose forms properly.
-
Gregorian date input diversity by Cornelis G. A. Kolbach — February 1, 2009
One of the most common interaction patterns one can find on forms is the date input group. They appear in all shapes and sizes in various applications and sign up forms on websites. Certain forms of appearance seem to be more popular in certain geographical areas than other. But other than that it is hard to find any pattern or rationale why one website has chosen for model X while the other has chosen model Y. The suspicion would rise that the date input method is often dictated by the way the backend would 'like' it. This is a situation which neither we, as interaction designers and consultants, nor the end user should settle for.
Read more... -
AJAX and the Old World by Cornelis G. A. Kolbach — November 19, 2006
Most of us know that HTML was designed in such a way that it would enable one to (single) click on certain underlined words in a text, that would link to another page. Initially, these hyperlinks were the only clickable items on web pages. Soon enough, besides using hyperlinks in an inline fashion, they would be grouped on pages so they would form a menu which would help people to navigate between pages that belonged to a certain group of pages. The web site was born.
Today, complex layout methods have made it possible to borrow from interaction patterns of desktop applications, including drop down menu bars, expanding trees and tabs. It's this exact inevitable shift of desktop application design patterns to the page metaphor that has more than often led to confusion amongst both web designers and end users. In this era of AJAX and RIAs, the possibilities for user interface designers have become infinite. Hence the question arises: Have all of these developments actually led to an improved user experience?
Read more...