The Common Web Design

Documentation & Guidelines

Version 2.3 Dallas Dhu

Online Services Team

ICT Services
University of Lincoln
 v2.3 Dallas Dhu

Contents
Contacts! 2
The CWD! 2

Help!! 2

About the Common Web Design! 3

CWD in 5 Minutes! 5

Customising the CWD! 7

Header Navigation! 7

The Banner! 7

Site Navigation! 9

More Customisation! 9

Getting It Wrong (And What We Do)! 10

Writing Style ! 11
Semantics 101! 11

Writing for the Web! 13

Recommended Style Guide! 15

Designing Pages! 17
Columns & Layout: The Grid! 17

Floating Content! 17

Forms & Buttons! 17

Icons! 18

Behind The Scenes! 21

CWD Assets! 21

Frameworks! 21

Web Standards! 22

1
The Common Web Design Documentation

Contacts
The CWD
The Common Web Design is developed by the Online Services Team, and is
managed by Alex Bilbie and Nick Jackson. You should direct any questions,
problems or change requests to either of these people.

Alex Bilbie
abilbie@lincoln.ac.uk
01522 886570

Nick Jackson
nijackson@lincoln.ac.uk
01522 886570

Help!
If you have issues with or need help using an online service you should contact the
IT Support Desk who will be able to help you solve your problems. Note that the
helpdesk cannot provide support for CWD implementations.

IT Support Desk
helpdesk@lincoln.ac.uk
01522 886500

2
 v2.3 Dallas Dhu

About the Common Web Design

The Common Web Design is an attempt to standardise the Universityʼs online
services under a common look and feel. It consists of a new, modern design built
from the ground up around established usability guidelines to cater to the needs of
current and future web users, as well as a set of pre-built page elements and a
comprehensive guide to writing for the web.
Using a single design and style for websites within the University helps to improve
the user experience through consistency in how a user interacts with the website as
well as providing a framework to dramatically improve the speed and reliability of
sites, their appearance and functionality across multiple browsers, their usability and
their accessibility.
Alongside this, the CWD intelligently adjusts the appearance of websites for small-
screen and mobile devices and for print, as well as dynamically turning the more
advanced features of sites on and off based on the ability of web browsers to use
them. Together this makes websites using the CWD accessible on the widest
possible number of devices.
The CWD is built on the Blueprint CSS 1 and jQuery 2 frameworks for page layout and
JavaScript functionality, uses the jQuery UI3 library to provide advanced user
interface elements, and integrates the Modernizr4 library to improve its appearance
on compatible browsers.

1 http://www.blueprintcss.org/
2 http://jquery.com/
3 http://jqueryui.com/
4 http://www.modernizr.com/

3
 v2.3 Dallas Dhu

CWD in 5 Minutes
This is a very quick guide to getting started with the CWD. Just follow the steps.

Get The Code

First you need to get the CWD code. We always keep an example page online for
you to copy from, so just visit it and copy all of the code into your web editor of
choice.
http://cwd.online.lincoln.ac.uk/2.3/examples/cwd.html

Customise The Metadata

Next you need to customise the metadata of your page. This will remain the same
throughout your entire web site, so you need to get it right.
Find the Title Block editable section near the beginning of the page and change
the title, description, application name and application URL sections. These refer to
your site as a whole and shouldnʼt change on a page-by-page basis.

Customise The Banner

Further down the page you will find the Customise CSS editable section. This is
where you specify the banner options you find later in this documentation in the
Customising The Banner section.
Note that you must not change the addresses of any of the CSS files or make a local
copy. It is important that all the CWD files are stored centrally on our servers, since
we actually change how the CSS is being output based on the userʼs browser. If you
absolutely need a local copy (we donʼt think there should ever be a time that you
would) then you must let us know so that we can make sure you are using the correct
files.

Add Custom CSS

Just underneath the Customise CSS section youʼll find the Site CSS editable. In
here you can specify the location of your site-specific CSS files (if any). Remember
that itʼs against the guidelines to override any of the CWD styles – this file is for you
to add any specific styling which you need for your own elements.

Adjust The Header Navigation

The Header Navigation Block editable section is where you can alter the
header navigation. This is reserved for University-wide links, site functions and the
universal search bar. Itʼs unlikely that youʼll need to change this section, but if you do

5
The Common Web Design Documentation

then you should check the Customising the Header Navigation documentation for the
rules regarding this area.

Add Your Site Title

Change the Page Title section to the same as the <title> element you set in
the Metadata section, making sure to keep the <h1> and </h1> tags intact. This is
the text which will appear on the banner (unless you have disabled that option).

Add Site Navigation

Change the Main Navigation Block to reflect your siteʼs top-level sections by
adding new <li> items to the list.

If you need it you can also edit the Sub Navigation Block. This is useful for
splitting your site into logical sections, as the sub navigation can change on a page-
by-page basis. If you donʼt need it you can delete the block.

Add Your Content

foo

6
 v2.3 Dallas Dhu

Customising the CWD

The CWD is a very flexible design which offers the ability to modify several sections
to better suit your site. This documentation will walk you through how to make those
changes, as well as what you can and canʼt do.

Header Navigation
The header navigation represents key, universal functionality which sites share such
as:

• A link back to the corporate home

• A link to contact information for the site

• Help or about pages
• Sign in/out links

• Links to admin pages

• Universal search
Generally speaking you should not put any links in the header navigation which do
not fall under one of these categories. It is important that users know both what to
expect in this area, and more importantly that the header navigation is where links to
those resources and tools will be on any site.
You must not remove the Lincoln Home item in this navigation (returns the user to the
corporate home page), and you must not remove the Universal Content element,
which is responsible for handling dynamic services such as Universal Search and
Messaging.

The Banner

The site banner is the strongest element of branding available to your site within the
CWD. It should reflect your siteʼs focus, and be distinct enough that your site can
easily be identified using the banner. In most cases this is done by specifying a
banner background image which relates to the siteʼs content or existing branding.

7
The Common Web Design Documentation

These options are added to the cwd.php CSS file as a standard HTTP query string,
for example cwd.php?b_hue=red&b_textbg=0.5. You can use multiple options
at once, and do not need to specify every option (just the ones you change from the
default).

Banner Background

Option Name b_bg

Values URLencoded image address

Default None

Specify the urlencoded location of the background image for the page banner. This
must be no smaller than 950px wide by 150px high.
If no image is specified, the banner background will be a gradient in line with your
b_hue setting. It is strongly recommended that you specify a banner background.

The banner background must be the same for all pages on a site, except for where
the header image is dynamically generated of as part of an image rotation. In these
cases, the images must clearly follow the same style.

Banner Text Visibility

Option Name b_text

Values on, off

Default on

Set whether the banner text and text background should be visible or not. For most
sites this will be left on – it should only be turned off if the banner image already
includes the siteʼs title (for example making use of a logo or specific branding style).
In these cases you should ensure the siteʼs title is towards the right hand side of the
banner to avoid the Universityʼs logo.

Banner Text Background

Option Name b_textbg

Values off, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9

Default 0.2

The opacity of the text background shading, where off is completely transparent and
0.9 is 90% opaque.

8
 v2.3 Dallas Dhu

Banner Text Colour

Option Name b_textcol

Values black, white

Default white

Change the colour of the text in the banner to either black or white. In most cases
this wonʼt need to be changed as the text background will help make the default
white text visible, however you may choose to use a light background image with no
text background in which case switching the text to black is important for visibility.

Banner Hue

Option Name b_hue

Values red, blue, orange, yellow, green, pink

Default blue

Set the hue of the banner background. Where you are not specifying a b_bg image
this can be used to add a more unique appearance to your site.

Site Navigation
A more detailed overview of this navigation is coming soon.

More Customisation
A common question is “can I change the colour/size/shape/position/font of the
header/footer/logo/text/banner/links/menu?”. The answer in these cases is almost
certainly “no”, as it would defeat the purpose of a common design. Customisation of
the page appearance should be limited to the banner using the above options and
positioning of elements within the main body.

In addition to this, you must not use your own CSS or inline styling to do anything
other than style elements you have added yourself. We make frequent, small
changes to elements in the CWD to improve accessibility and readability and often
these changes will clash with those you have made. In particular you must not
change any of the font sizes, padding, line-height, weight or other styles in standard
elements such as <p> or <h3>.

9
The Common Web Design Documentation

Getting It Wrong (And What We Do)

We are reasonably flexible with regards to the layout and content of the CWD,
however to enforce the universal appearance and behaviour of the site we have a
variety of automatic checks which monitor sites using the CWD to make sure they
are in line with the guidelines and rules regarding its use. We also perform a few
health checks on your site as a matter of course, so we can spot ways of making it
faster or fixing the odd glitch even before you knew something was wrong.

Generally speaking if we are alerted to a problem with your site we will contact you to
discuss exactly what is wrong, and how to resolve it. Weʼre friendly people and weʼd
rather help make sure that youʼre using the CWD properly than tell you off for using it
wrongly.
However, should you continue to ignore the guidelines and rules regarding the CWD
after us getting in touch, or if weʼre unable to contact you, we do have the right to
disable the styles and frameworks for your site. This will always be a last resort, but
misuse of the CWD will only weaken its position as a standardised, reliable and
universal approach to web design throughout the University.

What gives you the right to do that?

At the moment the CWD is a product of the Online Services Team and the
Universityʼs Web Team, and was developed in line with industry best practices to look
at possible new designs for University services. Although weʼre letting anybody use
the CWD to develop University websites it is still ultimately owned and operated by
the Online Services Team and we donʼt want the coherence of our own sites and
services to be damaged by abuse of the web design. Itʼs not a stance that we like
taking, but it is unfortunately necessary.

10
 v2.3 Dallas Dhu

Writing Style
An important part of designing for the web is making the style of your writing
consistent and easily understood. This helps both people and computers to make
sense of the page, helps make searching more efficient and is generally held as
good practice.

Semantics 101
Web browsers cannot understand web pages as humans read them – they cannot
interpret information such as the visual layout of a page, colours or bold text.
Whereas to a full-sighted human the meaning might be clear it might not be to a web
browser or when listened to through a screen reader. For this reason you need to be
aware of semantics and the correct way of providing semantic information when
creating web pages.
Using well-formed semantics is an easy way to make your page more
understandable to web browsers (including screen readers and other accessibility
tools), easier for you to manage because of cleaner code, and better formatted using
the CWD.

Detailed information on how to achieve a semantic layout from a technical point of

view is not covered in this documentation, but is a basic part of a web design course.
If you need to attend a web design or HTML training course you should first check to
see if there is an available training course for you. If not, or if you need quick help in
understanding semantics, then you can contact us using the details on page 2.
Weʼve included a few basic pointers on common mistakes, but if youʼre planning
serious web design (rather than just building writing content for a platform like Blogs
or Documents) then you need to attend at least a basic course in HTML.

Structure Is Everything
Your web page should be completely understandable if all formatting, layout and
JavaScript is removed. A lot of web browsers offer options or toolkits which let you
disable specific features of web pages to see how they look.
As a basic rule, you should never rely on size, boldness, italics, colour or position
alone to add meaning to something. Instead you should always use semantic tags
(weʼve given a basic overview of some common ones below) to add meaning to your
page. Using a semantic tag will often add its own formatting to the text so that it can
easily be understood by people reading the page (for example by making headings
bigger), but it also adds a second layer of meaning to the page which helps
computers make more sense of it, helping things such as screen readers add
emphasis in the right place or search engines to pick out relevant content.

11
The Common Web Design Documentation

Page Headings
Page headings in HTML are made using the elements <h1> through <h6>, with
<h1> being the biggest and most important.

Heading elements are used to break the page up into logical sections, which must
(according to the HTML specification) be arranged hierarchically. For instance, you
cannot put a <h5> element underneath a <h3> element since this makes no logical
sense. An example of how to use headings is as follows

<h1>Page Title</h1>
<p>This is an introduction to the page.</p>
<h2>Heading 2</h2>
<p>This is some text under the heading.</p>
<h3>Heading 3</h3>
<p>You can nest headings underneath each other.</p>
<h2>Heading 2 (Again)</h2>
<p>You can also put as many of h2 and below as you want.</p>

As mentioned in the example, you can use as many of <h2> and below as you want
but there can only ever be one <h1> on a page, and it is usually reserved for the site
title. The CWD uses the <h1> tag for the text in the banner, so you should never be
adding a <h1> element to your page.

Bold and Italic

There are two ways of making text appear bold or italic in a web page, and they are
amongst the most frequently confused pieces of semantic markup. This is a quick
overview of the two ways of doing each, and which you should use.

Bold
When making bold text you need to decide if the boldness is purely presentational
(for example in the name of an article) or if it puts a particular emphasis on the word
(such as giving a firm instruction). If the boldness is presentational you should use
<b> as the tag, which will make the text appear in bold but nothing else. If you are
placing emphasis on the word you should use the <strong> tag, which will make
the text appear in bold and also tell software such as screen readers that it needs to
be emphasised in speech.

Italic
When making italicised text you need to decide if the italics are purely presentational
(for example in the name of a book) or if it puts a particular emphasis on the word
(such as giving a firm instruction). If the italics are presentational you should use <i>
as the tag, which will make the text appear in italics but nothing else. If you are
placing emphasis on the word you should use the <em> tag, which will make the text

12
 v2.3 Dallas Dhu

appear in italics and also tell software such as screen readers that it needs to be
emphasised in speech.

Images
Images on the web are a fact of life for most people, but you must consider how the
web page will appear to those who cannot see the images and must have them
described to them. The <img> tag provides two attributes you can set to help in this,
alt and title.

The alt attribute in general terms should always be set for an image unless it exists
purely for the design of the page. For example, in the CWD template we do not set
the alt attribute for any of our images since they do not form part of the content of
the page and are irrelevant to anybody reading that content. By contrast any images
we put in the content of a page always have the alt attribute set. Alt should
contain a description of the image which makes sense if the image is removed. Some
times this is a simple matter of describing the contents of the images, but other times
you must describe what information the image is actually showing.

<img alt=”The University of Lincoln’s Main Admin Building,

viewed across the Brayford Pool”>

<img alt=”The SafeCom box is located on the right hand side of

the printer”>

Title, on the other hand, should be treated much as a caption. In all standard
compliant web browsers the title attribute will be shown as a floating tooltip when
you hover your mouse over an image.

<img title=”The University of Lincoln”>

<img title=”Printer showing a SafeCom box”>

Writing for the Web

Writing content for the web is very different from writing for print. Readers have a
shorter attention span, and are more used to moving between different pages to find
the information they need. Readers can also come from all over the world, and may
have different levels of English. It is important that your writing is clear and easily
understood.
For these reasons all web pages using the CWD should follow these guidelines.

13
The Common Web Design Documentation

Avoid jargon and specialist terms wherever possible.

If people donʼt understand words, they will give up on reading a page. If you can, find
a more easily understood way of saying something. If you canʼt, include an
explanation.
A certain amount of common sense needs to be used when applying this guideline. If
the page is a technical guide or specifically aimed at an audience you will be able to
adjust how much you simplify a page.

Donʼt fill sentences with unnecessary words.

Long words wonʼt impress people on the web, they will just make people go
elsewhere. Say what you need to say, nothing more.

Always double-check your spelling and grammar.

Writing with misspellings or poor grammar is hard to understand. This is especially
true on the web where people may not speak English as a first language.
Poor spelling also makes a web page look sloppily put together. Web pages should
always be proof-read before publishing.

Avoid relative times like “next Tuesday” or “tonight”, unless the

content is posted with a date.
Web pages arenʼt updated as often as people like to think they are. Relative times
can make a page look out of date very easily, so donʼt use them unless the content is
clearly from a particular date (like a blog post or news item).

Clarify acronyms.
It is very easy – especially when writing from within somewhere like a university – to
use specialist acronyms which people may not understand. As with jargon, explain
uncommon abbreviations and acronyms.

Be concise.
If you can say something in fewer words do so. People browsing the web have less
patience than people reading a printed page.

Avoid simile and metaphor.

Similes and metaphors can be easily misunderstood by people who donʼt speak
English as their first language. Avoid them if you can.

14
 v2.3 Dallas Dhu

Recommended Style Guide

We strongly recommend following the Yahoo! Style Guide 5 when writing content for
the web. This covers issues such as search-engine optimisation, the correct form of
words, guides to punctuation and capitalisation and more. A reference copy of this
style guide is available in the GCW reference collection, and many of the guideʼs
articles and tutorials are available online.
Following a style guide helps to ensure that all of the Universityʼs web pages are
consistent, reducing confusion of end users and making them seem more
professional.
If youʼre unsure of a writing style youʼre using with the CWD then you should contact
us and ask for clarification.

5 http://styleguide.yahoo.com/

15
 v2.3 Dallas Dhu

Designing Pages
Columns & Layout: The Grid
Help on how to use the grid content is coming soon.

The Sidebar
Details of the sidebar and how to use it are coming soon.

Floating Content
Help on how to float content is coming soon.

Forms & Buttons

We have provided several styles to make form elements and buttons appear more
consistent and visually pleasing. You should always use these styles where available.

Text Input
Adding the appropriate styling to text inputs is very simple, all you need to do is add
the text class to the element. This styling is also valid for other text-based inputs
such as password.

<input type=”text” class=”text”>

When creating text inputs you should also consider the use of HTML5 input types
such as email and url. These can be used by the browser to improve the
behaviour of your web page, for example by adding more appropriate input methods,
clearer prompting or in-browser validation.

Buttons
There are two ways of adding buttons to your web page, and which method is most
appropriate will change depending on what you are trying to achieve.
The first is to add the class button to the element you want to appear like a button.
Generally speaking this is limited to <button> and <a> elements, for example:

<button class=”button”>
<a href=”#” class=”button”>

17
The Common Web Design Documentation

The second, more complex method is to use the jQuery UI .button() function. This
allows for more complicated functionality such as adding icons to buttons (see the
section on icons) and control of states such as enabled and disabled. For more
information on this, please check the jQuery UI documentation.

Icons
The jQuery UI library which the CWD uses provides a large range of icons which can
be used to help prompt users. These icons can be used on their own or – more likely
– as part of buttons alongside helper text.

You should always use a provided icon (if one exists which meets your needs)
instead of creating your own, as these are sent to users in a very optimised way and
match the existing appearance and colour scheme of the CWD.
For more information on using icons please see the jQuery UI documentation.

18
v2.3 Dallas Dhu

19
 v2.3 Dallas Dhu

Behind The Scenes

This section covers the CWDʼs approach to the more technical aspects of building a
site.

CWD Assets
All of the CWDʼs assets – including images, scripts and CSS files – are stored in a
centrally managed location. This is designed to provide a robust and reliable
distribution of the files which make up the CWD, as well as allow the CWD to be
changed once to update all sites using it.

You should not, under any circumstances, make local copies of CWD assets for your
own site without first checking with the Online Services Team.

Frameworks
We have made four frameworks available to you, to make development faster and
easier. These frameworks abstract out a lot of the idiosyncrasies of individual web
browsers, provide a uniform and easily understood way of building web applications,
enforce uniformity and speed up the performance of sites. Wherever possible you
should use these frameworks instead of building your own alternative.
The CWD maintains these frameworks at the latest version as part of its centrally
managed assets; you do not need to worry about upgrading them as this will happen
automatically.

Blueprint: CSS
Blueprint is a CSS framework which ensures consistency across multiple browsers.
The only part of Blueprint which you really need to worry about is the grid, which is
explained in more detail in the Designing Pages section.

jQuery: JavaScript
JavaScript is an integral part of web applications, which is why we have included the
popular jQuery library in the CWD. The full scope of jQuery is beyond this
documentation to explain, but it includes optimised and browser-independent
methods for achieving complex behaviours, including the use of AJAX.
You should use jQuery functions wherever possible to help you develop web
applications, since they are regularly updated to include new optimisations, bug fixes
and browser compatibility fixes which are then automatically included in your
application.

21
The Common Web Design Documentation

For more information on the available functions, including examples and tutorials,
please check the jQuery documentation6 .

jQuery UI: User Interface

jQuery UI builds on top of the jQuery framework to offer rich user interface elements.
For more information on the available functions and widgets, including examples and
tuturials, please check the jQuery UI documentation7 .

Nucleus
Nucleus is a JavaScript library which provides a limited range of information about
the current userʼs role within the University, derived from the Nucleus APIs.
At the moment this library is under development and is not available for public use,
but will include functions to find information such as a userʼs physical location on
campus, their faculty or department, presence information and so-on using browser-
based methods better suited to web application development.

Web Standards
The Common Web Design is built around the latest web standards, and is carefully
designed to degrade gracefully on older browsers and Internet Explorer. These
standards make sure that web pages render consistently across different browsers
and operating systems (including mobile devices), and also that where a particular
feature is unsupported it is done so elegantly by maintaining the page readability.

When youʼre writing your own site using the CWD you should always follow the latest
relevant standards.

HTML5
HTML5 represents the next generation of the language which makes up web pages.
It allows for much easier development of web-based applications and replaces many
proprietary extensions such as Google Gears and Adobe Flash. Since HTML5 is built
on top of HTML 4.01 older browsers will simply ignore the new markup which they
donʼt understand, and will behave using the older standards. New browsers,
however, benefit from an improved user experience and optimised application
behaviour.
A good way to explore the possibilities of HTML5 is to look at Dive Into HTML5 8,
which explains many of the basic enhancements such as improvements to forms as
well as more advanced features such as geolocation, video and local storage.

6 http://docs.jquery.com/
7 http://jqueryui.com/demos/
8 http://diveintohtml5.org/

22
 v2.3 Dallas Dhu

It is important to note that you should not use XHTML elements in your pages as this
can make a page appear as invalid HTML5. Whilst this will not affect the pageʼs
rendering in most browsers it is considered bad practice.
The W3C standards body provides a free validator at http://validator.w3.org/ which
you can use to ensure your markup meets the HTML5 standard.

CSS3
Cascading Style Sheets are the industry standard for controlling the appearance of
content on the web, replacing older techniques such as tables, padding images and
inline <font> styling. CSS3 is the latest version of those standards, and is widely
supported by new browsers.

The CWD provides several custom styles for elements which help to make them
appear consistently. Whilst you should feel free to add styles for your own custom
elements, you should avoid extending or overwriting the CWD styles as these may
change in the future.
You must not use tables for any layout purposes, as this will break the page layout
when printed or viewed on mobile or small screen devices. You must not use the
<font> tag for text formatting.

23