Work Plan - Guidelines and Assessment Rubric
Because the work plan acts as a roadmap for the final project it’s
important to know what kinds of final projects are acceptable. To avoid
confusion, however, note that there is a separate rubric for the final
project. The final project is the culminating experience for this
class, and will become the foundation for much of what you learn. The
final project must be educational in nature, although education is used
here in the broadest sense of the term. For example, you can create a
job aid that walks users through assembling a device or repairing a
piece of machinery. Although they may not have learned the task, or be
able to perform it again without the job aid, learners should be able
to perform the task. You could also choose to design a learning
environment, that is much more open ended and allows for exploration
and discovery. Finally, you can design a more traditional vision of
computer-based instruction, consisting mostly of a presentation of
All past student projects are available here:
http://inst.usu.edu/~aewalker/studentProjects/ if you want some
You should be spending 5-15 hours in design related tasks (writing
the work plan, story boarding, and writing the project documentation),
you should be spending 40-60 hours in development related tasks
(finding and creating media, programming, etc . . . ). These ranges are
for individuals, if you work as a group you should be spending more
time on these activities.
You can either fabricate your own project, or you can find a real
one. You may also want to reverse engineer something that you have
already seen, just keep in mind that if you want to show this as part
of a portfolio you will need permission for any media and materials you
use in it. If you are currently working you are free to “double up” and
use something work related as your project. Finally for the MS/MeD
students in the Instructional Technology department you may want to
take something you designed in another class and take it to completion
here. We will be devoting some class time to your projects as we come
closer to the end of the semester. This will allow you to meet with
your groups (if you have decided to team up), and ask me questions, and
get help working through some of the problems you are sure to
encounter. Note that you
do need to encorporate sound into your project as well as two embedded
items (which we have a lecture on down the road).
As an initial step, you will be responsible for writing a work plan.
The work plan is a contract between you (or your group) and your
“client.” The finished work plan will consist of the following parts,
submitted at three different timepoints. The goal behind the phased
submission is to get you feedback before you go too far down a road
towards something that will either be too difficult to implement (or
perhaps too easy), or something that doesn’t really meet the needs of
this class. Your submissions should be cumulative (e.g. incorporate
feedback and resubmit prior sections with the new material).
Introduction (1st Submission) – a half page to a full page which
gives a clear picture of what the project entails. This should be
comprehensible by itself, and to people who have no idea what the
project is. Take a step back from coding and development here (i.e.,
there should be no mention of Adobe products or other technical
details). You might briefly mention who the target audience is here and
set the stage for your goal(s). Don’t use the first person (e.g. “ . .
. for this project I intend to”) as it makes your workplan extremely
uninteresting for a wider audience—and especially for the students in
our degree programs, you should be thinking about this as a portfolio
piece of interest to prospective employers.
Goal(s) (1st Submission) – a description of what end users will be
able to do after using the product. Think operationally. There is a big
difference between “Learners will know the fifty states” and “Students
will memorize the fifty states, and be able to name a state if shown
its shape and pick out the corresponding shape if given a state name.”
The definition of an operational goal is one that can be easily
measured. If you get in that mindset, you’ll do well with this section.
These also work far better as bullet points.
Client (2nd Submission) – a description of who your client is, if
this is a fabricated product be as specific as you can about who a real
client would be. This is important because it might impact some of your
design/development decisions. Here, client means“organization”—and it
needs to be a real one even if your relationship with the organization
is not real.
Scope (2nd Submission) – it is unlikely that whatever you create
will be a standalone piece, the intent of this section is to couch what
you are working on as part of a larger whole. For example, if you want
to build a piece of instruction on burning data CDs you might decide to
cover selecting appropriate media, formatting the disk, naming the
disk, and making a choice between an open and closed writing session,
all for Roxio Easy CD Creator version 5. You would be leaving out other
Burning software, previous versions of Easy CD Creator, burning music
CDs, labeling CDs, archiving/compression and alternative media storage
(super disks, DVDs, zip disks, tape backup, etc . . . ). This is the
most important part of the work plan, as it protects both you and your
client from problems. If you are clear in describing what you will do
your client will be happy and if you are clear about what you will not
do your client will not be able to increase the scope without further
increasing the budgeted time and/or the budgeted money. What you do
intend to cover should relate directly to your learning goals.
Target Audience (2nd Submission) – an indication of who will be
using the product. Outline factors that will be critical to your
design. For example, age, level of computer literacy, connection speed,
etc . . . For those of you who have taken the Instructional Design
class, this is not a full target audience analysis. Be brief. You
should also be specific. Designing a learning product for ages 13-90
will make your design task far too challenging. Think about an
archetype for the kind of person you see going through your training.
This will allow you to get much more specific about who this is for,
and have more interesting things to say in the limitations
Limitations (2nd Submission) – a discussion of constraints under
which the project has to be completed. All of you should have something
to say about a limited amount of time, and most of you should also be
able to note a non-existent or extremely small budget. Some of your
limitations might also flow naturally from your target audience section
(such as reduced connectivity or lower-end machines necessitating a
smaller screen resolution or the necessity for narration of
instructions with a pre-literate audience).
Finished Products (2nd Submission) – a list of what will be given
to the client. At a minimum this should include the work plan, the
storyboards, the project documentation, any development files, and the
final exported files. You may also want to include things like a well
organized set of related media.
Timeline (2nd Submission) – this is a list and description of
responsibilities for project completion alongside deadlines for their
completion. Make sure you leave yourself enough time to complete the
project documentation at the end. If you are working as a group, you
should designate what each person is responsible for.
Story board (Graded Submission) – This is a very rough idea of what
critical interactions will look like. For those of you who have taken
the design classes we will not be going to that level of detail.
Instead, give me (and yourself) some idea of how you will use your real
estate in the finished product. This can either be done with hard copy
or electronically if you want to use a rapid prototyping methodology.
Either way, graphics should be accompanied with a text description of
what is going on in each screen. You should have between 3-5 story
Check the syllabus for due dates. Everything will be due before the
stroke of midnight (23:59:59) on the date noted. More important than
point values for each part are their corresponding percentage of your
final grade (repeated above from the syllabus). The remaining 20% of
your grade will be based on assignments.
Deliverables: Submit a single MS Word document (or RTF file if you
have another word processing program). Go ahead and “build” on existing
work (so your second submission should include the intro and goals as
well as the additional sections, the third should include everything
even though only the storyboards will be new). You can revise the
introduction and goals based on feedback I give you but once your final
ubmission is in do not revise your work plan (even if you decide to
modify your project partway through). Any significant changes to your
design can be noted in your project documentation.
Submit to: Course website
File Naming convention: workPlan1YourName.doc (so if your name were
Sam Walker you would submit workPlan1SamWalker.doc). (use .rtf if you
submit a rich text format file). Please do not submit adobe acrobat
files unless you arrange it with me beforehand. The second and third
submissions would then be workPlan2SamWalker.doc and
Your work plan will be assessed using the following rubric:
Is your Work Plan clear, well written,
Does your Work Plan include all of the
required elements noted above?
Final Project and Final Project Documentation
Guidelines and Assessment Rubric
The project documentation has two purposes. The first is
functional, and the goal here is to provide enough information about
your project that another developer or team of developers could easily
come in and make revisions or extensions (many of you discuss in the
scope section of your work plan more features and/or content than you
intent to implement). The second purpose of your project
documentation is to serve as a portfolio piece when you go out and look
for jobs. Following are some strong suggestions of things that
will be good to have in your project documentation:
Give credit where credit is due, you should probably mention any
subject matter experts you worked with (most likely your clients) and
any material, such as actionScript from an outside source that you used
or adapted as part of the project.
In that same spirit
if you are working on the final project as
, talk about the team members and the role(s) each of you
Next steps – discuss the next logical area of development for your
project. This should be pretty easy to put together from the
scope section of your work plan, but might also include ideas that
emerged as you put the project together. Finally, this is a
great place to highlight things that were promised in your work plan
that did not get done due to time constraints.
The remaining sections are a little more technical. This portion can
be more of a “living” document if you choose, relying on good comments
embedded within your code rather than a separate explanation of what
your code does (although in both cases you will need a still need a
broad overview separate from your .fla file of what is going on).
Make the assumption that your end reader is familiar with Flash and
knows a little bit about ActionScript, but
assumption that they are familiar with your code. Some good
things to include here:
Timeline Structure – How is your project organized? (both in terms
of layers, and major “events”).
Flow chart – This can be an excellent means for diagramming some of
the main system interactions. Depending on the complexity of your
project, you might want to use a series of small flowcharts or
one large flow chart. (If your layers are well organized and
named well, you might collapse the timeline into the flow chart, by
providing the frame number(s) of the various portions of your
project). Pg. 54 in the option text has an example flow chart, in
addition to the exemplar project that is on the course web
Naming conventions – What are your naming conventions for
variables, layers, library items, etc .
Some of these might be general (all lower case, with subsequent
words capitalized) and some might be specific to particular items in
your project (Dynamic text fields used to show text feedback are given
an instance name in of “feedBackTextXX”, where “XX” refers to the
current frame number) Important variables – List and discuss the key
variables in your project (this will likely be limited to any session,
client, or application variables).
Explanation of critical code segments (again, using comments is
acceptable). Walk a programmer through how your code works for
complex sequences (such as drag and drop interactions w/
Known bugs – Discuss known limitations of your program (ways that
users can “break” it), or ways that it performs in an unexpected
Video compression –
If you use video in your project
write down the settings you selected when you embedded it in your flash
Be concise, if you find you are repeating yourself—you should
probably just explain it once and talk about other times that it
happens (for instance, don’t walk through how you implemented drag and
drop fifteen times).
Similarly, don’t feel the need to give a blow by blow on precise
pixels for where you placed elements. If you set up your project
timeline well and you have a good overview, someone can figure out what
they need to know.
If you find yourself spending more than 2-3 hours on your project
documentation you are probably going into too much
Project Documentation Front End
– As you have seen
with the exemplars, you will be responsible for creating a simple web
page (named index.html) that allows other class members (as well as
other interested parties) to take a look at your hard work. This
front end should consist of the following parts:
System requirements – you can pull this out of your work plan if
you already wrote this into your limitations section, but let your
audience know this up front.
Primary development platform – Was the work done on a PC or on a
MAC? This is more for me as a grader, so that I can look at your
development file(s) through the same lens.
Link to work plan
Link to project documentation
Link to related media files (assuming that you used graphics,
sound, and/or video, this would just be a link to a folder containing
these files prior to import into flash so they can be edited and
adjusted). I have had at least two students as me for their full
projects after taking the class, and they were both grateful to have
the original media as well.
Link to development (.fla) file(s).
Link to exported (.swf) file(s) – if you promised web delivery,
then link them to a web page with the .swf placed in-line. Flash
will do this for you, but we did not cover this in class, I’m happy to
help with this and with the project documentation front end if you need
it, either during class consultation time or a scheduled time outside
– These are
the development files for your final project along with the exported
.swf (or .swfs). Most of what I want is described below in the
rubric. I will say that although you won’t lose points for using
scenes as a way to break up your file this does cause performance
problems. The preferred method is to use movie clips as opposed
Deliverables: You will be handing in a folder (which will
likely have sub-folders) of everything mentioned in the
documentation front end
section above. You don’t need to
host this front end on a web server (I’ll take care of that), although
you are certainly free to do so. What you do need to do though is
give me everything I need to host it by packaging all of the materials
into a single .zip archive.
Do not submit this .zip file
as it will to very unhelpful things with
it. Instead, you can email it to me direct (the usu mail server
will give you directions and a place to post large files for me if it’s
too big. You can also get it to me via external media (CD-R
DVD-R are acceptable).
Submit to: see above.
Since there are multiple
ways to submit, send me an email message letting me know where I can
find your project.
File Naming convention: Use the following naming convention
for your folder name (zip archives should have this folder at the top
level, with all files and sub/folders contained within)
finalProjectYourName, so if your name was Sam Walker your folder would
be named finalProjectSamWalker.
Your final project
will be graded
according to the following criteria:
will be graded according to the
Is your project documentation complete (would someone
be able to recreate the structure of your project looking only at the
final .swf and your documentation—more importantly, would they be able
to easily find what they were looking for if they were forced to come
in and make changes?) Does it contain all of the relevant
portions as outlined above?
Is your project documentation
Is your project documentation professional (free of
typographical and grammatical errors)?
Does your project documentation contain a functional
front-end as described above?
Do you use a consistent naming convention for layers,
symbols, and pseudo-symbols? Do all of your layers have a
meaningful name? (e.g. “layer 1” is not an option)
Is your project easy to change and update?
you should have only the number of instances you absolutely
need for each symbol or element of the project.
you should use consistent tab stops for your code—don’t be shy
about using the autoformat button in the actions window.
Finally, you should not have any “magic numbers.” For the
purposes of this class, a magic number is defined as a value in
ActionScript that is used in more than one piece of code, but not
updatable in one place. If you find yourself typing out a number
in more than one location, create a variable and grab the value from
the variable instead.
Does your project include at least two
well-constructed ebedded items of an appropriate type for the learning
objective? Note that well-constructed means well written and
includes appropriate feedback.
Do you have a well organized timeline (related layers
are near each other, elements are where they are promised).
Is your project free of all syntax errors, and major
logic errors (operating in ways that are unexpected)?