Design: FightCard Factual Knowledge Practice System

The following write-up describes a flashcard-like system designed for individualized user practice of factual knowledge sets.

FightCard / Flashfight

FightCard / Flashfight is a mobile, online factual knowledge study system that allows users to build practice card sets based on their own goals and information needs, and to exchange cards and sets with other users in a networked community.

The primary objective of Flashfight is to provide an easy-to-use, smart flashcard system that users can take with them via digital mobile devices. The system reminds and encourages users to complete regular practice sessions, and builds upon their individual progress for maximum efficiency.

Flashfight employs a fighting game element that reflects user’s accuracy through turn-based fighting moves featuring cartoon avatars.

The following basic workflow illustrates how users may interface with the system:

User Accounts

Users must have an account and profile on the Flashfight web system, and are required to authenticate on each visit.

Users may customize their profile by choosing an avatar and setting their preferences for sessions and interface.

Problem Cards

Flashfight makes use of “cards” for problem instances in a session. Cards may be either binary matching–i.e. flashcards–or multiple choice. Rather than simply flipping the card, flashcards prompt users to select their certitude (“Know “, “Kind Of”, “Don’t Know”) in order to see the correct answer. Once the card is flipped, users are prompted to confirm or contradict their assumption (“Knew It!”, “Kind of Knew”, “Didn’t Know”) in order to proceed to the next card.

Multiple choice questions allow for up to 4 answers or distractors, and can be set to an “adaptive”-style mode. Though not a true adaptive mode, Flashfight’s adaptive mode allows users to guess again after a first failed answer choice, but at a penalty to their score.

The “back” of cards provide feedback–either response-specific for incorrect or uncertain answers, or topic-specific and elaborative feedback for correct or certain answers. Both sides of cards allow for text or media embedding.

Flashfight employs a card and session sequencing system that determines frequency and timing of card reoccurence. Based on the user’s response to a card (correctness in multiple choice or certitude in flashcards) individual cards may be moved into one of three “boxes”, mimicking a Leitner flashcard system. Box 1 include cards that should be practiced each session. Box 2 includes cards that should be practiced every other session (or user’s preference). Box 3 includes cards that should be practiced once every third session (or user’s preference). This Leitner system encourages user interest by decreasing the number of automatic responses, and increases efficiency by limiting the number of cards already known by the user. This system also allows more granular historical tracking of user progress and memory.

Progress Tracking

User’s session results are tracked, stored, and reported at the end of a session, followed by historical session tracking.

A flashcard session’s results are shown via stacked bar graphs, one stacked bar to count each level of confirmed certitude (“Knew It!”, “Kind of Knew”, “Didn’t Know”), and one stack within each confirmed certitude bar for each level of initial (presumed) certitude (“Know “, “Kind Of”, “Don’t Know”). This reporting allows users to self-assess and reflect on their own certitude and knowledge, and helps the system more effectively place cards in “boxes” for repetition.

A multiple choice session’s results are also shown via a bar graph (for regularly scored sets) or a stacked bar graph (for adaptive sets). In adaptive mode, the bar graphs stacked levels correspond to first attempt, second attempt, and third attempt. A fourth attempt is considered a failed attempt. Third and fourth attempt cards are placed in box 1 for repetition each session, etc. A multiple choice session’s results will also display the question numbers as hyperlinks for immediate user review before the session ends.

Following session result reporting, a session history will be available to users as a line graph that charts user’s progress–including number of items in each of the three boxes–over a historical period.

Creating Cards, Categories, Systems

The system allows users to select pre-made cards from categories to form their own sets for practice. Users may create or import their own cards via a GUI or file upload (XML, CSV, or plain text). Cards, categories, and sets may be shared by individuals in the networked Flashfight community.

Trainers

Flashfight utilizes graphical agents called “trainers” who “speak” via text bubbles. Users may select from a variety of different trainers. Trainer’s “personalities” will differ, often humorously, in order to increase motivation and encourage interest. Trainers greet users immediately after authentication, at the beginning of each session, and respond to session outcomes and session histories. This concept is based on emotive agents found in popular user progress games such as those found in the Nintendo DS games Brain Age and Brain Age 2.

Flashfighting

The name of the system refers to a tentative feature called “flashfighting”. A flashfight may occur in one of two ways:

1. The user’s avatar engages in a turn-based “fight” against an arbitrary computer opponent throughout a session (represented by a slightly animated character in the corner of the screen). Each correct or certain response results in a “strike” that damages the computer. Each incorrect or uncertain response results in a “strike” to the user’s avatar. The opponent’s “health” is determined by the user at the beginning of the session as a percentage of the total number of cards in the sets. A user’s accuracy can result in a number of different fight outcomes:

   <5% = loss: Super KO
   50% = win: timed
   >84% = win: KO
   >95% = win: Super KO
   

   

   Ryu’s Super KO from Street Fighter Alpha 3
2. The user’s avatar “fights” the avatar of another user in the community after a “challenge” has been issued. A challenge consists of one user sending his or her session results for a particular card set to another user to “beat this score”. Overcoming another user’s challenge can result in a rematch challenge based on the user’s results. Flashcard-based challenges rely on the honesty of the players (similar to correspondence chess).

Reminders and Notifications

The system will provide email and SMS notification, either for reminders (on a schedule pre-determined by the user) or for new or outstanding flashfight challenges by other users.

Scripting Languages and System Requirements

Flashfight’s front-end will be written in XHTML, CSS, and Javascript using web standards for use on any internet-connected web browser–desktop or mobile. It does not rely on Flash, Java or other proprietary programming languages, and thus should be usable on all Javascript-enabled web browsers, including those found on Apple devices. It is not an “app”, though an app version may be useful in a future iteration.

The back-end will be written in PHP using a MySQL database.

Mock-Ups

The following gallery of mock-ups represent latest drafts of screen layouts for key interfaces of this system:

(Sample fighter avatars are representational only, and are used courtesy of Speedbrkr)

Research-Based Criteria Mapping

Flashfight corresponds to the following criteria mapped out by David Wiley’s IPT 564: Intro to Instructional Design course.

Category	Criteria	Implementation
Providing Feedback	1. After each response, feedback is immediate.	This is inherent in the flashcard/MC system. This particular system responds to user’s choices by immediately displaying the "answer". Additional feedback is available for correct or certain answers on demand, or can display automatically if thus set.
	2. Includes knowledge-of-correct-response feedback (e.g., including response accuracy verification, providing correct answers, etc.)	This is inherent in the flashcard/MC system. See above.
	3. Elaborative feedback is available for low certitude responses	Corrective, response-specific feedback for uncertain answers is automatic. Elaborative, topic-based feedback and material for exploration is provided either on demand or automatically for correct or certain answers.
	4. Periodic feedback relates tracked data to learner goals (e.g., learning/achievement is definable (either by designer or user, i.e. five correct iterations)	Cards display current card number of total stack, including correct/incorrect so far. Session outcomes are immediately communicated after a session (Users determine session length [by time or by cards]) via bar graphs, followed by a history of sessions for that user via line graphs. Users will also be prompted to "stamp" a calendar date to track the number of instances of practice.
	5. Results of learning session are related to learner goals.	Explicit definition of learner goals are not currently supported in this design version, however the system’s method of user-specific progress tracking of sessions allows users to recognize their progress over time as they work through a defined set of information.
Scheduling Sequence and Spacing	1. Sequencing reflects a scheduled framework (e.g., Leitner system)	Depending on user’s response to flashcards (certitude) or multiple choice questions (accuracy), cards will be delegated to one of three different "boxes" which correspond to interdaily review (see Leitner system). It is likely that boxes should correspond not to the days of the week, but to the count of sessions.
	2. Presentation of each item is discrete and spaced.	Each card is a discrete unit of information with corresponding answer. Spacing occurs card to card.
	3. Design provides for at least one intersession interval of anywhere between one and thirty days (no "cramming").	Design encourages intersession intervals of one day by "dimming" the set or activity after completion. Intersession intervals are further encouraged by use of a Leitner system of "boxes", and by activation of e-mail or SMS-based reminders (which may result in phone text messages, Twitter replies, or Facebook posts) that users practice.
Motivating and Engaging	1. Design captures learners’ interest (e.g., use simple unexpected events like a loud whistle or an upside-down word in a visual, etc.).	Irrelevant and extraneous events are consciously excluded from this design. However, providing access to a community-built library of information sets may be attractive to students with intrinsic or extrinsic motivation to learn facts. The system utilizes user-selected "agents" (called "trainers") that greet and encourage users to progress. Cards may be multimedia, depending on the card author.
	2. Design stimulates learners’ inquiry (e.g., give mentally stimulating problems that engage a deeper level of curiosity, etc.).	Topic-based elaborative feedback is built into this design for users who exhibit certitude, or correctly respond to prompts.
	3. Design maintains learners’ attention (e.g., utilize variation).	Cards are randomized to avoid repetition and increase transfer out-of-order. Cards themselves may be multimedia, depending on the card author.
	4. Design makes learning outcomes relevant to students (e.g., connect content to learner goals, interests, learning styles, etc.).	The customizeability of card and card set creation encourages users to develop practice routines that meet their own learning goals. Pre-built card sets will be available on a number of different topics. For the most part, card sets will be created and shared by users in the community. Finally, users may create or import their own card sets.  Cards themselves may be multimedia, depending on the card author.
	5. Design builds learner confidence (e.g., providing examples of acceptable achievement).	Learner confidence will be supported by user progress tracking, both within a single session and along a historical timeline. "Trainers" greet and encourage users to progress by building their confidence and motivation.
	6. Design promotes student satisfaction (e.g., provides recognition and evidence of success, practical application, etc.).	Recognition will be provided in different flavors by a variety of pre-programmed "trainers" who offer congratulations or suggestions, often in a mildly humorous fashion.
Managing Cognitive Load	1. Design takes advantage of verbal (text, narration, etc.) and non-verbal (photographs, illustrations, diagrams, etc.) input channels	The design facilitates multimedia for dual-coding/dual-processing of verbal and non-verbal visual information on each side of  the card. However, this system is more of a tool than a specific instructional design, and therefore card creators should be encouraged to make use of dual-coding theory through a "Tips on Creating Your Cards" tutorial.
	2. Design avoids cognitive overload (e.g., text in close spatial proximity to visuals to avoid split attention cognitive load concerns).	See above for more on the limitations of the system to control design of multimedia. However, care has been taken in the system to minimize extraneous cognitive load through usable interface design, by spatial proximity of session and historical results, and by color-coding of response buttons and responses both on a card and in session result graphs.
	3. Design acknowledges and adapts to limitations of audience (i.e. universal design and accessibility)	Because the system is XML-based and will be writtin in XHTML, CSS, and Javascript addressing accessibility issues should be simple. Universal design is furthered by simple GUI, intuitive navigation, etc.
	4. Design enables learner to efficiently "chunk" facts by identifying, connecting (grouping), and sequencing information.	Chunking is difficult in a flashcard system. However, the system does utilize categories that include category-relevant cards from which sets are to be built. ALso, cards allow for tags in the XML as metadata. The system can utilize these tags in session reporting to group cards into sub-categories which may be drafted by the user into new sets for practice.
Determining Prior Knowledge	1. Design determines learner’s prior knowledge and goals (e.g., pre-assessment, iterations of a Leitner system, etc.)	Any flashcard system can be deemed to assess prior knowledge through the first iteration of cards. In this case, a Leitner system is being used to track learning. Further, the system could be designed to encourage a full-set session on the first attempt of a set as a means of pre-assessing.
	2. Design facilitates open content (e.g., user-generated content, sharing of content and results, user-user or user-population comparisons of results, etc.)	Pre-built card sets and categories within the system will be CC licensed. Users will be encouraged to CC license their own cards, sets, and categories, and share those via the system’s community features.
	3. Design provides low prior-knowledge students with response-contingent feedback (e.g., system explains reasons for correct/incorrect responses)	This is designed into the back of cards’ feedback.
	4. Design provides high prior-knowledge students with topic-contingent feedback (e.g., system directs learners to find the correct response or a path to additional information).	Elaborative, topic-based feedback and material for exploration is provided either on demand or automatically for correct or certain answers.
Maximizing Academic Learning Time	1. Design ensures all instructional activities support desired learning outcomes.	Not specifically addressed in this system, except through capability of users to control their own card sets.
	2. Design ensures waiting and transitional time is minimized.	One of the key objectives is to provide practice sessions whenever and wherever the user desires, in lengths of time that fit any schedule. No lengthy wait time will be built in, and actual scripting of the system will be done to minimize processing time. Ideally, multimedia files uploaded for cards would be pre-processed by the system before storing on the server to convert file types and maximize compression.