September 2010 Archives

A usability testing report is part of your Unit 1 scratch portfolio (due 09 Sep).

Usability testing means sitting and watching (with your eyes open and your mouth shut) while people try to use a document or project that you are developing. If your volunteers can't work the controls, or they ignore the button that's supposed to take them to the cool 3D rotating graphics that you worked for weeks to perfect, that's a sign that your project needs work. (See "Usability Testing: What Is It?")

Usability testing is not opinion-gathering.  Rather than showing your project to a volunteer and asking, "What do you think?", a full usability test will objectively measure some aspect of the user's performance. (How long did it take them to find the help screen? What part of the game were they playing when they gave up? How many mistakes did they make when trying to follow your instructions?)  Your goal is to improve your project, so that when you test it again, they find the help screen faster, they play the game longer, or they make fewer mistakes. (See "Usability Testing: 8 Quick Tips")

A usability report quantifies the results of your usability test, demonstrating improvement. It's written in the form of a professional report. (It's not a reflective essay or a personal narrative, which might focus on your personal struggle to reach your goal. Rather, a technical report puts the answers up front, and explains them later.) (See "Short Reports: How To Write Routine Technical Documents.")

Continue coding, but also think about how you will conduct a usability test on your project. (Is there enough for your user to do, to comprehend, to interpret?)

You have been working with Scratch for a few days. What do you think so far?

By posting a link on the "Usability Testing" page from Sep 2, please submit your blog entry on usability testing. Think of your audience not just as me, but anyone -- including a potential employer -- who might find your website.

At this stage, ideally, you should already have done some usability testing, so that you can revising your project based on what you learned from your testing, and focus on writing up your report.

Your Unit 1 Scratch Portfolio will involve either a Scratch game or some other interactive / narrative creation.

Your portfolio begins with a blog entry. Submit your portfolio by posting a link in a comment on this page.

Scratch Game

• Review of 2 Scratch games
• Opening Screen Instructions
• Level 1 (what's the point?)
• Level 2 (how does it get harder? How is it more rewarding?)
• Level 3 (how does it get harder? How is it more rewarding?)
• Win Screen (what's the payoff?)
• Lose Screen (how to encourage replay?)
• Credits
• Usability Test Report (watch and learn from 3 testers not in this class)
  

OR

Scratch Interactive / Narrative

• Review of 2 informative/narrative Scratch projects
  
• Opening Screen Instructions (if needed)
  
• Section 1 (what's the point?)
  
• Section 2 (how does it build on section 1?)
  
• Section 3 (how does it build on section 2 and 1?)
  
• Explanation (what does it all mean?)
  
• Bibliography (cite sources, suggest related sources)
  
• Credits
  
• Usability Test Report (watch and learn from 3 testers not in this class)

Introduction to interactive fiction (text adventure games) and Inform 7 (a tool for creating them.)

In class, we will sample some recent IF games, and we will start some simple coding exercises. Just as Scratch has a history behind it (it was created by MIT researchers in order to introduce kids to the thinking processes they'll need in order to learn computer programming skills), interactive fiction also has a history.  I'll let Jason Scott's GET LAMP movie tell that story in detail, when he comes to SHU to screen a trimmed-down version. (Here's a trailer.)


People's Republic of IF  (How to play IF postcard)


How did my son react to text adventure games, one dark night during Snowpocalypse '10? Here is his first encounter. Watching Peter play is not quite the same thing as watching a beta-tester playing through your own game, but you'll see how he uses problem-solving skills. Watch for when he realizes that progress in this game depends on reading the text carefully and interpreting the words (rather than just shooting anything that moves).

As I introduce Peter to "Adventure," I describe the significance and history of this game, which in about 1976 invented the text adventure genre (in fact, today's "adventure game" genre owes its name to this game.)

I'll discuss your "game plan" assignment with you individually. The rest of the time, you'll have free for experimenting with Inform 7.

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?

Workshop.

By now, the map should be mostly complete, the starting location and the first few rooms (or puzzles or whatever division seems to make sense) should be fairly well fleshed out.

Our goal for today is to end up with at least a brief game you can start testing out on users.

Workshop.

At this stage, be ready to trim down initial expectations that may have been too lofty. A well-coded, well-written game with a few rooms will be more satisfying for the player than an unfinished epic full of doors that don't go anywhere and puzzles that don't work.

Focus on the beginning and ending scenes, and as you have time, you can insert a middle section.

I want to reserve today as another workshop day, but I thought it would be useful to call your attention to the "take-home message" from an item this weekend's New York Times (Kevin Kelly). On its own, this bullet list comes pretty close to doubling as the rationale for this course:

Technology will change faster than we can teach it. My son studied the popular programming language C++ in his home-school year; that knowledge could be economically useless soon. The accelerating pace of technology means his eventual adult career does not exist yet. Of course it won't be taught in school. But technological smartness can be. Here is the kind of literacy that we tried to impart:

• Every new technology will bite back. The more powerful its gifts, the more powerfully it can be abused. Look for its costs.
• Technologies improve so fast you should postpone getting anything you need until the last second. Get comfortable with the fact that anything you buy is already obsolete.
• Before you can master a device, program or invention, it will be superseded; you will always be a beginner. Get good at it.
• Be suspicious of any technology that requires walls. If you can fix it, modify it or hack it yourself, that is a good sign.
• The proper response to a stupid technology is to make a better one, just as the proper response to a stupid idea is not to outlaw it but to replace it with a better idea.
• Every technology is biased by its embedded defaults: what does it assume?
• Nobody has any idea of what a new invention will really be good for. The crucial question is, what happens when everyone has one?
• The older the technology, the more likely it will continue to be useful.
• Find the minimum amount of technology that will maximize your options.

Workshop

During part of the time I will introduce HTML and CSS, but based on what I saw in class Tuesday, it seems like the class could use another Inform 7 workshop day.

Introduction to HTML (hypertext markup language, the guts of nearly every web page) and CSS (cascading style sheets, a powerful way of displaying HTML pages).

Today is just review and practice, preparing us to start making web pages that look like native iPad or iPhone apps.

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)