Difference between revisions of "Contensive Best Practice Guide"

From Contensive Wiki
Jump to: navigation, search
(Addons)
Line 3: Line 3:
 
==Software Development==
 
==Software Development==
 
===Addons===
 
===Addons===
* Should be named legibly.
+
* 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 be contained within a Collection.
* Should have Field Help for all non-standard fields.
 
 
* Should have Presentation set (Tool/Report/Setting/Addon).
 
* Should have Presentation set (Tool/Report/Setting/Addon).
 
* Should populate name fields in all records that are created.
 
* Should populate name fields in all records that are created.
* Should be done with Layouts.
+
* Public facing Html should be generation using layouts records and/or html file.
* Should handle visit timeouts gracefully, returning users to the beginning of the process with an error message.
+
* 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===
 
===Logins===

Revision as of 14:42, 22 July 2015

This page includes our best practices guidelines.

Website Patterns

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

Security, IT and Hosting

See Google docs /PracticesPolicies for more information