ivanjonas / memorytyper Goto Github PK

Add some nice styles when you get a chance. My eyes will thank you.

At the click of a button, a certain number of words (say, 3) should randomly be selected to be blurred out. The user can click this button multiple times to blur additional sets of words.

Each blurred word is equal in length to the original word. This can best be done by simply underlining the word and changing font color to match background color.

Clicking (or perhaps hovering? For a second?) momentarily reveals the word. Clicking it a second time blurs it. Clicking a different blurred word reveals it and blurs the previously revealed word. If a word is revealed when clicking the "blur" button, it becomes blurred again in addition to the new set of blurred words.

A Reset button should always be visible, but secondary to the Blur button. Clicking it will reveal all the words again. This allows the user to restart, blurring a probably different set of words each time. When all words are blurred, the "blur" button is hidden/grayed out and the "reset" button becomes more visually significant to reflect that it is now the primary action.

Do not blur punctuation. Just alphanumeric characters. Punctuation is helfpul in memorization, and blurred punctuation could be mistaken for an additional letter at the end of a word ("hi, " should not become "___ " because that is much wider than the word "hi" that it represents).

Not actually required: visual blurring. "Blurred" words could be replaced with, say, underscores or a solid-colored span.

The default handling of user input is not likely to be suitable for everyone. The application should allow the user to:

• Allow or not allow the wrong input
• Require exact capitalization or not
• Require punctuation or automatically insert it
• Require newline or automatically insert it

Add Bootstrap tooltips to display user-friendly explanations for each option.

The practice modes are not very self-descriptive. It would be good to have some kind of introduction to them. Options:

• On first page load, run a full-page guided intro like is common for phone apps on first run.
• Until a mode is used, immediately display a large bootstrap popup when hovering over a mode button.
• On entering a mode for the first time, show an animated gif of how that mode works

Or a combination of the above techniques.

Depending on the technique, save variables in localStorage or infer from an empty list of texts.

To best review memorized texts, we want a basic spaced repetition system. To that end, implement a reminder system that flags texts as "due for review" on a date that correctly factors these various criteria:

• Number of consecutive successful reviews
• Number of failed reviews
• Users' personal aptitude for retaining the memory of the text

I tried to understand Wozniak's algorithm, but it's a bit too complicated. Implement the following algorithm:

f(c, m) = min(2^(c - 1), m)
f(c) = min(2^(c - 1), 122)

where f(c) gives the number of days in which to review the text after c successful reviews. There will be a maximum of 122 days (a third of a year) so that the next review isn't eventually due after an eternity. This may be user-configurable in the future.

Additionally, when a user gets a known text wrong, it will become due the next day, and the "correct score" should be decreased by 2 in order to give sufficient practice. On error, the user goes back to 0 consecutive successful reviews.

For example, if a user successfully reviews on reviews 1-5 but gets it wrong on the 6th review, his 7th review will be the following day, and the next review will be due as if he had just completed 3 reviews successfully.

(successful reviews until now)
0  1  2  3  4  5   x  3  4  ...    ("x" means a failed review)
-----------------------
0  1  2  4  8  16  1  4  8  ...    (0 means it's due today, the day the text was created)
(days until the next review)

In the future, a user will be able to shortcut the level of a new but familiar text in order to skip the boring initial stages of reviewing every few days. Make sure the text metadata will be able to support that kind of use.

When in the middle of a practice, clicking on a different text will load the text but will not interrupt the practice. This is weird. The easy solution is to just cancel the practice when loading a new text, but there is room for better UX here. The user will either be managing/selecting texts, or practicing. Not both. It's not helpful to continue showing the list of texts during a practice, and there's no point in showing the input box while not practicing.

Therefore, there should be an intuitive transition between these two application states. Consider putting the texts in a sidebar, sliding it in/out of view at the appropriate times, and displaying the practice box only when it's sensible.

It's just a placeholder right now.

They should be draggable to set a user-preferred order. Currently they are listed in chronological creation order.

Needs a GUI for typing/pasting new text to add. GUI must take at a minimum body and title, but also option fields tag/category and source. Additional metadata to be generated and saved: text id/index (counting from 0) and time created.

Suppose you make a single typo, turning the output window from green to red. If you backspace once, the window should turn green again. However, it stays red; there is no correctness feedback on backspace, only on added characters.

Along these lines, copy-pasting (which shouldn't even be allowed) does not give correct feedback. Nor does correcting a typo by inserting a character in the middle (it gets appended to the end of the text).

When dealing with the backspace issue, make sure it also works for CTRL+backspace, which deletes entire words at once.

The convenience of having a browser-based application is mitigated by the fact that app data is tied to the browser and could be lost after a cache wipe. Import/export functionality should be available.

In this mode, a blank screen and two buttons are visible. The first button "Word" will reveal one word, and any following punctuation, on each click. The second button "Sentence" will reveal an entire sentence until the next period or newline character. When the last character of the text is revealed, either by word or sentence, the buttons should disappear and be replaced with a single button "Reset."

Throughout all stages of this practice, a "back" button will be available (possibly at the top of the text, android-style?) to cancel the practice and return to the default mode.

Apostrophes and dashes are part of the word that envelops them. Em-dashes are not; the first word will show the dash and the second will show on a subsequent click of the "Word" button. The sentence button needs to also stop on newlines because of the parts that end with a comma and are followed by a long-form quote.

Consider putting a highly-visible indicator where the next word will be inserted. This is useful in the case where the new word starts on a new line, but would not be obvious because it would otherwise all just be white space.

Use uglify.js with all the flags.

After completing #2 and #4, we want to be able to view some nice charts of, say, WPM and accuracy over time. Additional features, like graph smoothing, are not necessary for a 1.0.0 release but may be desirable pending use feedback.

Which bigrams and trigrams are causing the most trouble? If this will be a typing application, it would be useful for the user to know where to focus his attention in order to become a better typist.

Do not keep an eternal log of errors, but only keep the most recent errors: if an error was frequent in the past but today is not, it should have been flagged in the past but should not be flagged now.

Line breaks are not honored. Multiple paragraphs are concatenated into a single block of text.

Use a web service to fetch a portion of scripture by reference. Easier and more reliable than manually pasting it in.

Not functional for lists with items that aren't terminated by periods

No stats are being recorded about completed practices.

We want to record the following:
[text ID, start timestamp, duration(ms), words per minute (rounded to an appropriate number of decimal places), number of mistakes made]

The screen should turn red or green after a backspace. However, the screen currently only updates on new keyboard input.

Tabs should be completely ignored, along with any other leading and trailing whitespace.

If the user is typing and reaches a new line which start with whitespace, the caret should remain at the beginning of the line, as if the whitespace needed to be input by the user. If he types a space (tab is reserved for autocompletion/hints; TBDeveloped), the application should insert all necessary whitespace to move the carat to the position of the next non-whitespace character.
If, instead of typing a space, he simply types the first letter of the first word on that line, both the whitespace and that letter should be printed to the output.

As a special case, this should also work if the first character of the page is a whitespace character.

Add one text and save it. Click "Add new text" again. The modal will be prefilled with the content from the last text. It should be erased on successful save (but not on Close, which might be accidental).

While you're at it, the title of the modal is still "Modal title." Fix that, too.

When the Wrong Input setting is on, it should be possible for the user to erroneously type more characters than are in the text. There is an uncaught typeerror when this happens.

Currently it's in a vendor directory that I created manually. Not maintainable, does not communicate dependency.

There's currently no mechanism by which to edit or delete existing texts except to manipulate localStorage via the browser console.

When editing texts, we want to prevent major edits. Find a way to determine what qualifies as a valid minor edit (Levenshten distance is a good start) and prevent drastic edits. This is to keep existing statistics about that text relatively valid for the edited text, but this is an edge case.