While tinkering with my Blogger blog’s template, and consulting with the experts online regarding the latest webpage design standards, I began to wonder myself how adaptable my designs were. At times, I’m looking at my handiwork stretched to fill these 16:9 or 16:10 monitors and am satisfied it takes advantage of all that space. However, then I remember back to my 4:3 CRT monitors and how I was able to design to best utilize its space. So whatever was designed for 4:3 in mind now looks constrained for 16:9 because of the extra space on the sides. So what is the right way to design?

Before everyone was a web design expert and could learn HTML over the weekend, the web’s authors were throwing out words like “scalability” and “usability” and “user-friendly”. Then the designers stepped in and found all sorts of problems with the source code, having to manage all the kinks and incompatibility of browsers and developed workarounds or “hacks” just to get their visions up. Soon, it was about functionality, uniformity across browsers, or plain-out sticking strictly to standards. Designers had to become programmers themselves in order to keep their jobs and that possibly killed some of the creativity (and maybe fun of it all).

Designing distinctive elements despite limits in technology

Even back in the days of DOS, the designers still organized their applications in a way that data was modular enough to differentiate between static elements (menus, indexes, legends, etc.) and dynamic elements (fetched data, text, images, etc.) Sure, it’s all static in the end when it’s rendered to the screen, but what’s important is keeping aware of the distinction between elements. As a designer, you don’t want to design something new for EVERY element that you encounter. If you didn’t have access to templates or a scripting language as efficient as PHP, you’d have to design each HTML file separately. And copy-and-paste can lead to disasters.

So depending on the technology you’re working with and what it allows you as a designer to do, you might be stuck with its limitations. You’re goal is to make it as usable and accessible as possible. It can’t just be a wall of text (unless that was the intent of the design). Text itself is a graphic and could be used just as objectively as a picture or color or shape or whatever.

Before nice horizontal rules or div borders, coders found a way to draw a line separating comments and headers from actual code by using the equal sign:


/*
==========================================================================
A Program That Does Stuff
Description: This program does something
Copyright (c) 1993 Eastfist Software
==========================================================================
*/

function Main() {
print "This is a made-up or hodgepodge of languages, don't shoot the messenger.";
}


You can start to see object-oriented organization even back then. It is still interpreted line by line, but as a human being, you can tell distinctly that denoting it with an implied line it becomes a section of its own.

Of course, more advanced applications back then could draw real lines but the design aspect was still limited for designers. Menus still looked like menus, although the only indication that a menu was selected was to invert the background and foreground colors. Otherwise, menus looked like a string of text, no underlines (for the most part), no highlighting, no mouseovers. But it was distinct because it was either docked on the top or bottom of the screen.

The menus stretched across horizontally and any item’s text that were too long was truncated due to limitation of character count, and if you were lucky the menus would wrap to the next row if it surpassed the screen width.

Ultimately, a menu is distinctive because it is static and doesn’t change. If a user were to get lost in the wall of information or content, the menu would be in the same place. As a designer, the menu should be the easiest part to design because you do it once and it should carry throughout the rest of the template.

Modular designing was pretty hip recently for the past 10 to 15 years. Designers were slicing things up and using tables to hold their “organic” stuff together. It was a mess. Then cascading stylesheets were exposed (as they seemed to have always existed but not for public access) and modular designing wasn’t championed anymore (although it is still quite modular internally). The reason modular design wasn’t appealing was because designers felt like they were constrained to designing for a box (which, technically, they can’t escape as that is the nature of it all). But that’s not to say modular design isn’t efficient. Modular design is actually the easiest way to create distinction between elements. It looks incredibly segregated, but that’s where designers have to work their magic and make it look less like a grid but still retain distinction amongst elements.

Scalability

Because technology advances at such a fast rate, if you’re not taking advantage of the latest design technologies, you might find your webpages looking outdated or incompatible. Now with HTML5 and CSS3 trying to fix all the confusion, designers hopefully won’t have to rely on hacks as much. The technology opens up the design possibilities with more resolution, higher bandwidth, better coding, etc. If modular design felt constrictive, fixed-width and fixed-sized fonts definitely do.

These ultra high-resolution devices now make your fixed-sized fonts look like Braille! Yikes!

So what can designers do to adapt quickly? Gone were the days of newsprint on paper where you must stick to fixed sizes. A computer screen may be limited to it’s technical dimensions, but the virtual screen isn’t. If the cpu could handle it, I’m sure someone could mock-up an infinite wall of text to test it. You could get a bigger monitor (and they do get HUGE) or you’d be scrolling forever. You want it to look as nice as possible for whatever screen size you’re working with. Therefore, you need to make your elements proportional and fixed-size elements aren’t going to transition well. If you really want to stay ahead of the game, you’re going to have to start setting fonts at percentages of their actual size. Either that, or start using relative sizes like “small” or “large” or “xxx-large”.

The problem with this is that sometimes you want the text to match the graphics. If you intended it to change every time the resolution changed, the text would have need to be able to transform by wrapping around elements or doing all sorts of gymnastics without getting cut off somewhere or not rendering.

I’ve found that modern Internet browsers already have a very competent solution. It’s not the “zooming” in of text that’s important, but rather the zooming in of the entire page. I’m assuming text-zooming was implemented because there won’t be any pixelation as text are vector graphics. Adobe’s Portable Document Format (PDF) seem to be more successful at keeping the layouts the way they are while zooming in. Eventually, the HTML standard will fix all the bugs enough so that on clientside, the browsers will render the pages correctly. I’m not saying PDF is that friendly, but at the least, that’s how HTML documents should scale.

Images are another problem when scaled. Unless designers implement asynchronous data transfers, users will only download one size image and rescaling will be at the mercy of the browser size. The quality of that rescaling is up to the rescaler algorithm, but even then, the results will probably be unappealing. Site owners might also not like to store multiple copies of the same image at different sizes on their host server as it will eat up inodes and we know how some webhosts are about their inodes.

Ideally, I envision web browsers like a video game emulator. The emulator isn’t recreating any of the elements. It’s just rescaling the entire video single frame buffer, which at 30 frames a second is highly efficient. It’s not doing any more calculations than it should. Those recalculations are probably the cause of layout distortion. Also, what is the likelihood modern consumer’s computers don’t have decent graphics processors (even on-board ones) that can’t handle this kind of processing? Computer monitors have shown the modern world so much beautiful color and resolution with such ease than it did not even a year ago. Have you seen those iPhones? Holy cow!

Maybe there needs to be a combination of rescaling and optical character recognition (OCR) technology on clientside browsers. Computers seem to be fast enough these days. Designers can paint an image without worrying about it getting sliced up like a checkerboard and losing the pattern.

Ironically, I’m sure browsers already render pages that way. The performance and efficiency is there. What designers want is aesthetics.

Bare essentials first

When all fails layoutwise, as a designer, I was taught to always be able to fallback on the pure data. If your browser doesn’t support Javascript or stylesheets, it still shouldn’t deter the user from getting the information they were looking for whether it be text or images. Granted, it’s not that pretty, but with a little effort, designers should still have well-formed paragraphs, modular organization, and distinctive elements even though it may be a sprawling white page with tiny black text.