View System Documentation - HTML Page Design
Design Goals
The goal was to have a presentation system that runs on 90% of all browsers, is interactive, uses widely accepted web standards, is adoptable by other agencies, is lightweight (with minimal plugins), displays high quality graphics, is maintainable and simple as possible, and is 508 compliant. Some of these design goals conflict like interactive vs. simple and high quality graphics vs. accepted web standards while some are not totally met like the 508 compliance.Design
- HTML 4 is used because it is the most widely accepted/adopted standard while offering significantly improved HTML over version 3.x. This precludes some older browsers from using the system but the percentage is small and and most of the interactive features and SVG plugin will not work anyway.
- Used CSS as much as possible with as little as possible HTML element attribute control. This allows for look and feel changes to be made to a few CSS file(s) without having to touch the myriad of PAGE XML files and XSLT files. It also provides a common look and feel for all pages within the system.
- HTML "div" block elements with CSS were used instead of HTML "table" elements as much as possible. This keeps things simple and removes the oddities on how different browsers handle tables.
- HTML "div" and "span" elements are used for block formatting instead of the HTML "font", "strong", and other font formatting elements. These block elements are then controlled via CSS which allows for quick and consistent block formatting changes.
- H1..H7 HTML header elements were implemented in October, 2006 to format major block titles. Prior to this DIV elements were used with CSS class set to either BlockTitle or ContentBlockTitle etc. This change was made after reading an article on browser readers that help their user's by being able to skip content based on the "H#" element.
- Used CSS scaleable "Percentage" and "EM" font sizes. This allows the user to control how big/small they want their page's text. If "%" or "em" is specified as the font size then that font's size is based on the user's browser font size setting. The helps those visually impaired users as well as older users and allows those with good eye the ability to use a smaller font size which allows them to see more text without having to scroll the page. The printer friendly CSS specifies font sizes in points "pt" because this is a printer specific setting that allows all printed pages to be consistently handled.
- Javacript is used for control and providing some interactive features of the site. DHTML and DOM (document object model) type calls are used but are typically localized in functions so that browser specific code can be implemented or the call/object/method/property is check for support in all the major browsers. See www.quirksmode.org/ which is a great reference resource Javascript and browser compatibility.
- SVG was chosen for high quality interactive graphics. This requires a plug in and has some oddities. JPEG images are also available for those users who can not or do not want to use SVG.
- MS ActiveX components were not considered due to their inability to run on all platforms/browsers.
- Macromedia's Flash was not considered as an option because users can not copy Flash content and paste into other applications.
CSS
As mentioned above, CSS is used as much as possible to localize and control all of the web site's pages look and feel. Some XSLTs and PAGE XML files do contain local CSS overrides and/or new definitions but these are only needed/used in one special spot. If page specific CSS code is needed and it is something that another agency might want to control then that formatting should be specified in one of the included CSS files or it should be localized in an appropriate "SiteSpecific.xslt" file via a "html.otherCSS" type template call. These are best practices to follow which will help keep the pages consistent, more maintainable, and easier for another agency to change/adopt. Since most PAGE XML files are very specific to the deploying agency it is generally acceptable to embed CSS styles in this file and possibly even use some limited formatting HTML elements like "strong". See the CSS to XSLT Xref Report page for a detailed list of which HTML element/CSS definitions are used within which XSLTs.The system uses the following CSS files:
| Filename | Description |
|---|---|
| standard.css | Core, stylesheet definitions for all IBIS-PH View System pages. |
| printer_friendly.css | Printer friendly specific and "standard.css" override definitions for the printer friendly version of all IBIS-PH View System pages. This includes specifying the page width, different font sizes in terms of "points" and some color changes that are more appropriate for a printed page. |
| query.css | Query specific definitions for the query module, confirmation, and result pages. |
| selection.css | Selection specific definitions for the query module, selection and query module builder pages. These properties control how the query steps, questions, and answers are formatted. |
| map.css | Style definitions for the Map XSLT SVG. |
| jsp.css | Style definitions for the system's JSP pages. |
| doc.css | Contains system documentation page specific definitions |
There are two major things to know about CSS. 1) CSS properties are inherited
from their container NOT from a general class definition (as with a programming
language). 2) CSS property file properties are overwritten with the last property
defined having precedence. All pages utilize the css/standard.css
file which provides the core formatting. Other supplemental style sheet files
are then included which override previously defined style properties or define
section/new page specific class definitions.
Javascript Navigation Menus
There are two basic categories of Javascript usage. The first is the menuing system with the second major category being page control. Initially the site's menu navigation was implemented using the Milonic menu because it offered great cross browser compatibility, was very "cool" and interactive, and was able to be extended dynamically. However, the Milonic menu is not 508 compliant and it is very difficult to extend and maintain for other agencies wanting to implement the system. In October 2006, an HTML list structure was implemented which is 508 compliant and much more easily understood and maintained. Javascript code is used to control how the list is displayed and to control sub menus. Javascript code also is used to provide the elevator menu movement. The site's navigation consists of two menus. The first is the horizontal tab menu which shows the major modules of the system and is the same no matter which module/part of the application the user is at. The second is the left hand context navigation menu. This menu is specific to the current page/application module. The HTML link definitions are specified in each section's "SiteSpecific.xslt" file. Listed below are the Javascript files used for the Utah navigation menu.Milonic Menu Javascript Files:
| Filename | Description |
|---|---|
| js/mmenu/mmenu.js | Contains the Milonic Menu DHTML producing Javascript code. This code reads the menu definition structures and creates DHTML menus. |
| js/mmenu/base.js | Contains the Milonic menu style definitions, top menu tab navigation menu definitions, and core popout text menu definitions common for all IBIS-PH View System pages. |
| js/mmenu/home.js | Left hand navigation menu definitions used by all "home" type pages. |
| js/mmenu/query.js | Left hand navigation menu definitions used by all "query" type pages. |
| xslt/indicator/profile/_indicator.xslt | Left hand navigation menu definitions used by Indicator "PAGE XML" page (all non dynamically created Indicator Profile view type pages). |
| js/mmenu/doc.js | Left hand navigation menu definitions used by all "doc" type pages (system documentation). |
Javascript Selection Page Control
The selection page control consists of the the Javascripts that are used to control the hiding and displaying of Query Module selection sections. These selection sections are built by the associated "module.xslt" and "module_selection.xslt" which produce HTML elements with the appropriate "id" attributes and registers the HTML elements.Selection Related Javascript Files:
| Filename | Description |
|---|---|
| js/selection/handlers.js | Provides specific Javascript event handler functions that are registered to HTML user interface action type elements. |
| js/selection/preferences.js | Provides the Javascript functions that are used to get and set the user preferences for the "selection" javascript functions. |
| js/selection/specific.js | Contains the main Javascript functions that are used to controls the selections (questions and answers for the IBIS-Q input pages) and (sections and selections) for the Query Module Selection type pages. These functions include general purpose control code as well as specific business rules called from the handler methods and applied based on the user preferences. |
| js/general.js | Provides general, core non selection specific functions for working with the DOM (like getting the value of a radio button group, getting an element/object, hiding/showing elements), string prototypes, and cookie related functions. |
User Preference and System Cookies
This section lists the user preference cookies used by the system. The table below shows the cookie name, a brief description, what page the cookie is set/created/controlled on and what page(s) use the cookie value.| Cookie Name | Description |
|---|---|
| GraphicType |
Controls the type of chart or map graphic image HTML page the system
will build for the Indicator Profile view, PHOM view, and Query result
pages. This value is set to "SVG" or "JPEG" and defaults to "JPEG" if
the cookie is not present. The controllers read the cookie value and
set the value as a parameter that is passed to the XSLT that creates
the appropriate HTML image elements for the HTML page.
Used On: indicator/view/*.html, indicator/complete_profile/*.html phom/view/*.html, phom/expanded_view/*.html query/*/result.html Set On: home/GraphicPreference.html |
| QuerySelectionShowOnEntry |
Controls what to display on entry. "OVERVIEW" = Only display the Overview section for that query module and hide all other sections and steps when first entering the page. "ALL" = Overview, all sections, steps, questions and answers. "FIRST_SECTION" = Only show the first step. Used On: query/module/*/*.html Set On: query/module/*/*.html, query/ModulePreferences.html |
| QuerySelectionShowStep |
Controls how to display the steps/sections questions and answers. "CURRENT_ONLY" = Hide previous step/section and show the new current step/section. "ALL_SELECTED" = Show all questions and answers which have been selected. "ALL_VISITED" = Show all steps/sections questions and answers visited/expanded. Used On: query/module/*/*.html Set On: query/module/*/*.html, query/ModulePreferences.html |
| QuerySelectionAutoAdvanceNextStep |
If the current step's selection is a single selection list or radio
button then setting this cookie value to "AUTO_ADVANCE" will cause
the system to auto open the next step when current radio/single list
selection choice is made.
Used On: query/module/*/*.html Set On: query/module/*/*.html, query/ModulePreferences.html |
| QuerySelectionAutoSubmit |
If this cookie's value is set to "AUTO_SUBMIT" then the system will
set a query module XML element that specifies that the "confirmation"
page will auto submit for the query results. If this cookie is not
set to "AUTO_SUBMIT" then the confirmation XSLT code will build a
page that the user will need to press a submit button on to continue.
Used On: query/module/*/*.html, query/*/confirmation.html (via controller). Set On: query/module/*/*.html, query/ModulePreferences.html |
| QuerySelectionSavePreferences |
If this cookie value is set to "SAVE", then all the query module
type preferences are saved to persistent cookies. This cookie's
value is also saved and used for any subsequent changes which
causes the system to update those changed values. If the item
is not selected (e.g. not set to "SAVE"), the settings will be
in effect for the current session only.
Used On: query/module/*/*.html Set On: query/module/*/*.html, query/ModulePreferences.html |
508 Compliance
The site was tested by a visually impaired person that works at Utah's Department of Health. The system was navigatable using their standard software but it was klunky due to the Milonic DHTML menu used. Future site improvements include creating the navigation menu as standard HTML with some basic Javascript used to position the menu. This coupled with the site's usage of browser specified scalable fonts provides a site that complies quite well with 508. To reach 100% compliance involves updating all HTML elements to have a "title" attribute so that when moused over or focused on that some text describing the item is available. Most of the major HTML elements within that site already have have implemented title attributes but there are some that still need to be implemented.Web Crawlers and Page Indexing
The site was redesigned to look and work like a static "HTML" based web site so that search engine web crawlers could index the pages. This has been done and most search engines now have the IBIS-PH pages indexed quite well. The site's pages all have the capability to contain HTML META KEYWORDS and DESCRIPTION which some crawlers use. Most sites that discuss how to improve crawlability and page ranking say that the page's title, body content, and standard HTML navigation are the keys. Also having a site that is interwoven can help with an increased score. One of the biggest score raisers is to have other sites reference pages within the site. As discussed above in the "508 Compliance" section replacing the DHTML menu (which most crawlers can NOT deal with) would also improve the site's ability to be crawled and would show a much deeper interconnection. The Indicator Profile View type pages have been developed to provide standard left hand HTML menus for navigation for those users who do not support Javascript menus. If Javascript is supported then a small script hides this menu so that the Milonic Menu is shown (this functionality is located in the "indicator/profile/SiteSpecific.xslt" file). Also the footer contains a standard HTML "a" "site map" which allows a crawler to hit all the pages within the system.This IBIS-PH View System contains the standard "robots.txt" file. This file contains URL patterns for pages that the crawler should ignore/not index. Currently only the query result type pages should be ignored.