|
|
|||
|
|
|
|
|
|
||||
        
|
 |
Chapter 5: Evaluating Web Sites
Execution Analysis
Execution testing focuses on trying to make sure the site is built correctly. Execution includes issues with content, visuals, technology, and delivery. For example, with content, you might look to see if site content is up-to-date or if there are spelling and grammar errors in pages. Technical execution would focus on whether the site follows standards for HTML, CSS, XML, and other technologies. Visual execution would be concerned with image quality and file size. Delivery would be focused on speed and server capacity. The next few sections detail a few of the things to keep in mind as you evaluate each area, with the Appendix B checklist providing a set of specific questions to try to answer.Content Execution
The quality of a site is heavily influenced by the freshness and quality of the content presented. A site's content should be appropriate in quantity—not too much that it is difficult to find appropriate information easily, but not so little that the user is left wanting more. The content should also be up-to-date and accurate. Execution issues, such as spelling, grammar, and tone, should also be well considered. Last, the details of the site should be very carefully examined. Truly, with Web sites, the devil is in the details. Copyright dates, trademarks, product names, and very small formatting errors are often glaring to the user and may ruin an otherwise excellent experience.A good way to evaluate content is to do a careful screen and paper walk-through. Printing pages and going over each one very carefully is probably the best way to find typos and consistency issues. However, many Web maintenance tools and even page editors can be used to spell-check pages. When looking for details, it is tough to spot everything; fortunately, some Web site maintenance tools can be used to evaluate consistency of terminology through the use of custom rules that look for the inclusion of certain key phrases. Visual Execution
Evaluating the look and feel of a site can be difficult because doing so is, to a great degree, a matter of personal taste. However, execution of images and layout should be evaluated regardless of your personal take on a site's aesthetics. Images may not be used properly or optimized correctly. There may be color problems in the site, font sizing issues, and page layout problems. In many cases, the page layout may not even fit the screen resolution or print correctly. Pay particular attention to tests of the site under less than ideal conditions, such as lower resolution. In many cases, a site layout will completely fall apart when images are turned off or font sizes modified. When doing the visual portion of a site evaluation, it is important to print out a screen capture of the evaluated page, as it may change over time. Screen printouts can be marked up to draw attention to problem areas as well as interesting features. Figure 5-2 shows an example of a marked-up page with visual and navigation execution notes.
Technical Execution
Web design relies heavily on technology, ranging from simple markup languages to complex programming approaches. When evaluating a site you have full access to, it is possible not only to look at client-side technologies, such as HTML, but also to examine server-side technologies, such as CGI programs or databases. Unfortunately, when examining sites externally, you may be limited to looking only at technology easily viewed at the browser or the effect of technology executed on a server. For some evaluators, it may be appropriate to call in a professional programmer to evaluate the quality of examined code, as glaring errors may escape those who know CGI or JavaScript only just enough to use provided scripts. We overview a few of the more common technologies here for evaluation and leave the rest for Appendix B.HTML/XHTML Because HTML serves as the bedrock of a Web site, particular attention should be paid to the accuracy and quality of HTML. With the rise of XHTML, use of the doctype indicator and strict compliance are becoming particularly critical. Compliance with the various HTML or XHTML standards should be examined by validating key pages in the site. Online validators, such as http://validator.w3.org, can be used, but readers may find stand alone validation tools like CSE Validator (http://www.htmlvalidator.com) to be superior. Figure 5-3 shows this validator in action.
Proprietary tag usage or trick HTML should be carefully noted. Inspection <meta> tags, comments, and other small signs such as consistent page formats should be noted to help determine how HTML was created—such as with a tool or by hand. In some cases, telltale signs like indentation patterns of markup may indicate creation by a particular HTML editor; but if it is possible to directly query the developer, ask which tools were used and what standards were followed if any. CSS Cascading Style Sheets are rapidly becoming an important technology for presenting Web pages. CSS use provides a major benefit in allowing separation of document structure from presentation. However, unless the site uses external style sheets, this benefit is reduced. Document-wide style sheets or inline styles are adequate, but their use should be considered less than ideal. Regardless of the method of including style rules, extreme care must be taken with CSS because of all the browser bugs and rendering differences. Compliance with the CSS1 and CSS2 standards may not be as important as making sure the various CSS properties work under common browsers. However, a CSS checker, such as http://jigsaw.w3.org/css-validator/, should be used. Close attention should also be paid to the types of rules used and whether or not there is any problem with browsers that do not support CSS. Testing with an older browser or with the CSS facilities turned off should be performed.JavaScript JavaScript is a very important part of many Web pages, but far too often it is not used in a reliable manner. Well-executed JavaScript-laden pages will employ the <noscript> tag to address scripting being turned off, and may even restrict usage without script enabled. Scripts also should be able to address browser incompatibilities and should not throw error messages like the one shown here: Fortunately for Web site visitors, most browsers are shipped with the default to turn off JavaScript error notifications, since otherwise you would probably see a great number of them. Set your browser's preferences to show errors, as shown here in Internet Explorer.  In Netscape, you should check the JavaScript console for the error message shown here:  Cookies For many, the use of cookies is an invasion of personal privacy. The reality is that cookies are very useful to get around programming limitations caused mainly by HTTP protocol limitations. However, regardless of your personal take on cookies, it is important to know whether a site uses cookies and what they are used for. Some sites may even issue multiple cookies per visit, each with a different purpose. Careful inspection of cookie data can yield valuable clues to how a site works. If cookies are used, it is important to verify the site still works with cookies off. Also, if cookies are used, a statement indicating what they are used for should be available on the site.Browser Support Probably the most well-known aspect of site testing is browser support. Many site testing protocols simply advise designers to test in as many browsers as possible. The reality is that you should attempt to create a matrix of the various browsers and perform the technology and layout tests within each browser individually. Oddly, you may find that there are subtle rendering differences in each browser, as well as numerous bugs. A large matrix showing all the different versions of each browser and operating system is the best way to conduct a browser test. Unfortunately, you may find that there are literally dozens of versions of just the 4.x generation of Netscape. Because of the difficulty of testing so many combinations, you may want to focus on those browsers that are known to use your site. In some cases, such as with an intranet, the browser being used may be obvious; but before guessing what browsers a site's users commonly use, consider accessing the log files to make sure.Delivery Execution
How the site is delivered is extremely important to understanding the site's usability. Users appreciate fast downloads, but, as will be discussed in Chapter 17, speed of delivery is often influenced by many factors beyond the size of files being delivered. It is important to understand the server resources used to deliver a site, including both hardware and software used. It is also important to understand how the site is hosted. How the site eventually connects to the Internet can impact performance greatly. Using even simple network tools like "ping," it is possible to determine the responsiveness of a server. Many operating systems provide this tool; for example, under Windows, access the DOS prompt and type ping and a host name. If you typed ping www.webdesignref.com, you might see something like this:
C:\WINDOWS>ping www.webdesignref.com
The round-trip time of data can be used to get a general sense of the responsiveness of the server. It is also possible to acquire other server and network information using tools like WHOIS, traceroute, nslookup, and others. On Windows, most of these tools are included in the operating system, can be found in the public domain, or are nicely packaged in network tools like WS_Ping ProPack (http://www.ipswitch.com/).Pinging www.webdesignref.com [66.45.42.235] with 32 bytes of data: Reply from 66.45.42.235: bytes=32 time=32ms TTL=114 Reply from 66.45.42.235: bytes=32 time=66ms TTL=114 Reply from 66.45.42.235: bytes=32 time=27ms TTL=114 Reply from 66.45.42.235: bytes=32 time=95ms TTL=114 Ping statistics for 66.45.42.235: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:Minimum = 27ms, Maximum = 95ms, Average = 55ms After server and network issues, the size of the pages delivered should be considered. Most site analysis tools will identify pages that are considered large. You can set the threshold for what is considered large, byte-wise, in most of the programs, but some consider anything over 30–50K (including any graphics in the page) as a large page, despite the rising popularity of faster Internet access. Theoretical download times under a variety of line speeds can also be determined with a site analysis tool, and most Web page editors like Dreamweaver even provide facilities to determine page weight and download speed. However, do not rely solely on theoretical times; test the site under actual conditions, if possible. Since network conditions are always changing site delivery, test results may vary greatly from moment to moment. Next: The Final Question
|
 Overview | Chapters | Examples | Resources | Buy the Book! |
