Level 2 Page

Required Topics for Initial Submission of Standards Manual:
 

1. The "look and feel" down through all levels. For a small site (200 or so pages), there should probably be no more than four levels. Link to LEVEL (2) Page
2. Consider how links will be placed and used. Links should not be intrusive. And when used to lead the viewer off your site, use them with care and purpose.

From LEVEL (2) there will be internal and external links.  All external links will be created in a new page, not in the same frame, to prevent the user from being possibly locked up, not allowing the user to come back to the original page.   Periodically links will be checked to see if any have changed.  Currently external links that do not open in a new page, will be modified.

3. How and/or if frames will be used. Frames help with navigation, reduce the maintenance load, and facilitate space parsing, but can confound the uninitiated.

All LEVEL (2) pages appear inside the frameset of the default page.   This leaves the user in a comfortable environment, where it is obvious where one is at any time.

4. Navigation through your site. You should never let viewers get lost, no matter what they do. Viewers should always be able to undo whatever they do and always be able to find an index.

[ -07/27/01-] revised

Searching and finding Information

As in LEVEL (1), LEVEL (2) provides the same consistency in navigation using frames.   Even when using javascript with forms, the user can easily see where they came from and the path back by providing a return to home key.

[-07/27/01-] revised

Searching and finding Information

Navigation for accesibility shall be addressed at this level by using consistent content and links that work from wherever one is located.   From LEVEL (1) to LEVEL (2) shall provide the user with the same feel as if he/she was within the site.   This will help improve the overall appearance and consistency within the site.  Easily displayed at LEVEL (1) is the Search Engine at the top of the main page, clearly visible.  This same page will be available at the bottom of each subsquent page as a link.   A user can always use the search utility within anywhtere in the site, or external to the entire web.  On a consistent basis the web site is submitted to the search engine server that maintains the index and listings of all the URL's that are contained within a database on that server.   As pages are added, the web site is spidered by the search engine and re-indexed to provide an update on the lastest listings.&bnsp; The site map is located at LEVEL (1) and is updated each time new pages are added to the site.

5. Use of graphics, video, and audio. Multimedia effects can be both good and evil.

Continued use of many *.jpg,and *.gif images.   All images shall be pre-sized to allow for speed in loading.   This performance is verified in both Netscape and IE on a 28.8 baud modem for testing.

6. Text run length and use of restricted width columns.

LEVEL (2) pages will not allow text to run past the viewing window.   There will be instances where double width columns will be used but only within tables to provide consistency in browsers.  This is more appealing that one endless paragraph that never ceases to end.

7. Alternate formats to accommodate the disabled, printing, and browser variations.

[-07/27/01-] revised

Disabled Users

As stated in LEVEL (2), all images shall have ALT keys with descriptions of the image, and it's size, not just "Click Here".  The entire site shall work with Netscape Navigator 4.5,4.7 + and Internet Explorer 5.0 + versions.  As time permits other certifications for the disabled will be examined for possible implementation on this site.  This shall be an ongoing task until the entire site meets these requirements as defined by the Web Accessiblity Guidelines(Web Content Accessiblity Guidelines 1.0, 2001).

8. Use of header and footer snippets to maintain page consistency using Server Side Includes if hosts permits.

All pages on LEVEL (2) shall use consistent header and footer snippets to maintain the same style and consistency.   All footers shall also provide a home key on each page.

Required Topics after initial submission (with due dates announced in class and in syllabus): (Please use the same numbering scheme in your template.  Keep the text that is below and fill in your information below each numbered item.  If/when you add additional items, see below for format.)
 

1. Accessibility

LEVEL (2) will provide accessibility by different browsers, and by individuals with disabilities.   Ongoing attempt to secure one of the certifications for accessiblity by taking online analysis by sites such as BOBBY and TIDY.   Efforts will be made to correct as many infractions that can be met and yet still maintain the theme and beneficial content on the site.  Even though the site is using frames, within the index.html (LEVEL (1) to the frameset is a link to the sitemap.html, which provides any search engine to follow that path inside the site regardless of the use of frames.   This code is included inside the /NOFRAMES/ tag on the index.html page.   This consistency will be maintained at any level.

[ -07/27/01-] revised

All images on LEVEL (2) and image maps will provide text equivalent descriptions about content of the images.   Cascading Style Sheets (CSS) shall be used consistently throughout the site to provide speed of downloading, structure and ease of readability.   This will be an ongoing project due to the large amount of images used on LEVELS (1,2,3).  All pages including new pages will be tested with older versions of Netscape(3) IE4.5 +, and current published versions for compatibility and meeting requirements of older browsers, screen size and resolution.   Text must be visible if CSS does not work on older browsers.   Colors and background combinations must be compatible if someone who has color deficiencies, hence, using safe browser colors and combinations of colors.  Site should be readable and clear if viewed in black and white, while still being accessible.

2. Maintainability

Any updates on LEVEL (2) are reflected at the bottom of LEVEL (2)page.   Where possible, this will be accomplished by use of Server Side Includes (SSI).   This allows any client or user, at a quick glance, the last time the site was modified.   This date will be changed anytime there is any update on the site as well as the "What's New Page".

[-08/04/01-] revised

Structure The structure of LEVEL (2) pages   These pages are accessed from either the table of contents or the default page and consists the heart of the web site.   The LEVEL (2) pages are styled using CSS and provide consistency and format on the entire level regardless of the subject matter.   The pages are kits, Purpose,Turntable,Structures,Links, What's New,Engine,Survey,Guestbook and Archives.   All pages on LEVEL (2) are refreshed within the right-hand frameset of the default page.  Both relative and absolute links to the MAIN Home Page exists throughout LEVEL (1) pages.   All LEVEL (2) pages must have the same style, header and footers to provide consistency and ease of navigation into the next two LEVELS and well as back to the MAIN Home Page.

[-08/04/01-] revised Coding Issues To verify that all coding is working correctly to LEVEL (2) and back to any other LEVEL (0,1,& 3) must be validated.   I use the web site Search utility on a weekly basis to check any changes in my code as far as links are concerned.   The report generated sweeps the entire site and produces a report that identifies which links are not working.   This has to be corrected immediately.   Secondly within the code, is the issue of consistency in using headers and footers with SSI.   All files that are using SSI are saved as *.shtml files.   These are stored in the same root directory as the *.html files.   The editor HOMESITE by Altaire is used as the primary editor.   After a page is finished, the code is validated against the HOMESITE code analyzer for infractions in HTML XHTML, javaScript, ASP and SSL.   A style of coding is necessary for continuity for the next designer that might follow behind and have to fix something.   Currently, all code is hand-written without the use of external automatic code generators.  When testing a new page, it is always best to check it first in Netscape, then Internet Explorer.  I test with 3 version of Netscape, version 3.0, 4.7 and 6.0. as well as multiple versions of IE.

Documentation, Rules, and Collaboration When developing web pages, it is necessary to document when using nesting multiple tags, where various tables, forms, and html tags start and end.   If a change is made in an HTML page, the date of the change will be noted to reflect the last time a change was made.   This is separate from the SSI include statement that looks for a file that has changed since the last time and places that date on the *.shtml page.   Comments are very important for remembering and helping some else who might have to modify your code sometime in the future.   If something took considerable effort to implement the code, you should document only the essentials that would simply explain the coding.   Indentation, and proper spacing are required as well as helpful in reading the code when there is a problem.  Since HTML ignores white space, use it for something constructive.   These rules are no different that writing software in any other language.   If you borrow some code of any kind, it should be documented as to who the original author was, the date it was created, and that you modified the code on a specific date.   Remember, anyone can read your code on the Internet.   Anything that is not yours needs to be acknowledged and properly documented.   The rules for testing and implementing code follow the following requirements.  : 1) All development code, forms, and images reside first on the test server, Polaris.  There is a mirror image of what is currently on the test server at the Unix Polaris Server.   All ideas are first developed on the test server, NT 2000, saved and then ftp'd to the polaris machine.   The directory structure on Polaris is: /*.html ( All html code ) /images/ *.jpg, *.gif (majority of images keep here ) /images/roundhouse/ *.jpg (special image for a specific page ) /documents/ *.html (all documents that are referenced from the web site) The production server is first developed on the NT server in a directory called Hosteam.   The actual web server is at Ho Steam Central in Virginia.   The file and directory structure is: /*.html ( All html code ) /images/ *.jpg, *.gif (majority of images keep here ) /images/roundhouse/ *.jpg (special image for a specific page ) /documents/ *.html (all documents that are referenced from the web site) Anything that is on the production server must be checked with the various browsers on the Polaris Unix server first, then ported to the Production Server.

3. [-08/10/01-] revised Privacy Statement

   At LEVEL (2) there will be a link back to the home page, LEVEL (0), for the privacy statement and copyright criteria.   Any questions that a user might have over information collected as to design services will be explained in this document.

   There shall be a page dedicated to privacy issues as it pertains to any individual's information collected and used by this site.  There will be a link on all pages on LEVEL (2) to the location of the page on LEVEL (1) within the footer that is included in the SSL footer.txt as well as all *.html pages on LEVEl (2) for consistency.  

• 
  Additional Topics: (To add an additional item, please use a bullet list with the topic as the list item and your text following below.)

Typeface

[ -07/27/01-] revised

The typeface will be consistent within CSS.

• directory structure

[ -07/27/01-] revised

All images shall be stored in a different directory as the code, HTML,SHTML,JS will reside in the root directory under the WWW directory on the server.

• [-08/04/01-] revised legal

  This is covered in the Copyright page at ../../copyright.html

• privacy

  This is referenced and explained in the Privacy page at ../../privacy.html.

[ -07/27/01-] revised

From LEVEL (2) links to the privacy.html will be provided.

• link to home

[ -07/27/01-] revised

From LEVEL (2) links to home refer to links to the default page, not to the Main page on LEVEL (0).

• first-level, second-level, and third-level look-and-feel

  [ -07/27/01-] revised

  All pages and transistions between levels will be the same look-and-feel.

• templates for one-column, two-column, and three-column templates

  [ -07/27/01-] revised

  There will be templates for one,two and three column page to speed up the creation of pages and maintain consistency.

• absolute vs relative links (avoid absolute links for all but external links to insure portability of your site)

  [-07/27/01-] revised

  At LEVEL (2) all links shall be relative, unless for some special reason.

• type of code allowed (e.g., cgi, java, java script)

  [ -07/27/01-] revised

  All the above codes will be allowd on LEVEL (2).

• Frames? Target = new?  >>How will we handle external links?

  All external links will be created via a new page, so as not to leave the customer without a way back in case the external link suddently dies.

• [-08/04/01-] revised What happens if someone bookmarks any page other than the home page?

  Each page will display at the bottom a textual description of what the name of the page is within the frameset, so the user could actually bookmark that individual page rather than only the website.   An example would be" The page can be bookmarked at: http:hosteamcentral.com/structures.shtml.

• [-08/04/01-] revised Headers

  Will be used on all levels and will be called header.txt.

• [-08/04/01-] revised Footers

  Will be used on all pages in all levels unless for some images, called footer.txt.

• [-08/04/01-] revised Video

  N/A Not applicable at this time.

• [-08/04/01-] revised Audio

N/A Not applicable at the time.

• Pictures and Graphics (jpg? gif? animation? size -- on page and in MB)

  The size of images shall be limited and judged by the loading time and performance characteristics and impact on each page.   This is an area that can be changed many times depending on customer atttention or lack of.   Majority of images shall be thumbnails to avoid long loading times and frustration to the customer.

• [ -07/27/01-] revised Appropriate Content

  Inappropriate content is not acceptable.

• Logos (using yours and making it look good; using those belonging to others and getting permission)

  All logos with the exception of search engine, will be the sole property of HO Steam Central unless written permission from the owner has been obtained in order to display their logos or image banners

• How will you handle long pages/wide pages?

  The only wide pages will be for full size images that were accessed from a thumbnail image or page.

• Will you provide alternate formats that are printer friendly

  [-08/01/01-] revised

  Any Microsoft Word or other software word processor documents within the site will be available to print in Acrobat PDF format.

• [-08/04/01-] revised Will you allow database access

  The ability to use databases is acceptable if required, but performance must be considered as part of this endeavor.

• Security (e.g., client side vs server side coding, passwords and access controls, SSL and encryption, Certificates)

  There are very few limitations on the production server which is running WINDOWS 2000.   This site can implement any of the above methodologies plus site is protected via high security firewall.

• [-08/04/01-] revised Search capability

  LEVEL (2) shall be included in the index and available to the search engine.

• Forms usage (or other interactive capability)

  [ -07/27/01-] revised

  This will be used providing CGI server is available.

• Copyright/fair use

  [-08/01/01-] revised

  This is included in the Copyright Page.

[-08/04/01-]
Publishing model work flow (a good thing to mention, too -- need to seperate development/test/production material on different servers if you can)

[-08/01/01-] revised

Development Server is on Polaris while the production Server is located on HO Steam Central, which is hosted in Virginia.   The main front end Main page is on Nova

This provides considerable flexibility in testing and developing prior to implementing on the production server.

Back to Standards Manual Home