UI support for N-sided card types (30 work units)
Under the hood, libmnemosyne already supports this, but currently, there is no UI support.
This will enable card types with a arbitrary number of fields, and with an aribtrary number of sister cards.
Support will also be added for custum CSS and custom standard text on each of the cards.
Anki import is now implemented.
-
Anki import is live now in Mnemosyne 2.6.
-
I'm currently working on Anki import, which will include an option to edit and modify the card type templates of the Anki card types.
However, creating an M-sided card type from scratch outside of Anki will not yet be for the next version.
-
Bruce commented
What is the status of this feature??
In my very modest opinion it is a real must, I cannot even think of an application like mnemosyne without this capability.Every 'fact' must have an arbitrary number of fields, no reason for it to be otherwise (e.g. a chinese character (the fact) has several properties: pinyin, pronunciation, stroke information, meaning (!), common sentences, etc. etc.)
There is also no reason why the question/answer model (the 'card') should be limited to a fixed number of fields in the question and answer. The user should be able to define his/her own card type and thus design diverse memory exercises: e.g.:
- character -> meaning
- character, common sentences -> meaning
- pronunciation -> character
- etc. etc.This said, thanks for the great work!
-
David Foster commented
I'll second the request of Anonymous (Jan 14, 2013): I would like to be able to customize the fields that Vocabulary cards end up displaying in the UI. -- More context on my use case: https://groups.google.com/forum/?fromgroups#!topic/mnemosyne-proj-users/4qGPvEgIzvc
-
Hi Victoria,
Thanks for the kind words! Rest assured, if this feature is implemented, it will be in the Mnemosyne style and not in the Anki style. It also will not require any additional complexity in the database, as the backend is already flexible enough to support this (and is in some ways even more flexible than Anki). This is just about the UI part of things, and it will be a plugin which is disabled by default.
Peter
-
Victoria commented
As others have, I think, pointed out, this sounds rather like the functionality of Anki.
As an Anki user of six years, I've just switched to Mnemosyne since the most recent major Anki upgrade has been rolled out so clumsily it's left me unable to upgrade and (since the server was deactivated for my version) unable to work on flashcards anywhere other than my home PC.
The ability to configure such a complex deck was, at times, useful, but I don't miss it half as much as I'd anticipated. Instead I've just kept my vocabulary data exported from Anki (with Japanese Kanji, Kana and meaning values) in a spreadsheet, which I then use formulas with to construct the card "front and back" for the different pairs I want, and import into Mnemosyne.
The interface and structure of Mnemosyne is refreshingly straightforward and transparent, and i can see clearly what's going on with my cards (where with Anki I'd ended up having to put a lot of faith in the system and scheduling algorithm, which I'm not sure was well placed).
The other impact in Anki is that the database has become far more complicated, and I think this has caused a lot of work for the developers in terms of keeping the software stable and allowing the efficient use of large decks. It's taken them in a direction that has lead me personally to walk away from using the software after a very long time. Having just found Mnemosyne, it would be a shame to see it head in the same direction.
-
All of what you describe is indeed planned in this feature.
-
Anonymous commented
How would this interact with the already existing features of Mnemosyne? There is already the "Vocabulary" card type, which is good, but can be troublesome sometimes. I would like, for instance, that
* given the word in its written form, Mnemosyne tested me on its meaning only (and vice-versa)
* given the word in its written form, Mnemosyne tested me on its pronunciation only (and vice-versa)
* given the word in its written form, Mnemosyne tested me on its notes only, where I often put examples of the word's usage (but NOT vice-versa)
* Mnemosyned SHOULDN'T show me the word's notes and ask me for its pronunciation (and vice-versa)As it is, Mnemosyne tests more than one of those at the same time, which really slows me down. I (and I believe, most of us) like our cards to have as little info as possible, testing one thing at a time (pronunciation/writing, writing/meaning, writing/notes...). Maybe it could show me more than one of those in the answer field - as long as it *tested for each of this, separately. It's complicated for me to grade a card in which I successfully remembered a part, but not all of it. It seems like those N-sided cards could be a solution. Or have I misinterpreted it?
When/if this feature is implemented, would this customizable? (i.e. testing from one field to the other, and vice-versa, but NOT between all the fields/directions?)
Also, it would be nice to have a option (perhaps a plugin) to convert all our current "vocabulary type" cards to those specific, simple pairs of answer/questions (again, keeping - or else, many of us would have to manually redo each one of our old vocab cards to enjoy this new feature.
-
Pharmtech commented
Peter, I agree with you. But, if Mnemosyne's UI presents things like templates, it leads to "fields." And then, "how to refer to a collection of fields." And, "a collection of templates." I think "fact" and "model" make sense. But, more importantly, there will inevitably be terminology to describe what is essentially a data model or schema.
I don't think such a *logical* naming convention fits well with physical "cards." IMO, cards become a "view" to the logical. A fact can have many views (constructed through templates, contained within the "model" along with the "fields" of that model.).
I think applying physical (card-oriented) terms to the logical view blurs the relationship between cards and the underlying logical relationship which could never be represented by cards. (For example, the term "note" to describe what is a "fact" isn't very intuitive. Maybe it's just me.).
I'm probably rambling. My main point is that I think it will be inevitable for more complex descriptions to be used in the UI (if things like templates become mainstream). If so, the descriptions should be chosen carefully.
-
I think Anki's terminology is overly complex and not really needed to achieve this functionality. E.g. under the hood, libmnemosyne already has a Fact class, but the word 'fact' is never mentioned in the UI, and I don't think anyone misses it :-)
-
Justin commented
With this we could add one root verb, in Spanish for instance, and the amount of styling and card creation with per tense/case conjugation would be something like 102 cards/conjugations with text per master card. Very impressive. This feature is already implemented in Anki (http://ankisrs.net/docs/manual.html#_models).
On a related note, I think we should clarify our vocabulary for describing "cards". I suggest we base our vocabulary off of Anki's vocabulary: a deck is a file on your computer which contains cards, a card is a question and answer pair (what we see when learning), facts are a collection of related information which is then used to create cards (what we see when editing a cloze deletion card but not when tested for one particular cloze deletion), a template is the styling, standard text added (like 'ar' 'o'), and fields (user added variables such as Spanish verb root name) added, and a model is a list of templates with fields to store in a fact.
Also, an example of a field includes the questioned components of each particular cloze deletion question (each part in square brackets "[]"). So a model can be thought of as a collection of styled cloze deletion questions where the non-cloze portion of the question is stored as part of the template rather than being re-created each time a new fact is added.
To clarify: there are 1 or more cards per fact (a simple example is a front-back and back-front card pair created form one fact), and there are one or more templates and 1 or more cards per model. Each template produces one and only one card.
Example:
Model:
>Field 1: English word
>> example field: swim
>Field 2: Spanish word
>> example field: nad
>Field 3:Spanish pronunciation
>Template 1 Q: Translate "to {English word}" into Spanish
>Template 1 A:{Spanish word}ar
>Template 2 Q:Translate "I {English word} into Spanish
>Template 2 Q:[Spanish word}o
>Template 3 Q:Translate "you (informal) {English word} into Spanish.
>Template 3 Q:{Spanish word}asIn this way two fields could be input and three cards would be output using this model for studying regular Spanish "ar" verb roots:
field one: swim
field two: nadwould produce:
Q:Translate "to swim" into Spanish
A:nadar
Q:Translate "I swim" into Spanish
A:nado
Q:Translate "you (informal) swim" into Spanish
A:nadasAbout half of all Spanish verbs could be added in this programmatic way causing users to have an incredible savings in time spent adding cards and this is just an example from one language. There are likely uses for other subject matter beside languages.
-
Pharmtech commented
If I understand correctly, this would be like a "template." Layout (markup, styling, scripting) would be defined in one place instead of every card. Mnemosyne fields would be referred to as replaceable variables. Is this correct?
If so, I think it would be useful. Right now, there are two downsides to using HTML markup. 1) It's put in every card. If I want to modify the markup I have to edit every card. That wouldn't be too bad if I could export and import (do mass changes outside, using regular expressions so it's like a single operation). 2) The markup displays in the card browser.
So, if it were a "template" it would be a layer of abstraction. The card browser wouldn't have to know anything about the markup.
That opens up some other issues. Like, how the card browser will operate on "fields" instead of actual cards. The order in which fields are defined will affect the legibility of the card browser's display. That or, fields will require an attribute defining the order in which they should be displayed in the card browser. Or, the card browser will need configurable columns to choose which fields to display, in which order. But, displaying "cards" probably isn't the best choice because markup (tables) and styling (positioning) may alter the visual relationship of fields (relative to their physical order which the browser would operate on, but may not be the most meaningful display).
For that last point: if it were me, I would display in the browser the fields in the order they are defined (giving the user an option in the "field definition" dialogue to "move up" and "down" the order of defined fields). I think that would make the browser the most coherent, giving the user adequate control. If it turns out that's not enough control, I think the browser would need configurable columns (which fields to display, in which order.).
My point is: I think I would anticipate this and not have the browser display the card face (constants, order of fields as defined on the "template" which may not be relevant to importance of fields due to styling which alters the "visual" importance when the card is rendered).