Data-Driven Wizardry: Uses of Dynamic Data in Authorware

1. Data-Driven Wizardry: Uses of Dynamic Data in Authorware Presented by Mark Steiner mark steiner, inc. eLearning Producer Conference 2006 Boston, MA

2. Agenda • Introductions • A Quick Example • Why Data-Driven? • General Constructs and Guidelines • Designing the Data Structure • Designing and Developing the Engine • Designing and Developing the Wizard • Examples • Questions and Answers

3. Some Stuff About Me • BS Industrial Tech. ‘88 • MS Instructional Design ‘92 • 15+ years eLearning & interactive media dev. experience • Dozens of projects from 2 min. to 33 hours in runtime • Authorware 2.0, ‘93 • Presenter - eLearning Confs. US & Europe • Started mark steiner, inc. in March 2001

4. Some Questions About You • Project Manager/ID/Developer mix? • Tool use: Authorware, Flash, Director, Dreamweaver, Toolbook, other? • How many have built data-driven apps? • Data structure / database experience level? • What do you expect to learn?

5. A Quick Example • SBC (now at&t) Sales Information Guide

6. Why Data Driven? • Oddly enough, computers are really good at computing, so why not leverage that valuable ability? • Your client and the economy DEMAND it • Extend the functionality, usefulness, life, and value of your application • Ease of updating content

7. Many Ways to Go . . . • Most problems have either many answers or no answer. Only a few problems have a single answer. • Edmund C. Berkeley

8. General Constructs and Guidelines • First, your mindset must embrace all things self-defining, relative paths and structures, lists, data structures. • Specify your application’s requirements before authoring. • Define the line that separates the dynamic from the static, weighing the costs of over-building a dynamic app and under-building a static app. Apply a simple cost-benefit analysis. • Utilize an engine and wizard approach.

9. Designing the Data Structure • Start with paper and/or a white board first, prior to authoring. • What is your app going to do? What problem are you trying to solve? • What structures and media types will be dynamically supported? • What do the structures look like? • What is the relationship(s) between various data sets?

10. Designing the Data Structure (Continued) • Flat data files or database? What are the criteria? • Over the web? • Any cross-platform issues? • Lots of sorting / relationships? • What is the size of the user base / enterprise? • What is the criticality of application? • What is the complexity of the data structure? • Does data already exist somewhere else? • What is the depth of database knowledge on your team?

11. Designing the Engine • Again, though from purely an application standpoint: what is your app going to do? • Map it out first on paper or a whiteboard first. • Define global initializations / data reading and writing. • Define local / incremental initializations and data reading / writing. • Define and order the mechanics and transactions that the engine needs to process.

12. Designing the Engine (Continued) • Data and media: What info will your data (related to media) store, and when and how will you display corresponding media elements? • Consider any cross-platform issues. • Consider any web issues. • Data • Media • Firewalls

13. Time to Develop . . . • Plans are only good intentions unless they immediately degenerate into hard work. • Peter Drucker

14. Developing the Engine • Employ Rapid Prototyping techniques. • Create a dummy data file with sample data. Mock up portions of the functionality and / or data. • Depending on the complexity of the engine, you may want to develop pieces at a time. • Implement global initializations / data reading and writing. • Is entire engine in one part of your code? Or, are the several subroutines?

15. Developing the Engine (Continued) • Implement local / incremental initializations / data reading and writing. • Implement each mechanism / transaction. Are they in the correct order? If they are related, ensure that all relationships and links are addressed and functioning. • Again, if the engine is complex, break development into logical, manageable chunks. • Test individual components, then start assembling and testing multiple pieces and finally, everything.

16. Designing the Wizard • How sturdy are you going to build it? • What defaults will you specify? • What if the user makes no selections? • What things will “break” it? • If you choose to allow some “brokenness”, what are the consequences? • What error detection and corresponding error messages are needed? • Ensure that both “New” and “Edit” function equally well.

17. Designing the Wizard(Continued) • Follow the design you’ve already established for the engine. • What data do you need to gather from the user? • What are your interface requirements? • Is your layout easy to understand and user friendly? • How does the user navigate? • Can / should they be able to skip steps? • When do you save / write the data? • Can the user revert?

18. Developing the Wizard • Employ Rapid Prototyping techniques. • Follow the lead of the already defined needs of your application. • Ensure that everything you want to manipulate can be successfully manipulated. • Develop chunks of functionality at a time.

19. Developing the Wizard • As with any development, be aware of various dependencies within your code. • Start assembling and connecting chunks of functionality. • Let plenty of users test functionality for usability and bugs. • Make it functional first, pretty later.

20. Two Cents on Designing for Clients • If you are going to design for yourself, then you have to make sure you design deeply for yourself. Otherwise you are just designing for your eccentricities, and that can never be satisfying to anyone else. • Charles Eames

21. Examples • Walgreens XML Engine • SBC Online Assessment Tool • Green Screen (mainframe) Simulation Wizard and Engine • PowerPresenter Presentation Tool-Wizard and Playback Engine • Orius Multimedia CD-ROM and Database Wizard

22. Questions and Answers