[Parley-devel] Features in next version of Parley

[Inge Wallin]

On Wednesday, August 27, 2014 12:31:20 Andreas Xavier wrote:
> Hello Anša,
> 
> Thanks for finding bugs and suggesting features on bugzilla.  It is very
> much appreciated.  I read all of the bug and feature suggestions.

Same here.  Most of them many times.

> I flagged the following bugs that you have commented on as being fixed
> or improved with the new library and file format that we are working on:
> 317994, 317993, 252482, 279512, 312955 and 244664.
> I see that you have mentioned some of them below and I will comment
> on them there.
> 
> You may want to follow or contribute to the discussion about the format
> which is happening on kde-edu at kde.org.

While the new file format is important for the continued development, it's much too early 
to mark any bugs as fixed because of it.  There is no actual code yet...

> >I like the option of BIDIRECTIONAL TESTING and specifying which is the
> >target language (although I still will have to come up with something
> >for tests in which both items are "target", like translating from one
> >foreign language into another, where there is the risk of not
> >understanding the first, or understanding but not knowing the answer
> >in the other).

Here I would like to stress a point that may not have been obvious outside our little 
development group: We have worked very hard to get rid of everything that reminds the 
user of tests. Instead, Parley is now 100% targetted at practice and especially learning.

So the word 'grade' is nowhere to be found anymore in the GUI. We struggled a little to find 
a good term and we had to settle on 'confidence level' instead. It's not ideal but at least it 
doesn't have the negative connotations of a low grade. After all, a low confidence level is a 
necessary step to a higher confidence level.

That said, we might reintroduce testing later but if so it will be well separated from the 
practice, which is the only usecase right now. (See below on 'pregrade' which you asked 
about.)


> >However, images should not be shown for the target
> >language when the target language is the Question in the bidirectional
> >testing, while it is fine to show images for the Question when the
> >Question is the Known language (again, if one of the two languages is
> >Known). The practice setup should distinguish between "Image for
> >Question" depending on the direction.
> 
> You are correct.  Please add this as a bug in bugzilla, so that it is not
> forgotten.

Yeah, bugs or misfeatures like this one should be fixed.  But that's more of fixing bugs than 
new features. :)

> One of the suggestions for the new file format is to split the training data
> into listening, reading, speaking, writing and translation results.  The
> first 4 types are from standardized language proficiency tests.  I think
> that those 5 types capture the behavior that you are talking about, being
> able to read the question, but not being able to write the answer in the
> second language.

Not sure what you mean with 'translation' here.  All of the other 4 variations are 
translations of different kind. What we have discussed is to generalise the confidence 
concept so that you can set separate confidences between the same words but using 
different training methods - recognizing a spoken word vs being able to write and spell it is 
a simple example.

> >Talking about the new format and related to my wish
> >https://bugs.kde.org/show_bug.cgi?id=279512: I wonder whether the
> >concept of lessons could be generalized to tags and subtags instead.
> >The tags would form a tree, and one part of that tree would normally
> >be the division into lessons, but with the possibility to have one
> >word in several lessons. I noticed in the TODO list in the repo that
> >you mention thaipod101.com. I've been using finnishpod101 and
> >hebrewpod101 from the same company, and I noticed that you can also
> >look up the list of lessons that a word belongs to. This is hard to
> >achieve with a linear lesson structure, but easy to achieve with a
> >tag-like structure. Moreover, it would make it super-easy to select
> >for practice, lets say, just verbs describing animal behaviours from
> >lessons 1-10 (select tag "word", which is a subtag of "part of
> >speech"; tags "Lesson 1"... "Lesson 10"; and the tag "Animal" which
> >are subtag of "Topic"). Obviously, there would need to be further
> >specification of attributes that items with certain tags may have
> >(certain tags imply inflection) and maybe even some uniform ways of
> >treating words with a certain tag (like showing the subtags of the
> >"style" tag during practice so that the learner is reminded that a
> >word may not be appropriate in all contexts).
> 
> Some of these issues are handled in the new language file format.
> The words will be stand alone so they can be included in multiple lessons,
> or multiple times per lesson.

Actually, the current format kvtml2 supports this too. It's just that Parley and the editor 
weren't implemented that way. I don't know exactly why but that's the way it is. The file 
format itself supports it.  

Basically the file starts with a header, then there is a list of words with numeric ID's. Then 
there is a set of lessons (which we now call 'units' to be consistent within all of kde edu) 
which only refers to the word ID's. There is nothing in the format that prevents several 
lessons to refer to the same ID.

But this is not visible in the editor. So to make it possible in the UI to specify refer to the 
same word in several lessons is something we need to design.  Tags is one way; there may 
be other, better ones.

> Also part of the proposal is to have sets of words, like pronouns, verbs,
> nouns, fruits, animals, breeds of dogs etc.  And secondly to use
> relationships between sets to create a more generic, less rigid grammar
> structure.  For example fruits are nouns. Pronouns,  verbs and tense make
> conjugates.  Dogs are animals, animals are nouns. etc. You would be able to
> filter lessons with the sets of words.

Hmm, this is actually news to me.  At least it was not part of the original proposal. :)  We 
are currently in the process of collecting requirements. I like flexibility but I am wary of 
overengineering. We need to make it easy to handle the common case even if it would 
ultimately limit the flexibility a little.

> I think that this is almost what you are suggesting.  I think that you are
> also suggesting a non-linear lesson plan, perhaps a rooted tree based on
> the pronouns and key verbs and then branching to support the student's
> needs. The idea is possible.  It meshes well with language's behavior.  It
> will require some clever and elegant editor GUI design.

Indeed. I'd like to have some input from people who understand interaction design here. 
It's easy to go wild with features and then end up with something nobody but the original 
programmer can use.

> >SPACED REPETITION setup:
> >The TODO list also mentions "pregrades" (what are they?) and the need
> >for greater amount of practice on level 1.
> 
> Pregrades are currently 6 Leitner levels below the first visible one
> in the user interface.  They have testing intervals from 3.5 minutes
> up to 8 hours.  Inge implemented them.

Yeah...  The original Leitner system had an interval of 1 day until next time training a word 
once you got it right the first time.  That was much too long so you forgot almost every 
word until it was time to train it again.

So to fix this problem we implemented an 'initial phase' of the training which is loosely 
mapped to the phase where you are learning the word but doesn't really know it yet. The 
old Leitner system is then used in the 'long-term learning phase' to reinforce it once you 
have learnt it to begin with. You can see this in the upper right corner while practicing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-edu/attachments/20140828/f9babb09/attachment-0001.html>