Contensive Best Practice Guide

This page includes our best practices guidelines.

Website Patterns

Website Forms

A website form is a process of one or more pages that are rendered as html with optional prepopulation, and can be optionally submitted back to the server with user response.

Website Templates

A website template pattern is the process used to create the look-and-feel for a website. The emphasis is on flexibility and managing future changes.

Online Applications

This pattern is for applications that generally are controlled by the browser, and primarily use the server to request data.

Mobile Applications

This pattern is for applications designed to install and run only on mobile without a browser.

Software Development

Addons

• RemoteMethod addons should be camel-case with no spaces.
• non-RemoteMethod addons should be treated as public facing, named as captions with initial upper case.
• Should be contained within a Collection.
• Should have Presentation set (Tool/Report/Setting/Addon).
• Should populate name fields in all records that are created.
• Public facing Html should be generation using layouts records and/or html file.
• Administrative screen Html should use layouts, html files or internal html methods.
• All methods require error handling to gracefully log and exit.
• Error generation should be reserved for error conditions, do not throw errors to test values.
• When generating multi-page form, handle visit timeouts gracefully. Consider returning users to the first form of the process with an error message.

Content Definitions

Content Definitions are meta data that manage database tables and fields.

• Should have Field Help for all non-standard fields.

Logins

• Should focus on the username/email field.
• Should tab to password field.
• Should submit on pressing the Enter key or SUBMIT button.
• Record Lists
• Should use layouts and repeaters.
• Should paginate.
• Should contain pagination menu top and bottom.

Forms

• Should focus on first field.
• Should tab in a logical order.
• Should not show default name Guest.
• Should only allow users who are either Authenticated or Anonymous.

Addon Collections

• Should be named legibly.
• Should have all non-Admin Addons/Content Definitions hidden. These Addons/Content Definitions are exempt from naming standards.
• Should contain a link to the Help document.
• Should be set “system” if it should never display on Admin Navigator.

General Development

• Best practices used within general development would require code review and can not be incorporated into each test plan.

Browser Compatibility

We will use w3Schools.com to determine the current browsers. ON the Menu as Browser Statistics. Any browser with > 5% usage will be included by default. The client is welcome (encouraged) to include other browsers with appropriate labor requirements.

http://www.w3schools.com/browsers/browsers_stats.asp

The browsers supported will be specifically listed in all project requirements, stored in the project folder. The testing practices document will include a line item that says we test for browsers listed in the project requirements. We will create a new product under products and services to offer ongoing browser testing as a monthly service.

Design

Best practices are practices, not policies. They should be followed as a rule but are not required. (This means they should be followed unless there is a reason for each case) The goal of best practices is to develop habits that result is higher quality products. Include a brief summary of the practice, and an explanation with a reason why and a goal. General

• No inline script throughout the document body, script should either be referenced in the HEAD section or just before the end BODY tag in a single SCRIPT tag.
• All scripts/css/images should be referenced using absolute URLs, not relative.

CSS

• Styles used within body content (the content box) should not require wrappers outside the content box. For instance, an h3 within the content of the aboutUs page should never be styled with a class from the body tag, unless that tag is used universally through the site.
• Site templates should include a page of sample text as a style guide. Each line should show and describe all styles for use throughout the site.
• Use Shared Styles for all css, templates and addons.
• No absolute positioned elements.

Dynamic Menus

If a menu is to be populated dynamiclly, it should confirm to the following pattern.

<ul class="menu">
    <li class="menuItem active">
   	 <a href="#">Menu Item 1</a>
   	 <ul class="subMenu">
   		 <li class="subMenuItem">
   			 <a href="#">Sub Page 1</a>
   		 </li>
   		 <li class="subMenuItem">
   			 <a href="#">Sub Page 2</a>
   		 </li>
   		 <li class="subMenuItem">
   			 <a href="#">Sub Page 3</a>
   		 </li>
   	 </ul>
    </li>
    <li class="menuItem">
   	 <a href="#">Menu Item 2</a>
    </li>
<ul>

Email Design

• All email styles must be included in-line, never in a remote stylesheet.
• Email designs must render acceptably though our email test service, Litmus.com
• We must support all email clients with 5% marketshare, determined by the litmus.com site http;//www.emailClientMarketShare.com
• Folders that contain images, etc should be named to guarantee they are unique within the site. For instance, never user “image” or “img” or “styles”.

Site Performance Considerations

We follow the general guildlines and practices suggested by the Google Page Speed Insights Tool (https://developers.google.com/speed/pagespeed/insights/)

Security, IT and Hosting

See Google docs /PracticesPolicies for more information