For information on the .cstack file format see the CStackFileFormat.txt document.


Quizes

Quiz types - currently there are three quiz types: multiple choice, spelling, and flashcard. There is no grand scheme to which quiz types should be available. They function independent of each other, and have been added on an as desired basis. Use the one that suits you is the idea. It's easy to add more quiz types as necessary.

Quiz methods - currently, I envision two: a practice quiz and a quiz. Quiz methods determine the flow and evaluation of a given quiz type. Any quiz type should be able to be used with any quiz method. Adding quiz methods is not trivial, like adding quiz types. In the least the generic quiz class, and all subclasses would have to be modified. Further modifications to the StackModel and/or Scheduler class could be necessay, as well as changes to the interface. This all depends on the nature of the method.  


QuizManager, QuizController, [xxxxxx]QuizController

The QuizManager is a class that will begin quizes of a specified type and method. The main reason for it is to remove beginQuiz related clutter in the PopupController and EditorWindowController classes. The idea is for the the Quiz manager to offer a beginQuizOfType: usingMethod: method for use from the PopupController class. (or maybe beginQuizOfType: and beginPracticeQuizOfType:) and take care of instantiatiating the correct quiz subclasses with the right arguments.

The QuizController class is an abstract quiz. It's not a usable quiz, but serves as a container for the common code in all quiz types. This consists of the flow of the quiz. ie draw a card, display, evalute the result, clean up after the quiz. 

This sort of thing should likely be the same for all quiz types, and if a situation arises where this is not the case, then the quiz can either choose not to be a subclass of QuizController, or to override its init method and do entirely different things from that point on (while still gaining the benefit of other methods in QuizController, if need be). As an example, imagine some sort of 'puzzle matching game' quiz where all cards are displayed at once. (Note: I don't think thats a particularly useful quiz, but it might be fun for kids)

The [xxxxxx]QuizController classes are subclasses of QuizController. Currently there are three: CardQuizController, ChoiceQuizController, and SpellingQuizController. These classes contain all the code specific to the specific quiz types. ie. how the card is displayed, and how the result is evaluated.

The various quiz method functionalities touch both, the QuizController and [xxxxxx]QuizController classes. Primarily for this reason I think its a good idea to move the achievement related methods to the QuizController class. These methods will likely grow in number and/or complexity (dependent on quiz methods) and it would be better to not drag the StackModel class into the mess,
The minor drawback of this, is that the scheduler doesn't have instant, easy access to this information via the cardstack. So, this information will likely have to be passed via arguments to the processCards method.

I'd like to think of the StackModel class as a model of a stack concerned primarily with managing that stack, but with some hooks for quizing (drawCard, drawAlternatives). Rather than a quiz engine. having said that, it made me think that maybe we can move all the quizing machinery into QuizController. Any thoughts on that?


The schedule and the Scheduler

The Scheduler class needn't be a seperate class. It's really part of the stack. I've made it a seperate class now, because of a couple benefits: 1) The StackModel is relatively large. It keeps the code a little more manageable to split off the Scheduler in its own class. 2) It allows the possibility of easily having non-scheduled stacks.

The second point brings up some user user interface questions. If we have a non-scheduled stack do we use the old style Popup interface, and only once a card has been put into time zero, bring in all the scheduling machinery? Do you alter the menu to not include an schudle related functions as well, and only offer a 'Schedule stack' item. I think this is probably not a good idea. But a thought anyways.

I have some unanswered/undecided questions about the schedule itself as well. Currently, There is no configurability to the schedule. it resides in a property list in the app wrapper, and when a stack is instantiatied, it loads the scedule from there and uses it. The schedule is also stored in the cstack file, so that in the future, if one could edit the schedule, it would stay with the card stack. 

On one hand, if you say: 'no schedule editing' then we can leave everything like it is, and remove the schedule from the cstack file as well. On the other, if you want to edit the schedules (I think this is generally a good thing), you have some questions of when and how. in the Preferences panel you can put an NSTableView with the Schedule in it, for editing. Any modifications either get put in the user defaults or, stored in the app wrapper. I'd rather the latter, but don't think its possible under GNUstep. 

Then when a stack is created, do you pop up a windows saying this is your schedule (generated off of the default, or whatever you have set in the preferences). and allow the person to make sure thats what they want, or do you wait until they add a card to time zero/turn a stack into a scheduled stack, to pop up this window. and then once you have a schedule applied to a stack, do you allow it to be edited, and how do you handle this? modifying any already scheduled quiz times to fit the new schedule? lots of questions there. I lean towards having the preferences functionality, not having a second opportunity to modify it, and not allowing editing of the schedule of an already scheduled stack, and furthermore having all stacks scheduled by default. ie when creating a new file, always create the schedule. don't wait for the person to actually start using it. and when openinig a file with no stack, create the schedule just the same. But I'm not too sure if thats too much flexability, or too little, or if I've not thought of something I should, etc.


Prefernces

I think the Sound preference should stay in the menu where its at now. But we do have some things to go in a Preferences panel, now too. A list

The schedule editor - see the schedule section

default quiz, and default practice quiz - there is now a button in the editor to quiz and one to practice. They start a quiz or practice quiz of the default type that you have selected. As a consequence there are also default quiz and default practice quiz menu items, although its only there because of the button. Isn't there some ui guideline that says *everything* should be accessable through the menu. I think it clutters the menu.

repetitions for the practice quiz - by default 3, but user selectable

I figure a tab view with two tabs: Quiz and Schedule. should be obvious which preferences go where.


The Editor

The editor is much the same as the old Popup: A NSTableView on top of a NSTextView, encased in an NSSplitView. One for cards and the other for notes. It has the addition of an NSOutline placed to the left of the table, the full length of the window. It is encased in NSSplitView along with the NSTableView/NSTextView splitview. There are also additional buttons on the top left, and the same search field and status message on the top right. There are three more ui elemnts that I have in mind, but I can't figure out where to put them.

The NSOutlineView always has at least one item: an item named 'Cards'. All the cards in the stack are visible in the NSTableView when it is selected. The second, third, fourth, etc items are slots in the schedule. ie 'Time Zero', 'Five Minutes', 'Twenty-Five Minutes', etc. These items are expandable (except for Time Zero). Second level items are the individual quiz times, for the quizes in each slot. Selecting The slot and time items, will display all the cards for that slot or time in the NSTableView.

There are six buttons along the top: Quiz, Practice, Add Entry, Delete Entry, Add to schedule, and Remove from schedule. I'd like for there to be no text and only images on the buttons.

Quiz and Practice are buttons that will begin a quiz or a practice quiz of the default selected type. I have no ideas about icons for these at this point.

add and delete entry will add or delete an entry from the card stack. This is only possible to do the Cards entry in the NSOutlineView is selected. So, either these get disabled when viewing scheduled cards, or when this button is pressed, we change the NSOutlineView selection before doing anything. I think the latter is a better idea. I have icons for these: a card with a blue plus and minus sign superimposed on it.

Add to Schedule and remove from schedule move a card to time zero and remove a card from any scheduled quizes, respectivly. Add do schedule would need to be disable at all time except when Cards is selected in the NSOutlineView. I usually use the shortcut keys to add a card to the schedule, but I think for completeness sake, its good to have this button here.

Add Entry, Delete Entry, and Add To schedule are all only usable, when you are viewing the whole cardsstack. this is the reason for the modality in the Pimzler interface. It switches between two different views, because the two views have different functionality. I'd rather get rid of this modality. Having said that, there is another control which is only useful when viewing the whole cardstack: A drop down box that allows you to filter the card stack by 'all cards', 'schuduled/unscheduled cards', and 'learned/unlearned cards'. 'learned in this case means a card that has made its way through the entire schedule, and been spit out the other end. I haven't found a good place to put this, and have thought about only making it visible when cards is selected in the NSOutlineView.

I would like to, by way of text/background color. or an extra column with colored flags, denote if a card is learned/unlearned/sheduled, etc. perhaps when all cards are being viewed, sort automatically by these attributes, so that only non-scheduled cards appear at the top. Or, don't sort automatically, but allow one to sort by clicking on the 'flag' column header, or either of the word column headers. Or, do both.

How to handle search? When searching do you search in the entire cardstack, or just the displayed cards. Do you highlight words only in the 'Cards' view, or also in each scheduled slot they appear? I'd like to keep the search interface simple like it is now. The easy thing to do is to have the search only and always apply to 'all cards' and highlight results only in the Cards view.

It should be noted that all this filtering/sorting/highlighting doesn't ever touch the actual card stack, nor does the actual card stack ever get displayed in the NSTableView. It's all done through a proxy array, thats filled with indexes of the actual cardstack.


Card Inspector and Statistics

When using the 'quizes' (not practice quizes), a performance history for each card will be stored in the card's entry in the card stack. This will include just a date stamp and a result (Pass/Fail). This allows for the program to have a card inspector, that will tell you when this card will next be quized, and what your prior perfomance has been with it: listing dates, and pass/fail results. As well as a percentage.

This also allows you to keep statistics for a given stack of cards. but again only for the quizes, not for practicing. I haven't given much thought to the statistics, But the ability is there.


Other things

It currently seems to have horrible memory problems. Shared memory is about 41m. It doesn't grow abnormally when opening/using files, so I don't think its a memory leak, necessarily. But, something doesn't seem right. I'm wondering if the NSNumber class is more memory consuptive than I realize, as I use NSNumbers alot throughout (in the several hundred range)




 