Saturday, March 15, 2008

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: , , , ,

Saturday, December 15, 2007

security model

I was thinking about the security model for Flip the other day. As I have it currently, the security is maintained as a part of the file itself. But I need to re-examine whether the security should be part of the file itself, maintained separate from the file, or whether the user should be provided the option to decide where the login and password is maintained. Part of the consideration has to do with Leitner tracking.

Leitner tracking is a model whereby the memorization of a concept is quantified with boxes (or buckets to use a development term). Once a concept hits or exceeds a certain threshold, the concept is considered memorized. Answering the concept or card correctly advances the score for that concept towards the memorization threshold, while wrong answers decreases the score away from the threshold (or resets the score to zero altogether). More advanced models provide means to customize the incrementation and decrementing associated with correct and incorrect answers as well as set the thresholds for what is considered memorized. I still need to design the Leitner tracking system for Flip.

Maintaining the tracking file for each user has its advantages and its disadvantages for both inside the file and outside the file. If the file is maintained inside the file, then the Leitner tracking can be maintained as the file is moved from one computer to another, but the file size gets larger, quicker. If the file is maintained outside of the file, then the file size doesn't grow too large, too quick, but the tracking resides on one computer and you lose that tracking if you use the file on another PC. The best option is probably to maintain the tracking in an online repository so that the file size does not grow too large and the tracking can be accessed from one computer to another. This might even lend itself to online accounts individuals can create where their tracking, results, and analysis is maintained. The accounts could also have online communities dedicated to certain topics and offering online help in those areas of study. It wouldn't be necessary to use the application, but it might be an added benefit that some people would be willing to pay a little extra for.

I had to authenticate my computer for using SalesForce at home today. It finally dawned on me how useful that is to prevent hackers from stealing a password and using it from their computers. It's definitely a model worth following when I finally put together my company. I'll have to ensure that logins are people's email addresses the way SalesForce does. The more I think about the Software as a Service (SaaS) model, the more I like it.

Labels: , , , ,