Getting It Right

Web sites don't have to load slowly, look like they came out of a can, rely on code that is browser-specific (or worse, inoperable), and show little or no forethought for the convenience and needs of visitors. Instead, a web site can provide an online presence that gives credibility to your content and purpose. And the information that is there can be available to everyone, without requiring plug-ins, javascript or active-x. I design pages toward delivering information quickly in a visually pleasing display, and I author them with reliable code that can be expected to deliver content in new browser releases. This page explains some of my design considerations and opinions.

Speed

Web pages need to load quickly. Most people are still using telephone modems, so it is through that type of connection that download times must be considered. The general informed consensus seems to be that you've got about eight seconds to get the attention of your internet audience or they'll move on to another site, with dissenting views from two seconds to forty seconds. The heart of the matter is this: be quick or be clicked away. An opening home page that relies on large image files (or many small ones) may take too long to deliver sufficient content to keep your audience online. Multimedia files, such as Flash, sound and movie files, also court the mouse-click of death. And using such files for navigation nearly guarantees turning away about ten per cent of your web site traffic. Many people will not install or use Flash, and many will browse the web with javascript disabled.

Pictures make web sites more interesting and can lend credibility to a site. Just be sure that they support the information of the page, and that the image file sizes are manageable. If you want to display large pictures, it's best to use the thumbnail approach (as done with the photo galleries on this site). The supportive content will load quickly, and people who want to see the larger image can make the decision to download it and wait. What looks snappy and loads fast from a hard drive may be a slow trip through cold mollasses via telephone modem.

HTML and CSS code (the instructions that tell web browsers what to display and how) also make a difference in presentation speed. Software programs that create web pages tend to write code that is bloated and inefficient (I think Adobe Image Ready is among the worst in that regard), though they do generally get the job done. And at least one of those programs creates web pages with quite large image files for background images. In comparison, the blue background of The Light Preserve is about 3kb - very manageable.

Design

Text aligned with graphics

Background Overlays

It might as well look good. Now that most web browsers in use support CSS, we're seeing much nicer displays of information on the web. We're not seeing sophisticated magazine layout schemes, but it's better than the clunky stuff we were stuck with just a few years ago. Furthermore, we can create classier pages with minimal overhead in file sizes and download times. I use my knowledge of CSS and background in graphic arts to create page designs that complement the content.

One important element of web page design is site navigation. We need to be able to get to the content we're after. Some designs make it difficult to learn what the content is! (Search Google for "web pages that suck" sometime. Really.) Some preachers of navigation dogma would have us adhere to some kind of world standard for navigation schemes and link colors for immediate recognition. I agree that navigation should be clear and accessible, but I also have confidence that people are clever enough to recognize different designs. Make it a system that clearly identifies where the links will take us and we'll get along fine.

And then there's the issue of incorporating javascript and/or Microsoft's Active-X into web site design. Because of the numerous and well-documented privacy and security issues with these two scripting languages, many people disable them. (See editorial for documentation and information.) What does that mean for your web site? It means don't rely on such scripting for navigation. HTML code will get the job done without locking out your audience. Similarly, don't rely on "plug-ins" for navigation, either. Visitors without the plug-in aren't likely to install it just to see your web site; they're going to leave.

Now consider the search engines: Google, Yahoo, and others. They don't interpret javascript. They don't interpret Flash. They don't interpret images. They interpret text and HTML code. For a web site to get indexed by the search engines, it must be accessible to them. Some search engines, perhaps all of them, evaluate the frequency and density of key words in the HTML document as part of the criteria for indexing and ranking. By moving format and style information to a CSS file, key words become more significant within the HTML document.

The overall design should provide quick recognition of where to find the desired information. Navigation is part of that, but the layout should also be neat and clean without too much content on one page. Avoid, especially, unrelated content on the same page. Content should be broken into separate pages in the manner of chapters of a textbook. If there's considerable content, site design frequently benefits by separating content further or providing intra-page navigation (as done on this page). Organize content and navigation in a simple and intuitive manner so that visitors will quickly find what they want and not click away to another site with a simpler "floor plan."

Text should be readable, and generally of consistent font. Use a different font to call attention to links or special information, but don't use multiple fonts just because you can. Make the fonts big enough to be easily legible - many people don't know how to change font size on their web browser, and some don't know that they can change the size. The background (color and images) can affect legibility.

Decide whether page rendering is to be dynamic or static. Dynamic pages will expand and contract to fit various sizes of browser windows. The Google News page is dynamic; many of the news links are not. The down side of dynamic layout is that the "perfect balance" of elements gets juggled about as the window size changes from the design mock-up size. Generally, though, a good layout remains functional, attractive and easy to navigate. Coding can get fussy, however. Static designs are simpler to code and guarantee a fixed visual presentation, but be sure that the size will fit the typical browser windows of your visitors. If it's too wide, they'll have to scroll left and right to see content, and possibly for each line of text (a real good way to elicit the "geez, I'm outta here" response). The Light Preserve uses dynamic page design.

The Mess We Call "The Web"

The most amazing thing about the web is not what it does or what we can find there, but that it works at all. Except for connection and data transfer protocols, the sophisticated network we call "The Web" has been a mess at the user end. Different web browsers (Netscape, Microsoft, Mozilla, et al) have not only been in competition for market share, but also for code implementations and interpretations. For this reason, a page from a web site will not look the same on different browsers and different operating systems. Some browsers won't respond to or even recognize code words that other browsers render favorably. The Netscape-Explorer battle brought many new HTML code words to the web, but the Netscape code was interpreted only by Netscape, and new code words from Microsoft were interpreted only by Microsoft browsers. Sound messy? Yeah - it's like every railroad company having its own track width (which, at one time, was the case). Well, railroad companies have figured out that cooperation can benefit everyone. I'm not convinced that all browser companies have been so clever.

Over two decades into a functional internet, and we still don't have total standardization. Smaller companies do what they can to keep up, sometimes with truly laudable results. Bigger companies appear to have ignored the issue, hoping to set standards by default through market share. It hasn't worked.

So, what do we have? Well, like I said, the internet works. We don't all see the same thing when we log on to a site, but we usually get the information. To display that information identically across different browsers and operating systems requires much more effort than it should. There are dozens of hacks and tricks to accomplish this - and every new browser release chokes on some of the tricks and requires new ones. Who cares? Developers and the people who pay them care. Time and money goes into working around the bugs and idiosyncracies of different browsers. Then, the next generation of browsers comes along and the process starts anew.

I don't play that game. Rather than treat the symptoms, I believe that the smart approach is to address the problem. The solution is Standardized Code. That is the most reliable code of today and of the future.

Code Standards

The move by W3C (World Wide Web Consortium) is toward standardized code and separating content from style. HTML defines the content and CSS control hows it's displayed. Already, current web browsers support and correctly interpret most CSS code. Further, browser-specific proprietary code is fading from the scene in favor of standard code words and their interpretation. That encourages everyone to use the same code, which leads to standardized appearance across browsers and platforms. Eventually, maybe we really will get to the point where web pages look the same in FireFox on a Windows box as MSIE on a Mac.

That's the good news. The bad news is that although we're much closer than a few years ago, we're not there yet. Different browsers still render web pages differently, and it's not always practically possible to author pages that look exactly the same everywhere. Even with standardized code, there are quirks among browsers that cause the page display to differ among them. Browsers don't yet universally support all code elements and, in some cases, interpret elements differently.

And there lies the two primary drawbacks to software-generated code: it is often browser-specific and may use non-standard HTML tags (keywords of HTML instructions). You've probably seen the disclaimers: "This site looks best with FunkyToad 5." It still works, but might render less than elegant to awful or incompletely in browsers other than "FunkyToad." (And please don't ask about web authoring programs from Microsoft. Cough.) These issues of coding will become more important if MSIE loses its overwhelming position on the 'net, and continued reports of security vulnerabilities with MSIE may change its current level of dominance.

I write HTML and CSS code in a text editor. I've learned this code, and having done so I can more fully control how content is displayed. I'm able to write specific code that assists web browsers in rendering pages quickly and accurately. By writing the code myself, I can also avoid code tags that are only recognized by specific browsers, and I also avoid tags that have been deprecated (marked to be unsupported in the future). This improves the likelihood that my pages will render properly in future browser releases. That's Durability of Code.

I generally write "strict" code, and that mode is declared in the DOCTYPE information of my HTML pages. Strict requires standardized, error-free coding to meet W3C standards, i.e., to "validate." A validated, strict web page enjoys the benefit of what I call "Durability of Code." It is code that can be expected to render well in future browsers, because it meets standards defined for the future. As browsers become more demanding of correct code (which they must, if we are to have true standardization and compatibility), they will fail to execute the sloppy code that passes for web authoring today. Validated strict code is the best assurance that a web site will be servicable for many years.

Consider, again, the search engines. They must interpret the HTML code to determine what the site content is about. If there are improper tags, syntax errors or other invalid elements, the search robots may incorrectly assign index topic and placement. Code that validates is correct code, and that is what the search engines are designed to interpret. This doesn't mean that validating code will put your site at the top of the rankings, but it does mean that code with errors may have negative effects on index placement.

Some pages on other sites that I have authored will not validate. When I deliver or put a web site online, the HTML and CSS code validate. Completely. Some site owners "go it alone" after the initial template and code structure is in place. Sometimes they screw it up, and I hear from them when the site fails to render correctly.

Usefulness

Well, this is where it all comes out in the wash. Is the web site useful? If the pages load quickly and visitors stay to see an attractive design - and can find the content they're looking for via an intuitive navigation system - then the design side of the battle is largely won. Code that is written with future browser standards in mind can provide viable sources of information for the next generation of browser implementations.

I invite you to read About the Preserve to get an inside look at specific considerations for this site. If you're considering a web presence, or want to improve a site you already have, please contact me via the e-mail address below.