Claw Arcade Machines vs Obama
My sons are enamored with claw arcade machines. I myself have never really liked them. I think they are a waste of money, offering naive children 20 seconds of hope for $.50 - usually with nothing to show afterwords. But then I got wondering...how much does 20 seconds of hope cost under the Obama administration? I did the math. Per Google, there are 31,556,926 seconds in a year X 4 = 126,227,704. Divide that by 20 and you get 6,311,385.2. Divide that figure into the estimated $13 Trillion we'll be shelling out and those 20 second bursts of hope are costing us...$2,059,769.70Spending that kind of money, in 20 seconds my sons could simply buy a number of claw arcade machine routes loaded with toys and have a lot more to show for their expenditure with income producing assets stimulating the economy one naive child at a time - as opposed to pretending to stimulate the economy one naive nation at a time.Labels: arcade machines, Obama, politics
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
update
I haven't been updating my blog lately, but I have been working on the application. In fact, I have actually engaged a developer to put the application together. Initially, it will not be as robust as I would like the application. In fact, it will simply have the bare bones of requirements, but it will offer the user the ability to utilize multiple sides. Also, contrary to plans to develop a hybrid solution (which would require a lot of money to develop), I am going to develop the application as a strict online solution. Of course this means that I am redesigning the application to accommodate the online environment. Later, after the online application is established, I may develop a desktop version that can be used offline but if the online version does well enough, I may forego that. It's not the ideal version I envisioned, but it actually works out. I inquired with a couple superintendents about the demand for an application of this nature and whether it would be something a school system would use. Unfortunately, it is not something that school systems would be open to using, so the hybrid model which relied on monetizing through institutional demand wasn't going to work like I had anticipated. So I am back at the drawing board working to determine how I might monetize this with the understanding that students are my primary market.My wife was bemoaning not having the application to use for her nursing studies. Having the ability to validate multiple aspects individually, relative to a single cue, would come in very handy with her pharmacological studies where she has to know many aspects about each drug she is studying. Apparently, this application would be very handy for certain niches among students including nurses, some language students, humanities students, and probably many others. The key question is whether students would be willing to pay for the application. I guess we'll find out.Labels: flashcard application
requirements specification updated
It's been a little while and I have been a little lazy, but I have done some work on the requirements specification for Flip and re-uploaded the latest copy of the document. As always the latest versions of the documents can be found in the Flip Documents section (link on the side).
It's interesting (and tedious) working through the process of documenting all this. Just to give you an idea of how tedious it can get, check out this flow chart of the log in process. We're just logging in! How much is there to logging in? Well, a fair amount.
If the flowcharts can get this complicated with such simple processes, I am going to have to break up the application processes into many (many!) small processes. Time to get intimate with Visio. *sigh*Labels: documentation, Flip, flow chart, requirements specification
business requirements document complete!
I finally completed the business requirements document for Flip today. As usual, you can find the document by clicking on the Flip Documents link over on the sidebar. Now I am on to the requirements specification. After that there is a use case specification and then I will be seeking grants and donations to develop the application. Whew! So much work.Labels: business requirements, Flip
a numbers game
I updated the business requirements document today and added a section on tracking and reporting. This is a section that I have not given much thought until today. I am lucky that the company for whom I work is a software company whose application has a tracking section. Their tracking is for marketing purposes rather than drill and test scores, but it gave me some ideas how to better organize the data for presentation.
Still, as I thought through the prototypical numbers that would be presented, certain types of drilling and testing scenarios threw wrenches into what I thought would be clean and simple numbers. In particular, drilling scenarios where a user ran through a drill multiple times covering the same question multiple times posed a conundrum for how to calculate or present a user's numbers. Additionally, a single card with more than one cue side could potentially pose a question for each cue. In a German-English deck, there might be a card with the values "das Buch" and "the book". Each side could be presented as a cue. Each side could be expected as a response. The card could potentially pose two questions in a drill. How is that counted? How is it presented?
I had to think about it for a while, but I hit upon the idea of a tracking section which provided a list of drill/test sessions that had been run, providing basic information at that level to help identify the session - like the deck name, the drill/test name, the user, and the date/time it was started. Clicking on a session would provide the session's report with a header section that included the session's aggregate data and sub sections that provided detailed data specific to each iteration of the drill that the user ran. The header and the sub sections would have total numbers as well as numbers relative to unique instances of a question to help distinguish where questions might have been covered multiple times in a drill.
The numbers are sure to be confusing to users who may not understand the distinction between "total" counts vs. "unique" counts or why the distinction would be drawn, especially if their drills are relatively simple (only one cue per card) or they only allow one iteration per drill. I can't help users that refuse to read the online help (although I wish there were a way to force at least an attempt at it). I know tracking numbers for the marketing application I support are a constant source of confusion especially where users compare dynamic changing data with data that is static relative to a point in time. This might also be the case with tracking in Flip.
The presentation challenge also got me thinking about revamping the main interface to provide more convenient access to the common areas of the application (like tracking) by offering something similar to Microsoft Outlook's wonderbar. That's something to consider down the road.Labels: business requirements, interface, reporting, tracking, updates
