Carrie Sucharski { Bloggin' in MM120 }

Wednesday, February 05, 2003

The Screen Resolution Problem

I used to come across this problem almost every time I looked around the web. I would get to a web site that has a nice design, but I could not see everything without scrolling sideways with the bottom scrollbar in my browser! The reason is that the highest screen resolution my old monitor would support was 640x480 pixels. (It was an old VGA monitor). There are also many other surfers out there who have older monitors or video cards. If you have a large target audience, you will want everyone to be able to read the page easily.

So why are webmasters designing sites for larger screen resolutions (800x600, 1024x768 etc.) when people are clicking away because they cannot read without scrolling two ways? There are a few answers out there to look at: Webmasters who do not realize what they are doing, those who do not care, and those whose target audience would typically have a high screen resolution.

Yes, there are some webmasters who do not realize that their web site does not look the same on every computer. It took me a bit of time to find that out myself, back when I was creating my first homepage. The problem is that you simply cannot see the problem when you only use your own computer with your personal settings. In this case, I can't really blame the webmaster....if I had a nice monitor, I would set a higher resolution as well.

Webmasters who do this knowingly yet do not care are likely to lose a large number of visitors simply because they refuse to use a smaller graphic or table. The presence of a graphic that is over 600-620 pixels wide will almost surely force the user with a low resolution into using the horizontal scrollbar. The problem is really annoying if the viewer is trying to read a paragraph of text and has to scroll every 5 seconds to see the next few words at the beginning or end of a line. Navigation can be irritating as well, because the navigation menus may be partially hidden or in some cases, entirely hidden from the viewer when they first see the page. If they do not realize the scrollbar on the bottom, they may feel the site is not finished or has nothing there to see. Well, if the webmaster does not care.......

If a webmasters target audience would be people with higher screen resolutions, they may design site to be viewed at that resolution. Usually they will make sure the 640x480 viewer can at least see the important information without the need to scroll, but the site is optimized for their target audience. This is not a major problem, since most of the people viewing that site would have the correct equipment and settings.

So, how can you as a webmaster or homepage creator avoid forcing people to scroll from left to right? One way is to simply not use any graphic with a width greater than 600 pixels, and do not define anything such as an <HR> tag or tables to be greater than 600 pixels wide. Also, do not use the <NOBR> tag on any page unless you need to make a point, such as "this line of javascript needs to be all on one line."

Another option is to use tables to enclose the contents of your page. By using tables with a width of 600 pixels or less, you will be sure that almost anyone can view your page as intended. You can center the tables if you wish, but if you are going to use some of the new features of DHTML or Style Sheets you may want to align the table to the left or right side in order to use absolute positioning without any surprises.

Another problem I have been told about is that viewers of your site may resize their viewing window. There is no way to guess what size they might go to, but you can use a table with a width percentage instead of pixels so that the content resizes along with the window. This one is much harder to deal with, especially with a complicated design scheme that requires exact numbers rather than percentages. Do what you can, but if your viewers use 50x50 windows, there just isn't much you can do stop the scroll bars.

This page used to have a centered table with a width of 550 pixels. I only have a few pages where a bottom scrollbar will show up, usually on examples of the <NOBR> tag and in some javascript tutorials. This article uses style sheets or the browser defaults if style sheets are not supported. Otherwise, I use mostly 550 pixel tables, or I use no tables at all and keep the images and horizontal bars small in width. Just remember, if you want everyone to see your site without scrolling, keep your site inside the 600 pixel width barrier. Those who have old monitors or video cards will definitely appreciate it and return to your site in the future.

Handy Hints for Web Designers

Web Designing is as easy as 1-2-3, claim some of the software tools on the market that "generate" your pages for you. Unfortunately, many web designers today have fallen prey to this marketing gimmick - and the results are obvious. Every now and then, one comes across a website that looks good with a particular browser and a particular screen-resolution; but view it with a different browser, and you can't even read the plain text on the page. Worse still, given the number of operating systems that are used by netizens worldwide, these pages will never be seen properly by more than a half of the intended surfers.

Now let's assume that this web page belongs to a site that sells stuff online. The very fact that half the users cannot even see the page, translates into losses worth half the amount straightaway (perhaps, even more!) I guess that makes a good case for the raison d'Ítre of this article! Web Designing is, in my opinion, a cocktail of creative skills & technical prowess ñ and one is no less important than the other.

In the following lines, I have jotted down a few points that I noticed during my online journeys, important from the point of view of web designers. Some of them may be taken with a pinch of salt; for it is not possible to please everyone everytime. But most of them are simple enough to be used as a rule of thumb.

1. A picture, they say, is worth a thousand words. A picture file, alas, is also almost as big. Images, no doubt, enhance the look of a page, but it is not advisable to go overboard in stuffing your page with a truckload of images. Most net-surfers use a dial-up connection, and the average time to load a page should be no longer than 5 seconds. If it's longer, the surfer will most probably click away elsewhere. So, within this time, all the images on a page must be loaded as well. So, as a rough yardstick, keep the aggregate page size less than 30k.
Another important point to note is that each file on the page requires a separate HTTP request to the server. So a lot of small images - even if they do not add up to a lot in terms of bytes - will slow down the loading a lot.
Even when you must use images for navigation, please give a second thought to the users who will not be seeing those jazzy, fantastic & truly amazing buttons that you spent hours to design. Yes, I'm talking of the ALT text attribute of the IMG tag. Do not forget to provide an Alternate Text for each image that you use for navigation. (It may be left blank for certain images that are purely for aesthetic reasons, but let that be an exception, rather than the rule.) Though not obviously apparent, ALT text can help such users immensely.
Modern browsers offer users a choice to turn off images. This gives an idea of how troublesome the unwanted images could be.
A couple of more attributes that make your pages load faster are the HEIGHT and WIDTH attributes. Without these, the browser must wait for the image to download since it cannot know how much space to leave for them!
2. Navigability & functionality come before artistic excellence. It is no use making your site a masterpiece of art if users cannot navigate around it - even after they reach the main page, they have no clue as to how to go where they want to go.
3. Especially common, is a kind of navigation that some people call Mystery Meat Navigation. That means, that unless your mouse moves over an image, you have no idea where that link might take you. Only when the mouse hovers do you see the actual link. This is cumbersome because users need to move their mouse all over the place to find out which part is a link and which is not.
4. Follow the K.I.S.S. principle: Keep it simple, stupid!
5. Next is a very important practical suggestion: whenever your whole page is within a TABLE, the page cannot render (i.e., the page does not show on the screen) unless the entire table is downloaded. You might have noticed this on several websites, when there is no activity for a long time, and suddenly the entire page is visible. Hence, to avoid such a situation, what you should do is this: Split the table up into two tables one below the other, and let the top one be a short table that displays just the page header and a few navigation links. So now, immediately upon downloading this part of the page, users can see the page header ñ and this prepares them for the long wait ahead, as well as keeps them from leaving your site to go to other sites, in case of a slow connection.
6. The ongoing browser wars have left only one casualty ñ the user. As a word of caution, stay away from all browser-specific functions. Because if a certain feature is supported by one browser, it will most definitely not be supported by another. Where you must use such features, it should not hamper the display of the page in the other browser which does not support such functionality. In other words, your page should degrade gracefully.
7. Creating a new browser window should be the authority of the user only. Do not try to popup new windows to clutter the user's screen. All links must open in the same window by default. An exception, however, may be made for pages containing a links list. It is convenient in such cases to open links in another window, so that the user can come back to the links page easily. Even in such cases, it is advisable to give the user a prior note that links would open in a new window.
8. Keep in mind the fonts-challenged users too. The ultra-jazzy "Cloister Black MT Light" font that looks so amazing on your machine may well be degraded into plain old Times New Roman on your user's machine. The reason? He/she does not have the font installed on his/her machine - and one thing's obvious - there's nothing you can do about the situation, sitting halfway across the globe from them.
9. Stay clear of out-of-the-way hard-to-find fonts. Use plain vanilla fonts like Arial, Verdana, Tahoma, and Courier. If need be, make your jazzy fonts into an image and put that on the page. (and while you're there, do not forget Tip #1.)
10. A new design trick that is increasingly being used on the web has caught my fancy: It is a very functional navigation bar that guides you across all possible paths within the site. It looks something like this: Home > Section > Subsection > Page
11. Another new trend on the web is not all that inviting - various vendors come up with "revolutionary plug-ins" and undoubtedly, most amateur web designers jump up to spruce up their pages using them. The reality is that most people won't have them installed, and wouldn't care about it anyway. Come to think of it, have you seen plug-ins on any of the most popular sites, including Yahoo.com, Amazon.com or Google.com? It's simply not the best thing to do. Mention must be made here of Macromedia's Shockwave Flash plug-in, which has now made its way onto most computers today, and thus presents no harm in using vector animation on your site.
12. Java is yet another often-misused technology on webpages. Use Java as a utilitarian programming language, not as a graphics front-end for your photos/images. There are various things you can do with Java; that does not mean you should do all of them. Java applets are known to run slower, so users experience a certain sluggishness in performance. And worse still, Java has been known to crash certain browsers. This is not something everyone likes, especially if it is done for the sole purpose of showing a set of images in a slideshow! The moral: Use it, but with discretion.
13. Never underestimate the importance of those META tags. They can make all the difference between your users coming to your site and going to your competitor's ñ just because they couldn't find yours. Search Engines heavily rely upon the Keywords & Description Meta tags to populate their search database. And once again, use discretion in writing these. Including a huge number of keywords for the same page can spell trouble. The description should be a small, meaningful summary of the whole page that makes sense even when seen out-of-context of the webpage itself, say, in a listing of search engine results.
14. And the final point that summarizes all the points so forth: Write for all browsers, all resolutions, and all color-depths. If you show people pages that look best with their own browser and their own resolution, that makes them feel "at home", and you get a better response. Compare this with a website that proclaims "Viewed best with Browser X at a resolution of 1024x768." I'll give you a choice between two options when you see such a page: download the suggested browser (which might well be over 50 Megs), then go get a new monitor that supports the high-resolution, and then adjust your screen setting so you get the perfect picture. Or simply click away to another site. Which do you prefer?

The web waits for no one. And furthermore, the user is king. Try your best to keep the user happy. And to keep all users happy. For, a good website is like a good storefront - it can mean all the difference between a casual surfer and a serious customer.

Validation: The key to better Style Sheet Support

If your HTML is not valid, or you use syntax in your CSS which is not correct, then you have a much greater chance that your style sheet based web pages won't work. This page tells you how to validate your web pages and check your CSS syntax.

Why Validate your HTML?

Browsers which support style sheets are very choosey about HTML. Minor problems with your HTML which might "work" by themselves, can cause all sorts of dilemmas when style sheets are applied. This is why we need to move beyond "it looks fine in IE and Netscape on my computer" testing of our pages. To ensure your HTML is correct, it needs to be validated.

Some HTML editing tools like HomeSite have validators built in. There are also a couple of very good ones online, at from HTML Help and the World Wide Web Consortium (W3C). You can also find downloadable validators that run on your own computer.

HTML Help has an online HTML validator which you can paste your HTML into, or with which you can validate your current sites by giving it their URLs.

The World Wide Web Consortium has an online HTML validator. Your site must already be on the web to be validated by it.

For a list of downloadable validators that you can run on your own computer, see TUCOWS, which has sections for Macintosh and Windows validators.

What is Validating?

Validators ensure that your HTML conforms to one of the World Wide Web Consortium recommendations for HTML. Validating is a good habit to get into as it ensures that your pages work on browsers other than those you have "tested" it on, especially those which will come in future, and which may not maintain bugs and general leniency to imperfect HTML which current browsers tend to have.

Once we've ensured our HTML is correct we need to design our style sheet. There are two important considerations here.

In short, the latest HTML recommendation from the W3C is HTML 4.0. This version of HTML has three flavors, strict, transitional (or loose) and frameset. The strict variant excludes all presentational markup (such as <font> elements), while transitional includes these elements. frameset includes support for frames.

When validating your pages, you decide which variant (or "document type definition" DTD) you want to validate against. Which one should you choose? Here is what the W3C has to say, as part of the definition for HTML 4.0 strict.

Authors should use the Strict DTD when possible, but may use the Transitional DTD when support for presentation attribute and elements is required.

I'd recommend you always try for strict validation. Then you'll be ready for future versions of HTML.

So How Do I Do This?

Depending on the validator you use the approach is slightly different, but close enough that by discussing one, you should get the whole picture. Firstly, you need a way of telling the validator which DTD you are validating against. You do this by adding a link above the head of your HTML document like this

for Strict

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http://www.w3.org/TR/REC-html40/strict.dtd">

for Loose

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">

for Frameset

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"
"http://www.w3.org/TR/REC-html40/frameset.dtd">

You use the strict DTD if your page contains no presentational markup, and the frameset DTD if your pages has frames, otherwise use the loose DTD.

Next you copy all of the page, go to http://htmlhelp.org/tools/validator/ and paste your code into the validator. It will return errors and warnings where appropriate.

Validate your Style Sheets

Just as it is important to ensure that your HTML is valid, its also important to ensure that your style sheet is correct. It is common on the style sheets newsgroup to see news items bemoaning a bug in one browser, when the cause is in fact incorrect style sheet syntax that another browser is lenient towards. Beware that Internet Explorer can be very lenient toward invalid style sheets. If you usually "test" your web pages with Explorer, you might get some surprises when you view the page in another browser which supports CSS.

The most common example is leaving units off values. For example the following rule is invalid CSS. Browsers should ignore it.

h1 {margin-left: 12}

This specifies that the left margin for <H1> elements should be 12. 12 what? It isn't specified, and so, this is invalid, and should be simply ignored. Netscape Navigator does so, but Internet Explorer happily treats this as 12 pixels. Often developers consider that Navigator is buggy (because the style sheet "doesn't work") when in fact it is behaving correctly in ignoring the rule. IE "works" but is buggy.

Short of knowing the specification backwards (I don't, and I would suggest very few people on earth do) how can we ensure that out style sheets are valid? Validate them! There are two good validators that will help you ensure that your style sheet is valid, and will even warn you about possible problems.

You can validate your style sheets using an online validator from the World Wide Web Consortium.

HTML Help also provides an online CSS validator. In addition to validating your CSS, it will also warns of possible usability problems with your style sheets.

Using each of these is as simple as pasting the CSS code or the URL of the style sheet into a field. So go ahead, what are you wainting for?