Looking good
codesuidae
I just spent a little while playing with the memorize-it site and it's
looking very good, an excellent start! I hope to see further progress
on the interface, even if the spaced repetition algo isn't as refined
as SuperMemo, the better interface makes it more valuable to me.
I'd like to suggest that an import function, even a very simple and
basic import, would be very useful and should be a priority.
Any idea when collection publishing/sharing might be available? As in,
is that feature planned for 'sometime in the future' or is it a more
urgent feature?
Adam Dziendziel
> I just spent a little while playing with the memorize-it site and it's
> looking very good, an excellent start! I hope to see further progress
> on the interface, even if the spaced repetition algo isn't as refined
> as SuperMemo, the better interface makes it more valuable to me.
share it here and we'll take them into account.
> I'd like to suggest that an import function, even a very simple and
> basic import, would be very useful and should be a priority.
at the beginning from SuperMemo Q/A format.
> Any idea when collection publishing/sharing might be available? As in,
> is that feature planned for 'sometime in the future' or is it a more
> urgent feature?
as possible, but as for today there are more important things to do,
for example, the import function you have mentioned.
Adam
code suidae
<adam.dz...@gmail.com> wrote:
> If you have any suggestions about the interface, you can
> share it here and we'll take them into account.
It would be nice to have navigation buttons (prior, next) on the 'edit
card' page. When making multiple changes it is tedious to have to open
and close many cards.
It would also be nice to have a batch move function. Moving many cards
into a different category, for example after importing from Q&A,
currently appears to require the user to open each card and check the
box for the appropriate category.
'Edit selected cards' currently opens the selected cards in tabs. I'd
rather have something that opened a single edit card tab that would
let me navigate (prior, next) through the selected list, with a
control indicating which card in the current set was being editing
(i.e. 'editing card 3 of 12').
The 'Path' indicator in the text input on the 'edit card' screen has a
minor bug. Enter some text, the path will correctly indicate 'p'.
Click the 'B' control to turn on bold and enter a few characters, the
path does not change. Click the 'B' control again to turn off bold.
The path will now become 'P >> strong' and will remain so as you enter
new characters. Adjusting the caret position with the cursor keys or
the mouse will correct the path.
Some sort of formatting for the card display would be nice. When you
put an image into a card the half screen split on the card display
doesn't always show all of the image. Even just a simple property on
the card to set the split percentage would be useful.
CS
--
"Our ignorance is not so vast as our failure to use what we know." -
M. King Hubbert
Adam Dziendziel
> It would also be nice to have a batch move function. Moving many cards
> into a different category, for example after importing from Q&A,
> currently appears to require the user to open each card and check the
> box for the appropriate category.
list.
> 'Edit selected cards' currently opens the selected cards in tabs. I'd
> rather have something that opened a single edit card tab that would
> let me navigate (prior, next) through the selected list, with a
> control indicating which card in the current set was being editing
> (i.e. 'editing card 3 of 12').
> The 'Path' indicator in the text input on the 'edit card' screen has a
> minor bug. Enter some text, the path will correctly indicate 'p'.
> Click the 'B' control to turn on bold and enter a few characters, the
> path does not change. Click the 'B' control again to turn off bold.
> The path will now become 'P >> strong' and will remain so as you enter
> new characters. Adjusting the caret position with the cursor keys or
> the mouse will correct the path.
theirs demo page: http://tinymce.moxiecode.com/example_full.php?example=true
> Some sort of formatting for the card display would be nice. When you
> put an image into a card the half screen split on the card display
> doesn't always show all of the image. Even just a simple property on
> the card to set the split percentage would be useful.
card could be used by many users, each user could use a different
monitor size and the split percentage provided by a one user may not
be accurate for another user. I will try computing the size of the
content of question and answer fields when the card is displayed and
adjusting the view on the fly.
Adam
code suidae
<adam.dz...@gmail.com> wrote:
>> Some sort of formatting for the card display would be nice. When you
>> put an image into a card the half screen split on the card display
>> doesn't always show all of the image. Even just a simple property on
>> the card to set the split percentage would be useful.
>
> I would like to find a more elegant solution to use here. A single
> card could be used by many users, each user could use a different
> monitor size and the split percentage provided by a one user may not
> be accurate for another user. I will try computing the size of the
> content of question and answer fields when the card is displayed and
> adjusting the view on the fly.
Yes, I'd like to see a dynamic solution too, but if a complete
solution will take a while to implement, a quick hack would be
appreciated :)
Speaking of images, what do you think of doing an image occlusion
feature like SM?
It appears that the TinyMCE will allow floating DIV sections that can
be used to occlude parts of the image. Create a new card, click the
HTML button and paste in the following code (or see the examples I
created under the user/user account).
<p><img src="/images/1" alt="" /></p>
<div class="contents" style="background: lightgrey none repeat scroll
0% 0%; position: absolute; left: 20pt; top: 30pt; color: darkgreen;
width: 150px; -moz-background-clip: -moz-initial;
-moz-background-origin: -moz-initial; -moz-background-inline-policy:
-moz-initial; border: 1pt solid #eeeeee gray gray #eeeeee;">
<p style="/learning-app/margin: 0pt;font: 20pt arial; font-weight:
bold; text-align: center">What kind of animal is this?</p>
</div>
However, entering the div sections by hand is a pain, and I'm not sure
how to set them up so that they are sure to align over the background
image reliably. It is also important to be sure that the occlusions
appear before the image so as not to give away the answer.
Another necessary feature would be a preview mode in the 'edit card'
screen. The edit mode and the learn mode display the card differently,
and it's not desirable to have to go to learn to check how the card
looks (besides there being no way to get a card to come up again
before it is scheduled!).
sarukas
Tried to enter a few questions, same comments as above. group
categorizing would be nice, as well as sharing flashcards. Just
curious, by the way - will the data already entered to the system be
preserved between updates and in the future, or is this a really
development version where data loss is to be expected?
Another question - what implementation of the spaced repetition
algorithm are you using, is it something developed from scratch or
based on something else? How effective is it in aiding memorization?
Regards,
Sarunas - Lithuania
Adam Dziendziel
On Jul 13, 10:20 pm, sarukas <sarunas.chomentaus...@gmail.com> wrote:
> Just curious, by the way - will the data already entered to the system be
> preserved between updates and in the future, or is this a really
> development version where data loss is to be expected?
necessary and data is lost. It will change with the first official
release.
> Another question - what implementation of the spaced repetition
> algorithm are you using, is it something developed from scratch or
> based on something else? How effective is it in aiding memorization?
planning to provide alternative algorithms in the future, first SM2
(used by Mnemosyne), then an algorithm based on neural networks.
Adam
Adam Dziendziel
> Speaking of images, what do you think of doing an image occlusion
> feature like SM?
> It appears that the TinyMCE will allow floating DIV sections that can
> be used to occlude parts of the image.
Floating DIV sections used in TinyMCE are absolute positioned. This
has flaws I would like to avoid. For example, if the image is preceded
by a piece of text and we at some point decide to change default text
size, the coordinates of the DIV section becomes incorrect. I would
like to tie occlusion with the image, for example by adding to our
image edit dialog a tab with options to occlude parts of the image. If
there is not possible to use relative layer placement in TinyMCE, we
can use image processing at server side.
> Another necessary feature would be a preview mode in the 'edit card'
> screen. The edit mode and the learn mode display the card differently,
> and it's not desirable to have to go to learn to check how the card
> looks (besides there being no way to get a card to come up again
> before it is scheduled!).
The simplest solution is to make cards in edit mode look like in learning mode.
The need of clicking on the "preview" button goes out and the
interface is kept simple.
--
Regards,
Adam Dziendziel
code suidae
<adam.dz...@gmail.com> wrote:
> 2008/7/9 code suidae <codes...@gmail.com>:
>> Speaking of images, what do you think of doing an image occlusion
>> feature like SM?
>> It appears that the TinyMCE will allow floating DIV sections that can
>> be used to occlude parts of the image.
>
> Floating DIV sections used in TinyMCE are absolute positioned. This
> has flaws I would like to avoid. For example, if the image is preceded
> by a piece of text and we at some point decide to change default text
> size, the coordinates of the DIV section becomes incorrect.
Perhaps the image itself can be placed onto a DIV, along with the
occlusion images? This would maintain the alignment between the
occlusions and the image, but the image would then not be related to
text on the page:
<p>Floating Occlusion:</p>
<div class="contents" style="background: red none repeat scroll 0% 0%;
position: absolute; left: 20pt; top: 20pt; color: red; width: 450px;
-moz-background-clip: -moz-initial; -moz-background-origin:
-moz-initial; -moz-background-inline-policy: -moz-initial; border: 1pt
solid #eeeeee gray gray #eeeeee;">
<div class="contents" style="position: absolute; left:0pt; top:0pt;
width:400;"><img style="left: 0px; width: 376px;" src="/images/1"
alt="" />
<p> </p>
</div>
<div class="contents" style="background: lightgrey none repeat scroll
0% 0%; position: absolute; left: 20pt; top: 30pt; color: darkgreen;
width: 150px; -moz-background-clip: -moz-initial;
-moz-background-origin: -moz-initial; -moz-background-inline-policy:
-moz-initial; border: 1pt solid #eeeeee gray gray #eeeeee;">
<p style="/learning-app/margin: 0pt;font: 20pt arial; font-weight:
bold; text-align: center">What kind of animal is this?</p>
</div>
</div>
Also, is it possible to import cards to a specified category and can
we learn only from a given category? With thousands of cards in the
database it is apparent that these would be useful.
Adam Dziendziel
>
> Perhaps the image itself can be placed onto a DIV, along with the
> occlusion images? This would maintain the alignment between the
> occlusions and the image, but the image would then not be related to
> text on the page:
disadvantage of using DIV's for occlusions is that you can't use
shapes different than rectangles. For example, sometimes you may want
to use an arrow to point at something in the picture.
> Also, is it possible to import cards to a specified category and can
> we learn only from a given category? With thousands of cards in the
> database it is apparent that these would be useful.
category not yet, but it is a very important feature and will be
included in the application.
code suidae
<adam.dz...@gmail.com> wrote:
>
> On 23 Lip, 18:32, "code suidae" <codesui...@gmail.com> wrote:
>>
>> Perhaps the image itself can be placed onto a DIV, along with the
>> occlusion images? This would maintain the alignment between the
>> occlusions and the image, but the image would then not be related to
>> text on the page:
>
> Using your code and TinyMCE I can't move the occlusion.
Do you mean moving it by click-n-drag? If so, no, you have to use the
HTML editor to adjust positions. You'll have to update TinyMCE with
one (or more?) of the plug-ins to get layer dragging.
> Another
> disadvantage of using DIV's for occlusions is that you can't use
> shapes different than rectangles. For example, sometimes you may want
> to use an arrow to point at something in the picture.
You can use any shape you would like by putting appropriate content on
the div. For example, I've uploaded a transparent PNG file of an
arrow, which can be used to point to things (there is a sample card).
Of course you can't expect users to go to that kind of effort, this is
just to illustrate the idea that you can put pretty much anything you
want into a DIV for display without much trouble. The difficulty is
more with editing and placing items in a user friendly way. I can't
see it working for users without dragging support from TinyMCE.
Fortunately, TinyMCE has this covered. See the full-featured example at:
http://tinymce.moxiecode.com/example_full.php?example=true
Click the Add Layer button (on the bottom left of the toolbar, a box
with drag handles) and make sure Absolute positioning is on. You can
drag it where ever you want on the image, resize with handles etc. If
you could upload you could throw in a standard set of transparent
arrow graphics and you'd have a good first pass at editor-supported
occlusions. The editor for it lets you set various visual styles on it
so you can set background colors or transparency, etc.
As far as setting up complex shapes for occlusions, I think you could
skip that and just let users add multiple boxes, at least until later.
Adam Dziendziel
> If you could upload you could throw in a standard set of transparent
> arrow graphics and you'd have a good first pass at editor-supported
> occlusions. The editor for it lets you set various visual styles on it
> so you can set background colors or transparency, etc.
XML (XHTML) markup in the database so that I am able to process it and
provide versions compatible with devices which don't support fully
HTML/CSS. Currently you can use styles in cards, but it will be
disabled. Cards will be styled by themes, which will consist of XSLT
and CSS file. User (content author) will be able to provide these XSLT
+CSS themes and implement his own way to display/style all the stuff,
including occlusions.
The markup generated by TinyMCE would have to be parsed to XML markup
on save and restored on edit. It is feasible, because I've found a
library to parse CSS. I will think about this later.
Cheers,
Adam