|
|
This page discusses techniques and issues dealing with the IBIS-PH View Systems
page design. This discussion includes the system's goals, CSS, 508 compliance,
Javascript navigation menus, page control Javascripts, user preferences and
cookies, and search engine web crawlers.
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.
|