Quick and Simple Navigation
Some sites have really good looks, but are very confusing and difficult to navigate. Vistors are quite impatient and if they can't find what they are looking for, they will leave fast.
Therefore, if your Web site is not quick and simple to navigate then your visitors are history. So give your visitors lots of options for navigation and ALWAYS include a text navigation bar at the bottom of your page (especially if they are long). Visitors will look for this if anything goes wrong with your other navigation elements (buttons, image maps or navigation engines). If you use graphic buttons, or image maps, make sure to provide alternative text so that viewers don't have to wait for the buttons to download before moving around within your site.
If your site is more than a few pages, it is a good idea to supply a site map to help out. Also, remember that your site will work differently with different browsers, so test your site with as many browsers as possible (Internet Explorer and Netscape at least!).
Last but not least, don't forget to check all of your links once your site is uploaded to the web. It is a BIG turnoff for your visitors to find things that don't work, so make certain everything is functioning properly.
What size screen should you design you Web page for?
The answer to this depends on the monitor resolution used by your site's visitors. Data from the latest Georgia Tech Graphic, Visualization, & Usability Center (GVU) survey suggests that 800x600 pixels is becoming the standard screen resolution.
Screen resolution is a major Web design issue. If you design your page for a high resolution monitor, visitors with lower resolution screens will have to scroll to the right to view parts of the page. One school of thought is to design "liquid pages" that adjust to the visitor's screen size. This is done by defining the width of HTML tables used for page layout in terms of screen percentages. A table that covers to entire width of the screen is set to WIDTH="100%." However, this gives less control over the position of page elements within the table. As a result many Web designers prefer to define their table width in terms of pixels.
But if you use this approach, what pixel width should you use for the screen size? The conventional wisdom has been to design to the smallest screen width in common usage. That means designing for a 640x480 pixel screen.
That's where data from the latest GVU survey comes in handy. According to GVU's latest data, as of April 1998 16.6% of all Internet users is a monitor resolution of 640x480. That represents a downward trend from 19.95% in October 1996. In contrast, 28.4% of users have a monitor set to 800x600 pixels. That represents an increase from 17.67% in October 1996.
Does this mean that you should start designing your pages for 800 pixel width? That's a design tradeoff you'll have to make in building your pages. Sixteen percent of your audience is still a lot of users. A rule of thumb used by many designers says that, if a feature isn't available to 90% of your audience, you shouldn't count on it. GVU also states that their survey respondents tend to be more computer literate and spend more time online that the average Web surfer. They are therefore more likely to be using larger monitors and higher resolution screens. But the trend is clear and suggests that before long you may want to design for 800 pixels.
Important Note: Keep in mind that whatever monitor resolution you choose for your design, your HTML tables should be set to some lesser number of pixels. If you're target.is a 640 pixel monitor, set your tables to about 600 pixels wide; if your target is an 800 pixel monitor, set your tables to be about 750 pixels wide. This allows room for the browser's scroll bar, which takes up a portion of your screen width
WHAT CAN I DO TO FIX A BROKEN SCRIPT?
The most important thing you can do when faced with a script failure problem is take about ten deep breaths before dealing with it. Then, follow these simple steps to trace the cause of the problem.
Check your E-mail. Go read your mail. Maybe there is a note from your system administrator notifying you that something has been changed on the system that might affect your site. If this is the case, then the letter probably holds the answer. If the letter does not make sense to you, the reply to the letter and ask for clarification.
Check the script's modification date. Look at the directory listing for the script. If the date seems more recent than the last time you remember working on it, then either you or somebody else modified it. If you have a back-up copy of the script, compare the two and look for differences. This also applies to any related configuration files.
Check the script's permissions. If you notice that the execute permission on the file has been removed, then you need to figure out if you or the system administrator did it. Often when the sysadmin does this, they also change the ownership of the script so you can't change the permissions back! As I mentioned in the last section, if this is the case, write your sysadmin for advice.
Check your website's physical path. Whether using FTP or telnet, issue the pwd command to find out the full path to the directory where your script resides. If it looks no longer agrees with what paths are in your script(s), edit your scripts with the new path. If you were not notified, write your sysadmin a polite letter thanking them for not notifying you of a change that affected the operation of your site. Of course, if you find an e-mail from three days ago notifying you of an upcoming change.
Check file sizes. If your script creates a log file or other type of output file, check to see how big it is. Many sites have what is called a ulimit. Your sysadmin can advise you on this if you do not have telnet access. If you can log into your site via telnet then issue the ulimit command at the prompt. The result should be either unlimited or a number. The number is how many blocks large a file can be. You will need to then find out whether a block is 512 or 1024 bytes on your server and multiply the ulimit result by the block size to figure out the maximum file size. Fun?
If you have checked everything out and all seems okay at your end, the write your sysadmin. There is a chance that some minor system change was made that they did not think would affect anything. The odds are pretty good that the checklist above will resolve most problems.
THIS WEEKS CUT AND PASTE JAVA SCRIPT
Need a web site built? Or help with yours? Send me an EMAIL
You can also view example of a site I am currently building by Clicking this LINK
BRAVENET WEB MASTER RESOURCES
Thanks to WEB MONKEY for all the great learning materials that will make this site possible.
BACK TO TOP
THIS IS A TEST SITE. 99% OF THE LINKS ARE NOT SET UP YET. THE LINKS WILL TAKE YOU TO VARIOUS SITES AT THE MOMENT BUT SOON EACH WILL LEAD TO A PAGE PACKED WITH INFORMATION.
|