021

Why front-end
development is
crucial for a
successful CMS
build.

Tips and best practices for HTML and CSS

development
Release Date: June 2010
Author: Fabien Doiron, Creative Technologist

1
WHY FRONT-END DEVELOPMENT IS CRUCIAL FOR A SUCCESSFUL CMS BUILD
TIPS AND BEST PRACTICES FOR HTML AND CSS DEVELOPMENT

Table of Contents
Introduction........................................................................................................................................................................... 3  
Gather the requirements....................................................................................................................................................... 4  
Development......................................................................................................................................................................... 7  
Conclusion .......................................................................................................................................................................... 16  
About non~linear creationss .............................................................................................................................................. 17  

2
WHY FRONT-END DEVELOPMENT IS CRUCIAL FOR A SUCCESSFUL CMS BUILD
TIPS AND BEST PRACTICES FOR HTML AND CSS DEVELOPMENT

Introduction
Coding effective templates for a content management system (CMS) driven website is often over looked and result in a poor
CMS build. The content of this document is backed with many years of experiences with various CMS and is intended to
share an insight on what can make the difference between success and failure. We want to share the expertise gained with
these numerous successes to help avoid common issues that arise.

HTML/CSS is the foundation of a website, and when done properly, allows content author to expand a site while maintaining
the look and feel.

HTML, which stands for HyperText Markup Language, is the predominant markup language for web pages. It provides a
means to create structured documents by denoting structural semantics for text such as headings, paragraphs, lists, links,
quotes and other items. - Wikipedia

CSS (Cascading Style Sheets) is used to separate content from the visual. It builds the look and feel of a website taking it
from flat design comps to functional pages. The best CMS developers will still run a high risk of failure without a proper HTML
foundation. It is like the worlds best carpenter trying to build a house without a solid foundation.

In the sections that follow, we will cover the two main phases of front-end development, along with some
best practices.

1. Gather the requirements

a. This ensures the front-end developer (developer in charge of creating the HTML and CSS) is fully aware of
the graphic designers’ vision as well as the CMS developers’ technical plan to help minimize the room for
error.
2. Development
a. HTML development
b. CSS development

3
WHY FRONT-END DEVELOPMENT IS CRUCIAL FOR A SUCCESSFUL CMS BUILD
TIPS AND BEST PRACTICES FOR HTML AND CSS DEVELOPMENT

Gather the requirements

A lot needs to be done during this phase to ensure the development matches the requirements. The front-end developer
(developer in charge of creating the HTML and CSS) must be in close contact with both the graphic designer and CMS
developer to understand their needs and ensure the HTML meets them.

Knowledge transfer with graphic designer / developer

During the knowledge transfer with the graphic designer, as a front-end developer you must understand the vision behind the
design and the functionality of all components. A lot of times, crucial errors are made simply because there was a
misunderstanding over the design. It is important to note that the final design will most likely not contain the same information
when the site launches. Over the course of a project life, the content may get out dated, the site architecture may get
tweaked, and for those reasons, the code needs to be as flexible as possible.

Checklist of items to review with the graphic designer:

1. What if the content grows? How is the content area and content blocks (navigation, sub navigation, header, footer,
etc.) flexible?
a. Unlike print design, website design needs to allow expansion and growth. Many factors can affect the
content and the design needs to accommodate these. A user can increase the browser font, navigation
could grow with time, and new content could be longer/shorter than the original content used.
- See figure 1.1 and figure 1.2

2. Are all the default HTML tags defined and consistent?

Content area was designed at a fixed height. The screen on the right shows the
content overlapping the section below instead of pushing the entire content down.
This means the content for each section is restricted.

Figure 1.1

4
WHY FRONT-END DEVELOPMENT IS CRUCIAL FOR A SUCCESSFUL CMS BUILD
TIPS AND BEST PRACTICES FOR HTML AND CSS DEVELOPMENT

Content area was designed to allow flexibility. In this example the font size was
scaled up and the content block grew. This allows the content to change and the
design to maintain the same look and feel intended.

Figure 1.2

Both designs are taken from CSS Zen Garden (http://www.csszengarden.com/)

Checklist of items to review with the developer:

1. Which areas are rich text?

a. The importance of knowing which areas will be Rich Text based is to ensure default HTML is used. This
reduces the margin for error when a content author is inserting content. More explanation to follow in the
HTML development section.

Browser support
Once the design and the functionality are understood, the next step is to know which browser support is needed. This can
affect the CSS portion because not all browsers support the same styles. Here’s a list of the most common browsers and the
statistics:

2010 IE8 IE7 IE6 Firefox Chrome Safari Opera

May 16.0% 9.1% 7.1% 46.9% 14.5% 3.5% 2.2%

April 16.2% 9.3% 7.9% 46.4% 13.6% 3.7% 2.2%

Stats taken from http://www.w3schools.com/browsers/browsers_stats.asp

While all browsers mildly render sites differently, IE6 is generally where a front-end developer will run into the most problems.
There are quite a few workarounds that will limit those headaches and these will be discussed later in the document.

5
WHY FRONT-END DEVELOPMENT IS CRUCIAL FOR A SUCCESSFUL CMS BUILD
TIPS AND BEST PRACTICES FOR HTML AND CSS DEVELOPMENT
Accessibility requirements
Accessibility falls into 2 main categories: people based
and technology based. On the people side, accessibility
involves a wide range of disabilities, including visual,
auditory, physical, speech, cognitive, language, learning,
and neurological disabilities. On the technical side it
involves the browser of choice, the Internet connection,
the hardware, and many more.
It can be frustrating to open a website, and not be able to
find the information you are looking. This could be the
result of a bad navigation, a bad design, poor choice of
words… Now for example purposes, imagine having to
navigate that same site if you had a visual impairment.
Taking a step back, the minimum requirements to
use the web are:
• An internet connection
• A web browser
However, when looking at the requirements for a
specific site, the list can grow significantly, you
may need:
• A high-speed internet connection
• A keyboard and/or mouse
• A minimum resolution (ex: 1024x768)
• A specific browser
• A specific plugin (Flash Player, PDF viewer …)
• JavaScript
• Great vision and/or lack of colour blindness
• And many more…
The World Wide Web Consortium (W3C) has a content
accessibility guide to follow in order to make web content
more accessible to people with disabilities.
(http://www.w3.org/TR/WCAG20/) Although following
these best practices will not guarantee full accessibility for
all disabilities, it will ensure the following common pitfalls
are addressed.
• Text alternatives for all non-text elements
• Distinguishable, proper use of
o Colour
o Contrast
o Text size
• Keyboard accessible
At the rate the web/technology is evolving, more people
meet many technological accessibility requirements every
day. However, there are still a significant percentage of
users that do not meet the average requirements such as
the latest browser version, the latest flash player… For
example, referring back to browser statistics table, Internet
Explorer is the browser of choice for around 33% of
viewers, with 8% being 2 versions behind. Reviewing
statistics for each project individually will provide vital
information on the targeted users, including browsers
used, plugins installed, whether JavaScript is enabled.
This information is vital in understanding the minimum
technology accessibility required. Understanding the W3C
accessibility guide is extremely helpful for statistics that
cannot be measured – such as blindness, vision
impairment etc.
6
WHY FRONT-END DEVELOPMENT IS CRUCIAL FOR A SUCCESSFUL CMS BUILD
TIPS AND BEST PRACTICES FOR HTML AND CSS DEVELOPMENT

Development
Once all the requirements have been noted and signed off, the development phase begins. Please note the content and
examples to follow are not intended as the only solution but simply as a set of best practices that we have developed over the
years. This section will be split into 2 phases: HTML development and CSS Development.

HTML Development
First note is HTML is based solely on markup. When coding the templates, a clean and ordered markup should be the priority.
The look and feel of the website should be controlled by CSS and only addressed at that phase.

DOCTYPE importance
By the HTML and XHTML standard, a DOCTYPE
(document type declaration) informs the validator the
version of (X)HTML used. This declaration must be present
at the very top of every page. It is a key component of
compliant web pages and your markup and CSS will not
validate without it.
DOCTYPES are also essential to the proper rendering of
web pages in compliant browsers. Using an incomplete or
outdated DOCTYPE, or none at all, will throw your
browsers into “Quirks” mode, where the browser assumes
you’ve written old-fashioned, invalid markup, and will try to
handle an (X)HTML document like older browsers from the
mid-to late '90s did.
We’ve recently made the transition into the HTML 5
DOCTYPE listed below.
<!DOCTYPE html>
Not only is it a lot simpler to remember than previous
DOCTYPES, it also renders the site in all browsers in
Standards mode eliminating a lot of the IE6 issues right off
the bat.
Two other main DOCTYPES were XHTML 1.0 Strict and
XHTML 1.0 Transitional with Strict being the ultimate goal.
XHTML 1.0 Strict:
<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-
strict.dtd">
XHTML 1.0 Transitional:
<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd>

Separate content and visuals

When investing a lot of time and money into CMS build,
the end result should be an easy to manage website for all
types of users. Whether a content update by a non-web
savvy content author or a design update by a designer.
Separating the content from the visuals will help achieve
this goal.
When starting the templates, the HTML should be built
based on content and not design. Proper HTML is
extremely flexible and will allow CSS to create the look and
feel required. A great reference is CSS Zen Garden
(www.csszengarden.com). The site is a showcase of
designs using the exact same HTML markup with only the
external CSS being different.
It is important to use the HTML tags the way they were
intended. Headings must be encoded as headings,
paragraphs as paragraphs, lists as lists and so on.

7
WHY FRONT-END DEVELOPMENT IS CRUCIAL FOR A SUCCESSFUL CMS BUILD
TIPS AND BEST PRACTICES FOR HTML AND CSS DEVELOPMENT

Compare the two examples below and while both pages contain the same copy, notice how much easier it is to scan a page
when the HTML is properly structured.

<div class=”container”>
<div class=”logo”><img src=”logo.gif” … /></div>
<div class=”tagline”>Tagline</div>
<div class=”content”>Lorem ipsum dolor</div>
</div>

<div class=”container”>
<img src=”logo.gif” … />
<h2>Tagline</h2>
<p>Lorem ipsum dolor</p>
</div>

Avoid unnecessary markup

Some designs are fairly complex and use a lot of visuals to
complement the content and will require more containers
than a normal site, but this goes back to the previous
point, where you build the HTML based on the content not
the design.
First, in order to avoid unnecessary markup, you need to
understand the difference between “block-level” elements
and “inline” elements.
Block-level elements such as p, table, h1 – h6, div… are
tags that generate a break line and are flexible for
containers. They have 5 spacing properties: height, width,
margin, border and padding.
Inline elements, such as span, a… are tags that do not
generate a break line and are not as flexible to be used as
containers.
Note: Block-level elements are not allowed inside an
inline element.

8
WHY FRONT-END DEVELOPMENT IS CRUCIAL FOR A SUCCESSFUL CMS BUILD
TIPS AND BEST PRACTICES FOR HTML AND CSS DEVELOPMENT

Take a look at the 3 code blocks below. All three can produce the same look, but notice the amount of
markup in each.

<div class="header">
<div class="hdr-logo">
<p><a href="/" title="Company Name">Company Name</a></p>
</div>
<div class="hdr-toolNav">
<ul>
<li><a href="/">Fran&ccedil;ais</a></li>
</ul>
</div>
</div>

<div class="header">
<p><a href="/" title="Company Name">Company Name</a></p>
<ul>
<li><a href="/">Fran&ccedil;ais</a></li>
</ul>
</div>

<p><a href="/" title="Company Name">Company Name</a></p>

<ul>
<li><a href="/">Fran&ccedil;ais</a></li>
</ul>

HTML best practices would suggest using code block
three, avoiding any unnecessary markup. A general rule of
thumb is: Only if there is more than one area inside a
section should it be wrapped in a container. In the
example above, there is a logo and navigation inside the
header area, wrapping them inside a container is a way to
group the sections.
In the first example, a div was used to wrap both the logo
and the navigation separately. Each of them is already a
block-level element (p, ul) meaning the div tags are
useless. All styles that would be applied to the div tag can
be applied to p and ul tags.
As for using too many div tags or any other markup,
classes and ids should also be limited. With any HTML
templates, even more so for CMS, all default tags should
be used as much as possible. The use of classes and ids
during the HTML development should be limited to
containers. Keeping classes to a minimum while building
the HTML adding them as necessary during the CSS
development can limit common issues.
This is extremely important for CMS builds because all
sections that are rich text based, will allow content authors
to use a WYSIWYG editor (What You See Is What You Get)
to update the content. If classes or ids are specified in the
content area, then in order for the content authors to keep
the look and feel intended, they will need to manually
insert these classes increasing the risk of brand and layout
guidelines not being followed. The simplest way around
this is to use the default tags, which will guarantee
consistency. If for any specific area, a default tag’s look
and feel is different than the default for the rest of the site,
inheritance should be use in the CSS.

9
WHY FRONT-END DEVELOPMENT IS CRUCIAL FOR A SUCCESSFUL CMS BUILD
TIPS AND BEST PRACTICES FOR HTML AND CSS DEVELOPMENT

Looking at the 2 examples below, both have the same outcome.

Option 1 achieves the new style by adding a class on the In Option 2, inheritance is used within CSS to specifically
element – “new-color”. This class would have to be target the tag, reducing the effort of the content author as
manually added by the content author increasing the risk well as the risk for error.
for error.

Content Authors are responsible for the styles CSS is responsible for the styles

h2.new-color { color: #FF0000; } .container-name h2 { color: #FF0000; }

<div class=”container-name”> <div class=”container-name”>

<!-- START of WYSIWYG --> <!-- START of WYSIWYG -->
<h2 class=”new-color”>Heading 2</h2> <h2>Heading 2</h2>
<!-- END of WYSIWYG --> <!-- END of WYSIWYG -->
</div> </div>

Note: Some div tags and classes will likely need to be added during the CSS phase to create some design visuals, or extra
padding, but for the HTML phase, less is more. This ensures that unnecessary markup will not be used.

Validate HTML
Modern browsers tend to do a really good job parsing even the worst HTML. However, not all errors are handled the same.
Using standard, valid markup is also one of the most reliable ways of getting your site ready the future updates of browsers.
When browsers release new versions, they tend to stay compatible with old standards, but that does not guarantee the
rendering of errors will remain the same.

The W3C offers an excellent online validation tool. (http://validator.w3.org/)

After gaining experience and building a variety of templates, and validating different source code, validating becomes more of
a tool for spotting mistakes. It plays the role of spell checker for code.

HTML checklist
Proper HTML templates should not require any special treatment in order to be CMS ready. Here’s a
checklist of items to cover:

1. DOCTYPE is declared
2. Div tags are limited to containers only
3. Limited classes or ids are defined aside from the containers
4. Image tags are used for CMS controlled images
5. Code validates against DOCTYPE declared

If the checklist is complete, time to move on to CSS development.

10
WHY FRONT-END DEVELOPMENT IS CRUCIAL FOR A SUCCESSFUL CMS BUILD
TIPS AND BEST PRACTICES FOR HTML AND CSS DEVELOPMENT

CSS Development
When starting the CSS development, the HTML templates should be properly developed and have as little markup as
possible. Now comes time to open the design comps and transfer the look and feel from PSD files to functional pages. The
end goal is to create user friendly CSS that is easy to maintain whether for the original developer or any new developers along
the way.

CSS reset
First CSS file included in all our HTML templates is a reset file.

The goal of a reset style sheet is to reduce browser inconsistencies in things like default line heights, margins and font sizes of
headings, and so on. It helps provide a consistent starting point for all browsers.

Doing a search online for “css reset file” will result in many different versions as a lot of developers have their own approach.
There is not one golden reset file; the main objective is to understand the reset file you choose and how it works for you.
The reset file we developed is based on a few existing ones with modifications to what we felt was required. On top of
resetting the margins, padding and on all elements, a few standard classes commonly used in every project were added. This
prevents inserting them and forces the same naming convention from site to site. These classes are used to clear floats, float
items, show/hide elements and align text (right, left and center).

Style the default tags

Once the reset file has been included, the default CSS file is created. The default CSS should contain all content tags to
ensure they get assigned with default values. Even if the pages that have been developed in HTML do not include a certain
element (blockquote, forms, for examples) they should still be styled. CMS are meant to allow flexibility and growth, meaning
any element could be added at any time. Defining a default style for each tag will prevent any brand issues to rise.

Defining all the default tags at first is also beneficial because even if a tag has a different look in a specific area, it may be able
to inherit styles from the default and only require minor adjustments. Setting the default font properties on the body tag will
ensure all elements start with the same base. This will allow greater flexible and ease in inheritance when the time comes.
Say the font-size for the footer paragraph needs to be smaller than the regular body text but the color and font are the same
as the body, rather than specifying all these styles again, we simply need to overwrite the font-size property.

use:
.footer p { font-size: .9em; }

instead of:
.footer p { font-family: Arial...; color: #666666; font-size: .9em; }

11
WHY FRONT-END DEVELOPMENT IS CRUCIAL FOR A SUCCESSFUL CMS BUILD
TIPS AND BEST PRACTICES FOR HTML AND CSS DEVELOPMENT

Organize in blocks
CSS files tend to grow extremely fast and can become hard to manage. The importance of organizing the CSS code
becomes evident when you must return to a file long after the work has been done. Although there is not one golden rule in
how to organize a CSS file, here’s a few helpful tips.

/* ========== DEFAULT CONTENT TAGS ========== */

all default content tags (html, body, h1-h6, p, a…)

/* ========== HEADER STYLES ========== */

all header styles

/* ========== MAIN NAVIGATION STYLES ========== */

all main navigation styles

… the rest of the content blocks (ex: Content, Sidebar, Footer…)…

/* ========== GENERIC STYLES ========== */

all generic styles aside from the default tags (ex: text alignment, text size, colors…)

By keeping all the styles into their separate content block, if an update to the header is required, it will be fast and efficient to
find the proper styles associated with the update required which could be very beneficial if multiple developers work on the
file.

Proper naming convention

The naming of classes and ids should not be taken lightly. Names should clearly indicate their purpose without being too
specific. A bad name can limit the flexibility should an update be required. Let’s assume we need a class to highlight
important text. The current look and feel may suggest bold red text. If we specifically name the class using these guidelines
(ex: class=“txt-red-bold”) and for any reason, the style needs to be updated to normal blue text, this can cause some
problems. The CSS can be updated and the “text-red-bold” can have the normal blue text applied to it; however the name is
very misleading and could result in confusion for content authors. A proper name to indicate the class purpose could have
been along the lines of “imp-txt” or “highlight-txt” allowing the flexibility to change the look and feel of the styles without losing
the meaning of the class.

We also keep a prefix on block specific styles (ex: hdr-logo). This not only indicates immediately where a style is applied, but
also helps prevent duplicate classes from being used.

Avoid hacks – if possible

With IE6 still in the picture, avoiding hacks can be extremely stressful and sometimes simply impossible. There are a lot of
debates on whether a conditional include should be inserted to include an IE6 specific CSS file to ensure valid CSS, I’m going
to argue the opposite. I like to keep all my CSS into 1 default file and avoid hacks at all cost. Understanding the limitations
and rendering differences in IE6 will prevent the use of common hacks.

12
WHY FRONT-END DEVELOPMENT IS CRUCIAL FOR A SUCCESSFUL CMS BUILD
TIPS AND BEST PRACTICES FOR HTML AND CSS DEVELOPMENT

The most common hacks as well as how to avoid them:

The Box Model (only in quirks mode – not an issue using the HTML5 DOCTYPE)

Problem: The CSS box model defines the width and height of a box created with CSS. If IE6 renders using quirks mode the
box model will be rendered differently than other browsers. The box model consists of the width, height, padding, margin and
border properties. By default, the width or height of a box is calculated by adding the width/height with the padding and
borders. However, in quirks mode, IE6 will render the box the width of the width property and include the padding and border
within this width.

Say we have a div with the following properties:

- width: 300px;
- border: 35px;
- padding: 25px;

By default the width would be:

300 + 70 (35px border on each side) + 50 (25px padding on each side) = 420px;
However, in quirks mode: width = 300px;

Fixes/Workarounds:
An easy way to avoid this issue; never apply a width with borders/padding and vice versa. By following this guideline, there is
no need to worry about the box model rendering differently in different browsers. If a container needs both a width and
borders/padding, and it can’t be included on an element inside the container, adding another div is the easiest solution.

<div id=”content”>
<div class=”ctn-bounds”>
…
</div>
</div>

13
WHY FRONT-END DEVELOPMENT IS CRUCIAL FOR A SUCCESSFUL CMS BUILD
TIPS AND BEST PRACTICES FOR HTML AND CSS DEVELOPMENT

Double Margin Bug

Problem: Most of the time (yes – only sometimes) if a margin is applied to a floated element, it will double the value often
causing major alignment issues.

Fixes/Workarounds:
Add display: inline to the element and it’s fixed.

Transparent PNG
Problem: The main uses for transparent PNG are generally for overlay images with filters (ex: shadow, blur, outer glow…).
These types of filter require some pixels to be less than 100% opaque. Bottom line, IE6 simply does not support PNG alpha
transparency.

Fixes/Workarounds:
1. The easiest fix is to ensure the design does not use any elements that require transparency. This does not mean that
shadows can’t be used, but they should be used appropriately. If a transparent element is used on a solid
background color, the background color can be cut with the image and prevent any issues.
2. If method 1 is not an option, the second recommended fix is to use a GIF image and do the best to optimize the
transparency area as best as possible. This method will require a hack to ensure only IE6 uses the GIF while other
browsers use the intended PNG. Using minor hacks when necessary without having a conditional include. Here’s
what the CSS would look like.

.className
{
background: url(transparent-image.png); /* All Browsers /
_background: url(transparent-image.gif); /* IE6- */
}

The underscore before a CSS property is a hack ignored by modern browser but read by IE6-. The underscore will
cause a validation error, but when compared to the amount of extra work to include a conditional statement and an
extra CSS file for 1 style, it is strongly debatable. If there were many instance required of this hack, then the argument
for a separate stylesheet could become debatable.
3. If neither option 1 nor 2 can be used, Microsoft offers a solution using a filter called AlphaImageLoader. A major issue
with this method is the inability to tile or position the image (if used as a background). A workaround for this problem
is to create an extremely large image to ensure no matter how high or wide the area gets, the image will never get
cut. Downfall of this method is file size tend to be fairly large. Another issue with this method is the
AlphaImageLoader is JavaScript based which a user may have disabled.

Validate CSS
Validating the CSS is often overlooked or overrated. It’s debatable whether or not it is an essential. I like to run my CSS code
through a validation more as a check than a must. It can point out missing semi colons, typos and other minor errors that can
cause huge rendering issues. At the rare occasion where I do need to use hacks, I know beforehand that my CSS file will not
validate, however I still check to make sure the rest of the code is properly written.

14
WHY FRONT-END DEVELOPMENT IS CRUCIAL FOR A SUCCESSFUL CMS BUILD
TIPS AND BEST PRACTICES FOR HTML AND CSS DEVELOPMENT

CSS checklist
Here’s a checklist of items to cover:

1. CSS reset file is included

2. Default CSS file is well organized
3. All default tags have been styled
4. A proper naming convention has been followed
5. Hacks have been avoided
6. CSS has been validated

15
WHY FRONT-END DEVELOPMENT IS CRUCIAL FOR A SUCCESSFUL CMS BUILD
TIPS AND BEST PRACTICES FOR HTML AND CSS DEVELOPMENT

Conclusion
Information from this paper covers some of our best practices, which are backed up by numerous successful CMS launches.
It is not intended to be perceived as the only way of building the foundation but more as a sort of cheat sheet in avoiding
common pitfalls.

Websites will continuously expand through its duration and the importance of a solid foundation begins to surface more and
more. The end goal is to ensure existing content can be edited, new content and new sections can be added all the while
maintaining consistency with the original look and feel designed. This adds value to a company’s brand and provides the
visitor with a consistent experience throughout the site.

We hope you have found this document useful as you move forward with your CMS deployments. NLC has a proven track
record of creating highly successful websites. If you are still struggling with building your foundation, feel free to reach out to
us – we’d be delighted to hear from you. You can reach us at design@nonlinear.ca or 613.241.2067. You will also find
additional assistance in NLC’s every expanding library of whitepapers at http://www.nonlinear.ca/pages/whitepapers.htm.

The NLC Performance Framework
A pragmatic guide to planning online business initiatives
Choosing a Web Content Management System
The fundamental truths about CMS selection and
implementation projects
Effective Visual Design Strategy for CMS
Overcoming the 7 Main Challenges to Effective Visual
Design for CMS-Driven Websites
The Non-Technical Manager's Guide to
Successful Google Analytics
Gathering website intelligence
Best Practices for Building Your CMS
Architecture
A proven best practices approach to content architecture
development
Planning for Success: Best Practices in CMS
Gover nance
Decisions to make before you implement a web content
management solution
SEO and CMS: Implementing Best Practices
Embedding Search Engine Optimization tactics during a
CMS deployment
Six T ips for Delivering Faceted Navigation within
a CMS-Driven Website

16
WHY FRONT-END DEVELOPMENT IS CRUCIAL FOR A SUCCESSFUL CMS BUILD
TIPS AND BEST PRACTICES FOR HTML AND CSS DEVELOPMENT
About non~linear creations
non~linear creations (NLC) provides e-business consulting
services to an international clientele. Since 1995, we have
helped our clients leverage the power of Internet technology
to achieve tangible business benefits.
NLC leads seven Solutions Groups
Our Business Performance Group provides services in
strategic consulting, information architecture, web analytics
and content governance.
Our Enterprise Content Management Group has world-
class proficiency in the technical planning and deployment
of web content management systems, document
management and records management solutions.
Our Gold-Certified Microsoft Solutions Group specializes
in successful implementation of Microsoft Office SharePoint
Server 2007, Microsoft Commerce Server and Microsoft
Search solutions.
Our Enterprise Search Group partners with search
vendors such as Google, Microsoft and Endeca to ensure
information is effectively stored and easy to find—both
inside and outside the enterprise.
Reaching non~linear creations
Toronto Office Ottawa Office
info@nonlinear.ca info@nonlinear.ca
416.203.2997 613.241.2067
524 Front St. West, Suite 200 987A Wellington St., Suite 201
Toronto, Ontario, Canada Ottawa, Ontario, Canada
M5V 1B8 K1Y 2Y1
Our Custom Application Development and Integration
Group builds custom solutions when off-the-shelf offerings
aren’t sufficient for an organization’s business needs. This
group also specializes in legacy integration projects.
Our Digital Marketing Group provides services in organic
search optimization, pay-per-click search management,
email management and social marketing.
Our Design and Multimedia Group continues to win
awards for their high impact online design projects, which
achieve the goal of compelling design without sacrificing
functionality and ease of navigation.
Each Solutions Group leverages proven methodologies and
extensive technology partnerships to deliver effective,
individualized solutions that satisfy customers worldwide.
Visit our website at www.nonlinear.ca to learn more about
the results we’ve achieved for a number of high-profile
clients.
Calgary Office New York Office
info@nonlinear.ca info@nonlinear.ca
1.403.444.5964 1.917.368.8000
#1000, 888-3rd St SW The Chrysler Centre
Bankers Hall, West Tower 405 Lexington Ave., 26th Fl.
Calgary, Alberta, Canada New York, NY 10174
T2P 5C5
17