The Back button in the Learn dialogue

[bkzk7188]

In the PC version the back button is always greyed out, and in PocketStackz it doesn't work as it should. Instead of acting like an undo button, it puts the current word in the list to the left, thus making it unable to declare is as known.

[Chris]

I'm not sure if i understand your concern correctly.

1) There is an undo button, which will undo your last classification.
2) The arrow-up button has the function "put back on same stack".
3) The arrow-left button has the function "declare as unknown".

There is no "back" button that should act like an undo button... I guess you are referring to the arrow-left button, which seems to work exactly as described in the manual.

[bkzk7188]

I'm referring to the button with the blue arrow. Try clicking on it in the Learn dialogue and you will see that it declares the current entry as unknown.

[Chris]

Yes, that's the intention of an undo button - but only if you pressed "declare as known" before.

[bkzk7188]

I'll try to explain it once again.

Entry A is displayed, numbered as #13 on the list to the left.

I press the left button - the one with the red cross - and what happens is that entry A is removed and entry B shows up in its place, numbered as #13.

Up until now everything has worked as it should. However, if I for some reason would change my mind and press the undo button - the one with a blue arrow - the following two things happen:

1) Entry B is declared as unknown, and stays at #13.
2) Entry A is brought back, as entry #14.

This makes me unable to mark entry B as known, since the right button - the one with the green mark - is greyed out.

[James]

Yes, I share the same concern -

The problem occurs when using the undo button in a learn dialogue that has not been completely initialized.?
In such a case the undo button undoes the last classification and brings that entry back to the local stack. 

When this happens, if the local stack has not reached its max size (ie not completely initialized), the entry is ADDED to the local stack rather than replacing the entry that followed it.   The result is that the local stack increases in size by one, and the user has no opportunity to correctly classifty the second-last entry as "known".

This is a really challenging problem to explain. 

Basically if you put 5 or so cards in the local stack (assuming your max setting is 10 ) and try playing around with the undo button, you'll soon see what we mean.

Cheers. 

[Chris]

Ah NOW I see what you mean!? Sorry for the misinterpretation.

The undo action takes the focus away from the entry that was inserted during the erroneous declaration action.
This lost focus turns it to a "not allowed to declare as known" state!

Detail description:
On PocketStackz, after an erroneous declaration, the undo action adds the previously declared entry ("A") back to the local stack, without removing the entry that replaced it during the erroneous declaration ("B"). After the undo action, "A" is selected in the list and its attributes are displayed. When the new entry "B" then is selected, the "declare as known" button is disabled for this entry because it is selected for the second time now, and "declare as known" is only permitted at the first selection to avoid positive declarations out of an iterative learning session.

We will try to find a solution to this problem.

In the meantime, the entries that are added before an undo action can't be declared as known in a learning session indeed. They are best put back on the same stack instead, which does not alter their statistics. Note that another session can be started directly afterwards to catch up on classifying the missed entries, a test session would be more appropriate than a learn session in this case.

[Chris]

1) Entry B is declared as unknown, and stays at #13.

To "declare as unknown" means "re-classify the entry by moving it to a different stack on the left".
If an entry is declared as unknown, it leaves the learn dialog.

An entry can't be declared as unknown and stay in the dialog in the same time. According to my previous post, you probably mean "Entry B stays at #13 and is not allowed to be declared as known anymore".

[Konstantin]

I'll try to explain it once again.

It was really hard to understand the problem.
I hope now we have a solution.
I've made a bug-fix release and put it to the server.
You can find it here:
http://www.stackz.com/Stackz/ppc/ppc.htm#Download

Could you please check whether it really fixes the problem you meant?

Thanks,
Konstantin

[James]

Sorry my ppc has died    and I am unable to test. 

Anyway the issue I was describing occurs in the learn dialogue in the desktop version. 

It sounded like the same problem as the person who started this thread but perhaps it isn't 

[Chris]

When this happens, if the local stack has not reached its max size (ie not completely initialized), the entry is ADDED to the local stack rather than replacing the entry that followed it.

This was the behavior on PocketStackz, but I can't duplicate that behavior on the PC. Using the undo button with Stackz 2006 Dictionary Edition does not add the entry to the local stack, it replaces the last inserted one... anybody else experiencing the same issue as James?

[James]

Sorry I was getting ahead of myself when I said the problem was also occuring on the desktop version.   I think I was confusing my ppc with my desktop.  I cannot duplicate the error on my desktop by following the same steps.

It could be that I added another card (down arrow) to the initial stack immediately after making an erroneous declaration and without reviewing the card that replaced it. 

In this instance the "declare as known" button would be disabled even though I had yet tested myself on that card.  (thus giving me the same feeling of frustration I had with the error on my ppc)

My point is that the "declare as known" button is disabled even when only one field of a given card has been previously shown. Perhaps the behaviour should change so that the "declare as known" button is disabled only after 2 or more fields have been viewed previously. 

[Chris]

Oh, yes I see what you mean. Never had this idea myself!

In this case you would be allowed to declare an entry as known even after having seen most of its attributes for x times. For example, always skipping the comment field would keep the button enabled, which is not the intention of the disabling function... but I agree that the disabling function is somehow a "parental guidance" for the user, which is against the basic Stackz concept.

So yes, the user might want to select the guidance level himself... maybe it would be sensible to have the disable function as an option - to have the user decide on his own how strictly he wants the learn dialog to behave. A checkbox with the meaning

  [ ] Disable "declare as known" on repeated item selection

would not only solve the problem, but also give some sort of explanation in the options dialog about this mysterious disabling function.