All UCC web pages are required on the specific instructions of the College to be viewable (completely, but not necessarily optimally) in all browsers. The publishing of pages which will only work with a specific make or version of browser is not permitted unless they are intended for a restricted set of users such as members of an intranet site or committee, where it is known that all those users have the required software, and where control of the software version is possible.
‘Completely, but not necessarily optimally’ means that your information MUST be visible to all users even if it means sacrificing some of the aesthetics of layout or formatting for those users who do not have the full level of technology available. While the development of pages which present a ‘rich browsing experience’ (to use the designer/marketing jargon) is encouraged, this MUST NOT be at the expense of those who cannot see the information.
All designers MUST read the note about the Web Content Management System. All new UCC web sites for colleges, faculties, departments, offices, units, and centres MUST conform to the standard UCC page designs by using the CMS. The former free-for-all of allowing any site to look any way is not permitted. There are some exceptions for research projects, and for student clubs and societies: see the warning panel ‘Using the Content Management System’.
Do not write pages which lock out specific classes of users (eg Microsoft users, Mac users, Unix users, users with disabilities, etc). Pages which infringe these rules will be removed or made inaccessible without warning and replaced by a functional version which fulfils this requirement. For further information on making pages accessible to those with disabilities, please see the Irish National Disability Authority IT Accessibility Guidelines.
Remember that the site you are in charge of is not your information, it's UCC's information: you are only the custodian for the time being. Don't do things which will foul it up for whoever comes after you.
Designers are REQUIRED to provide technical documentation which describes what they have written and how to maintain it in future. Sites which are created without functional documentation will be deleted.
Designers SHOULD read the article by Jeffrey Zeldman referred to earlier, 99.9% of Websites Are Obsolete, which explains some of the reasons why these rules are here.
HTML pages MUST be written to one of the common publicly-available DTDs or Schemas (eg those from the W3C, ISO, or IETF) and SHOULD validate against that DTD/Schema—preferably XHTML or HTML5—but MUST be well-formed. (This is because they may end up needing to be moved automatically to XML () in the future, and ensuring validity at this stage avoids any parsing problems, otherwise you will need to re-edit them all manually). Existing invalid files SHOULD be passed through HTML Tidy or a similar filter like Bobby and post-edited to conformance. Script- or database-generated pages MUST also be well-formed.
The use of US-ASCII or one of the ISO 8859 character encodings is mandated for Latin-alphabet pages. If your web editor produces some other (proprietary) character encoding by default (such as Windows-1252 or Mac-Roman-8) you MUST change it, as it will be invalid, and private character sets restrict the number of browsers which can view the pages. If you need to use characters from more than one character repertoire, use UTF-8 encoding and ensure that your files are stored in the filesystem in UTF8 format. Do not use non-standard encodings like Big5.
All sites MUST identify UCC on their front page or on a contacts page, with the name of the site, the UCC email address, and phone number of the department, unit, office, project, club, or society. The use of off-site (non-UCC) email and web addresses for principal UCC contacts is not permitted under any circumstances: UCC provides all users with an email address so that off-site addresses are unnecessary. Pages found using non-UCC addresses for UCC contacts will be edited without notice to change them.
Dependence of pages on deprecated options or manufacturer-specific code is forbidden. This should not stop you using such code for illustration, decoration or enhancing navigation, it only means your pages MUST NOT depend solely on such code for them to be used.
If links are instantiated as graphical images, you MUST provide textual equivalents for those using non-graphical browsers and for those with disabilities (this is best done using the ALT attribute to the IMG element type, which is compulsory for all images anyway).
The use of non-default fontnames on their own is forbidden (eg styles MUST use ‘Helvetica, Arial’ not just ‘Arial’). Font specifications MUST provide for graceful degradation (eg provide multiple font specs as in the example in the warning panel ‘Font abuse’). To avoid problems with broken versions of Microsoft Internet Explorer, always specify ‘Times New Roman’ rather than just ‘Times’.
Use CSS stylesheets wherever possible rather than inserting style information in the HTML code. Design the pages within the restrictions of the technology, just as you would for paper, or radio, or TV: don't try to mimic paper designs on the screen. If a particular style or layout feature doesn't work in some browsers (eg tables in pre-tables browsers, or CSS styles in early or broken browsers), then arrange that those users will at least see the textual information (unformatted if necessary) and accept that they will not be able to see the same design as users of conformant browsers can, rather than filling the files with massively obstructive code and scripting in a desperate attempt to force a 21st-century design down the throat of a 20th-century browser.
Pick sensible and meaningful URIs. Brevity is not so important as usability: few people these days have to type URIs manually, as they are mostly links, or presented in a format that can be copied and pasted. Never use spaces or punctuation in URIs (except hyphen, slash, period, and underscore), as these prevent some browsers from accessing the page. Do not expose personal data (ID codes, staff numbers, etc) as field values or directory elements, especially in script-generated URIs.
Total graphics volume on any one page SHOULD NOT exceed 512KB unheralded (the same applies to links to external binary files). This is roughly the amount that can reasonably be expected to download on average within seven seconds on a marginal domestic 2Mb/s throughput broadband connection; seven seconds is the average amount of time a user is prepared to wait before giving up and going elsewhere (eg see JWU's guide, p.7).
Exception: pages (but never a home page) where the image or downloadable file is the feature and the user is made aware of this on the page[s] linking to it.
All images SHOULD be between 72dpi and 108dpi for optimum efficiency and SHOULD NOT exceed 1024 pixels wide. See the article on Graphics support for details of how to do this.
Design within the default screen size of 800×600 pixels, less an allowance for frame borders, toolbars, and scrollbars. Although all modern screen come preset to 1024×768 at a minimum, some users deliberately pick the coarser resolution (for unknown reasons), and resent having to scroll your pages sideways.
Do not use other proprietary or platform-specific graphical, video, or audio formats, or those which use unnecessarily large file sizes like BMP or TIFF: stick with common public formats like GIF, PNG, JPG, MPG, and OGG which all users can access.
No table may be taller than one screen height (at 1024×768 using a nominal 12px font; that means about 800 pixels less the height for menus and borders) unless there are compelling reasons otherwise (such as long lists or tabulations which have to be treated integrally). The reason is that too many untrained users (everywhere) don't realise they can scroll down the screen, so they miss stuff which is not ‘above the fold’.
Use the old journalist's rule for your text content: say it all concisely in the first paragraph and use the rest of the page for longer explanations. Don't put the important stuff at the bottom of a long page unless this is an unavoidable aspect of the document structure (for example a list like this which cannot be read until other things have been explained first). Never use text drawn in images unless you show it in normal text elsewhere in the page.
If you store data in non-text form (in a database, for example) make sure that you regularly export a master copy in text form for backup. Storing sole or master copies in binary formats only is a recipe for disaster.
All documents MUST have a
sensible and meaningful title in the HTML
<title> element in the header
which reflects what the document is about. This is
compulsory in HTML, as it is used for searching as well as
the browser title-bar, and is the first impression that
users will get of your pages when they search for you in the
campus search engine or Google. Pages with missing, default,
or meaningless titles don't just look silly, they make UCC
look silly. If such pages are found on the UCC site they
will be removed.
HTML provides H1, H2, H3,…H6 header levels for identifying section headers in your document. You SHOULD use them for headers because they will be recognised by search engines as important. Do not use web editing software which fakes them up with fonts because such pages will not be adequately indexed. Use a CSS stylesheet if you need to change the appearance of headers. Example: the following information will be recognised by a search engine as important because it identifies itself a header:
<h2>Ontology and Semantics</h2>
The following will not because it's simply formatting junk (and invalid HTML) and has no meaning:
<div align="left"> <font color="#ffcc99"> <table cool width="1025" height="644" border="0" cellpadding="0" cellspacing="0" gridx="32" showgridx usegridx gridy="32" showgridy usegridy> <tr height="1" cntrlrow> <td width="1" height="1"></td> <td width="64" height="1"><spacer type="block" width="64" height="1"></td> <td width="512" height="1"><spacer type="block" width="512" height="1"></td> <td width="64" height="1"><spacer type="block" width="64" height="1"></td> <td width="384" height="1"><spacer type="block" width="384" height="1"></td> </tr> <tr height="64"> <td width="1" height="64"><spacer type="block" width="1" height="64"></td> <td width="640" height="64" colspan="3" rowspan="1" valign="top" align="left" xpos="0"><img height="64" width="640" src="gold_bar.jpg"></td> <td width="384" height="64" colspan="1" rowspan="1" valign="top" align="left" xpos="640"><img height="64" width="384" src="top_bar.jpg"></td> </tr> <tr height="579"> <td width="1" height="579"><spacer type="block" width="1" height="579"></td> <td width="64" height="579"></td> <td width="512" height="579" colspan="1" rowspan="1" valign="top" align="left" xpos="64" content csheight="579"><span class="a"><span class="b"><b><br><br><br><br>Ontology and Semantics</b></span></span></font> ...
(Yes, that is taken from a real-life example. It displays exactly the same as the preceding example. No prizes for guessing which is the easier to use.)
All documents SHOULD
meta elements in the header giving
keywords to assist searching, eg
name="Keywords" content="whales dolphins">. This
lets your document be found even if the actual text doesn't
contain one of the keywords itself.
In addition to the keywords, there is a set of metadata
values known as ‘Dublin Core’, which
can be implemented using the
meta element in
the header as well, eg:
<meta name="DC.creator" content="Jacques Derrida"> <meta name="DC.title" content="Ontology and semantics"> <meta name="DC.subject" content="Deconstruction of analytical terminology in text criticism">
There are more details of this method at http://www.dublincore.org/
If you use Microsoft Word and ‘Save
As…’ HTML, make sure you first edit the
Document Properties (use the
.doc) files, and in this case you
SHOULD also clear the
‘Undo’ history so that people cannot
open your file and use the ‘Undo’
feature to see all your past edits. To clear the
‘Undo’ history, click on the
menu item, check all options, and then click
, then click on the
Total colour palette should still render acceptably (not necessarily optimally) on 256-colour (8-bit) screens. Do not make your site depend on users having 24-bit or 32-bit colour: stick to the 6×6×6 ‘Netscape’ colour palette. Check for colour contrast on a monochrome screen or by printing a screendump on a black-and-white printer or by using HP's colour contrast checker or the tools at Vischeck.
Keep the size of individual files reasonable: the overall limit of seven seconds download time applies to total page size (text plus graphics). Especially, do not use Word or Powerpoint files if you can achieve the same effect in HTML or PDF (which is almost always possible). Never use high-resolution PDFs straight from a designer without rerasterising the images to speed up the downloads. Approximate download times for different file sizes are:
|Location||10Kb (eg an average web page)||100Kb (eg a very large web page)||1Mb (eg a small PDF)||30Mb (eg a large PDF)||500Mb (eg a grotesquely large PPT or a small video)|
|Dial-up (56Kb/s)||2.2 sec||22 sec||4 mins||2 hours||22 hours|
|T1 (1.544Mb/s)||0.079 sec||0.79 sec||8 sec||4 min||1.5 hours|
|Broadband (2Mb/s)||0.06 sec||0.6 sec||7 sec||3.5 min||30 min|
|T3 (45Mb/s)||0.003 sec||0.03 sec||0.3 sec||8 sec||7 mins|
|LAN (100Mb/s)||0.001 sec||0.01 sec||0.1 sec||4 sec||4 mins|
|Gigabit (UCC)||0.0001 sec||0.001 sec||0.01 sec||< 1 sec||< 1 min|
(Speeds based on 80% throughput.)
Font size MUST not go below 7 pixels high at any resolution. Bear in mind many new machines will now do 1400×1220 or greater resolution, so small type or frames will be unreadably tiny or cramped. Never force a specific (absolute) font size or line length, always use relative or percentage values so that pages can be dynamically rescaled.
Be aware that many versions of Microsoft Internet Explorer have a badly broken font-sizing model, and incorrectly display type at up to several times the real size, depending on font. This tempts designers to try and force the font size down too far, with the result that users of other browsers cannot read it at all. Always check rigorously in other browsers if you use small sizes of type.
There MUST be no dependence on frames, graphic-only menus (imagemaps) or embedded scripts: use them by all means but do not make your pages depend on them alone. We cannot risk some users (especially funding agencies, disabled users, or potential students) being unable to see vital information. Embedded scripts are fine so long as the page does not depend on them. Server-side scripts MUST be documented and maintainable and MUST not place undue load on processing (scripts have to be installed by IT Services: users do not have authority to install their own scripts). Frames and imagemaps are OK provided the information is accessible in text-mode also. Frames MUST be avoided on home pages because of the navigational problems caused by nested embedding and involuntary transclusion (‘page stealing’).
Check your pages in at least the following browsers: Microsoft Internet Explorer 6, 7, and 8 (Mac and Windows) and Firefox 2 and 3 (Unix, Mac, Windows). If possible, also check in a recent version of Opera (Unix and Windows), Safari (Mac), and Galeon (Linux). Bear in mind that UCC is a university site, and up to 50% of external users will not be using Microsoft browsers.
It is no longer necessary to test in Netscape or MSIE v5 or earlier, as these are regarded as obsolete (anyone using them can upgrade to Firefox, even on obsolete hardware). Tests for text-only usage should be conducted using Lynx (there is a test page which uses this at http://www.ucc.ie/cgi-bin/uncgi/blind).
There is a recent summary of browser types used to visit the web site at http://www.ucc.ie/webusage#browsum.
|Keep up to date with our RSS newsfeed||
, Electronic Publishing Unit • 2018-05-20 • (other)