Two weeks later.
I’ve finished putting together the Anki-like database structure. Logic and inevitability have finally led us to this point. But as I survey the broken, charred landscape, the twisted burning metal that is the vcard code, I can only sit back in amazement and declare, “Anki is a horrible bloated peice of crap and I hate it.”
Of course, for all you Anki users out there, I don’t mean the UI. That’s the problem with the Anki fanboys I’ve run into over the years. They have fallen in love with the UI and don’t understand how it is all put together. And to be fair, it’s probably been refactored a few times from a first shot approach. But there’s just no way I can see a use case for all this junk.
A failed user experience
First you have to define a deck, a note type, and a card template — all of which is actually done for you at start, otherwise I suspect Anki would lose 90% of it’s users. We’ve already hit the first problem.
If there is a default deck and a default note type and a default card, what Anki is saying is that this is sufficient for most of it’s users.
It’s also enticing people not to go any farther. It’s basically saying that Anki doesn’t understand it’s own role or function. Yes, it is highly configurable, and most Anki decks look roughly the same.
The second thing is that in order to use Anki beyond this functionality you start to go down a rabbit hole of functions and features. Merging note types, knowing HTML for card templates, and so forth. Most users really don’t care, they really don’t.
Because in Anki, you can memorize world flags! Or the first few bars of your favorite blues songs! Oh my. That is completely useless, isn’t it? I mean for most people interested in a SRS flashcard app. If any more than 1% of Anki’s users use it for anything else other than studying Japanese (or whatever) I would be shocked out of my skin. And that’s another issue. The program isn’t used at all in places like Taiwan, it’s basically an English program only (I am sure some Taiwanese use it, I am just saying it’s rare and I know it is because I am here).
The Middle Ground
The big problem I made, I think, is going from building a deck based on dictionary entries to going full on Anki-style. Both extremes are not going to work for a better and more general use case. It seems that ultimately, having decks is okay, but any abstraction of card is going to be wrong. It would seem that each deck can have it’s own display code attached to it after all — this solves the vcarc abstraction problem — instead of vcards you just have a deck with cards, and if you want another card template you can always clone the deck and edit it’s template (and have NO difference in terms of data size) — the only difference seemingly in that things are better organized.
I Defiantly Ask
What possible use case is there that is aligned with language instruction which is not satisfied with “decks” of “cards” simply put? Why do we need multiple card types versus multiple decks? It’s a matter of conceptualization, organization, fielding, column names, array keys, pidgeonholing, arrangement, data structuring, isn’t it? Isn’t the real use case much simpler, and can be streamlined, right?