Tic-Tac-Toe Whadyaknow

Articulate Engage is the secret sauce that adds interactivity to Presenter content. One of the best things about it is that non-programmers can use it to create simple, polished interactive screens.

Until recently you were limited to using the interaction templates that came with Engage. That has changed! Here is a new custom Engage Game that anyone can add to Engage '09 /Articulate Studio 09.

Try out the demo...

To get it, go to our Custom Engage download page

How it works

Once you install it, Tic-Tac-Toe WhaddyaKnow will show up in your Community Engages tab when you create a new Engage (Articulate's FAQ)

To create a Tic-Tac-Toe interaction, fill out the tabs in the interaction creation form. It is just like a Process Engage with two exceptions: you must include 9 True/False questions, and you have to name the tab titles with the answer to each question ("true", "false").

What's Next?

We decided to give away our first custom Engage to gauge interest and reactions from the community. We also saw it as an opportunity to give back a little to a very generous learning community. We are also working on a business plan in case there is a market to sell custom Engages.

We recently created a software demo in Flash Lite to show our capability to distribute eLearning experiences to potential customers. Compared to authoring for conventional PC distribution, be it browser-based, AIR or executable, Flash for Mobile Devices presents a complex world.

There are 3 major versions of Flash Lite, each viable for certain applications. Version 1 runs ActionScript 1 code, 2 and 3 run AS2. There are multiple phone manufacturers, each supporting a variation of Flash versions and implementations on different families of phones and phone OS'es. Of course, new phones come out on a quarterly schedule. The implementations can include standalone, browser-based, wallpaper, screen-savers and others. There are significant regional differences in whether and how one can install software on a phone, how much it costs, how much data costs, etc. There is no carrier, manufacturer, or underlying technology consistently leading share in any market. There are multiple markets in each region- consumer, youth, business. There is an almost infinite variety of screen sizes, aspect ratios, color depths, memory spaces, processor speeds, browser versions, form factors, keyboards.

Fortunately it appears that we are on the verge of a big change that should simplify this landscape. Adobe is soon to release a new player version that is designed to work on PCs and most devices. It will run on the new AVM, so ActionScript 3 code can be used. And it will run on all smartphones except iPhone/iPad, which will be handled through a separate publishing process from the same code.

Until Flash 10.1 is released and adopted, there are other ways to cut down the complexity. We found the most efficient way to do this is to start by defining who your end customer is. If your customer is on a homogenous technology base you are in luck! For example, most of the development work we do is focused on eLearning in North America. That means we must support Blackberry. If we were targeting youth casual gamers we would probably have to support multiple platforms or start with the one with the best developer support or payment terms.

Since we develop custom solutions for individual customers, we might encounter a potential customer standardized on Windows Mobile instead of Blackberry. As long as we can show a demo on running on a comparable smartphone, we can make it work on that platform as part of the project. Blackberry will be a challenge until Flash support is truly part of their platform, however.

A complex learning experience that includes scenarios, role-play and research requires designers to document their ideas very thoroughly before committing resources to coding and development.

Here is an example of some developer storyboards which augmented what the instructional designers were creating:

General Course Flow

First Level of Choice

Second Level: Scenario Choice

Third Level: Decision Tree

Developer Asset Relationships

A challenge that often follows closely on the successful launch of an online course is the demand for translated versions. Careful planning and design can make this a painless and relatively inexpensive demand to satisfy.

Novatek always asks clients if a course could conceivably be translated in the future. The answer is a very definite “No” more than half the time. This can reduce the development costs of a course, squeak a project through a pilot phase or address an immediate need. However, we have found that a substantial percentage of those same courses come back for translation anyway, and cost more overall as a result. We don't suggest that every course should be designed to support translation, but we hope we can provide a realistic backdrop to the decision process.

There are several ways that a course can be designed and optimized for rapid translation/localization. There are at least as many ways that a course designed to be a “one-off” can make translation more difficult and expensive.

Design factors that drive translation costs:

	English-only	Designed for Localization
Rapid-Development Tools	Optimal	Requires a copy for each language May require manual authoring adjustments to animations, timing. English version must be done first
Graphics	Embedded text in graphics is not a problem	Embedded text must dealt with and avoided in new graphics
Software Training	Screens can be captured and used as-is	Localized software must be captured for each language Non-localized software may require additional support for non-English learners
Narration	One-time cost to record and integrate with content	Multiple cost per language Integration per language may be required for steps and processes that are timed to key words/phrases
Planning	Simple, single-project project plan	Plan for both concurrent and linear development, manage dependencies
Programming	Options for rapid development or “simple” custom development	More advanced programming concepts and rigor required. A development framework and strict naming and data conventions are important.
Editing	Text, graphics changes require re-compiling and re-distributing. May require re-recording narration.	Graphics and Text can be changed externally and/or replaced without require re-compiling. Narration changes may or may not effect content to require re-compiling.

A schematic describing runtime structure of eLearning Content