Developing Instructional Products with Authorware 7 Richard Van Eck

Transcription

Developing Instructional Products with
Authorware 7
Richard Van Eck
University of Memphis
Copyright 2002
All rights reserved
Van Eck, TOC Through Chapter 11
Table of Contents
Developing Instructional Products with Authorware 7 .....................................i
Table of Contents .................................................................................................i
Preface .............................................................................................................viii
Welcome ......................................................................................................viii
About Me .....................................................................................................viii
Who this book is for ........................................................................................ x
What this book is NOT ................................................................................... xi
How to use this book .....................................................................................xii
Heads Up .................................................................................................. xiv
Tip/Power Tip........................................................................................... xiv
Case Study................................................................................................. xv
Making the Connection .............................................................................. xv
Summary & Exercises................................................................................ xv
The Website.................................................................................................. xvi
Chapter 1: What is Authorware? .......................................................................... 1
Overview ......................................................................................................... 1
Objectives........................................................................................................ 2
What is Authorware? ....................................................................................... 2
Why Authorware and Not __________? .......................................................... 7
Card-Based Metaphors................................................................................. 7
Cast/Timeline/Stage Metaphor..................................................................... 8
Icon & Flowline Metaphor........................................................................... 8
How Does Authorware Think?....................................................................... 10
The Flowline.............................................................................................. 10
Rules of the “Road” ................................................................................... 12
The Interface ................................................................................................. 14
Description .................................................................................................... 16
Presentation & Design Windows................................................................ 18
Pull-Down Menus and Buttons .................................................................. 18
What Else Will I Need? ................................................................................. 19
Image Editors............................................................................................. 19
Sound Editors ............................................................................................ 20
Movie Editors ............................................................................................ 21
Animation Tools ........................................................................................ 22
Management Tools .................................................................................... 23
Case Study..................................................................................................... 24
Summary ....................................................................................................... 27
Exercises ....................................................................................................... 29
Chapter 2: Pre-Planning the Project ................................................................... 31
Overview ....................................................................................................... 31
Objectives...................................................................................................... 32
Is CBT the Right Choice? .............................................................................. 32
Is the content stable?.................................................................................. 33
i
How much money and time are available? ................................................. 33
Does this project require CBI/CBT’s unique strengths, characteristics, and
capabilities?........................................................................................................... 33
Do my learners possess the necessary computing skills? ............................ 34
Do my learners have access to computers?................................................. 34
How do my learners feel about computers? ................................................ 34
Learning a la Mode........................................................................................ 34
Tutorials .................................................................................................... 35
Exploratory learning environments (ELEs) ................................................ 36
Simulations................................................................................................ 36
Games........................................................................................................ 38
Simulation Games...................................................................................... 40
Learner Preferences and Characteristics......................................................... 41
Age and gender.......................................................................................... 41
Cognitive styles ......................................................................................... 43
Field Independent/Dependent................................................................. 43
Leveling/Sharpening. ............................................................................. 43
Visual/Haptic Perceptual Style. .............................................................. 44
Impulsive/Reflective Cognitive Tempo. ................................................. 44
Learning styles........................................................................................... 45
Passive/Active........................................................................................ 45
Accessibility .................................................................................................. 45
Auditory considerations. ............................................................................ 46
Visual considerations. ................................................................................ 46
Physical considerations. ............................................................................. 47
Operating System Considerations .................................................................. 47
Delivery Considerations................................................................................. 49
Internet, Intranet, CD-ROM, Hard Drive.................................................... 50
Media Considerations ................................................................................ 53
Graphics................................................................................................. 53
Sound..................................................................................................... 54
Video. .................................................................................................... 56
Fonts.......................................................................................................... 57
Color Palettes & System Colors ................................................................. 59
Designing the Interface .................................................................................. 59
Metaphor ................................................................................................... 60
Screen design principles ................................................................................ 62
Light and Screen Design ............................................................................ 62
Backgrounds and Borders .......................................................................... 64
A place for everything, and everything in its place ..................................... 65
Consistency ............................................................................................... 67
Text and readability ................................................................................... 67
Usability .................................................................................................... 69
Case Study..................................................................................................... 70
Summary ....................................................................................................... 71
Exercises ....................................................................................................... 73
ii
Chapter 3: Planning & Managing the Instructional Title .................................... 74
Overview ....................................................................................................... 74
Objectives...................................................................................................... 75
Establishing a Timeline.................................................................................. 76
Goals & Objectives........................................................................................ 77
Treatment ...................................................................................................... 81
What is a treatment?................................................................................... 82
What goes into a treatment? ....................................................................... 82
Storyboards ................................................................................................... 90
Title, Date, and Branch Point ..................................................................... 92
Branch Point Information........................................................................... 94
Graphics/Animation/Video ........................................................................ 94
Audio......................................................................................................... 94
Interactivity ............................................................................................... 94
Text ........................................................................................................... 95
Scene Sketch.............................................................................................. 95
Notes to Programmer ................................................................................. 96
Style Sheets ................................................................................................... 96
Clarity, Brevity, & Usability ...................................................................... 97
Text Styles................................................................................................. 98
Colors ........................................................................................................ 98
Quality Control............................................................................................ 100
Working as a Team...................................................................................... 103
Client Interaction ......................................................................................... 106
The Wow Factor ...................................................................................... 107
Sign-offs and Documentation................................................................... 108
White Paper ................................................................................................. 109
Variable List................................................................................................ 111
Media Use and Copyright Issues.................................................................. 111
Case Study................................................................................................... 115
Summary ..................................................................................................... 117
Exercises ..................................................................................................... 118
Chapter 4: Beginning with Authorware............................................................ 119
Overview ..................................................................................................... 119
Objectives.................................................................................................... 119
Getting Started with Your Program.............................................................. 120
Setting File Properties.............................................................................. 120
Background Color.................................................................................... 122
Size.......................................................................................................... 123
Screen Placement..................................................................................... 125
Title Bar .................................................................................................. 126
Menu Bar................................................................................................. 127
Building Font Styles .................................................................................... 127
Color Palette ............................................................................................ 131
Adding Text & Shapes................................................................................. 132
The Toolbox ............................................................................................ 133
iii
Adding Text/Text Tool ................................................................................ 135
Font Styles............................................................................................... 137
Scrolling vs. Non-Scrolling...................................................................... 138
Anti-Aliasing ........................................................................................... 139
The RTF Objects Editor............................................................................... 140
Importing Graphics...................................................................................... 141
Aligning Objects.......................................................................................... 143
Aligning Objects Within icons ................................................................. 143
Aligning Object Between icons................................................................ 144
Inspectors .................................................................................................... 145
Modes...................................................................................................... 146
Colors ...................................................................................................... 148
Controlling the Flow.................................................................................... 150
Setting Transitions ................................................................................... 151
The Wait Icon .......................................................................................... 155
Working with Libraries................................................................................ 156
Case Study................................................................................................... 158
Summary ..................................................................................................... 159
Exercises ..................................................................................................... 160
Overview ..................................................................................................... 163
Objectives.................................................................................................... 164
Types of Animation ..................................................................................... 164
Basic animation ........................................................................................... 165
Display .................................................................................................... 165
Animation................................................................................................ 166
Run.......................................................................................................... 167
Test.......................................................................................................... 167
Dialog box (motion tab) ........................................................................... 168
Adding media, part I .................................................................................... 170
Sound ...................................................................................................... 170
Formats................................................................................................ 171
Voxware .............................................................................................. 172
Loading sound. .................................................................................... 173
A final note about sound .......................................................................... 178
Video....................................................................................................... 180
Formats & CoDecs............................................................................... 183
Size and storage. .................................................................................. 186
Loading video. ..................................................................................... 187
Controlling video. ................................................................................ 189
A Final Word on Video............................................................................ 191
Case Study................................................................................................... 192
Summary ..................................................................................................... 195
Making the Connection................................................................................ 196
Presenting Information............................................................................. 197
Guiding the Learner ................................................................................. 198
Learner control ........................................................................................ 199
iv
Motivation ............................................................................................... 200
Exercises ..................................................................................................... 201
References ................................................................................................... 205
Chapter 6: The Basic Interaction...................................................................... 206
Overview ..................................................................................................... 206
Objectives.................................................................................................... 208
Terminology ................................................................................................ 208
Anatomy of an Interaction ........................................................................... 209
Display (DIRECT)................................................................................... 216
Interaction (DIRECT) .............................................................................. 217
Responses (DIRECT)............................................................................... 218
Customizing Responses—an overview................................................. 222
Buttons. ............................................................................................... 226
Hotspots............................................................................................... 229
Hot Objects. ......................................................................................... 232
Pulldown Menus. ................................................................................. 233
Text Entry Responses........................................................................... 235
Tries Limit/Time Limit. ....................................................................... 238
Evaluate (DIRECT) ................................................................................. 240
Control (DIRECT) ................................................................................... 241
Track (DIRECT)...................................................................................... 242
Feedback & the Teachable Moment ............................................................. 243
Summary ..................................................................................................... 248
Practice and Guidance.............................................................................. 250
Practice and Transfer ............................................................................... 253
Assessment .............................................................................................. 254
Motivation ............................................................................................... 255
Exercises ..................................................................................................... 256
Chapter 7: frameworks .................................................................................... 262
Overview ..................................................................................................... 262
Objectives.................................................................................................... 262
Why use frameworks? ................................................................................. 263
Anatomy of a framework ............................................................................. 264
Navigation icons.......................................................................................... 268
Recent...................................................................................................... 269
Nearby ..................................................................................................... 270
Anywhere ................................................................................................ 271
Jump to Page............................................................................................ 273
Call & Return .......................................................................................... 273
Specifying transitions between pages ....................................................... 276
Adding common elements to a framework ................................................... 277
Lining up elements on pages .................................................................... 277
Adding automatic page numbers to a framework...................................... 278
Importing rtf files......................................................................................... 282
Case Study: Building a Glossary.................................................................. 288
v
Presenting Information............................................................................. 293
Guidance ................................................................................................. 295
Assessment .............................................................................................. 296
Summary ..................................................................................................... 296
Exercises ..................................................................................................... 298
References ................................................................................................... 300
Chapter 8: Publishing Your Program ............................................................... 301
Overview ..................................................................................................... 301
Objectives.................................................................................................... 302
Save & Compact.......................................................................................... 303
Publishing.................................................................................................... 305
Formats.................................................................................................... 305
Web Player Tab ....................................................................................... 307
For Web Player Tab ................................................................................. 309
Web Page Tab.......................................................................................... 312
Files Tab.................................................................................................. 316
What are you delivering? ......................................................................... 319
Where & when will the learning take place? ............................................ 320
How stable is the content?........................................................................ 321
Summary ..................................................................................................... 321
The Easy Way ............................................................................................. 322
For CD-ROM/Hard Drive ........................................................................ 322
Formats................................................................................................ 322
Package................................................................................................ 322
Files ..................................................................................................... 322
For Web................................................................................................... 323
Formats................................................................................................ 323
Package................................................................................................ 323
For Web Player .................................................................................... 323
Web Page............................................................................................. 323
Files ..................................................................................................... 323
Exercises ..................................................................................................... 323
Chapter 9: Variables, Functions, & Lists.......................................................... 325
Overview ..................................................................................................... 325
Objectives.................................................................................................... 326
Introduction ................................................................................................. 326
Variables ..................................................................................................... 327
Defined.................................................................................................... 327
Functions: Overview.................................................................................... 337
Functions & Variables ................................................................................. 337
WriteExtFile, ReadExtFile, & AppendExtFile.......................................... 338
GetNumber, GetLine, & GetWord ........................................................... 341
AddLinear, AddProperty, DeleteAtIndex, etc........................................... 344
Functions & Navigation............................................................................... 349
vi
The GoTo Function.................................................................................. 349
JumpFile, JumpFileReturn, JumpOut, JumpOutReturn............................. 351
Scripting ...................................................................................................... 354
The Calculation Window ......................................................................... 354
Creating Custom Variables ...................................................................... 364
Case Study................................................................................................... 368
Summary ..................................................................................................... 368
Exercises ..................................................................................................... 369
Chapter 10: Scripting....................................................................................... 373
Overview ..................................................................................................... 373
Objectives.................................................................................................... 373
Introduction ................................................................................................. 374
Scripting with Variables .............................................................................. 374
Setting & evaluating variables.................................................................. 375
Operators, If-then statements, and loops................................................... 376
Scripting with Functions .......................................................................... 392
Scripting with Linear & Property Lists..................................................... 393
Time ........................................................................................................ 400
Accuracy ................................................................................................. 401
Path ......................................................................................................... 402
Case Study................................................................................................... 403
Summary ..................................................................................................... 408
Exercises ..................................................................................................... 409
Chapter 11: Knowledge Objects, BOTS, and Commands................................. 412
Overview ..................................................................................................... 412
Objectives.................................................................................................... 412
KOs, Commands, & BOTS, Defined............................................................ 413
BOTS ...................................................................................................... 413
BOTS & Functions/Variables................................................................... 416
BOTS & Properties.................................................................................. 418
Commands................................................................................................... 420
To Package & Access a Command............................................................... 423
Knowledge Objects...................................................................................... 424
Summary ..................................................................................................... 426
Exercises ..................................................................................................... 428
vii
Preface
Welcome
Welcome to the world of interactive instructional design and development. In selecting
this text and Authorware as your development tool, you have taken the first steps toward
becoming a designer and developer of computer-based instruction/training (CBI/CBT).
Whether you want to create small, interactive components to illustrate concepts as part of
a larger course or develop complete computer-based courses or curriculum, Authorware
is the right tool for you. Long the staple of corporate training departments that use CBT,
Authorware has gained a strong following for the development of instructional products
for use in schools and homes as well. Authorware makes it easy to develop complex
interactive instruction in much less time than any other program.
Unfortunately, learning Authorware on your own can be a frustrating experience. This is
not because Authorware is inherently a difficult program, but because it is so different
from other programs that we have no frame of reference to help us figure out how it
works. That’s where this book comes in. Depending on how much time you are willing
and able to devote to learning Authorware, you can learn to develop basic interactive
instruction with Authorware and this book in 24 hours. (Of course, I recommend that you
spread those 24 hours out over the course of several weeks, interspersed with lots of
practice, but we’ll get to that later.)
About Me
viii
So who am I and why should you trust me with the time and energy it will take to learn
Authorware? I began working with Authorware in 1993 (then version 2.0). I taught
myself the rudiments of Authorware through trial and error (more of the latter than the
former, I’m afraid). When I returned to graduate school for my Ph.D. in instructional
design, my major professor suggested that as part of my GA duties I should learn
Authorware (then version 3.0). I spent 20 hours per week for 20 weeks refining and
updating my Authorware skills to the point that I could develop (very) basic instruction
(i.e., graphics and text with simple animation and limited interactivity). It was only after I
had developed two moderate instructional products for other professors that I took my
first formal instruction in Authorware. During the first of two courses I took I became a
competent Authorware programmer. My authoring experience continued as I began
working on several projects of my own and for other people, and culminated in an
instructional game I created for my dissertation. It was not until that final game, 7 years
after I first started, that I became what I would call an intermediate Authorware
programmer.
That is the hard way to learn Authorware. I learned a lot about where the common pitfalls
and misconceptions lie when first learning Authorware on your own, and I have
developed some ways to think about Authorware that can help make it easier to learn. I
have taught Authorware (alternately beginning and intermediate) to college students of
all ages and levels of experience every semester since 1999. I have continued to develop
products as a private consultant for large corporations, small businesses, and individuals,
and I have conducted Authorware training workshops as well. These experiences have
helped me develop an approach to teaching Authorware that I think is effective and
ix
(relatively!) painless. This book is my attempt to share what I have learned with you, so
that you can learn to develop CBI/CBT without investing years in the process.
Who this book is for
I have made every attempt to make this book relevant to as many people as possible. It is
not, however, possible to be all things to all people, and so there are some assumptions I
make about who you are.
First, I assume that you have pretty good computer skills to start with. If you are not a
regular user of word processing, email, and Internet browser programs, you will probably
have to work harder than most to learn Authorware. You may want to read Chapter 1
closely if you think this applies to you, as I describe some other programs that, although
less powerful, are also easier to learn (Hyperstudio, for instance).
Secondly, I assume that you are interested in developing effective interactive
instructional products that adhere to the tenets of instructional design and learning theory.
Whether you are an instructor who wants to develop interactive computer-based or webbased modules for students to practice concepts discussed in class or a corporate trainer
who needs to develop more efficient and cost-effective training for new employees, using
Authorware in combination with ID principles allows you to create instruction that you
can evaluate for effectiveness.
If you are interested in creating non-interactive, non-instructional products, there may be
better tools and books for you (Flash, for instance). Authorware’s strength lies in its
ability to create interactive instruction and track learner responses and data, and while
x
Authorware can incorporate and support components developed with products like Flash,
if your focus is not on developing instructional products, Authorware should not be your
first choice.
Thirdly, I assume that you have had some instructional design training, at least to the
point that you understand instructional design (ID) models, goals and objectives,
assessment, and instructional strategies. While I will attempt to provide some background
information, there is not enough space to treat both the field of ID and teach Authorware
at the same time. Although this book is designed to be used as a textbook for Authorware
classes similar to the ones I teach at the university level, you should not have trouble
using the book if that is not your environment.
What this book is NOT
This book is first and foremost an Authorware book. Because I wrote it with ID graduate
students in mind, it is primarily an instructional designer’s Authorware book. There are
several excellent books available that treat the design of CBI/CBT as their primary focus
(e.g., Allessi and Trollip). This book is deliberately not that kind of book. The reason for
this is that those books are (necessarily), 300 to 400 pages in length. Were I to combine
the two approaches, this book would number some 1000 pages. In my opinion, such a
book would have limited usefulness. For one thing, it could not be fully used in a
semester-long course. More importantly, however, the cognitive load of learning
Authorware and CBI/CBT design theory simultaneously would virtually ensure that you
learned neither very well.
xi
This book is also not an “Authorware Bible.” Many books about software attempt to
cover everything about the program in excruciating detail. While this is useful in a book
designed to be a reference, I believe that when you are learning a program, you want the
author to pull out the most important points and present them as efficiently and succinctly
as possible. To that end, I have focused on using Authorware to build the kinds of
interactive instruction that most instructional designers want to be able to build. This
book, and lots of practice, will take you to the intermediate level; expertise lies in taking
on complex projects and learning how to extend Authorware, and I make no attempt to do
that in this book.
How to use this book
When you are done reading this preface, the first thing you need to do before you go any
further is to go to our website and register. Once you have done this, you will have a user
name and password that will allow you full access to the resources on the site, including
royalty free media for use in your projects, more Authorware tips and tricks, extra,
contact with other Authorware developers, and even access to a small amount of space on
our server so you can test out the web program you will develop by the end of chapter 8.
Each chapter in the book has it’s own section on the website where you can access
supporting files, examples, and documentation related to that chapter, so you will want to
have access to an internet connection on your computer while you read the book.
You will also need to have Authorware installed on a computer so that you can complete
the exercises at the end of each chapter. You can download a 30 day trial version of
Authorware from www.macromedia.com. At press time, we were working to secure a 45xii
day version of this program, so check the website to see if it is available there. You will
notice that the book is spiral bound, which makes it easier to lay out flat by your
computer as you work.
Additionally, there are several things you should know about how this book is organized
in order to make effective use of it. The first is that the book is divided into two parts:
beginning and intermediate. One problem I have found with textbooks on Authorware is
that they are either suitable for beginners or for intermediate users, not both. Beginning
books usually take a tutorial approach that seems to work well for beginning learners in
this area. Unfortunately, the requirements of the college CBI course and the desires of
students often exceed the content in such texts. This leaves instructors and students to try
to extend their knowledge on their own or to purchase an additional textbook. Other
books that go beyond the introductory levels of Authorware do not use the tutorial
approach and function more as a reference than a textbook. Such books require more
effort on the part of learners, who must sift through distracting material, and on the part
of the instructor, who must determine what to assign for reading, in what sequence and
amount, and what students should do as homework exercises. These activities cut into the
time instructors can spend working individually with students, developing ancillary (i.e.,
non-Authorware-related) assignments and lessons, and responding to homework and
project assignments.
The first eight chapters of this book focus on just what you need to know to create basic
interactive instruction, including presenting text, graphics, animations, sounds, and
movies, providing interactivity, tracking basic performance data, and packaging your
piece for use on other computers. This section does not tell you everything there is to
xiii
know about each of these things, only enough to do the bare minimum. Once you have
learned the basic process, the next eight chapters (Chapters 9-16) extend and refine this
knowledge so that you can begin to develop more complex, sophisticated programs.
You can follow the book straight through in sequence, either in one semester (two
chapters per week) or two semesters (one chapter per week). Once you have complete the
first half of the book, you can also skip around to the other chapters as you see fit, using
the second half of the text as a reference.
Each chapter is comprised of several elements to help guide you through the learning
process. Each chapter begins by providing a brief overview of what will be covered in the
chapter and why. The objectives then spell out what competencies you can expect to be
able to demonstrate by the end of the chapter. The main body of the text then begins, and
is itself comprised of several sections, described below.
Heads Up
I have found some concepts and rules within Authorware to be common sources of
confusion for beginning learners. I address these in the Heads Up section; anytime you
see one of these I highly recommend you read it carefully (of course, I think you should
read everything carefully!).
Tip/Power Tip
There are some shortcuts and techniques in Authorware that, if you take the time to learn
them, can save you time and/or allow you to create sophisticated, powerful products.
Nevertheless, in the interests of keeping the chapters as tightly focused on “just enough”
xiv
to do “just what you need,” I have pulled these out into what I call Tips or Power Tips.
Tips are suggestions that are fairly easily accomplished and/or allow you to do
moderately interesting things. Power Tips may be more complicated to do, allow you to
do impressive, powerful things, or both.
Case Study
In many of the chapters I include case studies or histories from projects that I or my
students have worked on. These are designed to illustrate concepts, ideas, or other issues
related to the content of that chapter.
Making the Connection
In this section I attempt to relate what you have been learning in this book to the field of
instructional design as it impacts the development of CBI/CBT. In particular, where
useful and relevant, I make the connection between what you can build in Authorware
and the four phases of instruction identified by Allessi and Trollip in their book
Multimedia for Learning (2001): presenting instruction, guidance, practice, and
assessment. This section can help you make intelligent use of the skills you are acquiring
in Authorware.
Summary & Exercises
As you might expect, the summary attempts to reiterate the highlights of what was
covered in the book, while the exercises give you a chance to practice what you have
learned.
xv
Heads Up: I know that there is a tendency to overestimate how well you have learned
something from reading about it (I know because I suffer from the same malady). If you
do not do the exercises diligently, there is no way you will become proficient in
Authorware. In fact, there is no way you will truly master Authorware if all you do is
read the book and do the exercises. You need to put everything you learn immediately
into practice, or you will lose it. Therefore, I recommend that you read the first eight
chapters, do all the exercises, and develop your own, comparable program right away.
The only way to get really good at Authorware (good enough to make $100/hour
programming for other people, for instance) is to build lots of programs and continually
push the envelope, trying to do more complex things more efficiently as you go.
The Website
The website is designed to be more than just a place to read about Authorware. It is a
resource for graphics, sounds, animations, show-mes, and examples. You can even post
your own small test programs there to see if they work on the web!
We will also publish updates to the book, answer frequently asked questions, and provide
a way for you to interact with other people who are working with Authorware too. You
should check the site regularly to get the most out of your experience as you become an
Authorware developer. Welcome to the world of CBI/CBT development
xvi
Chapter 1: What is Authorware?
Overview
There was a movement in the sciences during the last century which held that truth and
knowledge are constructed by human beings and do not exist in and of themselves in the
universe, something akin to the adage about a tree falling in the forest with no one there
to hear it. In this theory, the way that human beings perceive things is modified by their
philosophical beliefs, perspective, attitudes, biases, etc. Strangely enough (or perhaps
not), this is also true of the tools that we design; a hammer is very good at what it does,
but it assumes that you are using nails and not screws, that you are connecting two pieces
of wood and not stone, and that you will strike the nail with the small round head rather
than the claw or side of the hammer. While you can certainly violate one or all of these
assumptions, your success will be limited because you are working against the tool’s
design.
Authorware, like any programming tool, also has its own way of “looking” at the
authoring process. While there are many possible ways to accomplish the same task,
Authorware makes some assumptions about how the authoring process should work.
Understanding how Authorware views the authoring process is critical to learning to
program in Authorware, and this book begins with this in mind. To that end, it is also
helpful to understand the metaphor that Authorware uses in the creation of interactive
multimedia and how that metaphor compares to those underlying other authoring
programs. In addition to learning about Authorware’s approach, you will also learn about
other programs that are helpful when authoring multimedia CBI/CBT. It may seem a little
odd to begin with this discussion in light of the content of Chapters 2 and 3, which are
1
not focused on Authorware per se, but it is important enough that it should be discussed
separately from the “how-to”s of Authorware.
Objectives
At the end of this chapter, you will be able to:
•
Describe how Authorware presents a program (flows)
•
Use the five main icons needed to present multiple text, sound, and video content
•
Identify the design and development strategy that expert Authorware
programmers follow
What is Authorware?
Authorware is an object-oriented authoring tool. In order to understand what this means,
let’s take a closer look at the terminology. “Object-oriented” can best be understood in
contrast with the term “programming language.”
Ten years ago, if you wanted to create programs to run on a computer, you needed to
know a programming language. Programming languages you may have heard of include
Fortran, Pascal, Basic, and the most popular today, C++ and Java. While these
languages are all different (although Java and C++ have a lot in common), they are all
identical with respect to the process of creating a program; you have to learn the
particular lingo and commands in these programs and then type hundreds or thousands of
lines of “code” that specify how the program should behave under different
circumstances.
2
As you might suspect, not everyone was willing or able to learn these languages, and
those who did were more likely to use them to build other, larger applications (e.g., word
processors, graphic editors, and games) than they were to develop training or
instructional applications. This is because the investment in time and mental energy
required to master these languages was such that the relative few who became expert
were in high demand and could command better salaries working for big software
development companies than they could developing small training applications.
As we moved from a command interface like DOS to a graphic interface like the Mac or
Windows operating system (a move reflective of the increasing number of computer
users and of the relative complexity of command interfaces), the process of using these
languages has been gradually simplified to the point that they are easier to learn.
Examples of this include the popular “visual” series of programs: Visual C++, Visual
Java, Visual Basic, etc. These programs ‘hide’ much of the programming language by
combining chunks of code into single objects based on function. For example, rather than
typing several lines of code to create a button, position it on the screen, and specify how
it looks when up and when pressed (i.e., clicked by the user), programmers could instead
‘drag’ a button onto the screen they were creating and all the code that goes with it would
be automatically created, saving a lot of time.
Yet while these programs became easier to use, they still required a significant
investment of time and energy to master, because you still needed to understand the
underlying programming language to create a complete program. As a result of this, there
were, and are, still a relatively small number of people who have mastered these
3
languages, and these people are still in great demand for building software applications
rather than training applications.
There is another reason that these tools have not been widely adopted for the creation of
learning and training applications, however. The demands of a training or learning
application are much narrower and more specific than the demands of a fully developed
computer application such as a spreadsheet or database program. Instructional products
are designed to present information to individuals, provide for a means of processing,
elaborating upon, and interacting with that information, and to assess learner
performance. While all of these things can be accomplished with programming
languages, those languages are set up to do a great many other, more complex, things. In
other words, they are not specifically designed for what trainers and instructors want to
accomplish with CBI/CBT.
Another equivalent analogy may make this more clear. Suppose I want to create a flyer to
sell some items I no longer need. I plan to have a bold, catchy headline and a short list of
items for sale. I have decided that I don’t need pictures or graphics. I could use any
number of computer programs to generate this flyer, but the two most relevant might be a
word processor and a desktop publishing program. We are all familiar with word
processors, and you can imagine how I might create flyer by typing text and centering it,
changing the font size, etc. Desktop publishing programs are used to create professional
publications such as books, magazines, and newspapers. While I could use such a
program to create the flyer, desktop publishing programs are necessarily more complex
than word processors, because they must do so much more. For example, I would have to
create and position a text box on my screen prior to selecting and modifying the text
4
itself. Because a desktop publishing program must necessarily allow you to work with
text and graphic elements, I must then select the text tool in order to modify my text,
whereas the word processor assumes you are working with text as its default. Because the
word processor focuses predominantly on text, it can devote the majority of its interface
to text-related tools, which makes it easier to make my modifications than if I were in a
desktop publishing program, which may have to place some of these commands in less
accessible places in order to provide access to other, non-text-related tools. While nothing
prevents me from using either tool, clearly, I would be better off using the word
processor, because it is more focused on what I want to be able to create.
The last decade has seen the rise of a new class of programs designed for those with little
or no programming experience. These programs go by many names, but they can all be
classified as object-oriented authoring tools. These tools, of which Authorware is an
example, make it possible to create interactive multimedia programs with little or no
knowledge of a programming language. In addition, they are easier to use because they
focus on the elements most relevant to developing multimedia presentations rather than
on those relevant to developing full-blown computer software. In general, they are less
complex, better suited to the development of CBI/CBT, and easier to learn than any
programming language.
Authorware is one of these object-oriented authoring tools, in this case designed
specifically for the development of interactive CBI/CBT. It is easier to use than a
programming language and, as will be seen in the next section, probably the best choice
among all such tools for developing CBI/CBT.
5
Heads Up: All object-oriented authoring tools make use of SOME programming
language, and most, including Authorware, require knowledge of that language to make
full use of all of the capabilities of the program and to become an expert. However, it IS
possible to develop basic programs without typing any lines of code.
6
Why Authorware and Not __________?
You have probably heard of many tools that can be used to develop interactive
multimedia. A logical question then, is why choose Authorware instead of one of these
other tools? The problem with this question is that the efficacy of any tool is dependent
on the context in which it is used. In the case of authoring tools, this includes the content
to be taught, the intended audience, the intended instructional strategies, and the
preferences of the developer.
Rather than focus on specific programs, it might be more useful to examine the
metaphors used by different programs that are available, some examples of each type,
and some of the strengths and weaknesses associated with different programs.
Card-Based Metaphors
Some programs make use of a card metaphor. In these programs, a stack of cards is
created, each with different material and interactivity on it. The learner progresses
through the program one card at a time, often in a linear fashion but not necessarily so.
While many options and features are built in, some knowledge of scripting language is
often needed as well. Perhaps the best-known examples of a card-based metaphor are
Hypercard and HyperStudio. These programs are easy to learn but have only rudimentary
animation abilities, do not easily track learner responses easily, and do not incorporate
sophisticated interactions such as matching or drag and drop. A more sophisticated
example of this kind of program targeted more toward CBI/CBT can be found in
Toolbook. Toolbook is more powerful than Hypercard/HyperStudio and is suitable for
developing CBI/CBT.
7
Cast/Timeline/Stage Metaphor
These programs make use of a theater metaphor, in which all elements (cast members)
are assembled together on a “stage,” and controlled through the use of a timeline. The
timeline is composed of multiple “tracks,” each of which can represent a virtually
unlimited amount of cast members and actions. The most popular examples of this
metaphor include Director and Flash. They are very powerful in the sense that you can
control individual cast members by writing scripts (the theater metaphor again) that
specify how they should behave. This, however, is also one of their weaknesses, in that
some knowledge of scripting is usually needed to create complex programs. They are also
excellent animation tools. Unfortunately, they are not very good or intuitive at creating
interactions easily, and they do not track learner data and responses automatically,
meaning that training applications require significant scripting.
Icon & Flowline Metaphor
These programs make use of a drag and drop metaphor in which icons are dragged onto a
flowline. Each icon represents different capabilities and functions of the program, and the
flowline specifies when and how things happen on the screen by controlling when and
how the program processes each icon. Authorware is an example of this type of program.
Authorware requires little to no scripting knowledge, is targeted specifically to the
development of interactive CBI/CBT (one of the icons is called an interaction icon), and
automatically tracks a multitude of information about the learner and his or her
interactions with the program. It is probably the fastest tool for building training
applications in terms of the basic presentation of information, interactions on the part of
8
the learner, and assessment of learning. It is not nearly as good as Director or Flash in
terms of animation, and its internal drawing tools are rudimentary. Luckily, it allows for
the inclusion of Director and Flash movies, as well as graphics and sounds created in any
program, meaning that you get the best of both worlds.
As a stand-alone tool, none of these programs is really suited to the development of
sophisticated multimedia CBI/CBT. Unlike most other tools, however, Authorware takes
care of the most critical functions of CBI/CBT, while allowing for the inclusion of a
variety of graphic, animation, and other multimedia, even if that media must be created in
another program. This makes it possible to develop sophisticated multimedia CBI/CBT
much more quickly and easily than is possible with other tools. Table 3 summarizes the
programs mentioned specifically above along with with their strengths and weaknesses.
Table 3.
Interactivity
Media
Data
Tracking
HyperCard, Rudimentary
HyperStudio
Most
Requires
Scripting
Rudimentary
Fast
Low
Director,
Flash
Sophisticated,
but difficult
(requires
scripting)
Most
Requires
Scripting
Sophisticated
SlowMedium
Medium-High
Authorware
Sophisticated
and Easy
Most
Automatic
Rudimentary,
but allows for
others
Fast
Medium
9
Animation
Time to
Develop
Learning
Curve
How Does Authorware Think?
Like all programs, Authorware will do exactly what you tell it to do. The problems arise
when you think you are telling it one thing and it does another—in other words, when
there is a communication problem. Programmers use a term to describe this phenomenon
called GIGO, which stands for Garbage In, Garbage Out. The next sections describe the
way Authorware views the authoring process.
The Flowline
The flowline is the most critical element of Authorware. It determines how Authorware
will present the information in your program to the learner. Understanding this process is
critical to de-bugging your program, which probably accounts for at least 30% of your
project development time.
I always imagine that Authorware is a little jogger, running down the flowline. Other
metaphors are just as effective (e.g., a river, a pachinko game, etc.,) so feel free to use
your own. When I run an Authorware program, that little person starts at the top of the
flowline and tries to get down to the bottom as fast as he/she can. The problem (for this
person) is that there are rules governing when and where she/he can go. An abbreviated
list of these rules are that this person must:
1. Start at the top of the flowline
2. Move from top to bottom
10
a. Unless there are icons that go off to the right of the flowline, in which case
he/she must follow them from left to right, looking at or displaying the
contents of each one before moving on to the next icon on the flowline
3. Do what each icon says to do
a. Show everything she/he sees (graphics, text, sound, video, animation, etc.)
b. Perform calculations
c. Wait for learner input
4. Leave everything on the screen until told otherwise
5. Put each new thing up on the screen on top of what came before it
6. Keep track of everything that happens
The only things that can stop this jogger are wait icons, interactions, and empty icons.
Wait icons, as you might expect, are just stop signs that tell Authorware to wait for some
period of time, for the learner to click the mouse or a button, or for any combination of
these. Interactions are places in the program where you want the learner to interact with
the program in some way, such as by clicking on a button or dragging something from
one place to another. You will learn about these icons and processes in later chapters. For
now, let’s talk about the third thing that can cause the Authorware jogger to stop: empty
icons. To do this, we need to talk about the logic of how programs are built in
Authorware.
11
Rules of the “Road”
Building your program in Authorware is accomplished by determining which icon you
need based on what you want to have happen, dragging that icon to the flowline,
arranging the icons on the flowline in the order you want things to happen. While you can
do this one icon at a time, Authorware rewards you for building what I think of as scenes
(i.e., scenes in a movie), each of which requires several icons, and then running the
program.
The reason for following this process is that it greatly speeds up the authoring process.
This is because, more often than not, what you do with one icon (play a sound, show text
or graphics, erase something, animate something, etc.) is directly related to one or more
icons elsewhere in the program. This means that you often need to “see” the contents of a
different icon than the one you are working on. If you open up each icon and attempt to
work on it individually, you will not be able to “see” anything but the current icon, which
makes it difficult to build a program that matches the image you have in your mind. For
instance, a common and frequent need is to be able to erase something from the screen
after you are done displaying it. Because of the way programs are built in Authorware,
the thing you may want to erase may have been first displayed on the screen many icons
prior to the point at which you want to erase it. Building this “scene” by first laying out
the icons you will need to use and then running the program allows you to see what is
displayed to the learner at the point you want to erase something (or animate, or add,
etc.). This approach to building scenes (multiple icons that together form a small chunk
of your program) is actually part of a larger process that all expert Authorware
programmers follow; building programs from the top down.
12
The biggest single difference between novice and expert programmers in any
programming tool is that novices tend to think linearly while experts think in a top down
manner. In the case of Authorware, this means that novices tend to start building their
program from the beginning, one icon at a time, filling in all the details and parameters
for each icon in each section, from start to finish. For example, novice developers will
create their title (a display icon), type in the text and format it, animate it, add music, etc.,
and only then move on to the first section of their program. Experts use the process I
described in the preceding paragraph, building individual sections in chunks.
But expert programmers extend this process to the entire program as well. Prior to
actually developing the individual “scenes,” in the program, they begin their program by
by laying out the overall structure of the entire program (kind of like writing an outline
prior to writing a paper). They make sure that the big picture makes sense and that they
understand how the program will work. They then build the functionality in to the
program (navigation, buttons, menus, etc.) without worrying about the actual content of
the program itself. Then they move on to developing each scene in the program as
described earlier. In Chapter 3, you’ll learn about the white paper, which is a kind of
outline for the functionality of your program, and is critical in this process.
Taking this approach has several advantages. First, and most significantly, it allows you
to become a more proficient developer at an earlier stage. No one really believes this until
they have been working with Authorware for a long time, but taking the top-down
approach saves time (at least 30%, in my experience) and cuts down on the revision
process significantly.
13
This approach also reduces the cognitive load on the part of novice developers, who are
learning as they develop their programs. You may find it difficult to do this when you are
just learning the basic functionality of each icon, but the sooner you implement this
strategy, the more quickly you will move from novice to intermediate developer.
The picture you have in your mind of what you want to have happen in your program is
from the perspective of the learner (e.g., first I want the learner to see a title, then I want
it to animate, then I want to erase the title and…). Half the journey toward becoming
proficient in Authorware lies in mastering the conversion of what is in your head to what
is on the flowline. By authoring as I suggest, you will be able to make this conversion
faster and with less stress.
But how can you run a program that has nothing but empty icons in it? When Authorware
is running a program and it comes to an icon with nothing in it (that is, an icon that has
never been modified) it will pause, open up that icon for you, and wait for you to put in
text or graphics (display icon), sound (sound icon), video (movie icon), or to let you
specify how long it should wait (pause icon) what it should erase (erase icon), etc. Once
you are done, you can close that window and Authorware will continue. That way, you
can build it as it goes to match the idea you have in your head of how it should look i.e.,
what the learner should see. This process becomes even more critical when working with
animations and drag-and-drop responses (target areas), as you will see in later chapters.
The Interface
As mentioned earlier, Authorware uses the flowline metaphor. You create your program
in Authorware by dragging icons onto that flowline (See Figure 7). Each icon has its own
14
purpose and abilities. The flowline organizes these icons into a sequence you determine
so that the learner moves through your program in the way you want. What follows is a
brief tour of the main elements of the Authorware interface. What is important right now
is that you become familiar with the interface and terminology. You will learn WHAT to
do with these elements later. For more detailed descriptions and practice, you can also
view the tutorial that comes with Authorware 7. We will begin with the flowline and
icons. Table 4 presents each icon along with a brief description of its purpose.
Figure 7. Authoring window with empty flowline.
15
Table 4
Icons used in Authorware
Icon
Description
Any time you want the learner to see some kind of text and/or graphics,
you use the Display icon. It is the most commonly used icon in
Authorware, since the vast majority of an instructional product entails
the presentation of text and graphics.
The Animate icon is used to make something on the screen move from
one place to another. Usually, this icon is used to move text or graphics
you have displayed using a display icon, but it can also be used to
animate movies. You will learn about simple animations in Chapter 5,
and advanced animations in Chapter 13.
Any text or graphic you display on the screen for the learner to view will
stay there until it is covered by another object or erased. The Erase icon
is used to erase text and graphics from the screen when you are done
displaying them.
As you might expect, the Pause icon allows you to pause the
presentation for a specified amount of time or until the learner clicks on
the screen, presses a key, or clicks a button. This is useful when you
want to allow enough time for the learner to process what is on the
screen, for example.
The Navigate icon allows you to specify where the program should go
next. Navigate icons can ONLY go to icons that are part of a
framework (see the next entry). As you will see in Chapter 7,
frameworks and navigate icons represent one of the most powerful
features in Authorware.
Frameworks function like slideshows: they allow you to attach
virtually unlimited “pages” that can be displayed one after the other like
a PowerPoint slideshow. They are most commonly used to organize
your program, control navigation, and allow the learner to proceed at his
or her own pace. You will learn about frameworks in Chapter 7.
Decision icons allow you to specify how the learner should move
through the “pages” that are attached. For example, you can tell
Authorware to display the attached items all in a row (sequentially) or
all at random. You can also tell Authorware to only choose a certain
number of the attached items. A common example is when you want to
provide 3 questions out of 16
a pool of 10 at random (so the learner gets
different questions each time they go through). You will learn about
decision icons in Chapter 12.
number of the attached items. A common example is when you want to
provide 3 questions out of a pool of 10 at random (so the learner gets
different questions each time they go through). You will learn about
decision icons in Chapter 12.
The Interaction icon is the most critical element in Authorware. It is
what allows you to create places in the program for the learner to
interact (i.e., make some sort of response). One of the more common
examples is the creation of quizzes or practice items such as multiplechoice questions. You will learn about simple interactions in Chapter 6
and advanced interactions in Chapter 12.
The Calculation icon allows you to customize the functions of your
Authorware program by entering in variables, functions, and code. It is
used to provide functionality that is not available through the simple use
of the other icons. You will learn about variables and functions in
Chapter 11.
Maps are like little suitcases that can hold unlimited numbers of icons.
They are useful because as you will see, there is a limited amount of
screen space to place maps on. Maps allow you to condense several
icons into one. You can still see all the icons by opening (doubleclicking) the map icon; all the icons are stored inside it. Maps also help
you organize your program: an introduction with titles, animations,
sound effects, and music could be 30 or more icons. A map lets you put
them all into one icon and name it “Introduction.”
The Movie icon allows you to play a digital video you have created
elsewhere. Unlike the display icon and sound icon, you cannot store
digital video inside Authorware. Instead, the video always lives outside
of Authorware as its own file.
The Sound icon lets you play any sound you want at any time.
The Video icon is used to play video from a videodisc player. These
devices used to be quite common but are now rare. Most programs will
never need to make use of this icon.
Note that while I will make reference to the process I have just described whenever I talk
about how to add text, graphics, sound, etc., to your program, it is always possible to
17
open up each icon individually by double-clicking on it. In fact, this is the only way to
make later modifications and changes to each icon once you have created it the first time.
Presentation & Design Windows
Authorware has two basic modes, each with its own window. When you are authoring
your program, you are working with the flowline and icons. This window/mode is called
authoring mode. In this mode, you can drag icons to and from the flowline or your
library, and you can open up individual icons to view their contents and/or make
modifications to those icons. When you are running your program to see how it looks and
behaves, you don’t need to see the flowline and icons, so Authorware hides them; you
want to see how it looks to the learner. This is called presentation mode. When
Authorware hits an empty/unmodified icon (or when you double click on any icon), it
shifts to authoring mode so you can make changes and modifications.
Pull-Down Menus and Buttons
Aside from the icons and the flowline, much of what you will use to modify your
program will be found in the pull-down menus. These commands and processes will be
discussed throughout the text as their uses become relevant. For now, you may just want
to explore these menus to familiarize yourself with their basic layout.
In particular, you will need to know about creating new files, saving files, and running
the piece. The file menu contains commands for creating, opening, saving, and closing
files. It operates much like most File menus in other programs. There are also button
equivalents for the first three of these commands; they are the first three buttons on the
18
task bar from left to right. The other menu you will need to use frequently is the Control
menu. This menu contains the commands to tell Authorware to run and stop the program,
which you will need to do periodically as you create and test your program. The
command to start your program from the beginning is Restart (ControlRestart). There
is a button equivalent for this function as well, which is the fifth button on your taskbar
from the right.
What Else Will I Need?
Although Authorware is one of the most powerful multimedia authoring tools, by far its
strongest point is its ability to build in interactivity and track user responses. You may
need additional programs to complete your CBI/CBT program if you want to include
things like sophisticated animation and digital video. Both Flash and Director files can
be integrated into Authorware to allow for sophisticated animations, interactive or not.
Likewise, there are a host of other supporting programs and tools that you may find
useful when developing CBI/CBT with Authorware. Because CBI/CBT usually contains
a multitude of graphics, sounds, and media, it is necessary in many cases to use tools
specifically designed to create and manipulate those files. The next sections describe the
nature and function of these tools.
Image Editors
Authorware contains a basic set of drawing tools, allowing you create shapes, lines, and
colors without leaving the program. It will also allow you to import a wide variety of
image formats, including gifs, jpegs, picts, bitmaps, and tiffs. If you want to create more
than basic shapes and colors (freehand drawing, gradient fills, etc.) or you want to edit an
19
existing image, you will need to have access to some kind of image editor. There are
many such programs available, and most of them share common functionality, so pick the
one you like best. Adobe Photoshop has long been the choice of graphics professionals
because of its rich set of features. It can be more complex for a novice to learn, however.
Adobe makes a simpler version called Photoshop Elements, which is much cheaper than
the full version, yet still has the capabilities needed to do most basic image editing tasks.
Macromedia makes a graphics editor called Fireworks, which is relatively inexpensive
and competes most closely with Adobe Photoshop. There are a host of editing programs
(Photoshop included) that are often bundled with other products such as digital cameras
and scanners. Although these programs may be limited versions of retail products, many
of the programs will be sufficient for your basic editing needs. There are also shareware
and freeware products. GraphicConverter is a fast, powerful program available for the
Macintosh platform. IrfanView is a popular image editor available for the Windows
platform.
Sound Editors
Authorware will allow you to import sound files and control when and how they are
played, but it will not allow you to create or modify sound files. To do that, you will need
some kind of a sound editing program. As with image editors, there are a variety of
choices ranging from inexpensive and simple to professional level sound editing choices.
Chances are that your needs can be met with a basic sound editor. Macromedia
SoundEdit 16 is an excellent tool for editing sound on the Macintosh platform and can
save sounds in all major industry formats, included wav files for the Windows platform.
Programs such as SoundForge and CoolEdit are popular choices for the Windows
20
platform. There are also freeware and shareware versions available for both platforms.
SndSampler is an extremely intuitive tool on the Macintosh platform, and GoldWave (32bit) is a popular shareware choice for the Windows platform.
Movie Editors
Digital video is a complex subject that requires much more space than can be devoted to
it here. Chapters 5 and 12 will present some of this information in more detail.
Authorware handles movies the way it handles sound; you can bring them in and control
playback to a certain extent, but you can’t capture or edit video with Authorware. There
are not as many options available for editing video as there are for other media forms.
The dominant video editor on both platforms has been Adobe Premiere. Premiere has
fallen behind the curve in recent years and has been struggling to catch up, however.
Premiere, like Photoshop, is also a complex tool which will not quickly or easily be
mastered by novices. If you got a copy of Premiere bundled with a card and are willing to
put in some study time, or if you are already a professional who has been using Premiere,
there is no reason to switch to another program. However, if you are not committed to the
Premiere program, you have other alternatives. Final Cut Pro has been gaining a lot of
converts lately because it is more flexible and powerful in many respects, although it is
only available for the Macintosh platform. It also is relatively inexpensive for educators
and students.
For most developers of CBI/CBT, FinalCut Pro and Premiere may be more tool than is
really required. iMovie is probably the most intuitive movie editing program I have seen,
and it ships free with all Macintosh computers. It can be learned in 30 minutes and can
21
produce movies for CD-ROM or the Web on either platform. If you have access to a
Macintosh with iMovie, it should probably be your first choice.
If you don’t have access to a Macintosh, you can use Premiere or whatever software was
bundled with your camera or firewire card. I have used one program that ships with the
Pinnacle StudioDV card that I feel is as intuitive as iMovie, although not as powerful
when exporting the final movie. Currently, the software is not available as a separate
product, but the Pinnacle StudioDV card bundle is relatively inexpensive.
Animation Tools
While Authorware has its own set of built-in animation tools, many developers find it
necessary to go outside of Authorware to achieve the sophisticated kind of animation
learners and clients have come to expect from CBI/CBT. The most widely used and
sophisticated animation tool is Macromedia’s Flash. As I mentioned earlier, Flash is
actually an authoring tool comparable to Authorware in capabilities. It is possible to
develop sophisticated animations with Flash that can then be imported into Authorware.
In particular, Flash is very good at working with transparency, “zooming” or scaling
objects up or down, and “morphing” one object into another. It works equally well with
graphics or text, and it has an excellent set of tools for creating drawings even in the
hands of those of us lacking artistic talent. Because it is an authoring tool in its own right,
and because it uses the theater/timeline metaphor, Flash takes a significant investment of
time to master completely. Luckily, however, it is not necessary to master the entire
program if your goal is to create basic animations with little or no interactivity for use in
Authorware.
22
There are other animation tools that can be used to create animations for use in
Authorware. Animated GIFs are probably the second most common type of animation on
the Web after Flash. Programs for creating animated GIFs are abundant and inexpensive.
GIF Builder (for the Mac OS 8.x /OS X) and Ulead GIF Animator (for Windows) are
two of the more widely used shareware programs for creating animated GIFs.
Management Tools
When you are just starting out as a designer/developer of CBI/CBT and your programs
are small, it is possible to manage your time and resources without the aid of
management tools. As you become more competent and start to take on more and/or
more complex tasks, it becomes both harder to manage your time and resources and more
critical that you do so.
You need to be able to track and manage your design and development time for two
reasons. First, you need to be able to determine how long jobs are going to take so that
you can schedule multiple jobs efficiently. If you don’t know how long each of your jobs
is likely to take, you will be forced to either turn down jobs (since you can’t be sure
you’ll be done with one job prior to taking the next) or you’ll double book jobs. Either
way, you lose income and run the risk of missed deadlines and poor PR.
The second and most critical reason you need to track and manage your time on each job
is so that you can get an idea how long each job will take and bill accordingly. By
tracking each job you do in detail, you not only gain a better understanding of where you
are in the program, but also how long it takes YOU to design and develop CBI/CBT.
When you take on future jobs and programs, you will then have a more accurate sense of
23
how long it will take to design and develop them. To be sure, each job is different, and it
is unlikely that the second or third job will take the same amount of time as the first. But
after five or six jobs, you will begin to see some commonality between jobs regarding
design and development task time.
Several tools exist that can help you track program time by setting up tasks specific to
your program (e.g., analysis, one-to-one evaluation, focus groups, etc.). When you are
working on a team project, this software is then installed on all designer/developers’
computers so that whenever they start working on a task, they start the timer for that task
and it then runs in the background.
Resource management software can also be employed to help organize and manage all
the media resources in the program. These perform a similar function as the media log
discussed earlier in that they collect the individual media and relevant information. What
makes them particularly useful is that they can not only track the copyright, file format,
and other information, but they actually store the media themselves in the form of a
database, so that once you find the media you are looking for, you also know exactly
where it is and can call it up from the program.
Case Study
By far, the most compelling aspect of Authorware is its ability to create multiple
opportunities for learner interactions and to automatically track a wide variety of data
about the learner’s interaction with your program. Authorware closest competitor,
Director, is capable of the same things, but the programmer must use a language called
Lingo to track and store information, and must build each interaction opportunity from
24
scratch (although later versions of Director have simplified some of these interaction
opportunities through “behavior” libraries). Authorware pre-specifies hundreds of
variables and functions (you will learn more about these in later chapters) that keep track
of data and allows you to create several different kinds of pre-specified interactions
quickly, and without the need for any programming language beyond the name of the
variables themselves.
It is difficult to identify a specific case study to illustrate this because every instructional
project I have ever created has made extensive and integral use of these features, and I
have never attempted to develop such projects in Director or Flash for the very reasons
presented above. Nevertheless, a discussion how these strengths play out specifically in
an Authorware project may be helpful.
A common strategy in CBI/CBT is to provide instruction, give and example, and allow
the learner to practice applying the instruction. This is sometimes referred to as ruleexample-practice. To create this in Authorware, I can provide the rule by creating a
display icon that contains the text (and or graphics) I want. The example might likewise
consist of a display icon. The practice would consist of an interaction icon along with one
additional icon for each “response” I want the learner to be able to choose (e.g., buttons,
places to click on the screen, fill in the blanks, etc.), in this case, lets assume I want four
buttons they can click.
Because I want the learner to be able to read the instruction at their own pace before
viewing the example, I might need two wait icons (in between the instruction and the
example, and between the example and practice) and two erase icons (one to erase the
25
instruction prior to showing the example, and one to erase the example prior to showing
the practice/interaction). This whole process involves dragging 11 icons to the flowline
(10 seconds) and running the program to fill in the content (which is determined by the
length of time it takes me to type text, apply font styles, click on things I want to erase,
etc.). All told, this is probably 5 minutes or less. The same process in Director would
involve creating a “cast member” for each piece of text, graphic, and button, dragging
those onto a timeline to create “sprites,” creating a line of Lingo to tell Director to
pause/loop in between the instruction and the example, and between the example and the
practice until a MouseUp event occurs, at which point another line of Lingo code to “Set
the visible” of each cast member with the text I want to earse to “FALSE,” and apply a
“behavior” to each of the four buttons in the practice opportunity to control what they
will do. Even accounting for the fact that I can save time by copying the code a behaviors
and by using behavior libraries, the process is significantly more complex and time
consuming than it is in Authorware.
But this is only part of the process; in instruction, we need to assess whether the learner
needs remediation or additional practice items based on their performance during
assessment. Let’s say that I want to know how many answers the learner got right, what
percentage of items were answered correctly, and how long the learner took during the
assessment. I might use this data in the following way; if, during assessment, the learner
makes three errors and/or their perecentage score drops below 90% and/or they take more
than the 20 minutes I have allotted for the assessment, I want the program to stop what it
is doing and send the learner back to the instruction for more practice.
26
In Authorware, this would involve using three variables called TotalWrong,
PercentCorrect, and SessionTime. Authorware automatically tracks this information for
me, so that all I need to do is tell Authorware that if TotalWrong equals 3 (i.e., the learner
missed three questions) or if PercentCorrect is less than 90 (i.e., the learner missed 10%
or more of the questions) or if SessionTime is greater than 20 minutes, then it should go
back to an earlier part of the program. This would involve dragging one icon onto the
flowline of my assessment section and typing the following:
If TotalWrong>3 | PercentCorrect<90 | SessionTime>20
The vertical bars ( | ) stand for “or.” It is not important that you understand variables or
syntax here; the point to remember is that we are talking about two actions. Once I have
done this, Authorware will track this no matter how many questions I have in my
assessment; if I add 30 questions later, it will still work without any additional
modification. In Director, you would need to create a variable for each thing you want to
track and write several lines of code in Lingo to accomplish it. While this can be done, it
is not as straightforward as it is in Authorware. This is NOT because Authorware is
“better” than Director; they are different tools designed for different purposes.
Summary
Authorware is a multimedia programming tool that is unparalleled in its ability to create
instructional products. Authorware uses a flowline metaphor to create, or author,
programs. icons are placed on a flowline according to the order in which the programmer
wants them to occur. Authorware presents these icons in order from top to bottom, left to
right. Each icon has its own abilities and properties, including text, graphics, or image
27
presentation (display icon), animation (animate icon), sound (sound icon), and movie
(movie icon). Authorware also can create opportunities for the learner to interact with the
program in some way (e.g., answer a question, click a button, type a response, etc.)
through the use of the interaction icon.
Although it is possible to accomplish tasks in more than one way, Authorware rewards
programmers who create programs the way Authorware was designed. This includes
using font styles, setting your file properties prior to beginning the authoring process,
making use of libraries, and building the structure of your program (or different sections
of your program) by dragging the appropriate icons to the flowline and then running the
program to fill in the content and specify how it appears on the screen.
While Authorware excels at almost all aspects of CBI/CBT authoring, especially
interactive instruction, there are elements of your program that may require the use of
outside programs. This may include programs for sound, image, and video editing as well
as more sophisticated animation programs. More importantly, Authorware cannot
compensate for improper application to instructional problems; it is appropriate only for
certain populations and instructional content.
Finally, all of the considerations about color, font styles, learner characteristics, etc., must
occur early and be documented to avoid inadvertent errors later that can result in lost
time, increased cost and frustration, or all three. The next two chapters will explore the
concept of documentation and pre-planning your project in more detail, which are critical
to managing the development process in all programming tools, including Authorware.
While it is possible to skip these chapters and continue learning more specifically about
28
Authorware if you have developed projects in other authoring tools and are familiar with
the planning and documentation process, doing so without this prior knowledge will
almost certainly result in serious revisions and problems later on.
Exercises
1) Think about what you know about the way Authorware flows. In the example below,
in which order will the icons on the flowline be presented?
a) Fred, Barney, Wilma, Betty, Bam-Bam
b) Fred, Barney, Wilma, Betty, Pebbles, Bam-Bam
c) Fred, Barney, Wilma, Pebbles, Betty, Bam-Bam
d) No way to tell
2) If you wanted to create a program that presented a title, paused for 5 seconds, erased
the title, played some music, then played a video, which icons would you use (present
them in order of their use in the program)?
3) Which of the sequences below would represent how an expert (or someone who
desires to become an expert) would develop the following program: The program will
be comprised of an introduction, two main instructional sections, one assessment
section, and an exit section with feedback and credits.
a) Build the structure of the introduction by dragging the necessary icons onto the
flowline, run the program, fill in the content and modify how it appears for each
scene, then proceed on to the next section until the program is done.
b) Drag all the icons needed for each section onto the flowline, open each one up
and fill in the content from start to finish until the program is done.
c) Create all five sections first and make sure all the navigation and structure is in
place, then go back and begin working on each section one scene at a time.
29
d) Begin programming each scene one icon at a time, from the first icon needed for
the introduction to the last icon needed for the credits.
30
Chapter 2: Pre-Planning the Project
Overview
As with the development of all instruction, success is largely determined by the time and
effort devoted to the instructional design process. While novice designers find it easy to
see the relevance of establishing goals and objectives, they often underestimate the
importance of careful learner analysis, specification of instructional strategies, and
learning/task analysis. It is only after the successful development of several instructional
projects and, in some cases, one or more failures, that the importance of these tasks
becomes more clear.
With the design and development of interactive computer-based instruction (CBI) and
computer-based training (CBT), however, there are several other pre-planning decisions
that must be made prior even to the instructional design process, and these decisions are
also often overlooked. The results of this can range from missed deadlines and blown
budgets to complete failure. Time spent up front thinking about the project itself can
impact the success of the final product as much as the time spent on the instructional
design process. These decisions need to be documented both as an aid to you (so you
don’t have to keep a running mental record) and to anyone else who will be working on
the project (as is the case in team-based authoring).
This chapter focuses on these pre-planning decisions and determinations necessary for
the successful design of CBI/CBT. While there will be some discussion of instructional
design considerations in this chapter, a complete discussion of the instructional design
process is beyond the scope of this book. For a more in-depth discussion of the
31
instructional design process, the reader is referred to Gagne, Briggs, & Wager’s excellent
text, Principles of Instructional Design (1992).
Objectives
At the end of this chapter, you will be able to make appropriate decisions about your
CBI/CBT project by:
•
Selecting an appropriate learning modality
•
Accounting for learning preferences and learner characteristics
•
Considering the OS and platform for final delivery
•
Specifying interface design considerations
Is CBT the Right Choice?
All learning modalities incorporate instructional content according to their strengths and
weaknesses: the medium modifies the message. Print-based instruction is good at
presenting text and graphics, allowing for anywhere/anytime access and review, but it is
not as good at incorporating modeling and individualized instruction as live, instructorled instruction. Video-based instruction is excellent for incorporating modeling and
teaching motor skills, but it is less successful at presenting large amounts of verbal
information, presenting practice opportunities, etc.
CBI/CBT has the potential to combine the best of all possible worlds. It is able to
incorporate graphics, text, sound, video, and animation. It can be customized to adapt to
learner performance and feedback (e.g., remediation, challenge, etc.), and it can be
32
accessed repeatedly. It does, however, place some restrictions and requirements on the
instruction and the learner. There are several questions that must be answered to
determine if CBI/CBT is appropriate.
Is the content stable?
Computer-based instruction is expensive to modify. If the content is likely to change
over a relatively short period of time and/or frequently, CBI/CBT may not be the best
option.
How much money and time are available?
CBI/CBT is very time consuming and costly to develop. It has been estimated that an
hour of CBI/CBT takes between 200 and 400 hours to develop. Costs go down with
multiple uses over a long period of time, however, since making copies of instruction
once it is developed costs no more than the blank CDR or DVD it is developed on. This
is why it is important that the content be stable and intended for multiple users (think
hundreds and thousands).
Does this project require CBI/CBT’s unique strengths, characteristics, and capabilities?
CBI/CBT is good at incorporating multiple modalities, including video, sound, text,
graphics, non-linearity, interactivity, remediation, and individualization. If the instruction
does not make use of these strengths, it is hard to justify the time and expense involved
with CBI/CBT. Developing CBI/CBT because it sounds “cool” or is “cutting-edge” is not
sufficient.
33
Do my learners possess the necessary computing skills?
CBI/CBT requires at a minimum the ability to turn on a computer and use a keyboard,
mouse, and CD-ROM. It may also require the ability to navigate through files and
folders, and name and save files.
Do my learners have access to computers?
How likely is it that the intended learners will have ready access to computers? If access
to computers is limited, obviously, the instruction may be less effective. And while many
learners may have access to a computer at work, this is not necessarily the case for them
at home. If the instruction is intended to be accessed frequently and over long periods of
time, it may be necessary for the learner to have access to a computer at home.
How do my learners feel about computers?
Research has shown that computer anxiety can interfere with learning. Learners may not
be comfortable using the computer. Depending on demographics such as age, gender, and
prior computing experience, computer anxiety may be more prevalent.
The answer to any one of these questions may preclude the development of CBI/CBT.
Even when CBI/CBT is the best solution instructionally, if the learners are not able to
make full use of it or the budget does not support it, you are better off developing
instruction to be delivered in a different medium.
Learning a la Mode
34
Once you have determined that CBI/CBT is appropriate for the given content, learners,
and project conditions, it is time to make some decisions about the mode of CBI/CBT
that you intend to develop. There are four main modes of CBI/CBT: tutorials, exploratory
learning environments, simulations, and games. The latter two modes can be combined to
form a fifth, simulation games. A discussion of each mode and its relative strengths and
weaknesses follows.
Tutorials
Tutorials are by far the most common type of CBI/CBT. Instructionally, they can be very
effective and are among the more easily developed types of CBI/CBT. Tutorials can take
many forms, but most commonly they consist of presenting the learner with objectives
for a section or module, the information relevant to those objectives (i.e., the content),
opportunities for practice with feedback, and, finally, assessment. Tutorials tend to be
linear in nature, as a reflection of the natural sequencing of content, objectives, and
prerequisite skills. Tutorials lend themselves to the instructional design process because
the designer can focus on one objective at a time, presenting the information needed,
providing for practice and assessment, and then moving on to the next objective in a
similar fashion until all objectives have been presented.
This is also their weakness, however. Tutorials are potentially among the least motivating
of instructional modes if not managed carefully. Tutorials require careful attention to
motivational instructional strategies throughout the instruction to avoid becoming “pageturners” in the hands of novice developers. Although there are many page-turner tutorials
available commercially, tutorials developed in this fashion could just as easily (and with
35
considerably less expense!) have been developed as print-based instruction. The whole
point of developing CBI/CBT tutorials is to provide for interaction on the part of the
learner.
Exploratory learning environments (ELEs)
ELEs represent a more generative, constructivist approach to knowledge building. This is
not to say that they do not accommodate behavioral objectives but rather that the manner
in which those objectives are met differs from tutorials. In ELEs, learners are relatively
free to explore the environment to learn at their own pace and in their own preferred
order.
As the name suggests, the emphasis is placed on exploring the learning environment and
discovering the concepts, rules, and information relevant to the learning objectives. ELEs
are more difficult to develop than tutorials because the learner can move through the
program at will, making it hard to sequence the instruction to account for pre-requisite
skills. Because of this they are better at addressing higher-order intellectual skills. They
are also harder to trouble-shoot than tutorials, since there are multiple paths through the
instruction. They are among the most effective types of CBI/CBT when well designed
and implemented, however, especially for teaching higher-order intellectual skills.
Simulations
Simulations have been defined in many different ways. Depending upon the researcher, a
simulation may be “a process or mechanism relating input changes to outcomes in a
simplified reality that may not have a definite end point” (Randel et al., 1992, p. 262), as
36
“the ongoing representation of certain features of a real situation to achieve some training
objective” (Morris & Thomas, 1976, p. 66), and as “an imitation or simplification of
some aspect of reality” (Heyman, 1982, p. 3). Rieber (1996) defines simulations as “any
attempt to mimic a real or imaginary environment or system” (p. 49). Other researchers
see a simulation as “a situation that enables relationships in a model to be explored and
observed” (Duchastel, 1991, p. 265), or as a scenario (representation of real world), a
model (rules and relationships that control the simulation), or an instructional overlay
(Reigeluth & Schwartz, 1989).
Simulations can fall anywhere on a continuum of complexity from modeling a bicycle
pump or simple electrical circuit to modeling entire cities and worlds, as is the case with
the popular “Sims” games (e.g., Sim City, Sim World, etc.). Simulations may be seen as a
kind of ELE, in that they are most often meant to be explored at will by the learner. The
instruction is embedded in the processes modeled in the simulation, and the learning
takes place as the result of learner interaction with, and the resulting feedback from, the
simulation. It is important to note that while the experience appears to be completely
open and driven entirely by the learner, simulations, as all ELEs, are the result of
carefully planned, rigorous instructional design processes.
According to Gredler (1994), simulation share five characteristics:
1. They are implicit or explicitly problem-based units of learning that are set
in motion by a particular task, issue, policy, crisis, or problem
2. The subject matter is more than just questions or textbook problems that
have easily determined, definite answers
37
3. Participants behave according to their assigned roles in the context of the
simulation
4. Outcomes are determined by skills and actions on the part of the
participants, and are not determined primarily by chance or luck
5. “Participants experience reality of function to the extent that they fulfill
their roles conscientiously and in a professional manner, executing all the
rights, privileges and responsibilities associated with the role” (p. 16)
Simulations are among the more effective modes of instruction for complex systems and
processes. Simulations can represent mechanical systems such as complicated heating
and air conditioning systems or social systems such as business negotiations and
customer service training. Such content is often difficult to teach in traditional formats
such as tutorials since the material is complex and requires an understanding of the
system, which is often more than the sum of its parts.
Games
Games have been defined as goal-directed contests between individuals under some set of
conditions and constraints (Gredler, 1994, p. 13), as “a contest in which people agree to
abide by a set of rules” (Heyman, 1982, p. 3), as “competitive interactions bound by rules
to achieve specified goals that depend on skill and often involve chance and an imaginary
setting” (Randel, Morris, Wetzel, & Whitehill, 1992, p. 262), and as “contests in which
both players and opponents operate under rules to gain a specified objective”
(Cruickshank & Telfer, 1980, p. 75).
Most definitions of games agree that they are goal-directed activities in which one or
more people compete to attain a goal according to a set of rules and constraints.
38
Games are advantageous instructional tools because of their motivational
properties. Games tap into the human need to play, which play theorists would argue is
among the most effective instructional techniques regardless of domain. This conclusion
is based largely on the observation that we learn more in the first years of life than we do
in any other corresponding time in our lives (Lepper & Chabay, 1985). Games, such as
those played by young animals as they are growing up, are the means by which the most
important life skills are learned, naturally. “Games are thus the most ancient and timehonored vehicle for education” (Crawford, 1982, Chapter 2, p. 1). Only mammals and
birds engage in play, indicating that the role of play in fostering higher learning is critical
(Crawford). Rieber (1996) says research in “anthropology, psychology, and education
indicates that play is an important mediator for learning and socialization throughout life”
(p. 44) and that “Having children play games to learn is simply asking them to do what
comes naturally. . . . However, playing a game successfully can require extensive critical
thinking and problem-solving skills” (p. 52).
“Little attention has been given to the psychological and sociological value of play
despite its many advantages to guiding the design of interactive multimedia learning
environments for children and adults” (Rieber, p. 43).
According to Dempsey et al. (1997), “computer games have been employed effectively in
all areas of traditional schooling—from preschool . . . through higher education . . . and
continuing education of the elderly” (p. 1). Among the many potential strengths of
instructional games are the teaching of complex problem-solving skills (Hayes, 1989).
Games can be used as instruction (i.e., all learning takes place within the game), to
supplement instruction (e.g., allow learners to practice recall of knowledge), or as
39
assessment instruments. Games are effective in teaching social science, mathematics,
language arts, physics, biology, and logic (e.g., Randel, 1992; Bright et al., 1985), and
may be more effective in terms of retention than other forms of instruction (VanSickle,
1986). Games such as Jeopardy can be used for testing verbal information and to build
fluency, for instance, while games like Concentration may be used to help foster concept
learning (e.g., matching pictures to definitions) or foreign languages (e.g., English to
Spanish translation).
Simulation Games
Simulation games have been defined variously as a combination of simulations and
games with competition (Heyman, 1982) and as a subset of games (McGrenere, 1996).
One of the more complete definitions is proposed by Szczurek (1982, p. 27): “[an
instructional simulation game is] an instructional method based on a simplified model or
representation of a physical or social reality in which students compete for certain
outcomes according to an established set of rules or constraints. The competition can be
(1) among themselves as individual or groups, or (2) against some specified standard,
working as individuals or cooperating as a group.”
Simulation games may be defined as interactive experiences that contain some
representation of a world, real or imagined, that behaves according to a coherent (if not
realistic) set of rules, in which the participant(s) often have a clear goal, the pursuit and
attainment of which may result in an entertaining, rewarding experience.
As might be expected, simulation games combine the advantages of games and
simulations. They are effective in all domains and for all levels of knowledge, but they
40
are perhaps most effective in teaching higher-order complex intellectual skills (e.g.,
problem solving). Learners are free to explore the environment and interact with the
simulation game, which provides feedback according to the systems or rules it represents.
Simulation games differ from simulations in that they are goal directed, have a set of
rules under which the learner is allowed to operate, and involve some form of
competition (e.g., time limit, score, other players, etc.).
It should be noted that a designer is not limited to using only one mode. Simulations,
games, and simulation games may make use of tutorial-based components in order to
address all learning objectives. Conversely, games make excellent additions to tutorialbased instruction, both because of the practice opportunities they afford and because of
their inherent motivational properties.
Learner Preferences and Characteristics
Instructional designers quickly learn the importance of learner analysis in the
instructional design process. It doesn’t matter how well designed an instructional unit is if
the intended learners can’t make use of it because of reading levels, language, or visual
impairment. There are some aspects of learner analysis and preference that are
particularly relevant to the design of CBI/CBT and warrant particular attention.
Age and gender
The age of your intended audience may have an impact on the use or design of CBI/CBT.
Older adults tend to have less computing experience than younger learners. Even if you
can count on their basic abilities to operate a computer, older adults may not be as adept
41
at interaction as younger learners, whether because of visual impairment, reduced fine
motor skills, or simply lack of experience. CBI/CBT that requires multiple fine-grained
interactions throughout the instruction may present difficulties.
Older adults are less familiar with computer games and simulation games, and may not
be as receptive to these modes even though they might be the most effective overall.
Younger learners, what Marc Prensky refers to as “digital natives” (2000), may display a
preference for games and simulation games, and it may be more appropriate to use these
modalities for this population even if the same objectives could be met using other
modalities.
Gender also makes a difference in terms of strategies and modalities in CBI/CBT.
Research has shown that girls and boys begin to differentiate in terms of computer skills
and experience somewhere between the fourth and sixth grades, which is approximately
the same time that boys begin playing computer games. While a host of computer games
designed to appeal to girls are being developed, girls still tend to play fewer computer
games than boys.
One of the reasons hypothesized for this difference is that most computer games make
use of elements that do not appeal as much to girls. Violence as a primary response
strategy, competition, and repetitive arcade-style interactions tend to appeal more to boys
than girls, while girls are drawn more to social interaction, communication, and
exploration. When designing for both sexes, designers should look for ways to integrate a
variety of strategies (providing several means of solving a particular problem, for
instance).
42
Cognitive styles
Cognitive styles are constructs that describe the ways in which people process and
manage information during the learning process. These constructs are stable, meaning
that they are observable across multiple populations and do not change over time.
Knowing these constructs is useful for instructional design because they can help
determine which strategies and approaches are likely to be most effective with different
learners.
Smith & Ragan (1999) identify four cognitive styles in particular that they feel are useful
for instructional designers, each of which is discussed below. While it is not feasible that
designers of CBI/CBT administer the instruments needed to assess these cognitive styles
in their intended audience, consideration of these different styles may allow for the
inclusion of strategies which will appeal to a broad range of learners.
Field Independent/Dependent.
Field dependent learners have difficulty isolating specific information or details
embedded within larger, more complex fields of information. For example, field
dependent learners would find the popular “Where’s Waldo?” books difficult, while field
independent learners would be good at finding Waldo.
Leveling/Sharpening.
Sharpeners are similar to field independent learners; they are more easily able to pull
detail from complex fields of information, whereas levelers are similar to field dependent
learners.
43
Visual/Haptic Perceptual Style.
Visual learners are similar to sharpeners and field independent learners. They tend to do
best with visual information of all kinds. Haptic learners learn best by doing and
interacting with information rather than relying on visual kinds of strategies.
Impulsive/Reflective Cognitive Tempo.
As the name implies, impulsive learners tend to respond with less reflection than do
reflective learners. This becomes particularly relevant when selecting from several
possible choices. For example, reflective learners might be expected to perform better on
multiple choice practice items or assessment questions with multiple answers than
impulsive learners, since reflective learners will spend more time considering all the
options.
Careful examination of each of these cognitive styles reveals that it is possible to design
instruction appropriate for most learners without knowing which cognitive styles are
most prevalent in your audience or sacrificing instructional objectives. For example,
while field independent learners, sharpeners, and visual learners are good at pulling
details out of complex visual fields, it does not mean that they cannot learn equally well
from simplified visual fields of information. Where instructional objectives require the
ability to pull detail from complex fields, the details of that field can be presented a few
at a time to accommodate field dependent learners, levelers, and haptic learners.
While haptic learners learn best by doing and interacting, other types of learners might
learn as well that way also. In fact, instruction that does not require interaction and
practice is a poor candidate for CBI/CBT. And keeping the number of choices and
44
responses within reason is not likely to result in less effective instruction for reflective
learners, so instruction can be designed for both styles simultaneously.
Learning styles
Learning styles are somewhat more controversial than cognitive styles. Learning styles
tend to be postulated by researchers in a less rigorous manner than are cognitive styles,
often arising from no more than a personal observations on the part of the researcher.
Research on learning styles is thus, not surprisingly, less consistent than that on cognitive
styles. Nonetheless, there is one learning style that bears particular relevance to the
design of CBI/CBT.
Passive/Active.
The distinction between passive and active learners was first postulated by Lee &
Lehman (1993). Passive learners tend to be less willing or able to explore their
environments than active learners. This is particularly relevant when the learner “gets
stuck” and is unable to determine what to do next. Active learners will begin exploring
the environment and trying many options, while passive learners will look for someone to
tell them what to do next (e.g., the teacher). Some forms of CBI/CBT may be less
suitable for passive learners than for active learners. Likewise, active learners will do
better in simulations and simulation games than passive learners. It is still possible to
design CBI/CBT for both types of learners by, for instance, building in time-based
prompts which come up after a certain period of inactivity and ask if the learner needs
help.
Accessibility
45
With the advent of the Americans with Disabilities Act (ADA) and subsequent rulings
clarifying Section 508 of the Rehabilitation Act of 1973, colleges must make web sites
accessible to those with disabilities. It is a short leap from there to web-based instruction
accessibility at universities and colleges. Even if there were not a legal requirement,
however, taking learners with disabilities into account when planning CBI/CBT is the
right thing to do. Instructional designers have a responsibility to ensure that learning
opportunities are available to as wide an audience as possible. While a full treatment of
relevant design issues is not possible here, a brief description of some of the more
common issues is relevant.
Auditory considerations.
Learners with auditory impairments will obviously have difficulty making use of any
sound during the instruction. Providing textual equivalents of auditory content is
relatively inexpensive to do if planned in advance. Likewise, sound effects that are used
for feedback (right and wrong feedback, clicks for button presses, etc.) should also not be
used as the sole means of conveying such information. Visual highlights and animation
that accompany such sound effects make it possible for those with hearing impairments
to receive the same information and are not likely to interfere with those who are able to
hear.
Visual considerations.
Learners who are visually impaired will likewise have trouble processing visual
information. Providing an auditory equivalent to text elements is a good solution, but
may not always be practical. Visually impaired learners are able to make use of screen
46
readers or third party Xtras available for Authorware that will read aloud all embedded
text in the program. Likewise, visually impaired learners may have difficulty navigating
from screen to screen using buttons. Providing keyboard equivalents for each command
or button on screen in combination with an easily accessed auditory message describing
each command can help address this.
Physical considerations.
Those who have physical disabilities may have difficulty interacting with a CBI/CBT
program. There are many ways to overcome the difficulties these disabilities present.
Assistive technology can process spoken commands into keyboard strokes, so providing
keyboard equivalents as described above can help here as well. More sophisticated
interactions in the instruction may present additional challenges. While navigating and
selecting from a few options on screen can be accommodated, complicated simulations
that rely on making multiple moves in the program can be difficult to interact with.
Likewise, traditional “drag and drop” interactions may be impossible for some to
accomplish. While there are no easy solutions to these issues, consideration of them up
front can help minimize them. If the instructional objective allows you a choice between
such interactions and simpler ones, you may elect to choose the options that make your
instruction accessible to the widest audience.
Operating System Considerations
Up until now, most of the issues discussed have focused on more theoretical concerns.
There are many more practical hardware and software considerations that must be
addressed in the pre-planning stage. The first of these is what operating system (OS) for
47
which you will be developing. While there are many OSs available today, Authorware is
only available for Windows and Macintosh.
The most current version of Authorware is version 6, which runs on the Windows
platform only. The latest version of Authorware for the Macintosh is version 4. Version 4
lacks many of the newer features in 6, including support for Quicktime 5, Flash movies,
animated GIFs, and knowledge objects. This is unfortunate, as version 4 had some very
nice features that were dropped from 5.x, not the least of which is the ability to include
fonts in the final product (you must provide separate font files to your end user along
with instructions on how to install them with 6). If your project will make use of any of
these features and you intend to deploy the product on the Macintosh, you should develop
in 6 on the Windows platform and then convert it for playback on the Macintosh. If your
project does not require these new features and you are developing it for Macintosh users,
you may be better off developing in 4.0, as there will be fewer playback issues during the
testing and revision phase.
If, as many developers do, you intend to deliver the instruction on both platforms, there
are some additional considerations to make. One of the biggest issues relates to palettes
and fonts, which will be discussed in more detail later. Macintosh and Windows do not
use the same color palette when displaying graphics. The system palette on the Macintosh
uses different colors than the system palette on the Windows platform. Authorware 7 uses
a custom palette by default which closely mimics the Macintosh system palette, so you
will generally get very good results when viewing the program on the Macintosh OS.
Nonetheless, for more control and efficiency, many developers create their own custom
palette using a program like DeBabelizer. Doing so ensures perfect color matching on
48
any platform. System colors and custom palettes will be discussed in further in this
chapter and in Chapter 10.
Similarly, the same font appears differently on Windows and Macintosh computers. Arial
12pt is available on both platforms, but will look larger on the Windows side than it does
on the Macintosh side, where it will appear to be 10pt. A file called the Font Map helps
Authorware make adjustments for this, but when a font is used that does not exist on the
other platform, you will have to find an appropriate substitution yourself. You should
always specify your fonts up front, and it is safest to stick with fonts that exist on both
platforms. You can determine which ones are available on your computer by looking in
the fonts folder on the Windows OS (Control PanelsFonts) or Mac OS (System
FolderFonts). Alternatively, you may consider purchasing Font CD-ROMS that
contain Mac and Windows versions of fonts.
Another issue you will face relates to video. Not all video formats are supported on both
platforms. AVI format is a native Windows format that will not play back in Authorware
on the Macintosh side without AVI to Quicktime conversion software, and not very well
even in that case. Quicktime is available on both platforms and is probably the most
widely used format. It must be installed on the Windows platform, however.
Delivery Considerations
Interactive CBI/CBT can be delivered in a variety of ways, including playback from a
local hard drive (through a commercial installation program delivered with the program),
from a CD or DVD, or from a server over an intranet or the Internet. As with
instructional modalities, each delivery platform has its own strengths and weaknesses.
49
And while many programs, Authorware included, can be made to run on any of these
platforms after the program is created, it is critical to decide up front which platform(s)
on which you will deliver the final product. Failure to consider this prior to developing
the product can result in serious problems later on.
Some of the differences between these platforms relate to aspects of setting up the
Authorware file itself (e.g., hard drive paths), and will be discussed later in that context.
Others are specific to the platforms themselves, and those bear some discussion now.
Additionally, there are other delivery considerations that are independent of the platform,
such as graphics, sounds, fonts, etc., which must also be part of the pre-planning process.
Internet, Intranet, CD-ROM, Hard Drive
The Internet, in the simplest terms, is simply a connection between a server and a local
computer. The server contains information such as the web pages and web-based
instructional modules on its hard drive. When an end user calls for that information
through a browser, the server sends that information through the pipeline to the end
user’s computer. The means by which the end user’s computer is connected to the
Internet, and hence the server, determines how much information can be sent and
received over a given period of time.
You may have heard the terms “pipeline” and “bandwidth” discussed in terms of the
Internet. These terms are synonymous, with pipeline being the metaphor we use to
understand the more technical term, bandwidth. The pipeline metaphor is that the wires
connecting your computer to the Internet are like pipes, and the information you get over
those wires is like water. The “thicker” the pipe, the more “water” it can hold. The
50
amount of information and the speed at which you can access that information over the
Internet is a factor of the pipeline/bandwidth you have coming into your computer.
In fact, these terms apply equally well to any computing technology platform in which
information is being moved from place to place, whether from a CD-ROM or hard drive
to your screen, or a server to your computer (as with inter- and intranets). Each delivery
platform has a different pipeline, and understanding its capabilities plays a critical role in
designing and developing your CBI/CBT.
The most common connections to the Internet include 56k modems, ISDN, cable
modems, ADSL (DSL), satellite, and T1. Table 1 presents these connections and their
relative speeds for upload and download.
Heads Up: Satellite also has a delay, making response time critical interactions
problematic.
Type of
Connection
Speed per
Second
(download)
Speed per
Second (upload)
Time to Upload
1MB of
information
Time to
Download 1MB
of information
56K
Modem
5.6KB/sec
5.6KB/sec
3 minutes
3 minutes
ISDN
128KB/Sec
128KB/Sec
8 seconds
8 seconds
Cable
Modem
~380KB/Sec
~200KB/Sec
2.6 seconds
5 seconds
ADSL
Modem
~1.500MB/Sec
~90 - 256KB/Sec
3.3 seconds
11 - .6 seconds
Satellite
~400KB/Sec
33.6KB/Sec
2.5 seconds
30 seconds
T1
1,500KB/Sec
1,500KB/Sec
.6 seconds
.6 seconds
51
These bandwidth differences require different solutions when building interactive
instruction for delivery via the Internet. Using a lot of animation, video, and sound is not
feasible if your learners only have access to the Internet via 56K modems, as is currently
the case for over 90% of those with Internet connections (IDC, as cited in ZDnet,
available at http://www.zdnet.com/products/stories/reviews/0,4161,2475136,00.html on
7/22), since the bandwidth is too small to accommodate such media.
Intranets, private networks that are connected through Ethernet, have a much higher
bandwidth, ranging, in theory, from 10 to 100 MB/Sec. Such connections can make
extensive use of media without any penalty beyond file size.
CD/DVD-ROMs also have pipeline limitations, manifested in the spin rate. The faster a
CD/DVD spins, the more information can be accessed at once. As a general rule,
CD/DVDs can generate 75KB/Sec for every “x” of their speed. For example, early CDROM drives were double-speed, or 2x, meaning they could generate 150KB/Sec of data
transfer. Current CD-ROM drives spin as fast as 32x or more, indicating a theoretical
maximum of 2.4MB/Sec data transfer. It should be noted, however, that current speeds
do not reflect sustained transfer rates. Instead, they indicate the maximum the drive can
achieve for short bursts, usually when accessing data from the inner part of the disc,
which is smaller than the outside edge of the disc. Average sustained transfer rates are
probably closer to 8 or 10x, indicating such drives can provide access to 600 –
750KB/Sec.
Rates become critical when determining how much audio, video, and animation you can
include in your project. Typical CDs are not going to be able to deliver half-screen video
52
(320x240) at the same time they are doing anything else; trying to do so would result in
skips and jumps. It is not only the speed one must be concerned with, but also the size.
CDs hold a maximum of 800MB of data. While this far exceeds the actual Authorware
file size you are likely to develop, by incorporating sound and video you can easily hit
this maximum. As an example, while video file sizes can vary dramatically with the
means of compression used, one second of full screen uncompressed video is 30
gigabytes in size. Even at half size and compressed, seconds are measured in megabytes,
not kilobytes. CDs cannot easily hold much more than 12-15 minutes of good quality
video.
Media Considerations
Tip: Media can be stored externally to the piece, allowing the graphics to be updated in a
final product simply by providing the client with new versions of the media using the
same file names. The piece will simply load the new media in place of the old ones when
called for. Chapter 4 will discuss this in detail. Alternately, you can also specify a URL
as a location for graphics, allowing you to update the content without any client
involvement.
There are several decisions you need to make up front about the media you will use in
your CBI/CBT. Some of the decisions you make will drive the design of the CBI/CBT
itself, while others will determine the properties of the media. In both cases, making and
documenting these decisions will simplify the design and project management processes,
and help avoid costly revisions later.
Graphics.
53
Authorware understands a variety of graphics formats, including BMP (bitmap), DIB,
RLE, GIF, JPEG, LRG (xRes format), Photoshop, PICT, PNG (Portable Network
Graphic), TGA (Targa), TIF (TIFF), WMF (Windows MetaFile), and EMF (Extended
MetaFile). Of these, you are most likely to be working with BMP, JPEG, GIF, PICT, and
Photoshop. Bitmaps tend to be larger files and are not the best choice for CBI/CBT that is
ultimately intended for the Web. JPEGs are among the smallest files and display well on
the Web as well as in CBI/CBT, but they are best-suited for photographic images. GIFs
tend to be larger files than JPEGS, but they also display well on the Web and are bestsuited for clip art and other computer-generated art. PICT images are most commonly
created on the Macintosh platform. They are among the smaller size image formats and
will display on the Windows platform if Quicktime is installed. Photoshop images can
result in large file sizes and are not recommended except when making use of graphics
with an alpha channel. The alpha channel allows more specific control over graphic
transparency than the more common transparent mode in Authorware. These issues will
be discussed in more detail in chapters 4 and 13.
Tip: Screenshots taken on the Macintosh using the Shift-⌘--3 or Shift-⌘--4 are
automatically saved as PICT images. Using the Print Screen button on a Windows
keyboard captures a copy of the screen to the clipboard. You can then paste the image
into any image editing program and save it in different image formats.
Sound.
Aside from video, sound has the greatest potential to increase file size, and therefore, like
video, must be considered early on in the project. Will the project include voice-overs,
54
sound effects, music? When making these decisions, it is also advisable to consider your
final delivery medium. If CD is the delivery platform, you will need to keep the storage
capacity in mind. If the piece is intended for the Web, you need to keep the bandwidth
limitations in mind. The more sound you have, the less space/bandwidth you will have
for other elements.
As with graphics, there are several formats for sound files. Authorware can import WAV,
AIFF, PCM, SWA, and VOX files. WAV is the most common sound format on the
Windows platform, while AIFF (Audio Industry File Format) is often the default sound
for sound editing programs when creating high-quality sound files. SWA (Shockwave
Audio) PCM, and VOX files all create small files through compression. They are
recommended when developing for the Web. Unless there is a compelling reason to the
contrary, it is advisable to standardize on a sound format up front.
There are also several options for controlling sound file size within commercial sound
editing packages. Sample rate, sample size, stereo vs. mono, and compression all interact
to determine the final file size. A more complete discussion of these issues can be found
in chapter 13. For now, it will suffice to say that higher sample rates (11k to 44.1k) and
sample sizes (8bit vs. 16bit) result in larger, albeit higher-quality, files. Likewise, stereo
files are larger than mono files. It is important to test out examples of the sounds you plan
to include to determine the best settings for your file, and document them up front.
Tip: Authorware includes a compression utility for voice-only sound files called
Voxware. This utility allows you to greatly compress voice-only sound files without
significant loss in quality. See Chapter 13 for more information.
55
Video.
Few media have the ability to impact your CBI/CBT as drastically as video. It is by far
the largest contributor to final file size, and imposes the most severe demands for
bandwidth (web) or access (CD). Not only does video create file size and bandwidth
issues, it can add as much to the cost and time of your project as the rest of the project
itself. Clients and novice designers alike have a tendency to be unduly enamored of
video, especially as the cost and ease of editing digital video has come down. It is
important to consider the pedagogical versus “eye-candy” value of video when planning
your project.
The main value of video is in displaying motion. This is particularly useful for what
Gagne terms motor skills. Examples of motor skills include learning to serve a tennis
ball, operating a piece of machinery, and assembling devices like barbeque grills. Video
can present a series of motions and steps in sequence more efficiently than a textual or
audio description can. On the other hand, many skills which appear to be motor skills can
be broken down into discrete steps that can be equally represented with a series of images
accompanied by text descriptions. This latter solution can sometimes be more effective
than video because attention can be drawn to specific details through circles and
highlights, and the learner can study these images and details over a longer period of
time. Video also does not present detailed information as well as images do.
The format of the video you plan to use should also be decided up front. If your project is
intended to be cross-platform, Quicktime is the preferred file format. If the platform is
Windows only, Quicktime or AVI can be used, but AVI can be played back by any
Windows 95 or higher OS automatically, while Quicktime requires that end users have
56
Quicktime installed on their computers (Quicktime is available as a free download from
Apple).
Finally, Authorware can play MPEG video as well. MPEG format video produces highquality video. There are four types of MPEG, one of which, MPEG-2, is used for DVD
video playback. These types will be discussed in more detail in Chapter 13. For now, it is
important to know that MPEG files are larger files and usually require specific hardware
to be played back correctly. If you are authoring for interactive DVD, you could count on
this hardware being present, but it is not yet common enough to assume all computer
owners would have it.
Fonts
As mentioned earlier, fonts do not appear the same from platform to platform. In
addition, not all fonts are available on all platforms. It is essential to determine which
fonts you intend to use prior to starting the project. The best way to do this is to
experiment with fonts on all the platforms for which you intend to develop. Create
examples of different fonts at different sizes and look at them on each platform. Pay
attention to sizes and readability. An easy way to do this is to write out sentences in the
font which consist of the specifics of that font. For example, to test out Times New
Roman, I would write the following sentence:
This is Times New Roman 12pt regular
This is Times New Roman 12pt italic
This is Times New Roman 12pt bold
57
This is Times New Roman 12pt bold italic
This is Times New Roman 14pt regular…..
… and view them on each delivery platform. Once you have found a font or fonts that
you feel work well on all platforms, you will be able to use this information to set up
your font map (for more on the font map, see chapter 10). The font map is a file used by
Authorware to specify what font and size to use on other platforms. As mentioned earlier,
the same font on the Macintosh platform will look smaller than it does on the Windows
platform. The fontmap tells Authorware to display Arial 12 pt as 10pt when on the
Macintosh platform. Also, when a font does not exist on the other platform, the font map
can be used to substitute another font. Special care must be taken in this case to test out
equivalent fonts thoroughly prior to settling on a substitute font. For instance the font
map could be edited to tell Authorware to display text calling for Palatino 11 to use
TimesNewRoman 12 (which are roughly equivalent) and vice versa. Authorware would
then substitute the fonts as needed automatically. Failure to standardize on a font set and
edit the font map accordingly will cause Authorware to guess at a font if it does not exist
on the learner’s system. Most often, it selects Courier by default, with drastic results.
Tip: If you are able to develop using Authorware 4 on the Macintosh platform, you can
tell Authorware to include the fonts with the piece. This means the piece will display
correctly no matter what fonts the learner has. Unfortunately, Macromedia abandoned
this ability when it created 5.2 and 6.0, which are Windows-only products.
58
Once you have identified a basic design for your interface (see “Designing the Interface,”
this chapter), you should put sample text in the places you have created for text and look
at how much text fits in that area, how readable it is, and whether it matches the interface.
As it will become clear later, specifying your font styles now will allow you to set up
styles within Authorware. Failure to do this, which I have seen in almost every
Authorware piece I’ve watched students develop, will result in a dramatic increase in font
styles which cannot be deleted, and the inability to make wholesale changes to fonts
without actually opening and changing every single instance of text in the piece.
Color Palettes & System Colors
Palettes consist of 256 colors. Of these colors, 20 are reserved on the Windows side for
system colors. To prevent you from using Windows system colors, Authorware provides
a custom palette that closely mimics the Macintosh system palette. By default,
Authorware includes 20 colors that are specific to the Windows platform only in its
palette. This is done so that Authorware’s (the program itself, not your
program)windows, menus, scroll bars, and other interface elements appear correctly
when you are editing. Unfortunately, this means that you can apply these 20 colors to
your program. If you do so, and then play back your program on the Macintosh platform,
these colors may not display correctly. In order for the colors to display properly on the
Macintosh platform, you will need to tell Authorware 7 NOT to preserve the Windows
system colors. This procedure will be discussed in Chapter 4.
Designing the Interface
59
The interface has the most potential impact on the effectiveness of the final product, yet
in my experience it is the most often ignored and poorly designed element in CBI/CBT.
The best instructional design can be completely negated by a poorly designed interface; if
learners can’t figure out how to navigate or get help, they will never see the content.
Additionally, the content itself may be shaped by the interface. Issues such as how much
space to devote to text messages, help, and feedback impact your selection of font sizes.
Knowing how much space you have for text on each screen impacts how much content is
designed for each area. It may be just as easy to split a given piece of content into three
pieces if you do that initially, but not if you have to go back and make those changes
later. Spending time up front designing and developing your interface will speed the
development process, reduce revision time, and result in a “tighter” product.
Metaphor
All computer interfaces are metaphors. Therefore, an understanding of metaphor is
critical to understanding interface design. Computer interfaces do not, as many people
believe, simply make use of metaphors. Whether we type a command such as “print
myletter.doc to LPT1” or click on a printer icon, we are in neither case printing. We are
substituting one action (typing or clicking an icon) for another (the actual process of
printing). In order to understand the role of metaphor in interface design a brief
discussion of metaphor is necessary.
In its simplest sense, a metaphor is the use of one object or concept (the vehicle) in place
of another (the tenor) in order to say more than could be said in a “literal” manner. Thus,
when Steve Jobs and Steve Wozniak “borrowed” their ideas for the Macintosh interface
60
from Xerox, what they borrowed was a set of metaphors, NOT an interface. This
metaphor was, of course, the desktop. Desktops are places we keep things when we are
working. By substituting a desktop for the command-line interface then common to
computers, Apple was able to convey a great deal of information in a small space. Want
to get rid of a document? Throw it in the trash. Want to store something for later
retrieval? Put it in a file folder and label it. The power of a well-implemented metaphor is
obvious when one looks at the major operating systems today, most of which make use of
the desktop metaphor.
Unfortunately, few of us think about the metaphor when designing an interface for
CBI/CBT. We build generic “page-turner” tutorials, with forward, backward, and quit
buttons. While these may work in the sense that the learner understands them (by virtue
of having seen so many of them), they are not very interesting, and in some cases can
make it harder to convey information.
Let’s look at an example. Suppose you want to teach someone how to bake bread. You
could build a page-turner with each of the steps illustrated with graphics where
appropriate and then ask the learner to place the steps in the appropriate order. Interaction
in this piece would consist of lots of button clicking and selecting choices. Alternatively,
you could build a kitchen as the interface, use graphics of the items, and ask the learner to
place the items into the mixing bowl, use the mixer, etc. Instructionally, this is closer to
demonstrating the actual process than can be accomplished using textual descriptions,
which should promote transfer. It is certainly more interesting and interactive in any case.
61
The use of metaphor does not stop there either. Rather than forward and backward
buttons (if they are even necessary), you could use wooden spoons pointing one direction
or the other; the recipe book could be used for getting help, and the kitchen light switch
could quit the game. Interactivity now consists of working in an environment, not turning
pages, and is visually more appealing.
Screen design principles
Screen design has been the subject of many books, and cannot be treated fully here. For
more information the reader is referred to Roger C. Parker's One minute designer, and
Robin Williams’ The non-designer’s design book and The non-designer’s web book: An
easy guide to creating, designing, and posting your own Web site. What follows is a brief
discussion of some the design considerations specific to CBI/CBT. Keep in mind that
screen design should first take place on paper, so that you can try several things out and
make adjustments quickly and easily. If you start with the actual screen design on
computer, you are likely to become committed to your first designs. Once you have
developed paper versions for your interface, select the best two or three and make mockups on the computer. You can then fine tune them, make your final selection, and create a
template to use during development.
Light and Screen Design
When you look at any computer program, you will notice that items such as buttons and
menus appear to “float” above the screen. In reality, of course, the computer screen is a
two-dimensional medium. To achieve 3D effects in a 2D medium, we have to create
shadows and highlights. Shadows and highlights in the real world are created by a light
62
source; when you are outside on a sunny day and the sun is at an angle to you, the part of
you facing the sun will by lighter, or highlighted, and the part facing away will be darker,
or in shadow. In addition, you will cast a shadow in the direction opposite to the light
source.
In the same way, to create the illusion of 3D on the screen, items that are above the
background need to have highlights and shadows. In order to know how to create these,
we need to know where the “light” in our interface is coming from. Once we know this,
we can make sure that all elements have highlights and shadows in the same fashion, thus
creating a unified, three-dimensional look.
Fortunately, this decision has already been made for us: “light” ALWAYS comes from
the upper left corner of the screen. Thus, elements always have highlights in their top and
left sides and shadows on the bottom and right sides. Buttons, text, and boxes that are
supposed to be above the background will cast shadows to the lower right corner of the
screen. It is certainly possible to change this light source to create a unique interface for
your project, but virtually all computer programs adhere to this standard, and it can be
unsettling when this is changed.
Likewise, elements which are below others, such as is common with an inset box to
display text, have the highlights and shadows reversed. To understand why this is so,
imagine that you are standing in an empty swimming pool, facing the northwest corner of
the pool. This is also where the sun is coming from. The corner you face will be in
shadow because the edge of the pool is casting a shadow. If you were to turn and face the
southeast corner of the screen, it would be in the light, because the shadow does not reach
63
the corner and the sun is shining on the walls. Similarly, any item in your interface that is
supposed to be recessed should cast a shadow from the upper left corner into the recessed
area, and be highlighted in the lower right corner.
Tip: When building your interface, you can achieve these effects by using light and dark
colors for text and shapes on your screen. For instance, to make a raised square on my
screen, I can draw square that is the same color but a lighter shade than my background
(both the fill and line must be the same color—see chapter 4). I then copy that square
(EditCopy) and paste it (EditPaste) to get an exact duplicate. I then change the color
of that square to white, position it one or two pixels up and to the left of my first square,
and then stretch the bottom left corner so that it lines up with the bottom right corner of
my first square. Finally, I arrange it on screen so that it is behind (ModifySend to
Back) my first square. Now only a white edge shows up on the top and left sides of my
square, making it appear that the “light” is hitting the side of a raised square. You can use
this technique for creating raised text, and you can reverse it to make things look
recessed.
Backgrounds and Borders
The first place to start when designing your interface is the background. While all screen
elements are somewhat interdependent, with changes in one aspect requiring changes in
another, you need to have an idea for your background before you begin designing.
Often, the background is determined by the metaphor of the CBI/CBT. In an earlier
example about baking bread, the metaphor was of a kitchen. The background in that case
would be a photograph or graphic of a kitchen. If the module was to be a tutorial instead,
64
such as training about safety regulations in commercial food preparation for a paper and
pencil exam, we might still use a graphic of a kitchen which had been faded to the point
that text and other images can be displayed against it. In both cases, having the
background specified early allows us to make better design decisions about other screen
elements.
In some cases, it is not feasible to create a background image. In these cases, it is still
possible to create an interesting background without much expense through the use of
textures and patterns. Rather than specifying a plain color for the screen background,
commercial CD collections are available with different kinds of textures, such as stone,
metal, sand, water, wood, etc. These images can provide visual interest without being
distracting.
In these cases, and when using graphics or photos for a background, it is important to
provide visual boundaries for the screen. Without them, content on your screen will
appear to be floating in space. For photographic backgrounds, this may need to be done at
the time the photo or graphic is created. Boundaries need not be as obvious as lines,
either. In the kitchen example, we might take a photograph in a way that the edge of the
counters and cabinets form a visual border. You can also use a graphic editing program to
apply effects such as shadows and blurring to the edges of your graphic to create borders.
These techniques provide definition for your screen and will help you design other
elements of your interface.
A place for everything, and everything in its place
65
Once we have a working background image, we can consider the other elements on the
screen. Common screen elements include a place for direct instructional text and images,
a place for directions about how to proceed, and place for responses to requests for help,
and a place for buttons and other navigational tools. When designing these elements, the
metaphor we have chosen can help. For instance, in our example of learning to bake
bread, our main menu could be an actual menu. The instructional text might take place on
the pages of a “cookbook,” and directions on how to proceed or responses to requests for
help could take place on “recipe” cards.
One mistake novice designers make is that they try to place all these elements on the
screen at the same time, taking up the same amount of space. Not only does this kind of
balance create boring screens, it is also impractical. Decide first which elements are
likely to be on the screen the most often, and then determine how much space each is
likely to require. Often, it is the instructional text is likely to be the most common
element and require the most space. The more space you devote to this, the less “paging”
the learner will have do. Navigational elements and instructions about how to proceed
are likely to always be on screen, although they do not usually take up as much space.
Take the elements that are most frequently on screen and try to build space for all of them
to appear at once. This will minimize the amount of “mousing” the learner has to do on a
regular basis. The elements that are less frequently on screen, such as help, glossaries,
etc., can be assigned to icons that, when clicked, take over the screen temporarily until
the learner is ready to continue with the instruction.
Once you have assigned sizes and places to these elements, you need to define them for
the learner. This is done by, once again, creating boundaries for each element. This may
66
occur naturally as part of the metaphor (e.g., recipe cards), or may need to be created
through the use of lines, boxes, or other border effects. Without these boundaries,
elements tend to flow into each other, creating a disorganized and confusing interface.
Elements will also change shape and size, as is the case with differing amounts of
instructional text. Boundaries create a sense of order and size that do not change with the
content. You can then determine how much text will fit in each area, how much space
each takes up, and what their precise location on the screen is so that all your screens
look uniform.
Consistency
Once you have specified the placement and boundaries of each of these elements, don’t
change them. Nothing is more aggravating to your learners than having placement and
the size of elements change throughout the program. This is especially true for your
navigational elements. Don’t have more than one way to navigate from screen to screen
and element to element unless there is a compelling instructional reason. Buttons, icons,
menus, and labels should not change location or functionality. If you must make a change
for one or two instances, make that change obvious, draw the learner’s attention to it, and
provide specific directions about how to proceed if necessary. Determine what the exact
locations and sizes are for each of these areas and write them down so that you can make
sure each screen looks the same.
Text and readability
CBI/CBT has a lot of advantages over paper-based instruction. Text readability is not one
of them. Computer screen text is much harder to read than print. Because of this, the text
67
you use should make it as easy as possible for the learner to read and process. Font sizes
less than 12pts are not recommended for screen text. Serif fonts (fonts like Times New
Roman that have “points” on the bottom and/or top) are much easier to read on paper and
on screen than san serif (fonts like Arial that don’t have serifs). This is because the
serif leads the eye from one character to the next.
Even with serif fonts, long blocks of text are hard to process. Break up your text into
shorter blocks and widths, even if this means splitting up a paragraph. White space is not
only more appealing, it makes the text easier to process; good design takes place in space
between elements, not just the elements themselves.
Often, especially against complex or multi-colored backgrounds, text on screen can be
hard to pick out. Creating borders and defined areas with a solid background for the text
can help. In cases where this is not desired, the use of color and drop shadows can help.
First, pick a color for your font that provides a nice contrast with the background. Stick to
more traditional colors where possible (e.g., red rather than hot pink; grass green rather
than lime) as they are easier to read in long stretches.
When text crosses different colors or contrast areas in your background, it can be hard to
see. Try to keep your text over areas which don’t vary much in contrast. In some cases,
you may even want go back and modify your background image using a photo editing
program to “gray out” the areas behind where you will place your text. When this is not
possible or desirable, you can help the text stand out by using one or more text
“shadows.” This is accomplished by picking a color that contrasts well with the
background (e.g., white or gray against a dark background , making an exact duplicate of
68
your text (which is yet another color), offsetting it from your text by one pixel to the right
and below, and placing it behind your main text. A common example of this is the “drop
shadow,” in which colored text appears to float above the page by virtue of the “shadow”
it casts:
In some cases, a third “highlight” can be added one pixel to the left and up to add
additional definition:
Tip: San serif fonts are not good for long strings of text, but they make a nice contrast on
the page for shorter text such as labels, headings, titles, etc.
Usability
This is the hardest property of the interface to define, because it is determined by
individual learner interaction with the CBI/CBT. As such, it is heavily affected by
individual preferences and characteristics. Data gathered from your learner and audience
analyses can help when assessing usability. Nothing will substitute, however, for getting
feedback from members of your target audience.
Most ID models call for formative evaluation early in the design process, and it is even
more critical for CBI/CBT. It can be very helpful to sit down with learners from your
intended audience and ask them to view your sketches of the interface. Ask them how
69
they would use that interface to access information, navigate, get help, etc. This can help
narrow down and refine your interface even before you create your mock-ups on the
computer. Once you have built your computer-based mock-ups, including representative
screens for each major section of the program and basic navigation, you should sit down
with your learners again. This process need not involve more than 5-10 screens, one
learner, and 30 minutes to an hour.
Failure to get learner feedback on your interface prior to designing and developing the
CBI/CBT can have catastrophic results. Changes to the interface after you have created
the product are labor intensive and will certainly take longer than making those changes
up front; in some cases, as long as developing the CBI/CBT itself!
Case Study
When we began working on Ribbit’s Big Splash (CATE, 2000), we knew that we would
incorporate video of Ribbit the frog (played by a hand puppet) into the project. We were
developing in Authorware 4 for the Macintosh, and hoped to deliver the product crossplatform.
The video was shot and we had a local video shop export the video in the Quicktime
format. The codec they used was a new codec called Sorenson. Sorenson creates
beautiful quality video at surprisingly small file size. Sorenson required Quicktime 3,
which unbeknownst to us (or any Authorware developers at the time) and despite
documentation in Authorware to the contrary, did not work in Authorware.
Once we realized this, we decided to switch our development to Windows, as the new
version of Authorware was available there and would presumably support the Sorenson
70
codec. Unfortunately, Apple introduced licensing requirements for distributing Quicktime
at about that time, which meant increased cost for us (they have since removed these
unpopular restrictions). In addition, end users would have to install Quicktime 3 on their
systems, thereby increasing the difficulty and corresponding technical problems we
would have to deal with during installation. Since we were switching to the Windows
platform, we decided to use the native video format, AVI.
Our video shop could not export video as AVI, however, and after spending two weeks
attempting to convert the existing files to AVI, we came to the conclusion that we would
have to re-shoot the entire video sequence to that point. Needless to say, this presented a
serious cost to us in dollars and time.
While these problems were not actually the result of not considering our platform and
video formats prior to design and development, they do indicate the potential costs
associated with not making those decisions up front.
Summary
Instructional design is critical to all forms of instruction. The underlying principle, that
making decisions on paper will save time and money later during development, is as true
for the pre-planning decisions needed to design and develop CBI/CBT. Pre-planning
occurs prior to the design process, and focuses on issues such as platform, fonts, color
palettes, file formats, interface design, and the learner characteristics specific to
CBI/CBT.
71
Determining the type of instruction you will develop (tutorial, ELE, etc.) and careful
attention to the instructional strategies you think best suit the mode and content will also
guide and inform your interface design, which in turn will inform your design process.
Failure to attend to these issues prior to design will, at the least, result in longer design
and development time and higher cost, and at the worst may derail a project to the point
that it cannot be completed successfully.
72
Exercises
1) You have been asked to build a program to teach people the ten new safety rules at a
local manufacturing plant. Which learning mode might be MOST appropriate and
cost effective (assume that CBI/CBT is appropriate)?
2) You have been asked to build a program to teach customer service personnel how to
interact with customers who are unhappy with their recent purchase. Which learning
mode might be MOST appropriate and cost effective (assume that CBI/CBT is
appropriate)?
3) You have been assigned a project by your supervisor to develop CBI/CBT that will
teach customer service skills (a kind of what are often called “soft” skills). The
emphasis is on managing both positive and negative customer reactions. Describe
how you might do this in a tutorial format and a game or simulation format.
4) Develop a pre-planning document for a project you intend to develop. Include your
responses to each of the areas mentioned in this chapter as they relate to your project.
Provide a rationale for the decision you make, and indicate how long you think it will
take to make the necessary evaluations.
5) Describe what adjustments you might make in your project to account for differences
in learner characteristics, including age, gender, and cognitive style.
73
Chapter 3: Planning & Managing the Instructional Title
Overview
The point at which instructional design stops and instructional development begins is
usually seamless. The development of print-based or stand-up/lecture-based instruction is
a straightforward process with which most designers are familiar. Other forms of
instruction such as video-, web-, and computer-based instruction introduce specific
characteristics into the development and implementation processes that differ from other
forms of instruction. Some of these characteristics are the result of the development tool
itself, such as is the case with Authorware, while others are the result of the medium.
This chapter provides an overview of the planning and management issues associated
with developing an interactive instructional title, with a particular emphasis on specific
documentation and project management processes.
CBI/CBT is among the most difficult, time-consuming, and mentally demanding forms of
instruction to develop. There is a reason that CBI/CBT is expensive to develop; not many
people possess the skills to be effective CBI/CBT developers, and those that do recognize
the inherent difficulty and charge accordingly. While the design document is critical to all
forms of instruction, it is perhaps more so with CBI/CBT. Those who are successful
CBI/CBT developers can attribute a large part of their success to the use of
documentation during the design phase. The design documents described in this chapter
work because they allow the designer/developer to off-load much of the cognitive
processing involved in development onto the documents, which in turn frees them to
focus exclusively on the aspects of development related to the authoring tool itself, not
74
the least of which is troubleshooting. Rather than having to stop during development to
make decisions about fonts, placement, and functionality (and keep track of all these
decisions mentally), they are able to refer to their documentation where all those
decisions have been made in advance. This documentation also facilitates team-based
authoring by ensuring that everyone has the same information and conceptualization to
work from when designing and developing their individual modules.
Objectives
1. Identify the supporting processes and develop supporting documents required
when developing CBI/CBT, including:
a. Goals and objectives
b. Treatment
c. White paper
d. Variable lists
e. Storyboards
f. Style sheets
g. Quality control sheets
h. Media logs
75
2. Identify the issues involved with developing CBI/CBT as a team
3. Identify the client interaction procedures and documentation required when
developing CBI/CBT.
4. Identify formative and summative evaluations processes as they impact CBI/CBT.
5. Identify the basic media use and copyright issues needed to develop appropriate
documentation and procedures for managing media and copyright compliance.
Establishing a Timeline
The first thing you have to do when planning your project is to establish a timeline for
accomplishing all that you will need to do. Project management and coordination is the
subject of several books and courses, and cannot be discussed here in great detail, but
there are some principles so essential to all timelines that you may find them useful in
planning your CBI/CBT project.
The timeline can take any form you wish, but it should reflect each of the planning,
design, and development stages that are discussed in this chapter. Each task should have a
start date, end date, and personnel assignment (if working as a team).
In addition to the documents discussed in this chapter, your timeline should also reflect
the ongoing processes that accompany these documents, such as formative evaluation and
quality control. These processes should show up in your timeline just as any other task;
each with its own task bar and start and end time. They should start early and appear at
regular intervals throughout the project.
76
It is not uncommon for novice developers to both underestimate the amount of
development time needed and to short-change the design process. As a rule of thumb, you
will need at least half your time for development and evaluation, and at least 1/3 of your
time for design. For readers using this book in a typical 15-week, semester-long course,
this means a minimum of 5 weeks of design and 7-8 weeks of development. The
development time estimate is based on the assumption that you have spent the first five
weeks in the design process. If not, your development time will increase dramatically
(and the quality will likely drop), as you will be forced to make design decisions at the
same time that you are developing.
Tip: In a 15-week semester, you will not be able to develop the project you dream of,
neither in terms of quality, length, or complexity. As a rule of thumb, you will probably
be able to develop no more than a five- to fifteen-minute lesson on one or two concepts
with basic interactivity. It is important to be realistic about what you can accomplish as a
novice developer; your goal is to learn the basics of Authorware, NOT to develop
dazzling CBI/CBT (yet).
Goals & Objectives
Goals and objectives are, of course, integral parts of the instructional design process and
are covered in great depth in instructional design textbooks. Nevertheless, some
discussion of them is warranted here for two reasons. First and foremost is that novice
designers often have difficulty distinguishing goals from objectives and in writing good
instructional objectives. The second reason is that your goals and objectives help
determine the shape and type of CBI/CBT that you develop.
77
Goals are statements that indicate the overall purpose of the instruction vis-à-vis the
learner. Goals are the umbrella under which all your objectives fall and, in fact, are what
drive your objectives. Objectives are the specific things that the learner will be able to
demonstrate upon completion of the instruction, the sum total of which are your
instructional goals.
For example, if I want to develop an instructional module that will teach the learner to
develop basic instruction using Authorware, my goal might be written thus:
Given a computer with Macromedia Authorware installed, the learner will be able to
create a short interactive instructional module.
My objectives then come from my conceptualization of what is necessary “to create a
short interactive instructional module.” An example might be:
1. Given a working version of Authorware, the learner will be able to create a basic
interaction with 100% accuracy.
1.1. Given the icon palette and flowline in Authorware, the learner will be able to
drag the different icons needed for an interaction onto the flowline in the correct
sequence with 100% accuracy.
1.1.1. Given the icon palette in Authorware, the learner will be able to identify
the different icons with 100% accuracy.
78
Obviously, this is an incomplete breakdown of even this one objective, but it serves as an
example. A full instructional task analysis would result in tens if not hundreds of
objectives, depending upon the scope of my definition of a “short” interactive module.
The objectives listed above are types of behavioral objectives known as three-component
objectives. The name is derived from the inclusion of the condition (given _______),
what the learner specifically will do (identify/demonstrate/discriminate ______), and the
criteria (with ____% accuracy).
There are other types of goals and objectives, depending on what model and what
philosophy of instructional design you choose. Goals and objectives that are
constructivist in nature focus on process rather than behavior. For example:
1. Given a working version of Authorware, the learner will determine the relationships
between different components of instruction and their manifestations in computerbased instruction (goal).
2. Given a working version of Authorware, the learner will explore the relationships
between the different components of a basic interaction (objective)
These types of objectives are not mutually exclusive, nor is one “better” than the other.
The critical distinction is that between goals and objectives themselves.
Goals and objectives are of course critical to the design of any type of instruction. They
allow you to catch mistakes prior to development, guide your sequencing decisions about
the content, and lead directly to your assessment items. The consequences of skipping
this step or creating poor examples of them in CBI/CBT can be more drastic than for
79
other forms of instruction (with the possible exception of video and web-based
instruction), however. The expense and trouble of changing your objectives after
development in any form of instruction is significant, often requiring modification of
existing instruction and assessment items if not the creation of entirely new ones. With
print-based or instructor-led instruction, the instruction tends to exist largely in wordprocessing format someplace and, as word processed documents are linear and selfcontained, navigating through the instruction to make modifications is relatively
straightforward.
With CBI/CBT, instruction is often not linear from the perspective of the learner or
designer, and making modifications to existing instructional elements is anything but
straightforward. There are many examples of why this is the case, but one such example
serves to illustrate the point.
Assume that you created some instruction on how to repair a “widget.” As part of that
instruction, the learner must be able to identify 10 parts by name and shape. To test this,
you create an assessment item that requires the learner to match the shapes to their
names. You later find out you need to add an eleventh part. If this were print- or lecturebased instruction, you would open the relevant document, scroll to the point where the
parts are first identified, add the instruction on the 11th part, and then scroll to (or open)
the assessment item and add a graphic and name for the eleventh part. If, on the other
hand, this were CBI/CBT developed in Authorware, finding the relevant part of the
instruction can be difficult, as there may be hundreds or thousands of component icons,
each of which can be grouped or “nested” inside each other. Just getting to the relevant
portion can take 10 or 20 mouse clicks, and that is assuming you know where it is (which
80
you will if you have developed an appropriate naming convention as is discussed later in
the section on storyboards). Once there, you would add a new display icon, open it up,
type in the new instruction, create an additional practice opportunity for that part (5 to 6
additional icons, each of which must be opened and modified accordingly). Then you
would move to the relevant assessment portion of the file containing the drag and drop
matching sequence (where the learner actually drags the images of the parts to the
matching name), add and open an icon for the 11th part, add and open an icon for the
name, add and modify a target area response, and change the means of scoring that item
there and anywhere else in the file that makes use of it.
Much of the terminology here makes little sense to you now as it references procedures in
Authorware that are not covered until later, but it should be clear nonetheless that making
changes in CBI/CBT can be significantly more time consuming than print- or lecturebased instruction. Taking the time to design and evaluate your goals and objectives can
prevent expensive modifications down the road.
Treatment
Because CBI/CBT, like video-based instruction, is both expensive to develop, costly to
revise, and harder to “visualize” than other forms of instruction, additional documents are
required prior to development. Treatments, and the next document discussed,
storyboards, are common for CBI/CBT and video-based instruction. In fact, they both
come from the film world, where they serve as a means of both planning and describing
the final product for the writer/director and others. By spelling out the overall look and
81
feel of the product on paper, these documents serve a valuable formative evaluation
function in both film and CBI/CBT.
Tip: If you have a DVD player, watch for DVDs that include behind the scenes
information and storyboards to get an idea of what and how storyboards play an
invaluable role in film creation.
What is a treatment?
A treatment is a general narrative description of the learner’s overall experience of the
module you propose to design. It is used primarily to communicate the look and feel of
the project to other design team members and to the clients. It may be thought of as a
“blow-by-blow” description of the application you are designing. While it does not
describe every word, picture, screen, etc., that the user will encounter, it should describe
the main phases (e.g., introduction, main sections, basic content overview, practice items,
interactivity, assessment, etc.) of the program. It also describes the overall approach you
plan to take in delivering the instruction (e.g., the metaphor or context you will use). The
treatment should give the reader a good idea of what the final product will look, feel, and
act like from the learner’s perspective including color, composition/screen elements,
navigation options, menus, etc.
What goes into a treatment?
A treatment should address the following areas:
82
•
Visual content (e.g., backgrounds, buttons, transitions, images, text placement and
behavior)
•
Characters (who they are, how they will behave, and what their function is)
•
Story line (how the program will begin, progress, and finish, and what will
happen along the way)
•
Themes and sub-themes (what they are and how they will be developed)
Remember that you do not have to know or describe exactly what every element will look
like; often, all you will know is the general types of images, colors, buttons, and other
elements you want to use. Just as with an instructional design document, make sure that
anyone reading the treatment has enough information to describe it accurately to others or
to begin designing it themselves. It is critical to have someone unfamiliar with the
proposed project read the treatment. Because you are so close to the project, you will skip
steps and ideas without realizing it. Getting feedback from someone else unfamiliar with
the content or your project will force you to confront aspects of the design you have not
yet considered, which can save you time and stress later.
Treatments need not be much more than one to three pages, even for complex topics.
Here is an example for a module on learning to use the PADI dive planner to plan
S.C.U.B.A. dives:
Background/designer notes
83
This project adopts a largely behavioral approach because of the subject matter.
Although several techniques and ideas from the constructivist/cognitive approach
will be incorporated, since there is only one way to read the tables and dive
correctly and safely, a behavioral approach is most useful. Behavioral
contributions to this project include:
•
Chaining (diving is easily intuited as discrete behavioral units chained
together, and reading the card is similarly constructed)
•
Feedback (knowledge of correct results) on a CR schedule
•
Reinforcement on a FR schedule (access to underwater video segments for
three consecutive correct responses)
Examples of cognitive/constructivist elements in this project include:
•
Acronyms to remember sequence of steps
•
Difficulty of practice items varies with familiarity
•
Use of underwater metaphor for consistency
The project itself will be comprised of six units: introduction, terminology, PADI
Dive Planner orientation, planning single dives, planning multiple dives, and
closing credits/disclaimer/references.
Description of project
84
The program opens with a black screen, music (new age/Andreas Wollenweidertype?) slowly fades into hearing while black dissolves to full screen image of
ocean. Smaller images of marine life and scuba diving appear one after the other
in different parts of the screen’s periphery until perimeter is filled. Title fades into
sight in middle of screen (working title is “Charting Your Way to a Safe Dive”).
Title fades and is replaced in order by credits and warning/disclaimer.
Music continues as screen fades out and is replaced by main graphic/image of
cross-section of ocean, including a narrow strip of sky at the top, narrow strip of
ocean floor at bottom, and blue water in between. Where possible, actual images
of sea floor and/or sky will be used. The international diving/PADI flag appears in
the upper left corner and will indicate through text the user’s position in the
program at all times. A quit button appears at the bottom left of the screen (looks
like a PADI flag or a buoy), and forward and backward buttons appear at the
bottom right of the screen (they look like barracuda). Instructions appear
regarding their use. This is the background for the majority of screens in the
program, and may be assumed to be the background for all scenes unless
otherwise stated. Music fades as goals and objectives of the program fade into
center of screen accompanied by narrator voice-over. When the user clicks on the
forward button, these are then replaced in turn by a brief description of why this
program is necessary, also with voice-over. Finally, again when the user clicks on
the forward button, the description fades out and is replaced by a screen of
navigation instructions for use in the program, also accompanied by voice-over.
85
When the learner indicates she/he is ready to proceed, the terminology title fades
into view, and is then replaced by a description of what will follow (definitions of
terminology) and the rationale (have to know the terms before can used the
planner). Audio voice-over continues here, but no music. When the user moves
forward, a series of terms appears to the left side of the screen, along with
instructions to click on any term to see its definition. Voice-over narration is
present for the instructions and is followed by a background music loop.
Acronyms will be used where possible to facilitate association. Clicking on each
term brings up a definition immediately opposite it on the right side of the screen.
The learner may click on each term as often as he/she likes, and may advance
when ready by clicking on the forward arrow, which fades the background music
out.
The terms remain in the same location, while any remaining definitions fade out.
A definition, generated at random, appears in the lower half of the screen.
Instructions to drag the definition to its appropriate term and a reminder that a 100
percent correct response rate on this activity will allow the learner to view
underwater footage are presented as text and audio. The background music
appears again after the narration. When an incorrect match is made, the definition
returns to its starting point and the learner is told she/he made an incorrect
response (text). When a correct match is made, the definition disappears and the
learner is told he/she made a correct choice (text). This is the basic structure for
all responses in the program. If the learner makes all correct responses, a button
86
will appear along with text and audio congratulating and telling him/her to press it
if she/he wishes to see video footage.
The second section is an introduction to the PADI Dive Planner and is entered in
the same manner as the terminology section (fade in to title, objectives, rationale,
no music, voice over, etc.). Moving forward brings the user to a screen with the
PADI chart on the left half of the screen. Instructions (audio and text) tell the user
to watch the card and the text which appears to the right side of the screen to learn
about the different elements of the card. No music is present. The first element is
highlighted already on the card (yellow square) and connected to a description at
the right by an arrow. The description is read aloud. Instructions to press the video
button to see the highlighted item on the actual card, or the forward button when
ready to move on are at the bottom center of the screen. Each time the user clicks
forward, a new element is highlighted and a new description appears. This
continues until all elements of Table 1 have been covered. Buttons and
instructions to continue to Table 2 or review Table 1 are presented. This process
is repeated until all three tables have been reviewed, at which point the user can
review any table or continue to the test.
The tables are again presented in order (left side of screen) and labels/descriptions
of table elements appear (right side of screen) along with instructions (audio and
text—bottom center of screen) to point-click on the elements on the card which
match the labels/descriptions at the right. The user is also reminded that 100%
correct response rate gains access to more video. Correct and incorrect responses
87
result in feedback (text) as in Section II. When finished, the user enters the single
dive and decompression section.
This section is entered as all the others are (fade in to title, objectives, rationale,
no music, voice over, etc.). The second screen includes an animation of a diver
making a single dive from the surface, to the bottom, and back again. The card
with Table 1 is presented (left side screen) along with instructions (text and audio)
to click the forward button to see the successive steps involved in planning a
single dive. Learners will also have the option of viewing video of each step being
performed as well. Each time the continue button is clicked a description of the
corresponding step appears at right and is accompanied by audio. As the
description occurs, a highlighted, animated square moves on the card to illustrate
proper use of the table. A button to view the corresponding step as video then
appears, giving access to the video clip. This continues until all steps have been
reviewed, at which point the learner may repeat the process or continue to the test.
If she/he continues, all text fades out.
During the test, the time and depth figures of a hypothetical dive appear in the
upper right corner of the screen. An animated scuba diver “floats” at the surface
of the water. Instructions (audio and text) tell the user:
“In this next section, you will be asked to determine whether a
hypothetical dive requires a safety or decompression stop. To answer these
questions, you will need to access the dive planner from the menu above
to plan each dive. When you have done this, you will click on the dive
88
button to begin the dive. You will be asked upon ascending whether a
decompression or safety stop is required. At that point you may again
access the Dive Planner to check or determine your answer. If you get all
of the questions right, you will be able to view more underwater video
footage.”
These directions may be accessed at any time during the test. If the learner makes
all correct responses, a button will appear along with text and audio
congratulating and telling her/him to press it if he/she wishes to see video footage.
If the learner does not get them all correct, the screen fades and is replaced by:
Davey Jones’ Locker
This screen appears any time an incorrect response in entered in a test, and is
accompanied by dire music (Beethoven’s Ninth, etc.). It is an ocean floor scene
with no sky visible and many skeletons and bones littering the floor. Barracuda,
shark, and other creepy critters abound. A sign in the foreground says “Davey
Jones’ Locker,” while text across the upper center of the screen reads “Sorry, but
it looks like you won’t be doing any more diving! (click anywhere to return to the
program).” Clicking anywhere returns the user to the last point they were in the
program via a slow dissolve.
The next section teaches and tests repeated dives in the same manner as single
dives (tables with highlighted squares illustrating steps which appear at right,
followed by review if desired), the only difference being that all three tables of
the dive planner must be used together, and the animated graphic for repetitive
89
diving shows a single dive by the scuba diver with a pause at the surface and then
a second dive. Again, after each step is animated, the user has access to a video
clip showing that step. After all steps have been reviewed, the user may access a
video sequence that demonstrates all steps as one temporally contiguous action.
This video may be reviewed as often as the learner wants. The test and directions
are identical otherwise. All correct results in more video; any wrong results in
Davey Jones’ Locker.
The last section is further (scrolling) credits, another disclaimer, and the address
for PADI for further information, all with the same background as the main body
of instruction.
As you can see, enough detail is provided to give the reader a good sense of what will be
happening without going into excruciating detail about each screen.
Heads Up: The treatment above was for a 1-2 hour program. Yours, for your first
project, should be significantly shorter!
Storyboards
As mentioned earlier, storyboards also come from the world of film production.
Storyboards tell what will happen on each “screen” of the instruction. They are not an
exact one-for-one representation of what every element of your CBI/CBT will be; each
storyboard may require tens or hundreds of programming icons to implement. Instead, it
may be helpful to think of storyboards as “scenes” in a movie. Each scene may be
comprised of multiple characters, each with his or her own dialog, background scenery,
90
sound effects, etc., yet each can be represented with a single storyboard that encapsulates
all the action (e.g., “Frank realizes he’s been betrayed and confronts Don”).
As in film production, the storyboard presents the main components of the scene so that
decisions about content, style, etc., can be made prior to creating the final product. The
storyboards can be used in formative evaluation by SMEs, as approval documents for
sign-off by the client, and as design documents by the individual designers/developers.
Perhaps their most important benefit is that they force the designer to think through each
aspect of the module ahead of time. Novice developers of CBI/CBT often fail to see the
relevance of storyboards except in retrospect. This is understandable, as it takes a great
deal of time to develop them. In combination with the design document itself and the
deadline, the time spent prior to actual development can be frightening. The payoff
comes during development and revision, which in my experience are conservatively cut
in half by the judicious use of storyboards. The experience on the part of the developers
is vastly different as well. By doing the planning and arrangement up front, developers
are able to devote all of their mental energy to fine-tuning, polishing, and troubleshooting. The end result is a less stressed developer and more polished product in less
time.
Storyboards are largely dependent upon the beliefs and preferences of the designer. They
vary greatly in look and content. There are some elements that are common to almost all
CBI/CBT storyboards, however. Most storyboards include a title, date, scene sketch, and
media elements. What follows is a brief description of these and other common, useful
elements to include on a storyboard.
91
Title, Date, and Branch Point
The title is an optional description of the scene based on the topic or section of the
module. For instance, the project could have an introduction, help, glossary, 4 main
instructional topics, and assessment. It is sometimes helpful to have a prose description of
the section and content. The date is simply the date the storyboard was created.
Branch points are less familiar to novice developers of CBI/CBT but play a critical role
in the development process and, in particular, the revision process. Branch points derive
their name from the ability of the learner to navigate from place to place within the
instruction according to the controls the designer places in the instruction. This can be
from page to page (in linear tutorials) or from one section to any other section. Branch
points are the points at which the learner can “branch” to another location.
Branch points serve two purposes in CBI/CBT. First, they allow the designers and
developers to keep track of how the program is supposed to behave. This not only speeds
up the programming, it allows the designers and clients to view the storyboards with the
same sort of functionality that will be available in the final product. It is not uncommon
when making these kinds of “dry runs” to find gaps that need to be filled (transitions,
introductory screens, etc.). Second, they are also helpful when working with clients who
are less familiar with CBI/CBT, as they can get a feel for the interactivity and flow of the
program.
The second thing that branch points do is to greatly reduce the time and frustration
associated with making modifications and revisions to the program. This is because they
are used not only to identify the storyboards but also the corresponding elements in the
92
CBI/CBT. When a graphic or audio file needs to be placed in a previously developed
section, knowing the branch point allows you navigate quickly to the correct location.
The naming/numbering scheme you develop for branch points is largely a matter of
personal choice, but whatever you choose should be hierarchical. You should be able to
tell by looking at that name/number if it is a sub-section of something else. For this
reason, I usually start with the first 2 letters from the relevant section (e.g., GL for
glossary, AS for assessment, IN for intro, etc.). If it is a group project, I may start with
two characters for the group name (e.g., G1, G2, etc.) followed by 2 letters from the
relevant section. I then follow this with a decimal-based numbering scheme (e.g., 1.1,
1.2, 2.1, etc.). This way, I know that 2.1.1 is a subsection of 2.1, and that 2.1.2 comes
after 2.1.1. This particular numbering scheme is infinitely adjustable through the
incrementation of numbers and/or the addition of decimal places. If I find that I need to
create another storyboard in between two others, I can add .1 (or .4,5,6, or whatever
increment comes next in the sequence) to the number of the first storyboard.
Tip: Using the numbering system from your objectives as the basis for your branch
points will also help you identify components associated with each individual
objective/assessment item.
Power Tip: You can use your branch points as naming schemes for your supporting files
(text, audio, video, graphics, etc.). This will help you identify where each file is supposed
to go when it comes time to place it into the project.
93
Branch Point Information
If each storyboard has its own branch point, then there has to be a way in the program for
the learner to navigate from one branch point (scene) to another. Branch point
information differs from the branch point itself only in that is an area on your storyboard
for you to specify all the places the learner can branch to from the current
storyboard/branch point. For instance, if I am looking at a storyboard for group 1 (G1) on
the third “scene” of the first section (1.3), the branch point for this storyboard would be
G1_1.3. My branch point information might contain G1_1.2, G1_1.4, G1_MN, and Quit,
indicating that the learner can get to the prior page (which has its own storyboard whose
branch point is G1_1.2), next page, menu, or quit, respectively from here.
Graphics/Animation/Video
Depending on the title being developed you may or may not have animation or video.
This section is a place to describe any kind of graphics or animations that need to be
developed for this scene, along with the name and location of the files, if relevant.
Audio
Just as you would expect, audio is where you describe any sound effects, music, voiceover narration, etc., that will be used in the scene. Remember that a scene is not
necessarily just one static screen; different sounds may occur based on how the learner
interacts with this scene, so you need to describe all the sounds, even though they may
not all occur at the same time.
Interactivity
94
This section allows you to describe what kinds of interactions the learner can have with
the scene, and under what conditions. This is useful not only because during development
you can get right to work creating without having to brainstorm interactivity, but also
because it forces the designer(s) to think in CBI/CBT terms. Novice designers tend to
forget all about interactivity when designing because they get caught up in the instruction
itself (much as designers often forget about instructional strategies when designing other
types of instruction).
Text
Depending on your preferences, this may contain the entire text sequence for the scene,
or it may simply contain the name and location of a separate text file. As you will learn
later, Authorware can bring in text files automatically and generate the relevant icons for
you. Because of this, many designers prefer to create text in a word processor rather than
write it out on the storyboard and then re-type it in Authorware.
Scene Sketch
Again, depending on your preferences, this may take up the largest portion of the
storyboard, or it may be no more than a three by four box. In any case, it contains a rough
sketch of the scene as it will appear to the learner. This is particularly useful when the
designer is not the developer, as it aids greatly in communicating the vision of the
designer. Even when the designer and developer are one and the same, you might be
surprised at how many times you can’t figure out what you had in mind when you
designed that storyboard earlier.
95
Notes to Programmer
This is where you make any special notes about the scene that you think are not conveyed
clearly by the other elements on the screen. Most commonly, I find myself making
references to variables and special coding that may be needed to make this scene work,
either on its own or with other parts of the instruction.
In any case, you should identify the elements that make sense to you and arrange them
according to how you think and work. I change storyboard format for almost every
project I work on, although by now they all have the elements mentioned here in one
form or another. Two examples of storyboards can be seen in Figure 1.
Figure 1. Examples of two different types of storyboard.
Style Sheets
96
A style sheet is a document that specifies the look and feel of your final product. In
Chapter 2 you determined much of the information that goes into a style sheet, including
the fonts you will use, color choices, and the names and placement of on-screen buttons
and elements. The style sheet documents these earlier decisions in more detail (e.g.,
which fonts, sizes, and colors will be used for different elements such as titles, body text,
section headings, etc.).
Style sheets play three roles in the design and development of interactive CBI/CBT.
During design, they force you to make decisions about the project early enough that you
can make changes based on evaluations before you have invested too much effort in the
project. During development, they serve as a job aid so that you do not have to make
decisions on the fly and are able to focus on the development itself. Finally, they ensure
consistency throughout the project. You may think it is no big deal to keep be consistent,
but it is easy to make small errors along the way that you don’t catch until the quality
control review. And when you are part of a team, consistency among team members is
harder to manage.
Just as with storyboards, there are many different ways to develop a style sheet,
depending upon personal preferences, past experience, and the needs of the specific
product under development. While there are no hard and fast rules about what should go
into a style sheet or how it should look, there are some basic concepts and principles that
you may find helpful when you are first starting out.
Clarity, Brevity, & Usability
97
Above all, your style sheet should be usable. Long, prose descriptions of each of the
elements are not easily processed. Keep your descriptions short and to the point. Use
bullets, lots of white space, and clear headings or section titles in bold with larger fonts.
You should be able to find any information you need in five seconds by scanning the
document. Likewise, try to keep the length of the document within reason; flipping
through ten pages to find things takes time. You may even want to consider using index
cards with just one element on each card, which you can then bind together using ring
clips to make a sort of flip book. This is portable (fits in a pocket) and less likely to get
lost in all the other papers you often have around you. You can also rearrange the cards if
a different order seems to make more sense later on.
Text Styles
It is helpful to name each text element on your screen for ease of communication and
reference. Some common examples include Title, Sub-Title, Body Text, Captions, Button
Text, etc. If you use shadows to make your text stand out, you will need to name each of
those as well (e.g., Title Shadow, Body Text Shadow, etc.). You should list each by
name, followed by the font, size, color, placement on screen, and a description of when it
should be used. You may also want to provide a sample of that style in the document as
well. As you will see later, these elements will help you set what are called font styles in
Authorware.
Colors
You may find it helpful to specify the exact colors that can be used. While it is true that
you can safely choose any of the colors from the palette you have specified (see Chapter
98
2 for more information on color palettes), you will undoubtedly spend some time in
graphics editing programs like Photoshop or Fireworks creating elements for your
project. Knowing the exact color you are using for different screen elements will save
you time when you are creating or modifying other elements in a graphics program that
you want to match to what you have created in Authorware.
99
Quality Control
Quality control is, of course, part of the development process for all forms of instruction.
It is made somewhat more difficult by the non-linear nature of CBI/CBT and by the
complexity of the final product as compared to print-based instruction, for instance. Too
often, quality control, like formative evaluation, is left until late in the project, when
changes are expensive (in time and money) to make. Establishing a quality control plan
early on helps you minimize the amount of changes needed later on.
Part of the quality control plan is addressed by the creation of the documents described
earlier in this chapter. If those documents have been carefully designed to be complete
AND usable, and if all design and development team members know what they are, how
to use them, and what their importance is, your quality control plan may be little more
than “use the existing documents when developing.” There are, however, some additional
considerations for quality control that have not been addressed to this point.
Your quality control document should start by detailing when and how the quality control
process should be conducted, and by whom. It should specify exactly how each of the
documents created should be used to look for consistency and accuracy throughout the
project. Quality control should be assigned to one or more people specifically; making it
“everyone’s” job is a recipe for trouble, as it will undoubtedly be relegated to a lower
priority than the other tasks for which they are responsible. If, as is often the case, you are
the entire development team yourself, you should attempt to enlist someone outside the
project in the process—we are our own worst editors because we are too close to the
project. If you have a spouse or friend who is willing to help out, have them work on
100
quality control. If you don’t, consider paying someone to do it. In a classroom setting, it
is often possible to swap quality control duties with someone else in the same situation.
Regardless of who conducts the quality control, it is critical that you specify exactly
when to conduct the quality control, and in what manner. If you have established a
timeline, it should specify who will conduct the quality control and when they will do so.
Failure to do so will result in leaving it until too late in the project, resulting in wasted
time and extra effort. You may even find that there are things you should change that you
no longer have the time (and perhaps the budget) to modify, as this would require too
many changes in the project. Like formative evaluation, quality control should be
conducted early and often.
It is important for the quality controller NOT to simply go through the instruction as the
learner would but to attempt to make use of all options and navigation within each scene.
They should try all the buttons, menus, and interactions possible in that scene. There may
be different things they need to look for based on the stage of development of the project.
For instance, content can be evaluated from the storyboards for spelling and grammar
long before the project is developed. In the early stages of development, it is common to
focus on navigability and functionality of the program, which may not even contain any
real content at that point. As the program development proceeds, the controller may
examine all these issues again as all the elements are brought together in the product.
The other part of quality control consists of the creation of the documents that will be
used to document and manage the process. You should develop checklists and guidelines
for the quality control person to use during the process. These documents should again be
101
short and easy to use. The quality controller should be able to use the quality control
document both as a guide and as a means of documentation throughout the process. The
document should list what to look for (placement and location of elements, text styles,
navigation, colors, spelling, grammar, etc.) and make frequent reference to the relevant
documents created earlier (storyboards, style sheet, etc.).
The document should contain places for the quality controller to indicate where the
problem occurred (for example, at which branch point and title), and what the nature of
the problem is (doesn’t navigate as described, element is out of place, spelling/grammar
error, etc.). The document should also provide a space to indicate the status of the
problem (e.g., resolved, unresolved, pending, etc.) and who made the revisions and when.
Tip: One way to cut down on the number of documents and promote easy tracking of
quality control issues is to combine them with the storyboards. This can be done either by
printing the quality control checklist on the back of the storyboards or attaching the
quality control form to each storyboard.
An example of a quality control checklist can be seen in Figure 2.
Figure 2. Quality control checklist.
102
Working as a Team
Working as a team to develop CBI/CBT requires tremendous attention to detail and
process. While team development is the norm in the corporate training and development
world, it is not recommended for those just starting out. The reason for this is that you are
just learning the authoring tool and CBI/CBT development process yourself, and, until
you have enough experience with all of the different roles you must play and the
requirements of CBI/CBT, you cannot devote enough time to project and team
management.
Once you have worn all the design and development hats yourself, and after you have
mastered the basics of the authoring process, you will find it beneficial to work in teams,
103
both as preparation for real world development and as a means of creating more
sophisticated and complex titles than would be possible on your own.
There are several benefits of working as a team. First of all, each person can focus on a
smaller portion of the project, which not only cuts down on the development time but
also allows the creation of higher quality products. Secondly, each person can make the
best use of his or her own particular talents. We all experience the pain of working
outside our skill set when working as a one-person team; for me, it is creating graphics
and artwork, for others it may be Authorware or sound editing. Having one person to
whom to refer the things we ourselves are not good at frees us to do what we do best.
Thirdly, working as a team often results in a better product by virtue of the interactions
and brainstorming that occurs. As an individual designer/developer, we are limited by our
own vision. But each team member has their own perspective and ideas which, when
shared during design and development, generates a rich body of ideas to incorporate into
the product. Most team-developed projects result in a final product that is greater than the
sum of each individual’s original conception.
Like too many things in this world, these benefits do not come without a price. While
there are many issues involved with team development, most come down to
communication and project management. Because more than one person is involved, the
potential for inconsistency is much higher. It becomes critical that each team member be
aware of what is being done by others, themselves, and where this all fits in the overall
process.
104
The design documents discussed to this point become absolutely critical as
communication tools. The more time you spend on those documents, the less likely it will
be that people will develop conflicting aspects of the CBI/CBT. Team members should
be familiarized with the purpose and use of each of the documents. One person needs to
be responsible for the team/project management, and that should be ALL that they do. It
is a full-time job to manage communication among team members and monitor the
progress of the project. Regular meetings need to be held in which all team members
report progress and discuss where the team is in the overall progress.
Another challenge presented by team development is in the form of document
management. As the project coordinator, you cannot afford to have multiple versions of
storyboards, media, and CBI/CBT modules or sections under development by more than
one person. When a storyboard is “checked out” by someone, it cannot be modified by
anyone else or you’ll end up with multiple versions that are difficult to reconcile.
Likewise, when documents are not in use, they need to be stored someplace that is
accessible to anyone who might need to work on them, and the project coordinator should
know at all times who has checked out which document. This issue can be extended to
the management of electronic documents as well. Once development has begun, each
developer will be creating documents related to his or her own portion of the project.
If you don’t have a means of collecting, naming, and archiving these files, you can easily
lose track of them. You need to establish a rigorous backup procedure (whether working
as a team or not) so that each person has individual backups and there exists somewhere
an archive of the latest versions of the files in the event that a team member loses the
working version and their backup. These files need to be named in a manner that reflects
105
the date of creation; do NOT rely on the time and date feature of each file, as it relies on
individual computer calendars, which may not be correct. Instead, incorporate the date
into the name of each file.
Finally, there is a tendency on the part of individual developers to create things as they
need them (e.g., a graphic, a sound, etc.). We figure, “this is just a basic sound effect; no
need to hold up development while someone else creates it, I’ll just do it.” This is the
legacy of one-person CBI/CBT development that we all are most familiar with.
Unfortunately, this results in a file management nightmare; what do they name it? Where
do they save it? Will they remember to provide a copy for the archive? Is it royalty free?
The easiest solution to this is to put one person in charge of all media procurement.
Anything needed during development is submitted as a request to the media person, who
is responsible for creating or locating the needed element, naming it according to agreed
upon convention, logging it into the media use log sheet (see media use and copyright
issues below), updating the storyboard as needed to reflect this, and placing a copy in the
main archive and sending it out to the requestor. Likewise, any changes that need to be
made MUST be done by the same person, or you’ll end up with multiple versions.
Client Interaction
It is not uncommon to serve as your own client when you are first learning to develop
CBI/CBT. At some point, however, you will become proficient enough with Authorware
to begin taking on projects for outside clients or for your workplace. Because CBI/CBT is
expensive to develop and difficult to change, some of the procedures for client interaction
become more important than in other forms of instruction.
106
Power Tip: CBI/CBT developed in Authorware can be designed to be upgraded and
updated by using external text and media files. Making changes to content is then as
simple as providing new text or media files to replace those in use by the program.
Authorware will then make the appropriate substitutions automatically. Chapter 4 will
discuss this in more detail.
The Wow Factor
Many clients want CBI/CBT because they think it is “cutting edge.” Clients are rarely the
best judge of training needs, however, and it is the designers’ responsibility to ensure that
the solution matches the problem. If a client comes to you requesting CBI/CBT, be very
skeptical until you fully understand the problem they want solved. If you feel that
CBI/CBT is not warranted, or that there are other equally appropriate training measures,
it is your responsibility to educate the client about other options. In cases where
CBI/CBT will be just as effective as other options, you need only make the client aware
that they could save money by going with other options. In cases where CBI/CBT is not
justified or appropriate, you need to make the client aware that CBI/CBT may not solve
the problem and will certainly cost more money than other alternatives.
So why spend all this time trying to talk the client out of CBI/CBT (and yourself out of
the extra money involved in developing this type of training)? Clients often don’t realize
how expensive and time consuming CBI/CBT is until they get halfway into the project, at
which point they may decide a) they can’t afford it or b) that you are over-charging. In
either case, they will NOT blame themselves for the error. Even if they continue to fund
107
the project, if your solution does not solve their problem, they will hold the training and
you responsible, not their decision to use CBI/CBT.
Sign-offs and Documentation
Of course, some clients will insist on CBI/CBT when it is not necessary or is
inappropriate. At that point, you have two options: turn down the work, or develop it
anyway. In cases where CBI/CBT is inappropriate, you are better off walking away. If
you can’t afford to turn down the money, or if the CBI/CBT will be AS effective as other
(more inexpensive) options, you need to protect yourself through careful documentation
and sign-off.
You need to put your concerns and communications about the project in writing and get
the client to sign off on it. If there are other options that will be just as effective, indicate
what those options are along with some indication of the cost savings. Make sure that you
include your best estimate of the cost of the CBI/CBT. If CBI/CBT is not likely to solve
the client’s problem, spell that out in writing. In both cases, conclude with a statement
that indicates you have made them aware of the issues and that they want to proceed
anyway. Here is an example of one possible statement:
“I have read this document and understand that in [your name]’s opinion, CBI/CBT will
be more expensive to develop/is not appropriate for this situation. I request that CBI/CBT
be developed anyway, and authorize [your name] to develop CBI/CBT for me. My
signature below indicates that I have read and understand the contents of this document.”
108
You need to continue this kind of process throughout the design and development process
as well. As you develop drafts of your design documents (goals & objectives, strategies,
learner analysis, storyboards, etc.), have the client sign off on each of them indicating
they have been approved. This will prevent the unpleasantness that occurs when a client
decides during development to make a change to something that was already agreed upon
during design. You may still make the change, but with the sign off there is no argument
about the extra time and compensation you will need to do so. Of course, you need to
manage the sign-off process carefully; don’t bury clients with documentation or they may
adopt a siege mentality about the project and refuse to sign anything. Only present them
with versions that have been formatively evaluated and are ready to go as far as you are
concerned.
White Paper
The term white paper comes from the world of commercial engineering, design, and
R&D. A white paper is a document that specifies exactly how something should behave
under the conditions for which it was designed. An example of how and why a white
paper may be designed can be found in the world of computer microprocessor
engineering.
Assume that a company has successfully captured the majority of computer chip
manufacturing industry. Their chips are the heart of 95% of all computers sold. Another
company decides that they want to break into that market. They can’t just take one of the
first company’s processors and copy it because there are patents that make this illegal.
Instead, they take one of those chips and give it to a group of engineers whose task is to
109
develop a document that explains exactly what the chip will do under all the conditions
for which it was designed, but not how it does it. This document is called a white paper,
and is then given to a different group of engineers who then attempt to build a chip that
has all the functions of the first chip. Since they have not studied how that first chip does
what is detailed in the white paper, the solutions they are likely to come up with will
differ enough , in theory, to avoid patent infringement.
Of course, it is not likely (or recommended!) that you use this same process for the
development of your CBI/CBT. The white paper, however, can be an invaluable
document when it comes to designing and developing your project. Specifying in
advance how you expect your CBI/CBT to function under all expected conditions forces
you to think through the process early on; you’ll be amazed at how many things you
thought you understood about the product’s behavior will change as you try to spell it all
out on paper. It is like the phenomenon where you swear a paper you have written for a
class assignment is error-free, only to discover many seemingly obvious and egregious
errors upon reading it out loud.
The white paper will also aid you or your developers during the development phase. It
serves as the blueprint for the overall structure of the program. Contrary to what most
novice CBI/CBT developers believe, the best way to begin developing the product is
NOT at the beginning. Instead, you should begin by building the overall structure of the
program, including elements (Introduction, Lesson 1, Lesson 2, Practice, Assessment,
Glossary, etc.) and functionality (navigation, menus, question types, and variables). The
white paper IS the overall structure, and speeds the development process greatly. The
white paper also serves as the basis for developing your variable list. While this sounds
110
like a massive undertaking, remember that you are not saying how you will accomplish
these things, nor are you describing every instance. Your purpose is to talk about the
overall structure at a high level of abstraction, the bird’s eye view, if you will, of the
program. The white paper is rarely much longer than the treatment, in my experience.
Variable List
Variables have specific meaning in Authorware. They serve as “containers” for
information that you want to track and use throughout the program. Common examples
include feedback information such as learner scores on assessments or how much time
learners spend in the instruction. Less obvious uses for variables include tracking how
many times learners have attempted a question, whether they have visited certain sections
of the program, or what their names are. Then you can use those variables to control what
the program does (e.g., presenting different kinds of feedback, making certain sections of
the program accessible or inaccessible, and personalizing the instruction by referring the
learner by name throughout).
We will discuss variables in more detail in Chapter 11. For now, all you need to know is
that the white paper helps you determine what kinds of variables you will need, and
where you will need to use them. This is only true after you have worked with
Authorware enough to understand what it can do on its own and what you will need to do
for it (through the use of variables). You may want to revisit this chapter again once you
have learned the basics of Authorware and are ready to begin developing more complex
products.
Media Use and Copyright Issues
111
The importance of media and copyright management in CBI/CBT cannot be overstated.
Without a good plan for managing and documenting your media use, you will quickly
lose track of what media you have used and where it is. This can spell disaster for you
down the road when you have to make modifications to different media elements and
don’t know where the originals are or whether you own the rights to distribute them. We
discussed earlier how you need one team member who is responsible for media
procurement and distribution, and that they need to develop some kind of log to keep
track of media. Whether you have someone doing this or are doing it yourself as part of
your own one-person team, you need to develop a media log. The media log must be
updated religiously, accurately, and without exception. The first time you say “I’ll just
use this file now and update the log later” is the point at which you lose control of your
media use. This log should document the following information:
•
The name of the media file (exactly as it shows up on the computer)
•
What the format of the file is
•
Where the original of that file can be found
•
Where that file can be found in the project (branch points or libraries)
•
The copyright status of that file
This latter consideration is potentially the most critical; not knowing the other
information will merely increase your development and revision process (by 50-100% in
my experience). Not knowing the copyright status of your media opens you up to major
112
lawsuits, especially if you are developing a product for commercial resale. If you cannot
point to the status for every media element in your file, you cannot distribute the product.
There are many misconceptions about copyright, fair use, and electronic media. This area
of the law is changing rapidly and is extremely complex. In no way should the advice
listed here be taken as legal advice or as a substitute for legal counsel. Having said that,
there are some basic principles you can follow which will minimize your copyright
infringement risk.
•
When in doubt, don’t use it
- If you don’t know or don’t understand completely whether you can use a
piece of media, don’t use it.
•
Grow your own
- You are always safe if you have created your own media
•
The modification myth
- Many people assume that if you take existing media and change it
“enough” it is yours. This is NOT true. While some guidelines for this
process exist, they are blurred and differ by content, state, and context. To
be safe, NEVER use any media that you do not KNOW you have the
rights to.
•
It’s copyrighted and cannot be used unless it SAYS it can be used
113
- Many people think that you have to apply for a copyright and that if
something doesn’t say it is copyrighted, then it isn’t. This is NOT true. As
soon as you (or anyone) creates something, it is automatically copyrighted.
All copyrights belong to the creator until and only when they specifically
give them away.
•
There is no such thing as “fair use.”
- This is not strictly true, of course, but it is a principle you should adopt to
be safe. What constitutes fair use depends on the context, use, and a
variety of other factors which you don’t have the knowledge to determine
without legal counsel
•
The internet is NOT public domain
- In fact, you should assume that NOTHING is in the public domain. Many
people believe that once you put something on the Internet, it is open for
use by anyone anywhere. Again, the principle stands that if you are not
expressly and specifically granted rights to the content, you CANNOT use
it.
•
“Royalty-free” is not a get out of jail free card
- Creators of content can grant specific kinds of rights and attach conditions
upon the use of the content. Many people assume that the phrase royalty
free means they can do whatever they want.
114
- Some of the rights that can be assigned include:
⇒ The right to copy (but not distribute, modify, sell, or use)
⇒ The right to distribute (but not copy, modify, or sell)
⇒ The right to modify (but not sell, or distribute)
- Some of the conditions which can be imposed include:
⇒ Not being allowed to sell the media itself, but to use the media in a
product that can be sold
⇒ A limit on the number of items used, or copies distributed
⇒ Not being allowed to make any use of the content for commercial
purposes
⇒ Being required to give credit to the creator in any number of ways
If you use collections of “royalty free” media, make sure to read the conditions for its use
carefully. If you do not see specific reference to the type of use you will make of it,
assume it is illegal or get permission in writing from the creator for your specific use. If
you have somebody create media specifically for your use, make sure they sign a release
form that specifically states that they release ALL copyrights to the work in question to
you, including the right to copy, distribute, modify, sell, and repackage the media in any
way you see fit. Keep good records of all such releases and don’t lose them.
Case Study
115
As a beginning doctoral student in instructional design, I took a two-semester sequence in
CBI/CBT using Authorware. I took these classes so early in my studies that I had not had
the instruction design principles courses. As a result, I did not have any experience with
goals and objectives, let alone treatments, storyboards, and the other documents
association with the design and development of CBI/CBT.
My first project was, I thought, fairly modest; I would develop a tutorial on how to use
the PADI dive planner card to plan single and multiple dives. This seemed reasonable in
scope to me, as the dive planner consists of three tables. Because I was new to
instructional design as well as to CBI/CBT, it took me longer than others to develop my
documentation. By the time I got to the storyboards, most other students had already
started developing their projects. While I felt that I could ill afford to take more time on
my storyboards, they were part of the class assignment, so I began developing them.
One week later it was painfully obvious to me that I had too large a project. I had
developed 60 separate storyboards and had only gotten through planning single dives. I
decided to abandon the multiple dives and focused on finishing the storyboards for the
video portion of the project. By the time I had finished my storyboards (87 total), the
other students had been developing their CBI/CBT for three weeks, and more than half of
the quarter was gone. It seemed I had spent too much time in design.
Two weeks later I was done with basic development and ready for troubleshooting;
further along than several other people in the class. If it hadn’t been for some difficulty
with the graphic for the PADI card itself (I had tremendous difficulty making it fit on
screen and still be readable), I would have finished before most others, despite starting
116
three weeks later. This had nothing to do with my abilities (I was a novice) and
everything to do with my goals, objectives, treatment, and storyboards.
My CBI/CBT experiences since have echoed these results, whether working as one of a
team of 12 at a multimedia development company or as an independent contractor. The
time you spend on documentation is more than made up for during development.
Summary
CBI/CBT is expensive and time consuming to develop. Designers need to be certain that
both they and the client know what they’re getting in to and that CBI/CBT is appropriate
for the situation. Once you are committed to developing CBI/CBT, the importance of
good instructional design and careful, conscientious planning and documentation are
critical to the success of CBI/CBT.
The timeline is critical for establishing for the designer and client how long the process is
likely to take. Goals and objectives help ensure that the focus of the project meet the
needs of the client’s situation and minimize the chance of significant revisions based on
misidentification of the content (assuming you get sign-off from the client, as you should
with most documentation). The treatment, white paper, and variable list all serve to force
you to think through the basic design and functionality of your project. The treatment is
also a communication tool for the client to get a view (and approve) the overall approach.
The white paper and variable list not only help when building the overall structure of the
program during development, but also promote consistency as communication vehicles
for the developers.
117
Storyboards are invaluable as planning documents and communication tools for the
designer and client. Changes can be made quickly and painlessly to storyboards, saving
time over making such changes during or after development. Style sheets, quality control,
and media logs all ensure consistency and quality during the development process. All
documentation should be used for formative evaluation wherever possible, as changes to
documents are always faster and cheaper than changes to the CBI/CBT itself.
Working with clients and design/development teams requires special skills and
documentation procedures to ensure good communication and consistency throughout the
project. Your documentation promotes good communication, consistency, formative
evaluation, and can dramatically decrease development and troubleshooting time.
Exercises
1) Design your own storyboard for a project you plan to develop. Consider which
elements will emphasized (scene sketch, text, etc.). Use this storyboard to design a
sample screen for your instruction. How will it work for you? Do you have enough
space for each element? Make revisions as needed.
2) A client has approached you about developing “a multimedia CD-ROM” for sales
training. Describe what steps you would take prior to taking on the job and during
design and development to ensure a successful project. Make specific reference to
documentation and procedures you would use as part of this process.
3) Design your own style sheet, quality control form, and media log forms for a project
you plan to develop. Trade forms with a peer and review each others forms. Make
changes as needed.
4) Develop your goals and objectives, treatment, and white paper for your project. Get
feedback from the client or a peer and make revisions as needed. Pay particular
attention to your treatment; does your client/peer adequately understand what the
project will be? Ask them to describe it back to you in their own words. Ask them
follow-up questions about the project to make sure they understand the aspects they
do not describe back to you initially.
118
Chapter 4: Beginning with Authorware
Overview
Prior to beginning a project, there are several settings and steps you need to address in
Authorware to set the stage for your project. These will be explained in a step-by-step
fashion so that you can follow along with your own project if you desire. We will then
talk about interface design, including metaphor and screen design before moving into an
overview of the Authorware program interface. Finally, we will examine the process and
pitfalls of adding text and graphics to a program, and how to control the pace and flow of
text and graphic elements in Authorware.
Objectives
1) Identify the main elements of the Authorware interface
2) Describe the purpose and function of the basic icons in Authorware
3) Describe the purpose of the toolbox, presentation window, and design window
4) Appropriately modify the properties of an Authorware program prior to beginning
development
5) Create a library for an Authorware program
6) Create and modify Display icons, including importing, creating, and modifying
graphic elements and adding/modifying text
119
7) Use pause and Erase icons to control the flow and presentation of an Authorware
program.
Getting Started with Your Program
You’ll remember from Chapters 2 and 3 that there are a lot of decisions and tasks that
must be accomplished prior to the design of your program. It is the same with the
development phase as well. Decisions about screen size, elements, colors, and file
locations will all impact the development time of your program. The reasons and
procedures for making and implementing these decisions prior to beginning to work on
your program are discussed below.
Keep in mind that much of what you do in Authorware is a reflection of the individual
developer’s preferences for workflow and management. There is always more than one
way to accomplish something in Authorware. As I discuss what you should do to set up
your project in the next few sections, remember that these suggestions are based on my
own preferences, which may not be yours. My preferences are for the most part, however,
based on years of trial and error, and they reflect what I have found to be a streamlined
process that minimizes errors and revisions in the long run.
Setting File Properties
The first place to begin with any Authorware program is with the file properties. These
settings are accessed by selecting the pull-down menu labeled Modify, then selecting the
File sub-menu, and finally the Properties menu. Figures 3 and 4 present the menus and
dialog box for accessing and setting the file properties.
120
Figure 3. Accessing the file properties dialog box.
Figure 4. File properties dialog box.
Heads Up: For the sake of brevity, whenever menu commands are discussed the
following convention will be used. The path through the menu and sub-menus will be
presented in the order they are selected with arrows in between. In addition, menu names
121
will always be capitalized. For example, the menu sequence for accessing the File
Properties dialog box described above would be written ModifyFileProperties.
It is important to note one of Authorware’s interface conventions here. At first glance, it
might appear that there are 12 options that can be set in this dialog box. Closer
examination reveals that what we are looking at is actually only the options for the
Playback tab; there are also tabs for Interaction and CMI. The settings for the Interaction
tab allow you more advanced control over your program and will be discussed in more
detail in Chapter 10. The CMI tab controls how your program interacts with knowledge
tracking and management systems and will not be discussed in this book.
The first window at the top of the dialog box contains the name of your file. There are
several options immediately below that window that bear some discussion. Note that
many of these options are not immediately required when you are just beginning to learn
Authorware. Accordingly, many of these will not be discussed until Chapter 10. If you
are already familiar with Authorware or are beginning what you feel may be an advanced
program, you may want to read ahead to see if you will need to modify any of those
advanced settings.
Background Color
As you might suspect, this option sets the default color for all of your program screens.
You can modify this setting by clicking once on the square (which is white by default)
and selecting a new color from the palette that appears. Note that you are using the
Windows system palette here, so if your intention is to create a cross-platform piece or to
122
use a custom palette, you need to choose your colors carefully (see Chapter 2 for more on
system colors and cross-platform considerations).
You can always choose a background color later, of course, and you may elect to use an
image for your background (this will be discussed later—it is not done through the file
properties dialog box), but it is often helpful to select a non-white color here so that your
file doesn’t have that “blank page” look.
Tip: Setting your background color to black allows you to create “fade-to-black” and
“fade-from-black” effects which are familiar to us from movies. When we discuss
transitions and Erase icons later, you will learn about dissolves. Dissolves cause the
screen to fade in or out. The catch is that they fade to or from whatever color you have
chosen as your default color. Black has the advantage of creating nice transitions AND
being completely cross-platform.
Size
This option is the first critical option you MUST set prior to beginning your piece. If you
have not determined your target platform characteristics, now is a good time to do so.
Your target platform is the minimum required computing setup your end-users must have
in order to run your program. If you have ever purchased a computer game, look at the
System Requirements section on the box; they represent the target platform. OS,
processor, RAM, hard drive, video and sound requirements, and CD speed are the most
common elements of the target platform. The target platform is not just helpful
information provided to the end user as a service; they are also your means of ensuring
that the system you are developing and testing on is what the end user will be using. This
123
can be critical when developing for an outside client, as their organizations may have tens
or hundreds of different machines with different characteristics. Your target platform is
your contract with the end user or client that you only guarantee the program to run on
machines that meet the minimum requirements.
Once you have specified your target platform, you can use the video specifications to
help determine your screen size. In principle, you want to use the highest resolution
supported by your target platform in order to give you the most screen room to work
with. As with all such decisions, there are trade-offs, however. Higher resolutions mean
fewer people can use the program. If you are sure of your target platform and that you
will not be likely to re-purpose the content for others later, this may not be an issue.
Higher resolutions also mean that text and graphics will be smaller (they take up less
room at higher resolutions), which may make them harder to see or read.
Computers sold today commonly support resolutions in excess of 1024 x 768, so you are
probably safe selecting 800 x 600 as a resolution. To do this, click once on the drop down
menu for size and select 800 x 600. You will probably have noticed that there are several
resolutions to choose from including one called Use Full Screen. This last selection does
what it implies: it attempts to use the full screen resolution on the target computer
regardless of what resolution the monitor is set to. While it is tempting to just select this
option, doing so can cause unpredictable (and undesirable!) results. The only way to be
sure that your program meets the target platform specifications is to develop for them
specifically. This means choosing a specific screen resolution.
124
The reason it is so important to set this prior to beginning your program is illustrated by
the following scenario. Let’s say you left your screen setting at the default 640 x 480.
You have titles placed in the upper left corner of the screen, navigation buttons in the
bottom corner, and the quit menu in the lower left corner of the screen. These positions
are based on the assumption that there are 640 pixels from left to right across the screen
and 480 pixels from top to bottom. You then decide that you need more screen space, and
so set the size to 800 x 600. Because there are now 800 (160 more) pixels from left to
right across the screen and 600 (200 more) pixels from top to bottom, what was the upper
left corner of the screen is now 80 pixels in and 100 pixels down from the upper left
corner of the screen. The same is true for the rest of the screen. You must now physically
move every object on every screen of the entire program to the “new” corners of the
screen. The opposite is true when switching from higher to lower resolution, except that
now what fit nicely on the screen is suddenly too large for the new (lower) resolution.
Power Tip: Knowing this about resolution, you may be able to extrapolate to the
situation where your end user plays your program back at a higher or lower resolution
than you specified. Either your program will take up less of the screen than is available
(allowing the user to see your program and to see their desktop at the same time) or will
be too big for the screen (controls and screen elements will be inaccessible because they
are off screen). To avoid this, you can use the ScreenWidth, ScreenHeight, and or
ScreenDepth variables to have your program check the user’s settings prior to running the
piece. If they do not have the correct settings, you can prompt them to quit and make the
appropriate modifications. See Chapter 11 for more on variables.
Screen Placement
125
Screen placement goes hand in hand with resolution. In the above example where the
user plays the program back at a higher resolution than it was developed for, the program
does not take up all the space on the monitor. Screen placement allows you to specify
where the program should appear in such cases. By setting the screen placement to
“center on screen,” you can ensure that regardless of the resolution, the user will see your
program in the middle of the screen at all times.
Title Bar
The checkbox for the title bar determines whether the end user will see your program in a
window or by itself. Leaving this option checked (the default) means that the end user
will always see the title bar of the window your program runs in. Some people feel that
this detracts from the immersiveness of the experience. More importantly, the title bar
takes up space on the screen. If you have your resolution set to 800 x 600, and leave the
title bar on, you actually have 800 by approximately 580, because the title bar is 20 pixels
tall (about 1/4 inch).
While this may not seem like much space to be concerned about, there is one caveat; if
you design your program for that space and then decide later that you don’t want the title
bar, you will now have a 20 pixel blank space at the top of your screen (no images behind
it, no text or objects in that space, etc.). Unless you are sure you want the title bar, I
recommend you leave it off and try not to put anything critical (buttons, etc.) in the top
20 pixels of the screen. That way, if you decide to add the title bar later, it will just cover
up the top 20 pixels; if nothing critical will be covered up, you won’t have to make any
modifications.
126
Menu Bar
The menu bar is just that, the bar at the top of your screen that contains menus. By
default, all Authorware programs display a menu bar with the menu “File” in them. If
your program does not make specific use of pull-down menus, you should elect to turn
off the menu bar. If your program uses any menus at all, you must have the menu bar
turned on, or the end user will never see your menus.
Building Font Styles
This is the most critical step and the most often over-looked. I cannot emphasize the
importance of setting your font styles enough. You may remember from chapters 2 and 3
that failure to set font styles and use them consistently results in, at best, a multitude of
useless font styles that can cause programming bugs and glitches, and at worst can set
your program back days or weeks if you find you must change your fonts later.
To understand why this is so, keep in mind that an average program can contain two to
three thousand different icons. Because most instruction is predominantly made up of text
and graphics (at least 50-75% in my estimation), the majority of these icons will be
Display icons (icons used to display text and graphics). Let’s say you type each piece of
text and format it using the font, size, and style options individually (which you can do)
instead of font styles. Doing so will cause Authorware to create new styles each time you
make a change to a font, size, or style option. You then decide during your one-to-one
evaluations that the font you chose is not as readable as you would like, and you want to
change your font. If you go now to your font styles dialog box, you will see lots (50 to
100 is not uncommon) of font styles, each of which is named things like “Times 12,” or
127
whatever Authorware chose for it. You have no idea which of these fonts apply to which
parts of your screen (are the titles, body text, captions?), so you have not way of know
which ones to change. Instead, you would have to open up every single one of those
Display icons (some of which will be nested 2 or more levels deep), select each piece of
text with the text tool, and apply the font change one at a time. In contrast, if you used
styles, you would open up the style dialog box, change the style one time, and apply it to
the entire file. Fortunately, setting your styles is relatively easy to do. Open the define
styles dialog box by clicking TextDefine Styles. The dialog box will appear (see Figure
5).
Figure 5. Define styles dialog box.
You will automatically see one style called “(Default Style).” To add a new style, click
the Add button. The default name of your style, New Style, will appear in the window
immediately above the Add button. Name the style (e.g., body text, title main, etc.)
128
according to your style sheet by selecting the text and typing in the new name. Once you
have done that, set the style characteristics using the check box options in the middle of
the dialog box. Note that you MUST place a check mark by any attribute that you want to
have applied to your style. It is a good idea to set these options in the order they appear,
from top down (e.g., font, size, bold, italic, etc.). Check the box next to the font menu
(top of the middle column) and select the font you want to use. You will only be able to
choose fonts that are installed on your system.
Heads Up: Keep in mind that not all fonts you have will be available to the end user of
your program, and that not all fonts are available on all platforms.
Next, check the box next to the size menu and choose the size you want for this style. A
preview of your choices will appear in the box in the upper right corner of the dialog box.
You will have to select “Other” to see the full range of choices. Continue setting your
options in a similar fashion by working your way down the middle of this dialog box.
When you get to the color option, you will need to click on the colored area to pull up the
color palette choices (see Figure 6).
129
Figure 6. Color palette for setting font styles.
Heads Up: This palette is subject to the same color palette restrictions discussed in the
previous chapters. If you have created a custom palette for your piece and loaded it, this
palette will reflect that.
Tip: It is a good idea to assign a color to all your font styles, even if you are taking the
default black. This is because you may want to base some styles on others but use a
different color. A common example is when you want to emphasize your text by placing
a “shadow” under it as described in Chapter 2. In such cases it is common to set a style
that uses a light colored text for the main text (the part that is in the “light” above the
background) and to create a new style based on that style, but which is black (i.e., is the
shadow cast by the text above it). If you create a style and include the color name when
you name the style (e.g., body text black) you will find it easier later to keep track of the
different versions and styles that you use.
Heads Up: The section to the right labeled “interactivity” will be covered later in
Chapter 7 as a specific kind of navigation option. For now, just think of this section as the
way you add “hot text” to your file. Hot text allows you to click on a word or phrase and
have the program perform an action such as going to another place in the program.
130
Tip: You can modify your styles later by going through the same process, except you
simply select the style you want to change, change your options, hit the Modify button,
and then the “Done” button. Authorware will then go through every icon in your file and
change every instance of that style automatically.
Once you are done setting the options for your font style, you must hit the “Modify”
button, or none of your changes will be saved. This will move the named style you just
created up into the window under [Default Style]. You can then hit the “Done” button to
exit the dialog box.
Color Palette
As mentioned in Chapter 2, the Windows and Macintosh operating systems display
colors differently. Authorware’s default palette does a good job of mimicking the colors
on the Macintosh OS, with the exception of 20 colors. These 20 colors are reserved for
the Windows OS so that Authorware’s interface (buttons, scroll bars, window titles, etc.)
appear correctly. Unfortunately, that means that if you select them, they may not show up
correctly when your program is played back on the Macintosh OS. To ensure that your
colors will appear on both platforms correctly, you need to tell Authorware not to include
these 20 colors in its palette. To do this, go to ModifyFilePalette and uncheck the
box that says “preserve system colors.” Authorware will then ‘abandon’ the system
colors so that your color palette is virtually identical to that of the Macintosh OS.
There is one unfortunate cosmetic side effect to doing this, however. Because the
Windows system colors are no longer part of your palette, Authorware’s windows,
scrollbars, and other interface elements will not display correctly (in my experience, they
131
turn pink and yellow, although it is possible that this may vary from computer to
computer). This problem affects the entire Windows interface when you have your
monitor set to 256 colors, and you have the Authorware window open (colors display
normally when Authorware is minimized or not running). To avoid it you need only set
your monitor to 16-bit color or higher.
Heads Up: Since this problem affects the Windows interface components themselves,
this includes the title bar, menu bar, scroll bars, and buttons in your packaged piece as
well. If your final program makes use of these elements, they will not display correctly if
the end user’s has their monitor set to 256 colors. There are several options to avoid this.
You can avoid using menu bars, title bars, and scroll bars, and you can use custom
buttons instead of the system defaults. In this case, you should also make sure your
program resolution is the same as the end users. If your program runs at a lower
resolution than that of the end user’s monitor, they will be able to see the desktop in the
background, and it will be affected by the color change. If you need to use these
elements, you can use functions and variables to verify the end user’s color configuration
and change it or request them to change it prior starting the program. You can create a
custom palette (Chapter 10) that contains the colors you need and preserve system colors.
Adding Text & Shapes
Much of what your instructional product will do is present text and or images in prespecified sequences. In both cases, you need to use a Display icon. Adding text is
accomplished by dragging a Display icon onto the flowline and running the piece
(ControlRestart). When Authorware hits this empty Display icon, it will stop, open up
132
the Display icon (shift into authoring mode), allow you to type or import graphics, and
wait for you to close the window (by clicking on the “x” at the upper left of your tool
palette), at which point it will continue on in the program as normal.
Heads Up: There is a very important rule concerning Display icons that will impact your
ability to erase, animate, and to create drag & drop interactions. Anything that you want
to control by itself (erase, animate, drag, etc.) must appear in its own Display icon. For
example, if you want to erase the title of your presentation, the title must be in its own
Display icon with nothing else. This is because Authorware erases everything inside a
given Display icon. If you were to put the title in a Display icon along with some credits,
you would be forced to erase both the title and the credits. Beginning programmers have
trouble with this concept because they tend to build screens (what the user sees) all
together in one Display icon, making it impossible to erase or animate just one part of
that screen.
The Toolbox
Text (and drawings and shapes) are added to a Display icon through the use of the tool
palette (see figure 8). Taken in order from left to right and top to bottom, there are 8 tools
in the tool palette. The first tool, with the arrow, is your default cursor tool. This is used
for clicking on objects (such as text objects or graphics) already created inside your
Display icon and moving them from place to place. You can use this tool to drag any
object on your screen, including text, graphics or shapes you have drawn.
133
Figure 8. Tool Palette for editing Display icons when in authoring mode.
TIP: The name of the tool palette is derived from the name of the Display icon currently
being edited. When you first drag any icon to the flowline, Authorware immediately
names it “untitled.” This is not very helpful for remembering what you want to type or
place inside this icon, however! The first thing YOU should do after you drag the icon to
its place is to name it for what it is. If you have set up branch points in your storyboards,
you can use those to name your icons. But you should also probably include enough in
the title of the icon to jog your memory for what should appear there. If you build good
habits with this from the beginning you will find you spend much less time in the
authoring, troubleshooting, and fine-tuning stages later.
The second tool is the text tool (A). The vast majority of your time inside Display icons
will be spent using the arrow pointer or your text tool. We will discuss this tool in its own
section momentarily, as it is more complex than the other tools.
The other remaining tools are used to draw lines or shapes. The cross hairs (+) allows you
to draw perfectly straight lines up and down or across. The line tool draws straight lines
in any direction (you can force it to draw perfect 45 or 90 degree lines by holding the
shift key down). Starting at the left of the bottom row of tools, the circle/oval allows you
to draw circles and ovals; the square/rectangle allows you to draw squares and rectangles;
and the rounded corner square/rectangle allows you to draw rounded corner squares and
134
rectangles. The last tool allows you to draw irregular shapes by clicking each time you
want to “anchor” the line and “stretching” each line to the desired length and position.
When you are done and want to “close” the shape, you double-click on the desired end
point.
Adding Text/Text Tool
The text tool (A) is used to add text to your screen or make modifications to text you
have already created. In both cases, the first step is to click the text tool, then click on a
blank area of the screen (to type text) or inside some text you have already created (to
edit it).
Power Tip: While any amount of text can be added to your program in the fashion
mentioned above, Authorware has a unique, powerful feature for adding large amounts of
text to your program. This technique requires the use of a framework, which will not be
covered until chapter 7, and it is best suited for use when you have multiple pages of text
that you want to appear in the same place on your screen. If you add a framework to your
flowline, drag one Display icon to the framework, open it, select FileImport and point
to a word processed file (e.g., Microsoft Word) that has been saved as Rich Text Format
(rtf), Authorware will bring in all the text. You have the choice of telling Authorware to
add a new Display icon for every page of text or to ignore page breaks and bring the file
in as one text object. Authorware looks for hard page breaks (those that you insert
manually in your word processor) to determine when a new page starts.
135
Once you begin typing using the text tool, or when you click on an existing text object
using the text tool, you will see a line across the top of your text object with two squares
and three triangles on it (see Figure 10).
Figure 10. Indentation and Tab Markers of a Text Object.
The white squares at the outer limits of the line represent the text object handles used to
determine how big your text box is. You drag these as you would the object handles
described earlier in this chapter to re-size the object. When you drag these, the size of the
entire text object is changed. They are roughly equivalent to the left and right edges of a
page in a word processor.
The triangles allow you rudimentary control of your indents within your text object, and
are roughly equivalent to the margins in a word processor. When you drag these, you
change how much space within your text object can be occupied by text. For instance, if
you drag the solid triangle at the right end of the line toward the middle, you are telling
Authorware that the text object should remain the same size, but that you want the text
within that object to wrap around to the next line before it hits the edge of the text object
(e.g., you are setting the right margin of your document). Likewise, when you drag the
bottom triangle on the left in toward the center, you are telling Authorware to start the
text a certain distance in from the edge of your text object (e.g., you are setting the left
margin).
136
When you drag the top triangle on the left in toward the center, you are setting your first
line indent (e.g., you want to indent the first line of every paragraph). No matter which
triangle you move, the change will only be applied to the current paragraph, NOT the
entire text object, so if you have more than one paragraph (i.e., you have typed text and
hit the return key at least once) and you want to change the indentations of all paragraphs
in my text object, you have to first select all the paragraphs and then adjust the indents
(triangles).
You can set tabs in your text document by selecting the appropriate paragraph(s) and
clicking once on top of the line. When you do so, another triangle will appear, this time
pointing down toward your text. This represents a left tab, meaning that when you hit the
tab character, the text you then type will start at a point in line with that triangle and
continue as normal toward the right side of your text object. If you click on that triangle
one more time, it will change to an arrow pointing down. This represents a right tab,
meaning that when you hit the tab character, the text you then type will start at a point in
line with that arrow but then continue toward the left toward the left margin of your text
object as you type.
Tip: If you need to align text within your text object (e.g., an indented section of text, or
a list), you must use the procedure outlined above. If you attempt to line things up using
the space bar, you will never get things perfectly aligned, and it will show. Even in the
rare cases where you can get it to look ok, any change in font size, font type, or size of
the text object will completely alter your alignment.
Font Styles
137
Once you have typed text (or imported it from a word-processed file), you then need to
assign a font style to it. This will ensure that you do not inadvertently change fonts or
sizes from one screen to the next and, more importantly, that should you wish to make a
change (to another font, size, color, etc.) you can do so in one step and have it applied to
the entire file. When you begin typing using the text tool, Authorware automatically
assigns a style called “default” to the text. Font styles can be applied to text in one of two
ways. There is a drop-down menu in your toolbar at the top of the screen which, when
accessed, provides a list of available font styles from which you can select. Alternatively,
you can go to TextApply Styles and a window will pop up listing all available styles
along with check boxes to the left of each style name. Clicking on the check box to the
left of a style will apply it. In both cases, you must first have selected the text to which
you want the style applied.
Tip: I recommend the latter method of applying styles for two reasons. First, when using
the drop-down menu to apply styles, it is often difficult to scroll through the available
styles. In earlier versions of Authorware, some styles would not show up through this
method (this bug appears to have been addressed in Authorware 7). Secondly, it is
possible to accidentally assign more than one style to a piece of text during the course of
developing your program. In such cases, the drop down menu will show a blank instead
of the styles (since it can only display one style name at a time). Using the Apply Styles
window ensures that in such cases you will be able to see that more than one style has
been applied by looking at the check boxes.
Scrolling vs. Non-Scrolling
138
Sometimes you may have too much text to fit in the space you have set aside in your
interface on a given screen. If you cannot solve this through editing or breaking the text
up into two screens, it is possible to have the text display with a scrollbar to allow the
learner to scroll through the text. This is accomplished by selecting “scrolling” from the
text menu (TextScrolling). In general, I do not recommend using scrolling text for
three reasons. First, it may make the text difficult to access for learners with motor
impairments (scroll bars require fine motor skills). Second, learners generally don’t like
scroll bars for the same reasons and because they interrupt the flow and may “interrupt”
the interface metaphor. Thirdly, if you have too much text for one screen, you either have
not allowed enough space in your interface for text elements or you have too much text
for learners to easily attend to and process. It is worth a second thought in any case before
you add scrolling text.
Anti-Aliasing
Although most items on the Text menu are self-explanatory and their function easily
intuited, some readers may not be familiar with the term anti-aliasing. When text is drawn
on a computer screen, it is made up of tiny, individual squares of color (pixels). Because
of this, any part of a letter that is curved is actually made up of solid squares arranged in a
curved pattern. While this pattern looks like a curve from a distance, it appears to be
“jagged” when viewed up close or when the text is large. Anti-aliasing is a technique that
uses squares of color at different shades and intensities to create a smoother appearance.
Figure 9 presents a close look at text with and without anti-aliasing. Notice in particular
the lines of the W, A, and s. This effect is more pronounced at larger sizes and in some
fonts (e.g., courier) more than others.
139
Figure 9. Text with and without anti-aliasing.
To make your text anti-aliased, you select or highlight the text object, then go to
TextAntialiased. Unfortunately, there is currently no way to build this into your font
styles, so you must apply it one at a time (are you listening, Macromedia?).
The RTF Objects Editor
At the risk of getting somewhat ahead of ourselves, a brief mention of another means of
creating and editing text, the RTF Objects Editor, is appropriate here. Note that in order
to make use of the RTF Objects editor, you must first use the RTF Knowledge Object,
and knowledge objects will not be covered until Chapter 9. Nevertheless, it is relevant to
our discussion now.
The RTF Objects Editor represents one of the most significant and long-awaited upgrades
in Authorware 7. Up until Authorware 7, it was only possible to make rudimentary edits
to your text (e.g., bold, italic, underline, size, alignment, and font). Bullets and numbering
were not possible, spell check was only possible by searching through the entire program
one icon at a time. Tabs, while technically supported, were almost impossible to
implement in practice.
The Rich Text Editor in Authorware 7 changes all that. While not a true word-processor
in its own right, it nevertheless comes very close by incorporating almost all the features
140
you really need to create and edit basic word-processed documents. The RTF Objects
Editor will look very familiar to users of Microsoft Word Pad or Word. The RTF Objects
Editor gives you access to traditional word-processor options such as font, size,
paragraph, line-spacing, alignment, tabs, super-/sub-script, bullets and numbering,
inserting images and fields, search and replace, spell-check, and even limited database
connectivity.
Importing Graphics
Before we discuss importing graphics, you need to understand the difference between
internal and external storage of media. In Authorware, you can store a graphics internally
or externally. If graphics are located internally, you will have fewer files to keep track of
since each object will become an actual part of the program. This also means that your
program will be larger in size. If you store them externally, the program will be smaller,
but you will have to distribute each piece of media with your final program, which means
you will have to keep good track of each file. Storing media externally tells Authorware
to simply make a reference, or pointer, to the file. When it comes time for the media to be
displayed or played in the program, Authorware will go to the place you tell it the media
and play that file.
The best way to make this decision is to ask yourself if you will need to make frequent
changes to the media themselves, both during the development AND after it has been
distributed to the client. If you expect to frequently edit the files based on client feedback
and formative evaluation, you may want to store the media externally. That way, you can
simply open the sound or image in the program of your choice, make your changes, and
141
your Authorware program will display the new version automatically (as long as it is still
named the same thing and located in the same place). Also, if you expect the content to
change after you deliver it the client, storing your media externally will allow you to edit
the media and send only the media to the client.
Luckily, Authorware stores all media internally by default, which is the best option to use
when you are first learning Authorware. I say luckily both because it makes it easier for
beginners and because you can actually export your media later if you change your mind.
These procedures will be discussed in more detail later in Chapter 10. If you are unsure at
this stage whether your media will be stored externally, or if you are just learning
Authorware, store your media internally. If you know that you want to store your media
externally, you must specify this every time you import media.
Once you have decided how to store your graphics, the process of importing them is quite
simple. Again, you drag a Display icon over to the flowline, run the program, and wait
for Authorware to shift into authoring mode. You can then select the FileImport
command, select the file you want to import, and Authorware will bring the file into the
Display icon you have open. You can then use the arrow tool to position the graphic or
resize it by dragging the “handles” at the corners and on the sides (handles are gray-black
squares that show up once you have selected the object).
Power Tip: You can import multiple graphics files in a single step by selecting the
graphics files you want from the disk they reside on and dragging them onto your
flowline in Authorware. Authorware will automatically create a new Display icon for
each graphic, place the graphic in the Display icon, and name each icon exactly what the
142
graphic file is called. In order to do this, you must resize the Authorware window so that
you can still see the desired location on the flowline and arrange your screen so you can
see both the Authorware window and the window that contains the graphics files you
want to bring in. Note that you can do this with sound and movie files as well. This is an
excellent way to quickly build a library for your program. We will discuss libraries later
in this chapter.
Aligning Objects
Aligning Objects Within icons
Once you have brought in your graphics and created your text objects in a Display icon, it
is often the case that you need to align them. You cannot really eyeball this; it will drive
you crazy over a long period of time. Fortunately, Authorware provides an easy solution.
If you first select all the objects you want to line up, you can then select ModifyAlign
to bring up the following window:
At first glance, this does not seem very intuitive, but there is a logic to the display.
Clicking the different squares will, from left to right, top to bottom, align the selected
objects by left edge, top edge, vertical center, horizontal center, right edge, bottom edge,
143
equalize the horizontal space between them, or equalize the vertical space between them.
You can apply as many or as few of them in a row as you like.
Aligning Object Between icons
Aligning objects between icons is a little less straightforward but manageable if you have
adopted the approach to authoring I suggest (build it first, fill it in later). The reason it is
harder to align objects between icons is that doing so requires that you be able to see
what is in both/all icons at the same time. Yet when you open up an individual icon, you
can only see what is inside that icon.
There are two solutions to this dilemma. The first, and preferred, solution is to add icons
to the flowline that you will fill in as you run the program. That way, you can see
everything on the screen from before as you add and adjust the contents of the new
Display icon. This is true even when you decide to add one or more elements to a part of
the program that you have already set up in this manner; simply drag an empty Display
icon to the flowline where you want the new element to appear, run the program, and
create the new element(s) when Authorware stops at the empty icon. You will be able to
see everything that has come on screen up to that point.
Tip: Filling in content as you go by running the program is the preferred method for
working in Authorware. The problem is that once your program begins to get larger, it
may not be practical to wait for the entire program to run each time. In order to run just
the part of your program you are currently working on, you can use the Start and Stop
Flags. These are located at the bottom of your tool bar; the white flag is the start flag, and
the black flag is the stop flag. Drag the white flag to the point in your program that you
144
want Authorware to start at for now, and drag the black flag to the point in your program
that you want Authorware to stop for now. You can then hit run button (which now
contains a picture of the white flag) or use the menu (ControlRestart from Flag) to run
only the part of your program between the start and the stop flag.
There is another method of seeing what has come before while you edit another icon. If
you open up one icon, close it, and then hold the shift key down while you open another
icon, you will be able to see the contents of the first icon while you are inside the second
icon. There is no practical limit to how many icons you view at once using this method,
and there are occasions when it may be necessary to use it.
In many cases, you may not need to worry about seeing the contents of earlier Display
icons. If you have created spaces for text, titles, and graphics in your interface, then
placing these items is just a matter of lining up the object with the space you have
created.
Tip: You can use the arrow keys on your keyboard to “nudge” text and graphic objects in
a Display icon one pixel at a time to make precise adjustments.
Inspectors
When you create graphic shapes or lines in Authorware, the default color is black on
white, and all lines are the same size. This is rarely the desired result for all graphics in
your piece. To change these properties, you must use what Authorware calls Inspectors.
There are four Inspectors: Lines, Fills, Modes, and Colors. Each are accessed through
WindowInspectors, and each brings up its own window. Lines brings up a window that
145
lets you choose from a variety of dashed, dotted, and arrow-head lines in differing
thicknesses. These can only be applied to lines and shapes you have drawn in Authorware
using the tool palette. Fills brings up a window that lets you select from among several
different patterns to have inside shapes you have drawn. Fills do not affect color or lines.
Modes and colors are probably the two most frequently accessed inspectors, and require a
more lengthy discussion.
Modes
There are four different modes to choose from; Opaque, Matted, Transparent, Inverse,
Erase, and Alpha. These modes can be applied to any object or graphic in Authorware,
whether created with the tool palette or imported from an outside file. The modes
determine how that object is displayed when it overlaps (or is overlapped by) another
object on the screen. Opaque means the object will obscure whatever it overlaps. Erase
attempts1 to set the object color to the same as the background color you specified for
Authorware. Objects set to Erase will block out any object underneath them, making it
look like part of them has been erased. Inverse will set the color of the object to the
inverse of whatever is underneath it (try it to see what I mean). Alpha allows the object to
retain its color attributes but become transparent so that we can see through it to some
extent. This works only with 24-bit images created in a program like Photoshop or
Fireworks in which you can specify an alpha channel.
1
I say attempts, because in the case of graphic images you have imported, it
cannot do so perfectly. This mode is primarily intended for shapes you have drawn in
Authorware.
146
You may have noticed that I skipped Matted and Transparent modes. This is because they
are harder to understand from their names. Transparent mode actually means that only the
parts of the graphic, picture, or text that are pure white will become invisible (not
transparent, like Alpha), leaving only the non-white colors visible. This is particularly
useful for clip art, which often comes as an image on a white square background. A less
obvious use for it is with text. As you will see in the next section, text has a color for the
letters themselves AND for the background of the letters (the text object). By default, all
text objects have a background of white. This creates a problem when your program uses
other colors. Making your text box transparent allows only the letters themselves to show
up, with any colors or images underneath them being allowed to show through.
Matted, on the other hand, functions in the same way as transparent, with the following
exception: any white color that is surrounded by another color will stay white. For
example, if I had a picture of a snowman on a white background and I set it to Matted,
the white background would become invisible while the snowman himself would stay
white (because he is comprised of three circles of white with black lines surrounding the
white).
Tip: Transparent and Matted only work with pure white. One of the most common
problems people have with these modes is that a graphic will appear to be eye to be
white, but is in reality not pure white, resulting in these impure white areas to remain
visible despite setting the graphic to transparent. Pure white is defined as having a value
of 255 for the Red, Green, and Blue channels. You can set this within your graphic
editing program. If it is off by even 1 number (e.g., 254, 255, 255) Authorware will not
be able to make the white transparent.
147
Colors
We’ve already discussed how to specify colors for your text when you define your font
styles, and that is the only way you should modify text color in your program. If you
want to change the color later, you need only go to TextDefine Styles and modify the
color for the desired font style to change every text object in your program to which you
assigned that font style.
The Color Inspector (WindowsInspectorsColors) allows you to specify the colors of
any drawn graphic in your program. Remember that drawn graphics are those you create
with the tool palette. You cannot use the color inspector to make changes to images or
graphics you have imported into your program from outside Authorware. Figure 11
presents the Color Inspector window.
Figure 11. Color Inspector Window.
As with all such modifications, the first step in changing color is to select the object you
want to modify. Color changes are effected by clicking on the square containing the color
you want.
148
Heads Up: You may remember from Chapter 2 that your color palette and system colors
depend upon the OS you are developing on, the platform you are developing for, and
whether or not you use a custom palette. The Color Inspector will display the default
color palette for the OS you are on unless you have loaded a custom palette (see Chapter
10 for more on this).
There are three aspects of color change in the Color Inspector. Underneath the color
palette in the inspector, you will see a pencil, an A, and a color square at the left and a
paint bucket with two overlapping squares at the right. Clicking on one of the three
squares tells Authorware what aspect of the current object to which you want to apply the
color. The pencil/A square color will tell Authorware to apply the color change to a text
object. Since you should always use font styles to change text color, you do not need to
use this element; the minute you change the color of text using the color inspector, you
have created a new style, and changing it back will not undo this. The two squares next to
the paint bucket control the color of lines (top box) and fills (bottom box).
The lines color box will affect lines of drawn objects as well as plain lines. For instance,
if you draw a square (or select a square you have previously drawn), click once on the top
box next to the paint bucket, and select pink, the line around that box will turn pink, but
the inside of the box will remain whatever color it was when you drew it. If you then
click once on the lower box and choose pink, the inside of that box will turn pink.
The lower/fills box can also be used to change the background color of a text object (e.g.,
so that your text appears on top of a blue background rather than white or transparent).
149
Changing the background color of a text object does not affect your styles, and is the only
color change you should make to a text object using the color inspector.
Controlling the Flow
Once you have built several screens to display to the learner, you need specify how and
when they should be displayed. By default, Authorware displays everything it finds on
the flowline one on top of the other as fast as the computer is capable of, and leaves them
on the screen until it is told specifically to remove them. Computers are so fast that if you
were to create five different screens in a row (e.g., five Display icons) and run the
program, you would only see the last one, since the computer will have shown the first
four faster than you can see, and each is covered up by the one before.
Tip: You should get in the habit of thinking in terms of screens, and not of Display icons,
as they are not necessarily related in a one-to-one fashion. A screen is defined from the
learner’s perspective, not the programmer’s perspective. For example, imagine a screen
in which some background music begins to play, a title glides in from the bottom of the
screen, pauses, then disappears to be replaced by a graphic in the center of the screen, and
the learner is presented with a voice over telling them to click the forward button when
they are ready to proceed. To the learner, this is one screen, but to build this screen the
programmer must use eight different icons. This is another area in which storyboards play
a role, since they correspond to screens in a one-to-one fashion.
In order to control how each object on a given screen is displayed, and to determine how
your program will progress from screen to screen, you use transitions and pauses. In
Authorware, transitions are controlled by modifying the properties of Display icons and
150
by using Erase icons. Pauses are controlled by Wait icons. Each technique is described
below.
Setting Transitions
Transitions are what happen between one Display icon and the next on screen; objects
appear and disappear on screen according to transitions. To control the way objects in a
Display icon appear on screen, you set the transition for the Display icon through
ModifyiconTransition. This will produce a window in which you can select from a
series of transitions. You can set the duration of the transition (how long it takes) and the
smoothness of the transition. The higher the smoothness, the better it will look but the
more processing power it takes (video card and computer processor). You can experiment
with each to see how they work by hitting the Apply button to preview the transition you
have selected. Keep in mind that these transitions control only how the Display icon
appears, not how it will disappear.
Heads Up: By default, Authorware pre-selects [internal] transitions. These are transitions
that are built in to the Authorware runtime engine and do not require external files (called
Xtras) to run. If you choose any of the other types in the left hand window, you will need
to distribute the Xtras that control that transition, or your transitions will not work.
Luckily, Authorware 7 makes this much easier to do. You can read more about this in
chapter 8.
The other type of transition occurs when you want the contents of a Display icon to
disappear (as opposed to specifying how another Display icon appears). These kinds of
transitions are accomplished by using Erase icons. Remember that everything that shows
151
up on the screen will remain there until it is specifically erased using an Erase icon. This
is true even when the contents of one Display icon appear over the contents of another
and cover it up. You may no longer see the earlier objects, but they are still there. It is not
uncommon to discover this late in the program when you erase something on screen only
to suddenly find an object from the beginning part of the program.
Erasing objects is accomplished placing an Erase icon on the flowline at the point at
which you want to erase the contents of a Display icon. Although the Display icon you
want to erase must have come prior to the Erase icon, it is not necessary to place the
Erase icon immediately after the object you want to erase. In fact, you could place an
Erase icon at the end of the program and tell it to erase the first icon in the program. You
may recall from the first part of this chapter that the your success in creating an
Authorware program is largely determined by the method you use to develop it. Novices
tend to want to place icons on the flowline one at a time and make all of their changes to
that icon before moving on. This process increases the number of actions you have to
take for each icon by at least a factor of three and makes it very difficult to position
different elements on screen (i.e., to line up the contents of one Display icon in relation to
another).
If, instead, you place all the icons you need for one screen (see the earlier definition of a
screen) on the flowline, name them for what they will contain, and then run the program,
Authorware will pause at each icon; open it for you; allow you to draw, type, or import
graphics; position them on screen; and continue to the next icon once you close the
screen (by clicking the ‘x’ in the corner of your tool palette). Not only will this require
152
fewer steps, but you will be able to see the image/text/graphic you placed in your first
Display icon while you are creating your second (or third, or fourth, etc.).
This technique will also simplify the use of Erase icons. Let’s say that you have created
an introductory screen with a title, an animated set of credits that appear while the title is
on screen, and a logo that fades in at the top left of the screen. Now you decide that you
want to erase the title text you placed in the first Display icon and the credits you placed
in the second Display icon.2 You can simply place the Erase icon at the end of the
introduction (which is when you want the title and credits to be erased), run the program
to watch your introduction, and wait for Authorware to hit the new Erase icon, at which
point, (all together now:) Authorware stops and opens the Erase icon, presenting you with
the window seen in Figure 12.
Figure 12. The erase window dialog box.
2
They are in separate Display icons because you remembered reading the Heads
Up in this chapter regarding controlling individually screen elements.
153
At this point you can simply take your mouse and click once on the element(s) (text,
graphic, image) you want to erase, and it will be erased. One Erase icon can erase an
unlimited number of Display icons. If you click on the button to the right of the
transition: menu, you can select from the same transitions that you have when you are
setting entry transitions for a Display icon. The “Prevent Cross Fade” check box specifies
whether Authorware should erase the contents entirely before displaying whatever comes
after the Erase icon or not. Keep in mind that many times you will be erasing one (or
more) Display icons prior to having another Display icon transition in. In this case, what
you are erasing transitions out before (“Prevent Cross Fade” is checked) or during
(“Prevent Cross Fade” is un-checked) the transition of the next Display icon. When you
are satisfied, you simply close the dialog box and Authorware will continue as normal. If
you are modifying your Erase icon later, you can verify which icons it has been set to
erase by opening it up (double-clicking) and selecting the “icons” tab. This will bring up
the window in Figure 13.
Figure 13. Icons tab view of the erase dialog box.
154
The icons you have set to erase will be listed by title in the white box in the center of the
dialog box. You can tell the Erase icon not to erase one or more of them by selecting
them and hitting the Remove button. You may also have noticed the radio buttons labeled
“Icons to Erase” and “Icons to Preserve.” In general, you will not need to change this
setting from the default. Occasionally, however, you may have more icons to erase than
you care to erase by clicking on them individually. If you ever want to erase everything
that has come before, you can change the setting to “Items to Preserve” and then make
sure nothing is listed in the white box. In this case, it is not necessary to run the program
as indicated earlier. You need only drag the Erase icon to the desired place in the
program, open it up, switch to the icons tab, and change this setting; Authorware will
automatically apply it to everything.
The Wait Icon
The other most common way to control what is happening on screen is to pause the
program at different points. Many times this happens naturally, as in Interactions and
Frameworks (Chapters 6 & 7). Other times, however, you may need to tell Authorware to
wait for a specified time or until the learner clicks the mouse, a button, or a key on the
keyboard. These actions are all accomplished through the use of the Wait icon.
You add Wait icons to your program in the same manner described for display and Erase
icons. When Authorware hits the Wait icon, it will stop and open up the dialog box seen
in Figure 14.
155
Figure 14. Wait icon dialog box.
Power Tip: You can change the default button used by Wait icons by going to
ModifyFileProperties and clicking the Interaction tab. You can then change the
button to any button in your button library, including custom buttons (covered in Chapter
12).
By checking the “Mouse Click,” “Key Press,” or “Show Button” boxes, you can specify
whether Authorware should pause until the learner clicks the mouse, a key, or a button on
screen. The window next to “Time Limit” allows you to specify an amount of time to
pause (in seconds) before continuing. Any or all of these options can be checked
simultaneously.
Working with Libraries
Libraries are secondary (separate) files you can create to store media and objects. One of
the main purposes of libraries is to collect and organize commonly used elements. If you
want a certain sound to play back every time the learner gets a correct or incorrect
answer, you can place that sound in a library. Then you can use it in your program over
and over without making the file any larger (normally, adding media to your file
156
increases the file size by the amount of that media). The other advantage to libraries is
similar to that provided by font styles; should you ever determine that a sound, image,
text, or video needs to be changed, you need only make that change once in the library to
have it applied to the entire file.
To create a library, you select FileNewLibrary. This will open up a new window into
which you can drag display, interaction, sound, video, and calculation icons. You can
then open them up by double-clicking and make whatever changes you want to them.
Anytime you then want to use them in your file, you simply drag them from the library to
the flowline. Authorware will make a shortcut that points to the actual icon in your
library. Conversely, if you have created an icon you then want to place in a library, you
need only drag that icon to the library. Authorware will place the original icon in the
library and put a shortcut in its place on the flowline.
Heads Up: While libraries are powerful and commonly used, there are a few drawbacks.
The most significant is that you MUST have that library in the same folder as your
program every time you open your program.3 If you do not, you run the risk of breaking
every link in your library, which means that anywhere you used a library shortcut, it will
now be missing from your program. In theory there are ways to fix this, but in practice it
is often permanent. See the troubleshooting section for more information on this.
3
Technically, you can have it elsewhere, but you will be forced to locate it prior
to opening the file and, in my experience, many students inadvertently make errors doing
this.
157
Power Tip: If you have an existing collection of sounds, images, and/or movies that you
want to have access to in Authorware, there is a quick and powerful way to turn them into
a library. Simply resize and arrange your Authorware and computer windows so that you
can see your library (even an empty one you just created) and the folder on your disk
where the media are stored, select all the media, and drag them over to the library
window. Authorware will automatically create an appropriate icon for each one, name it
for the name of the media, and place the media in its icon.
Case Study
I was assigned to work on two games for the first Project CATE disc. One of the games
was a variation of the Chutes & Ladderstm game called Bridges & Waterfalls. There were
thirty questions in this game that were supposed to be presented randomly to the learner. I
had had several scenarios recently in which I had regretted not using libraries and font
styles, so even though each question would only be used once (and hence was not a good
candidate for a library), I decided to put each question in its own Display icon in a
library. I also created a font style called “question font.”
After I had developed a beta of the game, we decided to move the questions to a new part
of the screen. We also decided to go with a different font (we had used Skia and decided
instead on Comic Sans). Changing the font was a simple matter of changing the font
style, and took approximately 30 seconds. Without the font style, it would have taken
much longer, as I would have had to open each icon in the library, select the text, and
change the font.
158
Changing the placement of each question was greatly simplified by having the questions
in a library. Instead of having to go to each question in the file and move it manually
(something that font styles cannot help with), I was able to open each icon in the library,
move it to where it should go, and it was automatically updated in the file. This was
doubly appreciated because each question was nested four levels down in the file,
meaning I would have had to open and close 4 different windows to get at each question.
There was an unanticipated benefit to having taken this approach that I did not realize
until recently, when working on one of the games for the second Project CATE disc. The
same structure for delivering the questions could be used to deliver questions in the
current game. The only caveat was that I would have to change each question, as the
content was different for this game. I also needed to place them in a different spot on the
screen. Once again, having used the library proved beneficial. I was able to change the
placement of the questions in the library in about ten minutes. If I had had to track each
down through four levels, it would have taken me close to an hour.
Time saved like this may not seem like much, but the task I just described probably
accounted for 2% of all the work I had to do on that game, and the project is full of such
examples. Over the course of the project I would estimate I saved between five and ten
hours by using font styles and libraries alone.
Summary
Authorware, like other programs, has its own way of looking at things. If you don’t
understand how Authorware thinks, or if you work in a way that does not take that into
159
account, you can easily double or triple your development time. Learning to work with
Authorware may be confusing up front, but pays off in the long run.
Authorware wants you to think in terms of the flowline, not in terms of individual icons.
Learn to translate what you want to happen into Authorware’s language of icons, build
the structure of your program by dragging those icons to the flowline, and then run the
program and fill in the blanks as it goes.
Use Display icons to present text and graphics on screen, but never forget that anything
you want to control individually (erase, animate, etc.) MUST be in its own Display icon.
Control how your objects appear by using the align objects panel and the inspectors
(color, mode, and lines). Make objects appear by setting the transition for the Display
icon, but make them disappear by using the Erase icon. Control the flow and pace of your
program by using Wait icons to make the program pause for a certain amount of time or
until the learner clicks the mouse, a button, a key, or all three.
Before you begin any project, determine your mode (tutorial, game, simulation, ELE,
simulation game) and build your interface and metaphor accordingly. Set your properties
for screen size, placement, and title and menu bars before you start developing. Set your
font styles, even if you think they might change later, and create a library. If you follow
this process, you will be well on the way to becoming a proficient Authorware
programmer.
Exercises
1) Do the following:
160
a) Drag a Display icon onto the flowline. Open it and type “This is the title of my
program.” Arrange it on the screen so that it is centered at the top of the screen,
and make it 36 point, Times New Roman, and bold.
b) Set the properties of that icon so that it fades in.
c) Next, drag a Wait icon to the flowline. Open it up and tell it to pause for 3
seconds.
d) Drag another Display icon to the flowline. Open it and type “This is the sub-title
of my program.” Arrange it on the screen so that it appears just below your title,
and is 18 point Times New Roman, and in italics.
e) Drag another Wait icon to the flowline, open it up, and have it pause for another 3
seconds.
f) Then drag an Erase icon to the flowline. Open it and set it to erase everything
using a fade out/dissolve.
g) How many actions did it take you? Open up your Define Font Styles dialog box;
how many font styles do you have?
2) Now create a new file, and drag the following icons to the flowline in the order
specified: Display icon, Wait icon, Display icon, Wait icon, Erase icon.
a) Name the first icon “Title”
b) Name the second icon “Pause 3 seconds”
c) Name the third icon “Subtitle”
d) Name the fourth icon “Pause 3 seconds”
e) Name the fifth icon “Erase Title and Sub-title”
f) Create a font style called “Title” that is Times New Roman, 36 point, and bold.
g) Create a second font style called “Sub-title” that is Times New Roman, 18 point,
and italic.
h) Run the program and fill in each icon as the program pauses according the
specifications in question 1, above, making SURE to use your font styles as you
go.
i) How many actions did it take you? Was it easier to create the program? How
about arranging the title and subtitle, and erasing everything? Open your font
styles dialog box; how many font styles do you have? Astute readers may realize
that the number of actions taken is similar in both cases, since you must create
font styles for the second question, but remember that once created, those styles
161
can be applied over and over throughout the program; the first way requires you
to adjust the font and size every time you create text.
3) Why is it important to set the Title Bar, Menu, and screen size prior to developing
your Authorware program?
4) How many icons, of what type, and in what order are needed to do the following:
a) Create an program that has a title come in, followed 5 seconds later by a picture
of the Grand Canyon filling the screen, followed 5 seconds later by a sub-title
which disappears along with the title 5 seconds after that?
5) Create a new program called “My Program” and set it up according to the following:
a) Program will be displayed at a resolution of 800x600, and black background for
default screens.
b) Program will have no title bar but will have pull down menus and should be
centered on screen
c) Program will have four kinds of type: Title (Yellow, 36 point, Arial, Bold), Subtitle (Yellow, 18 point, Times New Roman, Italic), Body Text (Yellow, 14 point,
Comic Sans, Bold), and Caption (Yellow, 10 point, Times New Roman). Each
type will also have a drop shadow (Black), so there will be a total of eight styles.
d) Program begins with blue screen with the title (centered, 36 point, Yellow)
“Welcome to My Program,” which fades in. The title uses a style called Main
Title and has a drop shadow. The sub-title (also a style, 18 point, Yellow), which
says “My First Attempt to Program in Authorware,” fades in 3 seconds later just
underneath the main title, and also has a drop shadow. Both fade out 5 seconds
later.
e) Create a library and put all the Display icons you have used in the file into it.
162
Chapter 5: Motion & Media, Part I
Overview
Aside from displaying text and graphics, the most common elements in multimedia are
animation, sound, and video. This chapter will show you how to add and control basic
animation, sound, and video in an Authorware program. Chapter 13 extends these skills
to include more complex (and less common) animations, sound, and video.
Motion and media allow you to address three important components of instruction;
illustration of complex processes or concepts, demonstration of motor skills, and, through
enhanced visual appeal and variety, motivation. Animation can be used to illustrate
processes that cannot be adequately described using text. An example might be the
pumping of the heart, which is a complex process difficult to envision from verbal
description alone.
Video can also accomplish the same thing with higher fidelity, and is particularly useful
for teaching motor skills. A lesson on teaching the basics of the serve in tennis might use
video over animation for reasons of fidelity. Similarly, a lesson designed for physical
education students to learn how to critique and teach others the same content might use
video examples of good and bad serves and ask the students to critique the performances.
Aside from the ability to deliver content that is sound-dependent (such as music
appreciation), sound can also be used in addition to text for delivery of content, making
your instruction more accessible and interesting to the learner. Together, all three
components have the ability to increase the diversity of the learner experience as they
163
navigate through your instruction, which can make your instruction more appealing to the
learner.
The icons used for these processes are, predictably, animation, sound, and movie icons,
and adding them is a matter of dragging the appropriate icon to the place in your program
you want the animation, sound, or video to occur, and running that section of the program
to set it up. Animation is a little more complicated than sound and video, in that it
requires the use of more than just the animation icon. In all three cases, how the
animation, sound, or video is presented depends on the options you select within each
icon’s dialog box.
Objectives
•
Animate a text or graphic object from one point to another on the screen
•
Add sounds and control when, where, and how they play
•
Add movie clips and control when, where and how they play
Types of Animation
Adding animation to your CBT can be fairly simple or maddeningly frustrating. The key
to determining which it will be lies in three rules:
•
Animations are created by placing what you want to animate inside a display icon,
placing an animation icon someplace after that display icon, and running the piece
to set the properties of the animation
164
•
You can only animate the contents of a display icon that has come before the
animation icon
•
Animation icons affect everything inside a given display icon, not individual
objects within that display icon
The first rule should be familiar to you from the earlier chapters, and will appear in later
discussions about target area responses and interactions. The second and third rules
should be familiar to you from the discussion of erase icons in the last chapter; you can
only erase icons that have come before the erase icon, and the erase icon will erase the
entire contents of display icons, not individual objects within display icons. Although you
can animate movie clips as well as text and graphics, the process is the same for both, and
since it is more common to animate text and graphics than video, this chapter will only
discuss text and graphics animation.
Basic animation
One way to help you remember the optimal way to create an animation is to remember
the acronym D.A.R.T. (just think of an animation of a thrown dart). D.A.R.T. stands for
Display, Animation icon, Run, and Test. Lets look at each of these steps in detail.
Display
The first step is to drag an empty display icon onto the flowline. This icon is for the text
or graphic object you want to animate. Because you studied the previous chapter in great
depth, you remember that you don’t actually create or import that text or graphic object
yet—that happens after you run the program. You also remember to name the display
165
icon something that reflects what will go into it (so that when the program stops and
opens that icon, you will remember what should go in it).
The only other thing that you have to remember is that, because of the third rule
presented above, you must put the object (i.e., text or graphic) that you want to animate
inside its own display icon; if you put it into a display icon with other objects, they will
all be affected by the animation.
For example, if you want to create a screen in which some text fades into the middle of
the screen, followed by a graphic that animates in from the right of the screen, the graphic
would have to be in its own display icon; otherwise, both the graphic and the text would
animate at the same time, in the same direction.
Heads Up: If you are using the Direct to Point type of animation (defined later), you will
need to make sure that you place the graphic or text object you want to animate in its
starting position (i.e., the place you want the object to animate from).
Animation
Once you have created or imported the object you want to animate, you next drag an
animation icon onto the flowline after the display icon and name if for what it should do
(e.g., “animate title text”). While it is not absolutely necessary to place the animation icon
immediately after the display icon, you should probably get in the habit of doing so until
you are more comfortable with the process. There are several settings you need to make
in order to control your animation, but you don’t do that yet; once again, that happens
when you run the program.
166
Run
Now you run the program (you may want to use the start and stop flags to isolate just this
portion of your program), which immediately stops at the empty display icon, opens it up
for you, and patiently waits for you to create shapes, type text, or import text or graphics.
Once you have done this and arranged these objects on screen in the places you want
them to start animating from, you close the display window.
Authorware immediately stops again when it hits your animation icon, opens up the
animation dialog box, and waits for you to tell it what to do. There are several options for
animating an object on the screen which are contained in this dialog box. For now,
because I think it is helpful to become familiar with the basic process of animating an
object before exploring this options, just click on the object you want to animate and drag
it to the place you want it to end up. This will tell Authorware to animated the object
from where it first appears on screen to the place you have just now dragged it to. Close
the dialog box, and you are done.
Test
To view your animation as you have created it, you simply run the program again and
watch what happens. Assuming that it behaves the way you want it to, you are done and
can continue working on your program.
It is more likely that there are things you don’t quite like about the way your animation is
set up, however; perhaps it is too fast or slow, or it doesn’t move in a straight line like
you wanted, or you want it to move on a curved path or to several points on the screen.
167
Chapter 13 will cover animations involving multiple points, and along straight or curved
paths. These types of animations are not necessarily much more complex, but there is
enough to learn about Authorware that it is better to leave these types of animations for
later so that you can focus on other things like sound, movies, and interactions (Chapter
6). There are some adjustments that you can make that are worth examining now,
however. To do that, we will examine the animation dialog box in more detail.
Dialog box (motion tab)
Figure 15. Animation Dialog Box.
The title of your animation icon appears in the box at the top. The type of animation,
Direct to Point by default, appears in a drop down menu from which you can select any
of five different types of animation. These types will be discussed in more detail in
Chapter 13.
The next box allows you to set the layer for your animation. Each icon (and the objects it
contains) occurs on a different layer than all other icons. By default, the layer box is
empty, meaning that the contents should appear “on top” of everything that came before,
and “underneath” everything that comes after. In some cases, it may be necessary to
168
manually assign a layer number to a given icon in order to get it to appear as desired on
screen. For now, don’t worry about (or adjust!) layers, as they can be tricky to manage.
Chapter 12 will address layers in more detail.
The timing box is a pull-down menu that allows you to modify the unit of time used to
specify the time it takes your animation to complete. It is used in conjunction with the
next box, which by default has a “1” in it. The unit of time Authorware uses by default is
called “Time (sec),” which means that the number in the following box represents the
number of seconds it takes your animation to complete (by default, 1 second). The other
unit of time you can select is “Rate (sec/in),” which represents the ratio of seconds per
inch of travel for your animation (by default, 1 second per inch). Although there are times
when you may need to use Rate (e.g., when two objects are supposed to move at the same
speed but over different distances), most animations you set will be measured in time.
Heads Up: Although it may sound obvious, you’d be surprised how many people have
trouble when they attempt to speed up their animation. The time unit is time to complete
the animation, so higher numbers mean slower animations. The rate unit is seconds per
inch, so higher numbers also mean slower animations. Also remember that you are not
limited to whole numbers; it is possible to set the number of seconds or the rate to .0005!
By far the most important element of this dialog box right now is the Concurrency dropdown menu. Your choices here are Concurrent (the default) and Wait Until Done. To
understand these terms, we need to return to an earlier rule about Authorware.
Authorware takes every icon on the flowline in order, from top to bottom, and left to
right, until it reaches the end of the flowline. Along the way, Authorware is required to
169
display anything it finds inside display, sound, or movie icons, and perform any actions
specified by any other icon, including animations. Icons like animation, sound, and
movie, are all time-dependent in the sense that it takes time to play an animation, sound,
or a movie. By default, Authorware assumes that you want it to wait until an animation or
sound is done playing before it should move on to the next icon. This is the meaning
behind the term “Wait Until Done” in the concurrency menu. Concurrency refers to how
the current icon should be displayed in relation to the icons that follow (Wait Until Done
apparently means “no concurrency”).
In the case of animations, Authorware will, by default, wait until the animation has
finished before moving on. In some cases you may want the animation to occur while
something else is happening (another animation, a sound, an erase icon, etc.). In these
cases, you need to set the concurrency to “Concurrent.”
Tip: For reasons only known to Macromedia, movie icons are set to “Concurrent” by
default.
Adding media, part I
Sound
Sound is a part of most CBI/CBT, whether as opening or closing music, sound track,
narration, feedback, or button effects. With the exception of the latter (which will be
covered in Chapter 10), all of these are accomplished through the use of the sound icon.
The process involves (you guessed it) dragging a sound icon onto the flowline at the
place you want it to occur, running the program, and selecting the sound you want. There
170
are issues that require some discussion prior to examining the options for adding and
controlling sound, however.
Power Tip: Because there is no visual component to sounds, it is not strictly necessary to
run your piece in order to select the sound; double-clicking on a sound icon after
dragging it to the flowline accomplishes the same thing without much risk of error. In
fact, one of my favorite features of Authorware and libraries (first mentioned in Chapter
4) is the ability to drag a collection of sounds (sound effects, generic positive and
negative feedback, voice-over narration for text screens) which I have named according
to my design documentation onto a new library. Each sound is automatically placed in a
sound icon which is then named after the name of each sound file. This process also
works if you drag the sound file onto the flowline itself, although the advantages may be
outweighed by the need to arrange your desktop and Authorware windows to do so.
Formats
Just like images and movies, sounds come in a variety of file formats. Each of these
formats have its own strengths and weaknesses, and it is helpful to know something about
them before you add them to your file. Authorware supports AIFF, MP3, PCM, WAVE,
or SND file formats. If these sounds are stored internally, they should all play back on
any platform, regardless of whether they are native to Windows or Macintosh computers
to start with.
AIFF stands for Audio Interchange File Format, and is the standard sound format for
Macintosh computers. It tends to produce high quality sounds that are fairly large,
171
although much depends on bit rate, channels, and compression. WAVE files are native to
Windows, and yield files of similar size and quality to AIFF. If your target platform is
Windows only and you want to store your files externally, you should choose WAVE
over AIFF.
MP3 files are MPEG 3 formatted sound files. This format creates significantly smaller
files that WAVE or AIFF (90-95% smaller) with little noticeable loss in quality. MP3
files are also cross-platform (they are supported by QuickTime on the Macintosh,
Windows Media Player on Windows, and by all browsers). They are your best choice for
cross-platform authoring where file size is an issue.
PCM stands for Pulse Code Modulation and is normal, uncompressed sound. As such, the
file sizes are large and the quality is excellent. There is little appreciable difference in
quality from MP3, however and even less from WAV or AIFF, so unless high-fidelity
requires it, you are probably better off with any of these formats. SND files are native
Macintosh files, and should probably be avoided even if your target platform is
Macintosh (AIFF is a better choice in that case).
Voxware
Voxware is a compression utility included with Authorware 7 that allows you to take
WAVE files and compress them to VOX files. This utility creates small file sizes, and is
primarily intended for use with spoken sound rather than music or sound effects. While
the file sizes are small, the quality is not nearly as good as MP3, which will also handle
music. Nonetheless, if you don’t have a sound editor, have voice-over material in WAVE
format, and don’t mind a slightly “tinny” sound, Voxware is free and effective.
172
Compression. Compression is a concept that will be discussed again in the video section.
There are many different compression schemes, but they all accomplish the same thing;
making any existing file smaller. Almost all compression schemes are “lossy,” in the
sense that they “throw out” information in the file in order to save space. Some do a
better job than others of predicting what information can safely be jettisoned without
affecting the overall quality of the sound. This is largely a matter of personal taste
however, and there are no hard and fast rules about which are best. In my opinion, you
should avoid using compression with your sounds in all cases unless you have so much
sound that file size becomes a big issue. If you do use compression, try several
compression schemes out with the different types of sounds (music, voice, and effects)
prior to settling on one.
Heads Up: Whether compressing audio, video, or images, you should always preserve
the original (uncompressed) formats someplace safe. This is because compression is a
one-way street; once the compression scheme has thrown data away, it cannot put it back.
If you change your mind later (e.g., if the client tells you they don’t like the quality of the
sound), you can always go back to the original and use a different compression scheme
(or none at all). The same is true for file formats as well—once you go from WAVE or
AIFF to MP3, for example, you will not be able to get back to the exact same sound later.
Always make sure you do a “Save As” whenever you modify your file format or apply a
compression scheme—that way, the original file will be preserved.
Loading sound.
173
When Authorware encounters an empty sound icon (or when you double-click on any
sound icon), the sound dialog box opens up (see Figure 16).
Figure 16. Sound Dialog Box.
The first box in the middle of the dialog box contains the title of the sound icon. The
second box is identical to the Concurrency box in the animation dialog box, and again
determines whether Authorware should wait until the sound is done playing before
moving on (the default) or not. The next drop-down menu is connected to the one below
it in much the same way that time/rate in the animation dialog box was connected to the
box below it. By default, Authorware assumes you want to play the sound one time
(Fixed Number of Times=1). You can select another option, Until True, which lets you
use variables to control how and when the sound should play. This option will be
discussed in Chapter 11. For now, just remember that you can tell Authorware to play the
sound more than once by changing the number from 1 to however many times you desire.
174
The next box is Rate which, like its cousin in the animation dialog box, controls how fast
the sound should play. You can speed it up or slow it down by increasing or decreasing
the number from its default of 100 percent of normal. The next box is used to control
when the sound should start playing, and is again used in conjunction with variables and
will be discussed in Chapter 11. The checkbox at the bottom of this dialog box is
important to understand now, however. By default, Authorware is going to play a sound
one time (Fixed Number of Times=1) at it’s normal speed (Rate=100% of Normal), and
wait until the sound finishes before moving on (Wait Until Done). It will start playing as
soon as it hits the sound icon. Normally, this is just what you would expect and want it to
do. But there may be occasions where a sound that has come before may not be done
playing (remember that you can set a sound to play “Concurrently” so Authorware starts
playing it and moves on immediately to the next icon). In some cases, the earlier sound
may not be finished before you reach the current sound (e.g., slower computers run your
program at slower rates). To ensure that the current sound does not start until the previous
sound is finished, you can check the box next to “Wait for Previous Sound.” Authorware
will wait until all previous sounds are finished before playing the current sound.
Tip: This issue has become less important with the addition of media synchronization in
Authorware 7. This process will be discussed in Chapter 13.
To load the actual sound file using the dialog box, you click on the Import button at the
lower left of the dialog box. This will bring up a navigation window similar to the one
presented in Figure 17, below.
175
Figure 17. Sound Import Navigation Window.
This window functions like all navigation windows in that you are able to navigate to
different locations on storage devices connected to your computer and select from the
files in the display window area. There are two options that are unique to this window,
however; Link To File and Show Preview. Show Preview, when checked, will create a
preview panel in which you can play (and stop) any sound that you have highlighted.
This allows you to make sure you have the right sound before you actually import it. The
preview panel also display format and file size information specific to the highlighted
sound.
Heads Up: The Windows OS is pretty dumb when it comes to file types. Windows relies
exclusively on the three-letter extension of the file. There are several problems created by
this. If the file was created without an extension, Windows will not know what it is, and
programs like Authorware will not display that file as a result. For instance, in the
176
navigation window above, it says to show Files of Type “All Available,” meaning any
sound file supported by Authorware should be listed. But if there is no extension, or if
that extension has been mis-typed (e.g., while renaming a file), it will not appear even
though it is a supported file. What’s more, Windows hides extensions for all known files
as a default, so you can’t see what the extension is to verify if it exists at all or if it has
been mis-typed (you can change this option in Windows by double-clicking My
Computer selecting ViewFolder Options, selecting the View tab, and un-checking the
“Hide file extensions for known file types).
The other check box is labeled “Link To File.” This check box is deceptive, because what
it really does is specify whether the sound file should be stored internally (unchecked) or
externally (checked). Why Authorware does not refer to this process as internal vs.
external storage is unclear. When a sound file is stored internally, your Authorware file
size is increased by the size of that file. When it is stored externally, the size of the
Authorware file is not increased, but you must provide the original sound file with your
program, so you do not save any space overall. The advantage of external storage is that
your program does not take up as much RAM (not disk space) when running, and you
can update the sounds by simply replacing the sound file with another file with the exact
same name. This allows for fast updating of files (you can just send the new audio files to
the client or, if web-based, ftp the sound to the directory and the client need not do
anything!) as well as the ability to edit sounds quickly (just open the original file, edit it,
and save it—Authorware is automatically updated). The downside is that you must be
extremely conscientious about tracking your files and keeping them organized, or your
program will not function correctly when you package and distribute it. I have found that
177
it is best to store your media internally in a library (as MP3 files if space is an issue); if
changes are needed later, I edit the original file and reload it into the library and its done.
Extra steps, but much easier to keep track of.
A final note about sound
Now that sound cards are standard, microphones common, sound recording software
built-in, and adding sound to programs like Authorware is so easy, it is tempting include
sound everywhere in your CBI/CBT (e.g., as voice-overs, music, sound effects like
applause for correct responses and buzzers for incorrect responses). This is similar to
what happened in the late 70s with the advent of desktop publishing. Once the technology
advanced to the point where anyone could layout a page using different fonts and sizes,
people began to do their own flyers, newsletters, and brochures.
What people failed to realize then was that there is a difference between the technology
and the expertise needed to use it; while anyone could use the tool, few new the best way
to do so. This resulted, initially, in documents with so many different fonts in so many
different sizes that they were harder to read (and more annoying!) than a typewritten page
would have been!
We are at a similar position now with regards to multimedia—the tools have become easy
enough to use that the question is no longer how to create multimedia, but what is the best
way to create multimedia. Just because we can add sound everywhere doesn’t mean we
should. Aside from accessibility issues, sound should be used sparingly and should add
something to the program. For example, there is little point in creating voice-overs that
are word-for-word renditions of what is on the screen unless you anticipate learners with
178
hearing disabilities.4 Instead, consider using audio to extend and elaborate upon the
screen content. You might also use voice-over to help address common errors or
misconceptions you have identified through user testing—you can save screen redesign
in some cases by addressing these errors through the addition of audio advice.
Advisement itself is a good candidate for spoken audio—built-in help throughout the
piece might be presented as spoken audio.
Sound effects can play a vital role in good interface design. Providing a clicking sound
when a user clicks on a button helps solidify the illusion of three dimensionality and
interactivity in a two-dimensional medium. On the other hand, sound effects are often
greatly overdone. It may seem like a clever idea to include the sound of Bart Simpsontm
saying “Cool, man!” for every correct answer, but it quickly becomes annoying to your
learner. The thing to keep in mind is that you are designing for the learner, not yourself. It
may be tempting to build-in lots of media to your early projects, but ask yourself how the
learner will feel after an hour in your program. And because you may not be the best
judge of this initially, I suggest that you adhere to the following two principles: Place any
audio you feel is necessary under learner control whenever feasible, and pay careful
attention to your formative and one-to-one evaluations. If the learner has the ability to
4
There are better solutions to doing this now that make use of Microsoft Agent
technology. Microsoft Agent is built in to Windows ME and above, and is capable of
reading aloud any text you specify. Third party solutions exist for making use of
Microsoft Agent from within Authorware, and are much more cost-effective solutions
than recording your own audio.
179
turn off any existing sounds, or to select sounds when they want them, there is less
likelihood they will become irritated by them. And if they do become irritated during
your formative evaluations, you have a chance to modify the sounds prior to delivering
the final product.
Video
Few media have generated as much excitement in CBI/CBT development as video. In
fact, video is probably the single most important driving force in the development of
multimedia in the 80s and 90s; full-screen, full-motion video has been the holy grail for
many years.
Technology has finally been able to deliver on the full promise of computer-based video
in the last five years. This has been accomplished by software and hardware advances on
several fronts. The problem has always been that video was inherently analog, and
computers are digital. Without going into a lecture on electronics, suffice it to say that
these are not compatible formats.
To solve the problem, hardware manufacturers began making digitizers, cards that
plugged into your PC that would convert an analog signal to a digital signal. These were
expensive and produced poor quality videos, often of less than full-screen size. They
eventually became better and cheaper, and it began to look like they would solve the
problem. As with many innovations, however, the answer came from a different
direction, one that focused on the other side of the equation. Instead of converting analog
signals to digital ones, why not record digital signals in the first place? Thus was born the
digital video revolution.
180
Digital video cameras now record movies in a digital format called digital video (DV)
that can be read by a computer via means of Firewire. Firewire is an Apple Computer
branded technology that allows computers to import and export data at a rate of 400 to
800 megabits per second (equivalent to 50 to 100 megabytes per second). This is good,
because it turns out that digital video creates HUGE files; 1 minute of raw digital video
takes up nearly 2 gigabytes of space. Luckily, digital video cameras are able to compress
this down to a more manageable 10 gigabytes per hour of video without any appreciable
loss in quality, but the files are still much too large to fit on anything but a hard drive.
The reason Firewire is necessary is that in order to get these large files onto your
computer, you need a large pipeline. If it were just a matter of file size, you could use
USB, or SCSI connections; the only difference would be the time it takes to copy the
digital data. USB can transfer data at approximately 1.5 megabytes per second, so would
take almost 2 hours to transfer one hour of DV (USB2 is significantly faster, but not yet
widely available). SCSI is faster, with transfer rates of between 4 and 40 megabytes per
second, depending upon which card and hard drive you have. While the top SCSI card
(Ultra Wide) could transfer one hour of video in just under 5 minutes, cards and drives
are expensive.
It turns out that of these, only high-end SCSI would work because digital video cameras
play back video in real time, meaning that the computer must be capable of supporting
the data rate that DV plays back at (approximately 15 megabytes per second minimum).
In any case, SCSI Ultra Wide interfaces are not practical to build into cameras, while
Firewire is, which has thus been adopted as the standard for all DV cameras and
computers that work with DV.
181
The other side of the equation is software; it does no good to have a computer capable of
DV if there is no software to work with it, or if that software is too difficult for nonprofessionals to use. Although video editing programs abound, there are three big players
in the market today: iMovie, Final Cut Pro 3, and Adobe Premiere. The first two are
native to Apple Macintosh computers, while Premiere is cross platform. Final Cut Pro
and Premiere are professional level editing programs and are not good candidates for
novices to adopt as their first editing program. Of the two, Final Cut Pro is winning a lot
of converts in the professional market with its non-format dependent input and output
capabilities, is native color correction tools, it’s ability to generate video for any platform
or medium, and it’s ease of use (CNN and ESPN both use it for production). Adobe
Premiere is getting long in the tooth, having gone many years without significant
upgrades, but a new version is due out soon that should bring it to a more competitive
level.
iMovie is shipped free with all Macintosh computers since at least 2000, and is available
for purchase for less than $50. It’s ease of use and ability to generate video for Windows,
Macintosh, and the Web have quickly made it the program of choice for beginning DV
editors. If you have access to a newer Macintosh computer, it is worth the purchase price.
In fact, it may be worth the purchase price of Macintosh computer itself if you plan to
make use of video in your CBI/CBT projects. You can get a basic set up for around
$1000 that will allow you to produce high-quality DV in a variety of formats without a
significant investment in learning time (three hours is sufficient to get you making
movies). At least as significant is that all Macintosh computers come pre-configured for
DV (hard drives, RAM, Firewire, etc.) and work right out of the box. Although pre182
packaged PCs that support DV exist, because the companies that produce them include
DV as a marketing strategy rather than as an integral part of their computers as Apple
does, problems are common and getting competent support with these problems can be
difficult.
If you don’t have access to a Macintosh and can’t afford or justify the purchase, it is
possible to accomplish the same thing on the PC, albeit with more potential difficulty.
The problem on the PC side is that the hardware and software needed to work with DV is
produced by several different companies, even when bundled as a single solution in a PC.
The process of adding cards and software to your own computer can be problematic. You
need a Firewire card, an Ultra ATA 100 card and 40GB 7200rpm drive on its own bus
(no OS software installed on it and no other drives connected to the same cable), and
software that is compatible with the card. Getting different Firewire cards to work under
different OSes (e.g., Windows 98, 2000, and XP) and with different software and hard
drives can be a nightmare. The software available on the Windows side is not of
uniformly good quality in terms of power and ease of use, although Pinnacle bundles a
good program with their Studio DV 7 card.
As you can see, there is a lot about working with DV that requires careful attention.
While space does not permit a more detailed analysis, a discussion of some of the more
pertinent details as they relate to Authorware is warranted.
Formats & CoDecs.
All digital video must be compressed in one way or another for us to be able to work on it
on a computer. Even when we refer to “uncompressed” video, such as that taken with a
183
digital video camera, we are still talking about compressed video. The video is
“compressed” down in size using an algorithm, and when it is played back it is
“decompressed” for viewing. This all happens in real time, so we never notice it.
The ways in which video is compressed are determined by the tool that does the
compressing. These tools, or different standards for compressing digital video, result in
different formats. To make matters more complicated, each format can use multiple
versions of CoDecs, which stands for Compressor-Decompressor—the algorithm
mentioned earlier.
Authorware supports a variety of video formats, including Bitmap sequences, FLC/FLI
(Autodesk), PICS, Director, Flash, MPEG, Video for Windows (AVI), and Quicktime.
While each of these are different standards, the latter three are what we are most used to
thinking of as “movies,” and will be discussed here. The other types are more specialized,
and will be discussed in Chapter 13.
MPEG stands for Moving Picture Expert Group, which is an organization that sets
standards for digital video and audio compression. Other companies, in turn, can make
use of the MPEG standards to formulate their own CoDecs. While all of these movies are
MPEG movies, they will differ in quality and size, depending on which CoDec is used to
create the MPEG movie.
There are currently four MPEG standards named, predictably, MPEG-1, MPEG-2,
MPEG-3, and MPEG-4. MPEG-1 was developed for video and audio applications on
CD-ROM. CD-ROMs are slower than hard drives, which results in smaller available
bandwidth/pipeline. MPEG-1 allows CD-ROMs to display audio and video, albeit at a
184
smaller size and quality than on a television or videodisc. It is not used as much as
MPEG-2, which is the standard for encoding digital video for DVDs. It produces very
high-quality video. MPEG-3 never really got off the ground in regards to digital video
because MPEG-4 came out so quickly on its heels. MPEG-3 was originally targeted to
update MPEG standards to work with High Definition Television (HDTV), but it turned
out the MPEG 1 & 2 could be used with some modification. MPEG-3 is now best known
for its implementation as MP3, which stands for MPEG Audio Layer 3. MPEG-4 is a
new standard which will allow use in phones, games, interactive appliances, and a
plethora of other new electronic products. It is not yet widely implemented, however. For
our purposes, it is sufficient to know that if we are working with MPEG movies, they are
probably MPEG-2.
Video for Windows, now called Windows Media, is Microsoft’s standard for video on
the Windows platform. Originally, these were all AVI files, which is still the format
preferred by Windows Media Player. AVI files tend to be lower quality files and are not
easily cross-platform. They do, however, play back on any Windows computer without
the need for the end user to install anything.
Quicktime is the most common digital video format in cross-platform video development,
second perhaps only to Real Video in web application. Quicktime movies make use of
many different CoDecs to create video of varying quality and file size. Sorenson 3 is one
such CoDec which creates exceptionally high-quality video and very small file size, but
there are several available. Authorware understands Quicktime now on either the
Windows or Macintosh platform (although the free software must be initially
downloaded by Windows users in order for Quicktime movies to playback). iMovie can
185
save your movies as streaming Web movies for playback in an Authorware piece over the
web, and is automatically formatted for use on Macintosh or Windows computers.
Additionally, Quicktime allows you to create different versions of your movie for
different bandwidths, and will automatically download the version appropriate for the end
users connection (as long as they correctly identified their bandwidth when prompted
during installation). Quicktime also can control html content in a Web page, calling up
different scrolling text on a page at key points during playback of the video, for example.
Power Tip: To take the headache out of learning about each individual CoDec and
format, I recommend you purchase Terran Media Cleaner. This product does nothing but
create video for different applications and platforms. It has a built-in wizard that prompts
you for information about your video and makes adjustments accordingly. More
advanced users can adjust these settings manually as well.
Size and storage.
The size of your digital video is determined by the CoDec you use and the physical
dimensions of your digital video. A common term used to describe video is full-screen.
Full-screen means the video is at least 640 x 480 pixels (a peculiarity of the DV standard
is that it is actually 720 x 480, but who’s counting?). It is extremely rare that you would
be working with this size video in CBI/CBT, as the storage and bandwidth issues are too
significant to make this practical. The largest video dimension you are likely be working
with is 320 x 240, also referred to as half-screen video. Even though it is technically halfscreen (640 divided by 2 =320; 480 divided by 2=240), it only fills up one quarter of a
640 x 480 screen because you divide both dimensions by 2. If this does not make sense,
take a blank sheet of paper and place a mark in the middle of the top and left edges. Use
186
those marks to begin drawing straight lines toward the middle of the sheet until they
meet. You will have drawn a box the covers one quarter of the sheet, even though you
started out from the halfway point on both edges.
The smaller the dimensions of the video, the smaller the file will be, regardless of which
CoDec you use. You may need to experiment with different CoDecs to get the size and
quality you want. These CoDecs are selected during the export process from whatever
tool you use to edit your video (or from Terran Media Cleaner 5).
Regardless of how large your video is, you should always store it in the same folder as
your Authorware program. It is tempting to create lots of sub-folders to organize your
different sounds, images, and videos, but doing so can cause problems. It is true that
Authorware allows you to specify where it should look for these files when it is time to
play them, including different sub-folders, and this will be discussed in more in Chapter
10. At the beginning stages of learning Authorware, if you store your video (and all
external files you use) in the same folder and level (i.e., not in sub-folders) as you have
your program in, Authorware will automatically find it when it is needed. This is because
Authorware first looks for the place you originally loaded the file from, and then
automatically looks in the same place the program is running from. This means, of
course, that you should copy any video or files that you intend to store externally into the
same folder as your program.
Loading video.
So how do you go about loading video in Authorware? It turns out that the process
depends on the type of video you want to import. We’ll start with the formats that allow
187
you to use the movie icon, and then discuss Quicktime and Flash, which both require the
use of what is called an Xtra.
The easiest way to add video (that isn’t Quicktime or Flash, that is) is to drag a movie
icon over to the flowline, run the piece (perhaps using the start and stop flags), and load
the video when prompted. Authorware will present the dialog box in Figure 18 when it
opens the movie icon for you.
Figure 18. Movie Icon Dialog Box.
The first box under the title of the icon is where the name of the file you actually load
will appear once you have selected it. Note that the box underneath that, labeled Storage,
says External by default. This is because all video is stored external to your piece with
the one or two exceptions that will be discussed in Chapter 10. There are only 3 options
that need to be covered at this point are Prevent Automatic Erase (which in this case
prevents your movie from being erased by anything except an actual erase icon--it is
188
possible for some icons and processes in Authorware to erase content without the use of
an erase icon); Erase Previous Content (which will cause everything else to be erased
prior to your movie beginning), and Audio On, which allows you to specify whether to
play the audio associated with your movie or not. The other options only apply to internal
movies or to situations not normally encountered in a beginning project; they will be
discussed in Chapter 10.
Controlling video.
Once you have imported your video, you need to specify how and when it should play.
This is accomplished through the Timing tab of the same dialog box. Clicking once on
the Timing tab will bring up dialog box in Figure 19.
You may recognize some of these options from the Sound dialog box, and these options
all perform similarly. Concurrency specifies whether Authorware should start the movie
and move on or wait until it is done playing. Play determines if the movie will play a
fixed number of times, and if so, how many times. You will notice many other options
189
under Play, however, that were not part of the Sound dialog box. Most of these are not
commonly used and in any case do not apply to external movies, which is what we are
discussing in this chapter. The Play options Repeatedly, Controller Play, and Pause Play
will cause the movie to play over and over and show a play/pause button for the learner
to use to start and stop the movie.
Rate is similar to the Sound dialog box as well, but is measured in frames per second
(fps). Specifying a number here will cause the movie to play faster or slower. Full-motion
video is 30 fps (DV is really 29.97, but who’s counting?), so unless you saved your
movie at a different frame rate during compression (a common way to save space), you
can assume 30 fps is 100% of normal.
The bottom two boxes are among the more interesting and often under-utilized features
of Authorware. Start Frame and End Frame allow you to specify which part or section of
a movie to play. Suppose you had a video clip of someone demonstrating one correct way
and three incorrect ways of doing something. You want to use this clip for feedback to
the learner about the choices they have just made about how to accomplish that task.
Instead of breaking the video up into four clips, you could specify the start and end
frames for each part of that clip so that you would play a different section; to the learner
it looks like four clips, but is in reality just one. More often than not, it probably makes
sense for you to actually divide your video up into individual clips, but in cases where
you are using clips that have already been compressed by someone else (i.e., you don’t
have the orginals) using start and end frames may be the best solution. That’s because
you should never re-edit clips that have already be compressed; doing so reduces the
quality tremendously, in many cases yielding unacceptable results.
190
If you want to add Flash or Quicktime movies, the process is a bit different, and while
you can control these videos as you do those loaded into a movie icon, the process for
doing is more complicated and will not be discussed until chapter 13. For now, you
should assume that the movies will be played at a normal rate and in their entirety. The
process to add Quicktime or Flash movies involves clicking next to the part of the
flowline you want the movie to appear. A hand will appear pointing at the place you have
selected. If you want to reposition the hand, click somewhere else and it will move. Once
you have chosen the place to put your movie, select InsertMediaQuicktime or
InsertMediaFlash. This will bring up the dialog box shown in figure 19.
Figure 19. Insert Media Dialog Box.
A Final Word on Video
191
The same cautions for use of sound in your instruction apply to video. Just because you
can put video in does not mean it will make your instruction any better. Video is
expensive to develop and requires more resources on the part of your learner (disk space
and RAM) than animation, so it should be used only when it is most appropriate. Video is
best used to illustrate motor skills and processes where fidelity is important. There is no
point in using video to display essentially static content, nor to illustrate simple motion
that can be accomplished through animation. In fact, even in cases of complex motion
and motor skills, the use of several still images may be just as effective (if not as flashy)
as video.
Case Study
Two of my Authorware students wanted to integrate video into their projects. One, Dana,
was far enough ahead of schedule, and the video was simple enough, that I felt she could
manage to do so. The other student, Carl, wanted to make extensive use of video
throughout his project. He professed to understand the extra time he was taking on and
planned to purchase a digital video camera, software, and hardware.
Dana, an interior design instructor at a University, had access to a digital video camera
and editing software on the PC. She roped her husband into playing the part of a museum
curator who was “hiring” the learner to help identify different furnishing from different
periods in order to set up the displays for the museum correctly. This simulation was her
final assessment for instruction she had developed in Authorware to teach learners about
home furnishings. She filmed the clips she needed, edited them down, and exported them
at the size she wanted.
192
Upon integrating them into Authorware, however, she found that they would not play;
Authorware kept saying it could not find the appropriate Xtra to play back her movies.
While this is normally a problem related to the actual presence of the Xtras folder (you’ll
learn more about that later), in this case no amount of troubleshooting could get the video
to work. It turns out that her hardware/software combination had used a CoDec that was
proprietary and thus not understood by Authorware.
Because her clips were relatively un-edited and short, she brought her camera and video
in to class where we connected it up to one of our Macintosh computers. We brought the
video in to iMovie, made the basic edits, and exported the video as streaming video so it
would be visible from CD and the Web. The entire process took about an hour, at which
point she brought the video back in and it worked immediately.
Carl purchased a firewire card and an external hard drive so that he could work on his
video at home and at school, which was important as his project made use of 30 minutes
or more of video, all of which had to be edited and exported. His video worked from the
very beginning, even though it was AVI format just as Dana’s had been. Carl spent a lot
of time working on his project, doing all the video at home. In order to get help with his
Authorware program specifically, and to make efficient use of class lab time, Carl
brought his project to school once per week. Unfortunately, his program failed to display
the video almost half the time when he was at school, resulting in lost development time
(since he could not see the video, he could not make modifications to the parts of his
program that relied on the video). This had nothing to do with the format of the video,
however.
193
It turns out that the program Carl used to edit his video would store the video in a default
folder on his hard drive. Carl knew that he needed to keep the video in one place, so he
created a folder for his video inside his project folder and tried to make sure he saved his
video to that folder. Occaisionally, he would inadvertently save the video to the wrong
place, however. When he would then later go to load a new clip and it wasn’t in his
project folder, he would go to the default folder on his hard drive and, sure enough, it
would be there. He would then load the video from there, and make a mental note to copy
it over to the other folder later.
To make sure he had done so, he would always launch his Authorware program (in which
he had loaded his video clips into icons) from the external hard drive to make sure that
the video still worked. Upon reaching school, however, he would find that many of the
clips would not play. This was because Authorware knew where the clips were located on
his hard drive at home, and so would play when needed. But when he then opened the file
at school, Authorware would look for the video on the local hard drive, not find it, and so
not play the video.
Carl had to develop and strict procedure for copying all his files over to his hard drive
and reload all the movies that were not working. This was time consuming and
frustrating, but not nearly as much so as the problems he would have when the video
would not play.
In both cases, the difficulties they experienced with the video had nothing to do with
shooting or editing the video itself, and everything to do with planning and organizing the
video so that it could be worked with effectively with Authorware. Running tests and
194
developing stringent media management procedures can help you avoid these issues
somewhat, but integrating video into Authorware is a non-trivial endeavor, and you
should adjust your timeframe accordingly if you plan to make use of DV in your project.
Summary
Animation, video, and sound are what define multimedia, and they are common elements
of CBI/CBT. Each of these elements are incorporated into Authorware in a similar
fashion through the use of different icons. The means of modifying and controlling these
media are more complicated, but not as complicated as creating, editing, and producing
audio and video in particular.
The three rules of animations help to simplify their use in CBI/CBT: An animation is
created by placing the object to be animated inside a display icon, placing an animation
icon after the display icon, and running the piece; you can only animate the contents of a
display icon that has come before the animation icon; and animation icons affect
everything inside a given display icon, not individual objects within that display icon.
The first rule can be remembered using the acronym DART: Display, Animation icon,
Run, Test. The way an animation is controlled is through the motion tab in the animation
dialog box. Speed is controlled in terms of rate or time, and whether the animation starts
and moves on or waits until it is complete is determined by its concurrency.
Authorware can bring in a variety of sound formats, each with its own strengths and
weaknesses. The quality and size of a sound is the product of its format and the
compression scheme (if any) used. Sound is also controlled through concurrency options
and rate, but you can also modify the number of times the sound should play, when it
195
should begin, and whether it should wait for any previous sounds to stop before it plays
the current sound.
Authorware can also bring in a variety of video formats, some of which can be interactive
and stored internally, others of which can only be stored externally. The size and quality
of your video, like sound, is dependent on it format and compression, or CoDec in this
case. Quicktime is the most common format for video in Authorware and on the Web,
and is completely cross-platform. Unless it is stored internally (and most video is not),
you should always keep your video in the same folder at the same level as your
Authorware program.
The process for loading video in Authorware depends on the type of video used. AVI,
Director, and MPEG movies are all loaded through the movie icon. Quicktime and Flash
movies must be loaded through the Insert menu (InsertMediaQuicktime or Flash). In
the former case, video is controlled through the Movie and Timing tabs of the Movie icon
dialog box, where concurrency, rate, number of times to play, number of frames to play
can all be modified. In the latter case, the movies must be controlled through the Xtra
itself. For now, it is best to plan to play all of the movie at the time it is called for rather
than attempting to control how much of the movie plays, etc.
What you’ve learned in this chapter has relevance to four factors of instructional design
and development: presenting information, guiding the learner, learner control, and
motivation. Understanding how these factors relate to sound, video, and animation will
help you make intelligent use of them in your instruction.
196
Presenting Information
While all forms of media can be used to present information, to be effective, the
information should match the strengths of medium you use to present it. Kozma (1991)
calls these the “cognitively relevant characteristics of their technologies, symbol systems,
and processing capabilities.” Animation can make use of text and graphics, and as such
can present the same kinds of information as a display icon. But the key distinguishing
element in animation is motion. The extent to which the content you are presenting
matches the motion element determines whether your animation enhances or distracts
from the learning process. If I am trying to illustrate a concept which involves motion
(the operation of a bicycle pump, for instance), my animation can enhance my verbal
description of the different steps and components of the process concrete.
Video’s strength lies in representing motion as well, but with higher fidelity than
animation. In cases where realism is critical, video is a better choice than animation
(although perhaps not always a better choice than still images). While video can be used
to present content (e.g., a talking head), it is rarely a better choice than text alone, which
is faster and cheaper to create, more under learner control, and easier to edit and modify.
One exception to this is when social, humanistic, and affective elements are important.
Some learners prefer a human element in their CBI/CBT, and providing content via
talking head is one way to provide that. Even so, video like this should be used sparingly,
and not as the main deliver method. If it is, you are better off developing video-based
instruction.
197
Audio can present content as well as text and may be appropriate for auditory learners, at
least as an option. Sound alone is rarely a good method for presenting content, however,
because it is linear, meaning the learner can only process it in the order it was recorded; if
they miss something and want to repeat it, they must listen to the whole sound again.
Text can be scanned and re-scanned at will, and allows for more learner control. Audio’s
real strength lies in representing content that is purely sound-based. Musical pitch
training, engine diagnostics by listening to the sounds of an ill-tuned engine, or
identification of birdsong are good examples of content that must be delivered by audio.
Guiding the Learner
Animation can be used to guide the learner in many ways. Your program will
undoubtedly have a section that provides and overview and orientation to your program
interface. Animation can be used to move a mock cursor around on screen to illustrate
processes for interacting with your program. Animation can also be used to draw
attention to different components of a complex display to ensure that learners are
attending to relevant portions of the instruction. Animation can also be used to help the
learner manage their learning. For instance, it is possible to help the learner build a
mental model of the content being learned one component at a time using a concept map
with several components to represent the mental model. As the learner completes a
section, you could provide an animation showing that component being added to the
overall model.
Video can be used to provide guidance by creating advisement. While using talking heads
exclusively to present content does not make effective use of the medium, the ability for
198
video to gain attention cannot be ignored. When there are elements in your instruction
that require special attention (such as common misconceptions that learners form), you
can use a talking head to gain attention and to help learners focus on specific areas. In
these cases, the video should refocus the learner’s attention to the content rather than
providing new content. Talking heads can also serve a similar function in regards to
metacognition, by providing information about the learner’s progress through the
instruction, suggested paths to follow, opportunities for remediation, etc. While these can
more easily and cheaply be accomplished via text, for some populations and content
video may also be appropriate.
Sound can provide the same kinds of guidance as video, but has an added ability. Adding
sounds to buttons provides feedback to the learner that their attempt to press a button was
successful. Buzzer sounds can be used to indicate that the learner’s action was registered
by the computer but is not allowed (such as when you try to close a window while a
dialog box is open, for instance). In the case of advisors, you may not want to force the
learner to view the advisement available. In that case, you might use a sound to indicate
that advisement or extra information is available to the learner; they can then choose
whether to access the that information.
Learner control
Video and audio can be used to help learners manage their instruction as with the
advisement options described above. But there is another aspect of learner control and
media that is too often overlooked. You should always strive to give the learner control
over the media you incorporate in your instruction except when doing so would
199
compromise your learning objectives. While it may seem neat to put lots of sound
feedback, audio versions of screen text, and video pop-ups throughout your instruction in
an attempt to reach all learners, doing so virtually ensures that your instruction will
irritate most of your learners at some point, since few of us prefer all modalities equally.
When you put these elements into your program, give the learner control over how many
mediums they get and how often they get them. The default should always be the least
number of mediums presented, with instructions to the learner on how to access
additional media when available.
Motivation
While intrinsic motivation is predominantly determined by multiple design components
(e.g., challenge, fantasy, control, and curiosity, Malone, 1987; Attention, Relevance,
Confidence, and Satisfaction, Keller & Suziki, 1988), the use of video, audio, and
animation can serve some of these functions through learner guidance, management of
learner control, and gaining attention. Making appropriate and judicious use of these
elements throughout your instruction can help make your instruction more motivating.
Using animation and video advisement to draw attention to critical attributes of the
instruction can help manage the level of challenge for learners so that they do not end up
frustrated. Using animation to signal the end of one section and the beginning of another
also helps the learner recognize when they are finished with one section and moving on
to another. The use of animation, sound, and video to gain attention in and of itself may
in some cases justify their use even when the same information could be conveyed in
another way.
200
Exercises
1) What does D.A.R.T. stand for? Describe what each stage of the process means and
why the sequence is important.
2) I want to create a scene where the main title of the program “flies” in from the right
side of the screen, followed 3 seconds later by my subtitle that “flies” in from the left
side of the screen.
a) Why won’t the following structure work?
b) Why won’t the following structure work?
3) If I want my title and subtitle in the description in question 2 to animate at the same
time (i.e., they come from different parts of the screen, move in different directions,
but do so at the same time), I need to set concurrency option of the first animation to:
a) wait until done
201
b) concurrent
4) I want to speed up my animation. Should I:
a) Change the rate or time to a higher number
b) Change the rate or time to a lower number
c) Change the rate to a higher number, or the time to a lower number
d) Change the rate to a lower number, or the time to a higher number
5) Why is it important to save your original sound files after you have placed them in
your Authorware program?
6) I want to play two sounds in a scene in my Authorware program. The scene I am
concerned with looks like this:
7) The first sound should start playing and continue right away to the next icon, which
displays some text in it. The second sound should start playing only after the first
sound is done playing, and should not continue on until the sound has finished. Which
of the following describes the correct settings for these two sound icons:
202
a) First sound Concurrency=Wait Until Done, second sound Concurrency=Wait
Until Done
b) First sound Concurrency=Concurrent, second sound Concurrency=Wait Until
Done
c) First sound Concurrency=Concurrent, second sound Concurrency=Wait Until
Done, Wait for Previous Sound checkbox is checked
d) First sound Concurrency=Wait Until Done, second sound Concurrency=Wait
Until Done, Wait for Previous Sound checkbox is checked
8) True or False: When adding video to a project, it is a good idea to store all your video
clips in a separate folder from your program so that you can copy them back and forth
from machine to machine.
9) Open the file you created in chapter 4. Add the following:
a) Download one of the introductory music sound files from the website and have it
accompany your title screen. This music should start before your titles appear on
screen, and continue while the titles appear.
b) Animate the main title so that it “flies” in from the right side of the screen. At the
same time, make your subtitle “fly” in from the left side of the screen. HINT:
Remember that the starting point of any object (like your titles) in an animation is
determined by that object’s location inside it’s display icon).
203
c) Download the sound file called “Welcome.wav” from the web site (you may also
record your own if you have the tools and desire to do so). Have this sound play
after the musical intro is done. Have your program pause for five seconds, and
then erase everything on the screen.
d) Download the movies “Flash_Intro” and “AVI_Intro” from the web site. Have the
Flash_Intro movie play in the middle of the title screen. Your title (when if
finishes animating) should end up just above the movie, and the subtitle should
end up just below the movie. Have the Flash_Intro movie erase after 5 seconds,
to be replaced by the AVI_Intro movie.
204
References
Keller, J. M. (1983). Development and use of the ARCS model of motivational design.
(ERIC Document Reproduction Service No. ED 313 001).
Kozma, R. B., (1991). Learning with media. Review of Educational Research, 61,(2), p
179-211.
Malone, T. W., & Lepper, M. R. (1987). Making learning fun: A taxonomic model of
intrinsic motivations for learning. In R. E. Snow & M. J. Farr (Eds.), Aptitude, learning,
and instruction: III.
Cognitive and affective process analysis (pp. 223-253). Hillsdale, NJ: Erlbaum.
205
Chapter 6: The Basic Interaction
Overview
Once you have completed this chapter, you will have learned approximately 75% of what
you need in order to develop interactive instruction in Authorware, and chapter 8 is
almost a no-brainer, so this number is really closer to 90%. Of course, there is a LOT
more to Authorware, and you will quickly find that you want to do more than you will be
able to do after completing the first 8 chapters of this book. Nevertheless, everything you
learn from chapter 9 on will be more or less an extension of what you have already
learned.
You are now able to add text, graphics, sound, and video to an Authorware program. You
are also able to animate objects on the screen, cause them to appear and disappear with
different effects, and at different times. Up until now, Authorware has not provided any
unique capabilities—any multimedia authoring program can accomplish what you have
learned so far, even Powerpoint! What has been missing to this point is interactivity.
Without interactivity (i.e., the ability for the learner to interact with, respond to, and
control the program), it is not possible to create meaningful instruction. We are all
familiar with large lecture-based classes in which 100 or more students attend lectures for
50 minutes at a time. Although the information is presented to us, without the opportunity
ask questions and apply the concepts, it is much harder to integrate the knowledge in
ways that are likely to result in long-term learning gains.
206
Yet even in large lecture classes, we normally demonstrate knowledge through tests and
papers, which are opportunities for us to take an active role in working with the
knowledge (e.g., applying it to real-world scenarios, re-organizing and making
connections between concepts in order to support a position or hypotheses, etc.).
These two types of interactivity, practice during learning and assessment of learning, are
critical to the design and development of effective CBI/CBT. There is a third kind of
interaction in CBI/CBT as well; interactions that help the learner navigate from place to
place in your program (e.g., forward and back buttons). Interactions are the heart and soul
of Authorware; this is where the program distinguishes itself from it’s many competitors.
Interactions are icons that allow you to build in opportunities for the learner to responds
to your instruction. As practice items, they can allow the learner to answer questions,
practice applying concepts and skills, drag terms to their corresponding definitions, etc.
As assessment items, they can measure performance on the specific objectives you
identified for your instruction. In both cases, the interaction opportunities can include
clicking buttons, clicking objects or words on screen, typing in text, dragging objects on
screen, selecting menu items, and several other (less familiar) options. Authorware makes
the process of creating interactivity far more simple than its closest competitors and, most
importantly, makes the process of tracking learner responses (e.g., correct, incorrect, time
spent) nearly automatic.5 This chapter will focus on building basic interactions. We will
5
Nearly, in the sense that you must actually tell Authorware when you create
different responses that you want to keep track of them.
207
examine seven of the more common response types. The other, more complicated
response types will be covered in depth in Chapter 12.
Objectives
•
Add Button, Hotspot, Hot Object, Pulldown Menu, and Text Entry responses to
your program,
•
Set Time Limits and Tries Limits for each interaction,
•
Create feedback for the learner based on their responses,
•
Keep track of learner performance (e.g., number of correct vs. incorrect answers)
in your program.
Terminology
There are some terms used in Authorware and this chapter which are important to
understand prior to studying interactions. The first term, interaction, has already been
partially defined as an opportunity for the learner to interact with your program. One key
distinction, however, is that while there is an interaction icon in Authorware, it requires
several other icons to build interactivity into your program. In this way, it is similar to
animation icons; if you drag only an animation icon to the flowline, and not a display
icon to go with it, you will not have any animation.
An interaction must have one or more responses associated with it. Responses are the
ways that your learners can interact with (respond to) your program. If you want them to
208
navigate to the next scene by clicking a button, you must add an interaction icon and then
a button response type to that interaction. Depending on what kind of response you want
the learner to make, you select different response types (e.g., hotspot, text entry, etc.).
Anatomy of an Interaction
As I mentioned earlier, and interaction in Authorware is actually made up of several
different icons, only one of which is the actual interaction icon itself. In addition to the
different icons that are needed, there are several settings and steps along the way that are
required for an interaction.
To help you remember these, I have created the mnemonic DIRECT, which stands for
Display, Interaction, Response, Evaluate, Control, and Track. It is not strictly necessary
to create interactions using all of these options, nor in the prescribed sequence. BUT.
Given that
•
Interactions are key to building CBI/CBT, and
•
Interactions require several steps and icons, and
•
Five years of experience teaching students to use Authorware has convinced me
that not following this sequence and process when first learning Authorware can
produce disastrous results
I highly recommend that you stick to this approach until you have developed an entire
instructional unit in Authorware and are comfortable enough with how interactions work
that you can begin bending the rules.
209
As we go through the basic anatomy of an interaction, I will provide descriptions and
explanations of each step. At the end of each section, I will ask you to create that step in
Authorware. If you prefer to read this chapter prior to attempting to build an interaction
(not a bad idea in any case), ignore these requests until you are at a computer. Otherwise,
you may want to stop reading now, move to a computer and launch Authorware so that
you will be ready to perform each step as it comes up.
Heads Up: Don’t use the program you have been building as part of the chapter exercises
to build this practice interaction. Instead, create a new file so that you won’t inadvertently
“break” your existing program as you practice.
Let’s start by looking at what a completed interaction looks like. Figure 21 is an example
of a completed interaction. Keep in mind that this is just one possible type of interaction,
in this case a question that the user must answer by clicking on one of four buttons. As
we look at different response types later in this chapter, you will learn about other kinds
of interactions.
Figure 21. Example of an interaction that asks the learner a question and gives them four
possible answers to choose from.
210
This interaction is included on the web site; if you have access to the Web or have
already downloaded the chapter files for this chapter, you may want to stop here and run
the file (Ch_6_Fig_21) to see what the final product looks like. Keep in mind that the
example used is designed to illustrate a point, and is thus quite plain and boring; it is
NOT intended as good example of what your screens and interface should look like!
When you run the program, you see the question itself (“What kind of program metaphor
does Authorware use?”) and the four choices to choose from (Card-based, Icon &
Flowline, Cast/Timeline/Stage Metaphor, What is a meta for?). The question itself is
typed inside the display icon at the top of the flowline; when Authorware encounters the
display icon, it displays the text on the screen and moves immediately on to the
interaction icon.
When Authorware hits the interaction icon, it knows to stop and wait for the learner to
perform some action. In fact, Authorware cannot move on down the flowline until the
learner makes a response that allows it to do so. The actions that the learner can perform
are determined by the response types displayed to the right of the interaction icon. In this
case, these responses are buttons that the learner can click. Note that it is the responses
themselves that show up on screen, not the interaction icon itself—it is there to signal to
Authorware that you want to build in some kind of interactivity.
211
Heads Up: A response is actually made up of two components: the response type
(button, hotspot, etc.) and the icon connected to that response type:
The response type is represented by the shape at the top of each response on the flowline
itself. Each response type has its own shape; in the example above, this is an oblong
shape, which represents a button response. The icon connected to each response reflects
the feedback or action that occurs when the response is selected (triggered). Most
commonly, this icon is where you place your feedback to the learner (“Good work, you
got that one right”), although as you will see later, all kinds of activity can take place as
part of a response. Together, the response type and the icon connected to it form a
response.
When the learner clicks on one of the wrong answers, they get feedback that says “No.
Try again.” This continues until they select the correct answer, at which point it says
“Good work. Click continue to move on.” But how does Authorware know where to go
when the learner selects a response? How does it know what is correct or incorrect? And
where does that feedback come from?
The answer to the first question has to do with the flowline through the interaction.
Notice that the response types to the right of the interaction are all connected by a line,
212
and that this line runs across the top of and through each response. This line is an
extension of the flowline itself, which now runs through every response in this
interaction. Let’s examine this flowline in more detail, because it contains the key to
understanding how Authorware works with an interaction.
The flowline extends straight out to the right from the point of the interaction across all
responses, makes a 90-degree turn up and then another 90-degree turn left and back to the
flowline, creating a circle. So Authorware hits the interaction, follows the line out to the
right until it has seen (and displayed) all the responses (buttons, in this case), at which
point it runs back to the flowline and waits for the learner to select one of the responses.
This is key, because Authorware will stay in this “loop” until the learner selects a
response that allows Authorware to exit the interaction.
To understand how and when Authorware knows to exit the interaction, we need to
examine the flowine’s connections to and through each response icon.
Tip: Those of you mechanically inclined may find it useful to think of an interaction as
an electrical circuit diagram. The interaction itself is a closed circuit, while each of the
response icons attached to the interaction represent a switch, or gate. Selecting a response
extends the circuit down into the response icon. Depending on which direction the
response is set to, it either routes the power back up and around into the interaction (as
with Answers 1, 2, or 3) or out of the interaction (as in the case with Answer 4).
The lines that extend down from each response type (the shape on the flowline at the top
of each response) represent the paths that the flowline can take IF that response is
triggered (selected). When Authorware first encounters our interaction in the example
213
above, it makes a loop across the top of each response, comes back to the flowline, and
waits. As soon as the learner selects one of the buttons, Authorware immediately follows
the flowline down into that response icon, in this case a map, does whatever it finds there
(displays text or graphics, plays sounds, or whatever else is inside the map) and then exits
out the bottom of the response. Depending on which direction the flowline is pointing (as
indicated by the directional arrows), Authorware will then either exit the interaction and
go back to the main flowline (as it does with “Icon & Flowline” in our example) or return
back through to the top of the interaction where it will wait for another response (as it
does with the first three answers).
Heads Up: If you were paying close attention to the program when you ran it, you may
have noticed that the order of the button on the screen do NOT match the order of the
responses on the flowline. This is because you can place your responses on the screen in
any order you want, regardless of how they appear on the flowline.
Tip: It is not necessary to use map icons for your responses—any icon except the
decision icon and the interaction icon itself can use for a response. I use and recommend
maps because that way I can have more than one thing happen in each of my responses
(e.g., I can play a sound AND display some text feedback by placing a sound and display
icon inside my map). In the example here, I could have used a display icon instead of a
map, since most of my feedback consists only of text.
So now we know how Authorware knows which way to go when different responses are
triggered. The last piece of the puzzle is determining whether a response is correct or
incorrect. One common misconception people have when first learning Authorware is
214
that they mistake the feedback (“Right,” or “Wrong”) for determining whether a response
is correct or not. Your feedback tells the learner whether they were right or wrong, but
Authorware can’t read the contents of your display icon to see if it should count that
response as a correct or incorrect response. And you want Authorware to keep track of
this, because it will allow you to capture performance data that you can use to evaluate
your instruction (e.g., number of objectives mastered), provide feedback to the learner in
the form of final scores at the end of modules and units, and make decisions about how to
proceed (e.g., provide remediation to the learner in areas that they have not fully
mastered yet). The way that you tell Authorware how to score responses is determined by
the symbol to the left of each response name (+, -, or blank). When you create a response,
Authorware automatically creates a title for that response and places it off to the right of
the interaction (“Untitled” is the default title until/if you change it). The name of the
response closest to the interaction icon itself will be the first title on the list at the right,
with each successive response title appearing below. In our case, the titles of each
response determine the labels that appear on each button. The symbol to the left of each
title tells Authorware whether it should count that response as correct (+), incorrect (-), or
not judge it at all (a blank space). So Authorware will count the response “Icon &
Flowline” as correct, and all the others as incorrect.
By this point, your eyes may be glazing over and you may be seriously considering
whether should just stick with powerpoint and not get into CBI/CBT at all. Never fear;
this is a normal reaction. If Authorware were super easy to learn, everyone would do it
and we wouldn’t get paid nearly so much to create.
215
The reason this section can be a bit overwhelming is that interactivity itself is a
complicated process—ask a C++ programmer what is involved in creating the interaction
above! Believe it or not, Authorware makes this process as simple as it is possible to
make it—the difficulty comes in learning the terminology and thought process behind the
way it does it. Remember also that interactivity is the heart and soul of Authorware, and
so represents the largest single chunk of learning you must do when learning Authorware.
To make it easier to process all this information, let’s revisit each element of an
interaction in more detail, using the acronym DIRECT to help us manage the process of
building a basic interaction.
Display (DIRECT)
The first element of a basic interaction is a Display icon. This is where you create the text
and graphics objects that you want to display to the learner. In its simplest form, this is
where you would type a question you want to have the learner answer along with any
instructions about how to proceed (e.g., “click the continue submit when done”). It is
important to remember that this will be text only, and that when the learner responds to
your request they will be selecting responses on the interaction icon itself, NOT your
display icon.
In some cases, you may need more than a display icon. For instance, if you want to
animate something prior to presenting the question, or you want to have the question read
out loud, you would need to add an animation icon or a sound icon, respectively. These
actions are accomplished in exactly the same fashion you already know; remember that
we are building a basic interaction right now in order to keep the complexity low.
216
Create a display icon that has the following in it:
•
Text that reads “What color is the square on this page?”
•
A red square, a yellow circle, and a blue circle, each centered below the question.
Interaction (DIRECT)
The next step is to place an interaction icon below the display icon. There are several
options that you can set to control how your interaction behaves, but you actually don’t
need to modify any of them to create the kind of basic interactions we are interested in
now. For now, just add an interaction icon to the flowline beneath your display icon.
Heads Up: Although I have not asked you to set any of these options (nor do I
recommend that you do so at this point), it is prudent to describe the process involved in
doing so, because it differs from other icons.
If you double-click on an interaction icon, you will get a blank design window. This
window represents what is inside the interaction icon. Macromedia suggests that you type
your question inside the interaction icon, rather than a separate display icon. While it is
certainly feasible to do this, in my experience it can be confusing for beginning learners
(in fact, I never do it myself either). I find it helpful to think of my interaction icon
separately from my text and graphics objects. Also, there are times when you need more
than one element for your question (for target area responses, or if I want to animate two
elements of my question, for instance). In such cases, you would have to put one element
inside the interaction icon and the other elements in their own display icons, which can be
confusing.
217
The main reason I bring this up, however, is that in order to set the options for your
interaction, it is necessary to right-click on the icon and select properties from the popup
menu (ModifyIconProperties and Ctrl-I also work). For now don’t worry about
either the inside of the interaction icon or setting its properties.
Responses (DIRECT)
What you have created to this point is a place to request the learner to do something (e.g.,
answer a question, match concepts together) by using one or more display icons, and told
Authorware that you want to provide a way for the learner to interact with the program by
adding an interaction icon. What you need to do now is tell Authorware how the learner
will interact with the program; do you want them to click a button? Drag something on
screen? Select something from a menu? You do this by adding responses to the
interaction.
There are several different types of responses that are possible, some more familiar to
you than others. While Authorware allows you to build complex interactions, most
people find it a bit overwhelming to master them all when first learning Authorware.
Accordingly, I will only discuss seven of the eleven different types of responses in this
chapter. These seven types represent the most common types of interactivity most people
want to be able to incorporate. Chapter 12 will discuss the additional four types of
responses as well as some of the more complex options and settings you can use.
It is important to understand what each of these 7 response types is called and what it
does. Table 3 presents a description of each type along with examples of how each looks
to you and to the learner. Note that for simplicity’s sake, I have used small screen shots
218
from a program with a plain white background color for the “on screen” images; the
background colors, text, graphics, etc., will vary with each program. I have also
organized them by the description of the response rather than the name of the response
type, because Authorware’s naming conventions are not always intuitive.
219
Table 3. Description and names of response types in Authorware.
If you want to have
the learner…
then you use
this response
type…,
which looks like this to…
you, on the
flowline:
click on one or
more buttons.
you, on screen:
Button
the learner:
Same
(Default button: can be
customized to look like
anything)
click on one part of
the screen.
Hotspot
[hotspots are invisible to
the learner]
or
(Same)
Hot Object
(or any graphic or text
object you choose)
select something
from a menu.
Pulldown
Menu
(Same)
(menu is at top of screen)
type in their answer
(e.g., a short
answer or fill in the
blank type
question)
Text Entry
get a certain
number of chances
to answer the
question.
Tries Limit
Not visible on screen
(Same)
Give the learner a
certain of time to
answer the
question.
Time Limit
Not visible on screen
(Same)
(You can choose any
color background you
want for the text box)
The process for adding response types is identical for all types of responses: drag an icon
to the right of your interaction icon and release it. The first icon you drag onto you
220
interaction in this manner will “snap” onto a new line that extends out from interaction
icon, and you will be prompted to specify which kind of response type it should be. See
Figure 22.6 You can add as many responses as you want to any interaction, and they can
be of any response type you desire (i.e., you can mix and match as many as you want),
BUT; each subsequent response you create after the first one will automatically take on
the exact properties and settings of the first one. To change any of these to another
response type, you will have to open that response types settings dialog box (done by
double-clicking on the symbol at the. Once you add a sixth response to an interaction,
Authorware will create a scrolling window wide enough to view 5 responses at a time; to
view the others you must use a scroll bar to scroll through the responses. This is done to
prevent your interaction icons from taking up too much screen space, thus making it hard
to view libraries and other windows at the same time.
6
Remember that there are two components to a response: the response type, and
the icon you dragged to the right of the interaction! The response type is what tells
Authorware whether to display a button, a hotspot, a hot object, etc. The icon itself
represents what should happen when the response is triggered.
221
Figure 22. Dialog box for specifying response type for interactions.
You can drag any icon except an interaction icon and a decision icon to the right of an
interaction to turn it into a response, depending on what you want to have happen when
the learner chooses a particular response. For instance, if I want to have some text appear
on screen when they click a button, I could drag a display icon to the right of my
interaction. Then, when they click the button, the text I type inside that display icon
appears on the screen. Similarly, if I wanted a sound or movie to play when they clicked
a button, I could drag a sound or movie icon to the right of my interaction and make them
button. If I want the program to jump to another place in the program when the learner
selects a response, I could drag a navigation icon to the right of my interaction.
Nevertheless, I recommend that you use map icons for your responses so that you have
the option of placing more than one icon in a response (e.g., have a sound play, some text
appear, and something animate; or even ask a follow up question by putting another
interaction inside a response!). While you may not make much use of this feature now,
this will help you avoid common problems later when you start working with more
complex interactions.
Each response type has its own settings, options, and abilities. Although the process for
adding each of them is basically the same, it is important to understand the individual
options available to you for each one. The following sections will examine the process
and settings for each response type.
Customizing Responses—an overview
222
There are several settings and options you can adjust to customize how your responses
look and behave. All of these are accessed by double-clicking on the response type
symbol (see the Heads Up on responses, earlier in this chapter). Double clicking on the
response type symbol (you have to click right on the symbol) brings up a dialog box
similar to the following:
Figure 23. Response Dialog Box.
Note that the dialog box in the figure is specific to a button response, which is the first
response we will examine. There are several elements that are common to all response
type dialog boxes, however, and it may be helpful to examine these common elements
prior to looking at specific responses.
The top box is the title of the response, and changing the text here will change both the
name of the icon on your flowline and the name that appears on the response itself. In the
case of buttons, that means the label of the button will change. In the case of other,
223
invisible responses (e.g., hotspots), the label of the hotspot will change, but only you can
see that title when authoring your program; to the user, it is invisible.
The drop down menu below that box allows you to change the response from the current
state (in this case, button) to any other type of response (e.g., hotspot, menu, etc.).The
next four boxes allow you to specify the exact size and placement of the response. The
value represent x and y coordinates (and you thought you’d never use that high school
math!) on the screen, with 1,1 being in the upper left corner. While most re-sizing and
placement can be accomplished by “stretching” and dragging the response with your
mouse, there may be occasions where you need to be more specific (e.g, you want to
make several responses exactly the same size, or line up responses perfectly over several
screens). The box labeled Key(s) allows you to specify a keystroke or keystroke
combination that will trigger the response. You are already familiar with this process
from menu shortcuts in many programs, which allow you to select a menu item by using
keys (e.g., control-C copies whatever is currently highlighted to the clipboard).
Tip: Using Key(s). Space does not permit a complete listing of syntax and labels used in
this box, but typing the letter “k” would allow the user to trigger this response by hitting
“k;” typing in Ctrlk will allow the user to trigger the button by holding the control key
down and pressing k. Keys are case sensitive, so if you want the user to be able to select
either K or k, you must include both by using the symbol “|” which is the universal
symbol for “or” in Authorware.
You may have also noticed that there are two tabs in figure 23, and that the options we
have been discussing are all associated with the Button tab. Every response option dialog
224
box will also have a response tab. Selecting this tab will give you a dialog box that looks
like this:
In my experience, this dialog box is where most students become confused. There are
really only two things you need to change via this dialog box: “Scope” and “Erase.” All
the other options can be set more intuitively from the flowline itself. Making the “Scope”
Perpetual makes your response permanent; it will always be available to the learner at
any point in your program. By default, responses are active for only as long as the learner
is in your interaction; as soon as they exit and move on, the responses disappear.
Perpetual responses are useful for navigation (main menu, quit, etc.) and accessing help
features (buttons or pull-down menus).
The Erase setting tells Authorware what to do with the contents of a given response once
it is done. Setting your response to erase After Next Entry will cause Authorware to
continue to display everything in your response until the learner makes another response
225
(useful for “try again” feedback). Setting your response to erase Before Next Entry will
cause Authorware to erase everything in your response as soon as it leaves the response.
Setting it to Don’t Erase prevents Authorware from erasing the contents until you
specifically place an erase icon in your program that is set to erase the contents. Until you
get used to interactions, I recommend that you select After Next Entry.
That’s about all the features that are common to most response types. Now lets look at
each response and its options in more detail.
Buttons.
Buttons are probably the most common response type used in interactive instruction,
whether for navigation (forward, back, main menu, help, etc.), to access extra content
(“click here to see a video example….), or to answer questions for practice or during
assessment. They are also the most familiar to us and are thus among the easiest response
types to master.
The name you give each button response determines both the text that appears on the
button (called the label), and the title of the response itself (on the flowline and in the title
box—see figure 23). Clicking on the button while the piece is running will cause
Authorware to follow the flowline down through the icon attached to that response,
perform whatever actions that icon requires, and exit back out the bottom in the direction
you specify with the arrow (covered toward the end of this chapter). If the icon is a map,
you can specify several things to happen when that response is triggered by placing
several icons inside the map attached to that response.
226
Arranging Your Responses on the Screen
You can view your buttons and move them around on screen in one of two ways: opening
the interaction icon or running the piece.
If you open the interaction icon (double-click), you will see every response icon attached
to that interaction. By default, they will all be lined up in the upper left corner of the
screen. You can drag these buttons around on the screen to arrange them in any manner
you wish—doing so has no effect on the order they appear on the flowline to the right of
your interaction icon. If you use this method to arrange your buttons (or any response)
you will not be able to see any other screen elements you may have built in to your
interaction (e.g., screen titles, backgrounds, text boxes, your question, etc.), since you are
are really looking at the contents of your interaction icon. The tip mentioned earlier about
holding the shift key down while you open each icon you want to see (e.g., the display
with your question in it, the display with your background, and your interaction icon),
you will be able to see the contents of all those icons while you arrange your buttons on
screen. The other way to arrange your buttons is to run your piece, press Ctrl-P to pause
the program, and drag your buttons around as needed.
There are three areas that are unique to the button response options dialog box: Button
library (upper left corner window), Options, and Cursor. The button library allows you to
create custom buttons, with rollovers, sound effects, and special graphics. It is a very
powerful feature of Authorware, but can be overwhelming when you are still mastering
227
the basics of interactions. For this reason, I will not cover customizing buttons until
Chapter 12.
There are two settings that can be made to the Options sections: Make Default and Hide
When Inactive. The Hide When Inactive option will be discussed in Chapter 12, after you
have learned about variables. The Make Default option for a give button tells Authorware
that that button is the default for the given interaction. This means that hitting the
Enter/Return key on the keyboard will trigger that button. You are familiar with this from
dialog boxes in many programs in which there are more than one button to choose from,
but one of them has a heavy line around it or is otherwise highlighted. For instance, when
you attempt to move a file in Windows 9x to the recycle bin, you are presented with a
dialog box asking if you are sure you want to delete the file. Of the two options (Yes and
No), “Yes” has a dotted line around it—hitting return triggers that button.
The Cursor option allows you to specify a cursor to display when the learner has placed
his or her mouse over the response. This is most familiar to you from the Internet, where
placing your mouse over a link causes the mouse to change to a hand. If you select the
button labeled “…” next to Cursor, you will be able to select from several cursors,
including a pointing hand.
Power Tip: It is also possible to create a custom cursor using a cursor editing program
and selecting the “Add” from the cursor dialog box. The cursor should be no larger than
32 pixels by 32 pixels square, and must be saved in the .cur format. Several good
shareware program exist for creating and editing cursors. Icon Editor, by Herman &
228
Associates is a popular shareware program for doing this, and can be found online at any
shareware website such as www.shareware.com.
Hotspots.
Hotspots are invisible boxes or rectangles that you can place on the screen “over” other
elements on the screen. An example might be when you have an image of a piece of
machinery with several different components that you want the learner to be able to
explore. You could arrange several hotspot responses, each over a different component of
the machine, so that the learner can select different parts of the image to get definitions
and descriptions of that component. Similarly, you could turn an image into a menu in
such a way that selecting different parts of the image takes the learner to different parts of
the program.
Hotspots are particularly common in games, where the player explores their environment
with the mouse, which changes when over an object or area with which the player can
interact. Clicking then allows the player to examine the object, move to another part of
the game, etc.
Hotspots can be moved and resized in a similar fashion to buttons, but because they are
‘invisible’ to the learner, you cannot see them while the piece is running. Instead, you
must either pause the piece (at which point they show up as dotted rectangles on the
screen) or view them by opening up the interaction icon itself.
Heads Up: This is one example of why it is important to get into the habit of naming
your icons as you create them. If you open up an interaction icon with five different
hotspots attached to it, each of which is named “Untitled,” (as they are by default), you
229
will have no way of knowing where each hotspot should be placed on the screen.
Remember that the order of icon on the flowline does NOT reflect their placement on the
screen, so name each icon as you create it, and make sure that name will mean something
to you when you are looking at them on screen!
The Hotspot response options dialog box appears in Figure 24, below.
Figure 24. Hotspot options dialog box.
There are only three additional options to set in a hotspot response: Match, Highlight on
match, and Mark on Match. Under the match dropdown menu, you can select from
Single-click, Double-click, or Cursor in Area. These settings determine what action the
user must take to trigger the hotspot. Setting Match to Single-click means the response is
triggered when the learner clicks anywhere in the hotspot. Setting Match to Double-click
230
means the response is triggered when the learner clicks twice anywhere in the hotspot.
Setting Match to Cursor in Area means the response is triggered when the learner places
the mouse anywhere over the hotspot. You can think of this last option as a roll-over, in
which some text, sound, or image appears on screen when the mouse is “rolled over” an
area on the screen.
Tip: When using hotspots, it is important to remember that the learner cannot see the
actual hotspot itself, only the image on the screen over which you have placed your
hotspots. With roll-over hotspots, the learner gets immediate feedback when the move the
mouse over the hotspot, but with hotspots set to match when clicked once or twice, the
learner will have no idea if they are in the right place or not until the actually click and
something does or does not happen. This can be frustrating for the learner since they may
potentially have to click tens or even hundreds of time on screen in order to find the
hotspot. For this reason, it is important to always provide instructions and feedback to the
learner about what they should do. The best way to do this is to set a cursor to change
when the learner is “over” a hotspot, (like a hyperlink on a Web page). This way, they
can “wave” the cursor around the screen until they see the cursor change, indicating they
can click in that area.
The Highlight on Match and Mark on Match are ways for you to provide additional
feedback to the learner about their performance. When Highlight on Match is selected,
triggering that hotspot will cause the hotspot area to change color briefly, signaling that it
has been triggered. When Mark on Match is selected, a small check box will appear in the
upper left corner of the hotspot; triggering that hotspot will cause that box to permanently
turn black, indicating that the hotspot has been triggered.
231
Hot Objects.
For all intents and purposes, you can think of Hot Objects and Hotspots as nearly
identical. As far as the learner is concerned, interaction with either one is the same. The
only differences are that Hotspots are invisible and must be square or rectangular, while
Hot Objects are actual visible objects (text, graphics, movies, etc.). The main reason you
might use Hot Objects instead of Hotspots would be that the area of screen you want to
make “hot” is not a square or rectangle, or because you are unable to arrange a series of
hotspots on screen without them “overlapping.” In the first case, imagine you have round
shape on screen that you want the learner to select. If you used a Hotspot, you could
stretch the Hotspot so that the round shape was inside the Hotspot, but the corners of the
hotspot would extend beyond the round shape. This would create a situation where the
learner could click on the corner area (which extends beyond the round shape) and still
trigger the response. In the second case, imagine a series of areas close together on screen
that you want to make “hot.” It might not be possible arrange your Hotspots to cover each
area without overlapping, meaning the learner could click on one area but accidentally
trigger an adjacent hotspot.
Hot objects can be any shape or size, determined only by the size and shape of the object
itself. What’s more, if you change the size of the object itself, you have automatically
changed the size of the response, since they are one and the same. The process for adding
a Hot Object differs only slightly from other responses. When you set a response type to
be a Hot Object, the dialog box changes to include a message: “Click an object to make it
the hot object:”
232
Figure 24. Hot Object options dialog box.
For this reason, you MUST create the Hot Object response(s) on your interaction and
then run the interaction. When Authorware hits the interaction, it will pause and bring up
the dialog box, at which point you can click on the object you want to be the hot object.
All other available options function identically to other responses.
Pulldown Menus.
Pulldown Menus differ from other response types in that their primary use is for
remediation or navigation between sections of the program. They are most often
perpetual (permanent) kinds of interactions, and usually appear in the beginning of the
program. Nevertheless, they can be placed anywhere in the program and can be active
only for the duration of the current interaction if desired. While it is technically possible
to put Pulldown Menu responses on an interaction with other kinds of response types, it is
233
highly unlikely that you would need to do so. In any case, for now you should think of
Pulldown Menus as a separate kind of interaction.
The process for creating a pulldown menu item is as follows:
1) Drag an interaction icon to the flowline
2) Name the interaction icon whatever you want your menu to be called; this is what
will appear in the menu bar itself. For instance, if you want a menu called
“Navigation,” name the interaction icon “Navigation.”
3) Drag one map icon for each menu item you want to have on your menu, selecting
Pulldown Menu as the response type. Make each response “Perpetual” in scope if you
want it to be available throughout the program. For instance, if I want to have three
selections on my “Navigation” menu, I would add three map icons to my interaction.
4) Name each response whatever you want that item on your menu to be called. For
instance, I might name my three responses “Section I,” Section II,” and “Section III.”
5) Place whatever you want to have happen when each item is selected inside the
corresponding map. This could be a navigation icon (covered in Chapter 7) or any
kind of text, image, sound, movie, etc. that you want to occur.
The Pulldown Menu response options dialog box appears in Figure 26, below.
234
Figure 24. Pulldown Menu options dialog box.
There are no options to set beyond this, but a few words on the dialog box are in order.
The title box at the top reflects the name of the response as does the Menu Item box
below it, and will be the name of the menu item itself. The box in-between, labeled
“Menu,” reflects the name of the interaction icon itself, which forms the basis for the
name of the menu on the screen.
Heads Up: Everyone gets this confused in the beginning, so it is worth emphasizing that
the Menu name comes from the interaction icon, and the items on the menu come from
the names of the response icons themselves.
Text Entry Responses
Text entry responses can be somewhat confusing in their implementation. This is because
while every other type of response has one corresponding object on the screen (e.g., one
235
button for each response, one hotspot for each response, etc.), there is only one text entry
field on the screen, no matter how many different text entry responses you add to the
interaction. There is a kind of logic to this, however, if you think about it. We usually
only want to provide one place for someone to type, but we want them to be able to lots
of different things in that space. With the text entry response, the responses you add to
the interaction represent the different things that you anticipate the learner typing. For
instance, in your program on Mt. Rushmore, you might put a text entry response for one
of your questions, such as “Who was the first president of the United States?” You might
anticipate that the student could type in the name of any of the four presidents or
something completely different. Since you can anticipate the names of the presidents, you
would put one text entry response (e.g., one map to the right of the interaction) for each
president. Since you cannot anticipate ALL possible responses, you would also want to
put one additional text entry response that would match anything else they might type.
The process for doing this is similar to all response types: you drag one icon (I suggest a
map) for each response you want over to the right of the interaction icon. And just as with
buttons, you name these responses for the answers they represent. The difference is that
instead of the name of the response showing up on screen (as it does for buttons),
Authorware uses the name of the response to determine if it matches what the learner
typed in. If it does, then Authorware drops down into that response map (where you can
provide feedback about the learner’s answer). For this reason, you must name your
responses exactly as you expect (or desire) the learner to type in their answer.
So, in our earlier example, you would have one response for each president, named
George Washington, Thomas Jefferson, Abraham Lincoln, and Theodore Roosevelt. If
236
the learner types one of these names in, Authorware will “trigger” that response and drop
down into the response map. But what happens if they type in Herbert Hoover (or any
other text that differs from the responses you created)? This is why you need that
wildcard I mentioned earlier. Authorware reserves the asterisk character to mean “any
text or number.” Therefore, you can place an additional (in this case fifth) text entry
response as the LAST response on the interaction, and name it *.
Heads Up: You must make this wildcard response the last response because of the way
Authorware flows. Remember that it looks top down, left to right. This means that when
the learner types in their text, Authorware will look at the first (leftmost) text entry
response to see if matches. If it does not, it will continue down the line from left to right
until it finds a text entry response that it does match. If you put the wildcard (*) anywhere
but last, Authorware will immediately match that response as soon as it sees it and will
NOT continue down the line (i.e., to the right).
You can set a host of options for the text entry response, including how it should treat
partial matches, capitalization, punctuation, and spelling, for instance. These are all set
via the response options dialog box, and are fairly self-explanatory. One final note on text
entry responses: Whatever the learner types in is stored in a variable called EntryText.
You can use this variable in conjunction with another variable to keep track of what the
learner types. You will learn how to assign values to variables in Chapter 9, but for now
just remember that EntryText is reset everytime the learner types in a text entry box, so if
you want to save each thing they type, you have to transfer what is in EntryText to
another variable so that it is not lost. A good example of when you might want to do this
is when you have the learner type in their name. You can then store their name in a
237
custom variable that you can embed in the instructional text throughout your program
(e.g., Rick, now that you have finished section 1, …..). This is a nice way to personalize
your instruction.
Tries Limit/Time Limit.
Tries Limit and Time Limit are unique kinds of responses in that they actually represent
limits you place on the learner in regards to the current interaction. If you want to limit
the learner to two attempts and/or 30 seconds in an interaction, you would use a Tries
Limit set to 2 and/or a Time Limit set to 30 seconds. Tries and Time Limits should be
placed at the far right of the interaction, after all possible responses, so that you don’t get
them confused with your other responses when setting them to “Correct” or “Incorrect,”
(see “Tracking responses,” later in this chapter). The Tries Limit and Time Limit
response options dialog boxes appear in Figures 28 and 29, below.
Figure 28. Tries Limit options dialog box.
238
Figure 29. Tries Limit options dialog box.
As you might expect, determining the tries or time limit you want to set is a matter of
typing a value in the appropriate box. With the Time Limit, you have three additional
settings to choose from. The Interruption drop down box is used to determine what
happens to the “clock” if the learner jumps to another part of the program using some
kind of perpetual interaction (like the Pulldown menu described above). You may want
the clock to keep running while they are elsewhere (Continue Timing), to pause but pick
up where it left off when they return (Pause, Resume on Return), pause the clock and
reset it when they return (Pause, Restart on Return), or pause the clock and restart the
clock only if it has not already expired (Pause, Restart if Running). Don’t worry about
memorizing all this right now; it is unlikely that you will need to change it from the
default (Pause, Resume on Return).
239
The two options, “Show Time Remaining,” and “Restart for Each Try,” are easier to
understand. Selecting “Show Time Remaining” will cause a small clock to appear on the
screen to show the amount of time left to respond. Selecting “Restart for Each Try” will
cause the clock to reset itself after each response attempt by the learner.
That is all you need to know about response types for now to create the more common,
basic interactions you are familiar with. Now we’ll return to examining the rest of the
process for creating an interaction.
Evaluate (DIRECT)
The last section detailed seven of the most common response types. Your selection and
modification of responses to your interaction represents the third step in the overall
process of building an interaction: Display icon(s), Interaction icon, Responses. The next
step is to Evaluate the responses in your interaction, that is, determine which are
“correct” and which are “incorrect.”
A response in Authorware is counted as correct if it has a plus (+) sign by its name on the
flowline. Remember that responses are listed to the right of your interaction in a list form
from top to bottom, in the order they appear on the interaction from left to right (got
that?) A response is counted as incorrect if it has a minus (-) sign by its name, and not
counted as correct or incorrect if it has nothing by its name.
Macromedia suggests you set the response status, as this is called, through the response
tab in the response type options dialog box. I find it MUCH simpler to use the shortcut
they have built in to set this on the flowline. To do so, you need only hold the control key
240
down and click in the space to the left of each response title. Every time you do so, the
response will change once; simply keep clicking until the response symbol (+, -, or blank)
appears. That is all you need to do to set each response to correct or incorrect (or not
judged). Authorware will automatically keep track of all correct and incorrect responses
for you.
Heads Up: Setting the response status as described above has NOTHING to do with the
feedback you provide to the learner; these are two separate events. You must still provide
whatever feedback you want the learner to have inside the map icon for each response.
Setting the response status only tells Authorware what the status of the response is, NOT
the learner. It is possible (although not desireable!) to set the response status to correct
(+) and yet provide feedback to the learner that says “No. Try again.”
Control (DIRECT)
Once you have set the response status for each response(Evaluated them), you need to
Control the flow out of each response. You may remember from the section on responses
that you can set a response to Continue, Try Again, Return, or Exit the interaction. Return
is only used for perpetual responses such as Pulldown menus, so don’t worry about it for
now. Each of these corresponds to the direction of the flowline arrow through and out
each response. Again, while it is possible to set this through the response tab of the
response type options dialog box, it is much easier (and more intuitive) to do so from the
flowline. This is accomplished by holding down the Control key and clicking your mouse
BELOW each response icon, which in the example we have been looking at are maps. By
default, the flowline continues through the response (the map), out the bottom, turns back
241
away from the main flowline and returns to the interaction, allowing the learner to try
again. A Control-click on this line will cause it to cycle through the options one at a time;
keep clicking until the flowline points in the desired direction. It will take some time
before you get used to all of these nuances, but for now you can simplify it by making all
wrong responses point back into the interaction (Try Again), and all correct responses
point toward the main flowline (Exit Interaction). You will notice a third direction for the
flowline as you cycle through the options in this manner; one where the flowline doesn’t
actually come out of the response but seems to point straight back up. This is the
Continue option, which tells Authorware to continue search for additional response
matches rather than just returning to the interaction and waiting for another response.
Don’t worry about this for now, as it is less common to need this.
Heads Up: There !is actually one additional flowline control you may encounter that is
specific to perpetual responses. Perpetual responses have a condition where the flowline
drops down out of the response and ends in a small circle like this:
This is the state associated with Return, as was discussed earlier. You’ll learn more about
this in Chapter 12.
Track (DIRECT)
You have now performed all the steps necessary to create a basic interaction in
Authorware . Technically, you do not have to do anything else to make your interaction
242
work. But because we are talking about developing interactive instruction, pedagogy
requires one additional process; tracking the learner’s performance and providing
meaningful feedback during and after instruction. To do this, you need to know a little
about types of feedback and about variables in Authorware .
Feedback & the Teachable Moment
While I will discuss feedback in general as it relates to the development of interactive
instruction, it is far too complex a topic to be adequately addressed here. If you are
interested in the topic (and all serious developers of CBI/CBT should be), see Dempsey
& Sales’ 1993 book, Feedback and interactive instruction, published by Educational
Technology Publications.
Feedback has been classified and defined many different ways, but for our purposes here
I will focus on three kinds of feedback: feedback during instruction that relates to specific
questions that have been asked answered (Knowledge of Correctness--KC, and
Knowledge of Correct Response--KCR), and feedback after instruction that relates to
performance on the assessment (summative feedback).
KC refers the kind of feedback we are most used to seeing in CBI/CBT; the kind that tells
us whether we were correct or incorrect. This minimalist feedback helps the learner
assess and manage their learning performance as they work through the instruction. The
assumption is that when the learner finds out they were incorrect, they will know that
they need more instruction.
243
KCR is similar to KC in that the learner is told whether they were correct or incorrect, but
differs in that they are also told what the correct response should have been. KCR is more
effective, because the learner is not left in any doubt about what the correct answer is, as
could be the case with KC. This assumes, of course, that there are more than two possible
answers to the particular question.
The problem with both of these types of feedback is that neither one does anything to
address the cause of the error itself. There is a concept in education called the teachable
moment. That moment occurs when the learner is confident they have the correct answer
but find out they are wrong. This creates an affective and cognitive state in the mind of
the learner that makes them particularly receptive to learning. When we think we know
something and find out we don’t, we are immediately focused on finding out why: “Why
isn’t that right? Show me!” If we leave it up to the learner to determine this, as is the case
with KC and KCR, we run the risk that they will not find the answers they seek or, worse,
that they will form a misconception.
The most effective kind of feedback you can provide during instruction is KCR plus
explanation (KCRE). Tell the learner whether they were correct or incorrect, explain
what the correct response was (even if they got it right), and then explain in a few
sentences why that is the correct answer and/or why the incorrect answer is incorrect.
Table 4 presents hypothetical feedback of each type for a question about Authorware
interactions. You may think this sounds like a lot of work “just for feedback,” but
feedback easily can account for 30% of learning when done conscientiously.
Unfortunately, the fact that it is more work to do so is why we are most used to seeing
only KC feedback in CBI/CBT.
244
Table 3. Hypothetical feedback types and examples.
Question
Types of Feedback
Which of the
following represents
all the elements
needed for an
interaction?
KC
KCR
KCRE
A. Display icon,
interaction icon,
response icon,
decision icon,
evaluation,
control, tracking
Incorrect.
No, the correct
answer is B.
No, the correct
answer is B,
because you don’t
use a decision icon
for basic
interactions.
B. Display icon,
interaction icon,
response icon,
evaluate,
control, tracking
Correct.
Right! B is the
correct answer.
Right! B is the
correct answer.
Remember the
acronym DIRECT
when you are
building your
interactions.
C. Display icon,
interaction icon,
response icon,
decision icon,
feedback icon,
tracking
Incorrect.
No, the correct
answer is B.
No, the correct
answer is B. You
are right to be
thinking about
feedback, but
feedback goes
inside your response
icon; there is no
such thing as a
feedback icon.
The second type of feedback I mentioned is summative feedback. This is feedback that
you provide to the learner after they have completed significant portions of your
instruction (a set of objectives that form a module, for instance) and at the end of the
245
instruction. Feedback in this case refers to information about overall performance:
“You missed 5 out of 25 questions.” Like feedback during instruction, you should try to
provide enough information to help the learner identify where they went wrong: “Of the 5
that you missed, 3 were from section 1, and 2 were from section 2. You may want to
review these sections again before proceeding.”
This kind of feedback is made much easier by Authorware , which automatically tracks
information for you. For now, we will focus only on providing overall feedback (i.e., not
specific feedback on individual sections), because this can be accomplished using
variables that are already present in Authorware . In chapter 11, you will learn about
creating custom variables that you can use to provide more specific, targeted feedback.
Variables are simply containers that hold information. That information can vary (hence
the name variable) depending on many factors. Authorware has some variables built-in
automatically. Examples include a variable that tells you when the learner started your
program, how long they took in the program, and, more importantly for our purposes
here, how many answers were correct or incorrect. You will remember from the
Evaluation section of building an interaction that you must set your responses to Correct
Response (+), Wrong Response (-), or Not Judged ( ). Authorware keeps track of all
correct responses and incorrect responses. It stores this information in variables called
TotalCorrect and TotalWrong. Both variables, as is the case with most variables, initially
start out at 0. Everytime the learner makes a correct or incorrect response, Authorware
adds 1 to the appropriate variable. At the end of the instruction, you can display these
variables to the learner to tell them how many they got right and how many they got
wrong.
246
To do this, you must embed the variable(s) inside a display icon by typing its name.
When you type inside a display icon, however, the text (i.e., what you actually type)
shows up to the learner. In the case of providing feedback, however, you don’t want them
to see the actual name of the variable; you want them to see what is stored inside that
variable. The way that this is handled is to use special characters on either side of the
name of the variable to tell Authorware that what you are typing is NOT text, but is the
name of a variable. The characters you use to do this are called curly brackets, and they
look like this: { and
}.
So, if I want to show the learner how many correct answers they got, I could type the
following inside a display icon:
“You got {TotalCorrect} questions right.”
If the learner answer five questions right, then they would see this:
“You got 5 questions right.”
It is critical that you type the name of the variable exactly as it appears, with no spaces
and the same capitalization; deviating even one character will cause it not to work.
Power Tip: I recommend that you just type these variables out by hand now while you
are just learning Authorware , because working with variables can be overwhelming. For
now, just think of it as a magic formula that you know how to do. Because it is
impossible to remember all the different variable names, and because spelling is so
important when using them, Authorware has built in a way to display variables without
you typing them. This is accessed through WindowVariables, which brings up a
247
window that lists all variables by name. Clicking on each one provides a description of
what it does and how to use it, and allows you to copy it into your display icon (if you
have it open at the time have selected the text tool, and started typing) by means of Paste
button. You may want to look at this option now to see what I mean, but I do NOT
recommend that you try to use it at this point, as you don’t know enough about variables
to avoid problems.
Note in the example that the variable only contains a number (in this case, 5), so I have to
type some text on either side of it for it to make sense to the learner. The process for tell
the learner how many they got wrong is the same:
“You got {TotalWrong} questions wrong.”
Add a display icon now on the flowline underneath your interaction, and type the
examples above exactly as they appear. Run your piece a few times, answering correctly
and incorrectly, to see how this works.
Summary
While Authorware has the ability to add text, graphics, movies, and sounds, there are
numerous other programs that can do the same. Authorware ’s strength, and reason for
existing among other admittedly more polished animation and multimedia products, is its
ability to create and track interactivity. This is what makes Authorware the best tool for
creating multimedia instruction. The key to interactivity is, of course, the interaction.
Despite the fact that there is an icon called an interaction, interactions in Authorware are
actually created through the use of several icons. The mnemonic for remembering these
248
icons and the processes necessary to implement them correctly is DIRECT, which stands
for Display, Interaction, Response(s), Evaluation, Controlling the flow, and Tracking.
The display is used for presenting text and graphics that will be needed for the interaction
“scene.” Most commonly, this is where the text and or graphics for the question are
presented. It is important to remember the rules about display icons and animation and
erase icons (when you animate or erase a display icon, it affects everything inside that
icon; to apply animation or erasure to a specific element on your screen, that element
must be in its own icon.
The interaction icon actually requires the least amount of editing; simply placing it on the
flowline after the display icon is sufficient for most types of interactions. More
significant is the placement and creation of Responses. Responses are maps that you
attach to the right of an interaction icon. Responses can be buttons, hotspots, text entry
responses, target areas, pulldown menus, and others. It is important to distinguish
between response types and feedback to the learner. Response types are the means of
responding (interacting) that you provide to the learner (e.g., buttons to click, places to
type text). Feedback to the learner (i.e., what you tell the learner when they have
triggered one of your response types) is contained in the map that is attached to that
response type. This feedback can be anything you choose, including audio (a sound icon),
video (movie icon), and (most commonly) text (a display icon).
Once you have added your responses, each one must be set to Correct (+), Incorrect (-),
or Not Judged (Evaluated) so that Authorware knows whether to count that response as a
correct or incorrect response). Remember that telling Authorware whether a response is
249
correct or incorrect is completely unrelated to what you tell the learner about their
response!
Finally you must control the flow (where the program should go once the learner has
triggered a response). Usually, a correct response points back to the flowline, while an
incorrect response cycles back through the interaction so the learner can try again.
Tracking responses is actually done automatically by Authorware using variables. You
will learn more about variables later, but for now think of them as containers that hold
values (number of correct, amount of time spent in the program, etc.). You can also
create custom variables to track specific data that you are interested in. In any case, these
variables can be saved to a file, printed out, and displayed to the learner at any time by
referring to them by name. Most commonly, a display icon is used in which the variable
name is typed on the screen between curly brackets ({}). When Authorware encounters
these, it displays the contents (value) of that variable rather than the name of the variable.
Although interactions allow you to address virtually all four phases of instruction in the
Alessi and Trollip model, they primarily address guidance, practice, and assessment. The
way in which you design your practice and assessment can impact how intrinsically
motivating your instruction is as well. It is important to understand some of the principles
for determining the amount and type of practice and assessment to build into your
instruction.
Practice and Guidance
250
The distinction between practice and guidance is somewhat slippery in that the activities
look nearly identical. The difference relies on the amount of instructor guidance that your
provide during the interactions. When a learner is first demonstrating something they
have just learned, it is a good idea to provide a lot of guidance. The idea is that you want
to create a risk-free environment that minimizes error to the extent possible. As the
learner progresses and becomes more familiar with the content, the guidance is gradually
tapered until the learner is reliably demonstrating the knowledge with little to no
intervention.
This approach shares much in common with Vygotsky’s (1962) theory of the zone of
proximal development (ZPD). In this theory, there are some activities that are completely
within the abilities of the learner to accomplish independently, some activities that are
impossible for them to accomplish, and some that are possible to accomplish with some
guidance and support from someone else. These latter activities are said to be withing the
learner’s ZPD, and it is in this zone that learning occurs. Vygotsky called that guidance
“scaffolding” because it was the least amount of support needed for the individual to
accomplish the task.
As we move from guidance to practice, these scaffolds become less and less, until the
learner is making more correct responses than incorrect responses, at which point the
instructional emphasis shifts from learning the content to building fluency or
automaticity. The learner is then practicing applying the information in new a varied
contexts, over and over.
251
The only difference between practice and assessment is that practice provides immediate
feedback after each practice opportunity in terms of correctness of response along with
some form of elaboration and/or clarification, while assessment provide only correctness
of response feedback at the end of the entire assessment. Practice is used as part of the
learning experience, while assessment is used to provide information about the learner’s
progress toward mastery of the objectives.
Practice and assessment are types of interactions, but not all interactions are practice.
Practice refers to a type of interaction that allows the learner to apply a concept, rule or
problem-solving skill they have been presented with. In contrast, interactions can be
presented prior the content itself can serve as elaboration or prediction tools. For
instance, it is a common technique to ask the learner to predict why some phenomenon
occurs, allowing them to select from some possible responses. This kind of advance
questioning helps create a cognitive state that promotes learning by activating schemas
and mental models associated with the content. Even though this kind of interaction is
identical in structure to practice, its placement in relation to the content (before, rather
than after) precludes it from being practice.
It is a good idea to build multiple practice opportunities into your instruction. Providing
one practice opportunity is probably not sufficient for mastery of a concept; learners
usually require several practice opportunities. At the same time, however, you don’t want
to drive your learner crazy by making them practice everything they learn several times.
In general, the more complex the learning, the more practice opportunities are required.
Verbal information, discriminations, and concepts that serve as prerequisite skills for
rules and problem-solving skills may only require one or two practice opportunities,
252
while the rules and problem-solving skills that are based on them will probably require
multiple practice opportunities.
Additionally, practice opportunities may need to be distributed over time. Even if a
requisite discrimination or concept is simple enough that multiple, sequential practice
opportunities are not appropriate, it may be necessary to provide practice opportunities
separated by time to ensure that the information has been encoded for long-term retrieval.
Practice and Transfer
One reason that multiple practice opportunities are required comes from the research on
transfer. Transfer refers to the ability to apply prior knowledge in novel contexts. Despite
the importance of transfer of learning in education, learners in general rarely demonstrate
positive transfer (Asch, 1969; CTGV, 1992a, 1992b; Gick & Holyoak, 1980; Perfetto,
Bransford, and Franks, 1983; Reed, Ernst, & Banerji, 1974; Simon & Hayes, 1976;
Thurman, 1993; Van Haneghan, 1990; Weisberg, DiCamillo, & Phillips, 1978). One of
the reasons for this may be that transfer is context dependent (e.g., Bransford, Franks,
Vye, & Sherwood, 1989; Bransford, Sherwood, Vye, & Rieser, 1986; Brown, Collins, &
Duguid, 1989; Perkins & Salomon, 1989), and requires multiple practice opportunities
over a variety of contexts and settings (Gagné, Briggs, & Wager, 1992).
Because CBI/CBT can create learning environments that represent real-world contexts in
which the learning will ultimately be demonstrated (transferred), it is possible to create
multiple contexts (environments) in which to embed the practice opportunities with little
effort beyond that needed to create one context. For example, I once created a math game
in which the learner was charged with calculating the amount of paint needed to paint a
253
room in a house. A lot of effort went into creating the structure needed to use a measuring
tape to measure walls, doors, and windows, using a calculator and workbook to perform
calculations, etc. However, once done, I was able to change the environment from a room
in a house to a theater by simply modifying the shape and placement of hotspots and by
changing the background graphics and the numbers involved.
Assessment
Assessment is often a matter of copying and pasting your practice items into a section at
the end of your program, changing the numbers and details, and removing the feedback.
After all, your practice items should reflect the content and objectives. One thing that is
often missing, however, is something that requires the learner to synthesize all of what
they have learned into a single application. This culminating activity should be as close
as possible to the context in which the learning will ultimately be demonstrated, in order
to promote transfer of learning.
It is also important to provide feedback to the learner about their performance on the
assessment in order to help the learner manage their own instruction. But a simple overall
score does not help the learner do this; it only tells them there are some things they don’t
know. The feedback you provide should be tied to individual objectives (for the learner’s
benefit and for your use in evaluating your instruction) and to specific sections of the
program. Ideally, you should tell them which specific questions they missed (describe the
item as fully as possible and give them their response), which sections/objectives of the
program the content for those items can be found in, suggest a path for remediation for
254
them. You will learn later how to use a decision icon and variables to ensure that they get
different questions the next time through the assessment.
Motivation
The earlier discussion of the ZPD, guidance, and practice is relevant as well to creating
intrinsically motivating instruction. Malone & Lepper’s theory (1987) identifies four
factors that make for intrinsically motivating instruction: Challenge, Control, Fantasy,
and Curiosity. All but Fantasy can be addressed through the use of interactions within
your instruction. Challenge refers to making your instruction hard enough that the learner
can not just breeze through (and thus get bored) but not so hard that they fail (and
become frustrated). As you can see, this correlates with Vygotsky’s theory of the ZPD.
Your guidance (which is tied to your interactions) as the learner moves through your
instruction is what will allow you to keep the learner in the ZPD by providing
remediation and explanation when (and only when) the learner is having difficulty. You
should always design the instruction with the assumption that the learner can do it
autonomously, but also provide guidance for if and when they cannot.
Control can be addressed through interactions as well by allowing the learner to
determine their own path through the instruction (menus to navigate to different sections)
and control how and when they get extra information (help buttons, glossaries, etc.). Of
course, we know that learner’s are not always good judges of what they need and when
they need it, so you should also provide guidance reagarding things like the optimal path
through the instruction, the number of items most need to attain mastery, feedback on
performance and suggested remediation, etc. You should also make them aware of this
255
information periodically throughout the instruction, as research has shown learner’s do
not ask for advice often (Dempsey, J. V., & Van Eck, R., 1998; Van Eck, R., &
Dempsey, J. V., In Press).
Curiosity can be addressed through pre-questioning activities as described earlier.
Providing counter-intuitive examples and asking the learner to make predictions based on
common misconceptions are examples of ways to promote curiosity, each of which
requires an interaction. This is related to another cognitive theory proposed by Piaget,
who said that there are three stages involved in building mental models; the model as it
exists in the world, the model as it exists in the mind of the learner, and the process of
self-regulation (LOOK THIS UP) involved in reconciling the two (which can be done
through assimilation or accommodation). Piaget held that learning takes place in the third
stage, in the “disequilibrium” between what is and what we believe. According to this
theory, we want to keep the learner on their toes, so to speak, in that state of
disequilibrium. It is in that state that we arouse the learner’s curiosity; “why isn’t that the
right answer?” One way to integrate this into your instruction is to ask the learner to
indicate how confident they are in their answer prior to giving them feedback; the more
confident they are when they make an incorrect response, the more curious they are as to
why they were wrong, and the more amenable they are to attending to and processing the
information. It is possible to provide different feedback in cases like this than you would
if they were not confident and wrong or confident and right.
Exercises
1) Name and describe each of the elements of an interaction.
256
2) How do you arrange responses on the screen (e.g., how do you make your buttons
line up or how do you put your hotspots over the right part of the screen)
3) Why is it important to name your responses?
4) What is a “Catchall” Hotspot, and why is it important?
5) I have created a pulldown menu using the following structure:
257
a) What will the name of the menu itself be?
b) How many items will be on the menu?
c) What would I have to do to make this menu available to the learner at any time in
my program?
6) What is the difference between a hotspot and a hot object?
7) What does a tries limit do?
8) What does a time limit do?
9) Where on the interaction should either of the above two responses go?
10) Which of the responses in the following interaction are judged as correct?
a) Incorrect?
b) Neither?
11) Where does feedback (i.e., what you tell the learner after they select a response
choice) go in an interaction?
12) Open the file you have been building as part of the exercises and add the following:
a) Add a screen that tells the learner what the topic of your instruction is and what
the objectives are (i.e., what they will be able to do once they have finished your
piece). Let the learner read that screen until they are ready to move on by clicking
a button or a hotspot, at which point the screen will fade out.
258
b) Download the graphics for this chapter, including the four images of Mt.
Rushmore. Note that each of this images, when placed next to each other, forms
one large image of Mt. Rushmore. Add a series of scenes that teach the learner
about Mt. Rushmore using the following facts:
i) George Washington was the first president of the United States
ii) Jefferson was one of the signers of the declaration of independence
iii) Roosevelt was famous for the saying “Talk softly and carry a big stick.”
iv) Abraham Lincoln signed the emancipation proclamation.
c) Use animations, erase icons and transitions as you see fit when creating this
instruction
d) Provide a practice test question (interaction) on each of the four facts taught. Use
buttons for one question, hotspots for one other question, text entry for one
question, hot object for another questions, and limit the learner to two attempts
and 30 seconds for each question. Provide KC feedback for one question, KCR
feedback for the second question, and KCRE feedback for the third and fourth
questions.
e)
Provide a pulldown menu that appears in the beginning of your program and
remains accessible throughout. Name this menu “Help.” This menu should have
one item on it named “Mt. Rushmore.” When selected, this item will present a
259
screen with the answers to each of the 4 questions on it, along with instructions
for how to return to the program (a button, a mouse click, or whatever you want).
f)
Keep track of the number of correct responses and incorrect responses. Present
final data to the learner at the end of the assessment.
260
References
Dempsey, J. V., & Van Eck, R. N. (1998, April). Advisor use in CBT: Modality
and placement. Paper presented at the annual meeting of the American Educational
Research Association, San Diego, CA.
Malone, T. W., & Lepper, M. R. (1987). Making learning fun: A taxonomic
model of intrinsic motivations for learning. In R. E. Snow & M. J. Farr (Eds.), Aptitude,
learning, and instruction: III.
Cognitive and affective process analysis (pp. 223-253). Hillsdale, NJ: Erlbaum.
Van Eck, R. N., & Dempsey, J. V. (In Press). The effect of competition and
contextualized advisement on the transfer of mathematics skills in a computer-based
instructional simulation game. ETR&D
Vygotsky, L. S. (1962). Thought and language. Cambridge, MA: The M. I. T.
Press.
261
Chapter 7: frameworks
Overview
You have essentially learned everything you need to know to create interactive
instruction using Authorware. Everything you learn from this point forward extends what
you already know either by making it easier to accomplish what you want or by allowing
you to create products with more complex features. In this chapter you will learn how
frameworks can save you several steps and maintain consistency in design and
functionality throughout your piece. That’s because frameworks allow you to specify a
transition and set of navigational features once that can then be applied to the entire
program. Frameworks also allow you to make use of the navigation icon, which allows
you to navigate from place to place in the file.
Objectives
At the end of this chapter, you will be able to use frameworks to:
•
organize and deliver instruction,
•
specify transitions for each “page” of your instruction,
•
build in standard navigation options such as forward and back buttons,
•
maintain consistency of placement of items within each “page” of instruction,
•
jump to any page on any framework using navigation icons,
262
•
use call and return functions to create sophisticated “just in time” features such as
a glossary,
•
and import and create display icons for instructional text you have created in a
word processor.
Why use frameworks?
Frameworks were designed to solve a specific problem that only becomes apparent when
you’ve mastered the basic authoring process and have begun developing significant
products (i.e., products that are comprised of tens or hundreds of individual screens). The
problem is twofold. Firstly, while it is possible to create lots of “scenes” (e.g., pages of
instruction, opportunities to practice and interact, etc.) using displays, interactions, wait
icons, and erase icons, if we want to be consistent, we have to make sure all the elements
line up in relation to each other (so things don’t jump) and apply the same transitions for
every display and erase icon over and over again. For instance, every continue button
(from the wait icon) has to be lined up in the same place on every screen, every new
“scene” has to have the same transition applied to it, and every erase icon has to have the
same erase transition (which in turn must be set to erase a specific display icon). This
means we are performing the same three steps, each of which requires several actions, for
every new scene.
The other part of the problem is that up until now, we have assumed we are developing a
program in which the learner moves linearly through the program (e.g., in a tutorial
format). What happens if we want to “back up” from one scene to the previous scene?
Wait icons only pause the program’s forward progress; they can’t allow the learner to go
263
backwards. Likewise, if we want to be able to jump from place to place in the program
based on learner control (e.g., from a main menu, to access help, to look up a word in a
glossary) or according to learner actions (e.g., remediation based on performance on the
learner’s performance on practice items), we need a way to jump to places in the file.
While there is a way to do this using a function called GoTo(IconID@”name of icon to
go to”) which is typed inside a calculation icon, it is a somewhat tedious process to go
through. Additionally, this function does not allow us (easily) to jump to someplace
temporarily (as is the case with a glossary to look up one word) and then return to where
we just left off.
Frameworks allow us to, in one step, set up transitions between scenes (thereby replacing
display transitions and erase transitions) and navigation features such as forward, back,
main menu, and quit for a virtually unlimited number of individual scenes. These scenes,
or “pages” as they are referred to on a framework, are comprised of maps that are
attached to the right of a framework icon. Adding pages is a matter of dragging maps to
the right of a framework, much the way you add responses to an interaction icon. The rest
of this chapter will examine how frameworks work this is done.
Anatomy of a framework
You may be asking yourself why, if frameworks are so helpful and convenient, I didn’t
tell you about them from the beginning. The answer lies in the structure of a framework.
Frameworks appear to be one icon (that looks like a picture frame), but in reality are
comprised of several icons. When you double-click on a framework icon, you get a
design window that looks like figure 30.
264
Figure 30. The inside of a framework icon.
As you can see, a default framework icon is comprised of a display icon, an interaction
icon, and several buttons which lead to navigation icons. If you were willing to use the
exact setup that Macromedia creates as the default, it would be possible to use a
framework without knowing anything about interactions and responses. Unfortunately, I
have never encountered a project that required all of the navigation features included in
the default framework, nor can I conceive of any project that would want to use the
buttons that Macromedia has created for the framework (to see what I mean, drag a
framework onto your flowline and run the program—not pretty). In any case, there is no
doubt that you will have to modify some framework, sometime, so you need to know
how interactions behave before you can work with frameworks.
It may help you to understand what frameworks do by understanding where their name
(and shape) comes from. Just as a picture frame allows you to place a consistent border
around a picture, frameworks allow you to place common elements and features around
your individual scenes. And like a picture frame, these elements can be placed around
265
any scene you choose by removing the contents and replacing them with something else;
the frame remains the same, but the contents change. Frameworks allow us to place
“frames” around our instruction so that we don’t have to recreate those elements every
time. Most commonly, these elements are display icons that contain section titles and
page numbers (that can change with each page automatically), and interaction icons and
responses that allow the learner to control how they move through the program (forward,
backward, main menu, help, etc.). Together, these elements “frame” each “page” of our
instruction.
The first thing to note about a framework is that there are two flowlines; one in the “top”
portion (created by the horizontal line that divides the window approximately two-thirds
down) and one in the lower portion. Icons that appear in the top portion will appear (or be
executed) on every page of the instruction. Every time the learner moves from one page
to another (either by moving forward, backward, or jumping to a page), they are first
routed automatically through every icon that appears in the top portion. Icons that appear
on the flowline in the bottom portion of the window will appear (or be executed) only
when the learner leaves a framework (by jumping to another place in the file or otherwise
exiting that framework). For most programs, it is only the top portion of the window that
is of concern.
Power Tip: Although Macromedia has provided one display icon inside the default
framework, there is no limit on either the number or type of icons that can be placed here.
This means if you want to have 100 display icons, animations, movies, sounds, or
calculations applied to every page of your instruction, you can put them in this top
portion of the framework.
266
So, in the default framework, the display icon (inappropriately) named “Gray Navigation
Panel” contains an image that will appear on every page of instruction attached to this
framework. Because this image is placed in the upper right of that display icon, that is
where it will appear on every page; if I want to move it, replace it, or otherwise modify it,
I need only open that one icon and make my changes once. That’s because everytime the
learner moves from page to page on my framework, they are first routed through this top
portion of my framework, where the contents of that display icon is presented.
My parenthetical comment about the name of the display icon being inappropriate relates
to the next icon we find in the top portion of the default framework: the interaction icon.
Navigation (between pages on the framework and between the framework and other parts
of the program) is accomplished through the use of this interaction icon and the responses
that are attached to it. By default, Macromedia provides 8 responses attached to this
interaction, each of which is a button that leads to a navigation icon. For now, it is not
important to know what each of these particular navigation icons does, only that they
facilitate movement between pages on the framework.
You may remember from the last chapter that when you set a response to be perpetual (as
is necessary for creating permanent pulldown menus, for example), Authorware will
continue down the flowline past that interaction without waiting for the learner to trigger
a response. The symbol for perpetual responses is the straight line with the small circle
you see underneath each of the responses on the interaction in this framework. Given this,
what happens when the Authorware encounters a framework is it drops into this top
portion of the framework, displays any icons it finds there, including perpetual buttons,
hotspots, or whatever, and then continues to the first page. The items and buttons it found
267
inside the framework now appear on that page and every other page attached to the
framework.
Tip: This interaction icon and its responses behave identically to any other interaction
icon and responses. Therefore, you can create any kind of elements you want here,
including pulldown menus, hotspots, hot objects, etc. While frameworks make good use
of navigation icons, it is not necessary to use them as your responses—you can put
anything you want onto the interaction and response types inside a framework. In fact,
you can delete everything you see inside the framework, although doing so would mean
you would have to provide some other means of moving from page to page.
Navigation icons
Now that you understand the components of a framework, let’s examine the options you
have for the navigation icons. Navigation icons can do a lot more than you might think,
but they all follow one basic, important rule; a navigation icon can jump from anywhere,
but only to a page attached to a framework. This means that you cannot use a navigation
icon in a program that does not make use of at least one framework with at least one
page. So I can put a navigation icon anywhere I want in my program, but it can only go to
a page attached to a framework. One of the good things about this, however, is that a
navigation icon can go to any page on any framework in the file. So if I want to go to the
15th (or 30th, or 52nd, or…) page on a framework, I can use a navigation icon to do so.
Setting up these different types of navigation icons is, as with most icons, a matter of
setting it’s properties. There are two types of navigations, Jump to Page and Call &
268
Return, and three categories of places (pages) to go to. All of these are accessed through
the navigation icon properties dialog box, pictured in Figure 31, below.
Figure 31. Navigation icon properties dialog box.
The top of this box contains the place for the title of the navigation icon, which is
“unlinked” by defaul. Unlike most icons, Authorware will name your navigation icon for
you once you set its properties, so it is not necessary to give it a title yourself, although
you can. The next box you see is a drop down menu box that will let you select from five
different types of navigation destinations: Recent, Nearby, Anywhere, Calculate, &
Search. We will examine the first three types in this chapter; in Chapter 12 you will learn
about Calculate and Search.
Recent
When you select “Recent” from the list of possible destinations, you are presented with
two options: “Go Back,” and “List Recent Pages.” The key to understanding these
269
options lies in knowing that the last (or most recent) page the learner has viewed may not
be the one that immediately precedes the current page on the framework. This is because
not all products will be linear (i.e., page one leads to page two leads to page three). It is
possible (as you will see) to jump from any page to any other page on a framework, so
the most recent page viewed might be the 4th (or 12th, or 57th) on the fourth of five
frameworks in the file. “Recent” allows you to specify that the learner should be taken
back to the last page they viewed (Go Back) or be able to choose from a list of the most
recent pages (List Recent Pages) to go back to. You can control how many pages to list in
List Recent Pages by going to ModifyFileNavigation Setup; the default is 999.
Nearby
When you select “Nearby” from the Destination drop down menu, you are offered 5
choices: Previous, Next, First, Last, and Exit framework/Return. The key to
understanding these destinations lies in realizing that Nearby is defined in terms of the
framework you are currently on. Previous means go the previous page (i.e., the one that
comes immediately before the one the learner is currently on). It is important to
distinguish “Previous” from “Recent;” “Previous” can only go backwards one page on
the current framework (e.g., from page 5 of a framework to page 4 of the same
framework) while “Recent” goes to the last page viewed by the learner regardless of
what framework that page was on. If the last page viewed by the learner just happens to
be the previous page on the same framework, then “Recent” and “Previous” would be the
same.
270
“Next” refers to the page immediately following the current page on the framework (e.g.,
if the learner is on page 4, “Next” would point to page 5 of the same framework). “First”
refers to the very first page of current framework, while “Last” refers to the last page of
the current framework. The last option, actually serves a dual purpose, which is why it
has forward slash separating “Exit Framework” from “Return.” Remember the bottom
portion of the framework window, the one with the second flowline in it? The “Exit
Framework navigation icon is the way you tell Authorware to exit (leave) the
framework, at which point it executes anything you have put on the exit portion flowline
of the framework. The reason this is important is that when the learner reaches the last
page of your framework, clicking the “Next” button will not take them out of the
framework and back onto the flowline; it will cycle back to the first page of the
framework instead. You have to tell Authorware to exit the framework by using this Exit
Framework/Return option. As you will see later in this chapter, this is the same option
that you will use when building a Call & Return navigation; it is the “Return” part of Call
& Return.
Anywhere
“Anywhere” is perhaps the most intuitive destination name, but can be confusing to
implement. When you choose “Anywhere” as the destination type, you get a dialog box
that looks like figure 31 (it is in fact the default destination type). You can then tell
Authorware which specific page on which specific framework that this navigation icon
should go to. It can be any page on any framework anywhere in the file. This is when the
next drop down menu and the box below it become important. You use these to select the
framework and page that you want the navigation icon to go to.
271
The drop down menu labeled “Framework:” allows you to select individual frameworks
in your program. If you have one framework, you will only have one option in the
“Framework:” menu; if you have 10 frameworks, you will be able to choose from all ten.
The “Page:” window below is tied to the “Framework:” menu. When you select a
framework, the pages that are attached to that framework are automatically displayed in
this window. As you change to different frameworks, the contents of this window change
to match the pages on that framework. You may once again recognize the importance of
naming your icons in your program according to a naming/numbering scheme (you may
want to read Chapter 3 if you have not already done so). The only way you will know
which framework you are selecting is from it’s name. Likewise, the only way you know
which page to go to on a selected framework is from it’s name. If you leave them
“Untitled,” you’ll be selected from several frameworks and pages named “Untitled,” and
there is no way to pause and go look at each one (not that that would be any fun!) without
canceling the dialog box first.
You have one other option to choose from in the “Framework:” menu: “Entire File.”
Selecting “Entire File” will show you every page on every framework. While this can be
handy in some cases, it can be quite confusing, especially if you have named your pages
something like “Page One,” since you will then have a “Page One” for every framework,
with no way to tell which one is which. This is why I recommend that you name your
pages using a naming scheme that reflects the framework and page number (e.g., S1_P1
for Section 1, Page1). You may remember the discussion on storyboards and branch
points from Chapter 3; this is where the numbering scheme for your branch points comes
272
in handy, since you can just name each icon for the branch point number you assigned it
on your storyboard.
Jump to Page
Now that you understand three of the basic destinations you can choose from for each
navigation icon (Recent, Nearby, Anywhere), it is time to talk about the two types of
navigations you can use to go to these destinations. The first, and most commonly used
one, is Jump to Page. Jump to Page is a one-way trip; when you use Jump to Page (to go
to a Recent, Nearby, or Anywhere destination), Authorware will “Jump” to that page and
proceed from that point according to the rules and navigations you have set up on the
framework that page is on. In the case of Recent and Anywhere destinations, that
framework can be anywhere in the program. In the case of Nearby destinations, you are
“jumping” from one page on the framework to another page on the same framework, so
the navigation options will obviously be the same. In 99.9% of the cases where you want
to use a navigation icon, you want to use a Jump to Page type, regardless of which of the
destinations you choose.
Call & Return
Call & Return is a round-trip journey. When you choose a Call & Return type of
navigation, you are setting up two legs of a trip. The first leg acts just like a Jump to Page
navigation. Everything you’ve learned about navigation destinations and rules from the
section above applies to Call & Return as well. The only difference is that you have the
option at any later point in the program to send the learner back (Return) to the place they
last jumped from.
273
This can be a little confusing, so let’s break it down in more detail. The Call part of Call
& Return is just like the Jump part of Jump to Page, and setting up the navigation is the
same in both cases. It’s just that Call & Return (which might better be named Jump &
Return) has a second step. That second step is letting the learner Return from where they
jumped to so they can pick up where they left off. For example, if I want the learner to be
able to go look up the definition of a word that they don’t know while going through my
instruction, I could create a page of definitions on a framework and let them jump to that
page to look up a word. But once they do that, how do they get back? I only want them to
temporarily jump to that definition; once they are done, I want them to be able to pick up
where they left off. I can’t use a Jump to Page to get them back because I can’t tell which
page they came from, since they could have hit the definitions button from any page on
my framework. Call & Return solves this problem.
The key to understanding this process lies partly in the rule about navigation icons that
says while you can jump (or call) from anywhere in a file, you only jump (or call) to a
page on a framework. So in my example above, I can use a Call & Return from my
framework with the instruction on it by adding a navigation icon to the interaction icon
inside my framework, double-clicking on the navigation icon, selecting Call & Return as
the type, selecting Anywhere as the destination, and selecting the framework and page
that I want to Jump/Call to. Once I have done this, the learner can hit that button from
any page on that framework, and they will be taken immediately to the definitions page
on the definitions framework I set up. So far, there is no difference between Jump to Page
and Call & Return. But now, once the learner is at that definition page on that other
framework, I can let them return exactly to where they were when they hit the button to
274
take them to the definition page. I do this by setting up a “Return” navigation icon inside
the framework to which the definition page is attached. To do this, I need only attach a
navigation icon to the interaction icon inside my definition framework (the one I have
“called” to). While it can be any kind of response (button, hotspot, etc.), I will in this case
make it a button labeled “Return” (it could be named done, finished, go back, or anything
I want). I then open that navigation icon, select Nearby as my destination type, and
choose “Exit Framework/Return.” You may remember from the earlier discussion that
this option performs two functions. Under normal circumstances, this option simply
causes Authorware to exit the framework and continue down the flowline. If at any point
in the program, however, there has been a Call & Return initiated (as is the case with our
definition example), this options will not just exit the current framework; it will also
Return to the page the learner was on when they initiated the Call & Return. In my
example, this means if the learner is on page 12 when they hit the button to read some
definitions, hitting the button labeled “Return” that I set up to Exit Framework/Return
will cause Authorware to go back to page 12. This would be true for any page they were
on.
275
Tip: How to setup a generic framework. While you can certainly work with what you
have inside the default framework that Authorware gives you, in my experience I have
found that beginning students can become confused by all the elements. For that reason, I
usually recommend simplifying the framework by doing the following:
1) Delete the display icon named “Gray Navigation Panel”
2) Select the first 5 navigation icons on the interaction and delete them (choose
“Selected Icons” when prompted)
3) Delete the last icon on the interaction
4) This will leave you with a Previous and Next button for your framework. You can
add an exit button (Exit Framework), Main Menu button (Jump to Page), or whatever
other buttons (or hotspots, or target areas, or whatever you want) to that interaction.
You will learn how to customize your buttons to look different (and hopefully better!)
than the ones that are provided.
Specifying transitions between pages
As I mentioned in the beginning of the chapter, one of the most useful features of the
framework is its ability to specify a single transition between pages. By applying a
transition to pages rather than individual icons, it is no longer necessary to set a transition
for your display icons when coming in to a new scene, nor is it necessary to use an erase
icon to create a transition when leaving that scene. In a 20 scene program sequence, I
would have to apply 20 separate transitions to my display icons, add 20 erase icons, and
276
set 20 transitions for those erase icons; these 60 steps are replaced with one by making
these scenes into pages on a framework (using maps for the pages).
To apply a transtion to every page on a framework, you simply select the framework icon
itself and go to ModifyIconTransition. This brings up a dialog box almost identical
to the transition dialog box you get for a display icon.
Adding common elements to a framework
Although there are a virtually unlimited number of elements you can add to your
frameworks, there are two in particular that I find very useful. One is used for lining up
elements on my pages and one is for displaying page numbers automatically. In both
cases, we use a display icon.
Lining up elements on pages
Because anything you put inside the top portion of the framework window will appear on
every page (and not get covered up by what’s on those pages), you can use a display icon
to draw a grid that lays on top of your background image (it needs to come after the
background image in your framework to do this). You can draw lines using Authorware’s
drawing tools. Since these appear on every page, you’ll be able to use them to position
your text boxes, buttons, and other page elements. Once I am done and ready to package
my file, I can just delete the display icon that has the grid in it. See figure 32 for an
example of this.
277
Figure 32. A grid in the framework will appear on every page and can be used to position
elements on screen.
Adding automatic page numbers to a framework
A well-designed program finds ways to communicate with the learner in continuous,
unobtrusive ways. While we are used to creating feedback in response to questions, there
is a whole host of other information we can provide to learners that help them to manage
their own learning. This feedback can take the form of changing cursors when the mouse
is over a hotspot or hypertext, clicking and/or highlighting responses when they have
been selected, and providing titles that tell the learner what section and/or objective they
are working on. One of the more common elements of this kind of feedback is providing
the page number.
278
You have probably seen programs that tell the learner what page number they are on and
out of how many pages (e.g., page 20 of 37 pages). Typically, this has been accomplished
as one of the last steps in program development since it requires knowing how many
pages are in the final program. The programmer then manually types in the page number
information on every screen.
Frameworks allow you to specify elements to appear on every page of the framework. By
embedding variables in display icons, this means you can display information contained
in variables to the learner (time in session, number of correct and incorrect responses,
etc.). Two variables that have been built into Authorware are specifically related to pages
on a framework: CurrentPageNum and PageCount. CurrentPageNum contains a number
that reflects the current page number being viewed. PageCount contains a number that
reflects the number of pages attached to the current framework. Because these are
variables, they change as the pages change. Add a page to a framework and PageCount
increases by one; move from page 5 to page 6 on a framework, and CurrentPageNum
changes from 5 to 6.
The combination of these features allows us to embed page numbers in our programs
from the very beginning, without having to know how many pages there will be
(although we should have a pretty good idea from our storyboards). To add page numbers
to your frameworks, open up (or create) a display icon in the upper portion of the
framework window (make sure it comes after anything that might cover it up), select the
279
text tool, and click somewhere on the screen (you can always move it later).7 Paste in the
CurrentPageNum and PageCount variables (or type them exactly) so that your text
appears like this:
Page {CurrentPageNum} of {PageCount}
Because CurrentPageNum and PageCount are inside curly brackets, when Authorware
displays them it will show the current values (i.e., the current page number and the
number of pages on the current framework). Because the words “Page” and “of” are not
in curly brackets, they will appear exactly as typed in relation to the two values of our
variables. Thus, if the learner is on page 12 of a framework that has 23 pages, they would
see the following:
Page 12 of 23
The last step to making this work involves setting an option inside the display icon
properties dialog box (as usual, accessed through ModifyIconProperties or by right
7
You may remember from the last chapter that we used variables inside a display
icon to provide feedback about performance to the learner. This is accomplished by using
the WindowVariables dialog, selecting the variable we are interested in, and clicking
the Paste button; this creates a copy of the variable name inside the text box we are
working on. In order to get the contents of the variable to show up (as opposed to just the
name of the variable), we put curly brackets around the variable name (i.e.,
{variablename}). This tells Authorware to display the value of the variable, in our case,
CurrentPageNum and PageCount.
280
clicking on the display icon and selecting properties from the contextual menu), shown in
figure 33, below.
Figure 33. Display icon properties dialog box.
Make sure that you select the “Update Displayed Variables” option is checked, as in
Figure 33. Otherwise, Authorware will display the variable correctly the first time but
never change (update) it.
Power Tip: Customizing the Default Framework. Once you have worked with
Authorware long enough, you may decide that most of your frameworks use the same
basic interface elements and navigation structures, and you may get tired of having to
create them each time. It is possible to change how the default framework looks in
Authorware. To create your own, custom default framework, do the following:
1) Open a new Authorware file.
281
2) Drag a framework to the flowline and modify it the way you want all default
frameworks to appear (or copy and paste one you have already modified to your
liking from another file).
3) Go to FileSave in Model
4) In the dialog box, browse to My ComputerC: (or whatever drive Windows is
installed on)ProgramFilesMacromedia Authorware 7 and select the file
“Framework.a6d”
5) NOTE: You may want to make a copy of this file prior to doing the next step. That
way you can always go back to the original.
6) Replace the file when asked.
Now, when you drag a framework onto your flowline, it looks like the one you prefer. If
you ever decide you want to go back to the original, throw away the Framework.a6d in
the folder and replace it with the backup copy you made in step 5.
Importing rtf files
As you can see, frameworks greatly simplify the process of creating multiple-scene
(page) programs by making it easy to align common interface elements, specify common
transitions, and navigate in linear and non-linear fashion. These features alone are reason
enough to justify their existence. It turns out that there is one more feature of frameworks
that was probably an afterthought in their development but may be the most significant
feature of frameworks.
282
One of the most laborious parts of creating interactive instruction with Authorware is the
process of actually typing using the text tool inside a display icon. As you have seen, the
text tool is quite rudimentary, making it difficult to create much more than block text
with standard tabs and indents. The addition of the RTF Object Editor in Authorware 7
increased the complexity and ease of creating new rich text format objects that can have
images, sophisticated tabs, formatting, and alignment features, and other welcome
additons. Nevertheless, this process only alleviates the problem somewhat, in that these
objects are saved as external files and must then be imported.
Even if this were not so, the RTF Object Editor is of no help in alleviating a more
significant issue; how to incorporate large amounts of existing text into Authorware. This
is a common need for those who are creating instructional modules based on existing
instructional material (lecture notes, handouts, etc.). Until the advent of Authorware 7,
the only way to get this information into Authorware was to open up the existing wordprocessed documents and copy and paste chunks into individual display icons. As you
can imagine, this was a tedious process, as each display icon had to be created, opened
up, text pasted in, styles applied, and closed.
Frameworks make this process automatic and effortless, creating in one step a new
display icon for every page of a document placing the text inside that display icon, and
moving on until the entire document has been brought in. Further, they allow you to
specify where on the screen the text should be brought in, how big the text box should be,
and what styles you want assigned to the text you bring in. The following section
describes how this process is accomplished.
283
Power Tip: As you will see in chapter 13, you can import rtf files in similar fashion and
attach them to sound and movie icons. This is a great way to bring in and synchronize
text and media in a slideshow fashion.
As with most things in Authorware, there is more than one way to bring in an RTF file. I
will show you the one that provides you the most control over how your file is brought in
and displayed in Authorware. This means a few extra steps, but in my opinion these steps
save you more time in the long run than they take up initially.
There are three rules you need to keep in mind when importing an rtf file:
1) Only RTF files can be imported in this fashion (you must do a Save As in your word
processor and select Rich Text Format as the type of document).
2) You must use styles in your document and make sure that every piece of text in your
document has a style assigned to it.8 You must also make sure that you have not
defined your text styles in your Authorware file yet OR that you use different style
names in your RTF document than you use in your Authorware file.
3) You must insert a hard page break in every place that you want a new page (display
icon) in Authorware to begin. Soft page breaks (the ones that your word processor
8
OK, not really. But if you don’t, you’ll create all kinds of goofy styles in
Authorware when you bring it in, and you will NOT be able to modify the text you bring
in by using font styles; you’ll have to open up each display and change them individually.
Don’t say I didn’t warn you….
284
inserts automatically when it thinks you’ve typed enough for one page) have no
impact on Authorware and will cause the entire document to be brought into one
display icon.
The first step is to modify the word processed document you want to bring in according
to the rules outlined above. Create styles named for the styles you plan to use in
Authorware (refer to your style sheet if you have created one. See Chapter 3 for more
information on this). I like to create ones called Title, Sub-title, and Body Text. Apply
each of those styles to the related portions of your document. Make sure that everything
you have typed in the document has a style assigned to it.
Next, insert a hard page break every place you want a new page (display icon) to begin. If
you have gone through the process outlined in Chapters 2 and 3, you will already know
how much text (number of words) fits in the area you have designated for text in your
interface. If not, you should go type in as much text as will fit in that area now, making
sure to use the style you created for body text. Count the number of words and use that
number to determine where to insert page breaks in your document. Finally, save the
document as an RTF (Rich Text Format) file.
Now return to Authorware and create a framework to which you want to attach pages.
Make sure you have set your framework up the way you want it to appear in your
program (create the buttons, titles, and background image elements) so that you will
know exactly where to place your text. Place one display icon to the right of this
framework and run your program. When Authorware stops and opens up the empty
display icon (the first page of your framework) use your text tool to click somewhere on
285
the screen and type at least one letter (it doesn’t matter what you type, this is just a place
holder). Select the arrow tool and position your text box where it should go on your
screen. Use the handles of your text box to stretch it to the width you want your text to be
(using your background image as a guide). Then select the text tool again, click inside the
box, and delete the character you typed.
Without clicking anywhere else, select FileImport, browse to the document you want
to bring in, select it, and press the Import button. Authorware will then display the dialog
box pictured in Figure 33:
Figure 33. Import RTF file dialog box.
As you can see, there are two options you can set relating to what to do about hard page
breaks and whether the text should be scrolling text or not. The default is the setup you
want in most cases, so just click OK. Authorware will then import your file,
automatically generating a new display icon for every hard page break it finds. It will use
the name of the document or the title of the document (see Power Tip below) as the
286
name for each display icon, appending a “:” and an incremental number (1, 2, 3, 4, etc.
for each additional display/page).
Finally, the last step is to open up your define styles dialog box (TextDefine Styles).
There you will see the styles you created and assigned in your RTF document. These
styles can be modified as needed just like any other font style. You may also see several
“junk” styles (e.g., Normal, Heading, etc.). These styles are generated from the style
template in your RTF file. Since you assigned only the styles you wanted to use, you can
select any of these other named styles and delete them.
Your text will have been brought in, placed on each display icon in the place and size you
specified in your first display icon, and maintained the font styles assigned to it.
Power Tip: Naming your pages using the Title feature of Word. A slick way to control
the naming of the display icons authroware creates when importing rtf files is to use the
Title feature of your word processor. For instance, Microsoft Word allows you to specify
a title for your document (this has no bearing on what you type as the title within the
document itself). The title of your document will be used to generate the first part of each
display/page name. Titling your document for the framework you are bringing it into
(e.g., Section 1), allows you to specify what the first part of each display/page is named.
If I title my document Section 1, then the second display icon will be named “Section
1:2”, the fifth will be called “Section 1:5,” and so forth. This allows you to name the
pages according to your branch points from your storyboards automatically. Note that
your first display/page will be Untitled (since you generated it), and you will need to
name it, but the numbering scheme will still be correct.
287
Tip: Bringing in content this way is also a good way to divide up work up in team
environment. Instructional Designers who don’t know Authorware can nevertheless
create the text content for the screens. The Authorware developers can then import that
text and have their content already created, saving time and money. Doing so requires
that the Authorware developers specify how many lines and characters per page, and
what styles to use in the document, but this is easily accomplished.
Case Study: Building a Glossary
A common use for frameworks is to create a glossary of words that the learner can look
up as needed while they go through the instruction. Creating a glossary requires using the
Call & Return function, which is typically the most difficult aspect of frameworks to
master. For that reason, this case study will focus on building a glossary. Doing so has
the added bonus of teaching you a new thing about font styles that has not yet been
addressed: the ability to make text styles that are interactive. In this case, the interactivity
will navigate to our glossary, so that the learner can click on a word, be taken to its
definition, and then return to the place they left off.
Call & Returns are just like Jump to Page navigations, except that they allow the learner
to Return to the place they left off. Earlier in the chapter, we used navigation icons as
responses (buttons) in a framework to allow the learner to Jump or Call to another page
on a framework. This time, instead of using a response, we will create a hot text style that
we can apply to words that will make those words function like hyperlinks in a Web
288
page. Even though this differs from our earlier example, all the rules and procedures for
specifiying a Call & Return remain identical.
To build our glossary, we’ll start by defining a new font style called Hot Text. We’ll
specify all the characteristics of this style just as we would any other style. In this case,
we’ll make it Times New Roman, 12 point, and Blue for the color. Before we close the
dialog box, however, we’ll need to modify the column to the right labeled Interactivity
(See figure 34).
Figure 34. Font styles dialog box.
Note that by default, Interactivity is set to “None.” In this case, we want our text style to
be able to link to another place in the file (our glossary), so we set the interactivity to
Single Click. Now that we have told it how we want the learner to be able to activate our
text (by clicking once), we need to tell it what to do when clicked. Checking the
289
“Navigate” box will tell Authorware that clicking on the text should cause the text to
navigate to some page on a framework. Note that we can also tell it to change the cursor
when over a word with this style applied to it by checking the Cursor box and specifying
the type of cursor to use (we’ll use the hand in this case). Once done with these settings,
we hit Modify to apply the changes and close the dialog box.
Now we’ll create our instructional framework. For the purposes of this exercise, name it
anything you like and attach two display icons to it as pages. Inside each one, type a
sentence with a noun or verb in it that you intend to create a definition for in the glossary.
Use two words that start with a different letter so that you can make two different pages
in the glossary.
Next we’ll go create our glossary framework. This will be a framework at the end of our
file. Inside this framework, we’ll put a display icon. Inside that display icon, we’ll create
a large yellow box that covers nearly the entire screen. This will form the background for
our definitions for each word.9 We do this because we want our definitions to “cover up”
the screen the learner just came from (otherwise, our text would just show up
superimposed over the page they came from, since a Call & Return does NOT erase what
is on the screen).
9
Remember that when we jump (or call) to a page on a framework, Authorware
first routes the learner through the framework and then to the page, so anything we want
to show up on each of our pages (such as a background image) can be placed inside the
framework.
290
On our interaction icon inside the framework, we want a navigation icon attached as a
button response. We’ll label the button “Done,” and set the navigation to be an Exit
Framework/Return (see the earlier section on Call & Return if you don’t remember how
to do this). When you are finished, the inside of your framework should look like this:
Now attach two display icons to your glossary framework. Inside each one, type the
definition of one of the nouns or verbs that you created in the pages on your instructional
framework. Make sure to put only one definition on each page. Name these icons for the
word that they define. When you are done, your framework should look something like
this:
291
In my example, I have two pages in the instructional framework, each of which contain a
word I want to define in my glossary. I will apply my hot text style to those words in
those display icons. As soon as I do that, I am presented with the following dialog box:
Notice that it is identical to the dialog box for all navigation icons. This is because
navigation in a font style IS a kind of navigation icon, even though you don’t actually see
the navigation icon itself (it is the word instead). Because I want to temporarily go to the
glossary and then return, I want to use a Call & Return type of navigation. And because I
am going to a specific page on another framework, I select “Glossary” from the
framework menu, and then select the icon name “Apple” since I want this word apple to
jump to the glossary page with the definition of apple on it. I repeat this process with the
word Bumblebee on my second page, this time pointing to the page with the defintion of
bumblebee on it. Be careful to specify that these are Call & Returns, or your glossary will
not work.
292
Now run your program to test it out. Note that the yellow box covers up the previous
screen so that you can see the definition. Click the button named “Done” to return to the
page of instruction. Move on to page two and test the second word.
You may have noticed that the buttons from your instructional framework continue to
show up when in the glossary, which can cause navigation problems for the learner. In
Chapter 11, you’ll learn how to use variables to turn buttons on and off. For now, you can
get around this issue by setting the layers of all the icons in your glossary to be “higher”
than those on your instructional framework. This is accomplished by doing the following:
Right click on the display icon and interaction icon inside your framework and select
properties. Type the number 100 in the box labeled Layer (you will need to select the
Display tab in the interaction properties dialog box to find the Layer box). This will force
Authorware to put this items at a higher layer than anything else in the file. Repeat this
process for each of the display icons on your Glossary framework (the ones with the
definitions in them). Now run the piece again. Since all your icons are at a higher layer
than the buttons on the instructional framework, your yellow box and definitions “cover
up” those buttons.
Take a look at the Glossary example for Chapter 7 on the web site to see how I built
mine. You can also download the Glossary model for later use in your own files.
Presenting Information
293
Because of the way frameworks are designed, they lend themselves well to developing
linear tutorials. While tutorials can be effective, it is important to remember that
frameworks can also be used to create open-ended learning environments such as
simulations, games, and thus are as appropriate to non-linear, constructivist approaches to
learning. The key to accomplishing this lies in navigation icons, which as you recall can
jump from anywhere to anywhere else as long as the destination is on a framework page.
The earlier example about a glossary is a simple example of this priniciple; every time
the learner accesses our glossary, (a navigation element under learner control), they are
moving through our program in a non-linear process. Since we don’t know which words
they may want to have defined, we allow them to choose where and when they get access
to the definitions.
In a similar fashion, we can allow the learner to control how and when they view the
different elements of our program. In mathematics game I mentioned earlier, the learner
was able to move around a room in a house, measuring walls, doors, and windows at their
own pace and in their own sequence. This was accomplished by creating a page on a
framework for every wall in the room. Hotspots were added on each “wall” that were
attached to navigation icons pointing to other pages on the same framework. Clicking on
a hotspot on the left side of the wall caused the program to navigate to the wall in the
room that was to the left. Likewise, learners had access to a reference book and a
workbook, each of which were on their own frameworks; clicking on the icons for the
reference book and workbook from anywhere caused the program to navigate to the
relevant framework. From the learner’s perspective, the program is one big environment
in which they can navigate at will, yet the entire program was created using frameworks.
294
Guidance
Frameworks provide some unique opportunities for learner guidance. In addition to the
guidance you provide using interactions on each page of your framework, you can
provide metacognitive guidance throughout your instruction as well. Frameworks allow
you to place elements inside them that will then be “revisited” every time the learner
moves from one page to another, you can use variables and conditional responses
(covered in later chapters) to create advisement. Advisement generally refers to one of
three things (e.g., Gray, 1988; Johansen & Tennyson, 1983; Tennyson, 1980a, 1980b;
Tennyson & Buttrey, 1980):
1) advisement about an optimal path or sequence through the instruction
2) feedback advice about performance and suggestions for number of examples or
practice items to attempt
3) advice about whether to seek additional instruction
In the first case, we can structure our program using frameworks to reflect the optimal
path through the instruction in a linear fashion, but allow the learner to deviate from that
path. We might then tell them that it is suggested that they following the linear sequence
(which should be presented to them in the beginning and accessible throughout the
program). In the second case, we can track their success with practice items overall and
provide feedback about how many examples or practice items they should do based on
that performance. In the third case, we can present them with the option for participating
in more instruction in the areas they are weak on (based on performance during practice
295
or assessment) and allow them to determine whether to view that instruction. This
preserves the goal of learner autonomy, which some feel is an important goal for all
learning (Tennyson, 1981). Presenting the learner with advice about what to do but
allowing them to decide is called learner control with advisement. We can also use
conditional responses and variables to automatically provide more instruction, examples,
and practice items based on the learner’s performance to that point. This is referred to as
adaptive control. Adaptive control is generally hard to program into CBI/CBT, but
frameworks make it relatively easy to implement. Adaptive control, because it allows for
individualized instruction, has been shown to be among the most effective types of
CBI/CBT (Johansen & Tennyson, 1983; Tennyson, 1980a; 1980b).
Assessment
It is a good idea to put your assessment on its own framework so that you can allow the
learner to jump to the quiz (by using a button or hotspot or pulldown response connected
to a navigation icon on each instruction framework) whenever they want. Otherwise, you
force the learner to complete long sections of instruction that they may feel they are
already competent in. While you could also put your assessment on the same framework
as your instruction, it makes it harder to keep track of your program. Your assessment
may also require different interface elements and multiple pages, which is easier to
handle when it is on its own framework.
Summary
While it is possible to create sophisticated interactive instruction without using
frameworks, they are tremendous labor-saving devices, and in some cases allow you to
296
do more than would otherwise be feasible. Frameworks allow you to organize your
instruction, provide common elements on each page and maintain consistency, create
navigation options quickly and easily, specify transitions between pages, import rtf files
and automatically create new display icons for each page, and build sophisticated
navigations called Call and Return that allow the learner to return to the last place they
were in the instruction.
Frameworks look like one icon, but are really made up of several icons. In this respect,
they are like maps. Opening up a framework icon reveals an interaction icon with some
default response items attached to it and a display icon preceding it. Everything that
appears inside a framework will appear on every page attached to that framework in the
exact same spot as they appear inside the framework. This includes any icon you add to
the inside as well as the interaction and responses that you build there. Some examples of
common elements might be the title of that section, the current page number (through the
use of a variable), and navigation buttons.
Pages are added by dragging icons to the right of a framework. Although you can create a
page by dragging one of several icons, it is most common and useful to use map icons,
which can then contain one or one-thousand icons inside them, including interactions. It
is helpful to think of each “page” as a “scene.”
Frameworks accomplish their magic through the use of navigation icons. Navigation
icons allow you to navigate from one page to the next, whether those pages are right next
to each other, separated by 30 other pages, or on completely different frameworks.
297
Navigations can be one way (jump to) or round trip (call and return). The only rule is that
they can only go TO a page that is on a framework.
Exercises
1) If you wanted to make your program exit a framework automatically when the learner
hit the last page, but didn’t want to put an Exit Framework navigation icon inside
your framework (e.g., you don’t want it on every page of the framework) how could
you do it?
2) Import a document you have created elsewhere in a word processor (any document
will do) into a framework. Have Authorware create a new display icon for every
paragraph in the document (hint: there is a missing step here!).
3) Take the program you have created to this point and use a framework to deliver the
instruction and practice assessment portions.
a) The introduction should be on the flowline and not part of the framework. Your
performance data (number correct, etc.) should be on a separate framework that
comes after the instruction framework.
b) Use a forward and back button to navigate between pages.
c) Include an exit button that takes the learner to the performance data page using a
call and return structure. Present the data and ask them if they are sure they want
to quit. If they answer yes (button, hotspot, or your choice), quit the program. If
they answer no, take them back to the exact place they were in the instruction.
298
d) Use “Vertical Blind” for the transition between each page
e) Have the title of your instruction appear in the upper left corner of the screen at all
times, and make sure it does not move when navigating from screen to screen.
299
References
Gray, D. M. (1988). The use and effect on performance of learner control and
advisement in a computer-based educational statistics lesson (Doctoral dissertation,
University of Illinois at Urbana-Champaign, 1988). Dissertation Abstracts International,
49(06), 1434A.
Johansen, K. J., & Tennyson, R. D. (1983). Effect of adaptive advisement on
perception in learner-controlled, computer-based instruction using a rule-learning task.
Educational Communications and Technology Journal, 31(4), 226-236.
Tennyson, R .D. (1980a, April). Advisement and management strategies as design
variables in computer-assisted instruction. A paper presented at the annual meeting of the
American Educational Research Association, Boston, MA.
Tennyson, R.D. (1980b). Instructional control strategies and content structure as
design variables in concept acquisition using computer-based instruction. Journal of
Educational Psychology, 72(4), 525-532.
Tennyson, R. D. (1981). Use of adaptive information for advisement in learning
concepts and rules using computer-assisted instruction. American Educational Research
Journal, 18(4), 425-438.
Tennyson, R. D. (1984). Artificial intelligence methods in computer-based
instructional design: The Minnesota Adaptive Instructional System. Journal of
Instructional Development, 7(3), 17-22.
Tennyson, R. D., & Buttrey, T. (1980). Advisement and management strategies as
design variables in computer-assisted instruction. Educational Communications and
Technology, 28, 169-176.
300
Chapter 8: Publishing Your Program
Overview
Now that you know how to create basic interactive instruction using Authorware, you
need to know how to distribute it to your learners. Obviously, you can’t count on then
owning Authorware, nor can you expect them to purchase it; even in volume the cost
would be prohibitive for an organization of any size. To solve this problem (and to
prevent you having to give away your code and risk learners inadvertently messing it up
when running), Authorware allows you to create what is called an executable, which
means that you can turn your program into a file or files that run by themselves, without
requiring a copy of Authorware to be installed. This executable can be played from a CD,
LAN, or local hard drive. Further, you can even create a version that will play back over
the web, provided the learner has the correct plugin installed in their web browser.
In the orginal plan for this book, before Authorware 7 was released, this topic would have
required a minimum of two full chapters. Those of you just learning Authorware now
will never know how easy you have it, although if you ask any of us who worked with
Authorware 5 we’ll be happy to regale with horror stories (when I was your age, we
didn’t HAVE “one-button publishing”).
The price of upgrading to Authorware 7 is completely justified (and then some) by OneButton Publishing. Those of you who have worked with Flash 4 or 5 will recognize this
feature. It is now possible to simultaneously publish your file for playback on CD, LAN,
301
or the Web; Authorware will ensure that all the files you need are present, generate an
html page, and upload all needed files to the place you specify.
Prior to version 6, all Authorware would do for you is package your file; you had to
create an html page, figure out which of the hundreds of xtras, UCDs and DLLs, and
media files were required, upload them all and pray that it worked (which it NEVER did
the first, second, or twelfth time).
This chapter will walk you through the basics of preparing your piece for distribution via
CD, LAN, or Web. Unlike other topics in this book, it will be dealt with completely in
one chapter. However, in recognition of the fact that in many cases you do not need to set
(or understand) any advanced features, I will present it in two ways. In each section, I
will provide you with “The Easy Way,” which will be a list of steps and/options to set
that will result in a program that runs in almost any situation. If you choose to follow
only those steps, your program will almost certainly work wherever you use it.
This will be followed by a more in-depth discussion of the features and options that you
can set in that part of the publishing process. You should read this section to make sure
that there is nothing in there you need for your setup. In most cases, this additional
information represents ways to optimize and streamline your file for unique situations,
but there may be features that will be important to your publishing scenario.
Objectives
•
Prepare your program for distribution via CD, LAN, Hard Drive, and Web
302
•
Adjust settings to optimize your program for playback under different conditions
•
Publish your file to the Web via the Remote feature
•
Test your program
Save & Compact
Contrary to expectation, the most important step in preparing your piece for distribution
has nothing to do with publishing it. Because of the complexity of Authorware, its legacy
of development through 6 versions over 10+ years, and/or inefficient program code,
Authorware has a bug in it that only creeps in over time as you develop and work with a
program. It turns out that every time you make changes to your program (e.g., add or
delete an icon or icons, move pieces to and from a library, copy and past icons)
Authorware actually fails to do a perfect job of keeping track of these changes.
Remember that although you are creating a program using icons and a flowline,
Authorware itself uses programming code to accomplish what you are telling it to do. So
every step you make is translated by Authorware into programming code. When you
delete an icon, you are telling Authorware to remove the code associated with that icon,
which it pretty much does. But this process leaves traces in the code, and over time,
these traces build up. In their most benign instances, this results in a program that takes
up more space than is actually required. As a purely hypothetical example, if I build a
program that is ultimately comprised of 1000 icons, but in the course of building that
program I used 2000 icons (because of mistakes, dead ends, and other modifications), my
file might take up 4 megabytes of disk space. If I were to then recreate that program icon
by icon, using only the icons needed (i.e., without making any false steps or deletions),
303
the same exact file might be 2 megabytes in size. Given hard disk sizes today, this is not
the end of the world, but it illustrates how much “dead code” accumulates in a file while
you are working on it.
More significantly, this dead code can cause errors in your program; the longer you work
with a file, the more likely you are to run into these bugs, and the more likely they are to
be permanent and unrecoverable. Obviously, this is a problem you want to avoid rather
than attempt to solve after the fact. Authorware has had a feature called Save & Compact
built into it since at least version 4. This feature forces Authorware to take a look at what
you have in your file and compare it rigorously to the code it is using to represent your
file; any discrepancies it finds in its code will be removed so that your file and its code
match as closely as possible. You access this feature by selecting FileSave & Compact.
You should do this regularly and frequently (at the end of every authoring session or
every 2 hours, whichever comes first).
Save & Compact looks and behaves the same as the Save dialog box with one significant
difference; you must rename your file when using Save & Compact. I suggest that you
incorporate this feature into your regular authoring process; develop a naming scheme so
that you have different versions of your file that you can go back to should you discover a
problem with your file. I use the letters of the alphabet for my scheme, appending and
incrementing a letter to the end of my file (e.g., MyFirstAuthorware-a). When I hit “z,” I
go back through the alphabet as many times as needed (-aa, -aaa). I normally make it
partway through the third alphabet cycle for a significant program (one hour of
instruction or so). I also store all of the old versions in a sub-folder called Old Versions
so that my directory does not get too cluttered.
304
Publishing
This section will walk you through the most common settings, emphasizing only the
minimum steps needed to accomplish most publishing. The publishing process begins by
creating your publishing settings (FilePublishPublish Settings). Figure 35 presents
the publish settings dialog box. Notice that there are five tabs at the bottom of this
window. We will examine them in turn, describing the basic functions each one.
Figure 35. Publish settings dialog box: Formats tab.
Formats
The Easy Way. Check the format you want (CD/LAN/HDD or Web) and then make sure
every box and option is checked for that format.
305
This is where you tell Authorware what kind of program you want to make. There are
two main formats: Executable and Web. It is possible to publish for both versions
simultaneously; Authorware will specify a different path and create a different file for
each format. The top box (CD, LAN, and Local HDD) represent executables, which
means the program is designed to run as a stand alone program. The bottom portion is for
publishing files you intend to play back over the Web. In both cases you indicate what
you want by checking the box next to the format and options you want. The window at
the top represent the current file you want to apply these settings to (you can load a
different file to publish by using the “…” button to browse to another file).
The Package As check box serves to tell Authorware that you want an executable version
of the program; the window to right of that checkbox tells Authorware the destination and
name of the file to create. You can use the “…” button to browse to a different
destination (folder) or you can edit the path name and file name to change the destination
and name of the file (don’t change the “.exe” or your program won’t run!). You can
change the path and file name of your web version and its accompanying web page in a
similar fashion. Until you have packaged a few programs, I recommend taking the default
locations.
Checking “With Runtime….” causes Authorware to make one file that runs by itself. If
this box is NOT checked, you will need to distribute the runtime engine (C:\Program
Files\Macromedia\Authorware 7\runA6w32.exe) with your piece as a separate file. The
only reason to do this is if you have multiple programs you are distributing and want to
save the space by only including one copy of the engine (if you checked the box, each file
would have a copy of the engine embedded in it). The size is negligible (1.5MB) in my
306
opinion, and the risk of the learner inadvertently separating your program from the
location of the engine is not worth it.
The checkbox for Copy Supporting Files (in both portions of the Formats Tab window)
tells Authorware to include a copy of all of the files you need to run the program (why
you wouldn’t want that is not clear to me…). Note that you can choose to have
Authorware package your file for the web player but NOT generate a web page. This
option is for those who wish to generate their own web page instead.
Web Player Tab
The Easy Way. Check all four boxes on this tab.
You have 4 options to choose from in this dialog box.
307
Figure 36. Publish settings dialog box: Package tab.
“Package All Libraries” Internally tells Authorware to take any libraries you have and
embed them in your file (so that you only have one file). If you don’t check this,
Authorware will create a separate file for your program and for each library.
“Package All External Media Internally” tells Authorware to embed any external media
inside your program. If you do not check this, any external media will be copied to the
same directory as your program (where it can potentially be deleted, moved, renamed,
etc.). While selecting this option is the most conservative method (least likely to result in
error), there are two things to consider. The first is that in some cases, you want to keep
your media external so that you can replace it at any time (e.g., if a sound file changes,
you can just send replace the sound file in the directory where the program lives, and you
are done). The other thing to remember is that most movies (avi, quicktime, mpeg, etc.)
cannot be embedded in a file and must remain outside the file. Only movies made with
programs like Flash and Director can be embedded internally.
“Referenced Icons Only” is only active if you are using a library AND there are icons in
that library that are not used in the current file (as is the case when using a standard
media library for multiple projects). Choosing this option will tell Authorware to only
embed/package icons that are currently used in the file you are publishing. This saves
space, but does little else.
“Resolve Broken Links at Runtime” tells Authorware to let the learner locate files when
the program encounters a broken link (from external media or missing libraries). If you
don’t select this option and the program encounters a broken link when running, the
308
program will present an error message and usually keep running (depending on the
navigation you built into your program—if you require the learner to interact with the
missing link, it may prevent the program from continuing). In my opinion, this option is
of little use, as you cannot count on most learners to know what file to locate, where it is
located, or how to find it. In fact, it is more likely that they will create a bigger problem
than that they will solve it correctly, so I would rather present an error and have it move
on. Of course, if you take The Easy Way as I suggest throughout, you are not likely to
have any broken links anyway, which is a better solution.
For Web Player Tab
The Easy Way: Take the defaults on this tab (56kbps, Show Security Dialog).
The Web Player tab is only visible if you have chosen to publish for the Web. In order to
understand the options in this and the next publishing tab, you need to know how
Authorware works over the Web. Because any program is likely to be several megabytes
in size, not including any external media like videos, it quickly becomes impractical to
download even small programs to the learner’s local hard drive and then run them from
there. Even if that were practical, however, there would still be the issue of getting
learning and performance information (time spent, number correct, etc.) from the learners
local computer back to the web server where it can be tracked and stored.
To solve this problem, Authorware takes your file and chops it up into lots of little pieces.
The size and number of these pieces depends on the size of your piece and the bandwidth
you expect your learner to have (larger pieces require larger bandwidth but make the
309
piece more responsive). Authorware calls these pieces
“segments.”
It turns out that this is not enough, however, because most pieces will not run in an
entirely linear fashion from start to finish—the path the learner takes through the
instruction may vary with performance and learner control. Authorware needs some way
to handle this nonlinear process. It accomplishes this by creating a file that tells it which
pieces are needed to run different sections of your program; when those sections are
called for, it consults this file to see which segments are needed and downloads them.
Authorware refers to this file as a “Map.”
Figure 37. Publish settings dialog box: Web Player tab.
310
The top of the For Web Player tab is reserved for options for your Map file and segments,
while the bottom is for using Authorware Advanced Streamer. Advanced Streamer allows
you to reduce the wait time your learner has when viewing your piece over the web. It
accomplishes this by using past learner experiences with the piece to predict what pieces
of the file to download in the background (i.e., before the learner needs them). Advanced
Streamer will be covered in Chapter 15.
The first box you can modify is the Segment Prefix Name. This four letter prefix will
precede the names of every one of the segments in your file. The balance of each segment
name will reflect a sequential numbering scheme from 0000 to 9999. This can help you
identify the program that these segments belong to, and theoretically allow you to store
multiple programs at the same directory level in your server (since each has its own
prefix, they will be lined up in your folder when you view the contents).
The second box allows you to specify the segment size you want to use based on the
bandwidth you expect your learners to have. The smaller the bandwidth, the more pieces
there will be. There is not as much of a tradeoff as you might expect however, and your
piece will run pretty well at any of the sizes you choose. The only caveat to this is if you
have external files like audio and video. If you package your file with external media
(and you often have not choice as with video), these files will stay the same size and will
NOT be broken up into segments. This means that when your learner selects a part of the
program that requires these external media, the learner must wait until the file has been
downloaded to their hard drive before anything happens. In these cases, you should be
delivering via a larger bandwidth so that the lag time is less. If you can’t, then you should
not include large media files.
311
Web Page Tab
The Easy Way: Type your page title in the page title box; Select “Detect Web Player”
from the HTML Template box; click both “Match Piece” buttons; Select
“OnTopMinimize” from the Window Style menu.
The Web Page tab only appears if you have selected “Web Page” on the Formats tab
earlier. If you are publishing to the Web, you need an HTML page because Authorware
will not run unless it is embedded in a web page using the EMBED command.
Embedding your program in an HTML page also allows you to make a link to the
program by using the url for the web page in which your program is embedded.
There are several options on this page that control how your piece looks when it plays
back.
312
Figure 38. Publish settings dialog box: Web Page tab.
Authorware provide a generic web page template for you (See HTML Template) called
Default. You can choose other templates from the drop-down menu. The Data Tracking
web page template is used for interacting with Learning Management Systems (LMSs).
LMSs are front end systems used in corporations to manage and track institution-wide
training programs. Authorware can communicate with these systems using AICC CMI
protocols, which will be discussed in Chapter 16. For now, just remember that IF you use
CMI you will need to use the Data Tracking template.
The Detect Web Player template is an HTML page that embeds your piece in a web page
along with some java script that determines if the learner has the Authorware Web Player
installed in their current browser. If they do not, the script automatically provides the
option to the learner to download and install the player. If they refuse to do this, a
message pops up saying they don’t have the player installed. You also have the option of
using a template for IE or Netscape only if you are developing specifically for one
browser or the other. All of these templates are located in the Authorware 7 folder and
can be opened and modified as needed.
The page title is where you type the title you want your HTML page to report as its title.
A full discussion of HTML commands and syntax is beyond the scope of this text, but it
is important to know that the page title is NOT the actual title that will appear on screen,
nor is it the actual name of the file.
The bottom half of the window is titled the Playback section. The settings in this area
allow you to control the basic look and feel of your web page. You can set the width and
313
height (in pixels) for playback and you can set the background color of the web page. In
most cases you want the size to match the size you developed for. If you want to be sure,
you can click the Match Piece button and it will set these values to match what you set in
the File Properties of your program. The background color refers to the color of the page,
which is white by default. The color you choose depends in part on what you choose
from the Window Style drop down menu, but it is usually safe to match it to the piece.
The Web Player menu allows you to choose from a small, medium, or large version of
the Web Player. I usually specify the Full Player, but if your learner has bandwidth issues
you may elect to use the Compact or Complete versions.
The Palette you choose impacts whether color accuracy preference should be given to the
Browser (background) or your program (foreground). If you take the default
(background), the colors in your program may be slightly off. If you choose foreground,
the browser and interface buttons may change color, which can be disconcerting. Usually,
however, you want your program to look the way you designed it, so I recommend
choosing foreground. You can solve this problem entirely based on what you select from
the last option, Window Style.
Window Style refers to how you program runs in relation to the browser window. If you
choose inPlace (the default), it will run within the browser window, meaning that the
learner will be able to see the browser window (buttons, address, text, etc.) around your
piece. If your piece is set to the same or larger size that the current browser is set to, your
piece will be only partially visible, requiring the learner to scroll back and forth/up and
down to view your screen. This option is appropriate when you are embedding a small
314
piece inside some web-based instruction (e.g., to illustrate a concept in a web-based
course). In that case, you might develop and package the piece for 320 x 240 so it can be
fully displayed inside another web page (i.e., the part of your web-course where it
belongs).
If you choose OnTop, your piece will be displayed in its own window on top of the
current browser window. If that browser window is larger than your piece, the learner
will still be able to see it in the background; if it is smaller, it will be obscured by your
piece. If you choose OnTopMinimize, your piece will not only be displayed on top of the
current browser, but that browser window will be minimized so that it cannot be seen or
interacted with while your piece is running. In cases where the screen resolution is set to
the same resolution as your piece, your piece will take over the entire screen. This can be
useful in that it minimizes the likelihood that the learner will accidentally click on their
desktop or some other element than your piece.
The last thing of note for now on this tab is the button to the right labeled “Remote.” This
button lets you publish your web version directly to the server where you intend to
deliver it from. This is accomplished through a protocol called File Transfer Protocol, or
FTP (just at web pages are delivered through Hypertext Transfer Protocol, or http). It is
possible to ignore this feature and publish your files to your local desktop, but you must
then use an FTP client like Fetch to upload your files to the server later. If you always
publish to the same server (or almost always), it is worth learning how to use the Remote
feature. To do this, you need to enter data about your server in the Remote dialog box
(see figure 39). Every server is different, and explaining the details of server
nomenclature and FTP configuration is beyond the scope of this book. However, by
315
purchasing this book you have automatically been given limited access to our test server.
You will be able to load your final program (the one you are building as part of the
exercises) on our server to test it out. Go to the website now and view the section on
uploading your program. In it you will find a completed version of what the Remote
section or FTP dialog box should look like for uploading to our server.
Files Tab
The Easy Way: Select any file with a broken (red) link and click the Delete File(s)
button. Click the Publish button to publish your piece. Look in the folder called Published
Files located in the same place as the program you are publishing.
The files tab presents a list of all the files that Authorware believes are needed to make
your program run correctly on the learner’s computer. You may have noticed when you
opened the Publish Settings dialog box that Authorware began scanning the flowline for
files. During this time, it looks at all the things you have created in your program and
determines what files will be needed to implement those things. To understand this
process, you need to know something about Xtras, UCDs, and dlls. The good news is,
you don’t really have to understand this process if you don’t want to; just let Authorware
do it’s magic!
316
Figure 39. Publish settings dialog box: Files tab.
It turns out that Authorware is not a completely self-contained program. While it is able
to accomplish the vast majority of what it does on its own, there are several facets and
processes for which it relies on small, external pieces of code. The majority of these are
called Xtras, but there are other types as well. Together, there are approximately 120-150
separate files, each of which provides some kind of functionality (e.g., the ability to play
different sound and video file types, display different graphics types, etc.). If you were to
publish your program without any one of the necessary files, your program would not
work correctly. It used to be that you had to guess about which ones you needed, copy
them over into the folder with your program, and test it out. In most cases, we gave up
and just copied everything over (which added about 15MB to the size of every file we
published). Now Authorware scans your file every time you go to publish it (if you have
317
made changes since the last time) and copies only the files that are needed. These files
appear in the list on the Files tab.
By default, the files you need will be checked. You can uncheck any that you want, but
your program will not work if you do so. The only exception to this rule is that in some
cases, Authorware becomes confused about one or two files. Usually, this shows up as a
red broken link (
) as opposed to an blue unbroken link (
). In these cases, you must
select that file and hit the Delete File(s) button, or it can cause errors. In rarer cases,
Authorware may not find a file that you do actually need for your piece (this has only
happened once to me), in which case you may need to manually add the file by clicking
the Add File(s) button and locating the file yourself. You can determine which file is
missing by running the packaged piece and writing down the name of the file or xtra that
is causing the error. Ninety-nine point nine percent of the time, however, you will never
need to do anything with this tab beyond looking for any broken links.
You now need only hit the Publish button and let Authorware do the rest.
There is not much about the publishing process that lends itself to a discussion of
learning principles. By the time you are ready to publish, you have already made your
instructional design and strategy decisions. Assuming you have chosen your media and
instructional strategies according to your objectives, learner characteristics, and the
nature of the content, it is still possible to deliver your product via Web or CD-ROM.
318
However, it is important to remember that your decision to publish for the web or CDROM is not simply a matter of preference. Each medium has its own strengths and
weaknesses, and careful consideration of these factors and your learners is required.
Although chapter 2 treats these issues in more detail, it is worth reiterating some of the
highlights here.
What are you delivering?
While you can deliver video, audio, animation, and interactive instruction via Web or
CD-ROM, each has its own strengths and weaknesses. Video must be streamed if
delivered via the Web. Streamed video begins to play back as soon as enough of it has
downloaded to ensure that it will play continuously while the rest of the video is
downloaded in the background and played as needed. Non-streamed video means that the
user must wait until the entire video has been downloaded before it will play. Given that
you cannot count on more than 100k per second even in high-bandwidth environments
and that even a short, small video is likely to be several megabytes, this can mean waits
of several minutes. If you have a lot of video and/or cannot count on good bandwidth,
CD-ROM may be a better choice, since the video can be played immediately when called
for.
If you stream your video, the video must be prepared correctly (as streaming video) and
should be delivered from a streaming server. This means extra development time and
careful attention to the resources your client can support (bandwidth and server
technology). Additionally, your client may not be able to devote the space you need to
store large amounts of video. Given that CDs routinely hold 700MB or more of
319
information, it may be more practical to deliver the video via CD than Web. It is
important to note that you need not choose one or the other delivery method exclusively;
It is possible to deliver your piece by Web and distribute your media files (those that are
external, that is) via CD-ROM.
Where & when will the learning take place?
Where and when your instruction is intended to be used can help determine which
medium to use. In the corporate world, it is not uncommon for employees to have access
to high-speed, high-bandwidth computers at their desks, making web delivery feasible if
the training is to take place during working hours. The same MAY be true for CD-ROM
delivery, although you might be surprised at how many employers will not equip the
employee computers with CD drives and sound cards, fearing that employees will install
software or, (gasp) play music during working hours. If the learning is to take place
outside working hours, you should consider the likelihood of high-speed Internet access
in the home. While DSL and cable modems are becoming more common, they are by no
means ubiquitous yet, making CD-ROM a better choice in some cases.
The same considerations hold true for learning in school environments. K-12 institutions
are more likely to have CD-ROM access than high-speed Internet access, while colleges
and universities may be counted on to have both. If, however, the students will be
learning off campus, CD-ROM may be more common than high-bandwidth. And finally,
you should also consider the importance of access to your product. If you expect learners
to have easy access to your product in multiple places (e.g., from several places within
320
the work environment), Web delivery may be best, since it is accessible on any computer
connected to the Internet or Intranet.
How stable is the content?
In chapter 2, I suggested that CBI/CBT is only appropriate for content that is stable (i.e.,
not likely to change much over time). In some cases, however, the instructional content
may be stable but the media you use may need to change. In some cases, you may want to
update video examples or illustrations to keep them looking contemporary or to reflect
new situations and scenarios. Making such changes in Web-delivered instruction is a
simple matter of replacing the videos on your server, one time; everyone then has access
to the new content. Delivery via CD-ROM in this case would mean burning a new copy
for every learner, shipping them out to all the learners, and making sure that the old
copies are gathered or destroyed. The latter is one of the major drawbacks of CD-ROM
based training.
Summary
Publishing your piece is a matter of making a series of decisions via the publishing
settings (FilePublishPublish Settings). These decisions involve making selections in
up to five areas, each represented by its own tab: Formats, Package, For Web Player,
Web Page, and Files.
Under Formats, you select whether to publish to run from a hard drive, a CD-ROM, or
the Web. If you select Web, you will have access to the tabs labeled For Web Player and
Web Page.
321
On the Package tab, you make decisions about your media and libraries. on the For Web
Player tab, you make decisions primarily about the bandwidth of your target platform. On
the Web Page tab, you make decisions about what kind of web page to create to embed
your program in (e.g., one that downloads the web player automatically), how your piece
should play in relation to the browser and screen (e.g., the colors it uses, whether it is in a
browser window or on top of the browser), and the screen resolution of your piece. The
last tab, Files, shows you what files Authorware thinks are necessary to your piece. You
can add or delete files here manually as well.
While ultimately you will need to understand all of the different options within the
publishing settings, it is possible to publish your piece in a few simple steps (see “The
Easy Way,” below). Each method of delivery has its own strengths and weaknesses, and
the appropriate method depends largely on your audience, the stability of the content, and
where and when the instruction will be used.
The Easy Way
For CD-ROM/Hard Drive
Formats
•
Check CD/LAN/HDD
•
Make sure every box and option in this area is checked.
Package
•
Check all four boxes on this tab.
Files
•
Select any file with a broken (red) link and click the Delete File(s) button
322
•
Click the Publish button. Look in the folder called Published Files located in the
same place as the program you are publishing.
For Web
Formats
•
Check “For Web Player” & “Web Page”
•
Make sure every box and option in this area is checked.
Package
•
Check all four boxes on this tab.
For Web Player
•
Take the defaults on this tab (56kbps, Show Security Dialog).
Web Page
•
Type your page title in the page title box
•
Select “Detect Web Player” from the HTML Template box
•
Click both “Match Piece” buttons
•
Select “OnTopMinimize” from the Window Style menu.
Files
•
Select any file with a broken (red) link and click the Delete File(s) button.
•
Click the Publish button.
•
Look in the folder called Published Files located in the same place as the program
you are publishing.
Exercises
323
1) Open the program you have created to this point and publish it for CD and the Web
(i.e., two versions).
2) Test both program versions from your local hard drive (you can open your web
version by launching your browser and opening your index.htm page in the web
folder—FileOpen File).
3) Burn one copy to CD and publish the other using the Remote feature in Authorware.
324
Chapter 9: Variables, Functions, & Lists
Overview
This chapter will introduce you to the basic concepts of using and creating variables and
functions. Variables and functions are what allow you to extend the basic authoring
abilities of Authorware beyond what can be done solely with the authoring icons. It may
seem odd that the first chapter of this second half of the book should begin with variables
and functions rather than with advanced interaction or animations, but this is a reflection
of the power and importance of these authoring tools.
You will learn how to use variables to track information, to use that information to do
things like customize feedback to the learner and specify dynamic navigation through
your program. You will also learn how functions can allow you to do things like test the
learners platform, write and read data to external files, and jump to other programs.
More importantly, you will learn enough about these concepts so that you can put them to
use in your own custom script (covered in the next chapter), which is what truly separates
novice and expert Authorware developers. This chapter will cover more new information
and concepts than any previous chapter, so be prepared to read and re-read it. You won’t
be able to make full use of variables and functions until after Chapter 10, and many of the
examples in this chapter have been stripped down to bare essentials for ease of
comprehension. Consequently, you will not be able to fully implement all the code
examples that appear in this chapter. You can, however, practice creating and setting
variables, and using functions on variables.
325
Objectives
•
Distinguish between a variable and a function
•
Define the different types of variables, including string variables, numeric
variables, Logical variables, and lists
•
Use built-in variables and functions to get, store, and modify information relevant
to your program and the learner’s progress through it
•
Create custom variables and write basic programming script to extend the
functionality of your program
•
Use functions to control navigation and to modify variables
Introduction
You were introduced to variables in chapter 8, when you used FirstTryCorrect,
TotalCorrect, FirstTryWrong, and TotalWrong to provide performance feedback to your
learner. The variables you used then were built-in, that is, they are a part of Authorware.
There are currently 250 variables built in to Authorware. While that may seem like a lot,
there are times when it is necessary to create your own variables to make Authorware do
what you want it to do.
But variables are just one piece of the puzzle. To take full advantage of variables, you
have to know about the different kinds of variables, functions, and the logic of scripting.
The following sections will introduce you to these concepts. While you can learn a lot
326
about the concepts and processes involved from simply reading about them, the only way
you will become proficient is through practice, and over time, as you attempt to build
different functionality into your programs and solve the problems that inevitably come up
during that process. Joe Ganci has written what is widely considered the definitive text on
scripting in Authorware, Authorware Scripting for v6, Vol. 1 and 2, and it is available in
electronic form at www.dazzletech.com.
Variables
Defined
Variables are containers that hold information. In life, we use different kinds of
containers to hold different kinds of things: we use paper or plastic bags to hold fresh
groceries, and Tupperware to hold leftover meals. The same is true for variables; we use
different types of variables to hold different types of information. And just as you
wouldn’t put leftover soup in a paper bag, it makes a difference which type of
information you put in each different type of variable.
This is because Authorware expects the information it finds in a variable to match the
kind of variable it is stored in. As an analogy, consider a hardware store. While it would
be possible to store every different kind of nail, screw, bolt, nut, etc., in one large bin, it
would be impossible (or nearly so) to find what you need. So the hardware store creates
bins that store each different type separately. When you go to buy the parts you need, you
expect to find these things sorted appropriately. And when you pull out a 9/16 inch nut,
you don’t expect to find a different size nut. If you did, you probably wouldn’t even
realize it until you tried to use it later.
327
There are four different kinds of variables: string, numeric, Logical, and lists. The word
“string” has a very specific meaning derived from programming languages. A string is
any kind of text. Any character, word, phrase, sentence, or paragraph in this book could
be considered a string, and thus could be stored in a string variable. This includes
characters that are numbers, as well, but numbers stored in strings are treated as text, not
numbers.
Numeric variables, as you might expect, store numbers. Numeric variables can be used in
mathematical processes. For instance, the variable TotalCorrect is a numeric variable that
is equal to the number of correct responses the learner matched in my program. For every
correct answer they get, TotalCorrect goes up by one. Likewise, TotalWrong is a numeric
variable that is equal to the number of incorrect responses that the learner matched as
they went through my program. If I wanted to know how many different responses the
learner made (correct or incorrect) in my program, I could get the value of TotalCorrect,
get the value of TotalWrong, and add those two numbers together. But a more efficient
way to do that is to add the two variables together (TotalCorrect+TotalWrong) without
actually knowing what the values are. This is only possible with numeric variables; string
variables that contain numbers as text won’t work in this kind of expression.
The third type of variable is a Logical variable. Logical variables are words that signify
values or states. The most common and familiar type of Logical variable in Authorware
is the TRUE/FALSE Logical variable. A variable can be equal to “TRUE” or “FALSE,”
and based on that, Authorware can do different things. For instance, there is a variable in
Authorware called CapsLock. When the caps lock key on the learner’s keyboard is on,
then the variable CapsLock will be TRUE; when it is not on, the value will be FALSE. In
328
this way, you can use a logical variable to decide what the program should do (e.g., if I
find that CapsLock is true, tell the user to turn off the caps lock key). You will learn more
about this later in the section on scripting.
Heads Up: logical variables LOOK like numeric variables after they have been created,
but don’t confuse the two! A Logical variable with a value of FALSE appears in the
variables window as the number 0, while a value of TRUE appears as a 1. These are NOT
actually numbers, however, as they cannot be added, subtracted, or otherwise
manipulated mathematically.
The fourth type of variable is a list, and is actually comprised of two different kinds of
lists: linear and property. As you might expect from their name, list variables are lists of
information. And just as with lists in real life, they are useful for organizing lots of
information in one place; it is easier to keep track of things that are related to each other
if they are stored together in one place. Lists can store numbers or strings (or variables
that contain numbers or strings).
The main difference between a linear list and a property list is that linear lists are
sequential items, while property lists need not be in any order. A linear list can contain
strings, numbers, and variables that contain strings or numbers. Lists are the only variable
that can contain other variables, including other lists (which in turn could contain other
lists—thinking too much about that can make you dizzy). An analogy for a linear list
might be a recipe or driving directions. Order is critical to the use of either of these, as
each step must be completed before moving on to the next. If you imagine that these lists
are written on separate index cards, you will understand another aspect of linear lists;
329
every time you add something to a linear list, it is added to the end of the list unless you
specify the place (index number) in the list it should go. If you want to add a step, you
can create a new “card” and insert it in the “stack” (e.g., in the fifth position), but doing
so causes every “card; after it to shift down one position. This can create problems.
Let’s say that you have a list of driving directions on a stack of cards (not that this is very
likely, I know, but bear with me), and you know that the fifth step is to turn left on Brown
Avenue. Since you last drove the route, however, part of Brown Avenue has been closed
for construction, and you must now make two additional turns to go around the
construction to get to what was the sixth step. By adding two additional turns, you have
created a new sixth, and seventh step, so that what was the sixth step is now the eighth
step. Relying solely on order (called index position) in a linear list can make it almost
impossible to retrieve items in the list unless you never sort (arrange) the list or add
things to it.
Property lists, in contrast, are lists of properties, each of which has a its own value. In this
sense, properties are like, but not identical, to variables. Properties refer to specific things
about the file or the current icon. An example of properties are the File Properties that
you set through ModifyFileProperties back in Chapter 4. Each item (e.g.,
background color, screen size, and options on the playback tab) is a property of the file
that can be set. When you make changes to these properties, it changes the way
Authorware displays your piece. These properties are built in to Authorware already, and
exist in their own property lists. You can also create your own properties.
330
Power Tip: Because many of the ways you control Authorware are actually through
properties and property lists, and because you can set variables (like property lists) to
different values, you can actually control a lot about your piece during the authoring
process by writing code. This code can then automatically make tedious or repetitive
changes to the program for you. An example of this is making sure that your piece
conforms to the standard template your organization uses (screen size, depth, file path
names, etc.). You will see how to do this in Chapter 12, when you learn about BOTS,
Commands, and KOs.
Property lists can be ordered if you want, but you don’t need to know the order of each
item in the list in order to retrieve it: only the name of the item. Additionally, you can
change the value of each item in the list without adding to the list. One way to think of a
property list is to think of it as a shopping list. On a shopping list, you might list items
like the following:
•
Milk
•
Eggs
•
Butter
•
Pasta
This is a way for you to organize all the things you need to buy in one convenient place.
Order does not matter in this list—as long as you buy everything on it, you may do so in
any order you want. You don’t have to know that eggs are the third item on your list in
order to buy them.
331
Each of these items is a property, which can have a wide range of values. When you go to
the store, you don’t actually expect to find one product called milk, eggs, butter, or pasta.
Instead, there are many different brands (values) of each item. You may use convenience,
coupons, preference, or price to decide what brands you will buy. Each of these items is a
variable in its own right: when you get to the store you may decide that milk=Dairy
Farms Whole milk, eggs=Old McDonalds AA Large Brown eggs, etc. Your list is like a
variable for your shopping needs, and each item is a variable for the type of item you
want.
An example of a common list you might use in an Authorware program may help to
further distinguish between the two types of lists. Lets say that you want to store personal
information about your learner: their first name, last name, age, gender, and occupation.
You intend to retrieve that information at different times during the program. You could
use either a linear list or a property list to do this. I could create a list called
PersonalInfoList (remember that lists are variables, so they must be named). I decide
ahead of time that my list will store information in the following order:
Position (index) in list
Item stored at that index
1
First Name
2
Last Name
3
Age
4
Gender
332
5
Occupation
I can retrieve that information any time I want by using a function called ValueAtIndex,
which will give tell me whatever is stored at the index position I specify (don’t worry
now about how to do this—it will be covered later in the chapter). So if I tell the program
to retrieve the value at index position 2 (Temp:=ValueAtIndex(PersonalInfoList, 2),
which I happen to know is the learner’s last name, I can get the learners last name at any
time and use it (to store performance data in a text file named for their last name, for
instance). I can add as much information to the end of my list as I want; as long as I keep
my index number positions straight (which requires planning and documentation), I can
set and retrieve information as often as I like.
A linear list like this would work fine for me as long as I never want to add information
to someplace besides the end of my list. For example, lets say that I have been working
with my list for a while, and I have written several pieces of code throughout my program
that refer to items in my list by index number. I then realize that it would be good to store
the learner’s middle initial as well, since some people have the same first and last name
(e.g., John Smith). So I add a middle initial value at index position 2 (so that it falls
between the first and last name):
Position (index) in list
Item stored at that index
333
1
First Name
2
Middle Initial
3
Last Name
4
Age
5
Gender
6
Occupation
Notice that now Last Name, Age, Gender, and Occupation have all moved up one index
position number higher. While I can keep track of this myself from this point on,
anything that I have written up to this point that makes reference to an index position will
no longer work correctly. For example, the code example above to retrieve the learner’s
last name will now return the user’s middle name (because that is what is now at index
position 2)!
Tip: There is a function you can use called SetAtIndex that will actually replace the value
at an index instead of adding a new value (and corresponding index position). You could
use this function in cases where a value, such as the learner’s last name, needs to be
changed—that way you avoid creating a new index position. This is true for linear lists
and property lists, alike.
334
The best way to avoid this problem is to use a property list, instead. Property lists do not
rely on index position, so you can store (and retrieve) information in any order you want.
Property lists are comprised of a property and a value. The property is a label you use to
refer to that property, much like a variable name. The value is the value of the property.
Together, each property is called an element.
In our example above, we could create a property list (instead of a linear list) called
PersonalInfoPropList (you can name it anything, but it is good practice to include as
much identifying information as possible) which is comprised of several elements, each
with its own property and value, as follows:
Proptery
Value of that Property
FirstName
The first name of the learner
(e.g., “John”)
LastName
The last name of the learner
(e.g., “Smith”)
Age
The age of the learner (e.g.,
“28”)
Gender
The gender of the learner (e.g.,
“Male”)
Occupation
The occupation of the learner
(e.g., “Carpenter”)
335
(e.g., “Carpenter”)
I can retrieve the values of any of these properties by using a function called
PropertyAtIndex (don’t be fooled by the term index here—it is the result of poor naming
and not an indication of order. It should more properly be named PropertyAtElement). As
long as I know the name of the property (e.g., LastName) I want to retrieve, it does not
matter where that property actually resides in my property list. So if I decide, as in the
example above, to add an element for the learner’s middle name, I can do so at any time;
all I need to do is keep track of the names of my properties.
Property lists are also quite useful when it comes to sorting lists. While it is possible to
sort both linear and property lists (by alphabet in ascending order, for instance), doing so
changes the order of the list, which again creates problems for linear lists, but not
property lists.
Power Tip: You can actually include a property list as an element in another property
list. For example, if you anticipate 25 learners in your program, you would have to create
and refer to 25 linear lists. On the other hand, if you created property lists for each
learner, you could then store each list in a master learner list. A more common example
for this technique would be to create a property list for each individual learner to store
information like personal information, performance on different sections of the
instruction, etc. Each of these lists might hold several different pieces of information, and
could be stored in a master property list for each learner, so that all their records would be
stored in one list. This would make it easy to store records for multiple learners.
336
Functions: Overview
At first glance, functions look like variables; they are named in a similar fashion, and the
built-in ones can be accessed through a method similar to variables
(WindowFunctions). And just as with the similar Variables window, you are presented
with a list of all the functions available to you (more than 300 at last count); clicking on
the name of a function gives you a description of the function itself, and you can hit the
“Paste” button to copy the code you need for that function into your calculation window
(you have to have an open a calculation window prior to accessing the functions menu).
But functions are fundamentally different from variables. Functions do not contain
information (as variables do), they perform functions. In some cases, they perform
functions on variables. In this sense, if variables are containers of information, then
functions are tools that you can use to manipulate the information in those containers. In
other cases, functions work on different aspects of your program or the learners
computing platform, allowing you to print screens, set screen resolution, navigate within
or between Authorware files, etc. There are far too many functions in Authorware to
cover in this chapter, but discussing a few of the more commonly used functions may
help you understand the principle and use of functions. We will start with some of
functions that are related to variables, since you just read about them, and then move on
to other types of functions.
Functions & Variables
The next few sections will describe some common functions that can be used to work
with variables. It is important to keep in mind that there are hundreds of such functions,
337
and that mastering the art of working with them is largely determined by
experimentation. The following sections are designed to provide some contextual
examples for how the general process works; once you understand the basic syntax and
process, you will be able to (with practice!) extend and apply these principles to other
functions.
In order to facilitate this process, I have stripped these examples down as far as possible.
While everything in them is accurate, there are other steps and processes which must be
performed in order to actually implement these examples in an Authorware file, such as
definining the variable, setting it’s initial value, and incorporating appropriate syntax and
scripting in a calculation icon. These elements will be discussed in the scripting sections
that follow. As you read the next few sections, then, focus on the concepts rather than the
mechanics of the examples, and do not attempt to actually work with these in your own
Authorware file prior to completing this chapter.
WriteExtFile, ReadExtFile, & AppendExtFile
If we go back to the earlier example of nuts, bolts, and washers in hardware store bins as
variables, I could retrieve 10 nuts and bolts from a bin and use those to build a set of
shelves, repair the hinges on a fence gate, or weigh down the bottom of a set of patio door
drapes. Functions allow me to do different things with the information stored in variables.
Among the more common examples of functions that work with other variables are the
WriteExtFile, AppendExtFile, and ReadExtFile functions. As you might guess from their
names, these functions allow you to write data to and read data from an external file.
Authorware is able to write and read plain text files (as long as the .txt extension is
338
appended to the end of the file name). This is a simple way to store information from the
program locally on the hard drive. For example, I conduct a lot of research with
computer-based instruction, and I have a lot of data that I need to collect for statistical
analysis (see the case study for a complete description), and because statistical programs
can read in text files, I use these functions to create plain text user records. If you paste in
the WriteExtFile function from the function window, the default syntax looks like this:
WriteExtFile("filename", "string"). The first part is the function itself; the parts that come
inside the parentheses are called arguments or parameters, and are usually separated by a
comma. In this example, “filename” refers to the name of the file you want to create, and
“string” refers to the data that you want to write to the file. Putting text inside quotation
marks tells Authorware to treat it as a string (as with string variables).
Where this gets interesting, is that you can specify the name of the file and the actual data
yourself, or you can use variables. In the first example, I could write the following:
WriteExtFile(“Student Data File.txt”, “Hello World”). This would create a text file
named Student Data File.txt, and inside that file would appear the words Hello World.
This is fine if I always want to create the same named file with the same text inside it, but
that is rarely the case. More often, I want the name of the file to be different for different
learners, and I want to write different information to the file. In both cases, I can use
variables with this function to do so.
If I have a variable in which I store the learner’s last name, uLastName, and I want to
store the learner’s overall performance, I could write the following:
WriteExtFile(uLastName^“.txt”, TotalCorrect). This will use the contents of the variable
uLastName as the name of the file, add the .txt extension (the ^ character connects, or
339
concatenates, two things—don’t worry about the operators right now, they will be
covered in Chapter 10), and write the value (contents) of the variable TotalCorrect. In my
case, the file name would look like this: Van Eck.txt.
What’s more, I can write as many variables as I want to that file by using the
concatenation character, ^ ,[e.g., WriteExtFile(uLastName^“.txt”,
TotalCorrect^TotalWrong^PercentCorrect^…….)], and I can mix and match strings and
variables [e.g., WriteExtFile(uLastName^“.txt”, “Total Correct=”^TotalCorrect). If the
learner’s last name was Johnson and she had gotten 5 correct, this last example would
create a text file named Johnson.txt, and the contents would look like this: Total
Correct=5, with the words Total Correct= coming from the text string I wrote and the 5
coming from the value of the variable TotalCorrect.
The functions AppendExtFile and ReadExtFile function similarly. The only difference
between WriteExtFile and AppendExtFile is that WriteExtFile will always create a new
file; if one by that name already exists, it will write over the contents of that file.
AppendExtFile will always add to the end of the existing file. If the file does not exist,
then it will create it.
To understand and use the ReadExtFile function, you have to know a little about setting
the value of a variable, which is covered in more depth in the next section. For now, just
remember that in order to read in an external file, you must perform two steps: read the
file (by using ReadExtFile), and store the contents of that file in another variable. To
accomplish this, I might write the following: LearnerRecords:=ReadExtFile(uLastName).
This will take everything that I wrote to the file and store it in LearnerRecords. In the
340
earlier example, this would result in a string variable called LearnerRecords which would
contain the number 5.
Power Tip: There is a variable called IOStatus that will help you test whether your Read,
Write, and AppendExtFile functions were successful or not. IOStatus will be equal to 0 if
the function was successful, so you can verify your script by looking at the value of
IOStatus immediately after reading, writing, or appending from/to an external file. To do
so, you could use IOStatus in conjunction with a function called Trace, which sends some
text to the trace window (you can open the trace window by selecting the Control Panel
button
on the tool bar and then selecting the Show Trace Window button, which is
identical to the Control Panel button). You will learn more about the trace function and
window in Chapter 14. An example of this might look like the following:
WriteExtFile(“My Text File”, SessionTime)
If IOStatus<>0 then Trace(“The Write External File Function on line 001 failed”)
You will learn about the syntax for this code in Chapter 10.
GetNumber, GetLine, & GetWord
Note that by writing the variables to an external file and reading the data back in, as in
the previous example, I now have the value of TotalCorrect as a number, but I have NOT
retrieved the actual TotalCorrect variable. This is because I did not actually write the
variable TotalCorrect to the external text file; I wrote the value of the variable
TotalCorrect. Consequently, when I read that back in, I read the value, not the variable
itself. I can use that value to set the value of TotalCorrect, however. While there are
341
other, easier ways to store and pass variables between Authorware files, for the purposes
of illustration, we will look at how to retrieve the actual value of the variable from the
example above.
At this point, our earlier discussion about string vs. numeric variables becomes critical.
Authorware expects a numeric variable (one whose default value is some number) to
contain a number, and a string variable to contain text. The value that I wrote to the
external file in the previous example was 5; the current value of TotalCorrect. Although
TotalCorrect is a numeric variable, once I have written it to a text file, it becomes text.
Authorware no longer has any way of knowing whether what it sees in that file is text or
numbers unless I tell it.
There is another series of functions, GetLine, GetWord, and GetNumber, that are often
used in conjunction with the ReadExtFile (and others) to accomplish this. As you might
expect, these functions get a line, a word, or a number from the text stored in a variable.
GetLine and GetWord will retrieve the line or word you specify from a variable that
contains text. A line is defined by default as a Return character (each time Authorware
encounters a hard return, it assumes a line has ended and a new line will begin), while a
word is defined by spaces (every time a space is encountered, Authorware assumes one
word has ended and another has begun. A number is defined by a space or a non-numeric
character. In our example, I could use GetWord to retrieve the value 5 as text, or
GetNumber to retrieve the value as a number. The one that I use determines what I can do
with that value later; if I intend to store it in TotalCorrect, which is a numeric variable,
then I must use GetNumber.
342
Tip: This can make it problematic to retrieve a number from within a string that contains
both numbers and words. For this reason, it is a good idea to either store numbers and
strings in separate files (and, when retreived, in separate variables) or at least on separate
lines within a single file. That way, you can tell Authorware when to retrieve the value as
a number or a word.
Like the ReadExtFile function, there are two steps to using these functions: retrieving the
information you are looking for and storing that information. The syntax for each looks
like this: Get_____(n , “string”), where n is equal to the number of the line, word, or
number that you want to retrieve, and “string” is equal to the variable you want to get that
line, word, or number from. In the earlier example, we wrote the value of the variable
TotalCorrect to a file named for the last name of the learner, in my case, Van Eck.txt. We
did this supposedly because we wanted to store information about the performance of the
learner during some instruction. Now, the learner has presumably returned to the program
and I want to retrieve this data so that I can continue to track their performance, picking
up where they last left off. In order to retrieve that value and place it back inside of
TotalCorrect, I have to first read in the contents of that external file (using ReadExtFile),
and then read the number that is in that file (using GetNumber) and put it into
TotalCorrect. In both cases, this involves taking the result of each function and storing it
in a variable, like this:
TempVar:=ReadExtFile(uLastName^".txt")
TotalCorrect:=GetNumber(1,TempVar)
343
The first line creates a temporary variable, TempVar (it could be named anything) and
makes it equal (:=) to the contents of a file named for the learner’s last name
(ReadExtFile…..).
Heads Up: Note that in order for this to work, the learner would have to have typed in
their last name again, so that Authorware knows the value of uLastName. This would be
commonly done by asking the learner to type in their last name (or student number, or
whatever you use to track each learner) at the start of the program each time.
The second line then takes (GetNumber) the first number (1) it finds inside the variable
called TempVar (which is now equal to the contents of the external file we just read), and
stores it (:=) in the variable TotalCorrect. Note that in this instance, we told it to find the
first number because that is the first (actually, in this case, only) number we wrote to the
file. Because we used GetNumber, Authorware interprets the string character 5 as a
number instead of a word. If we had more than one number, we would have to specify
which one we wanted. The process is the same for GetLine and GetWord.
AddLinear, AddProperty, DeleteAtIndex, DeleteAtProperty, & SetAtIndex
This group of functions are specific to list variables, and are in fact the only way that you
can add, delete, or replace elements in a list. AddLinear and AddProperty add elements to
a linear or property list, respectively. They will fail if used with the wrong list (e.g.,
AddLinear is used with a property list). Likewise, DeleteAtIndex and DeleteAtProperty
are used to delete elements in a linear or property list, respectively, and will likewise fail
if used with the wrong type of list. SetAtIndex is a bit of an oddball, as it actually
344
replaces (sets) the value in a list rather than adding it, and works with both linear and
property lists.
AddLinear and AddProperty will add an element to the end of a list. In the earlier
example, we had a list for information about the learner. This list included the learner’s
first name, last name, age, gender, and occupation. I could add elements to a linear list as
follows:
AddLinear(PersonalInfoList, uFirstName)
The AddLinear function has two mandatory parameters: the name of the list (variable)
followed by a comma, and the value to add to the list. In this example, I have a list
variable (which I have defined and initialized elsewhere) called PersonalInfoList to
which I want to add the value of the variable uFirstName (which I have defined and set
elsewhere). The value of uFirstName (e.g., Richard), will be added to the end of my list. I
could accomplish the same thing with the following:
AddLinear(PersonalInfoList, “Richard”)
Heads Up: It is important to note that neither example adds a variable to this list. In the
first case, we add the value of a variable; in the second, we specify what should be
written. While in this case we added a string, it could be a number as well.
Richard is in quotations because it is a text string, not a variable; uFirstName is a text
variable. I could build my entire list in this fashion:
AddLinear(PersonalInfoList, uFirstName)
345
AddLinear(PersonalInfoList, uLastName)
AddLinear(PersonalInfoList, uAge)
AddLinear(PersonalInfoList, uGender)
AddLinear(PersonalInfoList, uOccupation)
Note that because each element is added to the end of this list by default, I must write
them in the order I want them to appear in the list. If I want to specify where in the list
something should be written, I can add a third parameter to give what I write a position in
the list:
AddLinear(UserList, FirstName, 5)
In this case, the 5 refers to the place in the list I want the value to be written.
Heads Up: Using AddLinear and specifying the index position will cause Authorware to
create indices to make it come out right if there are not enough indices already. For
instance, if I had not added anything to my list yet and used the syntax above to add the
users first name into the 5th index position, Authorware would create 4 indexes with
nothing in them so that it could add the first name in the 5th index. For this reason, you
are better off setting all the index positions in your list to a default value and using
SetAtIndex to replace the values at that index. You will learn about this function later in
this chapter.
AddProperty works in a similar fashion, except that there are three parameters:
346
AddProperty(PersonalInfoPropList, #FirstName, uFirstName)
The first parameter is the name of the property list, as it was with AddLinear. The second
parameter is the name of the property you want to set. Note that properties are always
preceded by a pound (#) sign; this tells Authorware that what follows is a property, not a
variable or value. The third element is the value that you want to store in the property (the
second parameter). In this case, I have used a variable called uFirstName, which I have
defined and set elsewhere. Just as with AddLinear, I could specify the value myself
instead of using a variable:
AddProperty(PersonalInfoPropList, #FirstName, “Richard”)
Remember that you must be careful to keep your lists straight, as both AddLinear and
AddProperty add rather than replace values, including duplicates! Writing the following
would give you two properties named FirstName with exactly the same value in your
property list:
Deleting items from lists is a similar process. DeleteAtIndex allows you to delete items
from a linear list, while DeleteAtProperty allows you to delete a property. Both use the
same syntax, in which you specify the function, specify the list, and specify the index or
property you wish to delete:
DeleteAtIndex(PersonalInfoList, 1)
347
or
DeleteAtProperty(PersonalInfoPropList, #FirstName)
In the former case, I delete the value in the first index position in my linear list called
PersonalInfolist. In our examples prior, this would delete the learner’s first name. In the
latter case, I delete the property FirstName from the property list called
PersonalInfoPropList. Again, in our earlier examples, this property contains the value of
the variable uFirstName, which is of course the learner’s first name. You can begin to see
the advantage of a property list here; I don’t need to know whether I stored the learner’s
first name in the first index position—I need only remember that I have a property called
FirstName.
SetAtIndex will allow you replace the value at the index position that you specify. You
can use this when you are updating your list (i.e., changing existing values). The
advantage to doing it this way occurs when the data you want to write to your list could
be created in any order (as in non-linear, learner-controlled instruction), yet you want
your list ordered. Keep in mind that if you specify an index, then anything else you add to
this list will be added after it unless you give them indexes as well. Also, remember that
AddLinear always ADDS information to your list; it does not REPLACE information.
You could, of course, use DeleteAtIndex and AddLinear (linear lists) or
DeleteAtProperty and AddProperty (property lists) to accomplish this as well. It is
important to note, however, that you must know the index number to make use of this
function. While this is obvious in a linear list, remember that you don’t need to keep track
of index positions in a property list in order to add and delete things. To make use of
348
SetAtIndex, you must know the actual index position of the property you want to modify.
In this regard, DeleteAtProperty and AddProperty might be simpler to use, unless you
keep track of index position in your property lists. The syntax for using SetAtIndex with
our example lists is as follows:
SetAtIndex(PersonalInfoList, uFirstName, 1)
or
SetAtIndex(PersonalInfoPropList, uFirstName, 1)
Note again that the variable uFirstName could be replaced by a text string value as well
(e.g., “Richard”).
Heads Up: You must always initialize a linear or property list in the Authorware file
itself, rather than relying on the initial value feature when defining variables. This
process is covered in the Scripting with Variables section in Chapter 10.
Functions & Navigation
The GoTo Function
There is a category of functions called Jump, which contains functions used for
navigating within and between Authorware programs. Normally, navigation within an
Authorware program is controlled by the learner or program according to the flowline
and navigation icons. Occasionally, however, you may want to specify where the learner
goes next from within a script that you write. For example, there may be occaisions
where you want the learner to view some information only the first time through a
349
section, and that upon returning to that section, they should skip that information. You
could set a variable that is TRUE if they have seen that section already, and when that is
the case, the program should skip that section. While you could use a framework and
navigation icons to accomplish this, sometimes that is overkill. You could instead use the
GoTo function.
The GoTo function specifies the name of an icon to which you want Authorware to go. It
can be especially useful when where you want to go is NOT on a framework (in which
case you cannot use a navigation icon). The syntax for this function is as follows:
GoTo(IconID@“S1.1”)
The first part is the function itself, and just as with all functions, it is followed by a
parenthetical expression, in this case, IconID@“S1.1”. Every icon in your program has a
unique ID number. This number is assigned automatically by the program, and cannot be
predicted (at least not by mere mortals), beyond the fact that 65543 appears to be the ID
number of the first icon added to a new file. Authorware actually uses this ID number to
keep track of where things are in your program; when you tell it to exit an interaction and
go to the next icon (using the flow controls from a response on an interaction), it actually
accomplishes this by knowing which ID number it should go to next. If you knew the ID
number of the icon you wanted to go to offhand, you could use it to tell Authorware
where to go (no jokes, please). But numbers are for computers, and words are for
humans, so Macromedia has provided a way for humans and computers to communicate
each in our own preferred language. IconID@“S1.1” simply tells Authorware to get the
350
ID number of icon that WE have named S1.1. Here again is another example of why it is
critical to name every icon you have carefully, so that you can refer to them easily.
There are a few caveats to using the GoTo function. First of all, if you use it, the icon title
that you specify MUST be unique. It is possible to name more than one icon the same
thing; Authorware does not care. But if you use the GoTo function and specify an icon
title that exists for more than one icon, Authorware has no idea which one you mean, and
it will force you to specify a unique icon title. Secondly, if you ever cut or delete the icon
to which you want Authorware to go, your code will look like this:
GoTo(IconID@DeletedIcon)
As you might expect, this will no longer produce the desired result, even if you create a
new icon and name it the same thing as the one you cut or deleted.
JumpFile, JumpFileReturn, JumpOut, JumpOutReturn
There are also occasions upon which you want to leave the Authorware file and go to
another Authorware file or program. Many developers of training are beginning to focus
on developing learning objects. The emphasis here is on breaking the instructional unit
down to the level where each addresses a particular learning objective or goal, and
creating instruction that addresses just that objective or goal rather than implementing all
goals and objectives within a single program. These learning objects are stored separately
and can be re-purposed and used again in later instruction by other designers. Because
they are independent (relatively speaking) of each other, they can be recombined in
different ways for different purposes. These objects can be strung together using the
351
JumpFile function; to the learner, these separate files appear to be one single program.
Another example is when you want to call up another program, such as a web browser or
a word processor. Authorware can launch other programs using the JumpOut function.
JumpFile and JumpFileReturn can be used to navigate from the current file to another
Authorware file. Note that this only works with packaged files, so you cannot test it
during the authoring phase without packaging both files first. The difference between the
two functions is that JumpFile will cause the current Authorware program to quit before
jumping, while JumpFileReturn will jump to the file you specify, but leave the current
file running in the background so that quitting the file you jumped to will put you back in
the first file. An example of the syntax for this might look like this:
JumpFile(“Unit Two”)
where the name of the file you want to jump to is enclosed in quotes and parentheses. It is
not necessary to specify the extension of the file you want to jump to, as Authorware will
only, and automatically, search for packaged files.
Power Tip: You can also pass variables from one file to the next using the optional
arguments for these functions. If I want to pass my learner information from the current
file to the next, for instance, I could type the following:
JumpFile(“Unit Two”[, uFirstName, uLastName, uAge, uGender, uOccupation]).
Note the square brackets that enclose the variable names. The astute reader may
recognize that my lists would be quite handy here, as I could instead type JumpFile(“Unit
Two”[, PersonalInfoPropList]) and accomplish the same thing. NOTE: the variables that
352
you pass from one file to the next MUST exist in both files, which means you must
define them in both places. An easy way to do this is to select everything in the current
file (Ctrl-a), copy it, open the second file, and past everything into an empty map icon.
You can then delete that map icon, as all of your variable names and default values will
have been copied into the new file.
If you want to launch another (i.e., non-Authorware) program from within your program,
you can use the JumpOut and JumpOutReturn commands. The syntax for these is similar
to their cousins JumpFile and JumpFileReturn:
JumpOut(“WINWORD.EXE”[, “Final Results.doc”])
This would cause the current Authorware program to quit, launch Microsoft Word, and
open the document “Final Results.doc” It is important to note that you must specify the
exact name of the program and extension. Also, if the program and document do not exist
in the same folder as your Authorware program (as they do not in the example above),
you must also specify the path for each (unless you set the search path for your program
appropriately, which you will learn about in Chapter 13). Our example above would be
better rendered like this:
JumpOut(“C:\Program Files\Microsoft Office\Office\WINWORD.EXE”[, “Final
Results.doc”])
This assumes that I have stored the document file in the same folder as my program
(good practice to do so). JumpOutReturn uses the identical syntax, and again differs only
353
in that the current Authorware program will continue to run in the background while the
new program launches.
Scripting
The Calculation Window
Now that you understand what functions and variables can do, it is time to examine more
closely the rules by which they are created and used, and how you can begin to
incorporate them into your own custom code within Authorware. All code that you will
write will appear inside a calculation window. That window most often will belong to a
calculation icon. It is also possible to attach script to icons themselves by right clicking
on the icon and selecting Calculation from the pop-up window. When you do so, you are
presented with a window that is identical to the calculation icon window in which to
write your script. Icons that you have done this to have a small equal sign at the upper left
corner, commonly called an ornament. There are several features of the calculation
window which are relevant to all scripting, so we will begin with an introduction to those
features.
A calculation window is a blank window with 14 tools at the top of the window:
354
Script is added by typing in the blank, white space, much as you do with a word
processor. The image here has been modified to make as many of these tools active as
possible; when you first open the window, only two of them are active, since you have
not yet added any script to the window upon which the tools can act. Many of these tools
will be familiar to you from other programs. The first seven are, in order from left to
right, Undo, Redo, Cut, Copy, Paste, Clear (delete), and Print. Undo, Redo, and Print all
work by a simple click on the appropriate button. The others, just as with a word
processor, are implemented by selecting the appropriate text or placement of the cursor,
and then a single click on the appropriate button. The last seven tools are unique to the
cacluation window and scripting process, and are worthy of closer examination.
Commenting and Uncommenting. The buttons with two dashes under an arrow are
called Comment and Uncomment. A comment, in the world of scripting, is text that you
write either to yourself, to another programmer, or which for some other reason you do
not want Authorware to interpret as script. Authorware will attempt to interpret
everything you write in a calculation icon as variables, functions, or code, each of which
have their own rules and requirements. If it finds anything that does not conform to these
rules (e.g., a function that does not exist or a syntax error), it will highlight the error to
the best of its ability (woefully inadequate, at times), and refuse to allow you to close the
window until it has been corrected. Sometimes, you want to write notes to yourself to
remind you of the purpose or intent of some part of your script.
Heads Up: In fact, if you ever want to be accepted into the ranks of good Authorware
programmers, you MUST get into the habit of commenting your script. There are two
reasons for this. First, if anyone is ever to make use of your programming at a later date
355
(or if you are part of a development team), you may THINK that what you have written
will be obvious. It isn’t. And even if it were, it would take somebody extra time and
concentration to figure it out. As you may know by now, brain power and time are at a
premium when working with Authorware, so it is common courtesy to comment all but
the most straightforward code. Additionally, even when the code is straightforward, the
purpose of the code is not always obvious (how is the variable you have defined
supposed to be used? To do what? Under what conditions?).
Ah, you say: I am a lone wolf and nobody but me will ever look at my code. Comment it
anyway. You would be AMAZED at how even the most “obvious” script becomes
impossible to decipher even days later, let alone months or even years. Often, you will
find that in the course of authoring a new program you come across a problem or feature
which you have already solved (or partially solved) in an earlier program. I have gone
back to programs I wrote 10 years ago to get code that I have a new purpose for. It is
well-nigh impossible to decipher your own code without the benefit of commenting.
In other cases, (quite common, in fact), you will find that there is an error somewhere in
your script that you cannot find, and Authorware will not allow you close the window.
“Commenting out” parts of your code forces Authorware to ignore that section of your
script so that you can close the window while you do research about the script you are
writing. Finally, commenting can be useful when you want to test different parts of your
script. By commenting out all but the part you are testing, you can run the piece and
evaluate whether it is working. If it is, you can comment it out and move on to the next
piece.
356
The amount of space I have given to the rationale for commenting and uncommenting is
a reflection of its importance, and not the difficulty of the process itself. To comment out
a line in your calculation window, you need only place the cursor somewhere within the
desired line and click the Comment button (the arrow pointing to the right over two
dashes). This places two dashes at the beginning of the line and changes the color of the
text, signifying that the line has been commented out, as in the example below:
Uncommenting the text, then, is simply a matter of placing the cursor somewhere in the
line of commented text and clicking once on the Uncomment button (the left pointing
arrow over two dashes). You can comment out (or uncomment) a line manually by typing
the dashes (or deleting them) yourself, but this becomes somewhat tedious to do when
you want to comment/uncomment several lines of text. If you select any number of lines
(by highlighting, as you do in a word processor) and hit the Comment or Uncomment
button, it will apply the action to every line you have selected.
Block indent & Block unindent. The next two buttons may be familiar to you from
word processing or presentation slideshow programs. Their function is to indent the
selected text four spaces (by default). Indenting is a convenience for you when you are
writing multiple lines of code that are part of the same process. Two common examples
357
are loops and if-then statements. You will learn about these in a later section of this
chapter, but for now just remember that sometimes you need to write sepearate lines of
code to accomplish one thing. In these cases, it is common to indent the lines to indicate
that they are subset (a sub-routine) of what precedes and follows them. The example
below shows how this might look with a common if-then statement:
The indented lines make it easy to see where my if-then statement starts and ends. This is
even more helpful with my if-then statement is one of several processes and lines of
script. Indenting is so helpful that Authorware has built the process into statements like
loops and if-then statements. The example above was automatically indented for me as I
wrote it, without my having to make use of the Indent block and Unindent block buttons.
Find Left Bracket & Find Right Bracket. The next two buttons come into play when
you write parenthetical expressions in your script. These may be familiar to you from
math class, where they were used to indicate the order in which different functions should
be performed. For example, if I want to divide the product of 10 and 2 by the product of 5
and 2, I would write it like this: (10 X 3) / (5 X 2). The parentheses indicate that I must
multiply 10 by 3 first, then multiply 5 by 2, and then divide the first product by the
358
second product, giving me 3. Without the parentheses, I might multiply 10 by 3 (30),
divide by 5 (6), and multiply by 2, giving me a total of 12.
Likewise, there are mathematical expressions in scripting that you will want evaluated in
a particular order, and you will use parentheses to do so. Additionally, you may recall
from the section on functions, all functions use parentheses to contain their arguments.
Between these two uses of parentheses, it even become possible (and necessary, at times)
to “nest” parenthetical expressions. For example, I might want to get the cosine of (30 X
2) – (2+15). I can use the ACOS function in Authorware to get the cosine of any value by
typing TempVar:=ACOS(x), where TempVar is a temporary variable that I want to store
the cosine in, and x is the number I want the cosine of. By combining these, I get
TempVar:=ACOS((30*2) – (2+15)). As you might expect, it can become difficult to keep
track of which left parenthesis goes with which right parenthesis, especially when
working with multiple lines of code. The Find left and Find right bracket buttons help
you keep track of this. When the cursor is placed just before a left parenthesis, the Find
right bracket button is active and, when clicked, will move the cursor to just before the
right parenthesis that Authorware thinks completes the expression. The same is true for
the Find left bracket button when the cursor is placed just before a right parenthesis.
Tip: You can use these tools to help you find errors in long, complex script. If you are
missing a bracket in a long string that covers several lines and has several parenthetical
expressions, knowing that one is missing doesn’t help you find it. The Find left bracket
and Find right bracket help you match the pairs to find which one is missing.
359
Preferences button. The last button in the calculation window toolbar is the preferences
button. This button provides access to the options for the calculation window itself,
allowing you to change the way the calculation window appears and behaves. Most of
these features are self-explanatory, so in the interests of space and time, I will discuss
only a few of the more relevant and perhaps less obvious features.
Clicking on the preferences button brings up the following window:
As with other windows, each tab at the bottom brings up a different section of
preferences. On this first tab, one feature that may be of particular use to you is the Show
line numbers feature. By selecting this, Authorware will automatically provide line
numbers for each line of code in the calculation window. The advantage to this lies in
your ability to get help with your code from others. If you are having trouble with your
code, or if you are working with others on a development team who will need to modify
your code, line numbers provide a common language for discussing your code. If I am
looking at your code and find that there is an error or something that is missing, I can tell
360
you exactly where in your code that occurs. Also, line numbers help when you are testing
long scripts, in that you can keep track of which lines you have tested or debugged.
The Editor tab also has a few features worth mentioning. On this tab you can specify how
many spaces Authorware should indent text when you use the Indent block button on the
toolbar (remember the default was 4). There is also an option on this tab to have
Authorware automatically correct the case of variables and functions. You may have
notice that when I type the names of variables and functions, I capitalize the first letter of
each element (e.g., TotalCorrect, instead of Totalcorrect). While it is not necessary to do
so, it is good practice, as it makes it significantly easier to interpret the name of variables
and functions. If you check the option to auto correct the case of functions and variables,
Authorware will automatically capitalize each part of any of the built-in variables and
functions in Authorware (it will NOT change the case of any variables that you have
created yourself, however).
On this tab you can also specify how many spaces Authorware should automatically
indent (or whether it should automatically indent at all) compound statements such as the
if-then example discussed earlier. Finally, the fourth item on the editor tab is worth
mentioning not so much because you may change it but because it points out a very
handy shortcut. This feature is the keystroke combination by which you access the
calculation completion feature. Any time you are typing the name of a variable or
function in Authorware, you can bring up a scrolling list of the names of variables and
functions that most closely match what you are typing. You can then select from among
this list and Authorware will automatically complete (and/or correct) your entry for you.
This not only saves typing time and prevents spelling errors, it also allows you to find the
361
correct name even when you only remember the first few letters. The default keystroke is
ctrl-h (control H).
The Toolbar tab allows you to specify which toolbar buttons appear at the top of the
calculation window, and the Font tab allows you to specify the font and size you want the
text you type to appear in. By default the font is courier new and 8 point, which can be
hard on the eyes. The remaining tab, Color, is important once again more for the feature
it points out than for the ability to modify it. You may have noticed in the earlier
examples that some of the code script appeared in different colors. Authorware specifys a
different color for different elements in your calculation window. This makes it easier for
you to pick out and identify these different elements. It also serves as a built-in error
checker. Table 5 presents the colors that Authorware assigns to some of the more
common script elements.
Table 5. Colors assigned by default to common script elements.
Element
Color (or style)
Comment
Blue
Operator (=, +, etc.)
Red
String (text in quotes)
Purple
User (custom) functions & variables
Green
System (built-in) functions &
Bold (of whatever color specified on
variables
the Font tab)
362
variables
the Font tab)
Once you get used to the color scheme (or define your own), you can easily distinguish at
a glance variables and functions from text, and identify operators among long strings of
text. You can also tell if you have misspelled a function or variable, as it will (by default)
remain green rather than becoming bold.
The last thing you need to know about the calculation window is some of the special
words and characters that can be used. One is a special character that looks like a
sideways L (¬). This character is used to tell Authorware that what follows should be
treated as the same line as what precedes it. Authorware has a 1024 character per line
limit in a calculation window. You will find that you can not fit this many characters on
one line of your calculation window without having to use the scroll bar at the bottom of
the window. In practical terms, you are likely to hit the limit at 124. To keep all your
script visible within your calculation window without using the horizontal scroll bar, you
can type this character at any point you want wrap to the next line by holding down the
Alt key and hitting the return or enter key. You must use this character instead of just
hitting the return key, because when Authorware encounters a return, it stops looking. If
the function or script you are writing continues on the next line, Authorware will give
you an error message, because it expects the script to finish on the line with the hard
return.
On a related note, there are times when you are writing to an external file and you want
Authorware to insert a special character like a Tab or a Return. A good example is when
363
you are writing learner data to an external file that will contain more than one learner’s
data. You might use the ^ and ¬ characters to string hundreds of variables together into
one learner record. In order to signify where the end of that record and the start of a new
one occurs, you may want to insert a new line in the file. This is particularly useful when
you plan to use the GetLine function on this file later, as a line is defined by default as a
new line, or return character. Or, you may want to read in your data to a statistical,
spreadsheet, or database program. Such programs can interpret “delimited” files, that is,
files whose records are separated (delmited) by a character such as a comma or a tab. To
force Authorware to insert a new line or a tab in the text file as it is writing to it, you type
the word Return or Tab, respectively.
Creating Custom Variables
Now that you know what variables and functions are and how to work within the
calculation window, you can begin to create your own script. One of the things you will
inevitably need to do when writing your own script is to create custom variables. The
process for doing so is actually quite simple, but there are a few procedural issues you
must pay close attention to avoid problems later.
There are two ways to create a variable. The first is to open the variables window
(WindowVariables) and click the “New” button. This will bring up the New Variable
dialog box:
364
The second, and by far more common and efficient, means of creating a new variable is
to simply type the name of the variable you want to create inside any calculation icon
(e.g., while you are writing script). Any text that you type inside a calculation icon that is
not in quotations (indicating it is a string) and that is not a recognized function, variable,
or logical scripting command, will be interpreted by Authorware as a new variable.
Authorware will automatically open up the New Variable dialog box when you attempt to
close or save a calculation window that contains such text.
Regardless of which method you use, you will be presented with the same dialog box,
with which you must perform the same steps. The first box in this dialog window will be
blank (if you’ve created the variable through the variables window) or contain the text in
your calculation window that Authorware thinks is a new variable. When you are
creating/naming your variables, it is a good idea to use a descriptive name for the
information that they will contain, and to use the case-naming convention in Authorware.
For instance, the variables I used as an example in the section on lists were named things
like “uFirstName,” and “uAge.” For me, the “u” stands for User, and the name of the
365
variable reflects its purpose (i.e., to store the first name and the age). I could just as easily
have named them UserFirstName and UserAge; Authorware does not care what I name
them. I use “u” because it is shorter than typing “user.” Additionally, notice that I
capitalized the first letter of each word-descriptor in my variable name, just as
Authorware does with built in variables and functions. This makes it much easier to read
at a glance (compare ufirstname with uFirstName, for example, or userpersonalinfolist
withUserPersonalInfoList).
Tip: If you have made a spelling or syntactical error in your calculation window, you will
often get this dialog box. In such cases where you did NOT intend to create a new
variable, you can simply hit the Cancel button and make the necessary adjustments to
your code.
The second and third boxes are critical to ensuring that your variables work as you intend
them to and that you (or others) are able to interpret their purpose. The initial value box is
where you specify what your new variable should be equal to by default. This is
important for two reasons. First, every variable MUST be equal to something at ALL
times. It can be equal to nothing, as you will see momentarily, but in the world of
Authorware, “nothing” does not mean leaving this space blank, as evidenced by
Authorware’s prompting you to fill this space in if you attempt to do so.
The second, far more critical, reason that the default value is important is that
Authorware uses the default value to determine what kind of variable it is. You will
remember (or should now go back and re-read) that there are four different types of
366
variables: string, numeric, logical, and list. The value that you type into the Intial value
field will determine which of these types of variables you want your new variable to be.
Tip: You can change any variable from one type to the other by changing its initial value
through the variables dialog box (WindowVariables, then select the desired variable
from the list and change its the Initial Value field).
Table 6 presents each type of variable and its corresponding initial value(s).
Variable Type
Possible Initial Value(s)
String
“” or any text in quotes, including spaces
Numeric
Any number
Logical
TRUE or FALSE
Linear List
[]
PropertyList
[:]
In the case of a string variable, I can simply type open and close quote symbols to
indicate that this is a string variable that has ‘nothing’ in it. I can also type one or more
spaces inside open and close quote symbols, and it will appear to be the same.
Authorware, however, counts spaces as characters. In practical terms, this will probably
make no difference in the end result, but it is helpful to remember how Authorware thinks
in terms of variables.
367
One final note on string and numeric variables: while you can type any number you want
in a string variable or a numeric variable, if the number appears in quotations, it is treated
as text, NOT as a mathematical number. This is important, because you cannot perform
any mathematical operations (addition, subtraction, etc.) on numbers that are in a string
variable (although as mentioned earlier, you can use the GetNumber function to search a
string and store numbers it finds in numeric variables).
Case Study
Although it may not seem like it, what you have learned so far is not really complex
enough to warrant much of a case study. When combined with Chapter 10, you will have
learned enough to apply to a real world situation. For this reason, Chapter 10 will present
a case study to cover both chapters.
Summary
Authorware automates the process of creating interactive instruction by using an iconbased authoring metaphor. This metaphor allows you to create interactive instruction
quickly and easily. When authoring advanced instructional products, such as adaptive
instruction, complex interactions that assess multiple responses simultaneously, and
instruction that relies on tracking and using detailed information about learner
performance, it becomes necessary to use variables and functions to extend Authorware’s
built-in icon-based capabilities.
Variables are containers that hold information. Each of the four types of variables,
(string, numeric, logical, and lists), hold different types of information (characters,
368
numbers, TRUE or FALSE states, elements, and properties). The built-in variables, and
those that you create allow you to store and act on a variety of information about the
program and the learner.
Functions allow you to perform actions such as read an external text file, test the learner’s
OS or display resolution, or navigate to different sections of your program or to other
programs. Functions always have some result, which must often be stored in a variable.
Using the ReadExtFile function results in all of the text in an external file being read into
Authorware. That text must then be stored in a variable if it is to be used in any way.
Combining variables and functions allows you to get, track, and create information,
which you can then use to customize how the program should behave. For example, you
can store all of your learner’s data from a session (itself stored in many variables) in a
text file and then use that data at a later date to pick up where they left off. Understanding
how to create and use variables and to use functions, is the pre-cursor to using them in
your own custom scripts and becoming an expert Authorware programmer.
Exercises
1) ___________ are like containers that hold information, while _________ are like
tools that operate on that information.
369
2) Match the following types of information with their respective variable category:
a. 0, 1, 2, 3, etc. (only)
e. Logical Variable
b. TRUE or FALSE
f. List Variable
c.
g. Numeric Variable
Hello, world (or any text)
d. Several properties or items
h. String Variable
370
3) Write out the initial values of each of the variables listed in the above question
4) Match each of the operators below with its description:
<
Make the value at left equal to the value at right
-
the value at left
is equal to the value at right
&
the value at left
is not equal to the value at right
*
the value at left
is less than the value at right
/
the value at left
is greater than the value at right
:=
the value at left
is less than or equal to the value at right
^
the value at left
is greater than or equal to the value at right
|
Not the value at right
~
the value at left
and the value at right
+
the value at left
or the value at right
<=
Add the value at left to the value at right
<>
Subtract the value at left from the value at right
=
Multiply the value at left by the value at right
>
Divide the value at left by the value at right
>=
Join the value/string at left with the value/string at right
5) If I wanted to track how many questions the learner answered correctly in my
program, would I be more likely to use a variable or a function?
6) Describe the process for creating a custom variable
371
7) I have a variable called StudentTime that I want to make equal to 10. Write the
syntax for doing this below:
8) I have a variable called StudentName that I want to make equal to Richard. Write
the syntax for doing this below:
9) Describe the difference between a property list and a linear list:
10) I have a function named MyFunction, which has 2 arguments. The first argument
is the name of the variable the function should work on, and the second argument
is the number of times it should perform the function. Assume that I want to use
this function on a variable called MyVariable, and that I want to perform the
function 3 times. How would I write this syntax?
372
Chapter 10: Scripting
Overview
Scripting allows you to extend the functionality of Authorware beyond the mere tracking
of information and advanced interactivity that the use of variables and functions allows.
If Authorware can do 80% of anything you want right out of the box, scripting lets you
create instruction that makes use of the remaining 20%. As you might imagine, it is this
last 20% that is the most complex.
This chapter is divided up into sections on scripting with variables, functions,
expressions, if-then statements, and loops. The basic process for scripting with each is the
same, however, so as you read this chapter the first time, try to identify the principles that
are shared by each example rather than attempting to memorize syntax and terminology.
As you begin to see these similarities, you will have more cognitive resources to devote
learning the syntax for working with each individual element. You will need all the
mental energy you can spare to master the content in this chapter. Don’t try to do it all in
one sitting; read a section and explore what you have learned for a while, then return.
You are likely to need several re-reads and practice opportunities before you begin to be
comfortable so be prepared. If it were easy, everybody would be an expert Authorware
programmer!
Objectives
373
•
Use built-in variables and functions to get, store, and modify information relevant
to your program and the learner’s progress through it
•
Create custom variables and write basic programming script to extend the
functionality of your program
Introduction
Now that you understand what functions and variables can do, it is time to examine more
closely the rules by which they are created and used, and how you can begin to
incorporate them into your own custom code within Authorware. Scripting takes LOTS
of practice, and even when you are good at it, RARELY works right the first time. It is as
much an art as a science. What follows in this chapter is as much of the science as can be
distilled in such a small space. The art will come only from experience, late nights, and
lots of caffeine.
Scripting with Variables
The main thing you need to understand about scripting with variables is that you set their
values according to some set of conditions or rules. You can set the value of a variable to
a value you choose (e.g., 5 or “Richard”), to a value determined by a mathematical
expression (e.g., 5 + 10), or to a value determined by another variable or expression (e.g.,
MyVariableOne+MyVariableTwo). The syntax is always the same, however, with the
variable whose value you want to set appearing on the left, and the value (or variable
containing a value) you want your variable to be set to appearing on the right. As you will
374
see in the next two sections, the way this syntax appears may vary on occasion, but the
most common examples are presented below:
MyVariableOne:=(some value/variable/expression you type here, without parentheses)
MyVariableOne=(some value/variable/expression you type here, without parentheses)
The first is an example of how you would SET the value of your variable. With it, you
are essentially saying “Authorware, make my variable equal to the thing on the right.”
The second is an example of how you would DESCRIBE the value of your variable,
usually for the purpose of evaluating it in an if-then statement (covered in chapter 10).
With it, you are essentially saying “Authorware, my variable equals the thing on the
right.” The key to these two different examples lies in the operators used to se or evaluate
the variables.
Setting & evaluating variables
A variable would not be much good if we couldn’t change it’s value, as its name implies
changing values. The process of changing a variable requires that you understand the
difference between two operators: the assignment operator (:=) and a relational operator
called “Equal To” (=). The assignment operator, :=, tells Authorware to make the value
on the left of the operator equal to the value on the right of the operator. It is the
assignment operator that we use to set/change the value of a variable. The relational
operator “Equal To,” (=), is used to describe the relation between the value on the left of
the operator and the value on the right of the operator. The difference can be better
375
understood by converting them to a textual equivalent (here’s where those story problems
skills from math class will finally be put to use in the real world!):
uFirstName:=“Richard”
is equivalent to saying the variable named uFirstName SHOULD BE MADE to contain
the string “Richard,”
while
uFirstName=“Richard”
is equivalent to saying the variable named uFirstName DOES contain the string
“Richard.”
In point of fact, you would never write the second example by itself, as it doesn’t do
anything on its own. Authorware looks at the first example and says “Aha! I am supposed
to store the string “Richard” in this variable called uFirstName.” It looks at the second
example and says “This guy thinks the string “Richard” is stored in the variable called
uFirstName. So what? Nothing for me to do here.”
One way that I used to remember the difference was to convert “=” into “equal to,” and
“:=” into “make equal to.”
Operators, If-then statements, and loops
Before we can go much further with scripting, there a few scripting objects, concepts, and
rules you must be aware of, You have already learned about two operators, the
assignment operator and one of the relational operators. There are actually 5 categories
376
and 15 types of operators. Operators are the “glue” that hold your script together; they tell
Authorware how your variables and functions relate to each other and/or how to interpret
them. These operators are used in conjunction with common programming structures,
variables, and functions, to create custom script. This next section will look at these
operators and two of the more common programming structures: the if-then statement
and the loop.
Operators.
Category
Character Description
Assignment
:=
Relational
=
the value at left
is equal to the value at right
<>
the value at left
is not equal to the value at right
<
the value at left
is less than the value at right
>
the value at left
is greater than the value at right
<=
the value at left
is less than or equal to the value at right
>=
the value at left
is greater than or equal to the value at right
Logical
Make the value at left equal to the value at right
~
Not the value at right
&
the value at left
and the value at right
377
|
Mathematical
Concatenation
the value at left
or the value at right
+
Add the value at left to the value at right
-
Subtract the value at left from the value at right
*
Multiply the value at left by the value at right
/
Divide the value at left by the value at right
^
Join the value/string at left with the value/string at right
Many of these are intuitive and familiar to you from other domains such as math and
composition, but a few bear additional comment and examples.
The relational operators should be familiar from high school math, despite the fact that
they are not in the “mathematical” category. The number 10 is greater than 3, and can be
expressed as 10>3 (for the mathematically challenged, as I am, an easy way to remember
these are that the “arrow” always points at the smaller number). Likewise, 5 is less than
7, and can be expressed as 5<7. Because of the vagaries of the QWERTY keyboard, we
do not have an easy way to type the more common symbols for “less than or equal to,”
(≤), “greater than or equal to,” (≥), or “does not equal,” (≠). To get around this, we type
the symbol for greater than (>) or less then (<) followed by the equal sign to represent
greater than or equal and less then or equal, respectively. The symbol for “does not
equal” is a bit more tricky, because we can’t use the “/” symbol followed by the “=,” as
that would mean “divided by or equal,” which is not at all the same thing. Authorware
378
has instead reserved the key sequence “<>” to mean “is not equal to.” In fact, once you
type this once, Authorware converts it to ≠ and you will see that symbol the next time
you view your script. To make matters a bit more confusing, Authorware also reserves
the symbol “~,” referred to as tilde (tild-ah), to mean “not.” You may remember from
math class that this symbol is more commonly used to signify “approximately.” In
Authorware, however, when placed before a value (or a variable containing a value), this
symbol negates that value (e.g., ~7 means “not seven). What makes this potentially more
confusing, is that <> and ~ can mean the exact same thing! If I type the expressions
uFirstName<>“Frank” and uFirstName=~“Frank”, Authorware will interpret them the
same way! The reason, I suspect, for the existence of <> is that as humans, we don’t like
double negatives, which the second expression is (uFirstName equals not Frank).
This leads us to the second point worth mentioning regarding operators in general, which
is that while we are familiar with the use of these kinds of operators with mathematical
expressions, we do not have much experience with using them with variables. The key
point to remember is that variables are simply containers. As such, they contain values,
whether those values are numbers or strings. Accordingly, I can use those variables
(which are after all just values of one sort or another) instead of numbers and text, to
create expressions. For instance, two of the variables you have already learned about are
TotalCorrect and TotalWrong. If a learner has gone through my program and answered 7
questions correctly and answered 3 questions incorrectly, TotalCorrect would be equal to
7, and TotalWrong would be equal to 3. Thus, the expression 7>3 would be equivalent
my writing TotalCorrect>TotalWrong.
379
The logical and mathematical operators are also fairly straightforward, once you get used
to using “|” to mean “or,” “*” to mean “multiply,” and “/” to mean divide. Thus, I can
write 5|6 to mean “five or six,” 5*6 to mean “multiply 5 by 6,” or substitute variables for
the numbers (e.g., TotalCorrect+TotalWrong). Likewise, at least with the logical
operators, I can write “Frank”|“Joseph” to mean Frank or Joseph, or substitute variables
for those strings (e.g., uFirstName). Two caveats to keep in mind regarding these two
types of operator, are that the mathematical operators are reserved exclusively for
numbers (or the variables that contain numbers), and that the logical operators can be
used with numbers, strings, or logical variables (those that equal TRUE or FALSE).
The last operator is a bit confusing at first glance. The concatenation operator is used to
join variables (i.e., the values they contain) into one thing. This becomes necessary when
writing script that normally has only a place for one variable or value but you want to
include more than one. The most common example is when you are using a function such
as WriteExtFile (you’ll learn about functions later in this chapter).
Expressions. What you have learned so far may make sense to you in terms of the rules
and concepts, but probably has little practical value to you at this point. There is little
apparent value in knowing how to tell Authorware that 7 <> 5, or to multiply 5*7. The
value of these rules becomes apparent only when you know how to use them in
expressions and if-then statements. To understand the former, you need only put three
concepts you already understand together: variables, the assignment operator, and logical,
mathematical, and relational operators. Let’s say that I want to tell the learner how many
answers they got correct on the second, third, or fourth try (assuming I limited them to 4
tries). There is already a variable for the total number of correct responses (TotalCorrect),
380
and a variable for the total number of correct responses the learner got on the first try
(FirstTryCorrect), but nothing for second, third, or fourth try correct. Technically,
TotalCorrect minus FirstTryCorrect should leave me with the number of correct
responses the learner got on the second, third, or fourth try. I can create a variable called
SecondOrGreaterTryCorrect and make it equal to TotalCorrect minus FirstTryCorrect by
writing the following expression:
SecondOrGreaterTryCorrect:=TotalCorrect-FirstTryCorrect
This is equivalent to telling Authorware to “take this variable I created and make it equal
to the value of TotalCorrect minus the value of FirstTryCorrect.” Likewise, I could create
a variable to track the percentage of correct responses on the first try by writing the
following:
PercentFirstTryCorrect:=FirstTryCorrect/(TotalCorrect+TotalWrong)
Which tells Authorware to take the value of FirstTryCorrect and divide it by the product
of TotalCorrect and TotalWrong, which represents the total number of judged responses
in the program, and store that value in a new variable called PercentFirstTryCorrect.
Another common example of an expression is the use of counters. A counter is a variable
that increments by some value (usually 1). You can use it, for instance, to track the
number of times a learner has visited a particular section of your program. This can be
particularly useful in non-linear instruction in which the learner has control over where
and when they go. For example, you may want to skip an introduction to a section if the
learner has already seen it once. To do this, you could use a counter, which by default
381
usually equals 0. If the counter were greater than 0 (>0), you could use the GoTo function
described in Chapter 9 to skip the introduction. Any numeric variable can be a counter;
the key is in the way that you use it in an expression. A generic example would be to
create a variable called MyCounter, set the initial value to 0, and increment it by one
every time it is encountered by typing the following in a calculation icon:
MyCounter:=MyCounter+1
The first time Authorware encounters this, Counter is equal to 0 (the initial value), so it
takes 0 and adds 1 to it, making Counter now equal to 1. The next time it encounters this
expression, Counter is equal to 1, so it takes 1 and adds 1 to it, making Counter now
equal to 2. I can now place the calculation icon with this expression in it anywhere in my
file where I want to track it. Of course, you would find it much more expedient to name
your counter something like SectionOneCounter, so that you know what it is tracking
(e.g., the number of times the learner has visited section one).
If-then Statements. In order to implement a counter and GoTo functions as just
described, you need to know about if, if-then, and if-then else statements. In our example
above, it doesn’t do us much good to know how many times the learner visited a section
of the program if we can’t use that information to tell Authorware to skip the section.
These statements are sometimes called conditionals, and are familiar to us from everyday
life: If I eat my broccoli, then I may have dessert; If it doesn’t rain, then I may play golf,
else I will have to stay home. If statements allow us to communicate our wishes to
Authorware in a similar fashion. In our counter example above, I would tell Authorware
to jump to question 1 if the learner had already viewed the section one introduction, or
382
else to jump to the section one introduction (if not), by typing the following inside a
calculation icon at the beginning of section one:
If SectionOneCounter>0 then GoTo(IconID@“Q1”) else
GoTo(IconID@“Section One Introduction”)
Heads Up: Note that the order in which this is written is critical. It is key that I begin
with the “if” statement instead of with the GoTo function. In human communication, I
could say “go to question one if the learner has visited this section before.” But
computers (an Authorware) are quite literal, so if I started with “GoTo(IconID@”Q1”),”
Authorware would immediately jump to that icon without reading any further.
Likewise, if I wanted to know if the learner had completed all four sections of my
program, I could create a logical variable for each section (e.g., SectionOneDone,
SectionTwoDone, SectionThreeDone, SectionFourDone) and set them to TRUE at the
end of each section (i.e., the place in that section that can only be reached by the learner
if they have completed the section). I could then type the following inside a calculation
icon:
If SectionOneDone&SectionTwoDone&SectionThreeDone&SectionFourDone=TRUE
then AllSectionsDone:=TRUE else AllSectionsDone:=FALSE
This simply says that if the value of each Section(One/Two/Three/Four)Done variable is
TRUE, then set the AllSectionsDone variable to TRUE as well. If this is not the case,
then set it to FALSE. Thus, if any one of those sections has not been completed, I’ll know
it. I might use such a series of variables in a program where the learner has complete
383
control over when they want to take the final assessment, at which point I can tell them
they haven’t completed all the sections yet, and ask if they are sure they want to continue
to the assessment.
A more in-depth example of the if-then-else statement may help to solidify this concept.
Assume that you want to provide performance feedback to the learner not just about total
mastery, but about mastery of each individual objective. Authorware does not know
anything about your objectives; all it can track is overall performance using variables like
TotalCorrect. Imagine that you have one goal with three objectives, each of which is
comprised of four questions. You have set a mastery criterion of 75% for each objective.
Accordingly, you need to know if they got 3 out of 4 correctly on each objective. To do
this, you might create a numeric variable for each question (e.g., Q1, Q2, Q3, Q4, etc.),
and set the initial value to 0 for each one. This gives you a total of 12 variables, one for
each objective. Inside the map icon for each correct answer, you could place a calculation
icon relevant to that particular question that would set the appropriate variable for that
question. For example, in the calculation icon I would place inside the map of the correct
answer for question one, I would type the following:
Q1:=1
Thus, every time the learner got the answer to question one correct, I would know it
because Q1 would be equal to 1 instead of 0 (the initial value). The expression would
vary for each question (e.g., question two would look like Q2:=1, etc.). After the learner
had gone through all the questions, each variable for each question would be equal to
either a 1 if they got it right) or a 0 (if they did not, since 0 is the default, or initial, value).
384
Accordingly, I could then create a new variable for each objective (not question), that
would be equal to the sum of the variables I used for each question of that objective. For
example, I could create a variable called Objective1, and make it equal to the sum of Q1,
Q2, Q3, and Q4 like this:
Objective1:=Q1+Q2+Q3+Q4
At the end of the instruction, then, I could type the following:
If Objective1>=3 then MasteredObjectiveOne:=TRUE
else MasteredObjectiveOne:=FALSE
This would tell me if they mastered (i.e., got at least 3 correct answers) for objective one.
I could then do the same for objectives 2 & 3. You may recognize a simpler way to do
this by combining this idea with a counter. I could use MasteredObjectiveOne as a
counter, and increment it by one every time they get a question in objective one correct:
MasteredObjectiveOne:=MasteredObjectiveOne+1
I could then use this expression for each of the four questions in objective one, which
would mean I don’t need to create a separate variable for each (i.e., Q1, Q2, Q3, and Q4).
I could then create another counter for each objective. At the end, these counter variables
would be equal to the number of correct responses in each objective.
Finally, if I want to know how they did overall on this goal (which is comprised of these
three objectives), I could create a variable called Goal1 and make it equal to TRUE if
385
Objective1, 2, and 3 were all mastered. In the first example (i.e., without using a counter),
this could be accomplished by typing the following:
If MasteredObjectiveOne=TRUE & MasteredObjectiveTwo=TRUE &
MasteredObjectiveThree=TRUE then MasteredGoalOne:=TRUE
else MasteredGoalOne:=FALSE
In the example where we use the variables as counters, it might look like this:
If MasteredObjectiveOne>=3 & MasteredObjectiveTwo>=3 &
MasteredObjectiveThree>=3 then MasteredGoalOne:=TRUE
else MasteredGoalOne:=FALSE
Here is another example of the ways you can combine variables and if-then statements. I
once had a project designed to teach how to anchor a boat. The correct way to anchor the
boat required the learner to perform seven steps in the correct sequence. I had decided to
make the instruction a simulation game, in which the learner could navigate around a
boat and perform any of the seven steps in any order. Each step had one correct and 2 or
more incorrect possible responses. I therefore had to know not only whether they had
gotten each step right, but also what order they had performed the steps.
To check this, I created a variable for each step called StepOneDone, StepTwoDone, etc.
These were logical variables, set to TRUE or FALSE, with FALSE as the initial value.
Upon performing each step, I used the status of the variables for the steps that should
have occurred prior to the current step if the learner had performed them in the correct
386
sequence. For step one, the variable StepOneCorrect was set to TRUE if, and only if, the
learner had gotten step one correct AND the status of all the other step variables was
FALSE, indicating that they had not performed any of those steps prior to completing the
first step. The script looked like this:
If StepTwoDone=FALSE & StepThreeDone=FALSE & StepFourDone=FALSE &
StepFiveDone=FALSE & StepSixDone=FALSE & StepSevenDone=FALSE, then
StepOneCorrect:=TRUE
else StepOneCorrect:=FALSE
I placed a similar statement inside the correct response map for each of the other steps,
but modified it to check for both the correct status of prior steps and the done status of
future steps. For example, the script inside the correct response map for the fourth step
looked like this:
If StepOneCorrect=TRUE & StepTwoCorrect=TRUE & StepThreeCorrect=TRUE &
StepFiveDone=FALSE & StepSixDone=FALSE & StepSevenDone=FALSE, then
StepFourCorrect:=TRUE
else StepFourCorrect:=FALSE
Note that I don’t need to check the status of StepFourCorrect here because I am in the
process of setting it. At the end of the program, I created another logical variable called
CorrectSolutionStatus and used the status of all the other correct variables to set it:
387
If StepOneCorrect=TRUE & StepTwoCorrect=TRUE & StepThreeCorrect=TRUE &
StepFourCorrect=TRUE & StepFiveCorrect=TRUE & StepSixCorrect=TRUE &
StepSevenCorrect=TRUE, then CorrectSolutionStatus:=TRUE
else CorrectSolutionStatus:=FALSE
Tip: You may have noticed that it is unnecessary to include the “else” portion of my
script example, since if the first set of conditions aren’t true, then the variable won’t be
changed from its initial value of FALSE. If you did, congratulations! You are beginning
to get used to the logic of scripting. However, it is good practice to specify every part of
your logic when scripting, just in case there is a way for your variables default value to
change that you have not thought of. By including the “else” portion of my script, I have
ensured that the value will be set correctly no matter what its value is at the time this
script is encountered.
There is no limit to the ways in which you can combine variables, numbers, strings, and
operators to create new values, as long as you adhere to the rules and nomenclature for
doing so. It is a bit confusing initially, but well worth the trouble to learn, as scripting like
this will be required by virtually all but the most rudimentary of interactive instruction.
Loop Statements. Unlike the scripting tools and concepts described above, you can get
by without mastering loop statements, linear lists, and property lists. These concepts and
tools are incredibly powerful and efficient, however, and if you take the time to learn
them, you will be well on your way to “expert” status as an Authorware programmer,
with all the rank, privileges, responsibilities, and big bucks thereunto. If there is one thing
I would do differently about my early study of Authorware, it would be to master these
388
concepts right away. They would have saved me untold hours of coding had I been able
to use them. I was able to accomplish everything I wanted to do without them, but at the
cost of more time and mental stress than was necessary.
Loops appear quite alien at first glance, and don’t much improve with a second look
either. But like many things in Authorware, what looks initially difficult is in reality very
simple. This is because every loop is exactly the same, script-wise, as every other loop. A
loop, as its name implies, is a piece of script that repeats (loops) a certain number of
times. All loops begin with the phrase “repeat with” or “repeat while” on the first line of
the loop, and end with the phrase “end repeat,” on the last line of the loop. These two
lines, the first and last line of a loop, form a kind of “sandwich” around what you want to
have happen during each cycle of the loop. The key is in specifying how many times the
loop should repeat. You can specify the number of times a loop should repeat by using a
counter, some condition, or a list.
For example, the following loop will cause the computer to beep 3 times:
Repeat with Counter:=1 to 3
Beep()
end repeat
The phrase “1 to 3” is a range that specifies how often the loop should repeat. In this
case, it will repeat three times, because I created a variable called Counter and told
Authorware to increment it by one from its current value until it equals 3, at which point
the “end repeat” cuts in and the loop is finished.
389
I can also create a loop that loops until a condition is satisfied (e.g., a variable I specify
reaches a certain value). For instance, I could accomplish my last example by writing the
following:
repeat while Counter<=3
Beep()
Counter:=Counter+1
end repeat
The condition is that Counter should be less than or equal to 3. Since I increment Counter
by 1 each time through the loop, it will eventually be greater than 3, and so Authorware
will exit the loop. You can use any kind of variable for your condition, not just a counter.
The last type of loop is one that makes use of a list variable. This type of loop is less
common than the conditional loop, but is useful when you need to repeat some action
with each element in a list. For the purposes of simplicity and illustration, let’s say that,
you want to find the product of all the numbers in a list (i.e., you want to multiply each
number together in sequence). Your list variable, called MyList in this case, is comprised
of the numbers 13, 25, 36, and 28, and you have already created it. The following script
would perform this action for you:
ListProduct:=1
repeat with X in MyList
ListProduct:=ListProduct * X
end repeat
390
Let’s examine this script line by line to see how it works. The first line sets the value of a
variable called ListProduct to 1. ListProduct is the variable I plan to use in my loop, and
this line sets the variable so that it starts where I need it to. While many variables might
start at zero, I need this one to start at 1, so that my multiplication comes out right. If I
started at zero, none the math would work because any number times zero will be zero.
The second line is the first part of our loop (which always starts with repeat with or
repeat while). Think back to high school algebra for this next part. Remember how you
wrote equations to solve for “x?” The letters x and y and z were used to represent an
unknown number that could be determined (i.e., solved for) by some set of rules or
procedures. In the case of our list loop, we likewise use the letter “X” to represent an
unknown number in MyList. “X” is unknown, because it varies each cycle through list.
The script will loop as many times as there are elements (in this case, numbers) in the list
variable. The first time through the loop, “X” will equal 13; the second time through it
will equal 25; the third time through it will equal 36, and so forth. The third line takes the
variable ListProduct (the one I made up and set to 1 on the first line) and makes it equal
to ListProduct multiplied by the current number (X).
Let’s see how this works. The first time through the loop, X is equal to 13, and
ListProduct is equal to 1. Therefore, ListProduct will be set to 1 X 13, which is 13. If we
had not set the initial value of ListProduct to 1, our first time through the loop would
result in a number other than 13. Since we need to multiply each number in our list by the
succeeding number, ListProduct MUST equal the first number after the first pass, so that
when it goes through again, we will be multiplying the second number by 13 (our first
number).
391
Now the loop goes back to the “repeat with…” line, only now ListProduct is equal to 13,
and X is equal to 25 (the next value in the list), so ListProduct will be set to 13 X 25,
which is 325. The loop now goes back again (because there are still numbers in the list),
and now ListProduct will be made equal to 325 X 36, which is 11,700. On the final loop
(because we are now on the last number in the list), ListProduct will be made equal to
11,700 x 28, which is 327,600. Because we have used all the numbers (Xes) in our list,
the loop is now finished and hits the “end repeat” line, causing the loop to finish.
Scripting with Functions
If you are feeling a bit overwhelmed by all of this at this point, don’t feel too bad.
Scripting is the least intuitive and most complex aspect of working with Authorware, and
it takes lots of time and practice. Take what you do understand and practice with the easy
stuff; creating and setting custom variables, performing calculations and basic
expressions (Variable1:=Variable2+Variable3) until you are comfortable with them, and
work your way up through if-then-elses and loops.
In the meantime, it may hearten you to know that it actually gets easier from here on out.
This is because you have learned the basic concepts and rules for writing script. The next
few sections will highlight only the specific syntax and rules needed for particular
implementations of these rules and concepts. We begin with an overview of integrating
functions into your script.
Functions always follow the same syntax, which is to list the function, followed
immediately by some set of arguments inside parentheses, like this:
392
SomeFunction(argument1, argument2)
In some cases, there may be arguments that themselves have options, but the basic
structure remains the same even in those cases. In an earlier example, we used the
function WriteExtFile. This function has as its arguments, the name of the file and the
thing we want to write to the file:
WriteExtFile(“My Text File.txt”, uFirstName)
In this case, I have specified that Authorware should create a file called My Text File.txt,
and should write in it the contents of the variable uFirstName. This is possible because in
many cases, you can combine functions with variables. In this case, I may have hundreds
of learners going through my program; obviously, many will have different first names! It
would do me little good if I had to specify the text I should write for each one. Instead, I
can use a variable for each learner’s first name.
The syntax for each individual function changes slightly, but is always defined for you in
the Functions window.
Scripting with Linear & Property Lists
Scripting with linear lists differs little from scripting with any other variable. They are
created in the same manner and given the appropriate initial value. They differ only in the
manner in which they are set or evaluated, and in the way that they are initialized.
Initializing List Variables. When you create a numeric, logical, or string variable and
set their initial values, you have essentially told Authorware what kind of variable it is
393
AND set it’s initial value. You may then work with this variable at will. For LIST
variables, however, the initial value when you create the variable is does NOT serve to
actually set the initial value; it only defines the type of variable. For this reason, you
MUST initialize any list variable prior to using it. To do this, you set the variable in
question to be equal to the initial value. For linear lists, you use [], and for property lists
you use [:]. Here is an example of each:
MyList:=[]
MyList:=[:]
These lines MUST occur sometime in your program BEFORE you begin working with
that list. You need only do this once in the file, however, so it is good practice to do so at
the beginning of your program.
Tip: In fact, it is good practice to initialize all your other variables at the beginning of
your program. The syntax for doing so is Initialize(), which tells Authorware to set the
value of all variables (except lists) in the file to their initial values. If you want only to
initialize one or more variables specifically, you can type the names of those variables
inside the parentheses, separated by a comma, for example, Initialize(VariableOne,
VariableTwo,….). This does NOT hold true for list variables, however, so you must also
type the lines as described above for any list variables you use in your file.
Adding Values to List Variables. In addition to the manner in which list variables must
be initialized, they differ from other variables in the manner in which they are set, as you
have already seen earlier. List variables are usually set and evaluated by using functions.
394
The functions for adding items to linear and property lists are AddLinear and
AddProperty, respectively, and the syntax looks like this:
AddLinear(MyLinearList, uFirstName, 5)
AddProperty(MyPropertyList, #uFirstName, uFirstName)
In the first case, we are adding the value of uFirstName (a variable we created) to a linear
list variable called MyLinearList (which we initialized earlier), into the 5th position in
that linear list. If we don’t include the index position number as the third argument, then
the value of uFirstName (or whatever we are adding) will be added to the end of the list,
by default. In the second case, we are adding the value of the variable uFirstName to a
property which we have also named uFirstName. We could also have specified a string or
number, or logical value to write instead of a variable.
There is a much shorter way to add information to a list, however. The following script is
the equivalent of the two examples above:
MyLinearList[5]:=uFirstName
MyPropertyList[#FirstName]:=uFirstName
Note that in the first case, you MUST specify an index position for the syntax to work.
This is not only shorter, but easier to remember, because it looks more like how we set
other variables.
Retrieving Values from List Variables. Retrieving values from your list requires the
use of a function to get the value, and the use of a variable to store that value. The
395
functions that you use for this are ValueAtIndex and PropertyAtIndex. You use these
functions to get the value you are looking for, and then you store that value in a variable.
In the examples above, we stored the contents of the variable uFirstName in the fifth
index position of a linear list and in the property called FirstName in a property list. To
retrieve those same variables from each list, then, I could write the following:
uFirstName:=ValueAtIndex(MyLinearList, 5)
uFirstname:=PropertyAtIndex(MyPropertyList, #FirstName)
As with adding to lists, there is a shorter and more reliable way of achieving the same
results:
uFirstName:=MyLinearList[5]
uFirstName:=MyPropertyList[#FirstName]
Again, with the linear list, you MUST specify the index position, which of course means
you must keep track of that index position. For this and other reasons mentioned earlier, I
highly recommend that you use property lists over linear lists whenever possible.
Sorting Lists. It is possible to sort linear and property lists, in ascending or descending
order. Sorting works according to the rules of alphabetizing, which means that (when
sorting in ascending order) numbers will come first, followed by items starting with the
letter a through z following. For this reason, you may want to consider storing strings and
numerical values in separate lists if you intend to sort them at some point.
396
To sort a linear list, you use the function SortByValue. For property lists, you use the
function SortByProperty. In both cases, there are at least two arguments. The first
argument specifies the list (for linear lists) or the property (for property lists) that you
want Authorware to sort for you. You can sort multiple lists or properties by listing as
many lists or properties as you want, each separated by a comma. The second argument
specifies the order you want to sort the list(s) or property(ies); TRUE means sort in
ascending order, while FALSE means to sort in descending order. The default for this
argument is TRUE, and if you leave it blank, Authorware will sort your list or property in
ascending order. Sorting only makes sense if you have a list with multiple entries of the
same sort, such as a list that stores the last names of all of the learners who have gone
through your program. Up until now, our examples have been for lists that are intended to
store the data for a single user, so sorting those lists does not make much sense. To
understand the process of sorting a list, let’s assume that we have a list called
FirstNameLinear and one called FirstNameProperty. In these lists, we have been storing
the learners’ first names, like this for property list:
FirstNameProperty[#1]:= “Richard”
FirstNameProperty[#2]:= “John”
FirstNameProperty[#3]:= “Tom”
and like this for a linear list:
FirstNameLinear [1]:= “Richard”
FirstNameLinear [2]:= “John”
397
FirstNameLinear [3]:= “Tom”
where the properties are numbered only for the sake of distinguishing one entry from the
next (i.e., there is no particular importance to the order). In both cases, I would now have
a list with the names stored in them in the order Richard, John, Tom. To sort these lists,
we could type the following:
SortByValue(uFirstName, TRUE)
SortByProperty(uFirstName, TRUE)
In both cases, the lists would then appear in the order of John, Richard, Tom.
Heads Up: When you sort a linear list, you sort the items in that list. Doing so changes
the index position of each item. For example, after sorting our linear list of first names,
John is now in the first index position, Richard in the second, and Tom in the third. Any
script that makes reference to an item by its index position will now point to a different
item in that list! Although sorting a property list results in the same order, because we can
refer to each element by its property name, we once again do not need to know its relative
position in the list.
Additional List Functions. there are several functions that can be used with lists, all of
which can be viewed by selecting the List category from the Functions window. A few of
the more commonly used ones appear in the table below:
Function
CopyList
Description
makes a copy of your list before you manipulate it as a backup
398
DeleteAtP
deletes the property itself
roperty
FindPrope
rty
ListCount
returns the number of elements in your list (property or
linear)
PropertyA
tell you position of a property
SetAtInde
replaces a value at a certain place in your list
tIndex
x
List
converts a string into a list
The last function, List, bears additional explanation, as it is critical when writing your
lists to an external file for the purposes of later retrieving that list. When you send a list to
an external file, it is automatically converted into a string. In order to turn that string back
into a list variable, you must use the List function (to turn the string into a list) in
conjunction with the functions ReadExtFile (to read the file which contains the string you
want to convert) and GetLine (to get the string from the line in the file in you wish to
read in order to convert it into a list). The following example reads in the first line of an
external text file and uses it to set the value of a linear list variable called MyList:
ExternalFileContents:=ReadExtFile(“My External File.txt”)
LineOneContents:=GetLine(tempVar, 1)
MyList:=[]
399
MyList:=List(LineOneContents)
Note that I had to initialize MyList prior to storing anything in it.
Variables, functions, and scripting allow you to extend the functionality of Authorware in
virtually unlimited ways. In terms of instructional programs, the true value of scripting
lies in your ability to customize the information that you are able to track, and the things
that you can then do with that information. In particular, they allow you to create
individualized, adaptive instruction through the tracking and use of time, accuracy, and
path.
Time
Built-in variables like SessionTime and TimeInInteraction allow you to track how much
time your learner is spending in your program, and at which particular places. You can
track this time over several sessions to get a good estimate of how long it takes the
average learner to complete each section (which is always good information to provide
the learner to help them manage this time). But you can go further with this, too.
Imagine that you track not only how long each person spends in each section of your
program, but that you then correlate that with performance assessment scores on the
related portion of the assessment. This would allow you to provide future learners with
information about how long it generally takes to master that particular section.
You can also use time to determine when and if to offer remediation. If you know that it
takes the average learner 15 minutes to complete one objective, and the current learner
400
has spent that long and is only half-way through the section, you could have a message
box pop up asking if they want to read some extra information on the topic. For example,
you could use TimeInInteraction in conjunction with an if-then statement like this:
If TimeInInteraction@“QuestionOne” - AverageLearnerTime>=300 then
GoTo(IconID@“Ask if Need Help”)
where AverageLearnerTime is a custom variable I have been using to track how long it
takes the learners who go through the program to complete that section, and 300
represents seconds, which is how Authorware measures time by default. Alternatively, if
they are spending much less time per section but still getting the practice items correctly,
you could ask them they want more advanced questions.
Accuracy
Built-in variables such as TotalCorrect, and CorrectChoicesMatched allow you track
learner performance during practice and assessment. You can also create your own
custom variables to track performance on individual questions or objectives, as well.
During practice, this information could be used to suggest (or enforce) remediation.
Perhaps you set a criterion of 75% on the practice items as a prerequisite for attempting
the assessment portion of the instruction. Maybe you have a pool of 20 practice questions
for one objective that you draw from at random (using a decision icon, which you will
learn about in Chapter 11) 4 at a time. You set a 75% performance rate for each
objective; if they miss more than one question in a group, their score would be less than
75%, so you would draw another question and present it. You could continue this process
401
until they meet the 75% criterion or miss so many that you determine they need more
help.
Being able to track this kind of performance information is also useful for testing
prerequisite skills and knowledge. It does the learner little good to know only that they
don’t have one or more of the prerequisites for the current program, but being able to tell
them which specific questions they missed and which corresponding skills they need
work on makes your instruction much more useful to the learner.
During the assessment portion of your program, you can use performance on individual
questions (by tracking each with a custom variable) to provide feedback to the learner
about which questions they missed. Additionally, you can map which questions go with
which objective to give them feedback about the objectives they need work on. Finally,
you could use all of this information to set custom variables that would then take the
learner (or offer them the opportunity) back to only the relevant portions of the program
to review, making sure that you provide them with new versions of the practice items
where possible.
Path
You can also use variables to track the path that learners take through non-linear
instruction. Such information can provide you with valuable feedback about your
interface and program structure; how often do people select the help function? After
selecting it once, do they continue to select it? Such information can tell you if you need
to change the placement or means of access to different sections, prompt learners to
consider selecting sections that are often ignored, or modify these problem sections.
402
When you combine this kind of tracking information with performance scores over time,
you can also get a an idea of the optimal path through the instruction. In other words, if
there is a path taken by most learners who master the instruction, you can suggest this
path to new learners, or modify the program to follow that path.
You can use all of these features in combination to make responsive, adaptive instruction
that would be difficult or impossible to do without the benefit of variables, functions, and
scripting. Imagine extending this by also tracking performance on pretest scores, level of
expertise and experience, gender, age, and other characteristics and using the relation of
all of these factors to performance, path, and time to create learning programs specific to
each individual. Once you have mastered the basic concepts, you are limited only by time
and the goals of your instruction.
Case Study
I wrote an instructional simulation game using Authorware as part of my dissertation. In
this game, students took on the role of a middle-school aged child who was helping their
aunt and uncle fix up a room in a house, as part of their business. In this game, the learner
could move at will around the room, measuring walls, ceilings, doors, and windows. The
goal was to determine how many cans of paint and how many rolls of wallpaper border
were needed to decorate the room.
Each learner was assigned a specific ID number, which was used to track their
information. In total, I was writing 214 separate variables to an external file. This
external file was supposed to contain all of the records of every learner who had gone
through the game on that computer. Each individual variable had to be separated by a
403
comma, so that my statistical program could read each one as a separate variable, and
each learner had to have all of their data appear on one line of the text file. In the interests
of space, I will only include the syntax for the first and last parts of my code, which took
up 53 lines in a calculation window:
AppendExtFile(FileLocation^"Session2.txt", StudentIDNum^","^¬
TimeInInteraction@"Calc79"^","^¬
TimeInInteraction@"Calc80"^","^¬
……………missing code here………………….
Onehundredeight^","^"Finished"^Return)
The function AppendExtFile was used so that I could add the current learner’s data to the
end of the file, rather than creating a new file. Remember that AppendExtFile will create
a new file if one does not exist. The first argument inside the AppendExtFile function,
FileLocation, is used to specify that the file should be looked for (or created) in the same
location as that in which the current program (my math game) resides. The second
argument specifies the name of the file to create, in this case, Session2.txt. The third
argument specifies what should be written to the file, in this case, a variable called
StudentIDNum, which I created to hold their ID number. Note that each of these
arguments is separated by a comma.
What follows this last argument is all of the variables I wanted to write to the external
file. I have connected all of these using the concatenation operator (^), which tells
404
Authorware that more is coming and it should not stop looking yet. Theoretically, I could
have just written all the variables to the file by writing the name of each variable
followed by the concatenation operator and the name of the next variable (e.g.,
variable1^variable2^…..). But remember that I need to have each variable separated by a
comma for my statistical program. Each of my variables has some value, usually a
number; if I wrote them all to the file as described above, a series of the numbers 10, 23,
50, and 72 would appear in my file as 10235072. My statistical program would have no
way of knowing where one number stops and the next begins.
Accordingly, after each concatenation operator, I wrote “,”. The quotes signify to
Authorware that what follows is a string (i.e., some text characters), not a variable.
Immediately after each of these, I had to use another concatenation operator to tell
Authorware to expect more strings or variables. This results in a pattern of
variable1^”,”^variable2….
Because my calculation window was not wide enough to display this syntax for 214
variables, I wanted to “wrap” the text around so that it all fit in the width of my window.
Remember that functions always operate on the arguments that appear in parentheses to
the right of the function? That means that all 214 of my variables, with the concatenation
operators, and the strings of commas, must appear inside the parentheses. I could not just
hit a return for a new line each time, because when Authorware hits the end of a line, it
thinks the function is done, and it expects (demands!) a right parenthesis.
To accomplish this, I have to use the special character, ¬, to signify that I want a new line
but that Authorware should treat what follows as the same line. This pattern is thus
405
repeated until all my variables have been written to the file, at which point I type the
word Return, which tells Authorware to insert a return (i.e., a new line) in the external
file. I do this so that my statistical program will know that each line is a separate learner,
or case.
For my purposes, this code accomplished what it was intended to accomplish. This code
could be modified to serve as an external set of records for each learner that could be read
back in to the file in future sessions, and it may be of some use to you to see how that
could be done.
To accomplish this, we would use the ReadExtFile function (to read the file in), a repeat
loop using the GetLine and GetNumber functions, and an if-then statement. To determine
how we know this, lets break down our task into plain English:
•
We need to have the learner type in their ID Number so we can search our records
(the external file) for it
•
We need to read the file called Learner Records.txt into our program
•
We need look at each line of that text file (because each line is one learner’s
record) one at a time
•
We need to look at the first number in the line we are looking at to see if it
matches the ID number the current learner has typed in (i.e., if this line contains
the records for this learner)
406
•
If it matches that number, then we need to read each addition number of that line
one at a time and assign them to the variables in our file (remember that each
number is the value of a variable that was written to that file, so we now must
reverse the process and read those numbers back into the appropriate variables).
This assumes that there are no string variables in the file we want to read.
We can accomplish goal one by using a text entry response, which you learned about in
Chapter 6, and storing what they type in a custom variable.
Goal two can be accomplished by using the ReadExtFile function to read the text file to
which we last wrote the learner records into a variable in Authorware.
Goal three can be accomplished by using the GetLine function on the variable that now
contains the contents of our external file. We can store the result (the line) in a custom
variable. We’ll have to put this in a loop of some kind, because we want to look at each
line of the file, and we don’t know how many lines there are.
Goals four and five can be accomplished by using the GetNumber function on the
variable that contains the line we just read. We can store that number in a custom
variable. We then need to compare that number to the number that the learner typed in
and, if it matches, read in and set all the variables. We can do this with an if-then
statement. Here is an example of how that code might look, with the code in boldface and
comments below each line to explain it in italics. We assume that we have already asked
the learner to type in their ID number, and that we have stored that number in a variable
called StudentIDNum:
407
TempVar:=ReadextFile(“Learner Records.txt”)
--reads the file and stores it in a custom variable called TempVar
repeat with i:=1 to LineCount(TempVar)
--Begins a loop that will happen as many times as there are lines in TempVar; i is
used as an unknown value that changes with each line/loop
CurrentLine:=GetLine(TempVar, i)
--Gets line i from the variable TempVar and stores it in a custom variable
called CurrentLine. i varies with each loop/line of TempVar.
CurrentNumber:=GetNumber(1, CurrentLine)
--Gets the first number from CurrentLine and stores it in a custom
variable called CurrentNumber.
if CurrentNumber=StudentIDNum then
TimeInInteraction@"Calc79:=GetNumber(2, CurrentLine)
end if
--If (and only if) the current number (the first number in the line we are
looking at) is equal to the number the student typed in, then read in each
additional number set the variables accordingly
end repeat
--Closes the repeat loop
Summary
Variables and functions allow you to track, store, and use data about the learner and their
interaction with your instruction. Scripting is the glue that allows you to use that
information to create customized, responsive instruction.
The key to working with variables and functions in your script is to understand the syntax
for each. Operators are symbols that allow you to create expressions (relational and
logical operators) and change variables (the assignment operator). Functions always
begin with the name of the function, and are immediately followed by a parenthetical
expression with one or more arguments, each of which tells Authorware what to perform
the action on, and in what manner. Functions always return some result, which in most
408
cases must be stored inside a variable using the assignment operator so that you can act
on that result.
None of these things would be of much help if we couldn’t control the manner in which
this information is changed or used. The script elements that allow us to do this include
the if-then, and loop statements. If-then and if-then else statements allow us to specify a
set of conditions under which we want Authorware to perform some action. Loops allow
us to automate a repetitive action a certain number of times, whether the number of times
is known to us in advance, or is determined by some variable such as the number of items
in a list or the number of lines in a string we obtain from an external text file.
Finally, there are a variety of ways to add, remove, delete, sort, or otherwise modify list
variables, which in turn can be used in script to help us track and organize large amounts
of learner data within and between sessions. The time it takes to master all of these
elements, while not inconsiderable, pays off in our ability to create adaptive, learnercentered instructional programs.
Exercises
11) Create a program in Authorware that asks the user for their first name and stores
what they type in a custom variable.
12) User AppendExtFile to save some data to an external text file.
13) How might I add an item to a linear list? To a property list?
409
14) How would I retrieve items from a linear list? A property list?
15) Describe the purpose of an if-then statement
16) Describe the purpose of a loop
17) If I want to look at every word in a string variable, but I don’t know how many
words to expect in that string, would I be more likely to use an if-then statement
or a loop?
18) Describe, in plain English, what the following script will do:
repeat with i:=1 to LineCount(MyText)
CurrentLine:=GetLine(i, MyText)
AppendExtFile(“Line.txt”,CurrentLine^Return)
end repeat
19) Take the program you created in the first half of the book (or any other program
you have with correct and incorrect responses in it) and have the program write
the following data out to an external file: The last name of the learner, time the
learner spent in the program, the number of correct responses made on the first
attempt, and the number of incorrect responses they made. The file should contain
multiple records (i.e., it should keep data for different learners separate from each
other, but stored in the same text file).
20) Add a login screen that asks for the learners last name to the program you used for
the previous question. Use what the learner types in to search the file you created
to store their records. When you find their record in that external file, use it to
410
read in all of the variables you wrote to the file when they last exited the program.
Refer back to the Case Study in this chapter as needed.
21) I have a list called MyList. In it, I have stored the numbers 1, 4, 10, and 13. How
many times will the following loop repeat? Why?
repeat with X in MyList
AddNumber:=AddNumbers+X
end repeat
411
Chapter 11: Knowledge Objects, BOTS, and Commands
Overview
This chapter will discuss how to use existing Knowledge Objects (KOs) and the basic
process and theory behind creating your own KOs. KOs allow you to add functionality to
your program through “wizards” that walk you through what are often complicated
processes in a step by step fashion. KOs are advantageous to you as a programmer, not to
your learners. They allow you to add features that would normally be beyond the abilities
of a novice programmer, which can be useful in a team-based authoring environment.
Creating KOs, and their brethren Commands and Bots, requires significant knowledge of
scripting in Authorware, most of which is beyond the scope of this book. Joe Ganci and
Chris Swenson’s book, “Extending Authorware for v6: Commands, Knowledge Objects
and other Extensions,” should be available by the time you read this called, and is
required reading if you intend to get into development of KOs, BOTS, and Commands.
This chapter will give you enough of an overview about how the basic process of creating
KOs, BOTS, and Commands to allow you to decide if and how much you want to
become involved with them. You must be familiar with variables, functions, and scripting
to proceed with this chapter. If you are not, read (or re-read) Chapters 9 & 10.
Objectives
•
Discriminate between KOs, BOTS, and Commands
412
•
Define KOs, BOTS, and Commands
•
Add and use pre-existing KOs and Commands to your piece
•
Describe the process of creating your own KO
KOs, Commands, & BOTS, Defined
KOs, Commands, and BOTS are all ways to automate procedures and processes in an
Authorware program. There are key distinctions between them, however, and you must
understand their differences and similarities in order to use them and create your own.
While we cannot cover the nuts and bolts of creating Commands and BOTS in any detail
here, an overview of what each does will help us discuss the basic process for creating a
KO, later.
BOTS
BOTS are the building block for all three types, so we will start there. While this next
section is fairly long, once you understand how a BOT functions, you will be able to
extend that knowledge almost immediately to Commands and KOs, so it is worth the
time you spend. BOTS get their name from the word “robot,” which reflects their basic
functionality: to automate repetitive, tedious tasks in a fraction of the time it would take
a human to do the same thing. BOTS are calculation icons that you place at the top of
your flowline. These icons contain script code that can perform a variety of functions.
They are triggered when you run your program and Authorware encounters the
BOT/calculation icon.
413
In order to understand what a BOT does, you have to know about dives. Dives are pieces
of code that “dive” through an entire Authorware file, looking at each individual icon in
that file, getting information about it, and moving on to the next icon. While intimidating
at first glance, they are essentially just big loops that have been written for you already;
all you have to do is put the stuff in the middle that you want Authorware to perform
during each cycle (iteration) of the loop. The loops that are used by a dive are written in
such a way that they will loop one time for every icon they find in the file. This is good,
because it means you can use them with any file, regardless of how many icons there are.
Luckily, some very smart programmers have already created these dives for us, so we
don’t have to know how to create them. This is good, because dives can be pretty
intimidating to the novice programmer (see Figure X).
Figure X. Example of a Basic Dive.
Tip: Although it is not necessary to understand the intricacies of a dive script in order to
use it, you may find it helpful for future discussions if you understand the concept of
414
“Parents” and “Children.” As you might guess, the names reflect relationships between
two objects/icons in Authorware. A parent is an icon that has other child icons attached to
it in some way. Six icon types can have children: interactions, maps, frameworks, sound
icons, digital movie icons, and decision icons. An example might be an interaction with
several responses; the interaction icon itself is the parent, and the responses attached to it
are its children. Likewise, a framework icon would be the parent to every page that is
attached to it.
As intimidating as they are, many elements of a dive should be familiar to you: If-then
statements, functions like GetNumber and GetLine, repeats, and properties. We refer to
icons in our files by the titles we give them. Authorware, on the other hand, would rather
work with numbers than language. Every icon in your Authorware piece has it own,
unique, ID number. This is called the Icon ID. Once we have the icon ID, we can do
anything we want to that icon: delete it, copy it, paste it, rename it, move it, or change
any of its properties. We have no way of predicting what an icon ID number will be,
because it is assigned by Authorware according to a process that would be too difficult
for humans to predict. We can, however, ask for the icon ID of any icon. Dives function
in part by getting the icon ID of every icon in the file. They do this in a loop process, one
icon at a time, so we can then modify each icon in the file.
The only part of the Dive you need to worry about is the part that appears in blue between
the dashed lines “Do custom stuff here” and “end of doing stuff.” Any code that you type
in this space will be executed on every single icon in the file. A BOT, then, is a dive that
someone has added some custom script to perform an action or series of actions on icons
415
in any file. To run a BOT, you need only copy the calculation icon to the top of your
flowline and run the program.
Tip: There are two kinds of dives: Depth and Breadth (some people also use the terms
Level and Sideways, respectively). Depth dives start at the flowline level of the piece and
look at every icon on that level. It looks at all the “Parent” Icons first (e.g., maps with
things inside them, interactions with responses attached, frameworks with pages attached,
etc.) then moves on to any “Child” Icons (e.g., the things inside a map, the responses
attached to an interaction, and the pages attached to a framework). It then proceeds on
through each successive level until all icons have been examined.
Breadth dives start with the first icon on the flowline and “drill down” through all levels
of that icon (including all Parents and Children) until it has seen them all, and then moves
on to the next icon on the flowline. In other words, and breadth dive preserves the
relationship between each Parent Icon and its children, while a depth dive takes a top
down approach by level.
In addition to knowing how the basic scripting language in Authorware works, there are
three main components that you will use in a BOT: Variables, Functions, and Properties.
Chapters 9 & 10 describe these concepts in some detail, so the following discussion will
address only the role these components play in a BOT.
BOTS & Functions/Variables
I can type anything I want to do to each icon (or types of icons I specify), by writing my
own code in the space between those dotted lines in the middle of the BOT. For instance,
416
if I wanted to add a copyright statement to each calculation icon in my file, I would type
the code in the space between those dashed lines. That code might look like this:
---------------------------------------------Do custom stuff here ---------------------------------vCalcContents:=GetCalc(_ChildIcon)
vCalcLastLine:=LineCount(vCalcContents)
if GetLine(vCalcContents, vCalcLastLine) <> “Copyright R. Van Eck, 2004” then
SetCalc(_ChildIcon, vCalcContents^Return^“Copyright R. Van Eck, 2004”)
end if
---------------------------------------------End of doing custom stuff----------------------------Heads Up: My purpose here is NOT to teach you how to write this code—that requires
more practice with variables, properties, and lists than can be reasonably addressed in one
chapter. It is intended as an illustrated example for you to follow along with.
This code makes use of three functions and one variable. Open the functions window
while you read the next section. Scroll down the list of functions to find the one called
“GetCalc.” This is one of the functions used in the example above. Read about this
function, and then find the others listed in the earlier example (GetLine and SetCalc).
Now let’s examine the example code above line by line to see what each is doing.
The first thing I have to do if I want to add a copyright statement to the end of every
calculation code in my file is to retrieve that code. Remember that the dive is going
through my file one icon at a time, and everything I type in between the blue dashed lines
will be performed on each icon, one at a time. To do this, in the first line, I created a
variable called vCalcContents and stored the contents of any calculation code that is part
of the current icon (the one the dive routine is looking at currently). The BOT script (the
stuff outside where we type our own code) has determined that the current icon the BOT
is looking at in each loop should be referred to as _ChildIcon. GetCalc is a function that
417
will retrieve this code from an icon, whether that icon is a calculation (with code inside
it) or an icon with a calculation ornament (code attached to an icon).
Now that I have the code for the current icon (stored in my variable, vCalcContents), I
can work with that code. The next thing I need to know is how many lines there are in the
current calculation (now stored in vCalcContents). I need to know this, because I want
my copyright statement to be the last line in the calculation (i.e., after the last line in there
now). To do this, I create another variable called vCalcLastLine and make it equal to the
number of lines of code that were retrieved from the current icon (by using ListCount on
the data, which is now stored in vCalcContents). vCalcLastLine now contains a number
that represent the total number of lines in the current calculation (e.g., if there were 5
lines, vCalcLastLine would equal 5).
Now that I know the last line in the calculation, I can look to see if it already has the
copyright statement in it. I tell Authorware that if the last line (vCalcLastLine) of the
current calculation (vCalcContents) is not equal to –Copyright Richard Van Eck, 2004,
then it should add a return (create a new line at the end) and paste in the copyright text.
Hopefully, you can begin to see the basic concept behind how this script and others work,
although you would not be able to create your own without lots of practice.
BOTS & Properties
In addition to using functions and variables, many BOTS also use what are called
properties. Chapter 9 discussed property lists and linear lists. It turns out that just about
all of the icon and file options that you can set through dialog boxes in your program are
418
actually properties that are stored in property lists. For example, when you open the
dialog box for your file properties (ModifyFileProperties), every checkbox you see
under the Playback tab is actually a property that exists in a property list. You can access
(and modify) these properties using the GetFileProperty and SetFileProperty functions,
respectively. You can find out what each property is called by searching for File Property
in the Authorware help pages and selecting “SetFileProperty.”
A classic example involves display icons. You already know how to embed a variable in
a display icon (CurrentPageNum, TotalCorrect, etc.). You may remember that one of the
necessary steps in doing this is to set the display icon to “Update Displayed Variables,”
(see figure X).
Figure X. Display Icon property dialog box.
If that check box is not set, then I would have to go to every display icon with an
embedded variable in it, open the property window, and check the box. In a large file, this
419
could not only get tedious, but would make it hard to know if I had actually found every
display icon and checked that box.
The example below is code that could be used to set this automatically:
The first line checks to see if the current icon (the one the Dive is looking at while this
code executes) is a display or an interaction (both of which have the Update Displayed
Variables property). The second line sets the Update Displayed Variables property to true
(i.e., it checks the option). This BOT would run in about second on a small file, and
would probably take 5 seconds or less on a file of 10,000 or more icons.
Commands
By now you are probably thinking “Good lord, I thought he said BOTS were the most
basic of the three; he just spent 9 pages discussing them!” Scripting in Authorware allows
you to extend Authorware’s functionality in powerful ways. The last 10 percent of a
domain requires the most learning, and scripting is a good example. Once you master the
basic scripting tools (lists, repeat loops, and if-then statements), however, all scripting is
pretty much the same process over and over.
Commands are a good example of this. The only difference between a command and a
BOT is that while BOTS only work on the file in which they currently reside, Commands
are self-contained programs that can be called from, and act on, another file. Turning a
BOT into a Command is almost as simple as packaging it without runtime and putting it
420
in your commands directory (usually c:\Program Files\Macromedia\Authorware
6\Commands).
I say almost, because there is one key difference between a BOT and a Command in
regards to the code. BOTS have the advantage of already being inside the program on
which they are operating. This makes it easier for them to get access to information about
the icons in that file. To understand why this is, imagine that a friend has asked you for
help with some task. If you are in the same room with him or her, you can see the same
thing s/he sees, and you can even step in and perform part or all of the task yourself. If,
however, your friend called you from another state and asked for your help, you would
have to rely entirely on their description of the task and their ability to implement the
suggestions you give them. Because Commands are outside the program, they have to
communicate with that program to get information (e.g., the Icon ID) and to make
changes (e.g., set properties; cut, delete, or move icons; etc.).
This is accomplished by using a function called “CallTarget” and a category of functions
called “Target.” In this sense, the file on which the command is working is the “target,”
which must be “called” in order to get information or perform actions. There are several
types of Target functions that can be used in this fashion (select the Target category from
the functions window to see them all), but it is important to remember that only target
functions can be used in a Command, so in that sense, BOTS are more powerful that
Commands (since you can use any function you want in a BOT).
At first glance, this may seem like a non-trivial difference, conceptually and in practice,
but once you learn the basic syntax for implementing the CallTarget function, it is a
421
relatively straightforward process to turn any BOT into a Command. The CallTarget
function can either send or retrieve information about an icon or the file. When we use
the CallTarget function to retrieve information, it is because we want to do something
with that information (e.g., find out what type of icon we are currently looking at in our
dive, change that icon’s properties, etc.). In order for us to work with that information, we
need to store it in a variable locally (in our command file). Once it is in a variable, we can
use any function we want on it (whether it is a Target function or not. So, while we are
limited to the Target functions when retrieving and sending information to the target file,
we can use any function while we are in the command file.
The syntax for using CallTarget to retrieve information from the target file is as follows:
myVariable:=CallTarget(name of target function, #argument/property here)
This takes the result of the CallTarget function (which is some information about the
target file or an icon in that target file) and stores it in myVariable (which of course is
named whatever makes sense to you). I can then use that variable to perform whatever
calculations and functions I want before using CallTarget to then send that information
back to the target file.
Power Tip: There is a variable called EvalStatus that is invaluable for determining
whether your CallTarget syntax was successful or not. This variable has 56 possible
values, all but one of which, 0, indicates a failure of some kind. You can use this variable
in two ways. First, you can use it to test your Command as you build it one line at a time.
Second, you can use it in conjunction with the Message Box feature to create pop-up
boxes that convey information to the learner. After each CallTarget function, you can use
422
an if-then statement or the Test function (the logical equivalent, but shorter to type) to see
if EvalStatus<>0 (that is, there was some error). If there was, then you can cause a
custom message to pop up in window by right clicking in the calculation window and
selecting InsertMessage Box from the contextual menu. You can then type your
custom message in the window and specify how it looks and what buttons are available.
To help you understand this difference, let’s reexamine the BOT example for setting all
display icons to “Update Displayed Variables” that I showed you earlier. Here is the
original code when I was doing this as a BOT:
To make this BOT into a Command, I have wrap all of my “calls” for information in the
CallTarget syntax. Doing so looks like this:
To Package & Access a Command
While BOTS are used on the program in which they reside (i.e., we place them at the top
of the flowline of the file we want them to run on), Commands are external files that can
be used from any program during the authoring process (i.e., they don’t have to be put
anywhere in the file we want them to run on). Commands are accessed via the
423
Commands pull-down menu within the program you are working on at the time.
Commands are finalized when you package them without runtime and store them in the
commands directory (C:\Program Files\Macromedia\Authorware 6\Commands, by
default on most systems). It will then be accessible under the Commands menu in any
Authorware piece I work with. I can also distribute it to others (along with instructions on
where to put it), and they can use it on any of their files, as well.
Knowledge Objects
You worked with knowledge objects in chapter 7, so you are familiar with what they look
like and some of the things that they can do. Initially, KOs seem to work in
incomprehensible ways that are closer to magic than programming. It turns out, however,
that KOs are really little different than Commands with an interface. The process for
building your own KO consists of building a command to do what you want it to do, and
then building a “wizard” interface to walk the user through the process. This wizard
interface collects information from the user and modifies the output accordingly. For
instance, the Create RTF Object KO has this screen as the second “page” in the wizard:
424
It takes the data the user inputs and uses it to determine what document should be used to
create the RTF object and whether it should start off visible or invisible.
The basic process for building a KO is as follows:
•
Create your wizard interface to collect information and store it in variables
o You then use those variables to modify the output code of the KO
o Use the CallTarget syntax as you do with Commands, since we are still
communicating with the target file as a separate file
•
Package this wizard without runtime and store it in the KO folder (by default,
c:\program files\macromedia\Authorware 6\Knowledge Objects
•
Create your KO (InsertIconKO)
425
o Ctrl-Alt double click KO icon to open it up. Build the functionality of the
KO inside. Use variables collected in your wizard to make changes
accordingly.
•
Select (highlight) the KO and save it as a model (FileSave in Model)
o Make sure to use the SAME NAME exactly as you did with the wizard
o Save it inside the KO folder
KOs are implemented in your program via the Knowledge Objects window
(WindowKnowledge Objects). Like commands, any KO you add to the KO directory
will show up in the KO window (if you add a new one while authoring, you will need to
hit the Refresh button to get it to show up).
Conceptually, KOs are little different than Commands, but in practice they require much
more practice. Luckily, Macromedia has provided a template to help you get started with
your own KO. The template is called Knowledge Object Template.a6p, and can be found
on the original CD (GoodiesMacromedia). Macromedia has also provided a TechNote
(15011) that walks you through using this commented and well-documented template
file. Additionally, Joe Ganci and Chris Swenson’s book, Extending Authorware for v6,
Commands, Knowledge Objects and other Extensions, is a MUST read if you intend to
develop KOs and Commands.
Summary
BOTS, Commands, and KOs are ways of automating certain aspects of the authoring
process. All are based in some part on what are called dives. Dives are further classified
426
as depth and breadth, or level and sideways dives. Both are essentially giant loops that
search (dive) through an entire file, looking at one icon at a time. While we use icon
titles, dives (and the BOTS, Commands, and KOs that rely on them) use Icon ID
numbers. Once we are looking at one icon in each file, we can perform a variety of
functions on it (e.g., copy it, paste it, delete it, update its properties, add text to it, etc.).
BOTS exist inside calculation icons, and work by being pasted at the top of the flowline
of the file on which they should operate. Commands are BOTS that have been packaged
(after being modified with the CallTarget function) and stored inside the Commands
directory. They are accessed via the Commands pull-down menu, and operate on the file
from which they are accessed and run. KOs are commands that have had a “wizard”
interface added to them to help the user implement them.
All are useful primarily to programmers, not to learners, as they help automate tedious or
difficult processes and promote consistency of design among a team of designers who are
working on the same project.
427
Exercises
10) Match the following descriptions with the appropriate name:
____Code is placed at the top of a file
which is then run. Code changes
settings and properties in the current
file.
A. Knowledge Object
B. Command
____Code is accessed via a pulldown
menu in Authorware. When
selected, code is automatically
executed on the current file.
C. BOTS
____Code is accessed via an icon that is
dragged to the current flowline.
Wizard immediately appears to
walk you through a process.
428
2. Indicate which of the following are external and self-contained (e.g., packaged):
a. ____ Command
b. ____ KO
c. ____ BOT
3. How do you access a KO? A Command? A BOT?
4. How do you “load” new KOs, Commands, and BOTS?
5. Your boss wants you to add a copyright statement at the bottom of every calculation
in your program. Would you be most likely to use a KO, Command, or a BOT?
6. Your training group is comprised of novice Authorware programmers. You have
noticed that they have a lot of trouble with drag and drop (Target Area) interactions.
Would you be most likely to use a KO, Command, or a BOT to address this problem?
7. You have developed some code that automatically turns on the “Update Displayed
Variable” option on every display icon with an embedded variable in it. You would
like to make this available to every Authorware programmer in your company. Would
you be most likely to use a KO, Command, or a BOT?
8. Identify the steps and the sequence in which they should occur in order to create your
own KO by writing and number in the blank space. In cases where two or more steps
could be performed in any order, add a lowercase letter next to the number (e.g., 2a,
2b, 2c, etc.). Place an “X” next to any step that you feel is not needed:
429
a. __X___ Package the entire file with runtime
b. __1___ Create the interface that collects the data from the user to control
how the KO will work
c. __X___ Save the file as a command
d. __5___ Save the KO as a model
e. __X___ Drag a KO icon onto the flowline
f. __2___ Package the entire file without runtime
g. ___4__ Build the functionality of the KO
h. ___X__ Package the KO with runtime
i. __3____ Insert a KO icon
430
431

Developing Instructional Products with Authorware 7 Richard Van Eck

Transcription

Similar documents

RLASD Substitutes - Navigating Your Mac

Blackfoot Motosports invites you to take 20%

Black Hawk County Assessors website step by step

the ICON Mini Poster

IB learner profile IB learner profile IB learner profile IB learner profile

HTC Android - MTN Online

SPWAW USER-SELECTABLE ICON GUIDE

The Birth of Techno

Wheaties Project Examples