This paper discusses best practices attained by analyzing, troubleshooting, and building numerous layout and question templates. The expected audience should already have an intermediate knowledge of XML, XSL, HTML, JavaScript, CSS, and UNICOM Intelligence template tags.

Start by thinking about how the page will look on legacy web browsers with JavaScript turned off, images turned off, low resolution, low bandwidth, and no CSS support. Thinking about these factors will help ensure that each component is usable on a wider array of devices, networks, and user abilities and disabilities. Ensure the questions and user instructions for providing responses are clear in the HTML, and then begin adding features.

Responsive design is a technique that replaces mobile-specific subsites. Responsive design techniques must be in place to handle large screen resolutions in addition to the very small ones it already handles. As such, the UNICOM Intelligence strategy for any device must begin with responsive design techniques. The following device widths are specifically targeted:

Height measurements are not targeted, as users expect to scroll pages vertically. Horizontal scrolling is only acceptable for widgets on a page.

The targeting device width and height are not targeted. This provides greater flexibility in delivering optimized experiences to devices that have re-sizable browser windows (such as laptops and desktops).

Relative units of measure should be used as much as possible to ensure accessibility and flexibility.

Border must use pixels and should be used sparingly. Whitespace can be used to make the interfaces less cluttered and confusing.

Width and Height should rely on percentages as much as possible, then EMS (the number of characters across an item), and finally pixels when an absolute size is required.

Images should be relatively sized; width and height should be set in percentage (which takes the parent element’s size into account).

There should be no fixed width templates, all UNICOM Intelligence templates should be fluid to allow for adaptation to any window size.

In order to ensure the content can resize in relation to the browser window size, the very first few lines of default CSS should be:

Some browsers show a disabled scroll bar by default. Setting the HTML overflow to hidden resolves this issue.

Margin and padding increase the size of an element that has a specified height and width. For example, when the body element is 100% and is left with the browser default for padding and/or margin, the body is 100% + 10px wide. This causes the horizontal scroll bars to appear where they are not intended and ruin the layout.

All body elements need to size and flow proportionally to the viewport (browser window). Setting HTML and body elements to 100% height and width will set the reference point for all children to be related to the viewport.

Some mobile devices try to make web browsing more consistent with desktop browsers by zooming the web pages. This effectively shrinks content to fit within the width of the browser window. This is now ideal given that the goal is to create content that is optimized for small windows. The following meta tag in the document head will prevent zooming:

Ignore the media query JavaScript implementation for Internet Explorer and other legacy browsers. Having a good default layout will take care of respondents using Internet Explorer. However, users can test their responsive layouts in the Internet Explorer dependent applications only if media queries are faked with JavaScript.

A better JavaScript solution can be found in the responsive DefaultLayout.htm layout template. The template is installed with the UNICOM Intelligence Developer Documentation Library at:

The file of interest is in the supporting files folder, the default.js file:

This solution looks for the existing media query links in the DefaultLayout.htm head element, and builds a JavaScript object that can be used to detach and reattach CSS styles based on the current size of the browser window. This solution reduces the number of files that have to contain identical styling information.

Simplifying the question template involves separating the content from the behavior and layout. Rather than using inline script, wrap the desired mrData tags in an element with a class name that corresponds with the question control you are building. Create a supporting files folder and include a JavaScript file that will handle both generating the controls as well as placing them within the page. The best way to do this is to have the JavaScript look for every instance of your control class name, create a new control, and place it in relation to the element. When you reference the js file in the questionTemplate.htm, include the "defer" attribute (defer="defer") and place the reference in the head (set the position attribute to "head").

Alternately, by using common best practices and setting the position at "bottom", you will not need to include the defer attribute.

This ensures that the js file is only referenced once, and forces the file to run after all the HTML elements have been added to the DOM. This helps by:

Avoid global variables because there is no way to ensure non-conflict, especially if there are multiple script files running on a page. Instead of writing something like the following in a js file:

Wrap the object as: