This guide aims to help Monash web designers, developers and content authors of all skill levels create, maintain and manage high-quality websites. It provides information on branding, usability, accessibility and technical requirements.
The design and branding guidelines apply only to Monash University web pages. They do not apply to course materials in MUSO. Monash University web templates must not be used on personal pages.
To make the Monash website a success, we need to design for our users. This section provides information about the target audience groups for the Monash website, and suggests ways in which you can work with your users to better understand their needs.
The Monash website is used by three main audience groups:
In addition, a number of external groups are also part of the target audience for the site. These include:
Some Monash websites have may not have all these groups in their target audience, while others may need to cater for groups that are not identified in this list.
If you identify your audience, your website has a far greater chance of catering to their needs. It is important to work with business representatives, particularly those in marketing, to identify your target audience groups, as well as any secondary audiences.
Once you have identified your target audience groups, you need to develop an understanding of their information needs, and the issues that affect how they use your website.
A number of methods can be used to assist with the task of understanding users' needs. These include:
When identifying users' needs and preferences, consider some of the following questions:
Monash University's strategic vision, as outlined in "Monash Directions 2025", challenges the university to deliver a high level of quality in all areas of activity including teaching, learning, research, and professional and community activities.
A commitment to quality assurance is critical to the success of Monash websites.
To ensure the accuracy and quality of the information published on Monash websites, all content should be subjected to an editorial review process and an approval process.
Content should not be published without planning how it will be maintained. A regular maintenance/review schedule should be developed and followed for all online content. Using the university's CMS can assist in automating the maintenance/review schedule.
All webmasters/persons responsible for maintenance of a Monash website should ensure that a quality assurance process is developed and adhered to. A quality assurance process should include:
A website that is usable is one where the user is able to clearly identify the information they need and/or perform the task they came to the website for.
To assist the user in this, there are several things you need to consider.
Navigation is how users get to where they want to go. It is the pathway they take through a site.
User orientation consists of the visual clues that allow a user to know where they are in the structure of your site. Without these clues, users often feel "lost" and can find navigation more difficult.
One of the most important things on your website is the content you are presenting. The more clear and relevant the content is to the user, the more usable it is.
In its broadest definition, "web accessibility" is an approach to web design that aims to include the widest number of people and user agents as possible. Commonly, when people speak of web accessibility they are referring to access for disabled user groups.
The university has a legal obligation under the Disability Discrimination Act 1992 to develop and maintain accessible web pages. Our websites are required to comply with the accessibility standards developed by the World Wide Web Consortium (W3C). These standards are the Web Content Accessibility Guidelines (WCAG).
WCAG1.0 contains a number of checkpoints. These checkpoints are grouped into the following priority levels:
All Monash websites must meet all of the priority 1 checkpoints. In addition, all priority 2 checkpoints should also be met, except for checkpoint 3.3 that requires layout to be handled by stylesheets. Stylesheets cannot be used for layout because of the difficulties with stylesheet implementation across different browsers.
The Monash web templates have been authored to achieve compliance with these standards. They also meet some of the checkpoints listed as priority 3 requirements in WCAG.
Other areas in the Web Style Guide that deal with accessibility issues.
Amendments to the Education Services for Overseas Students (ESOS) Act 2000 include a legally enforceable national code for all registered providers of education programs to international students in Australia. The introduction of the Act coincided with amendments to the Migration Act and Regulations governing student visas.
To comply with the Act, Monash websites must include the university's CRICOS Provider Number in the footer of each page, as shown below.
Ensure the text "CRICOS Provider Number: 00008C" is linked to the CRICOS and Visa information for international students web page.
The standard web templates have been set up with the required CRICOS Provider Number in the footer. To get a copy of the web templates, contact your faculty or divisional web team
For more information on ESOS requirements, visit the Monash International ESOS web page (staff only).
All official Monash University websites must display copyright information in the footer of each page in the following format:
Copyright © 2007 Monash University
The standard web templates have been set up with the required copyright statement in the footer. To get a copy of the web templates, contact your faculty or divisional web team
Many countries have legislation or policies relating to accessibility of information or services online. In Australia, Section 24 of the Disability Discrimination Act 1992 states:
Section 24 of the Disability Discrimination Act 1992
Failing to put content online in an accessible format may leave the university open to legal action. In addition to complying with accessibility standards, ensure that the link to accessibility information appears in the footer of every web page.
The standard web templates have been set up with the required Accessibility information link in the footer. To get a copy of the web templates, contact your faculty or divisional web team.
Monash University is subject to the Information Privacy Act 2000 (Victoria). The university is committed to protecting the privacy of people using our websites. The Monash University Websites Privacy Statement, sets out how the university will deal with personal information recorded through the use of its web sites.
Please ensure that a link to the Monash University Websites Privacy Statement, using the link text 'Privacy', is included in the footer of every web page, as shown below.
The standard web templates have been set up with the required Privacy link in the footer. To get a copy of the web templates, contact your faculty or divisional web team.
All university websites must link to the caution page in the footer of every web page, as shown below. The caution page details how Monash withholds the right to change published information when required and that previously published information doesn't bind the university.
All official Monash University websites (excluding the sites of our international campuses and centres) must display the university's Australian Business Number (ABN) in the footer of every page.
ABN 12 377 614 012
The standard web templates have been set up with the required caution link and ABN number in the footer. To get a copy of the web templates, contact your faculty or divisional web team.
The Monash University brand is more than the logo. The brand includes the university's name, courses, history, people, and reputation. The users' experience of the Monash University website is also an integral part of the brand and it is important that this experience is one that enhances the brand.
The Monash branding for websites is captured in the approved web templates and these should be used wherever possible.
All administrative and business units of the university come under the Monash University masterbrand unless an exemption has been obtained from the university's Marketing Division. Contact the Marketing Division via the Web Centre at webmaster@monash.edu.au.
Centres with cross-faculty affiliation should also use the masterbrand as attempting to use multiple faculty sub-brands and colours on a website may be unworkable.
Masterbrand websites must use:
The approved masterbrand colours for websites are as follows:
| Page component | Colour |
|---|---|
| Global navigation bar and data table header | #339 and #FFF |
| Global utilities bar | #36C and #FFF |
| Highlight box header | #36C and #FFF |
| Section navigation column | #EAEFFA and #339 |
Each faculty has been given a distinct colour and a modified sub-brand.
For centres that have two or more faculty affiliations, the masterbrand should be used.
Websites for all schools, departments and centres within a faculty must use:
Faculties can use grades of their faculty colour though adequate contrast between text and background colours should always be maintained. To determine whether a selection of colours has adequate contrast, a colour contrast testing tool is available.
The approved faculty colours for websites are as follows:
| Page component | Colour |
|---|---|
| Global navigation bar | #3B3838 and #FFF |
| Global utilities bar | #B1AFAF and #000 |
| Highlight box and data table header | #B1AFAF and #000 |
| Section navigation column | #EBEBEB and #339 |
| Page component | Colour |
|---|---|
| Global navigation bar | #911C11 and #FFF |
| Global utilities bar | #CFA19C and #000 |
| Highlight box and data table header | #CFA19C and #000 |
| Section navigation column | #F4E8E7 and #339 |
| Page component | Colour |
|---|---|
| Global navigation bar | #00889C and #FFF |
| Global utilities bar | #99CFD7 and #000 |
| Highlight box and data table header | #99CFD7 and #000 |
| Section navigation column | #E5F3F5 and #339 |
| Page component | Colour |
|---|---|
| Global navigation bar | #C7B34C and #000 |
| Global utilities bar | #DFD499 and #000 |
| Highlight box and data table header | #DFD499 and #000 |
| Section navigation column | #F7F4E5 and #339 |
| Page component | Colour |
|---|---|
| Global navigation bar | #E9B050; and #000 |
| Global utilities bar | #F9E8CD; and #000 |
| Highlight box and data table header | #F9E8CD; and #000 |
| Section navigation column | #FCF3E6 and #339 |
| Page component | Colour |
|---|---|
| Global navigation bar | #653579 and #FFF |
| Global utilities bar | #C1AEC9 and #000 |
| Highlight box and data table header | #C1AEC9 and #000 |
| Section navigation column | #EFEAF1 and #339 |
| Page component | Colour |
|---|---|
| Global navigation bar | #968D81 and #000 |
| Global utilities bar | #C3BEB7 and #000 |
| Highlight box and data table header | #C3BEB7 and #000 |
| Section navigation column | #F0EEED and #339 |
| Page component | Colour |
|---|---|
| Global navigation bar | #75BDEB and #000 |
| Global utilities bar | #B1D9F4 and #000 |
| Highlight box and data table header | #B1D9F4 and #000 |
| Section navigation column | #EBF5FC and #339 |
| Page component | Colour |
|---|---|
| Global navigation bar | #B8C160; and #000 |
| Global utilities bar | #D8DCA5 and #000 |
| Highlight box and data table header | #B8C160 and #000 |
| Section navigation column | #F5F6E8 and #339 |
| Page component | Colour |
|---|---|
| Global navigation bar | #195E4A and #FFF |
| Global utilities bar | #99B7AF and #000 |
| Highlight box and data table header | #4C8172 and #FFF |
| Section navigation column | #E5EDEB and #339 |
Some organisational units have been granted sub-brand status. For example, Monash South Africa, Monash University Malaysia, Monash Research Graduate School, Monash University Accident Research Centre, Monash University Library, and Monash International.
Sub-brand websites must use:
The approved colours for sub-brand websites are as follows:
| Page component | Colour |
|---|---|
| Global navigation bar | #000 and #FFF |
| Global utilities bar | #339 and #FFF |
| Highlight box and data table header | #339 and #FFF |
| Section navigation column | #EAEAF5 and #339 |
Commercial entities with links to the university also use a sub-brand but without the Monash University shield. For example, Monash Commercial, and Monyx.
Websites within this category:
Websites of other entities associated with Monash University, for example, student associations:
Where Monash University is just one of a number of organisations involved in a project, centre or activity, use of the Monash University brand, while necessary, must be negotiated with the needs of other entities involved.
Further information on co-branding requirements is available from the Monash Brand Guidelines (staff only).
Entities within Monash who have existing logos should contact the Marketing Division to discuss the continued use of these logos under the Brand Guidelines.
Personal pages should not use or attempt to mimic any of the branding or visual design aspects of the official Monash University web designs. Professional profile pages that are part of a faculty, school, centre or department site are exempt from this requirement.
For examples of images for different target audience, see the Monash Brand Guidelines (staff only).
Photographic images used for decorative or promotional effect on official Monash University websites must be approved by the Marketing Division. For image approval email webmaster@monash.edu.au.
However, all images appearing within the Monash Image Library have been pre-approved and can be used on Monash websites without further approval.
Other images and graphics (such as diagrams, process charts, and screenshots) appearing on web pages must be of a high quality but do not need official approval.
Images appearing in the header of the university's top-level pages cannot be re-used on other Monash University websites.
Navigation is closely tied with the structural organisation of a website. It is important to get the structure right before designing your navigation. Often you will need to consider the design of the structure and the navigation as part of the same exercise.
The information architecture of websites includes an organisation scheme (content categories) and a structure (usually hierarchical).
Information can be structured according to a variety of organisation schemes.
On the web, hybrids of two or more of these schemes are usually used. For example, on the Monash home page a hybrid of audience-specific and topical organisations schemes is used.
Organisation schemes work best when users understand them. Work with target audience groups when creating or refining the site's organisation scheme. Card sorting and content agreement analysis (see resources below) are user-centred methods for designing an organisation scheme. Usability testing can confirm that the resulting scheme is workable.
Avoid designing an organisation scheme that mirrors the structure of the organisation. Users who are unfamiliar with the organisational structure may find it hard to locate resources. Also, organisational changes will require changes to the organisation scheme.
There are two main approaches to organisation structures on the web: hierarchical or top down, and bottom up as in database models. Some sites also use a linear structure, though this is generally unsuitable for anything other than very small sites.
Hierarchies are simple and effective ways of organising information and everyone is familiar with how they work.
Three important things to remember about designing hierarchies are:
The database model is useful with relatively homogenous content. Course information and staff directory content are good examples.
In the database model, metadata is the key. Here, the metadata relates to structural elements of content objects. For example unit code, unit name, unit description, prerequisites and year offered are elements of the unit content object.
Use of a linear structure assumes that users will move through the content starting from point A, and progress through an ordered series of page to point Z.
This may be useful for material that requires a linear approach, e.g. some instructional material, but this approach is generally unsuitable for websites with more than a few pages.
Each of the following is available from the Monash library.
One of the main functions of a home page is to provide users with an overview of the content and resources on offer. Generally, home pages should present users with the top levels of the information hierarchy (for faculties and sub-brands, some of this might be included in the global navigation bar). A set of quicklinks is sometimes used on home pages to allow users easy access to popular resources. Home pages may also include feature content (e.g. promotions, expos, open days) and news items that are updated regularly.
Guidelines for home page design:
The Monash home page devotes most of the screen real estate to showing users the content available on the site.
Section home pages play a similar role to home pages. They act as a gateway to the content within a section of a website and can be designed in a similar way.
Guidelines for designing section home pages:
If the site is master brand then section navigation can be developed to act as global navigation around the site. The following figure shows a site with three sections. The section home page has section navigation which links to each of the three sections along with a link at the top to the site's home page.
A second option, if the section home page doesn't have section navigation acting as global navigation, is that the page will simply link to content pages underneath it.
The following figure shows a site with three sections. The first two sections contain a number of grouped content pages. Each group contains an index and a number of sub pages. For these two sections the section home page contains a link to the index of each one of these content groups.
The Monash staff page is an example of good section home page navigation. The main content available for staff is highlighted through a series of links that occupy the primary screen real estate.
Content pages provide content and should form the majority of a website. They are destination pages rather than pages that users pass through to reach information.
Content pages exist below the section homepages in the site map hierarchy, as shown in this content site map.
The kind of navigation that appears on content pages depends on the navigation structure chosen for the section home pages. There are three different options.
With some sites, such as masterbrand and faculty sites, the global navigation forms part of the web template and cannot be changed. As a result, sites and subsites sitting under these templates (for example, the Research at Monash subsite) can use section navigation for navigation around all the sections contained within the site. In effect, the section navigation acts as global navigation. Please note that section navigation should never appear on the site or subsite's home page (see Designing home pages).
The following figure shows a site with three sections. Each section home page includes section navigation that allows a user to access all other sections of the site. This section navigation also includes a link to the site's home page. All of the subsequent content pages will carry the same section navigation.
If the section home page doesn't use section navigation as global navigation, then the section navigation can be used to navigate around content pages that exist within that one section (rather than the whole site or subsite).
The decision of whether the content page needs to have this form of section navigation depends on the size of the sections and the amount of information they contain.
The following figure shows a site with three sections. Each section has its own home page and its own section navigation. Content pages within a particular section will use that section's navigation.
If the size of a section is small and the section page doesn't use section navigation as global navigation then the content page does not need to include section navigation.
The following figure shows a site with three sections. Due to the small amount of content included in each section, it isn't necessary to include section navigation.
The Monash web templates support a range of navigation systems. You will need to design your navigation systems and customise your templates to reflect your design.
Faculties and sub-branded sites must customise the global navigation bar. This will provide site-wide navigation and requires careful planning. Options for global navigation include links to the main content sections on the site, or links to the most-used features.
Design global navigation in conjunction with home page navigation. Home page screen real estate must be used well and should not simply repeat the items in the global navigation bar. Section navigation will also need to be considered at this stage.
The navigation for the main Monash website was designed through a series of workshops with a range of stakeholders. Global navigation focuses on providing access to information about the core business of the university, through links to Faculties, Campuses and About Monash. Primary contact information is also provided. The home page navigation provides access to the same content, but the focus is on catering to target audience groups.
Global navigation must:
Using Monash Commercial as an example, the relationship between the site map and the global navigation can be seen. The following site map shows the Monash Commercial home page and its four sections (research commercialisation, products and services, about us, and contact us). This site map does not show the number of content pages under the section home pages.
The following screenshot shows how the four sections in the site map become the links in the global navigation - with each link pointing to the appropriate section home page.
The screenshot below shows the global navigation used on all Monash Masterbrand websites. It includes the following links: Monash home, About Monash, Faculties, Campuses, Contact Monash.
On the Adobe website, the global navigation provides access to the main sections of the site: products, solutions, support, purchase, company
The global navigation elements on the Macromedia website (Home, products, support, solutions, store) are similar to those on the Adobe website, which is not unusual given the similarity between the two companies.
http://search.monash.edu.au/emailThis example shows how the limited scope search is used on the Web Style Guide sub-site.
A script generates the breadcrumb bar used on Monash web pages. A configuration file allows for customisation of the bar.
Guidelines for the breadcrumb bar:
Section navigation provides navigation around a section of a website. In the case of Masterbrand sites, section navigation may provide site-wide navigation (eg the ITS website).
Guidelines for section navigation design:
The screenshot below shows the section navigation used within the Web Style Guide sub-site. All navigation options were available from the style guide home page.
Contextual navigation is used to provide links to related information. These links may be embedded within the text of a web page or grouped together and labelled "related links" or "see also".
Guidelines for contextual navigation:
title attribute to provide more information about the target pagetitle attribute to distinguish one link from another if this cannot be avoided.See the <a href="tutorial-navigation.html" title="Advanced tutorial on navigation design">tutorial</a> on this topic.
The web templates provide a skip link that allows users to skip over repeated blocks of navigation to access the content of a page. Without this, navigating through each page would be very tedious for some users. Those using screen readers would have to listen to the content of the page header being read out every time they visit a new page. People who cannot use a mouse would have to press the tab key to get to section navigation or a form located within a page. They would have to do this on every new page they visited.
The image below shows the location of the skip link at the top right of the page. The arrow points to the area on the page that is given focus when the skip link is used. Ensure that you do not remove the skip link.
For some disabled users, a site map or site index might provide a less confusing alternative to navigating your site. For others, search may provide an easier means of locating resources. These supplementary navigation features must be provided on all Monash websites.
To assist users who navigate using the keyboard, a series of shortcut keys have been implemented in the Monash web templates. These shortcuts use the accesskey attribute to provide keyboard shortcuts for important navigation options. The following accesskeys have been defined in the official Monash University templates and should not be removed.
To use keyboard shortcuts, hold down the alt key (Mac users need to use the control key) and press the relevant number key. In some browsers, the enter key also needs to be pressed.
Note: accesskeys do not work reliably for all users. Some keys may be reserved by other programs that the user may be running. However, we have provided them as they may be of benefit to some users.
Framesets are a collection of two or more HTML documents loaded into individual frames to create the appearance of a single page. Frames are not recommended as they are hard to implement well.
If frames are used, ensure the title attribute provided for each frame set is meaningful. People using speech readers or text browsers rely on the title attribute of each frame set to assist in navigating the site.
The title attributes should be descriptive enough to enable users to identify the contents of a particular frame, understand how one frame relates to another, and navigate between the frames that comprise a page.
A noframes element must also be used. It must provide access to the site's content for those using browsers that are not capable of dealing with frames.
<frameset rows="30%,70%">
<frame name="nav" src="nav.html" title="Site navigation" />
<frame name="content" src="content.html" title="Page content" />
<noframes>
<body>
<h1>Our home page</h1>
<ul>
<li>About us </li>
<li>Courses </li>
<li>Teaching </li>
<li>Research </li>
<li>Staff profiles </li>
</ul>
<p>Welcome to our home page</p>
</body>
</noframes>
</frameset>
Image maps are images with hotspots that act as links to other pages. Image maps are not recommended for navigation on Monash websites.
Where image maps are used, it is important to ensure the image map is client-side, its hotspots are at least 15 pixels squared and its hot spots have meaningful alt attributes.
<img src="navigation.gif" width="500" height="212" usemap="#navmap" alt="Site navigation" />
<map name="navmap">
<area shape="rect" coords="203,114,258,129" href="/aboutus.html" alt="About us" />
<area shape="rect" coords="277,113,348,129" href="/courses.html" alt="Courses" />
<area shape="rect" coords="364,113,401,128" href="/research.html" alt="Research" />
<area shape="rect" coords="418,114,488,130" href="/staff.html" alt="Staff profiles" />
</map> Do not use Java applets and JavaScript for navigation on Monash websites. For consistency, clarity and simplicity, all Monash websites must use the navigation systems provided by the Monash web templates.
A navigation label represents a chunk of content. For example, the label 'Contact us' usually represents the name, phone number, fax number, address, and email address of the organisation that owns the site. This label should trigger this association in the user's mind.
Even the best site structure and navigation systems will be undermined by poor labelling, so it's important to get it right. Some tips on improving labelling include:
Links are often included within the text on a page as a way to provide access to background or supplementary information. When links are placed within chunks of text, users sometimes click on the links before reading the text nearby. They can then end up moving away from the information they were looking for. If you include links within text, try to place them at the beginning or end of a paragraph. Avoid using too many links in any text chunk as they can distract attention away from the content.
A better approach may be to group the links together at the bottom of the page or paragraph using the heading "related links" or "see also". Highlight boxes can also be used for links to related or background information.
Always use the Monash style for links: blue underlined text. Never underline text that is not a link.
Wrong: To find out more about our new Science courses click here
Right: Find out more about our new Science courses
Do not use a URL (web address) as the text for a link. Where necessary, rephrase your text so that you can add the link to text that clearly describes the target of the link.
Wrong: For conference details visit www.scienceconference.com
Right: For more information, visit the Science Conference website
Where any link takes the user to a page that is not in HTML format, the format and size of the linked resource must be indicated and included as part of the linked text, using the following approach:
Wrong: Annual Report 2002
Right: Annual Report 2002 (pdf 250kb)
Where a document is provided in multiple formats either of the following approaches is satisfactory, although the first is preferred as it aids visual scanning and the link target is immediately clear to screen reader users. Where the latter is used, ensure that each link has a title that provides complete information about the linked resource (also shown below).
Right:
Acceptable: Annual report 2003 (pdf 286kb, rtf 510kb)
<a href="annual-report-2003.pdf" title="Annual report 2003 in PDF, 286kb">
docpdfrtftxtxlspptexezipWhere any link takes the user to a page that is not publicly accessible, the access restrictions must be indicated and included as part of the linked text, using the following approach:
Wrong: Monash staff policies
Right: Monash staff policies (staff only)
The link text for email links must be the actual email address:
Wrong: Contact the webmaster
Right: webmaster@monash.edu.au
If you are linking to an online form or a contacts page make this clear.
Wrong: Email us
Right: Feedback form
A step-by-step approach to page creation and design will help you create pages that have a logical and clear structure. The information shown here will help you make the best use of the screen real estate for effective page layout, provides advice on writing good page titles, and will help you choose sensible file and directory names.
On a web page, the most important elements should appear on the first screenful of information. As people set their monitors to different screen resolutions, the amount of information seen on the first screen varies. Browser toolbars also take up space. It is safe to assume that about 300 pixels will fit within the first screenful. Use this space to provide users with a clear indication of the page contents.
On content pages content, not navigation, should be the primary focus. Resist overdoing navigation on these pages. Site designers may be interested in navigation, but users are interested in content and see navigation only as a means to an end.
Navigation should dominate on navigation pages (e.g. home and section home pages). See website navigation.
Place images and text on pages in a way that creates a clear visual hierarchy. Creating a visual hierarchy helps to:
It is important to keep page length in mind when designing pages.
Named anchors provide navigation within a web page rather than around a website. Except in the case of the skip link, avoid using named anchors. They are often used in the belief they help users move around a long page, however:
Named anchors may cause problems with users:
Because named anchors and links appear the same when users click a link they expect to go to a new page. They can become confused/frustrated or think the link is broken when the same page reloads.
Users often use the back button to navigate a site. If the user has clicked a named anchor they have to click the back button twice. Clicking the back button once will just reload the page they are presently looking at. This may cause confusion or frustration and may lead them to conclude that the browser back button is broken.
Despite the availability of faster download speeds there are still many users with slower connections. For example, off-campus students in rural areas may only have access to dialup modems. People accessing the web via their mobile phone may also have a very slow connection:
Apart from the last two, web authors cannot do anything to improve page loading time.
Complex tables and frames can slow down display speeds, so:
Page size can be measured by adding up the size of all the page components (HTML file, images, stylesheets, etc).
Netmechanic's load time report measures page size.
These are available from the Monash University Library.
Web page titles are used in a number of ways. They:
If you are using a visual web page editor, you may need to look at the HTML source code view of the page to see the page title. It will be located inside the <head> tags at the top of the document, within the <title> tags. It should look like this:
<title>Page title</title>
Page titles must be written so that they:
A title should start with the specific and move to the general. Begin with a title that reflects the content of that page and then move to include the context in which the page exists. When describing an organisational unit, abbreviate as much as possible. For publicly accessible Masterbrand sites, refer to the organisation as "Monash University".
Do not use:
<title>Monash University, Prospective Students Office, Prospective Students</title>
Use this approach instead:
<title>Prospective students, Monash University</title>
Do not use:
<title>Usability guidelines, Web Style Guide, Monash University</title>
Use this approach instead:
<title>Usability guidelines, Monash Web Style Guide</title>
The page title and the page heading (<h1>Page heading<h1>) will convey similar information. When a user reads the page heading, the rest of the page helps gives context to the user. For example the logo, branding, breadcrumbs, section navigation, etc, all help the user understand where they are and what they are looking at.
Page titles are often read out of context, for example in a search results page, browser favourite or bookmarks lists, or in a browser history list. Because of this the page title needs to contain more information than the page heading to give more context to the user.
| Page title | Page heading |
|---|---|
| Page titles, Monash Web Style Guide | Page titles |
| Usability goals, Monash Web Style Guide | Usability goals |
| Courses for prospective students, Monash University | Courses |
Most search engines use the words in the page title to index the page. Accurate and descriptive page titles will make it easier the page easier to select from the listing of results. It also means that it will be placed nearer to the top of the search engine's results.
The address of a web page is determined by it's file name (eg. file-names.html) and the directories it lives under (eg. /staff/web/pages/). To ensure these addresses are easy to use and remember, follow these naming conventions.
Use whole words in file and directory names where possible, and when using abbreviations, only use those that are widely known.
It is much easier for a user to remember, to read out (on the phone to a friend, over a desk to a colleague), or to type in a web address where whole words are used.
Users who attempt to locate information by guessing web addresses will be more likely to find information on your site if you use whole word file names or common abbreviations.
Using appropriate whole word names also makes site maintenance easier. A file named privacy.html in a directory named policies can be readily identified as the policy document on privacy for your organisation.
File and directory names must use lower-case characters. As most web servers are case-sensitive, if users get the case wrong they won't find the page.
Combinations of upper-case and lower-case characters in file and directory names are also more difficult to type and to remember.
Never use spaces or non alpha-numeric characters in your file or directory names. They are not legal characters in web addresses and will be converted to their hexadecimal equivalent with a preceding percentage sign (%). This results in URLs web addresses that are difficult to type and remember. Some older browsers cannot access URLs web addresses containing hexadecimal these values.
For example, a file named my holiday.html in a directory named travel info would be translated to travel%20info/my%20holiday.html
If you must use a character to separate two words in a file or directory name, use a hyphen rather than an underscore. When web addresses are formatted as links (i.e. as underlined text), underscores cannot be seen and users may think there is a space in the address. The image below shows how the underscore in a hyperlink cannot be seen in a Word document.
Underscores also require two keystrokes (Shift key, plus the hyphen key), whereas a hyphen requires only one.
When http://www.monash.edu/students/ is entered as a web address, the Monash University web server sends the index.html file from within the students directory to the user's browser. This means that all directories on the web server must have an index.html file within them. If not present the web server will show a listing of all the files contained within that folder.
The default file that is sent to the browser is sometimes customised to default.html or welcome.html, please check with your web server administrator.
Using the default index file name means you can use shorter web addresses: http://monash.edu.au/students/ instead of http://monash.edu.au/students/index.html.
The generic templates are based on a set of standard file and directory names. These should be used when the templates are customised. The standard names include:
assets which includes sub-directories called includes, images, errors, and optionally styles and scripts assets/includes directory .shtmlassets/images directory assets/errors directory assets/styles directory assets/scripts directory should include all scripts except CGI scripts which should sit in a centrally-maintained cgi-bin directory sitemap.html a-z.html .html not .htm.For content to be successful it must be written for the web and presented in a way that makes it easy to use. Images should be used appropriately and document formats chosen with care.
Most people do not read word-for-word when reading online. They scan instead. They are also likely to skip or ignore large chunks of text or content that are not relevant to their immediate goals.
When writing for the web aim for a concise style of writing that uses clear and simple language, can be understood by your audience, and is organised into clearly labelled sections.
In order to write content for Monash web sites, you must attend a one day training session on Writing for the Web. These courses are run by Usability and Accessibility Services through the Staff Development Office. Learn more about the Writing for the Web course or contact the organisers.
Plain English is a writing strategy that can help improve communication. It involves:
Using everyday words makes content easier to read and understand. Here are some examples:
Sentences that are short and simple make content easier to absorb. Long sentences that include a number of clauses quickly become confusing and may be misunderstood.
Most sentences have 3 parts:
With active voice the subject of a sentence takes the action while with passive voice the subject is acted upon. For example:
Active: Maria returned the book to the library.
Passive: The book was returned to the library by Maria.
Using the active voice makes writing clear, direct and dynamic. It can also help reduce the length of sentences.
A lot of writing lacks a clear goal. If you aren't sure of what you're trying to say, your writing will suffer.
When writing or reviewing web content, write a list in point form of the things you want to say. Check your written content against this list and remove anything that doesn't need to be there.
Don't publish pages with "under construction" or "more information coming soon" messages. These pages can frustrate users looking for information. Either the content exists or it doesn't.
Don't publish pages without first having them reviewed and edited.
It is important to keep your audience in mind when writing. Before you write anything, consider:
Usability improves when writing is concise, easy to scan, and when it gets straight to the facts rather than being boastful, fluffy, or pushy.
These are available from the Monash University Library
Multimedia is necessary if you want to show movement or change over time or demonstrate three-dimensionality.
Where an image is used to provide information, a text equivalent must be provided by using the alt attribute.
<img src="openday.jpg" alt="Monash University Open Day, 2 and 3 August" />
Some images require a longer description. There are two recommended ways of doing this.
First, the longdesc attribute can be used. It should link to a page giving a full description of the image.
<img src="room.jpg" alt="A student room at Halls of Residence" longdesc="room-description.html" />
However, some older screen readers and text browsers do not recognise the longdesc attribute, so you must always also use a visible link to the long description. The screenshot below shows an example of this approach as used on the Monash senior management page. The page lists the senior management at Monash in a hierarchical chart format. The chart is an image. A longdesc attribute together with a visible link to a text description of the image are provided.
An alternative is to give a full description of the image on the page on which it is used. This is the approach used on this page to describe the image above.
Where images are used for decorative or layout purposes, the alt attribute must still be used, but should not contain any content. The best approach is to use an alt attribute that contains a space. The space is a workaround for older screen readers. They attempt to alert users to the existence of an image by substituting the file name. Newer screen readers accept that an empty alt attribute is deliberate, and ignore it. Using this workaround causes a small square to appear when a user mouses over an image when using Internet Explorer. To avoid this, use an empty title attribute in conjunction with a space in the alt attribute.
Where an alt attribute is missing, screen readers and text browsers will alert users. Sometimes the file name will be displayed, or the word "image" or similar may be used. This can cause unnecessary confusion. It is not acceptable to omit the alt attribute.
Wrong: <img src="spacer.gif" />
Right: <img src="space.gif" width="100" height="1" alt=" " title="" />
Recent improvements have been made to Flash, but the format is not considered fully accessible. In August 2002, the Australian Human Rights and Equal Opportunity Commission issued the following statement on the use of Flash:
"... work is currently underway to make Macromedia's Flash technology accessible to people who use screen-reading software. While some positive progress has been made, it will be a considerable time before most users will benefit, and even then, Flash may be accessible only in certain specific circumstances. It is certainly wrong for web designers to assume that improvements in the accessibility of a technology mean that it can be used indiscriminately without regard for the principles of accessible web design."
To provide accessible audio:
Captions can be created for a range of multimedia formats. Tutorials for Quicktime, Real Player and Windows Media Player are linked below.
To create an accessible video:
Bear in mind that not all users access video the same way and that you will need more than one method to make the video accessible to them.
The University is legally obliged under the Disability Discrimination Act 1992 to develop and maintain accessible web pages. Our websites need to meet standards outlined in the Web Content Accessibility Guidelines (WCAG) developed by the World Wide Web Consortium (W3C).
Monash University's 'Accessibility standards' webpage
Those who benefit from accessible videos include:
When creating the video:
When converting the video for web use:
When placing video in the site:
The site should have detailed information about the file including:
Text-based alternatives to the file should be provided such as:
An audio description is a narrated track of the video. A narrator talks a user through what is happening on the screen, usually between dialogue or pauses in the scene, but sometimes voice-over commentary is required.
In order to create audio descriptions, your video file must be in MP4 format. You will need the following software:
Uploading the audio description and the video
original_movie.mp4
audiofile1.wav
audiofile2.wav
audiofile3.wav
<video dur="0:02:19.75" region="videoregion" src="original_movie.mp4"/>
with
<video dur="0:02:19.75" region="videoregion" src="http://www.yoururl.com.au/original_movie.mp4"/>
<audio src="audiofile1.wav" begin="0:00:00.00"/>
with
<audio src="http://www.yoururl.com.au/audiofile1.wav" begin="0:00:00.00"/>
<audio src="audiofile2.wav" begin="0:00:43.52"/>
with
<audio src="http://www.yoururl.com.au/audiofile2.wav" begin="0:00:43.52"/>
<audio src="audiofile3.wav" begin="0:01:18.50"/>
with
<audio src="http://www.yoururl.com.au/audiofile3.wav" begin="0:01:18.50"/>
<a href="/filename_audio.qt.smil">My film with audio descriptions (2.2MB)</a>
Captions are text-displays made over video content. They can be transcriptions of dialogue (spoken words converted into text displays) and descriptions of important sounds.
In order to create captions, your video file must be in MP4 format. You will need the following software:
original_movie.mp4
filename.qt.txt
<video dur="0:02:19.75" region="videoregion" src="original_movie.mp4"/>
with
<video dur="0:02:19.75" region="videoregion" src="http://www.yoururl.com.au/original_movie.mp4"/>
<textstream dur="0:02:19.75" region="textregion" src="filename.qt.txt"/>
with
<textstream dur="0:02:19.75" region="textregion" src="http://www.yoururl.com.au/filename.qt.txt"/>
<a href="/filename.qt.smil">My film with captions (2.2MB)</a>
In order to create captions, your video file must be in MP4 format. You will need the following software:
In order to create captions of your vodcast, your file must be of the format MP4. You will need the following programs installed to create a vodcast:
Sometimes Quicktime crashes at this point. If so:
If you are still having problems then:
If your RSS feed is not already uploaded to iTunes:
Wherever possible publish in HTML format because it is the most widely accessible. If you publish in other formats:
If PDF is used, an alternative accessible version of the content must be made available online. RTF (Rich Text Format) or TXT (text) format are acceptable alternatives. Although there have been significant accessibility improvements to the PDF format, a PDF document is only accessible when all of the following conditions are met:
As a result of these extensive requirements, PDF documents are not considered accessible. In August 2002, the Australian Human Rights and Equal Opportunity Commission issued the following statement on the use of PDF:
"The Commission's view is that organisations who distribute content only in PDF format, and who do not also make this content available in another format such as RTF, HTML, or plain text, are liable for complaints under the DDA [Disability Discrimination Act]".
Some web authors may put information online in PDF format in the belief that this protects it from unauthorised change or use. This belief is incorrect. Online content in any format is at risk of misuse.
To make Word documents accessible to people with disabilities:
To make PowerPoint files accessible to people with disabilities:
To provide an accessible HTML version of PowerPoint slides, use the Illinois Accessible Web Publishing Wizard for Microsoft Office.
OperaShow is a useful alternative to PowerPoint. Presentations are created in HTML format and a projector style sheet (supplied with OperaShow) is attached. This converts the document into a presentation format.
See making images and multimedia accessible.
When used well, HTML tags provide information about the structure and meaning of content chunks on a page. However some web designers use HTML tags just for visual effect. These two approaches are called "structural" and "presentational" markup.
Presentational markup: I want to <b>draw attention to this phrase</b>
Structural markup: I want to <strong>draw attention to this phrase</strong>
Only graphical browsers will display text wrapped in the <b> tag as bold. Other types of browsers treat this text the same as other text on the page, so the effect of bolding to draw attention is lost. On the other hand, using the <strong> tag draws attention to the text wrapped inside it on all sorts of browsers. For instance, screen readers will read the text in a louder or different voice.
Here is another example:
Presentational markup: <font size="large">My page heading</font>
Structural markup: <h1>My page heading</h1>
In this example, increasing the size of a page heading by using the font tag will only work in browsers like Internet Explorer, Netscape and so on. Text browsers, screen readers and handheld devices will show the text in the same size as the rest of the text on the page. Using heading tags, like h1, h2 and so on will mean the headings work in every sort of browser or device people might use.
Headings should be properly nested. There should only be one h1 on the page. Headings at the next level down should be marked using h2 and at the next level h3, and so on. An h3 should never follow an h1.
The markup for this list looks like this:
<ul>
<li>item 1</li>
<li>item 2</li>
<li>item 3</li>
</ul>
Different visual formatting effects can be applied to unordered lists through the use of stylesheets. See applying styles to content.
For examples of how to use HTML tags for tables, see designing tables.
In graphical browsers, emphasis is generally displayed as italic text
This is highlighted text using emphasis.
The markup for this is shown below:
This is <em>highlighted text</em> using emphasis.
and strong is generally displayed as bold.
This is highlighted text using strong.
The markup for this is shown below:
This is <strong>highlighted text</strong> using strong.
For example:
blockquote or li to indent text that is not a quotation or list.Tables and forms need to be designed and created with care so they are accessible and work in a variety of browsers, including text-only browsers and screen readers.
Tables are designed to be used only for showing data. However, they are widely used on websites to control layout. Using tables for layout is now being phased out because of improvements to browsers and the layout techniques that can be achieved using style sheets.
Layout tables are still used at Monash because many of our users still use older browsers that don't work well with style sheets. In the coming year or two we will be monitoring the use of Netscape 4 and looking to phase out table-based layouts.
Avoid designing complex data tables. They can cause usability problems for all users and are particularly difficult to markup for screen reader accessibility. Sometimes complex data is best communicated with a diagram or visual representation of some kind.
The most important thing for accessibility of data tables is to make sure that the content is read or presented in the correct order. In browsers that do not support tables the information is treated as a series of paragraphs. The paragraphs are read in a particular order, starting with the top left cell. You can check the reading order with a tool like The Wave.
Structural markup should be used to distinguish table header cells from data cells. Header cells should be marked up with <th id> and data cells should be marked up with <td headers>. Each data cell references the relevant headers, for example:
<th id="monday">Monday</th>
<th id="low">Low impact</th>
<td headers="monday low"> 10am </td>
Tables should also include an appropriate summary attribute that describes the content contained in the table. For example, "Aerobics class sessions, Monday to Friday".
<table width="100%" summary="Aerobics classes and session times, Monday to Friday.">
Another way of providing summary information for a table is to give the table a title using the <caption> element.
<table width="100%" summary="Aerobics classes and session times, Monday to Friday.">
<caption>Class times</caption>
<table width="100%" border="1" cellspacing="0" cellpadding="5" summary="Aerobics classes and session times, Monday to Friday." >
<caption>Class times</caption>
<tr>
<td></td>
<th id="monday">Monday</th>
<th id="tuesday">Tuesday</th>
<th id="wednesday">Wednesday</th>
<th id="thursday">Thursday</th>
<th id="friday">Friday</th>
</tr>
<tr>
<th id="low">Low impact</th>
<td headers="monday low">10am</td>
<td headers="tuesday low">2pm</td>
<td headers="wednesday low">10am</td>
<td headers="thursday low">2pm</td>
<td headers="friday low">10am</td>
</tr>
<tr>
<th id="step">Step</th>
<td headers="monday step">8am</td>
<td headers="tuesday step">5pm</td>
<td headers="wednesday step">1pm</td>
<td headers="thursday step">9am</td>
<td headers="friday step">2pm</td>
</tr>
<tr>
<th id="pilates">Pilates</th>
<td headers="monday pilates">7am</td>
<td headers="tuesday pilates">7am</td>
<td headers="wednesday pilates">7am</td>
<td headers="thursday pilates">7am</td>
<td headers="friday pilates">7am</td>
</tr>
<tr>
<th id="spin">Spinning</th>
<td headers="monday spin">3pm</td>
<td headers="tuesday spin">8pm</td>
<td headers="wednesday spin">3pm</td>
<td headers="thursday spin">8pm</td>
<td headers="friday spin">3pm</td>
</tr>
</table>
This is what the table looks like on a graphical browser.
| Monday | Tuesday | Wednesday | Thursday | Friday | |
|---|---|---|---|---|---|
| Low impact | 10am | 2pm | 10am | 2pm | 10am |
| Step | 8am | 5pm | 1pm | 9am | 2pm |
| Pilates | 7am | 7am | 7am | 7am | 7am |
| Spinning | 3pm | 8pm | 3pm | 8pm | 3pm |
The following guidelines will help you design forms that are accessible and work in a variety of browsers.
Position labels so that they are read out immediately before the form input field. In most cases, this means placing the label above or to the left of the form input field. For radio buttons and checkboxes the label should be positioned immediately after the form input field.
Doing this will makes content easier to scan and improve readability for sighted users. It will also ensure the read order for screen reader users is correct.
The disadvantage of a vertical design is the increased length of the form. You may find it better to split the form into more than one page - although this means that you will need to pay particular attention to navigation through the different pages of the form.
To associate a label with a form input field, use the <label> element. The association is made by copying the form identification (id) attribute to the for attribute in the label as shown below.
<label for="fname">First name
<input type="text" id="fname" name="firstname" size="20" /></label>
If you are using a table to layout the form this is how to associate the form label with the form input field:
<table summary="Layout table for name details.">
<tr>
<td><label for="fname">First name:</label></td>
<td><input type="text" name="firstname" id="fname" /></td>
</tr>
<tr>
<td><label for="lname">Last name:</label></td>
<td><input type="text" name="lastname" id="lname" /></td>
</tr>
</table>
Often forms are made up of two or more sections. On an event booking form there might be fields to collect your contact details and fields collecting information about the events you wish to attend. Using headings to group these section is a quick and easy way which can make the form easier to understand.
Another way of grouping form fields is by using the <fieldset> element. This is visually displayed in a browser as a solid line around a number of form fields with the legend text intersecting top of box.
The following markup shows how the form fields are grouped and titled using the <fieldset> and <legend> elements:
<fieldset>
<legend>Personal information</legend>
<label for="fname">First name: <input type="text" name="firstname" id="fname" /></label><br />
<label for="lname">Last name: <input type="text" name="lastname" id="lname" /></label>
</fieldset>
If you have a menu form field which contains multiple groups of information they can be grouped using the <optgroup> element. These groups will be displayed in the browser as a dropdown menu with bold group headings and indented options like so:
The following markup shows how the menu options can be grouped using the <optgroup> element:
<select name="ComOS">
<option selected="selected" label="none" value="none">None</option>
<optgroup label="PortMaster 3">
<option label="3.7" value="pm3_3.7">PortMaster 3 with ComOS 3.7</option>
<option label="3.5" value="pm3_3.5">PortMaster 3 with ComOS 3.5</option>
</optgroup>
<optgroup label="PortMaster 2">
<option label="3.7" value="pm2_3.7">PortMaster 2 with ComOS 3.7</option>
<option label="3.5" value="pm2_3.5">PortMaster 2 with ComOS 3.5</option>
</optgroup>
</select>
Mandatory fields must be labeled with the word "required" immediately after the field name and within the actual field label.
In addition to this, mandatory fields can be also marked up as a different colour (eg. red) to enhance visual identification, but colour must not be used as the only means of conveying a mandatory field.
Using images for buttons cause difficulty for users who need to increase the text size or use a screen magnifier. Images don't enlarge well as the text can become jagged and difficult to read. If styles and markup are used to create the button when the text size is increased the text size on the button will also gracefully increase.
If you must use an image make sure that the alt attribute contains meaningful description. For example:
<input type="image" alt="Submit!" border="0" name="imageField" src="/assets/images/submit.gif" width="109" height="41" />
Whilst there may be forms which require a "Clear" or "Reset" button the majority of forms don't and will not benefit from having these buttons added. The reasons being:
Colour must be used carefully on the web. Using colours with sufficient contrast is important, and you should not use colour as the only way to show meaning or distinguish between important information or elements on a page.
A series of colours that have been tested to make sure they offer good contrast have been approved for use on Monash websites. The Monash web templates must be used to handle presentation of colours and fonts on all Monash web pages.
Two potential accessibility issues arise from the use of colour:
Colour combinations used for text and background colours should offer sufficient contrast to ensure they are legible to all users. Several colour contrast testing tools are available (see below). Colour combinations that fail these tests should never be used. However, those that pass may still present contrast problems for some users. There is no simple definitive test to ensure sufficient colour contrast or differentiation.
Colour should not be the only means for distinguishing between different types of content, or the only means for highlighting important content. For example, using red text as the only means of marking required fields on a form will not provide necessary information to users who cannot see colours.
The approved colours for the web are detailed in Branding and visual identity. See visual components of the web templates for an overview of the terminology used to refer to template components such as global navigation, section navigation and highlight boxes.
For information on colour values for print publications, please refer to the Monash Brand Guidelines.
Typography can only be controlled to a limited degree on the web. Fonts will be displayed on the user's machine only if they have them installed. Because of this, web fonts should be limited to commonly installed fonts such as Times New Roman, Arial, or Helvetica.
For information on typography for Monash print publications, see Brand Guidelines (staff only).
These styles will work in a slightly different way across browsers. Many of them will not work in Netscape 4 and older browsers. Where you need to add an HTML attribute to an element to get the desired effect in Netscape 4 and older browsers, an example will be provided.
| Appearance | Markup to achieve this |
|---|---|
A paragraph |
<p>A paragraph</p> |
alt="code example" |
<code>alt="code example"</code> |
Text caption for an image. |
<div class="caption">Text caption for an image.</div> |
|
<ul> |
|
<ol> |
|
<ul class="nobullet"> |
|
<dl> |
Indented text |
<div class="indent1">Indented text</div> |
Text indented more |
<div class="indent2">Text indented more</div> |
Text width of 50% of available space (does not work in Netscape 4 and older browsers) |
<div class="text50">Text width of 50% of available space</div> |
Text width of 60% of available space (does not work in Netscape 4 and older browsers) |
<div class="text60">Text width of 60% of available space</div> |
Text width of 70% of available space (does not work in Netscape 4 and older browsers) |
<div class="text70">Text width of 70% of available space</div> |
Text width of 80% of available space (does not work in Netscape 4 and older browsers) |
<div class="text80">Text width of 80% of available space</div> |
Text width of 90% of available space (does not work in Netscape 4 and older browsers) |
<div class="text90">Text width of 90% of available space</div> |
| Appearance | Markup to achieve this |
|---|---|
Heading level 1 |
<h1>Heading level 1</h1> |
Heading level 2 |
<h2>Heading level 2</h2> |
Heading level 2 - black |
<h2 class="black">Heading level 2 - black</h2> |
Heading level 3 |
<h3>Heading level 3</h3> |
Heading level 3 - black |
<h3 class="black">Heading level 3 - black</h3> |
Heading level 4 |
<h4>Heading level 4</h4> |
Heading level 4 - black |
<h4 class="black">Heading level 4 - black</h4> |
Heading level 5 |
<h5>Heading level 5</h5> |
Heading level 6 |
<h6>Heading level 6</h6> |
These styles will not work on browsers older than version 4. Netscape 4 requires the inclusion of the <border> attributes on the img element to display a border.
| Appearance | Markup to achieve this |
|---|---|
|
<img src="/assets/images/img.jpg" width="38" height="31" class="noborder" alt=" " title="" /> |
Note: Netscape 4 requires |
<img src="/assets/images/img.jpg" width="38" height="31" border="1" class="border" alt=" " title="" /> |
Note:Netscape 4 requires |
<img src="/assets/images/img.jpg" width="38" height="31" border="2" class="border2" alt=" " title="" /> |
| Appearance | Markup to achieve this |
|---|---|
Text chunk highlight |
<div class="box">Text chunk highlight</div> |
Text shade style |
<div class="shade">Text shade style</div> |
Note: Netscape 4 and older browsers will not display this style. |
<img src="/assets/images/img.jpg" width="38" height="31" class="screenshot" alt="Screenshot showing ... " /> |
Note: Table header colour will vary for faculties and sub-brands.
| Appearance | Markup to achieve this | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
<table width="90%" border="1" cellspacing="0" cellpadding="5" summary="Summary of table content."> |
|||||||||
|
<table width="90%" border="1" cellspacing="0" cellpadding="5" class="info-table" summary="Summary of table content."> |
It is possible to apply two styles to a single element.
| Appearance | Markup to achieve this |
|---|---|
A black indented heading |
<h3 class="black indent1">A black indented heading</h3> |
A black heading indented more |
<h3 class="black indent2">A black indented heading</h3> |
If you would like to request that a new style be added to the central style sheet, please email webmaster@monash.edu.au.
For search to be useful, web pages must have good metadata.
Metadata is typically defined as "data about data". Metadata provides information about a web document. It may include details on the subject matter of the document, the name of the person or group who created it, the date of creation, and keywords that can help a user locate that particular document amongst a number of similar documents.
The <meta> element allows page authors to include metadata about a web page. It is usually found within the <head> tags in a web document. All metadata tags use the same basic format. Here are two common examples:
<meta name="keywords" content="web, style, guide" />
<meta name="description" content="Guidelines on the appropriate use of Monash web templates, including branding, visual design, usability, accessibility, and technical issues." />
There are other elements of web pages that provide data for search engines. This includes the text within the <title> tags, text on the page, text alternatives for images, and links to and from other websites.
Most search engines use all of these data sources to index web pages, but they do it in different ways and treat some forms of data with more importance. For example, some ignore keyword metadata elements because it is easy for page authors to deliberately include incorrect or misleading metadata in an attempt to attract visitors to a website.
There are some Monash-specific uses for metadata that you should consider. Pages that have certain metadata attributes can found by using the search engine or filtered from search results.
Two common uses for Monash-specific metadata are:
<meta name="monash.approval" content="Marketing and Public Affairs" />
<meta name="monash.access" content="public" />The first example identifies the approver of the page content. The second marks the page as being for public access.
Pages for internal use only should use the monash.access metadata element. Mark the content as intranet, as shown in the example below. Searches from the Monash home page and other publicly-accessible pages have been set up to exclude pages with this metadata attribute from search results.
<meta name="monash.access" content="intranet" />
Mailing lists that are archived on the web should use metadata to prevent the search engine including mailing list messages in search results.
<meta name="monash.access" content="emailarchive" />
The Monash search engine gives ten times more weight to terms used in the page title than terms in the body of a document. All search engines treat the title tag with importance.
See page titles for a discussion of the importance of page titles and guidelines on how they should be written.
If a description field is provided, most search engines will use this information to place beneath the page title in a list of search results. It is important to make sure that your description includes a concise and accurate summary of the contents of the page. A sentence or two is all that is needed. Search engines limit the number of characters that can be used in a description. Keep descriptions to a maximum of 200 characters to avoid having your description cut off.
<meta name="description" content="Information and resources for current students at Monash University." />
The Monash search engine gives ten times more weight to terms used in the description field than terms in the body of a document. Most other search engines will not give as much importance to this metadata.
The keywords meta tag allows you to supplement the title and contents of a web page with a list of index terms for a document. Some search engines may rank keywords higher than body text. The Monash search engine has been configured to add ten times more weight to keyword metadata than to body text.
Keywords should be included on top level and other important pages. However, adding the same keywords to every page is counter-productive. It is better to create unique keywords for each individual page.
When using keywords, make sure the terms you select accurately describe what users can find on the page.
<meta name="keywords" content="current students, portal, exams, fees, scholarships, enrolment, study resources, research resources, graduation, university life, student employment" />
When websites are migrated into the content management system (CMS), there will be two types of pages: pages that are generated from CMS data capture templates, and regular web pages.
CMS-generated pages will eventually be able to take advantage of metadata generated by a CMS product called MetaTagger. This will reduce the burden on page authors who will then be able to review and edit the automatically generated metadata.
This section provides detailed information on markup standards, cascading style sheets, customising error messages and the technical implementation of the current web design.
Any markup tools may be used to customise the templates or to create web pages provided the following markup standards and guidelines are followed.
Documents must use a W3C-approved DTD. Either XHTML 1.0 Transitional or HTML 4.01 Transitional are permitted.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
Markup should be syntactically correct and should be validated against these DTDs.
After customising the templates, they should be validated before being made available to web authors. Web authors using customised templates should validate all pages and correct any errors.
A suitable online validator is the W3C validator.
Avoid using deprecated markup elements such as <center>, <strike>, or <u>. A list of deprecated elements is provided by the W3C.
Where possible (taking into account the behaviour of Netscape 4), avoid using deprecated attributes such as align="", bgcolor="". The W3C provides a list of deprecated attributes.
Developers customising templates or those using text-style HTML editors should follow these style guidelines. Users of authoring tools such as Dreamweaver and FrontPage should follow as many of the guidelines as possible.
All markup and attributes should be written in lower case. This is required for documents to validate against the XHTML DTD. It should also be used for HTML DTDs to enable a smoother transition to XHTML in the future.
Wrong: <P>This is a paragraph with <STRONG>important text</STRONG>.</P>
Right: <p>This is a paragraph with <strong>important text</strong>.</p>
Attributes should be enclosed in quotation marks. This is required for documents to validate using XHTML DTDs and recommended practice for those using HTML DTDs.
<table width=100%></table><table width="100%"></table>Use HTML comments to show the page structure and mark important elements. This improves readability and can assist when correcting faulty markup.
<!-- H E A D E R -->Ensure that special characters are properly encoded. Take particular care when cutting and pasting from word-processed documents.
"&©The web templates use cascading stylesheets (CSS) for formatting page elements. However, because Netscape 4 was widely used at Monash, HTML tables are used for page layout. Using tables for layout is now being phased out because of improvements to browsers and the layout techniques that can be achieved using style sheets.
For information on the implementation of stylesheets and cross-browser/platform rendering, see technical implementation.
The stylesheets provide a list of styles that can be applied to common page elements. Styles should be used to format page elements for display.
font elementsDo not use the <font> element. If you want to use larger text for a decorative effect, use a style. If the text is a heading, use a heading tag: <h1>, <h2>, etc. Avoid using smaller text sizes than those provided as the default in the stylesheets.
color attributesDo not use the color="" attribute. Colours are included in the Monash stylesheets. Additional colour options (subject to branding, usability and accessibility guidelines) can be added to either the centrally-maintained stylesheets or to a local stylesheet.
Local stylesheets must be added to faculty and sub-brand templates to apply the approved colours for the site.
Additional styles may be added, but should be limited to simple text styles that display properly across a range of browsers. More complex styles must be added to the centrally maintained stylesheets.
If adding additional text styles, do not use fixed font sizes (points and pixels). Use relative sizes instead (ems and percentages). This must be done because:
To provide a quality service to users, all Monash websites must provide customised error messages for the following common web errors:
Standard text for error messages has been developed and is supplied with the approved web templates. The aim is to clearly explain the error to users and assist them to recover from the error. The standard text must replace any error messages currently in use.
The error messages use CGI-Mailer, an online form processor. They capture the referring page URL as well as the page on which the error occurred and allow users to submit error reports to site maintainers with a single click.
The scripts, HTML, and data files needed to implement standard Monash error messages are supplied with the approved web templates.
All error messages must send the error report to the local webmaster or web team rather than to webmaster@monash.edu.au.
Web teams should obtain a role account. Using a personal email address means that error reports may not be dealt with when the recipient is on leave, ill, or has left their position.
The standard templates are designed to work on Apache-hosted web servers. They make extensive use of server side includes (SSIs).
They can be customised to work on other platforms, but the cross-browser/platform functionality built into the templates must be preserved. You will need to provide an alternative to Apache SSIs and you must maintain links to the centrally-maintained stylesheets.
You must also test extensively on a variety of browsers and platforms.
A number of SSIs are used to make up a single page. These are:
<img src="file.gif"... >) can be used if you do not have multiple banner images.To see the range of template styles that have been created go to web template styles.
The visual components of the templates are available in the Web Style Guide.
The header file contains two versions of the header markup.
One is designed for older browsers like Netscape 4. This was created because of rendering problems in Netscape 4 running on Windows XP. Single pixel margins around the logo and banner image were displaying at several pixels wide. To fix this problem, the borders have been removed and implemented on the banner image instead.
A second instance of the header markup contains the header styled as the designer intended, with CSS-enabled borders.
An SSI contained within the header file handles browser detection and delivers the appropriate header to the requesting user agent.
The Monash stylesheets have been designed to work independently of web server platforms. They will work for websites hosted on IIS as well as Apache or any other type of web server. They have been tested widely for cross-browser and platform compatibility, and optimised for use with a broad range of browsers. Despite this, some rendering problems remain and are documented below.
All templates include a link to a stylesheet file at http://assets.monash.edu.au/styles/monash.css. This file does not exist. Instead, the server detects the browser making the request and substitutes the appropriate CSS file in place of monash.css. The current rewrite rules are:
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} Chimera [OR]
RewriteCond %{HTTP_USER_AGENT} Camino
RewriteRule monash.css camino.css [L]
RewriteCond %{HTTP_USER_AGENT} Safari
RewriteRule monash.css safari.css [L]
RewriteCond %{HTTP_USER_AGENT} Omni
RewriteRule monash.css omniweb.css [L]
RewriteCond %{HTTP_USER_AGENT} iCab
RewriteRule monash.css icab.css [L]
RewriteCond %{HTTP_USER_AGENT} Opera
RewriteRule monash.css opera.css [L]
RewriteCond %{HTTP_USER_AGENT} Gecko
RewriteCond %{HTTP_USER_AGENT} "Win"
RewriteRule monash.css mozwin.css [L]
RewriteCond %{HTTP_USER_AGENT} Gecko
RewriteCond %{HTTP_USER_AGENT} "Mac"
RewriteRule monash.css mozmac.css [L]
RewriteCond %{HTTP_USER_AGENT} Gecko
RewriteRule monash.css mozilla.css [L]
RewriteCond %{HTTP_USER_AGENT} Konqueror
RewriteRule monash.css safari.css [L]
RewriteCond %{HTTP_USER_AGENT} "MSIE 6"
RewriteCond %{HTTP_USER_AGENT} "Win"
RewriteRule monash.css ie6win.css [L]
RewriteCond %{HTTP_USER_AGENT} "MSIE 5.5"
RewriteCond %{HTTP_USER_AGENT} "Win"
RewriteRule monash.css ie55win.css [L]
RewriteCond %{HTTP_USER_AGENT} "MSIE 5"
RewriteCond %{HTTP_USER_AGENT} "Win"
RewriteRule monash.css ie5win.css [L]
RewriteCond %{HTTP_USER_AGENT} "MSIE 4"
RewriteCond %{HTTP_USER_AGENT} "Win"
RewriteRule monash.css ie4win.css [L]
RewriteCond %{HTTP_USER_AGENT} "MSIE 5"
RewriteCond %{HTTP_USER_AGENT} "Mac"
RewriteRule monash.css ie5mac.css [L]
RewriteCond %{HTTP_USER_AGENT} "MSIE 4"
RewriteCond %{HTTP_USER_AGENT} "Mac"
RewriteRule monash.css ie4mac.css [L]
# older browsers
RewriteCond %{HTTP_USER_AGENT} "Win"
RewriteRule monash.css deprecated-win.css [L]
RewriteCond %{HTTP_USER_AGENT} "Mac"
RewriteRule monash.css deprecated-mac.css [L]
# anything that we do not pickup
RewriteRule monash.css base.css [L]
A base stylesheet contains all styles needed for page layout. A number of browser specific stylesheets are included to handle rendering quirks on different browser/operating system platforms.
The base stylesheet is imported into the browser specific stylesheet using an @ rule. It is then delivered to the requesting user agent.
For example:
@import url("base.css");
A set of print styles has been included in the base stylesheet. These instruct the browser not to print the header or section navigation portions of a page. However, print styles do not work with Netscape 4 or earlier browsers. It is possible to overcome this for pages generated by the content management system (CMS). A print presentation style can be dynamically generated by the CMS.
This is the list of browser/platforms combinations that have been tested. In the section below we document the issues that we were unable to or decided not to resolve.
Information not yet available. In the interim, see notes on The new Monash website: "under the bonnet".
The "change text size" feature linked from the top of the page uses a PHP script that allows users to easily change the size of text on Monash web pages. The default font size is set at 90% of the user-defined font size (i.e. it is based on whatever the user has set in their browser preferences).
Web templates are available for each type of Monash website: Masterbrand, Faculty and sub-brand. Different styles are also available for different page types: home pages, and content pages.
To get a copy of the web templates, contact your faculty or divisional web team
See also: Technical implementation of the web templates
The web templates meet the university's branding, usability and accessibility requirements. They have passed quality assurance checks, including cross-browser/platform testing, markup validation and accessibility validation.
There are three main template styles based on brand requirements and several page styles for pages with different functions. To select the appropriate template, first select the brand, then which page style you need for your content. Each template also has a list of styles for formatting content within the page template.
Templates must be customised (for example, to include your site's breadcrumbs, contact details, etc) before they can be used.
There are three main template styles based on branding requirements derived from the brand architecture. These are Masterbrand, faculty, and sub-brand styles. The primary visual differences between each are the logo elements (shield and text) and colours. For information on which level of branding you should use, see branding and visual identity.
This style is to be used for all sites that are required to use the Masterbrand.
Each faculty has a unique colour and logo (shield and text elements). Schools, centres and departments within a faculty will use the faculty template style. Centres with cross-faculty affiliation should use the Masterbrand style.
This style is to be used for all sites that have been allocated a sub-brand.
A range of page styles are available. These can be customised in either the Masterbrand, faculty or sub-brand style.
Note: most of the following page template styles are based on the sub-brand website style.
This template allows the creation of home pages and section home pages. Section home pages are pages whose primary function is to provide links to content within a given section of a website (for example, the prospective students home page or staff home pages that are linked from the Monash home page).
This template can also be used for content pages without section navigation.
This template should be used for content pages within a section of a website. They provide for a navigation column on the left of the screen which provides links around the content section of a site.
This template allows for news or special content to be highlighted on the right side of content pages.
Use a sitemap template to provide users with an overview of the structure and contents of your website.
Use this template to provide an alphabetical list of the main resources offered on your website.
See applying styles to content for a list of styles that can be applied to content elements.
The header is the first group of elements on the page, and comprises:
These links provide accessibility enhancements for people with visual or motor impairments.
The Monash University logo is comprised of the following elements:
These links appear on all pages within a site.
The utility bar contains links to the staff directory, site map and A-Z index. Search is also part of the global utility bar.
A limited-scope search can be provided to enable users to search within a sub-site.
The body includes all page elements between the header and footer. It may optionally include section navigation and/or highlight boxes.
The breadcrumb trail appears on all university web pages except the home page.
Section navigation provides navigation within a section of a site and may also provide site-wide navigation around a Masterbrand site.
These show highlighted or supplementary content or links. A maximum of two highlight boxes can be used on any one page.
The footer includes the copyright notice, the university's Australian Business Number, a link to a legal caution, a link to Monash's privacy information, the university's CRICOS provider number with a link to CRICOS and Visa information for international students, the date on which the page was last updated, a means for contacting the maintainer of the page, and a link to a discussion of the accessibility features of the site.
All pages provide a means for users to contact the maintainer.
Templates need to be customised before you can use them to create your website.
Faculty and divisional web templates can be obtained by contacting the web group within your area. If your area does not have a web group, you can request customised templates by contacting the university's Web Resources and Development group at webmaster@monash.edu.au.
When you receive your customised templates, you should be given a short document that provides information about the directory structure of your site. It will also provide a very brief overview of the contents of the Web Style Guide. You should not rely on the overview, but should familiarise yourself with the style guide.
The templates can be edited using any web authoring tools, but care should be taken when using graphical editing tools, particularly FrontPage.
Do not use any of FrontPage's formatting tools. The screenshot below shows the toolbar in FrontPage 2002 (it is similar to FrontPage 2000) with the formatting tools circled.
Do not change the font setting from the default of Times New Roman size 12 (shown in the screenshot below). If you change this, FrontPage will add font tags to your document. Font tags are not permitted for use on Monash web pages. The Monash web style sheets will automatically restyle the text to use the correct font and font size.
Use the text styles for headings and sub-headings within your web page. These are circled in the screenshot below. The main heading on a page should by styled to use Heading 1. For subsequent sub-headings, use Heading 2, 3, 4 and so on to show the structure of your document.
Do not cut and paste from Word documents or existing web pages into FrontPage. The resultant markup will include Word and other formatting styles that are not permitted for use on Monash web pages.
If you need to cut and paste from an existing document, the safest approach is to save the document as a text file (with a .txt file extension) or cut and paste into Notepad (which will removing formatting) and then into FrontPage.
When adding content to web templates, make sure you do not accidentally remove or change coding elements that make the templates work. Particular care should be taken when using a graphical editor, as most of these elements are not visible unless you are editing the HTML source of the template.
The document type declaration (DTD) is the first two lines in the template file. It tells the web browser which version of HTML is being used. A DTD looks like this:
<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
The style sheet links will appear in the first part of the file, usually a few lines below the DTD. They look like this:
<link rel="stylesheet" href="http://assets.monash.edu.au/styles/monash.css" type="text/css" />
<link rel="stylesheet" href="http://assets.monash.edu.au/styles/print.css" media="print" type="text/css" />
Two (or more) server-side include (SSI) statements will also be included in the templates. These tell the server to automatically include the header and footer files (and section navigation). They look like this:
<!--#include virtual="/assets/includes/header.shtml" -->
A named anchor is included in the templates and allows people with disabilities who may use the "skip to content" link to jump over the navigation and directly access the page content. It looks like this:
<a name="content" id="skiplink"></a>
You should be given several types of templates for use on your site. Use a home page template for your home page, and avoid the use of section navigation templates for anything other than content pages (Masterbrand sites may use section navigation pages more extensively where these provide site-wide navigation).
For formatting and layout affects, do not use HTML markup (font tags, etc.). Use the styles available in the style sheets attached to your templates.
Do not override the default alignment of text and headings. Left-aligned text and headings are easier to read.
See a list of the visual components of the template.
Navigation for your site should always be presented in either the main navigation bar or the section navigation column. You can also include links within the text on your pages.
Highlight boxes should never be used for navigation around your site. Links within and around a section should be provided in the section navigation column. Highlight boxes may be used for news items, related content, or related links. Related links are links to content in other parts of the Monash website or within other sections of your site.
Highlight boxes may only appear on the right side of your page. Never use more than two highlight boxes on each page.
See the page title guidelines.
We encourage you to incorporate the usability and accessibility features outlined in this guide.
To ensure that the quality of your website meets the required standards, you should have quality assurance procedures in place. Please see the quality assurance section of this guide for further information.
This page provides information for Monash web developers. Web authors do not need to read this information.
Note: templates should not be customised by anyone other than experienced and competent web developers. Use a text editor to ensure that HTML elements are not repositioned and whitespace is not added.
Review existing content with these aims:
The generic templates are based on a set of standard file and directory names. Make sure file and directory names comply with the guidelines for file and directory names.
Read the information in the style guide on website structure and website navigation.
Two types of generic templates are provided:
templates-html directory)templates-xhtml directory)All have been tested and validate against the relevant DTD.
Where possible, use the XHTML templates. However, do not provide them to inexperienced users unless they have a suitable authoring tool. For instance, Dreamweaver MX can write XHTML but Frontpage 2000 does not.
If you provide HTML templates, use the HTML 4.01 header, footer and other elements (contained in the includes-html directory).
A number of items will need to be changed in the generic templates in order to customise them for use. These include:
A checklist has been provided (in the documentation directory) to help you check off each of the elements of the generic template set that require customisation.
Use a text editor to customise headers, footers, etc. to ensure that HTML elements are not repositioned and whitespace is not added.
header.shtml)To ensure reasonable rendering across both current and older browsers (such as Netscape 4 which is still heavily used at Monash), it was necessary to produce two versions of the page header. An SSI is used to handle browser detection so that the correct header is displayed.
The differences between the two headers include:
display:none but Netscape 4 won't hide it, so it was omittedMake sure you edit both versions of the header.
Logo images are available at http://assets.monash.edu.au/logos/. Faculty logo names are based on the faculty sub-domain name, e.g. arts.gif, buseco.gif
alt="Monash University, Arts"Two versions of each banner image are needed.
Banner image templates supplied by Web Resources and Development (webmaster@monash.edu.au) are set up to produce images that meet these requirements.
A static banner image may be used. Larger sites may wish to use different banner images in different sections of the site. To automate this process, two SSIs (supplied with the templates) are used:
Note: do not add line breaks to the SSI file. These add whitespace around the banner image.
Faculties and sub-brands must customise the global navigation bar. For a list of requirements for global navigation see website navigation.
Schools, centres, and departments within a faculty must use the faculty global navigation.
See the requirements for utility navigation at website navigation.
To add limited scope search options to the drop-down menu, the following line should be added to the search form.
<option value="+url:http://www.arts.monash.edu.au/">Arts</option>
Replace http://www.arts.monash.edu.au/ with the appropriate sub-domain and/or directory.
All searches on publicly accessible pages must exclude intranet pages and mailing list archives by using the following hidden input field:
<input type="hidden" name="qs" value="-monash.access:intranet -monash.access:emailarchive" />footer.shtml and section-nav-footer.shtml)The footer files should be used in the format provided in the generic template set.
section-nav-footer.shtml for section navigation pages and footer.shtml for all other pages.section-nav.shtml)See the requirements for section navigation at website navigation.
See the requirements for the breadcrumb trail in the website navigation section.
A central script is used to generate the breadcrumb trail. By default, the links shown in the breadcrumb trail are based on the directory names and structure of your website. Since some directory names or structures may not be the same as the breadcrumb trail you want to display, a configuration file can be used to customise these links.
Within the generic template set there are two files which need to be customised:
breadcrumb_reg.conf - this file is located in the root directory of each server. The entries within this file tell the central breadcrumb script which areas have their own breadcrumb configuration files.breadcrumb.conf - there can be any number of these files, one in the top-most directory of a given site and others in other directories that require separate maintenance of their customisation. It contains the definitions to customise the breadcrumb trail.breadcumb_reg.conf) Each server needs one breadcumb_reg.conf file in it's root directory that identifies the locations of all the breadcrumb.conf files that are used to customise the breadcrumb trail.
For example the Faculty of Arts may need to customise the display of breadcrumbs for Schools and Centres, Chinese Studies, and the Centre for Women's Studies and Gender Research. Each customisation may have its own breadcrumb.conf file so there needs to be an entry for each of them in the breadcrumb_reg.conf file like so:
# registered locations for config files
# note: leave out slashes at the end of directories
schools
chinese
ws
If you have a breadcrumb trail that is customised at different levels by different breadcrumb.conf files, you can avoid having to define the customisation for the parent path in each breadcrumb.conf file by marking the parent location in the breadcrumb_ref.conf file with an asterisk (*). This allows you to easily change the breadcrumb for all sections just by changing it in the parent breadcrumb configuration file.
For example, a directory called study with sub-directories called access and applications each have their own breadcrumb.conf file to set up customisations.
In the breadcrumb_reg.conf file we add an asterisk after the entry for study (which is the parent directory) so that its sub-directories will inherit whatever customisation is set up in the breadcrumb.conf file for the study level within the breadcrumb trail.
# registered locations for config files
# note: leave out slashes at the end of directories
study*
study/access
study/applications
breadcrumb.conf)Because the breadcrumb trail for every Monash branded website needs to be set up to display "Monash University" and link to the Monash home page, there will be at least one breadcrumb.conf file in the top-most directory of a given site.
You may need to have a separate breadcrumb.conf file for other levels of a site if:
Each breadcrumb.conf file must be registered in the breadcrumb_reg.conf file or the entries within it will not be processed.
Within this file there are three sections which may need to be customised.
For every site within the Monash brand the first breadcrumb in the breadcrumb trail will be "Monash University" which links to the Monash home page. Sites with their own sub-domain (eg http://arts.monash.edu/) can add entries which follow "Monash University" by using the SITEROOT attribute. For example:
# SITEROOT=Link text; Link URI
SITEROOT=Arts Faculty; http://arts.monash.edu/
There can be multiple SITEROOT entries. The order in which they are listed will be the order they are displayed in the breadcrumb trail.
The breadcrumb trail is generated by default to use the names used in the directory structure so if you have a directory name "scholarships" the script will automatically generate the text "Scholarships" in the breadcrumb trail. If you want to use different text in the breadcrumb, you have to define an alias.
An entry for an alias consists of the directory name and the text you want to display in the breadcrumb.
# Format:
# ALIASDIR=directory
# ALIASNAME=Alias name
ALIASDIR=web
ALIASNAME=Web Style Guide
ALIASDIR=legal
ALIASNAME=Legal requirements
ALIASDIR=branding
ALIASNAME=Branding and visual identity
ALIASDIR=navigation
ALIASNAME=Navigation and site structure
Because you may have more than one directory with the same name in a directory structure, you may need to have more than one breadcrumb.conf file at various levels in the directory structure so you can set up different aliases in each. Remember to add the location of any new breadcrumb.conf files to the server's breadcumb_reg.conf file.
There may be times when the directory structure is different from what you want displayed in the breadcrumb trail.
For example, on the Monash Library server there is a matheson directory. The address of this directory is http://www.lib.monash.edu/matheson/. With SITEROOT entries on the library server to start the breadcrumb trail with "Monash University > Library" and an alias for the matheson directory of "Matheson Library" the breadcrumb trail will appear like this:
Monash University > Library > Matheson Library
But there is information missing from the above breadcrumb trail. We want it to include a link to the libraries page with the displayed text "Branches".
So within the directory mapping section we can specify the matheson directory, using the MAPDIR attribute, and, with the MAPPATH attribute, specify the entries which will appear in the breadcrumb trail. The order of the MAPPATH entries determines the order of the breadcrumbs in the trail.
# Format:
# MAPDIR=directory;reset
# MAPPATH=link name; link URI
MAPDIR=matheson
MAPPATH=Branches; /libraries/
MAPPATH=Matheson Library; /matheson/
This will make the breadcrumb trail appear like this:
Monash University > Library > Branches > Matheson Library
In the above example we expanded one directory into two breadcrumb references. It is possible to have multiple directory mappings which expand several directories into multiple references. Here is an example for http://www.lib.monash.edu.au/clayton/matheson/.
MAPDIR=clayton; reset
MAPPATH=Campuses; /campuses/
MAPPATH=Clayton; /clayton/
MAPDIR=matheson
MAPPATH=Branches; /libraries/
MAPPATH=Matheson Library; /clayton/matheson/
This will make the breadcrumb trail appear like this:
Monash University > Library > Campuses > Clayton > Branches > Matheson Library
In the above example the first directory mapping (MAPDIR=clayton) is followed by "; reset". If there is already a directory mapping in another breadcrumb configuration file higher up in the hierarchy, that entry will be reset and the mapping described in this configuration file will be used.
All faculty and sub-brand sites should have both a site map and an alphabetical index of web pages. This is highly recommended for Masterbrand sites.
All sites must have their own error messages for errors 401, 403, 404 and 500 in order to improve the time and quality of responses to errors reported by users. Do not change the text that users will see.
Change the following in each of the HTML files:
CgiMailerReferer form field to give the correct address of the error page.On the response pages update the following:
An .htaccess file must be put in the home directory of the site. The file should include the following:
ErrorDocument 401 /assets/errors/401.html
ErrorDocument 403 /assets/errors/403.html
ErrorDocument 404 /assets/errors/404.html
ErrorDocument 500 /assets/errors/500.html
*template.html)Create the following:
There should be at least two SSI statements in each template - one for the header and one for the footer. Section navigation templates will have a third enabling the inclusion of section navigation.
Each template has a named anchor associated with the "skip to content" link. It looks like this: <a name="content"></a>, appears beneath the header SSI, and is marked with a comment tag.
There should be two stylesheet links in the top of each template. One provides screen display styles. The other contains print styles. Remove this only from templates used for home pages. Add a third stylesheet link on faculty and sub-brand sites (see below). This enables the use of approved web colours for these sites.
<link rel="stylesheet" href="http://assets.monash.edu.au/styles/arts.css" type="text/css" />
For more information, see cascading stylesheets.
Each template includes keywords and description metadata fields. Remove them unless you are confident they will be understood and used.
author-guide.doc)Generic documentation for web authors has been created and included in the documentation directory. It should be customised to provide information about the site structure and directory names. Ensure that the document is provided whenever customised web templates are created for web authors.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> The Monash University logo is comprised of the following elements:
The logo used on Monash websites differs from other versions of the logo:
<!--#echo var="LAST_MODIFIED"-- > Web Resources and Development (WRD) can provide assistance with customising templates, but only where faculty or divisional teams do not have the expertise. To obtain templates or assistance, contact your local web team first.
© 2010 Monash University