Difference between revisions of "Contensive Best Practice Guide"

From Contensive Wiki
Jump to: navigation, search
(→‎Software Development)
(→‎Website Patterns)
 
(13 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
This page includes our best practices guidelines.
 
This page includes our best practices guidelines.
 
==Website Patterns==
 
==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==
 
==Software Development==
 
===Addons===
 
===Addons===
−
Should be named legibly.
+
* RemoteMethod addons should be camel-case with no spaces.
−
Should be contained within a Collection.
+
* non-RemoteMethod addons should be treated as public facing, named as captions with initial upper case.
−
Should have Field Help for all non-standard fields.
+
* Should be contained within a Collection.
−
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===
−
Should focus on the username/email field.
+
* Should focus on the username/email field.
−
Should tab to password field.
+
* Should tab to password field.
−
Should submit on pressing the Enter key or SUBMIT button.
+
* Should submit on pressing the Enter key or SUBMIT button.
−
Record Lists
+
* Record Lists
−
Should use layouts and repeaters.
+
* Should use layouts and repeaters.
−
Should paginate.
+
* Should paginate.
−
Should contain pagination menu top and bottom.
+
* Should contain pagination menu top and bottom.
 +
 
 
===Forms===
 
===Forms===
−
Should focus on first field.
+
* Should focus on first field.
−
Should tab in a logical order.
+
* Should tab in a logical order.
−
Should not show default name Guest.
+
* Should not show default name Guest.
−
Should only allow users who are either Authenticated or Anonymous.
+
* Should only allow users who are either Authenticated or Anonymous.
−
===Collections===
+
 
−
Should be named legibly.
+
===Addon Collections===
−
Should have all non-Admin Addons/Content Definitions hidden. These Addons/Content Definitions are exempt from naming standards.
+
* Should be named legibly.
−
Should contain a link to the Help document.
+
* Should have all non-Admin Addons/Content Definitions hidden. These Addons/Content Definitions are exempt from naming standards.
−
Should be set “system” if it should never display on Admin Navigator.
+
* Should contain a link to the Help document.
 +
* Should be set “system” if it should never display on Admin Navigator.
  
 
===General Development===
 
===General Development===
−
Best practices used within general development would require code review and can not be incorporated into each test plan.
+
* Best practices used within general development would require code review and can not be incorporated into each test plan.
−
Browser Compatibility
+
===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.
 
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.
  
Line 40: Line 58:
 
The testing practices document will include a line item that says we test for browsers listed in the project requirements.
 
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.
 
We will create a new product under products and services to offer ongoing browser testing as a monthly service.
−
Addons
 
−
Should be contained within a Collection.
 
−
Should load within a reasonable time.
 
−
Should prefix all non-standard folders stored in the wwwroot.
 
−
Should prevent duplicate users.
 
−
Collections
 
−
Should contain all files/records necessary for its addons to function, no additional work should be needed to deploy
 
−
Should be set “Block Navigator Node” if only for developers.
 
−
Each collection represents no more than one Visual Studio Project.
 
−
Coding Practices
 
−
Variables and methods should be camelCase.
 
−
Variables and methods must be named consistent with their meaning
 
−
Wherever possible, use methods within the development namespace
 
−
If third party code is needed, preference should be given to nuget packages
 
−
Should prefix all non-standard CSS declarations.
 
−
Should use jQuery alias rather than $.
 
−
Variables should be prefixed if used globally.
 
−
Methods should be prefixed if used globally.
 
−
Referencing Content
 
−
Should be referred to by GUID not name.
 
−
Should contain a constant and descriptive for each GUID.
 
−
Should not use shared Content Definitions/Tables between different features.
 
−
Should be contained in Content Definitions.
 
−
Should prefix all table names.
 
−
Logging
 
−
Should be maintain programmatically if used.
 
−
Add only errors to the /Logs/Tracexxx.log
 
−
For logging helpful information, or custom errors, use a subfolder of /logs
 
  
 
==Design==
 
==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.
 +
<pre>
 +
<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>
 +
</pre>
 +
 +
 +
===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

Latest revision as of 15:00, 22 July 2015

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

Retrieved from "http://wiki.kmacloud.net/index.php?title=Contensive_Best_Practice_Guide&oldid=913"