Recently in due_dates Category

1) Written Report (30%)

• Abstract (10%)
• Body (20%)

2) Final Portfolio Screencast (30%)

3) Presentation and Project (40%)


1) Written Report

Your final project report starts with a blog entry, written for the benefit of an outside audience (one that does not know anything about the purpose of EL405).  The written component of the final portfolio should be about 800 words (roughly three or four pages, not including illustrations). Feel free to link to more detailed blog entries if you have more detail than will fit in 800 words.

The blog entry that starts your final project portfolio should either contain or link to an abstract.

Note: The abstract does not simply list the questions you are going to answer. Instead, it actually provides the answers (as briefly as possible).

• If your term project is an IF game, then I ask that you create a promotional page for your game, as part of your iPad-optimized web portfolio. (Why? Because I would like to see your polished HTML skills; further, your game may be of interest to players who aren't that interested in your educational goals.) Your promotional page should include a screen shot, instructions for first-time players (you can link to existing online instructions rather than write your own, but a few original lines will be useful), and a prominent link to where your visitors can play your game online. Don't forget to beta-test this promotional page. Here are examples of Emily Short's promotional pages and Adam Cadre's promotional pages. Artwork is optional.)
• If your term project is a web site, then you don't need a separate promotional page.

Your reader will read your abstract first, but you should write your abstract last -- after you have written out all the details in the body of your report.

Your complete abstract will feature, in a usefully-organized manner,

Content:
___ a description of your final product
___ the goals that motivated you at the beginning
___ the resources you used as models and tutorials
___ your previous experience in your chosen genre
___ your most important beta-testing results
___ the most important changes you made since the beta report

Form:
___ concise, informative prose
___ specific answers and conclusions (an abstract should not simply tease the contents of the full report)
___ a link to your final online project
___ a link to your final portfolio screencast (see details, below)

The abstract should be very concise, with no more than a sentence or two devoted to each item, but feel free to share your frustrations and triumphs, demonstrating your ability to engage as well as inform; please don't just write down the information in the order that I've listed it here. Instead, write an informative, persuasive package that highlights your accomplishments. Ask yourself, if your reader looks at nothing but your abstract, will he or she get your best points? You can leave the details for later, but the abstract is not a table of contents or a teaser.

The body of your portfolio should offer

___ more detailed treatments of each point you made in the abstract (with specific examples or narration, as appropriate), following the same order in which the points were presented in the abstract.  (You might offer additional blog entries to supply details of the various supporting points, or you might divide your work up into numbered subsections.)
___ as part of the details mentioned above, useful, selective screenshots of both the code and final product. (Carefully explain each screenshot, but note that three or four detailed examples that show diversity and creativity will be more valuable than an exhaustive record of what happens when you click every link or type every command)

2) Final Portfolio Screencast

Your final screencast should be four to six minutes long. Mention all the components of your portfolio report, but feel free to emphasize those parts that would be most interesting in video format.

The screencast should not simply walk the viewer through your project. Rather, its main purpose is to demonstrate how your usability testing helped you improve your project. (Try to make this engaging, rather than dry; hit the highlights.)

That screencast should include brief clips (introduced and/or captioned so that their purpose is clear) showing
___ a volunteer user (not someone who is already familiar with your work) struggling with some area of your project (perhaps the user gets lost or confused, or gives up, or misses something that you thought was obvious)
___ your explanation of the code causing the problem (remember to change the font size so the code is legible)
___ a demonstration of your ability to modify the code to address the problem
___ a demonstration of how your code change avoids the problem (it would be acceptable if you simply demonstrated the revision yourself, but it would be even more persuasive if you can show a clip of a volunteer who, thanks to your revised code, sails through what had been a problem area)

Overall, your screencast should show
___ careful explanations of what you hope to accomplish by showing each clip. Think of the needs of an audience with no outside knowledge of your project or EL405. (It may help to think of a potential employer as your primary audience.)
___ good production values (smooth edits, audible sound, legible text)
___ selective editing (I am not asking to watch a user's complete encounter with your project -- just brief highlights; any long sequence where a player is reading or wrestling with a problem or the text isn't legible might need voice-over narration or pop-up captions so that the viewer can tell what's going on and why the clip is important; trim the dry stuff, so that your viewer spends more time watching interesting stuff)

Relationship between the written report and the screencast

While your screencast and your written portfolio cover the same subject, design them so that they make sense separately.

• Your screencast should not assume the viewer has read your report, and your report should not refer specifically to something you say in your screencast.
• I'd rather not watch a screencast that simply clicks through each section of your portfolio, but if you reuse some material, that's fine. Just bear in mind that you are demonstrating your ability to present the same information in two different formats.

3) Project Presentation

Update, Dec 1

Form: Either a video posted to YouTube, OR a formal live presentation.

While the portfolio screencasts focuses specifically on how your user testing helped you improve your final project, the entire project presentation has a broader focus.  (See the subject checklist, below.)  Pitch your final presentation to your classmates and your professor, who are deeply familiar with the goals and methods of EL405; avoid summary, and spend time on analysis, synthesis and evaluation. (See "Writing that Demonstrates Thinking Ability.")

(See the project proposal page)

___ Presentation revisits your initial goals in terms of your artistic, technical, and personal goals
___ Presentation showcases your methodical, thorough user testing procedure
___ Presentation assesses how your final project has approached your artistic, technical, and personal goals
___ Presentation includes hand-coded HTML optimized for the iPad (for IF projects, a single promotional page is fine; for HTML projects, the project itself is enough)

___ Project ambition (to what extent does it stretch the skills you demonstrated at midterm?)
___ Project depth/scope (to what extent is it bigger/longer/more complex/better than your midterm project in the same genre?)
___ Project polish (writing, mechanics, small details)
___ Project organization (how do the components mesh, flow, interact? Are the purposes of each component clear? )

• What did you learn when you asked a minimum of three volunteers to play/use your project?
• What changes have you already made?
• What further changes (prioritized from most to least important) will you realistically be able to make by the Dec 8 deadline?
• What additional changes would you make, if you had more time? (Prioritize these, starting with the first thing you would do if you had more time, and ending with more ambitious, long-term possibilities.)
  

Present your findings in the form of a short technical report. Length: 500 words of original analysis, plus some useful combination of screenshots, code samples, transcripts, video clips, etc., as needed to support your findings. (Link to a full copy of your beta release, and assume your reader has direct access to it, so there is little need for a detailed summary.)

A short technical report is like a news story, in that it is written in the inverted pyramid format, but unlike a news story in that you are not writing a technical report for the general reader. (For this assignment, you can go ahead and write for your classmates and for me-- insiders who know has happened in the classroom, rather than writing for an outside audience. Feel free to link to older blog entries that provide background information.)

A technical report would not focus on your personal journey of discovery, nor is it a reflective self-assessment. Instead, it focuses on how the process leads to the product.

Submit your report by e-mailing it to me. (You are welcome to post it on your blog, but I am thinking of this report as a down-and-dirty, practical, internal document, so it would not be of much interest to outside readers, and I don't think it would be the most productive use of your time to make this particular document interesting to outside readers.)

An alpha release is a rough draft, with plenty of rough spots and "broken" areas. But there should be enough to work with that a patient, forgiving volunteer would be able to get the general idea of what the project is supposed to do.

Scratch

• Screencast w/ audio of first-time volunteer using your Scratch project
• Updated project
• Screencast of you demonstrating changes in project

Inform 7

• Screencast w/ audio of first-time volunteer using your Inform 7 project
  (you can use someone who already knows interactive fiction)
  
• Updated project
• Screencast of you demonstrating changes in project

Web App

• if it's not technically possible to record a screencast from an iPad, document a volunteer's experience as best as you can. (Video camera pointed at screen? We'll figure something out.)
• Updated project
• Screencast of you demonstrating changes in project
• CSS for screen, iPad, mobile, and print.

Blogging

• A main page that operates as the center for this entire portfolio, perhaps with links to separate pages on each unit, perhaps all in one. 
• I recommend that you blog major milestones as you go, rather than wait until the last minute. (You are welcome to use class time to blog.)
  
• The organization is up to you, as are choices that you make about how much information you provide, how you use hyperlinks and linked text, and how to make it as easy as possible for a potential employer to view your accomplishments.
  

An oral presentation that begins with a portfolio web page. (That page could be a regular blog entry, or part of your CSS Unit 3 project.)

The portfolio page should contain:

1. Introduction (What is the purpose of the portfolio? How does it serve the purpose of the class?)
2. Units (Not-so-brief treatments of Scratch, Inform 7, and HTML/CSS, with files to download, links to playable versions, and other resources that would be useful to help your audience understand the point of each project)
3. Conclusion (what would you want your future employer to know / believe / do, now that he/she has seen your portfolio page?)

Length: 10-15 minutes. Can be informal, but this is also an opportunity for you to get feedback on your formal presentation style.

Attire: I don't think you need to rent a suit for this, but a T-shirt is probably too informal. Come to class as you would go to an internship.

Assessment: I will give you feedback on your goals for revising Unit 1, Unit 2, and Unit 3, and an overall estimate of your grade so far.

Reminder: I have mentioned screencasts, but those are NOT due for the Oct 14 midterm portfolio presentations. (Your revised portfolio, with a total of 6 screencasts, is due Nov 9.)

A working connection of several pages, optimized to use the iPad style sheet. I recommend a professional / academic portfolio, but your subject matter is up to you.

 

I do not have any formal usability testing requirements for this project, but I encourage user testing.

Workshop.

Exactly what form the project takes will depend quite a bit on how much progress you've made, but in general, I'm asking you to report what you learned when you asked three volunteers to play your game. The format will be very much the same as the Project 1 Report. (Details TBA.)

Your Unit 2 Inform 7 Portfolio begins with a blog entry. Submit your portfolio by posting a link in a comment on this page.

• Review of 2 Interactive Fiction games
• Setting and tone of your game
  
• Influences (what factors influenced your choices? This can be informal and narrative, or a simple list)
• Opening (what does your opening screen of text accomplish? What creative and technical factors influenced the final result?)
• Code (what is one particularly tricky or thorny coding detail that demonstrates your ability to use Inform 7 to help you tell this specific interactive story? If you figured something out on your own, this is a good chance for you to call my attention to it.)
  
• Main Body (what happens during the middle part of your game? How do you reward the player's efforts and encourage further play?)
• Ending (one or several? How did the interaction between story-level writing and code-level writing affect the end of your game?)
• Credits (any games, resources, borrowed code, or other helpful contributions that helped you develop your project)
  
• Usability Test Report (watch and learn from 3 players  not in this class)
  

Come with a plan for your Inform 7 project. (You may post your plan on your blog or, if you want to keep your story a secret, you can just show it to me on your iPad.)

1. What are three IF games that inspired you (other than the ones we played in class)?
2. What is the setting and genre for your game? (For setting, draw a rough map, showing the locations of important objects. For genre, that would be "horror" or "adventure" or "romance" or maybe "wordplay" or "devious puzzles.")
3. Who is your PC? (What will happen when the player types "examine me" or "inventory"?)
4. What are some specific, concrete actions your will PC do?
   
1. Good: "Construct a cannon, using raw materials found in the environment (charcoal, sulfur, and saltpeter to make gunpowder; diamonds for bullets, a section of bamboo for the gun barrel, a strip of cloth from your clothes for a fuse) and "Break into a museum. put sleeping powder in the guard's coffee, and steal a painting." are specific goals tied to actions we can simulate.
2. Too Boring: "Get out of bed, eat breakfast, and wash your face" are certainly things to simulate, but they're not exactly exciting, in terms of a story -- unless there's an infra-red-eyed security bot loose in the house, or your character will go insane if he touches anything red, and the game involves making sure you avoid all red objects. Would that be any fun? It would probably depend on the writing.)
   
3. Too Abstract: "Get your crush to fall in love with you" is too abstract.  (You might instead "evade a guard dog and an overprotective father in order to deliver a love note to your crush," which will lead to a cutscene that shows you've won your crush's heart.)
   
5. What is a transcript showing the opening of your game, and the first few moves?
6. How will the player figure out what to do?
7. How will the game get harder, and how will you reward the player in order to encourage him/her to stick with your game?
8. How will your game end? (Is it a "win" or "lose" situation, or are there simply multiple endings?)
9. If you run short on time, what is one part of your plan you can cut?
10. If you have the time, what is one optional thing you'd like to do?