UCC Web Site Owner's Guide

7. Requirements for site authors and designers

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.

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 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.

• Use a DTD

  HTML pages must be written to one of the common publicly-available DTDs (eg those from the W3C, ISO, or IETF) and must validate against that DTD—preferable XHTML. (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 valid.

• Character encoding

  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.

• Contact

  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.

• Code dependence

  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.

• Graceful degradation of images

  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).

• Font specification

  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 you must 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’.

• CSS

  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.

• Addresses (URIs)

  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.

• Graphics

  Total graphics volume on any one page should not exceed 256Kb 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 32Kb/s throughput dialup 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.

• Screen size

  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.

• Animations

  The use of proprietary animation techniques such as Macromedia's Flash must be avoided on home pages because up to 40% of users will be unable to view the page (because they cannot install a plugin) and it makes the site completely inaccessible to the visually disabled. Keep Flash movies to secondary pages or lower, and give users adequate warning in the links which lead to them. Do not use 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.

• Tables

  No table should be taller than one screen height (at 800×600 using a nominal 10pt font; that means 600 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’.

• Content

  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.

• Document titles

  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.

• Section headers

  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:

  Terminal Commands

  _=X

  <h2>Ontology and Semantics</h2>
  	  

  The following will not because it's simply formatting junk (and invalid HTML) and has no meaning:

  Terminal Commands

  _=X

  <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.)

• Metadata

  All documents should contain HTML meta elements in the header giving keywords to assist searching, eg <meta 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:

  Terminal Commands

  _=X

  <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/

• Document properties

  If you use Microsoft Word and ‘Save As…’ HTML, make sure you first edit the Document Properties (use the  File | Properties  menu) and set the title, author, and other properties correctly. Failure to do this will result in your file being wrongly indexed. This also applies if you upload Word (.doc) files, and in this case you must 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  Tools | Protect  menu item, check all options, and then click  OK , then click on the  Tools | Unprotect  menu item.

• Palette

  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.

• File size

  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 (I)

  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.

• Font size (II)

  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.

• Frames, imagemaps, and scripts

  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 must be installed by the Computer Centre: 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 browsers

  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.