Kongzi Desktop had always been different from programs like Anki in that it had a central “dictionary” from which the system hard-coded different kinds of flashcards and games, and kept track of user stats.

Part of the reason is that all this mucking about with decks and notes and virtual cards is not viable in a classroom setting. Students don’t care, they just want to learn exactly what the teacher tells them to learn. And from the teacher’s standpoint editing 30 or 40 decks per class simply takes too much time. Kongzi was always supposed to target a different audience, an audience that did not care about graduating intervals, “ease”, leach thresholds and so forth. An audience that just wanted to learn a language. You see, it is very clear to me that what people need when learning a language is not endless stale flashcards but a kick in the pants to pick up readers as soon as possible. To help them remember a few new words for sentence practice. To give the teacher an idea of where the student was in his learning journey,

The initial attempts (Kongzi Desktop) were fine and every group of students I worked with asked for the program. But every time I began to work on the dictionary aspect of the system I realized that the idea of deriving flashcards from dictionary data was horribly flawed. A dictionary aims to be a complete source of knowledge, with history, examples, and so forth. A flashcard system which just wants to convey a quick impression of the meaning of a few hundred words and then move on to readers. It’s a different set of data, and users only access the system to see one side and not the other at a time.

So invariably when I tried to reframe the flashcard system independently from the dictionary, I would build the flashcard schema, build the dictionary schema, build the learning schema (separate from cards, since this was a shared system intended for teachers in a classroom setting), put the field and template code in the deck table, and start coding the interface. The idea was to have a system set of cards but still allow the user the freedom to make decks and choose their own way of displaying the cards. However there was always a problem, the code would become intensely convoluted. For me this is a problem because I never start coding until I get a complete picture of the code in my head (this is a safeguard against black holes of spaghetti bullshit) and for years I didn’t know why it would get so convoluted until I had a flash of insight, a breakthrough, an epiphany.

Before just blurting it out here is what I was meditating on when it hit me. I had just written the following line of code:

$vcards[$k]['sortby'] = $note_data_exp[$card['data_id']][$note_types[$card['note_id']['sortby']]];

I knew something was wrong. A line of code like that does not exist in my style. I started meditating.

We don’t need decks or cards because the system uses a dictionary entry to construct a set display of information.

We don’t need decks or cards because the system uses a dictionary entry to construct a set display of information.

We don’t need decks or cards because the system uses a dictionary entry to construct a set display of information.

Suddenly it all made sense. The card template didn’t belong in the DECK TABLE. It was supposed to be a part of the CARD TYPE itself! You see? The system cards, which were the kinds of cards the system used to track your knowledge of a language, were like a card type, and the way it was displayed was just like a card template. But looked at another way this is like saying the card template was naturally attached to the type of card being used, the system cards — and not the deck — or in this case, the deck which was not a deck (cards not in a deck)!

I realized that we didn’t need to have two separate systems. Just create a card type, and then decks can have cards of any type in them and the template for their display is attached to their card type. Then card types can define what various games and quiz/test types show while still allowing full user control and system monitoring of how much the user ‘knows’ compared to the dictionary data.

I know this is the real and true way because it reduces the complex task of programming the whole KZO system into a simple CRUD interface. I’m so excited about this I can hardly speak. I expect the basic interface to be done within a week and a day, and as the study flashcard section is already written and operational the site should be finally usable in HTML mode.

The next step is going to be to rewrite Kongzi Desktop to work with the online system (signups). This will finally allow me to have central control of who uses the software (which is why I never released the desktop version — software piracy) and create a procedure for remote access of the KZO database. Then Android and iOS apps will follow.

I finally see a clear path to basic functionality that FEELS RIGHT. This is so important to me as a hobbyist coder. Will update when available.

By Serena

Leave a Reply

Your email address will not be published. Required fields are marked *