 | |||
 | | | |
WEB DESIGN TIP ARCHIVE Currently, there are only 6 tips in this archive, due to the fact that I began writing the tips in May 2002. As the tips grow, I will organize them on multiple pages, as well as add a search function on the main page. If you have any comments or constructive criticism on these web design tips, please feel free to email me. | |
| |
October 2002 Tip: Slicing Graphics For the longest time, I couldn't clearly see why leading software developers like Adobe and Macromedia so heavily promote their design tools' "slicing" capabilities until I discovered that there is a general misconception in the web design world that "graphic slicing equals speed." Except for the extreme case of using a single humongous graphic as the sole source of web page content, a good design rule of thumb to remember is "a fewer number of graphic items on a web page results faster loading times, both in reality and in perceptibility." Graphic slicing, therefore, should be used sparingly. In one of my past web designs, I sought to describe and compare the functional benefits of a few security products by displaying several icon graphics on my pages that represented individual product features. I could have combined the entire block of icons into a single graphic, since this would have made the pages download faster. However, I wanted to offer popup "TITLE" descriptions above each icon, such that the viewer could read a convenient text description of what each picture stood for when their arrow pointer moved over the individual icon graphics. With dozens of tiny graphic files (or slices) on the page though, the server has more work to do and the overall loading speed within the browser declines, both in reality and in perceptibility by the viewer. I nevertheless sacrificed loading speed for slicing, thinking it would be better to provide more information to the viewer via the TITLE attribute of the <IMG> tag. But this decision resulted in much longer page loading times, even for my web visitors with broadband connections. I later modified my sliced icon design into a single graphic that contained all my icons, which greatly improved loading speed. I then provided a link to another web page that explained the meaning of each icon. Advice on web graphic optimization. To improve your visitor's "perception" of web page loading speed, turn on "interlacing" for medium to large GIF images and activate "progressive loading" for most JPEGs. Also, don't forget to add "ALT" text for each graphic. ALT text vital for providing information to the visually impaired who cannot see the graphics, but it also provides some viewable content in the browser to maintain the attention of web visitors while graphics are loading. Also, don't use a single large graphic as the only content for a web page -- slicing certainly would be a better option than that. But it would be best to rethink the layout of your web page, scaling down the size and number of graphics as well as adding more HTML text content to speed loading. Unless you absolutely need to put TITLE and/or ALT text on multiple sections of a given graphic, I strongly recommend against the practice of slicing. Taking time to properly optimize web graphics and adding more HTML text will result in accelerated download times, bringing additional return visitors to your site. | |
| |
 | ||
| | |
September 2002 Tip: Font Choices When constructing your web sites, one of the most crucial design decisions centers around your choice of fonts. Virtually all web sites have text on them in one of three forms: (a) classic HTML text, (b) CSS text and (c) graphic text. CSS stands for Cascading Style Sheets. CSS offers you tighter control over typographical styling in the browser, such as fixed point sizes and spacing between characters. CSS is compatible with version 4 and higher browsers from Netscape and Microsoft; but CSS is also viewable in many alternative browsers that have appeared in the last several years. Graphic text is just that--text that is "rasterized" or pixilated into a non-editable graphic image. Using graphic text ensures that your web visitors see precisely what you intended for them to see font-wise. But of course, because graphic text cannot be selected, copied or indexed into web search engines, it is best to limit use of such on your web pages. Our focus today is therefore on editable HTML text, illustrating how to make prudent choices with fonts and sizes. The first point of consideration is that non-styled HTML text will default to the viewer's browser preference settings. This may not be desirable if you wish to have a unique look-and-feel to your site. If for example you want to have your web visitors see all your body text in Times, but you did not specify the Times font in your HTML design, it is very likely that Helvetica or another font will appear in the viewer's browser instead. Thus the use of the <font face="x,y,z"> tag in HTML, where x, y, and z stand for specific font names you wish use for a single sentence, a paragraph or an entire body of text on a given web page. You are allowed put a single font name in the <font> tag (e.g., just the "x" without the "y" and "z"), but it is wise to also add similar looking fonts to ensure greater cross platform compatibility. What this means is that someone's Windows PC may not have the "Geneva" typeface that you wish to design with on your Macintosh. Even if you want to use Mac specific (or Windows specific) fonts in order to cater to that group of viewers, it is still wise to add a couple other similar looking typefaces into the tag to ensure someone without that font doesn't receive an ugly mess of text splattered across their browser screen. If you don't know how or don't have the desire to manipulate the font face tags manually, you would do well to consider a web page layout software application, such as SoftPress Systems' Freeway for the Macintosh or one of dozens available on the Windows platform. So what fonts are best to use in HTML text? Helvetica, Times, Courier and Verdana tend to work seamlessly across Mac and Windows platforms, assuming your visitors are running English or other "1-byte" browsers. Asian "2-byte" browsers vary wildly; but on the whole, if your font point size selection is large enough, your web text should be legible in 2-byte browsers. Consider keeping your English font point sizes to 10pt and higher for the best looking display in most Chinese and Japanese browsers. What about font sizes? Windows browsers render fonts just over 30% larger than Mac browsers do, and UNIX browsers display font sizes somewhere in between that. So if you are designing on the Mac, be careful when creating very large HTML text since such will appear quite huge on other platforms. This is important because your web page layout may shift undesirably if the font becomes too large. You can easily test this though by previewing your web pages in a browser, such as MSIE, and then choosing a "Text Zoom" in the browser of 120% or 150%. Also note that you cannot specify specific point sizes in classic HTML--you can only do so in CSS. In classic HTML, you specify font sizes in a manner relative to the default browser font size--such as +1, +2, or -1, -2, larger or smaller than the default browser size. For additional tips and information on web typography, visit wpdfd.com. | |
| |
| ||
| | |
August 2002 Tip: The "robots.txt" file Before explaining how to write "robots.txt" files for your web site, it is important to define what an internet "robot" is. In general terms, a robot is a computer software program designed to automatically traverse the web and gather information from web sites. Although there are several types of web robots, the most common type is the "indexing" robot, deployed by many internet search engines. If such a robot discovers your web site, it will automatically log (i.e., "spider") information throughout your site into its database. While it is important to list your web site content in as many search engines as possible, there are times when you may wish portions of your site to be blocked from indexing. This is where the usefulness of the "robots.txt" file comes in. Robots.txt files are used to limit robot access to information in a web site. Most search engine robots that discover your web site will scan the root directory of your webspace to see if there is a "robots.txt" file. (In other words, the file should be found at: http://www.yoursitename.com/robots.txt.) If robots.txt is found in your web domain root directory, visiting robots will scan the contents of the file to see what limitations are imposed on their information gathering. Writing robots.txt files. Even though writing robots.txt files is very easy, it is important that you take care to structure the file contents and filename correctly. First off, the file must be saved as plain text, not HTML. Next, the file name should be all lower case, spelled exactly as "robots.txt" but without the quotes. Example content in a robots.txt file that will disallow indexing of two web site directories would be: # Put comments after a "pound" symbol, if you wish to include comments. The asterisk (*) used within the User-agent designator signifies that all robots should obey the commands that follow. Disallow /private will disallow access to the content of any filenames that begin with "private" as well as disallow access to all files within a directory named "private" and also disallow access to any subdirectories under /private. Additional "Disallow" lines must be written for each exclusion you wish to have. In the case of "/family_photos/," only files within that directory and subdirectories under it will be excluded. Putting a slash at the end of family_photos means that any file which happens to begin with "family_photos" and is located within the "personal" directory will not be disallowed. For more information on writing robots.txt files, have a look at this resource and this tutorial. This extensive FAQ on robots is also helpful. And finally, it is important that you verify the syntax of your robots.txt files to ensure there are no mistakes. Here are a couple online checkers that work nicely: UKOLN and WDBC. | |
| |
| ||
| | |
July 2002 Tip: The Truth on Frames When I designed my first company web site, I decided to go with a layout based upon frames. If you don't know already, "frames" allow viewing of multiple HTML pages within the same browser window; and a "frameset" is the container that displays those individual pages in the same window. Anyway, I had read the various do's and don't of incorporating framed web pages, but I decided on a framed site under the somewhat false assumption that my web pages would somehow load faster. My thinking was that I could put all the fixed content, such as a horizontal header and vertical menu bar, into separate frames and then put a compact page of changing content in the central frame. If I clicked a button in the navigation frame, only the content in the central frame changed, giving the appearance of a fast loading page. Another advantage was that no matter how far down the page one scrolled, the header and navigation buttons would always be visible. One of the problems I found though was that the filesize of my main content frame quickly expanded to become just as large if not larger than a non-framed page with the header and menu bar. This is technically not the fault of frames, but rather a psychological design issue--since the header and button bar don't need to be put on every HTML page, the designer has more freedom to add additional content to the central frame pages. But frames pose more serious problems than this. Framed web page content cannot easily be bookmarked. I discovered this problematic area when I began website support. I often needed to point customers to a specific URL on our site; but with frames, only the "frameset" page can be bookmarked. To better understand this problem, imagine that we have a frameset for a section of a website pertaining to "Security Products," and there are a couple dozen individual product pages that can be displayed through the central frame of that frameset. You browse through several pages in that frame until you find one of interest. If you try to bookmark what you see (meaning, the content in the central frame), only the URL of the frameset will be saved, which doesn't contain the content you wanted. Although many browsers allow you to open a new window and display the content of an individual frame, you will most often lose the branding and navigation information that are stored in the fixed frames within the frameset. Offering customers a URL to such a stripped-down page also looks quite tacky too. Printing troubles, lack of support in older browsers, users who disable frames in their browser preferences, problematic search engine indexing and the general web surfer dislike of framed sites are also reasons to consider going with a single HTML page layout approach. Even though you may find beneficial reasons for frames in your site design, its worth a good thinking over to determine if those benefits outweigh the many negatives of frames. | |
| |
| ||
| | |
June 2002 Tip: Web Page Width Considerations I unfortunately come across all too many web pages that force me to scroll HORIZONTALLY to view everything. Last month, I spoke about the problem of webmasters who are designing more and more HTML bloat to fill our ever-widening pipes to the internet. Along those same lines, many web designers mistakenly assume that "the majority of surfers" have very high resolution monitors and therefore they design sites to fill up ever inch of screen space. Although many modern monitors can display 1024 pixels in width, the designer must consider that: (1) not everyone has their screen set to that high resolution and (2) the designer must account for scroll bars, window borders and other onscreen items that take up a significant amount of screen space. A good rule of thumb is to assume that only 75% or less of the pixel width of any given screen will actually be used to view web page content. So, if you are designing under the assumption that most of your web visitors have screens that are 1024 pixels wide, it would be a good idea to set your page width limit to 768 pixels. It may be the case the some of your site viewers have very high resolution screens. And if, for example, your page is 550 pixels wide and left-aligned, your site could appear quite small on some viewer's hi-rez monitors. To rectify this problem without widening your pages excessively, consider center-aligning your pages and/or making them expand to fill the horizontal space as the viewer expands the browser window. The top portion of the web page you're reading right now is an example of a width-can-grow and center-aligned design. Apple.com is a good example of a non-widening, center-aligned design. In any case, you should design your web pages with viewer convenience in mind above all else. This is especially true as our web surfer population ages and adjusts their monitor resolutions down to a larger, more easily readable size. | |
| |
| ||
| | |
May 2002 Tip: Keep Your HTML Filesizes Small Even in this age of high speed cable and DSL services, it is still prudent for web authors to keep individual HTML page sizes to a minimum. It might be accurate to assume that "the majority" or "a growing number" of web surfers in a given geographic area have high bandwidth internet access. But does that mean web designers should upload bloated HTML pages? One good example of "bloat" can be seen in the personal computer sitting on your desk right now. The raw speed of desktop computers has grown exponentially over the last decade, but can anyone truly say their machine runs software "too fast"? Unfortunately, software authors on the whole have grown rather lax in optimizing their ever-expanding code base. Why worry about shrinking the size of the code or optimize it if the CPU can run it "decently" at GigaHertz speeds? Just because a growing majority of web surfer's (including myself) have a fat pipe to the web doesn't mean you, as a web author, must fill that pipe completely. When I first started designing web pages a few years ago, I read a good HTML page size rule-of-thumb: keep the size of individual web pages to 32kb or less, if at all possible. In many cases this is not an easy task. But there is no excuse for a page (especially not a top page) of any web site to become a bloated 250kb or higher. Flash content pages have a tendency to exceed 200kb in size because the creators mistakenly assume that flashing bits and pieces of content on the screen is sufficient to keep the viewer preoccupied while the whole thing loads. Remember that even a "fast connection" to the internet may slow to a crawl during peak usage hours. If you must use Flash, use it sparingly. Compress photographic images as JPEG, 75% compression or greater; and format line art images as GIFs or PNGs, preferably using a 216-color web safe palette to get the absolute smallest size. Keeping your HTML pages tiny will delight analog modem surfers and also thrill high bandwidth viewers, bringing a greater number them back to your site in the future.
END OF TIP ARCHIVE | |
| |