by Kevin Schmitt

The Mother of All Flash Quiz Engines, Part 1

One of the things we strongly believe in at Standard Imagination is making technology understandable, accessible, and fun to those dedicated to teaching and learning. In that spirit, we’re going to dedicate this space to the process of creating tools aimed at educators and students, in the hopes of accomplishing two things: 1) for those interested in learning more about creating such tools, we’ll hopefully provide a solid foundation for your own experiments, and 2) to make (and make available) a series of free tools for general use.

In this first installment, we’re going to begin the process of creating an XML-based quiz engine using ActionScript 3 in Adobe Flash CS4. We’ll start slowly today by figuring out what features we want to include and how those features will translate to the structure of the XML template we’ll eventually use to populate the Flash playback engine. So, to kick things off, let’s ask the obvious question: what do we want this thing to do?

What we want this thing to do

The idea of this tool is to provide a simple mechanism for stepping through a series of multiple choice questions (including true/false). Hardly an original idea, to be sure, but one of definite usefulness in a variety of situations. Let’s run down a list of features we’d like to include:

• A variable number of questions, each having between two and six possible answers (after all, why limit ourselves to four when we don’t have to?)
• For each question, the order the possible answers appear in is randomized
• The option to include a media asset for each question
• The ability to choose between two progress modes:
  • inline scoring, where correct answers are given and explained after each question
  • a silent mode, where users would either be shown the results (along with the correct answers to any missed questions) or directed to submit their quiz with no results given
• A progress indicator
• An optional countdown clock for timed quizzes

It looks like we’ve got ourselves a pretty hefty to-do list for such a supposedly “simple” application, but as the adage may or may not go, anything worth doing is worth doing well enough to not have to do again. In any event, it may be useful to run through a few follow-up statements now that we have the feature list, which will hopefully help flesh out some eventual development tasks which may not be glaringly obvious at this point:

1) The biggest development ramification lies in the ability to submit a quiz. This necessitates having a server-side technology (such as PHP) handle the submission process, and while that’s an extra layer of complexity, we’ll aim for a fairly painless implementation.

2) While optional, we will be running into scenarios where we will want to provide further explanation or information when the answer is revealed, so we’ll have to make sure that content exists for those situations.

3) The optional media asset should, ideally, encompass the various media types that Flash supports: images (GIF, PNG, or JPEG), audio (MP3), video (H.264 MP4 or FLV), and even embedded Flash movies in SWF format. Might as well go for broke.

And, with that hodgepodge of requirements strewn about like so much confetti, let’s go about organizing things a bit with a technology designed for just that sort of thing.

Enter XML

If you are only vaguely aware of this buzzword-compliant technology, rest assured that XML is more than just one of the few heavily hyped dot com era up-and-comers that happened to prove highly useful over time — XML is also very easy to work with, even for the complete beginner. While there is no shortage of comprehensive XML resources available online, we’re only going to go over a few basics that will get us up to speed. If you’re already familiar with the ins and outs of XML, consider yourself excused and we’ll see you in part two. For the rest of you, however, here’s the skinny:

Put simply, EXtensible Markup Language is a specification for structuring sharable data using custom markup. Even more simply, XML is sort of like HTML (the underlying language of the Web), except you get to define your own tags. If you still need simpler, we’re going to approach XML the way we would make an outline, because the two processes can be remarkably similar. In fact, let’s create a very simple outline in XML to better illustrate things.

Before we start, it’s worth mentioning that there aren’t a whole lot of rules when it comes to XML, and indeed, there often is no “right answer” for how best to structure your data. But, like Fight Club, what rules do exist are non-negotiable:

• Every XML document must have a root element
• XML documents must be well-formed

If those two rules don’t make a lot of sense yet, don’t worry. We’ll go over what things like elements and “well-formed” mean in due time. For the moment, let’s say I’m writing a book (which I never seem to actually get around to, but that’s another story entirely). If I were to describe the parts of this non-existent book using XML, it might look something like this:

<book title="My Nonexistent Book">
	<information>
		<author>Kevin Schmitt</author>
		<copyright>2033, at this rate</copyright>
		<publisher>WikiWorld BitBooks</publisher>
	</information>
	<chapterlist>
		<chapter>Finally Getting Around to Writing a Book</chapter>
		<chapter>Shopping It to Publishers</chapter>
		<chapter>Having Them Laugh At You</chapter>
		<chapter>The Fetal Position: A Perfectly Normal Coping Mechanism</chapter>
	</chapterlist>
</book>

What is hopefully apparent in this admittedly ludicrous example is that XML allows you to structure data any way you like. In this case, I’ve used self-defined tags (or elements, as they are officially known) to segment data into two distinct parts: general information on this book, such as author and copyright, are contained inside an information element, while each chapter element is contained inside the chapterlist element. Two things are of note here, as they are essential to the two rules mentioned earlier. One, the root element in this case is the book element present on line 1, so that satisfies the first rule. Two, notice how every element has both an opening and closing tag? This is the most basic definition of well-formed. For example, the following code snippet is well-formed:

<copyright>2033, at this rate</copyright>
<publisher>WikiWorld BitBooks</publisher>

While this snippet is not well-formed:

<copyright>2033, at this rate
<publisher>WikiWorld BitBooks</publisher></copyright>

In the incorrect example, I didn’t close the copyright element before beginning the publisher element. A wrinkle in this rule is that elements can be self-closed if they don’t contain any data. For example, if I don’t have any copyright information, the following is perfectly acceptable:

<copyright />
<publisher>WikiWorld BitBooks</publisher>

In this case, the opening and closing tags for the copyright element are squeezed together into a single, shorter tag that both opens and closes itself. We’ll see this shortly as we modify the XML for the quiz data for various scenarios, so file that info away for the moment.

The last thing to mention before mashing all this information together into our XML template for quiz data is this: in the root element, I’ve introduced another XML concept — attributes. In this case, the title is an attribute of the root book element, and is contained in quotes. Attributes are part of the containing tag, the same way, for example, the width attribute is part of the img tag in HTML. As you write more and more XML over time, you’ll come up with your own methods for when and how to use attributes.

Putting it All Together

Now that we’ve completed the five-minute, bare-bones XML primer, let’s smash that info together with the requirements and features we defined earlier into the base structure for our quiz engine. So, without further ado, here is our first cut at an XML file for the quiz engine we have yet to build:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

<!--mode types: inline, reveal, or submit-->
<quiz mode="inline" timer="0">
	<item>
		<question>The first question is a true/false question.</question>
		<answer correct="true">True</answer>
		<answer>False</answer>
		<explanation>When a question has one answer called "true" and one answer called "false," it is a true/false question.</explanation>
	</item>
	<item>
		<question>Does this question have three possible answers?</question>
		<answer correct="true">Yes</answer>
		<answer>No</answer>
		<answer>Maybe</answer>
		<explanation>Some questions have two answers, some have four, but this one has three.</explanation>
	</item>
	<item>
		<question>How many possible answers does this question have?</question>
		<answer>One</answer>
		<answer>Two</answer>
		<answer>Three</answer>
		<answer correct="true">Four</answer>
		<explanation>Four is an excellent number in general, so we are very fortunate that it is the right answer in this case.</explanation>
		<media>http://url/path/to/mediafile.jpg</media>
	</item>
</quiz>

While this document may be bordering on overload to those of you who are new to XML, hopefully it’s starting to make some sense. After all, one of the hallmarks of XML is that it is, in theory, a human-readable data format. However, some further explanation might be needed just to get everyone on board with some of the choices, so let’s do that now.

Line 1. I’ve included a standard HTML comment here, which helpfully reminds us of the three choices available for the mode. Remember, inline keeps score and tracks progress as we go, while reveal and submit are the two flavors of the “silent” mode we outlined earlier.

Line 2. Here we have the required root element, which I’ve named quiz, and the twist here is that all the settings we need have been distilled down to two attributes (type and timer) and placed inside the root element itself. The latter attribute has been set to zero, a number which, when we build the engine itself, will be ignored.

Lines 3-8. Each question is encapsulated in its own item element, and contains the base question element as well as the various answer elements. Note the correct attribute which defines the right answer in each case — it doesn’t have to always be the first answer listed. Our engine will find it.

Line 7. Since this XML document specifies inline mode, we have to remember to place an explanation element in each item, which will be displayed after the user clicks an answer.

Line 23. The media element is optional, which is why it only appears in the last item. In all cases, including this one, this element requires a URL (either full or relative) to any of the media types that Flash supports. In this example, we’re specifying a JPEG image.

Until Next Time…

Well, we’re off and running. We’ve defined our features and requirements, learned a bit about XML, and set up a working XML template we can use when building our quiz engine. Speaking of which, we’re going to actually fire up Flash CS4 next time and start bringing this thing to life, so stay tuned!