Commonwealth Computer Navigator's Certificate/Milestone 4/Media guidelines

Media Development Guidelines

For Outstanding Actions/Questions, see the discussion tabbed page

The CNCC materials are developed in 2 stages:

1. Source content (script)

• Development is in WikiEducator
• Flash files demonstrating how to use Open Office may be inserted into WikiEducator.
• Audio files may also be inserted into WikiEducator.

2. Final Output (media-rich, activity-rich: SCORM or Web packaged)

• WikiEducator Content is pulled into the [http://eduforge.org/projects/exe/ eXe authoring tool. Look in the Files section of this project space to download the relevant version of eXe. For the CNCC project we will use eXe Version ?
• Content can be further enhanced/authored in the tool (e.g. activities added)
• eXe provides options for exporting the eXe files (.elp) as SCORM packages, packaged web pages, etc.

Note: Metadata processing is still to be determined.

In addition to these Media Guidelines, we recommend you look at the 'Editing Guidelines'.

Using WikiEducator to develop content

Learning how to use WikiEducator

We strongly recommend that you take the Basic Tutorial on how to use WikiEducator.

In particular the tutorial explains about basic editing and inserting Images and Media. You will also learn about any specific file type constraints.

Using Templates

WikiEducator Design Templates have been established for the CNCC Module, Section and Sub-section pages.

Pedagogical templates in Wikieducator

The template provides the wiki tools and pedagogical icons (iDevice Templates) for authors to write the content. Additional support resources include:

• The tutorial on Pedagogical Templates provides guidelines on how to use iDevices in the wiki; and
• the summary of template guidelines.

Tip: Template is a technical feature of the Mediawiki software where layout and navigation features are included in a wiki page using two "curly" brackets {{ ...}}, where the instructional design template refers to the overall learning design features to be used for the CCNC development

Using eXe to develop your learning materials

eXe is an authoring tool which enables you to build a structure and learning activities to support the learning outcomes.

eXe can be used off-line to develop your learning activities.

eXe contains a number of 'iDevices' (learning activity templates). Using the content from the WikiEducator pages, you can choose to take more activity-based approaches to your learning design using eXe activities. For example, building interactive questions.

eXe Style Sheet

CSS - Action: Identify a style sheet to be used by the CNCC project.

Generic Technical Information

The following technical information supports good practice principles of modularity, accessibility and web development (coding).

Acceptable Download Time

Use of video is really useful, but if being delivered online, think about the impact of download time. Try to keep video to max. 2 mins runtime.

Web-delivered materials should be optimized so that every page loads in the browser in less than 5 seconds on a 56kb connection (threshold of frustration). Determining a page budget and sticking to it will help to achieve this. Page budget should ideally not exceed 50KB. Media rich materials are likely to go over this limit however pages should be designed in a way to minimise any inconvenience to the user. For example, larger Flash movies should employ a preload sequence which starts within the agreed 5 seconds and which displays a visual notification of percentage loaded. Additionally, such movies should be built in a modular fashion to minimise the need for extended preload times.

Coding Standards

All code written in support of courseware production should be richly documented in a manner consistent with best software-development practices.

Clear comments should be included, where appropriate, in both XHTML and CSS code. In complex pages, page elements should be clearly signposted. For example using and to ‘bracket’ page content at code level. In CSS style sheets, appropriate comments should be used to ease maintenance. For example, /* Styles MAIN NAV tabs */.

Additionally, all classes and id’s defined either for stylesheets or page elements (accessible forms or tables) should use clear and meaningful naming strategies. For example, use class=”grey box” and id=”navbar” rather than class=”ov_124”.

Rationale: collaborative working practices on complex development projects require that each developer clearly document their code and code structures. This is especially important in the arena of Open Source where the materials need to be built with future redevelopment or disaggregation in mind.

Use of Tables

Tables should be avoided for layout or design purposes. Instead, style sheets should be used to control page layout, and to define the style of courseware, even though cross-browser limitations to this approach exist. Use of tables as a page-formatting device is unacceptable and should be avoided. Only data tables containing information requiring a comparison matrix should be used. Strong consideration should be made of the use of semantic, bulleted or numbered lists for collections of data.

Known issues with table layouts include

• Trouble for users with narrow window settings
• Large fonts preferred by some users can cause problems
• Issues when tables are fed into non-visual browsers or assistive technologies such as a refreshable Braille display.
• Complex nested tables may result in slow download

Tables should use accessible mark-up:

• Use the caption element to associate the table title with the table itself and use the summary attribute of the table element to describe the overall structure of the table.
• Use the table header element, TH, to indicate cells with header information and define scope="col" or scope="row" where appropriate.
• For tables whose structure is more than just simple column and row headers use the id attribute on all header cells and use the headers attribute on data cells to indicate heading information that applies to each cell. [see http://www.usability.com.au/resources/tables.cfm#complex]
• The appearance of tables should be defined by the master CSS style sheet.

Use of Images and Graphics

The following notes will guide you in how to use graphics/images in course materials:

• Graphics/images that convey meaning and enhance the message being communicated are important features of a good design.
• Use of graphics/images to encapsulate text for navigation should be avoided unless that approach will improve clarity and usability.
• Animated GIFs or other animations should play once and stop, with an option to replay the animation at the user’s discretion. Continuous movement acts as ‘visual noise’ and goes against usability and accessibility best practice.
• Include alt, height, and width attributes for every image.
• Create quality alt text captions. The alternative text should be consistent, clear and, most importantly, useful. When an image is not a link and carries no information or is redundant, use a null alt (alt=" "). In such cases consider whether this image should actually be used. [see http://www.jimthatcher.com/webcourse2.htm] At the very least, it should be a CSS rather than an inline element.
• Consider using a long-description and corresponding D-Link to provide more detailed information than a simple alt caption. See http://www.wac.ohio-state.edu/tutorials/bestpractices/images.htm. Example, in the OER NZ project we used the legend ‘Text Equivalent’ in addition to the WCAG standards’ compliant ‘[D]’.
• Deliver all graphics together with source files (.psd file if Photoshop is used)
• Use appropriate compression format (.gif or .jpg)
• Images should be high quality (not pixelated or blurry)
• All text legends should be legible (special consideration should be made for laptop LCD displays – test as early as possible in the design process). Ideally only use anti-aliasing on 14pt+ font sizes.
• All IPR and Copyright issues resolved (any licensing or requirements for author accreditation labelling should clearly be documented [in metadata database?].)
• Vertical and horizontal spacing should be provided around images and graphics to stop wrap-around text from crowding the media element.

Use of Flash

Think about the following when using flash authored content:

• Flash movies should be exported to cater for two versions prior to the current flash plug-in. *Do not use the Flash 8 ‘Stroke Hinting’ feature for vector graphics as the processing power required for runtime rendering is considered excessive for legacy machines.
• Do not use anti-aliased text or Flash8 ‘alias for text’ for body text. Use ‘no anti alias’ instead. [Flash8 calls this ‘Bitmap text (no anti-alias)’]. As ideally the flash materials are to be built for the flash7 plug-in newer aliasing technologies cannot be employed. As with text legends in images and graphics, titles or headings using larger fonts (14pt+) can be anti-aliased to improve appearance. The intention is for all text to be legible (special consideration should be made for laptop LCD displays – test as early as possible in the design process).
• Make sure that fonts are embedded for dynamic text-boxes. Depending on the scale of the flash project this should either be done as a font symbol (loaded from a shared library if appropriate) or by character embedding, remembering to include Uppercase, Lowercase, Numerals and Punctuation glyphs (as required).
• Use a D-Link and the legend ‘Text Equivalent’ to provide a text alternative. See http://www.wac.ohio-state.edu/tutorials/bestpractices/images.htm. For example in the OER NZ project we use the legend ‘Text Equivalent’ in addition to the WCAG standards’ compliant ‘[D]’.

The syntax for inserting a flash file in WikiEducator: <flash>file=filename.swf|width=800|height=489|quality=best</flash>

Document Headings

Use these guidelines regarding document headings:

• The XHTML heading scheme should be used to convey the relative importance of elements in a document (h1, h2, h3...). Note that when using eXe, this should be catered for by the stylesheet.
• Every document should have one and only one h1 element and as many of the other elements as needed
• Authors should not choose a heading level based on the font size commonly used by visual browsers; the heading level should be chosen based on the heading's importance and placement in the document.
• The <font></font< tag should never be used. It is particularly inappropriate for headings (e.g. <font size="20"></font> instead of h1), as it does not convey the structure of the document.

Rationale: The semantic layout of document structures into clear headers, paragraphs and lists, not only helps users with cognitive impairments or learning disabilities but should be generally considered as usability best practice, making materials easy to understand for all users. The use of headings is further clarified in the Editing guidelines documentation.

Frames Should Not be Used for General Navigation

Frames should not be used for cross-site navigation. Although effective for small-scale and target applications, the disadvantages of frames outweigh the advantages. Issues with frames include:

• Users may bookmark individual pages nested within a framed document, thus losing context and navigation
• Framed documents are usually not printed properly; the "Print" command results in the printing of a single frame, rather than the whole screen
• Users of assistive technologies have difficulties deciding which document in the frame-set requires focus. The descriptive naming of frames is not always enough to help such users.
• Older browsers do not support frames

Exceptions to this rule will be considered on a case-by-case basis. Present a written justification prior to development. In cases where frames are used <noframes> content should be created for the pages in question. For detailed information about frames see What's Wrong With Frames.

If a scrollable region is required then CSS should be used to simulate this frame effect. [see http://tutorials.alsacreations.com/frames/] Care should be taken that such pages function as expected in older browsers.

External Links

Links to external websites (virtual resources) may be necessary in the provision of reading sources or as a research activity. It is important however to minimise this usage as far as possible.

Issues include:

• requires users to be online (may not be the case if re-purposed by other institutions for off-line use)
• maintenance and checking of these links cannot be done after the learning object has been packaged and uploaded to a repository
• Links to other learning objects (other parts of the same courseware) should be avoided.

Rationale: Building with IMS and SCORM Content Packaging in mind puts limitations on the interaction between parts of the courseware. At the lowest intended level of granularity, each learning object should function as a stand-alone object.

Deep Linking

Try to ensure that all content can be accessed within a maximum of three clicks. Its accepted that sometimes, due to gaining benefits of good page layout and accessibility, this may be unavoidable.

Accessible links

• Text links to documents should be consistent, descriptive and convey meaning. For example do not use ‘Click here’, use ‘next page’ instead. The href title attribute should impart additional meaningful information (for example ‘Opens in a new window’). Do not use a title attribute unless appropriate (note that this attribute is not supported in XHTML 1.0 Strict)
• Two or more links on a page should not share the same link text or title attribute.
• Split consecutive links by using, for example, the vertical bar ( | ) character with a space before and after. This will aid visually impaired readers. (NB. Bobby accessibility validation requires that more than whitespace separates adjacent links)
• For the benefit of viewers with, eg, low vision, or dyslexia, contents links should show which pages have been accessed.

Use of Plug-ins

The web delivery of rich media materials is complicated by the plethora of plug-ins and associated file formats which exist to deliver everything from audio, video, animations, print-ready documents and three dimensional simulations.

Users do not always have the necessary administration rights, inclination or technical knowledge to download or install additional plug-ins on their computers. For this reason the number of plug-ins required to run a particular learning object should be minimised. Flash has become ubiquitous across both mac and PC platforms and should be used wherever possible to deliver interactive audio/visual media even though alternative (and more efficient) technologies exist.

Recommended plug-ins:

• Flash (version 7)

To be avoided where possible:

• Shockwave (bloated)
• Authorware (bloated)
• QuickTime Player (platform specific - although some PC users will have access to it, not all will want to install it)
• Windows Media Player (platform specific)
• Real Player

File formats

The issues of file format are mostly taken care of by the fact that we are using WikiEducator and eXe to produce the CNCC Modules. However you will need to take note of some media file formats.

For development we will use any of the following:

• XHTML (.html) For the web delivery of content
• Flash (.swf and .as at runtime, .fla for authoring)
• Text Files (.txt) For data required by flash movies at runtime
• XML (.xml) For data required by flash movies at runtime
• Rich Text Format (.rtf) For readings and where a web-page delivery is thought inappropriate.

• Images
  • JPEG (.jpg)
  • GIF (.gif)
  • PNG (.png) See note below.
  • SVG

Note: the PNG format is both a binary and source file format. It is used by both compressed images and animations (similar to GIFs) but it is also the native authoring file format for Macromedia’s Fireworks graphics package (analogous to Photoshop’s PSD). Care should be taken to prepare authoring PNGs using ‘the Optimize for Web’ option in Fireworks. IMPORTANT: PNG transparencies are not supported by all browsers and so it is recommended that the format be only using for authoring and not for delivery.

Some media file issues to be aware of:

Audio and video materials pose particular problems with regards to file formats. It is recommended that Flash technology is used to deliver such materials wherever possible. Simple players should be created which load and play external media assets; Its recommended that .flv (for video) and .swf (audio) files should be created (A tool you might consider is Sorenson Squeeze - where you can specify some parameters for Flash files to run media assets).

Audio mp3 is probably preferable for audio assets [Project owners will take care of any licensing issues about mp3 usage and this project].

Special care should be taken when preparing podcast materials for digital music players. Real Media, Wav, Wma, Aiff, m4a, Ogg Vorbis and Flac (etc.) formats are inappropriate as they are either proprietary or platform specific or lack widespread support by portable and software players. Using the mpeg layer 3format is an obvious solution however the commercial (revenue-generating) distribution of MP3's requires a license from its patent owners [see: http://www.mp3licensing.com/help/index.html]. This should be carefully considered by the Project Manager on a case by case basis. (This requires further research and clarification by the COL legal advisers)

Packaging guidance.

Scorm packaging within eXe will take place at the Section level. The Scorm package includes the content as well as all the 'assets' such as style sheets (CSS) needed to run the courseware.

A number of items should be made available within the package for future developers: The original .elp file (the source eXe file, which will include media sources used) eXe provides the facility to produce a SCORM packaged output.