Rubrics

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

All past student projects are available here: http://inst.usu.edu/~aewalker/studentProjects/ if you want some additional ideas.

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 section.
• 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 boards.

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

Assessment Rubric

Your work plan will be assessed using the following rubric:

Criteria	Points
Is your Work Plan clear, well written, and professional?	30 points
Does your Work Plan include all of the required elements noted above?	70 points
Total	100 points

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 a group , talk about the team members and the role(s) each of you played.  
• 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 do not make the 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 page.  
• 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/ feedback).  
• Known bugs – Discuss known limitations of your program (ways that users can “break” it), or ways that it performs in an unexpected manner. 
• Video compression – If you use video in your project , write down the settings you selected when you embedded it in your flash development file.  

Other thoughts:

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

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:

• Project Title
• 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 of class. 

  Final Project – 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 to scenes.  

• Deliverables:  You will be handing in a folder (which will likely have sub-folders) of everything mentioned in the project 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 to blackboard 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 or
• 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.

Assessment Rubrics

Your final project documentation will be graded according to the following criteria:

Your final project will be graded according to the following criteria:

Criteria	Points
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?	30 points
Is your project documentation accurate?	25 points
Is your project documentation professional (free of typographical and grammatical errors)?	25 points
Does your project documentation contain a functional front-end as described above?	20 points
Total	100 points

 

Criteria	Points
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)	10 points
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.	40 points
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.	10 points
Do you have a well organized timeline (related layers are near each other, elements are where they are promised).	30 points
Is your project free of all syntax errors, and major logic errors (operating in ways that are unexpected)?	10 points
Total	100 points