LO Development Guide

LEARNING OBJECT
DEVELOPMENT GUIDE
TUESDAY, MARCH 30TH, 2004
Prepared By
204 - 1010 Chilco Street

Vancouver, BC, Canada / V6G 2R6
TABLE OF CONTENTS
01 INTRODUCTION 4
A Who Should Use This Guide 4
B Purpose Of This Guide 4
C Expectations of the Developer 5
D Living Document 6
02 LEARNALBERTA.CA ENVIRONMENT 7
A LearnAlberta.ca Overview 7
B Presentation of Learning Objects on LearnAlberta.ca 7
C Where Learning Resources May Be Used 8
D Additional LearnAlberta.ca Reference Guides 9
03 DEPLOYMENT ENVIRONMENTS 10
A Performance Factors 10
B Displays 12
C Browser Navigation Bar and Browser Chrome 13
D Accessibility Standards 13
04 THE LEARNALBERTA.CA WRAPPER 15

A What is it? 15
B Why do we need it? 15
C What is on the Wrapper? 16
D What is not on the Wrapper? 16
E What are the rules? 17
F LearnAlberta.ca Icon Treatment 18
G Functional Design 19
H Must Be Removable 19
I Visual Treatment Guidelines 19
J Some Examples 20
05 FUNCTIONAL DESIGN 22
A Guidelines for Common Elements 22
B Media Control Elements 28
C Navigational Elements 34
LEARNALBERTA.CA LEARNING OBJECT DEVELOPMENT GUIDE 2

TABLE OF CONTENTS
06 GUIDELINES FOR CONTENT PRESENTATION 37

A Text Content 37
B Thumbnails 38
C Rich Media 39
07 CODE DOCUMENTATION AND MEDIA CREATION 40

A Programming 40
B General Naming Conventions 42
C Directory Structure 43
D Image Files 44
08 MEDIA SPECIFIC DEVELOPMENT 45

A Flash 45
B Director 48
C LiveStage Professional (QuickTime) 52
09 LEARNING OBJECT SPECIFIC STYLE GUIDE 58

A Why a Style Guide? 58
B Style Guide Audience 58
C Libraries 58
D High Level Outline 58
10 REFERENCES 61
A Internal 61
B External 62
11 GLOSSARY OF LEARNALBERTA.CA TERMS 64

01 INTRODUCTION
The LearnAlberta.ca Learning Object Development Guide is the primary resource for developers to use
while creating learning objects for the LearnAlberta.ca portal. This document acts as the hub, or umbrella
document, for the following documents related to LearnAlberta.ca:
1) Content Development Technical Specifications

2) Functional Design Guidelines
3) Instructional Design Guidelines
4) User Interface Design Guidelines
5) Guidelines for Recognizing Diversity and Promoting Respect
The LearnAlberta.ca Learning Object Development Guide will cite the above-mentioned documents
throughout, but is not meant to replicate any of the information contained in those documents. So,
developers must be comfortable with the abovementioned documents first, before using this guide.
It is recommended that this guide be read in its entirety, however, it is also structured to act as a convenient
reference guide. It allows quick access to important information required for specific tasks.
1.A WHO SHOULD USE THIS GUIDE
This document is intended for internal and third party developers working on learning resources for
LearnAlberta.ca. However, project coordinators will also find this document useful in assessing the work
being performed by these developers.
1.B PURPOSE OF THIS GUIDE
This guide will provide high-level guidance on how to create learning resources for the LearnAlberta.ca
portal to ensure:
1) Consistency
Consistency means that the user will immediately ‘know’ upon launching the object, that it is
a LearnAlberta.ca resource. It is important to understand that consistency does not mean a
common ‘look and feel’ as it might apply to a typical Website. Learning objects will have very
different looks from one to the next since we are dealing with a wide range of learners (K-3 level to
post-secondary), and a wide variety of subjects.
2) Quality
Quality means that every learning object will reflect the best workmanship that each developer is
capable of providing. Each learning object will undergo pre-planned tests to ensure the utmost
refinement upon completion.
3) Reusability
Reusability means that the learning objects will be created with certain prescribed elements and
founded upon some predetermined procedures so as to optimize the ease and flexibility of use by
a third party after the product is turned over to Alberta Learning.

01 INTRODUCTION
1.C EXPECTATIONS OF THE DEVELOPER
The LearnAlberta.ca Learning Object Development Guide is not a ‘how to’ guide. It assumes that
the reader is an experienced digital media and Web professional. As such, this guide will not discuss
specific multimedia development techniques but instead will guide well-versed professionals by outlining
processes and procedures that should be adopted by the developer when creating LearnAlberta.ca
learning objects.
COMPETENCY
It is assumed that all developers have a level of competency that places them as leaders among their
industry peers. Developers should be well versed in:
• Object Orientated Analysis and Design

• Media Digitization and Digital Media Deployment
• Web Standards including Accessibility
• Information Design
• User Interface Design
• Scripting and Programming
• Graphic Design
• Cross Platform deployment Issues
• All other skill sets necessary to perform the required development work.
QUALITY
Developers must ensure that their skills and efforts directly translate into the highest quality product
possible. Quality will be assessed based on recognized, industry-accepted standards. Development
shortcuts that reduce consistency, reliability, or reuse are never acceptable.

01 INTRODUCTION
FIT
While the developer understands that individual learning resources are unique and function independently,
it must also be understood that all resources must be designed to ‘fit’ naturally into LearnAlberta.ca. As
such, the developer is responsible for:
1) Understanding the overall concept or objective of the LearnAlberta.ca portal.

2) Understanding how learners navigate the portal and launch objects.
3) Understanding the overall ‘look and feel’ of LearnAlberta.ca.
In essence, the developer must ensure that the learning object under development takes into account all
issues related to the entire LearnAlberta.ca portal experience.
FUTURE PROOFING
Developers will take care to develop projects using industry standards and best practices to ensure future
proofing is a primary outcome of their development work. Objects will be created to endure a long active
life as technologies advance in display devices, and as CPUs become faster. Developers also need to take
care to ensure that the look and feel of their project will not become quickly dated.
Developers will also make certain that projects are properly constructed so that third party developers can
quickly access the project source files and make changes with minimum difficulty.
1.D LIVING DOCUMENT
This learning object development guide is intended to be a ‘living’ document, meaning that it will evolve
over time. So, it is understood that there may be exceptions to some of the guide’s content and additions
to it as well. However, because adherence to the guide is paramount, there are only certain circumstances
under which a developer can get some leeway. The developer must provide clear written support for the
change being recommended and then gain Alberta Learning’s approval before proceeding with the work.
Whether the situation in question is deemed to have a universal application or whether it is a unique
exception, this guide should be amended with a description of the circumstances and the rationale.

02 LEARNALBERTA.CA ENVIRONMENT
2.A LEARNALBERTA.CA OVERVIEW
The LearnAlberta.ca portal will provide all Albertans with access to life long learning resources. Although
the portal will initially provide learning objects in both English and French for the Kindergarten to Grade
12 communities, it will eventually expand to include all Albertans - a group of over one million users.
Learning objects are continually being developed, licensed, and acquired to populate several repositories
of learning objects. The LearnAlberta.ca portal is completely plug-in based and is constructed to support
high quality learning objects, growth in the quantity of learning objects, and growth in the number of user
groups able to access them.
The portal has an intended audience of four user groups:
1) Learners (primary users)

2) Teachers (secondary users)
3) Parents (secondary users)
4) Developers (peripheral users)
2.B PRESENTATION OF LEARNING OBJECTS ON LEARNALBERTA.CA
To ensure a proper fit, as described in Section 1, the developer needs to understand where the completed
learning object will reside, and how the learner will use it.
Access to all learning objects is provided via the LearnAlberta.ca portal, which is essentially the user
interface to an extensive learning object repository. The interface provides the learner, teacher, or parent
with quick and easy access to the learning resources of their choice.
BROWSE FUNCTION
Users generally browse through the portal by first identifying themselves with a grade level, and then
a subject of interest. Users are then presented with a listing of available resources represented by a
thumbnail and a brief description. Learning objects can be launched from this listing.
SEARCH FUNCTION
Users may also search for resources using the search functionality of the portal. The search results are
displayed in a similar list format to that of the browse page. Learning resources can be launched from the
search results pages. Learning resources can also be launched from either the Browse or Search results
page, by clicking on the Start button located below the relevant thumbnail.

MORE INFORMATION PAGE
Whether it’s Browse or Search functions being used, a learner has the option of getting more information
about the learning resources by accessing the More Information page of a learning object. The learning
object can also be launched from the More Information page of a particular learning object.
THUMBNAILS
It is recommended that developers produce a thumbnail for each individual project destined for the
LearnAlberta.ca portal. The thumbnail should provide a good representation of the content or the title of
the project, keeping in mind that users who do not read, will have little else to go on. Learning objects
should be able to be launched by clicking on the thumbnail.
2.C WHERE LEARNING RESOURCES MAY BE USED
It’s important to keep in mind that the learning resources that are produced may be used in a variety of
situations by a variety of user groups. The same resource may be used quite differently from one situation
to the next. As with any multimedia project, it is not only important to understand the audience, but to
appreciate the context in which the product will be used.
IN-CLASS
In-class refers to a context where there is teacher-led instruction. Students may be in the classroom
collaborating over a single computer, or they may be watching the teacher guide them through the learning
resource using an overhead projector.
IN-LAB
Students may be in a school lab where a one-to-one computer/student ratio exists or small groups may
be sharing a single computer.
AT HOME
Students may use the learning objects for self-study. They may not have been guided to these objects by
their teacher, but discovered them on their own. When learners access resources at home, there may be
any one of a variety of connection speeds ranging from modems to cable/DSL.

2.D ADDITIONAL LEARNALBERTA.CA REFERENCE GUIDES
There are two guides that will help the developer gain a further understanding of the LearnAlberta.ca
portal: the LearnAlberta.ca User Interface Style Guide and the LearnAlberta.ca Usability Report.
LEARNALBERTA.CA USER INTERFACE STYLE GUIDE
This guide is an extensive style guide for the LearnAlberta.ca portal. Although this LearnAlberta.ca
style guide does not directly apply to learning object development, it does detail the underlying design
principles and rationale for the portal.
LEARNALBERTA.CA USABILITY REPORT
LearnAlberta.ca has gone through extensive usability testing to ensure that users from 5 years old and
up can navigate the portal comfortably and effectively. Some developers may find it useful to familiarize
themselves with the LearnAlberta.ca Usability Report in order to understand why certain design choices
were made.

03 DEPLOYMENT ENVIRONMENTS
This section will describe the environment and the rules to which the learning objects must conform. These
rules are derived from the LearnAlberta.ca Technical Specifications document, and references will be made
where appropriate. This section is not a replacement for thorough understanding of the LearnAlberta.ca
Technical Specifications document.
3.A PERFORMANCE FACTORS
There are some key factors that should be considered when looking to maximize performance across
different CPU levels.
Minimum Hardware Requirements are defined in the Technical Specifications document and it is important
to review these requirements before development begins.
To ensure the best playback possible on low-end systems, the following factors should be considered
during the development process.
ANIMATION
Avoid using large amounts of key-frames while animating as this easily taxes the CPU and dramatically
increases the file size. Make use of the tweening technology readily available in most of the relevant
authoring packages. Try to avoid excessive amounts of motion and size tweening when animating within
large portions of the screen. For further optimization, make use of mathematical tweening when deemed
applicable, particularly for simple and replicable elements.
TRANSITIONS
In general, transitions should be avoided for routine navigation. They should be used sparingly over
large areas as complex cross-fades and dissolves will hinder the user experience, particularly on low-
end systems. Alpha transitions and blending is especially demanding on the CPU, and should be used
carefully.
VECTOR GRAPHICS
Given the compact yet scalable nature of the vector-based imagery, it is certainly beneficial to the overall
file size and performance of the learning object. Above a certain level of complexity, vector imagery can
become very demanding to render and animate, as it is drawn on the fly. Try to use vectors consisting of
relatively simple shapes and fills, and pre-render the more complex forms of imagery into a bitmap.
RASTER GRAPHICS
Bitmaps are often employed in relief of vector graphics for the display of more photographic forms of
imagery. However, they can still be relatively demanding on the CPU when animated or scaled on the fly.
Manipulate these type of images sparingly, and avoid animating very large bitmaps altogether.

EMBEDDED FONTS
When possible, try to defer to a default system font (e.g. generic Sans-Serif). Embedding the required
outlines for a font set directly affects the file size, and in some cases, performance of the object. Using
different font styles within a set can also have similar ramifications.
CODECS
Modern generation video CODECS like Sorenson 3, WMV 8, or MPEG 3, are very CPU intensive and
generally will not run on low-end Macintosh or Windows machines.
Older CODECS like Sorenson 2 are easier on older CPUs running sub 300 MHz. However, as these
CODECS do not use delta frames, running video in reverse will be VERY CPU intensive even on 800 MHz
machines.
PERFORMANCE TESTING
Developers should test their project on their own to ensure quality playback performance has been
achieved on the minimum hardware requirements as defined in the Minimum Hardware Requirements in
the Technical Specifications document.
TWO VERSIONS – FULL AND LITE
There may be occasions in which learning resources are developed with a motive to push the envelope
with respect to the production level, often resulting in performance issues on lower-end systems. In such
cases, it is highly recommended to offer FULL and LITE versions of the learning object, to accommodate
both low and high end deployment CPU levels/systems.

3.B DISPLAYS
The following will discuss a few key quality assurance points, to ensure the best possible experience
across multiple platforms.
PROJECT DIMENSIONS
All projects must be adaptable to a screen resolution of 800 x 600 pixels. Plug-in based learning objects
must be 750 x 500 pixels. These dimensions take into account browser chrome, and OS menus and status
bars, while still trying to best utilize the standard screen aspect ratio.
Please review the Minimum Hardware Requirements of the Technical Specifications document for
additional display settings.
GAMMA
The default gamma settings for Windows and Macintosh monitors are different. Windows is 2.2, rendering
the screen darker compared to a Macintosh with a gamma of 1.8. Therefore, when authoring, you should
set your gamma to 2.0. You are still responsible for testing of gamma levels of all images, and you should
always do so on a CRT monitor as gamma displays poorly on LCD.
TEXT SIZE
You should be aware that the default rendering of screen type is based on 96dpi for Windows, and 72dpi for
Macintosh. Type sizes on a Macintosh generally appear about two point sizes smaller than on Windows.
This can be exacerbated with certain fonts. See more detail regarding font choices in Section 6.
OTHER DISPLAY CONSIDERATIONS
Projectors can present challenges for the effective display of an interface. This needs to be taken into
consideration, as this is a common element in a classroom setting. Light-coloured text and graphics can
‘wash out’ and be illegible. Be sure that any integral or functional graphical elements, such as critical
navigation or rollovers, are sufficiently dark and/or high in contrast, to ensure it is easily viewed in this
display environment.
To guarantee the best results on both LCD and CRT displays, ensure that any image-based (rasterized)
text has a strong level of anti-aliasing.

3.C BROWSER NAVIGATION BAR AND BROWSER CHROME

Each learning object is presented within a basic pop-up window, with the toolbar, address bar, and all
other utilities disabled. Although this solves many issues in presenting the learning object, it also creates
a few, such as those below, which need to be resolved.
PRINTING
Printing may be handled by invoking the native print function using JavaScript. The function should launch
the standard print dialog, just as the browser button would. Similar methods of printing also exist within
the Shockwave and Flash environments.
NAVIGATION
The navigational path must be clear and concise within the learning object. For objects containing more
than two levels, additional methods such as ‘breadcrumbs’ should be considered.
SCROLLBARS AND WINDOW SIZE
You may set the window size of a pop-up, but you may not disable the scrollbars, or lock the window. For
example, users may have their default text size set higher to address projectors or a visual disability.
3.D ACCESSIBILITY STANDARDS
The W3C Web Accessibility Standards should be considered during the creation of all learning objects.
For more information on Web Accessibility Standards, please visit the W3C Website:
http://www.w3c.org/TR/WCAG10/
K-3 CONSIDERATIONS
Primary learners think in concrete terms, with little if any grasp of the abstract. They often do not recognize
icons, so use them sparingly. Their motor skills are not yet fully developed so clickable elements need to
be large. Bold colours, a liberal use of graphics, hidden mouse-over events, and loud sounds will provide
this group with an enjoyable and engaging learning experience.

Text needs to be large and generously spaced to suit this age group’s newly acquired reading skills.
Children at this age are taught to write in a particular manner, and might be confused when confronted with
text that is displayed using standard Web fonts. Custom fonts, more appropriate for this age level, should
be embedded or rasterized when possible, to help alleviate this issue.
Simulated K-3 Penmanship:
Sans-Serif (Helvetica) Typeface:
Figure 3.1 - Typeface Comparison
Please review Best Practices and General Issues for Learning Object Design in the Functional Design
Guidelines document for additional accessibility considerations.

04 THE LEARNALBERTA.CA WRAPPER
4.A WHAT IS IT?
The LearnAlberta.ca Wrapper is a semi-flexible learning object UI component that contains some or all of
a common set of specific content elements. We refer to these common elements as meta-content. The
Wrapper is not vital to the functionality of the learning object. If it were to be removed, the functionality of
the resource would remain unchanged.
4.B WHY DO WE NEED IT?
In a word: orientation. Learners and educators should immediately recognize a LearnAlberta.ca resource.
In the future, it may be possible to access non-LearnAlberta.ca resources from the LearnAlberta.ca portal
so it is important that the user be able to clearly distinguish which resources are from LearnAlberta.ca, and
which are not.
From a usability and production standpoint, since every LearnAlberta.ca learning object will have a
common brand and common meta-content elements, it makes sense to utilize a single common Wrapper
across the board.
Figure 4.1 - Default Wrapper Wireframe

4.C WHAT IS ON THE WRAPPER?
The meta-content that is on the LearnAlberta.ca Wrapper includes the following, beginning with the
required elements:
LearnAlberta.ca Icon
The LearnAlberta.ca icon is a required element. It indicates that this is a LearnAlberta.ca resource.
Copyright
This is a required element and contains all necessary copyright information, and terms of use.
Parent Guide
This element is not always applicable to every learning object, but if it does exist, it will contain certain
support information about the learning object, specifically targeted to the parent.
PD Materials
This element is not always applicable to every learning object, but if it does exist, it refers to professional
development materials for teachers.
Acknowledgements
This element provides access to the various credits and legal acknowledgements for the particular
learning object.
Feedback
This is an element that provides a means of submitting feedback about the learning object (either by way
of an active Web form, or by providing contact information to the user).
4.D WHAT IS NOT ON THE WRAPPER?
Help
It is recommended that all help content related to a learning object be provided within the context of the
learning object itself. General help is provided elsewhere on the LearnAlberta.ca portal.
Object Navigation
Any navigational element used within the learning object itself must not be displayed in the same manner
as a Wrapper element. This is done to ensure that the Wrapper can be removed, without affecting the
functional design of the learning object.
Language Selection
The selection of language is dealt with through a separate mechanism on LearnAlberta.ca. It should not
be included on the Wrapper or within the individual learning object. For multi-lingual resources, language
selection should be presented within the learning object itself.

4.E WHAT ARE THE RULES?
WRAPPER WINDOW DIMENSIONS
The default size of the window is 750 x 500 pixels.
WRAPPER ELEMENT DIMENSIONS & POSITIONING
With the exception of the LearnAlberta.ca Icon, each of the following elements has been given explicit
boundaries, which should not be exceeded by their respective labels. By default, all elements are given
a padding of 5 pixels. The positioning instructions for these elements must be adhered to, to ensure a
consistent user experience across learning objects.
The region for the icon is set at 85 x 55 pixels. The size of the icon must allow for an ample amount
of padding (between 10 and 15 pixels) within this region, keeping its visual definition clear. The icon is
positioned within the left-most region of the wrapper.
Parent Guide
Dimensions of 115 x 20 pixels have been allocated to this region. Not all objects have a Parent Guide
element, but for the ones that do, this element is situated to the right of PD Materials, and above the
feedback button – all of which are aligned within the right-most region of the wrapper.
PD Materials
Dimensions of 115 x 20 pixels have been allocated to this region. Not all objects have a PD Materials
element, but for the ones that do, this element is situated to the left of Parent Guide, above the feedback
button – all of which are aligned within the right-most region of the wrapper.
Copyright
Dimensions of 200 x 20 pixels have been allocated to this region. This item is situated to the right of the
LearnAlberta.ca Icon, and above Acknowledgements.
Acknowledgements
Dimensions of 200 x 20 pixels have been allocated to this region. This item is situated to the right of the
LearnAlberta.ca Icon, and below Copyright & Terms of Use.
Feedback
Dimensions of 115 x 20 pixels have been allocated to this region. This element is found below the Parent
Guide, aligned within the right-most region of the wrapper.

POSITIONING & WEIGHTING CONSIDERATIONS
Navigational components and other forms of content internal to the learning object should not share
the same location and weighting as the Wrapper elements. Although certain proximity is permitted,
appropriate spacing must be given to the Wrapper elements in order to ensure a separation between the
content and the meta-content.
WHAT TO DO WHEN META-CONTENT ELEMENTS DO NOT EXIST
In cases where certain meta-content pertaining to a Wrapper element does not exist (most commonly
the PD Materials, or Parent Guide), the meta-content label should be removed entirely from the Wrapper.
However, other Wrapper elements must not be repositioned in their absence, and no ‘new’ elements may
take their place. The space for these elements must be left blank on the Wrapper.
4.F LEARNALBERTA.CA ICON TREATMENT
As stated earlier in this section, the LearnAlberta.ca icon must always be placed in the lower left-hand
corner of the learning object. The region for the icon is set at 80 x 40 pixels. The size of the icon must allow
for an ample amount of padding (between 10 and 15 pixels) within this region, keeping its visual definition
clear.
The icon alone, without the “LearnAlberta.ca” text, must be presented in its entirety, and must also be of
the original aspect ratio. Utilizing the source EPS files will ensure the best logo quality – avoid repurposing
a bitmap. Furthermore, the logo must not have any interactive attributes, as it is a static identifier.
In terms of visual treatment, there are three options:
1) to watermark the icon, however it must be easily discernable over the background of the
region.
2) to use the native colour or greyscale schemes found in the EPS source files
3) to use a flat white or black version of the icon – whichever is considered to be more dis-
cernable over the background of the region.
RIGHT: WRONG:
Figure 4.2 - The logo should not adopt the colour scheme of the learning object, as it will
depreciate the LearnAlberta.ca brand.

4.G FUNCTIONAL DESIGN

As stated in 4.F above, there must not be any interactivity whatsoever associated with this element.
Labeled Elements
With the exception of the LearnAlberta.ca icon, all elements on the Wrapper are text-based labels. These
labels may be true text, using the recommended Verdana and Helvetica fonts, or rasterized text, for more
customized treatments.
Figure 4.3 - Each label should be underlined

to indicate that it is clickable, and must have
rollover, active, and visited states.
4.H MUST BE REMOVABLE
To accommodate reuse, the Wrapper must be removable,

without affecting the function of the learning object.
Programmers and designers should view the Wrapper as
an independent object, which can easily be removed within
the original authoring application. Visually, the resource can
appear to be a self-contained unit, but care needs to be
taken not to confuse the learner into thinking that these items
are integral to the function of the resource.
Figure 4.4 - Removable Wrapper Example
4.I VISUAL TREATMENT GUIDELINES
While the placement and functional design of the Wrapper elements are set, the visual treatment of them
has more leeway. The Wrapper elements may follow the look and feel of the learning object, but care
needs to be taken as not to confuse these elements with the actual navigational elements of the learning
object.

4.J SOME EXAMPLES

Here are a few examples (good and bad) of the Wrapper being applied to a learning object.
Figure 4.5 - Blended Wrapper Example (Good)
Figure 4.6 - Button Style Wrapper Elements (Bad)

Figure 4.7 - Contained Wrapper Example (Good)

05 FUNCTIONAL DESIGN
This section will define the expected behaviour of various elements that may be present within a learning
object. These guidelines are constructed so that the design parameters are as flexible as possible in the
development process.
5.A GUIDELINES FOR COMMON ELEMENTS
INTERNET DETECTION AND FEEDBACK FUNCTIONALITY
Given that learning objects can be launched in both online and offline environments (on CD), and there is
a required Feedback element, all learning objects should have an Internet detection function built into the
Feedback function.
The Feedback element requires the following functions:
1) If online, the Feedback element should yield an active Web-form, where the user may
submit Feedback over the Internet.
2) If offline, the Feedback element should display the contact information only. This may
include the appropriate telephone number, address, and contact name. This permits the
user to provide Feedback by other means than electronic.
HYPER-LINKS
Visual
Links should look like links. Their colour should be in contrast to the surrounding text, and they should be
underlined.
Functional
Hyper-links need to provide visual user feedback, particularly upon rollover. Other standard hyper-link
states, such as Visited, and Active, are highly encouraged.
EXAMPLE:
Paragraph Text … Standard Link … Rollover Link … Active Link … Visited Link
Educational Considerations
Book citations use underlined text. Ensure that a book citation is treated similarly to the surrounding
textual content, and that any links are presented in a different colour for all states.

OFF-SITE OR EXTERNAL LINKS
Visual
Off-site links present an interesting challenge. Using glyphs (such as a globe or exit arrow) is not advisable,
as this will make external links appear more prominent than regular links, which is probably not desired in
most cases. Also, these types of glyphs are simply not universally understood.
A better approach is to try and ensure that off-site links are not placed within a paragraph of content,
and are instead placed on their own below the content or in a contextual side bar. The link should have a
descriptive label, and include the URL in brackets when possible.
EXAMPLE:
Please visit The Government of Alberta (www.gov.ab.ca) for more information.
Functional
Off-site links should function just like standard links. The preferred Web practice encourages launching
external links in the active browser window. However, this is not the case for learning object development.
It is HIGHLY recommended that off-site links launch in a new window. It is highly probable that the learner
will want to jump back to the learning object at the state he or she left it. As noted above, a URL is best
presented in brackets, however, this is not always practical with very long, cryptic links.
For more information on off-site links, please review Section 2.23 - Internet Links of the Functional Design
Guidelines document.
USER RESPONSE ELEMENTS
User response elements should have a minimum consistency across learning objects. For example, a
Checkbox must behave like a Checkbox, no matter how it is developed (Flash, QuickTime etc.).
The following are some of the more common user response elements used in learning object
development:
Drop-Down Menus
��
Visual
Each menu should be visually contained, using a border, bevel, or drop
��
shadow to suggest an interactive element. It should include a visual cue
to the right to indicate what sort of behaviour the learner should expect. ��
A downward or up/down arrow is the most common choice. A default ��
selection or label, indicating that the user should make a selection, must be ��
visible within the element.
��
��

Functional
The entire element must be clickable. While making a menu selection, the rollover items need to be
highlighted. This is usually done with a boxed region around the particular item on the list. It is preferable
if the actively selected item is accompanied by a bullet or check mark while the menu is displayed. To
accommodate a long list of items, implemented a scrolling mechanism to the menu.
Checkboxes
Visual
Not surprisingly, a Checkbox must be a box of some sort. They can be selected with
either a checkmark, or an X. Under no circumstances should it be selected with a dot, ��
as this will cause confusion with radio buttons.
Functional ��
The box is a clickable item, but the text label (or image) presented with each Checkbox
should also be clickable. Allow for more than one check box to be selected at a time.
Checkboxes should toggle (checked and unchecked) when they are clicked a second ��
time.
Educational Consideration
Checkboxes can be used when using a format that asks the learner to answer by ‘clicking all that apply’.
Radio Buttons
Visual
A Radio Button must be circular or spherical in shape. They may be selected with
some style of bullet. ��
Functional
Like the Checkbox, the Radio Button is a clickable item, and the text label (or ��
image) presented with each Radio Button should also be clickable. Only one item
may be selected at a time. Once a Radio Button is selected, it cannot be toggled
off, by clicking the item again. Selecting a subsequent Radio Button within the
given context will result in the former Radio Button being deselected. ��
Educational Consideration
Radio Buttons can be used in a multiple-choice context where only one answer is required.

Text Fields
Visual
A Text Field must be clearly defined by a border, containing a white region where the learner may type
textual content. It is permissible to use a different colour than white for the region, so long as it is
highlighted compared to the UI background and text is well contrasted.
��
When the Text Field is active, a blinking text-style cursor,

common in word processors, should be displayed within
the highlighted region. The cursor is most often displayed
as a vertical rule or block.
Functional
The Text Field is activated by tabbing, or by direct
selection with a mouse. When multiple-lined fields are
used, there must be a set of scroll bars present, unless
some form of character limiter is in effect.
Selection Lists
Visual
Each list must be visually defined using a border, and ��
contain a white, or highlighted region. Each list item
must be presented on its own line and scroll bars should ��
be employed for longer lists.
Functional
��
Clicking on any line item within the list will toggle the
highlighted state of the list item on or off.
��
For more information, please review Section 7 – Learner ��
Response Models Described of the Functional Design
Guidelines document. ��
RESOURCE DOWNLOADING
Occasionally it is necessary for a learning resource to enable the learner to download an external file to
their desktop. On the Web, download links look exactly the same as any other link. Therefore, it must be
ensured that the learner understands that a particular link will start a download procedure.

Visual
These links should clearly state, “Download” within the descriptor. Other pertinent information such as an
icon denoting the type of file being downloaded (e.g. Word, PDF, etc.), should be included to indicate what
the user will be downloading. However, do not rely solely on a PDF, or similar icon, to relay any meaning
to the learner. Here is a summary of valuable information that could be included:
- File Size (in Bytes)

- File Type (Word, PDF, TIFF, etc.)
- File Name
- File Description
EXAMPLE:
Download The Documentation (1.2MB PDF File)
Functional
Clicking ‘download’ should initiate the download process, based on the system preferences of the user.
If there are instances where the user is not taken directly to the resource (i.e. by a download tracking
and/or re-directing mechanism), a direct link must still be provided as a contingency step, in the event of
a malfunction.
STATUS INDICATORS
Loading
Loading indicators must be employed when initially loading a Flash. QuickTime, or Shockwave based
learning object, and when loading individual components into an existing interface.
Visual
A loading mechanism should be displayed as some form of container, which fills up as the loading takes
place. Indicators may be accompanied with either textual or numeric information. However, it is not
satisfactory to have textual or numeric information without the loading bar.
Functional
The percentage of the container filled should directly correlate to the percentage downloaded.

Do not rely on loading indicators as a satisfactory solution to large and time intensive downloads.
Multimedia projects should be constructed in such a way that perceived download time is always at a
minimum. Rather than loading a project all at once, try chopping up a project into smaller components,
and loading only what is needed to start the application. Once the learner is engaged in the project, the
application can load subsequent components in the background.
Progress
Progress indicators usually come in the form of a video play head. However, progress indicators can also
be utilized to convey the status of a given task, or set of tasks.
Playback Progress
A playback head represents the current location in time for the playback of rich media. It is recommended
that this element be a dragable handle, so the user may track to various locations in the given clip. If the
loading status is present, it is recommended that it be placed underneath the playback head.
Task Progress
Similar to the aforementioned loading mechanism, this form of progress should be displayed as some
form of container, which fills up as the user advances. Appropriate indicators may be accompanied with
either textual or numeric information. However, it is not satisfactory to have textual or numeric information
without the loading bar.
In some cases it may be important to indicate progress in discreet steps, such as Step 1 of 5, Step 2 of 5,
etc. In these cases a visual continuum of steps should be provided. The steps should be links, which allow
the learner to easily jump back to a specific step and redo it. Naturally, steps that have yet to be completed
should not be active/clickable in the continuum.
Computation
Occasionally, an application may need to use a number of CPU cycles to perform a calculation before
displaying the results back to the learner. With respect to acceptable time durations, a common misapplied
rule-of-thumb in Web design is to allow 10 seconds. Application developers would never even let the user
go 1 second without providing some form of active feedback. It only takes a few seconds for a user to
think that something may have gone wrong. It is therefore important to provide a computation indicator
for the learner, whenever there is a risk that a computation takes longer than 3 seconds on the minimum
requirement computers.

Visual Indicators for Ten (10) Seconds or Less

For computations that will take less than 10 seconds, the most universally recognized symbol
for an ongoing computation is to indicate the passage of time. A watch or hourglass is very
common. Other symbols that can spin, rotate, or osculate are also being used, but these
symbols are not generally as representative of the passage of time.
Indicators for Over 10 Seconds

In situations where the wait will likely be over 10 seconds, a spinning ball or osculating hourglass is not
appropriate, as these may incorrectly indicate an irrecoverable loop in the application. When waits are
expected to be over 10 seconds, the indicator must explicitly tell the learner that such a wait should be
expected. Ideally, an approximate estimate should be provided with a count down if possible.
Functional
Whatever image is chosen to display the passage of time, it needs to be animated; an hourglass should
osculate and a beach ball should spin. It is important that loading indicators are not used to convey
computation.
5.B MEDIA CONTROL ELEMENTS
Many of the LearnAlberta.ca media controls will have a rather strict treatment to ensure a consistency in
expectations across learning objects. That being said, the treatment of these elements may still be applied
with the visual theme of the learning object.
GENERAL SLIDERS
Visual
A slider is comprised of two elements - a shuttle and a track. The shuttle is represented by a type of handle,
which overlays the horizontal or vertical track. The appearance of the track may be solid, or beveled.
Functional
The shuttle slides along the full length of the track. It cannot be moved off the track. Dragging the shuttle
between minimum and maximum, even while the mouse is outside the track area, must directly affect the
position of the shuttle. This can be experienced by dragging the scrollbars on a browser or word processor.
Note that if the cursor moves off the shuttle while the mouse is still down, scrolling remains active. Clicking
anywhere on the track must also relocate the shuttle to the selected location.
Application
Common applications for sliders are for control of attributes such as volume, equalization, balance,
brightness, and contrast.

GENERAL ADJUSTMENT BUTTONS
Visual
Buttons used for ‘increase’ and ‘decrease’ should be in the form of a Plus and a Minus sign, respectively.
There must be a visual indicator in close proximity, or between the two buttons, which displays the current
level in discernable increments. Holding down either of the buttons should continuously perform the given
funtion, until the extent of the function has been reached.
Functional
Clicking the Minus button incrementally reduces the level, and the state of the corresponding visual
indicator. Clicking the Plus button incrementally increases the level, and the state of the corresponding
visual indicator.
Both the Plus and Minus buttons should have rollover and active states.
Application
Common applications for adjustment buttons are to control attributes such as volume, equalization,
brightness, and contrast.
PLAYBACK CONTROLLERS
Playback controllers share the same concept as a VCR or DVD controller. While there is some visual
flexibility within brands of DVD players and VCRs, playback controls still have a rather strict treatment to
ensure consistent expectations across the board. The same goes for digital media playback controllers
but again, the visual treatment of these elements may still adopt the visual theme of the learning object.
It is suggested that these control elements be given a button-

style treatment, meaning they should be presented within a
pronounced shape, such as a square or circle, and must exhibit,
up, over, and down states.
Go to Beginning/ End
Visual
These buttons must each contain an isosceles triangle, pointing left or right, for the
beginning and end respectively. A vertical line of equal height must be adjacent to the
vertex point of each triangle.
Functional
These buttons send the play head to either the beginning or the end. Unless there is a very
good reason, it is suggested that the Go to End button not be used. In most cases where
this button might be used (chapters), the Next button is more suitable.

Rewind
Visual
This item must contain two isosceles triangles, with both vertexes pointing left.
Functional
This item is generally used for moving video backwards, often at a speed multiple of 2X.
When a video is in rewind mode, the video should be seen moving in reverse. NOTE: For
digital video using beta frame only CODECS, rewind is a highly CPU intensive process.
Fast Forward
Visual
This item must contain two isosceles triangles, with both vertexes pointing right.
Functional
This item is generally used for moving video visually forward at a speed multiple of 2X or
more the ‘play’ speed. When a video is in Fast Forward mode, it should be seen moving
at the higher speed.
Play
Visual
This item must contain a single isosceles triangle, with the vertex pointing right. This item
may be visually weighted larger than its counterparts (Fast Forward, Rewind, etc.).
Functional
This item is used to play linear media at normal speed.
The Play button may toggle with the Pause button when clicked. The Pause button is
displayed when the media is playing and the play button is displayed when the media is
paused. In this case, the Pause and Play buttons must have the same visual weightings.

Pause
Visual
This item must contain two thick parallel lines, situated vertically.
Functional
The Pause button is used to stop playback. However, when the Pause button is clicked,
the media must still remain visible within the viewer at the precise point when the Pause
button was clicked.
The Pause button may toggle with the Play button when clicked. If so, this button must
have the same weighting as the Play button.
Stop
Visual
This item should be represented by a perfect square.
Functional
The Stop button is used to stop the media from playing, turn the media viewer off, and
return the playback head to the start of the timeline. Because it is returning the play head
to the start, this button is rarely used for digital media on the Web. If this were the desired
functionality, then the Go to Beginning button (see below) would be a preferable choice.
Previous
Visual
This item should be represented by a two isosceles triangles, pointing left and adjacent to
a vertical line of equal height at the outermost vertex.
Functional
This item is generally used for going to the previous slide, screen, or chapter.
Next
Visual
This item should be represented by a two isosceles triangles, pointing right and adjacent
to a vertical line of equal height at the outermost vertex.
Functional
This item is generally used for going to the next slide, screen, or chapter.

VOLUME ADJUSTMENT
When audio is being presented, it is highly recommended to have volume control. This control
may be handled three ways – a slider, adjustment buttons, or preset buttons. An appropriate icon
should accompany this control – the speaker is a common example.
Furthermore, a Mute Check Box should accompany the volume control element. Please see the Check
Box definition, found earlier in this section, under User Response Elements.
Sliders
Visual
A slider is comprised of two elements - a shuttle and a track. The shuttle is represented by a type of handle,
which overlays the horizontal or vertical track. The appearance of the track may be solid, or beveled.
It is advantageous that secondary indicators visually illustrate the present volume level. For example, Real
Player uses a crescendo over the sliding bar and QuickTime uses individual sound waves coming from a
speaker.
Functional
The shuttle slides along the full length of the track. It cannot be moved off the track. Dragging the shuttle
between minimum and maximum, even while the mouse is outside the track area, must directly affect the
position of the shuttle. This can be experienced by dragging the scrollbars on a browser or word processor.
Note that if the cursor moves off the shuttle while the mouse is still down, scrolling remains active. Clicking
anywhere on the track must also relocate the shuttle to the selected location. Dragging the slider to the
right increases the volume, while dragging to the left decreases the volume.
Adjustment Buttons
Visual
Buttons used to increase or decrease volume should be in the form of a Plus and a Minus sign, respectively.
There must be a visual indicator in close proximity, or between the two buttons, which displays the current
volume level in discernable increments.
Functional
Clicking the Minus button incrementally reduces the volume, and the state of the corresponding visual
indicator. Clicking the Plus button incrementally increases the volume, and the state of the corresponding
visual indicator. Holding down the Minus or Plus buttons should continuously modify the volume, until the
minumim or maximum volume has been reached.
Both the Plus and Minus buttons should have rollover and active states.

Preset Buttons
Visual
When using preset volume buttons, there should be at least three levels present – Minimum, Medium,
and Maximum. Each button should contain an icon of some type indicting volume and its corresponding
level.
Functional
Clicking each of the buttons sets the corresponding volume to the predefined level. Each of the buttons
should have rollover and active states.
Balance
Visual
Balance is another slider, and as such, it is comprised of two elements - a shuttle and a track. The shuttle
is represented by a type of handle, which overlays the horizontal or vertical track. The appearance of the
track may be solid, or beveled, the shuttle located at the centre by default.
A mirrored speaker icon may represent Balance, while the track itself should have (L|R) at the respective
end points, representing the stereo channels.
Functional
The shuttle slides along the full length of the track. It cannot be moved off the track. By default, the
element provides equal volume in both channels, as it the shuttle is centered between the stereo channels.
Dragging the shuttle left and right, even while the mouse is outside the track area, must directly affect
the position of the shuttle, and the audio balance accordingly. Clicking anywhere on the track must also
relocate the shuttle to the selected location.
ADDITIONAL CONTROLS
Play Head
The Play Head is a special kind of slider. The play head differs from regular sliders in that the beginning and
end of the track represents the beginning and end of the media timeline. The play head also automatically
moves along the time line while the movie is in Play, Fast Forward, or Rewind modes.
Visual
Like all sliders, it is comprised of two elements - a shuttle and a track. The shuttle is represented by a
type of handle, which overlays the horizontal or vertical track. The appearance of the track may be solid,
or beveled.
Functional
The play head slides along the full length of the track. It cannot be moved off the track. Dragging the
play head the length of the track, even while the mouse is outside the track area, must directly affect the
position of the play head, as well as the current playback location. Clicking anywhere on the track should
relocate the play head to the selected location.

Brightness
Visual
Brightness should be represented by an image of a light bulb, the sun, or any other
established symbol of luminosity.
Application
Either a slider or a set of adjustment buttons may be used. Please review the general
definitions for each, found earlier in this section.
Contrast
Visual
Contrast should be represented by a symbol, which basically contains two highly
contrasting halves.
Application
Either a slider or a set of adjustment buttons may be used. Please review the general
definitions for each, found earlier in this section.
5.C NAVIGATIONAL ELEMENTS
Navigational elements should be used for moving from one presentation element to another, similar to
navigating within a browser.
General Buttons
Buttons should look like buttons. They should be visually contained, using a border or similar alternative,
to suggest interactivity.

Close
Visual
The Cose button should be illustrated by an X, encased within a region.
Functional
The Close button should close its corresponding window.
Additional Considerations
The Close button should be used when a new region of content pops open over another,
like a second window on a desktop. It should be slightly offset, and visually smaller than
the preceding region from which it was opened. If a region perfectly overlaps another
region, there is no way for the learner to understand that something has opened ‘over’
the previous region. It looks like a new page. In this case, the ‘back’ element may be
warranted.
Back
Visual
The Back button should be represented by a single directional element, pointing left.
Functional
This item is generally used for going to the previous page or screen. Within this context,
do not use it to go to the beginning of a sequence. A rollover state is recommended for
this item.
Forward
Visual
The Forward button should be represented by a single directional element, pointing
right.
Functional
This item is generally used for going to the next page or screen. Within this context, do not
use it to go to the end of a sequence. A rollover state is recommended for this item.

Scrollbars
Scrollbars are required when a single piece of
displayed content exceeds a predefined region.
If content can be broken into smaller pieces, then
consider presenting the content using more than
one page or screen.
Visual
Although it is a type of slider, the appearance of the
scroll bar is much like the progress bar, in that it is a
contained region. This region contains the tracking
area for the contrasting scroll handle. Scroll arrow
buttons must be situated at each end of the scroll
bar.
Functional
Clicking and dragging the scroll handle, even while the mouse is outside the scrollbar area, should directly
effect the position of the handle, as well as the contents of the scrollable area, in real time.
Clicking the scroll arrow buttons will shift the scroll handle, and the contents of the scrollable area. Holding
down these buttons should continuously shift the scroll handle, and the contents of the scrollable area
accordingly as well.
Active states are required for both the scroll handle, and the scroll buttons.
Search Widgets
These components must be clearly marked with either an appropriate text label, or descriptive icon, such
as a magnifying glass. A Submit button should also be present, preferably containing the text, Search.
��

��
Please review Section 5 – Button Types and Functions of the Functional Design Guidelines document, as
well as the LearnAlberta.ca User Interface Design Guidelines.

06 GUIDELINES FOR CONTENT PRESENTATION
6.A TEXT CONTENT
RASTER & TRUE TEXT
True Text
Because of the significantly low resolution of computer displays compared to print, it is recommended that
two common sans-serif fonts be utilized, Verdana & Helvetica. These fonts are specifically designed for the
Web, and are common across both Macintosh and Windows platforms.
Embedded Fonts
For resources authored in Flash and Director, custom fonts must be embedded. These fonts should also
accompany all source file deliverables.
Please note that embedding fonts does not allow for a carte blanche to use any font desired. Display
limitations must always be taken into account. The developer should justify choosing a font other than
Verdana & Helvetica, especially if it is not sans serif.
Headlines
Headlines should not be underlined, as this will be confused with active links. Instead, use bold and an
increased font size.
There may be specific issues to consider when dealing with Language Arts learning resources, particularly
for K-3 learners. For example, displaying text using certain fonts may have cognitive ramifications, as
learners in this age bracket are taught to write letters in a particular manner.
In such cases, a ‘Web-friendly’ font may not be advisable. But when using non-standard fonts, care needs
to be taken to test across a number of displays, systems, and resolutions.
Simulated K-3 Penmanship:
Sans-Serif (Helvetica) Typeface:
Figure 6.1 - Typeface Comparison

HYPER-LINKS
Visual
Basically, links should look like links. Their colour should be in contrast to the surrounding text, and they
should be underlined.
Function
Hyper-links need to provide visual user feedback, particularly upon rollover. Other standard hyper-link
states, such as Visited, and Active, are highly encouraged.
EXAMPLE:
Paragraph Text … Standard Link … Rollover Link … Active Link … Visited Link
Book citations use underlined text. Ensure that a book citation is treated similarly to the surrounding
textual content, and that any links are presented in a different colour for all states.
6.B THUMBNAILS
If thumbnails accompany synopsis type information, while

providing access to more detailed information, then thumbnails
must be clickable to allow for this access. Clickable elements,
such as buttons, must appear to be interactive. This is done by a
beveled treatment and/or an animated rollover state.
Figure 6.2 - Thumbnails are also used as small previews for

larger images. In such cases, an enlarge button or link should
be provided, preferably along the bottom of the thumbnail.
The ‘enlarge’ label is usually accompanied by a plus sign, or
magnifying glass.
��
When presenting enlarged images in a pop-up window, please employ the Rich Media Wrapper, detailed
on the next page.

6.C RICH MEDIA

PRESENTATION
Media Wrapper
In the event that a pop-up window is needed to present video, audio, or imagery, a small Wrapper
must be applied to frame the content. This Wrapper should be given a similar treatment to that of the
LearnAlberta.ca learning object Wrapper. Please see Section 4 of this document for more information and
the specifics on the treatment of its elements.
The horizontal measurement of the

window should be the width of the given
media, plus 25 pixels on each side.
The vertical measurement must be the
height of the media, including 50 pixels
on the top and bottom. This provides
the necessary spacing for the wrapper
elements.
There are three required elements for

this Wrapper:
1) the LearnAlberta.ca icon

2) a close button
3) a copyright statement
The LearnAlberta.ca icon must be

presented at the bottom left. A close
button must be situated in the top right-
hand corner of the window.
Figure 6.3 - Media Wrapper
The name of the given media must be present in the title bar of the window, and may also be included
above the media iteself. The footer of the Wrapper should contain a brief copyright statement.
REQUIRED ELEMENTS
Controls
Ensure that users have control over their media. Pause, Restart (Go to Beginning), and Play buttons must
be available. Volume controls are also recommended.
Status Indicators
When media is of a significant duration, it must provide a download bar, and a playhead.

07 CODE DOCUMENTATION AND MEDIA CREATION
This section outlines the high-level requirements that all developers must satisfy with the delivery of a
learning object.
7.A PROGRAMMING
COMMENTED CODE
Source code delivered with a project must be documented in such a way that a different development
team would be able to easily understand, maintain and/or redevelop any part of the program. To enable
this priority the developer is required to thoroughly document source code.
Follow these guidelines when commenting source code:
• Each file containing source code must contain a documentation header, including the
component name (if applicable), description and purpose, and modification history (in-
cluding the author).
• Every non-trivial function or method must be preceded by a commented header that de-
scribes that function, its properties and arguments. Comment any code that would not be
immediately understood, either in the header or within the body of the function.
• Programmers should incorporate commenting into the ongoing coding workflow, rather
than commenting after the fact.
• Document code where choices were made between different programming solutions, and
explain why the solution was adopted.
• Comments in the code should alert other programmers to any unusual scripts, issues or
workarounds.
The following are suggested terms to highlight particular issues:
// :BUGFIX:
Comment on known issues and their resolution.
// :KLUDGE:
Indicates the code in this area is not elegant or may be a workaround. Should give details of the
problems encountered and why the workaround was used.
// :TRICKY:
Indicates that this code has a lot of interactions and that it should not be modified without careful
consideration.
// :TODO:
Indicates that more work is required on this code and suggests strategies for going forward with
the code.

EXAMPLE:
// :TODO:
/*
This loop will work with a limited numbers of iterations. When above 5000 iterations, it may begin
to generate an error. If more than 5000 iterations are required, there will be a need to break up the
array into a series of smaller arrays.
*/
See the requirements described in Section 8.A and 8.B, under ‘Commenting’ for media specific
applications.
READABILITY
Programmers should write code with clear and meaningful language to produce readable and easy to
interpret code. Programmers are required to follow best practices for the programming language and to
apply a consistent style across the project.
Methods and variables should have descriptive names and statements should be written so that the
code is inherently ‘self-documenting’. Camel case is highly encouraged to facilitate comprehension of the
script.
The following is an example of good and bad names:
// snippet of code for animating analog clock
Good:
Clock.hourHand. rotation = 360 * dayPercent + hourPercent * (360 / 12)
Bad:
Anaclk.hrhnd.rtn = 360 * dper + hper * (360/ 12)

DOCUMENTATION
A formal document must accompany each type of code-base that makes up the learning object. The
documentation should discuss the overall architecture and functionality of the developed component or
framework. A directory structure of all relevant resources must also be provided. This should give all file
names (and extension) and a brief description. Wherever documentation requirements are described in
section 8, they should be included in this document.
7.B GENERAL NAMING CONVENTIONS
Source Files
When creating new documents or elements, utilize the following standard, unless otherwise stipulated:
[ui-component]_[name-of-element]_[optional-descriptor].[extension]
For example, a rollover state for a menu item could look something like this:
global-nav_home-over.gif
Try to make the names as verbose as possible, while using common abbreviations to keep the filenames
at a reasonable length.
Layers within Photoshop

The names of layers must be clearly indicative of the element contained therein. Layer sets should also be
used and appropriately labeled based on constructive grouping.

7.C DIRECTORY STRUCTURE

Developers must set up their folder structure to conform to the following:
This structure allows the files to be transferred as is from the delivery

�� medium onto the LearnAlberta.ca Web server.
0 �� Observe the following guidelines when implementing this file structure:
0 ��
1) The index.html file should contain an object embed tag that references
0 �� the startup.swf.
2) The startup.swf may, or may not, use XML that contains, for example, a
0 ��
menu that can reference imsmanifest_rt.xml (rt stands for runtime).
0 �� 3) There should be only three files contained at the root level of any project
0 �� that launch the resource.
4) The other folders are there for organization purposes only and are broken
0 ��
down as follows:
0 ��
a. asx – Windows Media Player SMIL files. These files tell Windows
0 ��
Media Player what movie to launch, the start and end times, the
0 �� duration, etc.
0 �� b. authorware – any Macromedia Authorware file (.dcr)
c. documentation – all available developer documentation for the
0 �� resource, including a PDF of the style guide (detailed in Section 9).
0 �� d. flash – any compiled flash file (.swf)
e. flash_source – any non-compiled flash file (.fla)
0 ��
f. fonts – all available fonts used in the project (Mac/Windows)
0 �� g. html – any .htm or .html file
h. image – any .jpg or .gif
0 ��
i. lsp_source – any applicable LiveStage files (.lsd)
0 �� j. movies – any .mov or .avi.
0 �� k. other – anything else that doesn’t fit within the folder structure
l. pdf – any Adobe Acrobat .pdf
�� m. powerpoint – any Microsoft Power Point file (.ppt)
n. rtf – any rich text file
�� o. runtimedocs – any .xml other than the root imsmanifest_rt.
�� p. smil – QuickTime smil files (.smil)
q. word – any Microsoft Word file (.doc)
r. wrapper – all resources related to the Wrapper
5) This folder structure can and should be modified as new technologies

require.
6) Developers can create subfolders within any of these root folders for
easier maintenance. For example, html might contain Lesson 1, Lesson
2, etc.

7.D IMAGE FILES

Creation of Droplets for Common Elements (Photoshop)
For elements such as thematic buttons and other consistently treated images, it is recommended that
Photoshop droplets be created, and included as part of the final deliverable of the learning object.
Layered Source Files

Source artwork such as files in Photoshop format must be layered with any attributed layer effects intact.
These files must also be included in the final deliverable of the learning object.
EPS for Vector Artwork

There are many vector formats available to developers. However, the EPS format is most commonly used
between Web and print environments, and thus should be the native format utilized in the final delivery of
vector resources.

08 MEDIA SPECIFIC DEVELOPMENT
8.A FLASH
The developer must ensure that projects developed in Flash are built so they can be easily edited, revised,
and repurposed by other developers. Special efforts must be made to organize and document the project
to enable this requirement.
STRUCTURE
Flash movies passed between developers can be extremely difficult to interpret. Movie structure is a
critical concern. Projects must be built with an obvious and consistent organization of content. This
applies to scenes, movie clips, interface elements, and dynamically loaded content.
The developer must include separate text files or diagrams (see section 8b) that describe the structure
of the movies, the organization of movie clip instances, the uses of objects, and the placement of code.
The organization and hierarchy of dynamically loaded movies and content must also be explained in these
documents. Include the location of any internal documentation, file naming conventions and media asset
naming protocols.
Projects should be designed with granularity in mind. Reusable components of the project, media
elements, movie clips, movies, etc. should be as self-contained as possible.
PROGRAMMING
Make the code accessible and easy to interpret. Programmers should make a high priority of developing
code structures and language that are clear and easy to understand by other developers.
All programmers should be familiar with the Macromedia white paper “ActionScript Best Practices” and
adopt these best practices where applicable.
http://download.macromedia.com/pub/devnet/downloads/actionscript_standards.pdf
Names for objects, methods and variables should be descriptive and chosen for readability. Function
names and variables should begin with a lower case letter. Objects, and object constructors should be
capitalized. Using mixed case works well for variable names. The style should be consistent throughout
the project.
EXAMPLES:
Good:
lastGameScore (variable name, mixed case, starts with lowercase)
last_game_score (variable name, starts with lowercase )
Bad:
lastgamescore (variable name, hard to read)
lastgmscr (variable name, difficult to interpret)
lgs (variable name, difficult to interpret)
Lastgamescore (variable name, wrongly Capitalized)

Use the Macromedia specified suffix (_mc, _btn, _txt, _xml, _array, _sound) to clearly identify the type of
object in your code.
Use relative scoping of variables to enable the portability and repurposing of Flash elements like movie
clips and loaded movies.
Relative paths should be used to all external files and media.
Code must be cleanly written and formatted, and all redundant code must be removed. Refactoring
should be considered if the code has become unclear or has evolved into a bad design. Refactoring is
the process of changing code in such a way that does not alter the external behaviour of the code, yet
improves its internal structure. The goal is to improve the programming design and maintainability and to
restore coherence and flexibility.
CODE PLACEMENT
Locating code is one of the most important issues in making a source files accessible to another
developer.
In addition to the ActionScript Best Practices white paper, a useful technical document on the placement
of code can be found at http://www.macromedia.com/support/flash/ts/documents/as_behavior_
practices.htm
The developer must be consistent in the placement of code and must document the strategy used. Efforts
should be made to centralize the code, usually in the first frame.
These guidelines should be followed:
• Every timeline that contains code should have one layer (or two — one for functions and
one for frame actions) to contain code and a layer named labels. These should be posi-
tioned at the top of the timeline. Use these layers exclusively for labels and scripts.
• Avoid putting code directly on buttons or movie clips, except in the case of behaviors.
• Avoid in-line code in frame actions on the timeline. Instead, make a call to a function or
Object method which defines where your main code is centralized.
• Use an external actionScript file for each Class. Name the file based on the name of the
Class (e.g. Calculator.as, Blackboard.as)
• When including an .as file with a library of related functions, a brief comment above the
#include directive in your internal code should summarize the purpose of the .as file.
• If Class definition code is included in a timeline script, script comments should clearly
separate, identify and describe the code that applies to each Class.
• Group all related functions and methods for easy interpretation.

COMMENTING
Commenting is essential to the maintainability of a project. Comment in plain language as much as

possible. Programmers should incorporate commenting into the ongoing coding workflow, rather than
commenting after the fact.
All .fla files should have a documentation header that describes the use of that movie in the overall project.
Timeline variables and globals should be explained. Complex movie clips should also include this type
of documentation. This should be placed consistently, either in the first frame or another location that is
documented.
Every non-trivial function or method must be preceded by a commented header that describes that
function, its properties, and arguments. Comment any code that would not be immediately understood,
either in the header or within the body of the handler. It can sometimes be useful to indicate where the
code is called from.
Class definition scripts should have a commented header that describes the object, its properties and
methods.
LIBRARIES
Libraries can contain a large number of media elements, graphics, sounds, symbols and movie clips. If
these are not filed consistently it can be extremely onerous or, practically speaking, impossible to edit or
update content in the production. Locating and replacing media elements easily is a critical requirement.
The developer must use folders and subfolders to organize media elements logically. Another developer
should be able to identify media elements easily by the organization and naming of library elements.
Use the following structure to organize your library:
• Buttons, components, fonts, graphics, movie clips, sounds, shared resources or compo-
nents and text folders should be represented at the top level.
• Create any number of subfolders within these root level folders for easier maintenance.
For example, buttons might contain Lesson 1, Lesson 2, etc. Apply the same system con-
sistently across the library.
• Documentation of the system used in the library must accompany the project.
• The developer must create, document, and apply a systematic naming convention for in-
ternal media assets stored in the library. Every symbol must be named. Assign logical and
descriptive names (“foghorn sound” vs. “fh_aug2_final_rev”). Avoid cryptic abbreviations
(“ssbkgd” for “sunset background”).
• Before deployment, delete all redundant, temporary or unnecessary library items

TIMELINE
Name every layer descriptively in a way that other developers can easily identify what content is on that
layer. Do not mix and match content within layers. Instead use layers liberally and group them into folders
of associated content. Do not use the default layer names (Layer 1, Layer 12, etc).
Name all instances using Macromedia approved suffix (_mc, _btn, _txt). Use a different style of naming for
library items to avoid confusion between a reference to a library item and an instance of that item.
EXAMPLE:
Library item: “generic section button”

instances: “section1_btn”, “section2_btn”
Use one or more separate layers for sound if including sound in a timeline.
WORKFLOW AND MEDIA PRODUCTION
Any unusual workflow or production processes should be described in a text document.

Internal documentation within a .fla file is also acceptable if it is easy to locate. This documentation should
be sufficiently detailed so a different production team making content changes can successfully replicate
the process.
Production processes that cannot be easily replicated should not be used.
8.B DIRECTOR
The developer must ensure that projects developed in Director are built so they can be easily edited,
revised, and repurposed by other developers. Special efforts must be made to organize and document the
project to enable this requirement.
STRUCTURE
Projects must be built with an obvious and consistent organization of content. The programmer should
consider whether a frames based implementation vs. a purely programmatic implementation would be
easier for other qualified developers to understand and work on. In making the choice the developer must
favour the ease of redevelopment and revision by a different team.
The developer must include documentation as separate text files or diagrams (see section 8b) that describe
the structure of the movies, and the uses of objects. Include the location of any internal documentation, file
naming conventions and media asset naming protocols.
Again, projects should be designed with granularity in mind.

SCORE
The following guidelines should be followed to increase the readability of the score:
• Use white space (empty frames and sprite channels) in the score for readability. Group
related sprites in adjacent channels. Use a group of empty frames between sections and
screens to emphasize the structure and flow of the timeline.
• Use descriptive frame labels to indicate the structure of the movie and the content of a
frame or group of frames. It is often useful to label some frames for readability of the
score, even if these are not required for navigation.
• Colour coding of related sprites in the score is recommended to assist in readability.
• Do not hard-code frame numbers in your navigation scripts. Navigational code should
use frame labels, not frame numbers, so that content can be added or extracted without
breaking the navigation. An exception is permitted if the numbering system is integral to
the structure of the navigation, flexibly designed to accommodate changed values and
thoroughly commented so it can be updated and repurposed.
PROGRAMMING
code structures and language that are clear and easy to understand by other developers.
The following guidelines should be followed:
• Create a documentation header at the top of the first Movie script. This banner should
contain comments on the movie name, purpose, all global variables and custom Objects,
who programmed it, unusual programming, dependencies, extras required, and any other
important information. This script should also contain the startMovie handler, an init han-
dler for initializing variables, and an optional stopMovie handler.
• Place this movie script in the first member position of castLib 1 or another cast designated
for strictly for script members.
• Centralize and organize all movie script code logically so it is easy to find. Use a separate
Movie script for utility and production code.
• For clarity initialize variables within separate init handler within the movie script, objects,
and behaviors.
• Avoid any instances of hard-coding data within functions and methods. Values (such as
sprite numbers) should be stored as a variable or property.

• Test and debug code should be identified with comments, indicating the purpose of the
code where necessary.
• Group Movie scripts, Parent scripts, and Behaviors in the cast designated for scripts. Us-
ing cast member scripts is discouraged as they can be difficult to locate.
• The developer must name every script in a way that indicates its function (“MAIN movie
script”, “Utility movie script”, “rotation behavior”, etc. ).
• The developer must use a system for naming variables and properties that clearly identi-
fies the scope. The system must be used consistently across the program. Notice the
mixed case style to improve readability.
These are recommended:
gCustomObj (global instance of object

gGlobal (global Variable)
pProperty (property)
variableName, aVariableName (local variable)
• Relative paths should be used to all external files and media.
• Code must be cleanly written and formatted, and all redundant code must be removed.
Refactoring should be considered if the code has become unclear or has evolved into
a bad design. Refactoring is the process of changing code in such a way that does not
alter the external behaviour of the code, yet improves its internal structure. The goal is to
improve the programming design and maintainability and to restore coherence and flex-
ibility.
COMMENTING

Every non-trivial handler, function or method must be preceded by a commented header that describes that
function, its properties, and arguments. Comment any code that would not be immediately understood,
either in the header or within the body of the handler. It can sometimes be useful to indicate where the
code is called from.
Parent scripts should have a commented header that describes the object, its properties and methods.
CAST
The developer must create, document, and apply a systematic naming convention for internal media
assets stored in the cast. The media production team should follow these naming conventions for their
production output (e.g. In Photoshop layers if using Photocaster to import Photoshop layers).

These guidelines should be applied to the organization of assets in cast libraries:
• The preferred system is to use several casts, logically organized and descriptively named
according to media type and/or usage.
• If using a single cast, group cast members by type, leaving a row of empty members to
improve readability.
• Every cast member must be named, regardless of the member’s type.
• Assign logical and descriptive names (“foghorn sound” vs. “fh_aug2_final_rev”). Avoid
cryptic abbreviations (“ssbkgd” for “sunset background”).
• When designing and applying the naming protocol, use a consistent set of suffixes or
phrases to indicate the media type or usage of all cast members.
Good:
animal sound 01, intro_snd, quit btn, animal image 01, intro background,
Bad:
intro, animal 01, background, quit
• Before deployment, delete all redundant, temporary or unnecessary cast members
Any unusual workflow or production processes should be described in a text document.

Internal documentation within a .dir file is also acceptable if it is easy to locate. This documentation should
be sufficiently detailed so a different production team making content changes can successfully replicate
the process.
Production processes that cannot be easily replicated should not be used.
Examples
The developer should ask how a different team might reproduce an animated film loop with changes to
some of the graphics. Does it require providing source movies used for this type of production process,
as well as documentation?
Flash elements incorporated in a Director file may have their regpoints changed programmatically. This
process requires documentation and explanation. Utility code and comments that facilitate this process
should be left in place.

References
ActionScript Best Practices: Macromedia White Paper

A useful technical document on the placement of code in Flash can be found at:
http://www.macromedia.com/support/flash/ts/documents/as_behavior_practices.htm
8.C LIVESTAGE PROFESSIONAL (QUICKTIME)
Although QuickTime movies authored in LiveStage Professional (LSP) are by their nature very re-useable,
developers must still ensure that projects are built to be easily edited, revised, and repurposed by
other developers. Special efforts must be made to organize and document the project to enable this
requirement.
STRUCTURE
An LSP project displays its media over time and across the different layers. At any given time, one or
more tracks can be displayed. It resembles the frame-based environment of Director and the track-based
environment of a modern Non-Linear Editing (NLE) system.
LSP is a media integration tool rather than an authoring tool. Media is generally created first, first in other
applications like Flash, Photoshop, Cleaner etc. and then brought into LSP. The developer needs to take
into consideration the workflow of 3rd party applications and ensure maximum compatibility.
The developer must include separate text files or diagrams that describe the structure of the project, the
uses of behaviours, and the placement of code. The organization and hierarchy of dynamically loaded child
movies must also be explained in these documents. Include the location of any internal documentation, file
naming conventions, and media asset naming protocols.
PROGRAMMING
code structures and language, which are clear and easy to understand by other developers.
The following guidelines should be followed:
• Centralize and organize all Qscript logically so it is easy to find.
• Avoid any instances of hard-coding data within functions and methods. Instead use the
Defines Window.

• ‘Test’ and ‘debug’ code should be identified with comments, indicating the purpose of the
code where necessary.
• The developer must name each script in a way that indicates its function (“MAIN Parent
script”, “Create Play List Script”, “rotation behaviour”, etc.).
• The developer must use a system for naming variables and properties that clearly identi-
fies the scope. The system must be used consistently across the program. See Naming
Conventions Below.
• Code must be cleanly written and formatted, and all redundant code must be removed.
Refactoring should be considered if the code has become unclear or has evolved into a
bad design. Refactoring is the process of changing code in such a way that does not alter
the external behavior of the code, yet improves its internal structure. The goal is improve
the programming design and maintainability and to restore coherence and flexibility.
NAMING CONVENTIONS
Naming conventions are a high priority when building a project, not only for a developer’s internal
organization, but to enable easy sharing and reuse across multiple developers.
There are two schools of thought with respect to naming conventions: the underscore school and the first
letter capitalized school.
The underscore school uses “_” to separate the words (my_variable_defined)
The first letter capital school separates the words by putting the first letter of each word in caps
(MyVariableDefined)
You should never leave a space in the file name nor use any special characters other than an underscore.
Do not begin the file name with a number either.
File and Folder Names
LiveStage Professional authoring will necessitate the use of many different file types and formats. The
developer will be using .swf, JPEG, MP4, .MP3, .mov, and .gif to name a few. They will also be using
multiple instances and versions of these files. File names must therefore be as descriptive of the file’s
content as possible. An example of using an appropriate file naming convention to ensure proper sorting
and tracking could be:
InitialFileName_YYMMDD_Version_ModifiedBy.FileExtension
EXAMPLE:
Spinner_040315_02B_DONAT.LSD
ModifiedBy = The Individual Developers Initials or other agreed upon descriptor.

Folders should be organized as per the structure described in Section 7 of this document.
Object Names
An ‘object’ in LSP refers to a movie, track, sample, or sprite. It is important to give them a name that
describes their content for ease of use at a later date.
Variable names
Variables have different levels of scope within an LSP application. Just as with Flash or Director, it is
beneficial to add a single letter prefix to denote what scope level a particular variable may have, shown
as follows:
Local Variable: lMyVariable

Sprite Variable: sMyVariable
Global Variable: gMyVariable
Movie Variable: mMyVariable
Assign logical and descriptive names. For example, mCountDown would be more obvious than mCntDn.
COMMENTING

Commenting QScript should be done using // for a single line and /* */ for multiple lines. This helps any
developer understand what the script does.
Best practices would dictate that developers should:
• In the Defines Window include comments on the project name, purpose, and variables.
custom behaviours, who programmed it, unusual programming, dependencies, and any
other important information.
• Input comments at the beginning of each script related to its function. And add com-
ments before each main section of the script. In short, comment any code, which would
not be immediately understood.

MODULAR PROGRAMMING
Within a Project
The ability to share QScript within a project allows developers to easily and quickly update the QScript if
needed
Defines
When using Defines, developers can easily define, set, and alter specific QScript values and parameters
to be used inside its script. Once Defines are declared in the Defines Window, developers can refer to it
throughout the entire project. Changing the Defines changes all the incidents calling it. This also simplifies
the script throughout the project.
As a rule of thumb, it is recommended to use a ‘k’ as the prefix for a constant (konstant), as it will prevent
it from being confused with variables. Note that these constants cannot be changed at run time.
kMyConstant = “My Text to display”
Custom Events Handlers
Custom event handlers are a good way to create sub-routines within an LSP project. Developers can
set a script up as a custom event, and trigger it when needed. This is especially useful if developers
wish to use the same script at several locations, thereby avoiding the extensive use of cut-and-paste if
something changes. If a parameter or value needs to be external to the custom event handler, simply set
a variable to be used, within the handler.
Refer to the LSP manual for further details on how to create and trigger custom event handlers.
Across Projects
Includes
Includes are similar to Defines, except that they are not stored within a project but inside an external text
file generally called “Includes.qsf”, located in the libraries. Developers can then refer to the Includes from
any LSP projects accessing the libraries. Using Includes allows developers to share several constants
across several projects, making global updates and changes easier.
Behaviours
Behaviors allow developers to share QScript across projects while allowing custom parameters to be set.
Once built, they can be reused over and over within a project or across projects. It is recommended to
follow the various guidelines proposed in the LSP manual. The use of behaviours is essential for proper
Object Oriented Programming.

External Tracks
If developers want to share more than QScript code across projects, for example, share functionalities, LSP
allows them to share external tracks (or widgets) across projects and more specifically Sprite Tracks. For
example, you can build a custom branded movie controller in a single sprite track, export it as a QuickTime
movie and import it into another project. Updating the movie controller will update (upon recompiling) all
the other projects using it.
Please refer to the following tutorial for more information:

http://stagedoor.totallyhip.com/direct.asp?TOPIC=Resource&RESOURCE_ID=7&ITEM_ID=130
External Movies Loaded Within MIAM
Another way to share functionalities across projects is to load the functionalities into a Movie Track in
the QuickTime movie. It uses the same concept as the external tracks, described above, but allows the
QuickTime movie to be updated at runtime.
SHARING PROJECTS AND PROJECT REPORTS
Export Gathered Project
The ’export gathered project’ command allows the developer to gather all the media used in the LSP
project into one location. The ‘gathered’ file can be used as a back-up and also prevents the omission of
media files when transferring a project to another location. However, it is not acceptable as a final project
deliverable in itself.
Folder Name Functionality
The ‘Folder Name’ functionality in LSP allows developers to arrange their media source files within folders
inside the Libraries and then create the appropriate tracks, samples, and sprites instantly by simply
dragging the folders to the Timeline or Stage. For example, developers could create an entire sprite track
containing several sprites with roll over states and behaviours attached to them, by simply dragging and
dropping a folder.
Refer to the following StageDoor tech note for the list of pre-defined naming and organization conventions:
http://stagedoor.totallyhip.com/direct.asp?TOPIC=KBase&RESOURCE_ID=2&ITEM_ID=292
If this folder name functionality is used within a project, details must be provided within the
documentation.

Other Preprocessed File Names
In addition to the Folder Name functionality described above, media files used inside the Skin Fast Track
can be expediently named by simply dragging and dropping the files inside the SkinFastTrack.
Dragging and dropping a folder containing the following media into a SkinFastTrack will create a SkinFT
with the proper associated images.
• A single Photoshop file with 3 layers named ‘background’, ‘shape’, and ‘drag’, or 3 indi-
vidual files.
• A Folder called ‘close’ with 3 files named ‘up’, ‘down’, and ‘over’ (the file extension may
vary)
• A folder called ‘FullScreen’ with 3 files named ‘up’, ‘down’, and ‘over’ (the file extension
may vary)
Again these time saving procedures must be detailed within the documentation when they are used.
LSP XML Import/Export
An LSP project can be exported as an XML file describing the project itself. If the XML file is imported
into LSP, it will re-create the LSP project described within the XML file. This functionality allows for the
automation of XML-based projects, using 3rd party applications.
All automation will need to be detailed in the documentation. The developer must ensure that the
described automation will function across multiple platforms.

09 LEARNING OBJECT SPECIFIC STYLE GUIDE
9.A WHY A STYLE GUIDE?

It must be assumed that there is a high degree of probability that a learning object will be amended in
some fashion during its life on LearnAlberta.ca. To ensure a high level of continuity in look and feel, a style
guide must be developed and delivered to Alberta Learning with the completed learning object.
Please note that the style guide is a separate document from programming documentation, which must
also be supplied.
9.B STYLE GUIDE AUDIENCE
The style guide’s audience is a third party developer who may be asked to extend or reuse components
of the learning object. It should be assumed that this developer is an experienced professional, but would
have no previous experience with this specific learning object.
9.C LIBRARIES
Source files must be supplied on disk and referenced within the style guide. The working files must have
layers intact where applicable (PhotoShop, After Effects, etc.). The layers will need to be labeled and
referenced within the guide where applicable (button states for example).
9.D HIGH LEVEL OUTLINE
Below is a high level outline of what the learning object style guide should cover. In general, the finished
document should focus on definitions rather than rationale. The document should liberally cite the Library
CD of source files by file name and folder.
INTRODUCTION
Guide Overview
This is a brief overview of the guide, citing the main area of information and important points of reference
within the guide.
Deliverable Directory Structure

This is a visual diagram identifying all major files and folders required to build the project. The organization
of this diagram should conform to the directory structure detailed in Section 7 of this document.
LEARNING OBJECT OVERVIEW
A summary of the key information related to the learning object including:

Official Name
The official name of the learning object.
Authored Date
This is the date the project was completed.
Version Number
The version number of the guide including all the dates of any amendments made since version 1.0. It
should also include references to sections that were changed.
Developers
The vendor’s company and personnel involved in the learning object’s development as well as
individuals from Alberta Learning involved in the project. It should people’s roles or responsibilities in the
production.
Target Audience
The target audience is the primary audience for the specific resource. If choosing from K-12 grade level
audience groups, it can be described by division as well:
• Division 1: Kindergarten - Grade 3

• Division 2: Grades 4-6
Subject
The subject areas where the learning object is applicable.
Technology Requirements
A list of deployment technologies (including versions) required for viewing the resource. This must
conform to the information contained in the Supported Player / Plug-Ins section found in the Technical
Specifications document.
Architecture
The ‘sitemap’ of the object where a visual diagram with appropriate commentary is expected.
Sectional Descriptions
An ‘at-a-glance’ breakdown of each page/screen found in the object, including a brief description for
each.

VISUAL TREATMENT
Creative Rationale
Provide a brief rationale as to the overall visual objective. Why were certain colours, tones, textures, and
images chosen?
UI Specific Guidelines
This section covers the visual treatment and overall design of the various navigational elements.
References should be made to the accompanying library so third party developers can find and edit these
elements as needed.
Content Specifics Guidelines

This section will be very diverse from one guide to another as it covers the visual treatment of the content
itself. It will cover the dimensions of images and video, the fonts used, why, and what exceptions are being
made if any?
LEARNALBERTA.CA WRAPPER TREATMENT
Visual Treatment
Covers the visual adaptation of the meta-content elements.
Implementation
Discusses the technical incorporation of the Wrapper, along with the process of removal.
FUNCTIONAL DESIGN
Established Metaphor Rationale

The expected behaviour of all established metaphors within the learning object. This is particularly
important for unique response models.
UI Specific Guidelines
Covers the functionality and behaviour of the navigation and other non-content related elements. It need
only focus on functionality not addressed by the existing Functional Design Document.

10 REFERENCES
We have provided here a list of references, which supports this Cross-content Learning Object Style
Guide.
10.A INTERNAL
Technical Specifications
This document starts off by setting forth a list of principles and obligations that are upheld by Alberta
Learning. Application conformance is noted, along with a content model, which includes common Web
development practices and established standards. Hardware and software requirements are then detailed,
along with encouragement for the implementation of accessibility standards.
Functional Design Guidelines
The goal of this document is to ensure that learning objects from source A and B employ similar methods
of interaction for a consistent user experience. Recommendations are made for various aspects of learning
object design. These include various accessibility standards, content packaging, functional behaviour,
technical limitations, and visual design principles. Use case response models are also detailed to provide
further qualification.
Instructional Design Guidelines
According to the document, its purpose is to provide a frame of reference for the development and
evaluation of instructional designs. It does this first by making comparisons between three distinct
approaches to learning: the behaviourist, the cognitivist, and the constructivist. The instructional design of
learning objects is then broken down into core components, such as project & learner analysis, outcome
identification, instructional context, and pedagogical correlation. Instructional tasks are discussed and
examples (by academic subject) are given via correlation tables, a qualifying mechanism used by Alberta
Learning during the development process.
Interface Design Guidelines
Interface design obviously plays a key role in the user experience. This document basically touches on the
key areas: Elegance and Simplicity, Contrast and Proportion, Organization and Visual Structure, Module
and Program, Image and Representation, and Style. Each of these sections provides descriptions and
principles while noting common errors and providing possible solutions for each. Summaries are then
made to justify why each of these aspects of design are so important to the object as a whole.

10 REFERENCES
Government of Alberta Visual Identity Guidelines
This document defines the online representation of the Alberta provincial identity by providing guidelines
and best practices for aspects such as appearance, searching, and content. The specifications for
common elements are outlined and discussed first, including various navigational models and identifier
components. Searching mechanisms are then detailed in terms of predefined search forms and content
indexing. A high-level HTML meta-tag definition is also defined here. Content is then discussed, primarily in
relation to best practices for content preparation, along with general maintenance procedures. References
for each main facet of the document are also provided.
10.B EXTERNAL
WEB SPECIFIC RESOURCES AND LITERATURE
• W3C
This stands for the World Wide Web Consortium. Several relevant standards and specifi-
cations reside here, making it a valuable wealth of information: http://www.w3c.org
• Jakob Nielson, Designing Web Usability - New Riders, 2000
• Jesse James Garret, The Elements of User Experience - New Riders, 2003
• Jonathan and Lisa Price, Hot Text - New Riders, 2002
• Gerry McGovern and Rob Norton, Content Critical - Prentice Hall, 2002
• Louise Rosenfeld and Peter Morville, Information Architecture 2nd Edition - O’Reilly, 2002
• Steve Krug, Don’t Make Me Think - New Riders, 2002
SOFTWARE SPECIFIC DEVELOPMENT STANDARDS
Resources and Developer Centres

There are several valuable resources for the various authoring environments as listed below:
Flash
http://www.macromedia.com/devnet/mx/flash/
http://www.macromedia.com/support/flash/ts/documents/as_behavior_practices.htm
Director
http://www.macromedia.com/devnet/mx/director/
Dreamweaver
http://www.macromedia.com/devnet/mx/dreamweaver/

10 REFERENCES
QuickTime
http://www.apple.com/quicktime/tools_tips/
• Steven Gulie, QuickTime for the Web 3rd Edition - Morgan Kaufmann 2001
• Matthew Peterson, Interactive QuickTime - Morgan Kaufmann 2004
OTHER REFERENCES
• Charles F. Goldfarb and Paul Prescod, The XML Handbook 3rd Edition - Prentice Hall,
2002
• Edward Rolf Tufte, The Visual Display of Quantitative Information 2nd Edition - Graphics
Press, 2001
• Erik Spiekermann and E. M. Ginger, Stop Stealing Sheep and Find Out How Text Works
2nd Edition - Peach Pit Press, 2003
• Alan Cooper, The Inmates Are Running the Asylum - Sams Publishing, 1999
• Bruce Tognazzini, Tog on Interface - Addison-Wesley Publishing, 1992

11 GLOSSARY OF LEARNALBERTA.CA TERMS
Content Package
A Content Package comprises a parcel of learning materials, their description, their structure, and location
online.
http://www.imsglobal.org/content/packaging/index.cfm
Future Proofing
Future proofing means ensuring content has a long shelf life. It means that something (a learning object)
will remain valuable over a long period of time even as technologies and tastes change.
Future proofing can be addressed by ensuring:
• There is a high degree of granularity to encourage reuse.

• That visual design balances the contemporary with the classic.
• That projects, to a great extent, adhere to standards.
Granularity
Granularity refers to the relative complexity or extensiveness of a learning object in terms of how many
digital assets or files are aggregated or combined to form a learning object. OOAD ensures a certain level
of granularity. See ‘Future Proofing’ above.
The LearnALberta.ca Icon refers to the specific instance of the LearnAlberta.ca logo used in the
LearnALberta.ca Wrapper.
LearnAlberta.ca Wrapper
This is a required part of a UI for all LearnAlberta.ca learning objects. It houses the LearnAlberta.ca Icon
and a specific set of all common meta-content elements.
Learning Object
One or more digital assets combined and sequenced to create or support a learning experience
addressing a curricular outcome(s) for an identified audience(s). A learning object can be identified,
tracked, referenced, used and reused for a variety of learning experiences.
Learning Object Repository

A learning object repository is a database of learning objects stored on servers and catalogued or
organized using metadata.

Learning Resource
A learning resource is any item that can be used for learning (in school or at home) by a teacher, student
or parent. For the purposes of LearnAlberta.ca, a learning resource can be a learning object such
as an interactive multimedia concept lesson, a link to another useful Web site, or reference material
(encyclopedias, etc.) offered through the Online Reference Centre.
Masthead
The area on the top of a Web page or learning object. Includes essential information describing the content
and often includes branding elements.
Meta-Content
Also called non-content content. This is reoccurring content that is common to all learning objects
produced for LearnAlberta.ca. such as, Feedback, Copyright, etc.
Navigation
Global: links represented as menu elements common to all pages that provide direct access to key
areas of the site or multimedia project.
Local: links represented as menu that are complimentary to the Global Navigation, and relevant to
that particular section of the site.
Contextual: page specific links that appear within the course of a specific page’s content or as a
more prominent menu.
Courtesy: links common to all pages that provide direct access to affiliates or content not directly
related to the goals of the site.
Portal
The term used when referring to LearnAlberta.ca
Reuse
To use again, especially after special treatment or processing.
Share
To use again, with little or no special treatment or processing.
Multipurpose
To use again, especially after special treatment or processing permitting reuse across mediums.

Repurpose
To use again, especially after special treatment or processing permitting reuse across mediums and
audiences.
SuperNet
SuperNet is an unprecedented endeavour to provide affordable high-speed network connectivity and
Internet access to all universities, school boards, libraries, hospitals, provincial government buildings and
regional health authorities throughout the province. At the same time, SuperNet will ensure businesses
and residences in 422 communities will have access to high-speed Internet at competitive rates.
Wrapper
(see LearnALberta.ca Wrapper)
TERM CONSISTENCY LIST
Term to Use Instead of...

Desktop Desk Top
Email e-mail
Hotspot hot spot
Internet internet, Web, World Wide Web
learner Student, Pupil
learning Education, Schooling, Instruction
Login (Noun) Log-in, Sign In, Log In
log in (Verb) Log in, Log-in, Login
online on-line
plugin plug-in
Teacher educator, instructor
Test exam
(an evaluation Exercise, administered by a
teacher)
UserID User ID, User Name, Login Name
Website Web site
Portal Website
(when referring to LearnAlberta.ca)

LO Development Guide

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

LO Development Guide

Încărcat de

Drepturi de autor:

Formate disponibile

LEARNING OBJECT

204 - 1010 Chilco Street

04 THE LEARNALBERTA.CA WRAPPER 15

LEARNALBERTA.CA LEARNING OBJECT DEVELOPMENT GUIDE 2

06 GUIDELINES FOR CONTENT PRESENTATION 37

07 CODE DOCUMENTATION AND MEDIA CREATION 40

08 MEDIA SPECIFIC DEVELOPMENT 45

09 LEARNING OBJECT SPECIFIC STYLE GUIDE 58

11 GLOSSARY OF LEARNALBERTA.CA TERMS 64

LEARNALBERTA.CA LEARNING OBJECT DEVELOPMENT GUIDE 3

1) Content Development Technical Specifications

1.A WHO SHOULD USE THIS GUIDE

1.B PURPOSE OF THIS GUIDE

LEARNALBERTA.CA LEARNING OBJECT DEVELOPMENT GUIDE 4

1.C EXPECTATIONS OF THE DEVELOPER

• Object Orientated Analysis and Design

LEARNALBERTA.CA LEARNING OBJECT DEVELOPMENT GUIDE 5

1) Understanding the overall concept or objective of the LearnAlberta.ca portal.

1.D LIVING DOCUMENT

LEARNALBERTA.CA LEARNING OBJECT DEVELOPMENT GUIDE 6

2.A LEARNALBERTA.CA OVERVIEW

The portal has an intended audience of four user groups:

1) Learners (primary users)

2.B PRESENTATION OF LEARNING OBJECTS ON LEARNALBERTA.CA

LEARNALBERTA.CA LEARNING OBJECT DEVELOPMENT GUIDE 7

MORE INFORMATION PAGE

2.C WHERE LEARNING RESOURCES MAY BE USED

LEARNALBERTA.CA LEARNING OBJECT DEVELOPMENT GUIDE 8

2.D ADDITIONAL LEARNALBERTA.CA REFERENCE GUIDES

LEARNALBERTA.CA USER INTERFACE STYLE GUIDE

LEARNALBERTA.CA USABILITY REPORT

LEARNALBERTA.CA LEARNING OBJECT DEVELOPMENT GUIDE 9

3.A PERFORMANCE FACTORS

LEARNALBERTA.CA LEARNING OBJECT DEVELOPMENT GUIDE 10

TWO VERSIONS – FULL AND LITE

LEARNALBERTA.CA LEARNING OBJECT DEVELOPMENT GUIDE 11

OTHER DISPLAY CONSIDERATIONS

LEARNALBERTA.CA LEARNING OBJECT DEVELOPMENT GUIDE 12

3.C BROWSER NAVIGATION BAR AND BROWSER CHROME

SCROLLBARS AND WINDOW SIZE

3.D ACCESSIBILITY STANDARDS

LEARNALBERTA.CA LEARNING OBJECT DEVELOPMENT GUIDE 13

Simulated K-3 Penmanship:

Sans-Serif (Helvetica) Typeface:

Figure 3.1 - Typeface Comparison

LEARNALBERTA.CA LEARNING OBJECT DEVELOPMENT GUIDE 14

4.A WHAT IS IT?

4.B WHY DO WE NEED IT?

Figure 4.1 - Default Wrapper Wireframe

LEARNALBERTA.CA LEARNING OBJECT DEVELOPMENT GUIDE 15

4.C WHAT IS ON THE WRAPPER?

4.D WHAT IS NOT ON THE WRAPPER?

LEARNALBERTA.CA LEARNING OBJECT DEVELOPMENT GUIDE 16

4.E WHAT ARE THE RULES?

WRAPPER WINDOW DIMENSIONS

The default size of the window is 750 x 500 pixels.

WRAPPER ELEMENT DIMENSIONS & POSITIONING

LEARNALBERTA.CA LEARNING OBJECT DEVELOPMENT GUIDE 17

POSITIONING & WEIGHTING CONSIDERATIONS

WHAT TO DO WHEN META-CONTENT ELEMENTS DO NOT EXIST

4.F LEARNALBERTA.CA ICON TREATMENT

In terms of visual treatment, there are three options:

LEARNALBERTA.CA LEARNING OBJECT DEVELOPMENT GUIDE 18

��

��