flashcards at their most basic level
Over the years as I've designed my application, I have really disliked the term "flashcard" because of the limitations and constraints that the term conveys. A flashcard is typically a piece a cardstock (like an index card) with a prompt on one side and an associated response on the other. The simple beauty of the flashcard is that while you contemplate the prompt, or more appropriately, what the response to the prompt is, the response remains hidden from view. Once you have decided on the response you can validate your answer by flipping the card to reveal the response written on the other side. Simple. Effective. But limited.Occasionally, the answer to a prompt escapes the student, but it is on the tip of their tongue, so they peek at the other side and proclaim to themselves, "I knew that!". Good enough. On to the next card, confident that the detail they just studied was learned. Except it really wasn't. Faced with a similar question in a real test, the student proclaims, "I know this!" and then struggles to nudge the tidbit they thought they knew off the tip of their tongue - to no avail. The student in practice incorrectly validated information that was not learned, giving themselves a false sense of security in what they knew.
Sometimes, the student needs to learn multiple aspects relative to a prompt. Limited to two sides, the student adds each aspect to the response side and relies on not peeking at response #2-n while they are validating response #1.
I'd like to think that when I came up with the idea in '93 to create a flashcard application (yes, I have been at it THAT long), that I was original in my idea. I'm not. Other besides me have realized the organizational and randomizing benefits that a computer could bring to flashcards. Those that developed their version of flashcard software exploited the advantages computers offered to organize cards, randomize them, and offer cheat resistant validation.
If you break down a flashcard and its use to its basic elements, it boils down to a few things:
An author creates a deck of flash cards.
A user (it may even be the author) utilizes the deck of flashcards to study a topic.
A deck is a collection of cards.
A card is a prompt (the revealed side of a card) and its associated response(s) (the hidden side of a card).
Each prompt is associated with at least one response.
There is a breakdown though between the real world and the virtual world on the computer. A card in the virtual world is not limited by two sides. It can flip as many times as it needs, prompting for a uniquely associated response that requires individual validation with each flip.
If a user is prompted with a picture of the Mona Lisa, what is the response? It depends on the aspect of the Mona Lisa for which you are testing. If you are prompting for the name, the response should be "Mona Lisa". If you are prompting for the artist, the answer is "Leonardo di Vinci". If you are prompting for the style, the response might be "Classical". And so on and so on.
In the real world, this requires three cards, each with a picture of the Mona Lisa on the prompt side and a single response on the other, since you are limited to only two sides per card. And unless there was an additional prompt besides Mona's mug as to what response was being expected by the other side, the user would additionally require a unique deck to better know what associated aspect was being tested. The big problem is that Mona's mug should have appeared one time and one time only while the user was prompted for the name, the artist and the style, as should be the case when the next 50 pieces of art are tested. All these aspects could be presented on a response side together, but then they are validated together as well. What if you know two of the three aspects? You lose the value of validation if each aspect is not individually validated separate from the others and yet so many flashcard applications are constrained by the 2-sided limits of the real world. This shouldn't be.
How should it be? Each side should have a name that identifies the content it is exposing (where that side is being used as a prompt) or validating (where that side is utilized as a response). It could be Question/Answer, German/English, Art/Name/Artist/Style/Value, Drug/Common Name/Interactions/Contraindications, or simply Side1/Side2 (if that works for you). The name should indicate what is being exposed or what is being expected for that side. If German/English doesn't work for you, then "What is the German equivalent of the English exposed?"/"What is the English equivalent of the German exposed?" should also work as names. I prefer the succinct German/English side names, but to each their own. Generally, the cards in a deck are testing the same aspects for a list of related items. Enter the aspect names once and fill out the deck with the appropriate associated values to create a drill or test. Why make it any tougher than that?
If you flatten it out, think of a deck as a table. The header row is your side names, the rows are your cards and the columns are your individual sides. Each cell is the value for that side for that card. With the deck virtualized, sides can be randomized, cards can be randomized, cards can be organized into drills/tests and so much more. Essentially, the application serves up prompts (or cues as I prefer to call them) and awaits user responses to validate. Essentially, the application is a cue/response processor. At its heart, it is still a flashcard, but in reality, it is so much more.
Labels: flashcard application, flashcards, organization
posted by bylaw @ 10:12 AM
0 comments
