CGDC '97 Roundtable Report

Day 1:

Populated completely by newbies, the attendees had no clear experience with authoring tools and (with one exception) no clear understanding of how to quantify their own expectations. And, of course, the ubiquitous Intel ringer. I tried to address the group in more of a seminar format, falling back on the material I'd used in my '96 roundtable (the Authoring Paradigms Checksheet, located at http://www.castlemoose.com/jsrt96h.html), as well as the general concepts covered in the Multimedia Authoring Systems FAQ (at http://www.tiac.net/users/jasiglar/MMASFAQ.HTML, and mirrored around the world at the RTFM sites).

Day 2:

Populated largely by return attendees and people who were in search of specific authoring tool functionality, this was the best (and most argumentative) session. The merits of Director vs. mTropolis vs. Authorware vs. every Card/Scripting tool (SuperCard, Toolbook, MetaCard, HyperCard, etc.) vs. Quest vs. Visual Basic (!) were discussed.

In so far as conclusions were reached:

*produce your slick demo in Director
Director gives you the best control over your graphical presentation (especially synchronization and animation) in the shortest amount of time.

*produce your functionality demo in mTropolis (and buy a Mac)
mTropolis gives you the best interactive behavior between elements (especially game-state behaviors) of any tool available. The downside for one attendee was that his shop is Win 95/NT only and he'd have to get a Macintosh to author in mTropolis.

*produce your interface demo depending upon who is authoring the demo:
- if your developer is a subject-matter expert (instructional designer, non-animation savvy graphic designer, or other non-technical type): use an iconic/flow control tool (Authorware, IconAuthor)
These users will benefit from the ability to visually track the flow of the program while they're desiging the interactivity

- if your developer is an educator or similarly trained interactive designer, use a Card-based tool (*Card, or Toolbook, or Digital Chisel)

These users will benefit from their legacy scripting abilities, and the familiarity of the index-card metaphor for organizing their thoughts

- if your developer is a programmer, use a Frame tool with a scripting language (Quest, Apple Media Kit, Visual Basic with MediaShop or FXKnife, etc.)

These users will benefit from their legacy coding ability while still having a robust visual interface to play off of, and won't be distracted by the lack of visual debugging clues.

Day 3:

Populated by newbies, an authoring-tool developer (vertical market), and the Intel ringer, with the late and appreciated addition of Chino (Direct-L and Sharkbytes maven), this session mostly concentrated on what feature set a new user should be looking for in building up their tool chest, and how to analyze their content (emphasis upon this year's handout, located at (http://www.castlemoose.com/jsrt97h.html) to choose their tools wisely.

A lot of the session was spent on the various deficiencies of currently available tools (limited text handling in Director vs. no integral text handling for mTropolis, for instance).

In this session, I was able to quiz the Intel dude as to what the hell a chip manufacturer was doing at an authoring tools session; his reply (I suspect this is the usual stock reply for someone so obviously out of his element) was that he wanted to know what Intel could do to help, and thereby sell more Intel chips. He really didn't like my comment (and Chino's agreement) that 90% of multimedia content is produced on Macs and SGIs, then ported to Windows.