Recording SL

The following is the setup I used with CamStudio (an open source screen capture application available at but I think some of the settings (and especially the physical setup) may apply to other screen capture applications. This was done on a Wintel machine running XP:

Software Settings

  • Video compressor – Microsoft Video 1 (CamStudio’s lossless codec produces smaller files, but I could never find a codec to play the video under Windows Media Player or QuickTime. This may not be a problem if you are going to record directly to Flash .swf files, CamStudio offers direct recording to Flash via a .avi intermediate file)
  • Capture Frames Every – 200 milliseconds (keeps the file size low with no noticeable loss of quality)
  • Record audio from microphone (more on this later)
  • Audio options for microphone
    • Recording Format – 22.05 kHz, mono, 16-bit (22100 Bytes/sec)
    • Compression – MCI recording (no compression but avoids synch problems on long captures)

Physical Setting

Here’s the problem I ran into. With a USB headset, I could launch CamStudio with audio coming into the screen capture application via the microphone and record SL session video and my own voice audio—but not the audio voices of other SL participants. So, I found a non-USB headset (a microphone only will work—but find a good noise-canceling mic if you’re going this route) and physically placed it in front of me with the speakers equidistant behind the mic. Since I had CamStudio set to record from the mic, my audio voice was sent directly to Cam Studio; and because I didn’t have a USB headset (and because my speakers were the output for the SL audio), the mic picked up the audio voices from the other SL participants.


  • originally released by a company called RenderSoft who were subsequently bought by a company called eHelp who used some of the technology in their program, RoboDemo
  • eHelp was bought by Macromedia who wanted RoboDemo (which was to become Captivate)
  • CamStudio is now released as open source software

The Design Profession

The career recommendations was extremely practical in listing designer, project coordinator, and artist as the primary personnel paths. The industry categories were similarly useful; accrediting bodies (such as associations) also offer job opportunities. The professional development sections were somewhat cursory (writing a blog should be added to the promotional suggestions). However, the 2 pages that summarized design models with visuals was superb:

  • Dick and Carey provides all the elements (ADDIE) but only a linear process.
  • R2D2 provides an iterative process solution. Assessment is the junction and bridge between Dissemnination and Definition; the model can also embrace Nokia’s spiral between explicit and tacit knowledge.
  • The layers model inserts the real-world constraints of time (budget); higher layers can produce meta-designs such as simulation archetypes.
  • The rapid model marries ADDIE to concurrence.

Development – A Factory model

The Development phase is treated as a factory model which may be more appropriate for large-scale projects than for individual courses. The team management section could be a separate text, and while the graphics section should add a paragraph on 3D modelers, it’s a practical and useful overview. The scheduling section should include usage of Gantt charts.

The most thorough aspect of the chapter was on post-project activities which are often ignored:

  • post mortem debriefing
  • deployment
  • recommendations
  • training
  • documentation
  • summative evaluation
  • client evaluation
  • project cost analysis

Demonstration phase

A transition between Design and Develop/Deliver, this phase is often incorporated directly into a single iterative unit release methodology. The optional deliveries were very helpful:

  • treatment
  • scenarios
  • templates (content as well as layout/technical)
  • requirements spec (especially useful for software)
  • storyboards
  • scripts
  • prototypes

Practical suggestions are prevalent:

  • media asset lists
  • reading levels
  • translations
  • reviewer training

The storyboard form could have been demonstrated as a template–with the navigation (top) annotated as a common element.

Design – Flowchart & Content

The most helpful part of the entire chapter–since the bulk of it detailing the design document was covered in detail in our previous ID course–was the explicit linking of 4 deliverables to this phase:

  1. Kickoff meeting
  2. Design document
  3. Flowchart
  4. Content document

Our SME’s usually provide all the content; our role is to guide their development of aligned interaction opportunities and assessments.

The design document covered at a high level all of the elements in this key document. What I most appreciated were the sections on the flowchart and content document; the case which used the latter to help clients realize missing questions was very powerful. The flowchart topic could use expansion to present alternatives and rapid models.

Define – Project Proposal

The risk factors, although not explicitly grouped as external (client-side) or internal (production team), were very thorough: i especially appreciated the recommendation to use an MOU for intra-institutional work. The section on proposal research included the most critical “Why” question (we usually add, “Why aren’t you d0ing this yourself?”). The sample project profile was extremely detailed; we tend to focus on (a) interaction and assignment development for academic courses, or (b) the format and nature of the content for classroom self-paced training modules. The best question we’ve found for visual and interface design is to ask the client to show us her favorite web sites and tell us why.

Audience, outcomes, and delivery issues were treated only briefly (covered elsewhere); the schedule section was extremely helpful, although I would have appreciated a discussion of critical path in the schedule (especially in light of our programmers regularly underestimating their effrort by 30-100%). The budget reminder to account for marketing and product management was excellent; we use the estimate by labor (resource) for internal planning and tracking–and the estimate by deliverable for the client.


At UTTC, we use a smaller version of the production team described: the project manager is usually the instructional designer; we (often) use one graphics/multimedia/usability developer; we (usually) use one programmer (Flash AS and/or JavaScript); we seldom (but would like to) use an HTML/layout/documentation assistant. While we always follow the decision-making trail as recommended, we usually try to solve problems by asking questions and developing alternatives collaboratively with the client.

I especially enjoyed the practical suggestions of limiting meeting attendance, sending review materials 5 days (major) and 3 days (minor) in advance, and requiring agendas and meeting summaries. However, the real value of the chapter was in the delineation of visioning tools, although we usually reserve the 5th tool for the post-contract phase:

  1. brainstorming
  2. examples (exterior and prior work)
  3. user scenarios
  4. goal scenarios
  5. prototypes

The recommendation to provide reviewer guidance is well-taken; I usually use a modification of the schedule organized by date rather than task:

Date AISD team activity TPTL activity
w/o 2-16 Send project proposal for approval Review and approve project proposal; answer questions raised in proposal

The rest of the client, document management (version control, backup), and etiquette suggestions were helpful and could constitute an entire book.