The magic of thinking small
I highly recommend an old book by a Dr Schwartz called "The Magic of Thinking Big". It's a wonderful book that I recently had the opportunity to read again while I was away on a temporary assignment. While away on this assignment, I also had the opportunity to work with some wonderful individuals including one young man who was proficient with an iPhone.Over a dinner conversation where we were discussing application development, he mentioned how one person created a Bejeweled knock-off for the iPhone, sold it for $.99 a pop and made $250K in about 6 months. Not bad. He thought that perhaps developing my flashcard application for the iPhone might not be a bad strategy.Perhaps it wouldn't be. I have had reason to pause and contemplate - What is the one main selling feature of my application that sets it apart from all other flashcard applications? There are numerous things which set my application apart from others in its full glory, but when the application is pared down, there is one feature that distinguishes it from other flashcard applications - the ability to associate multiple responses with a cue. I've wondered if it was a distinction people would be willing to pay for. There is really only one way to know for sure, so my current efforts involve refining the application to a bare-bones version for the iPhone that provides the unique benefit of poly-sided cards. I know there are some distinct areas of studies that would definitely benefit from such an application. From there I can add features and build towards the ultimate application that I envision.Start small. Baby steps.Labels: flashcard application, flashcards, iPhone
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
