View System Documentation - Menu 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). |