Last Wednesday the site was updated with the next item that was on my list : a refactoring of the calls between client/server that is used across the site : when editing a story, syncing flashcards during review, voting a story and so on.

I'm happy with the results of this rewrite. I learned a few things about TypeScript along the way that will prove useful later. Mainly that in this case using simple OOP approach and Javascript's native classes, it simplified the TypeScript code. I could remove the interface because the class in itself is already the interface, and you can export it. By using a factory function approach, I had to declare a separate interface, and the code was unnecessarily verbose and annoying to maintain.

This will prove handy later this year if we (hopefully) get to a point where we can have a proper API (likely using token generation from Laravel Sanctum).

This refactoring now done, closes second item on my "Phase 1" of the "reboot" roadmap I posted in January.

Next : Review, Repeat!

Next on my list then is Issue #184 Add "Again" button in Review page posted by shintoo. I'm really excited to finally be working on a feature, or at least a tangible enhancement to the site's functionality!

The gist of this feature is to allow users to repeat cards in the same review session. Essentially this adds something similar to Anki's "learning" stage : a new "Repeat" (or "Again") button will move the card back to the bottom of the pile in the same review session. The user is free to "Repeat" those cards as many times as they want. Eventually they'll want to answer Hard / Yes / Easy (typically Hard or Yes, Hard for New cards ensures they will show up again next day). If the review session is ended early (clicking the "End" button), any remaining "Again" cards are not rated. Therefore they will remain in the due pile, and the user can study them again later.

Note if you'd like to weigh in on how it will work, now is the time! Feel free to leave a comment in the Github issue linked above.

One of the design questions is what to do with the flashcard answer buttons. I'm not too fond of having five buttons under the flashcard. The solution I'm leaning towards atm, quoting the Github issue:

(...) adding an option to SRS Settings to Use Learning mode (similar to Anki) : With this option enabled, the "No" button is replaced by "Again" (or "Repeat"). The "Again" answer moves the card to the back of the pile for another test in the same review session.

If the user ends the session early with the "End" button, unlike what I wrote in the issue, the "Again" cards will remain unrated. That way they will simply sit in the due card pile, and will be available to review again later in the same day.

So, assuming we tick this option, the buttons under the flashcard would become : Repeat / Hard / Yes / Easy. The choice of labeling "Repeat" or "Again" is mostly about the shortcut : I like "Repeat" because the first letter then can be underlined, like the other buttons. The key r would logically become the shortcut.

My hunch is for most users new to the site having a "Repeat" button instead of "No" is probably closer to what they need. If that is the case, then I could turn this on by default for new accounts, and those that want the more strict mode (doing a second review of New cards after a night's sleep) could enable that in the options. Let me know what you think!

I'm aiming to complete this item in two weeks. Let's do this!

End of support for Internet Explorer 10-11

While refactoring I also decided to finally drop support for Internet Explorer. Specifically, in developer terms I removed ie >= 11 from the target browser compatibility. The reason for this change is to allow legacy javascript code to use a feature called Promises which are unfortunately not supported at all in IE11.

Maintaining support for outdated browsers means the packaged javascript delivered by the server is larger, as well as a tad slower due to containing extra code that "patches" the missing functionality in the browser.

A quick glance at Google Analytics, shows that IE is not even in the top 10 entries of the "Browser & OS" chart anymore. Microsoft EDGE, which now replaces IE in Windows, is at 2.93% of users. For the curious, in this audience specifically, starting at position #1 I'm seeing 60.68% of users on Chrome (I assume this also covers Vivaldi etc. which use the Chrome engine, not sure), #2 is Safari at 21.56% (the default browser on all iOS devices), Firefox is at 7.50%, then EDGE at 2.93%, followed closely by Opera at 2.58%. ... Internet Explorer is at 0.15%.

Account Delete functionality

Last Friday the site was updated with the functionality to permanently delete an account. As I noted in the New Year roadmap:

most sites these days let you delete your account at the click of a button. For a long time I was able to handle these requests via the contact form, but I have been lagging behind lately and it's admittedly not what I would expect myself from other websites/apps.

The delete account option is found at the bottom of the "Edit Account" page. Personally I always feel a bit nervous when I see this sort of options. :) Let me reassure you even if you mistakenly tap that button on your laptop while scrolling the page or whatnot, it will take you to a second step with a form. The form requires your current email, a short phrase as well to confirm your current password (see picture).

This closes Github Issue #87 Add "Delete Account" option somewhere in Account Settings. The issue was created by yours truly in March 2017... humbling.

Also completes one of the three main items for Phase 1 of the New Year roadmap (blog post).

Stories also sail away...

Stories and flashcards are immediately deleted... which isn't great. Sites like StackOverflow have a way of converting a user's public contribution (the questions & answers) into some kind of a "community wiki". Kanji Koohii doesn't have such a system in place. It would be really complicated for me as well to code it on the legacy code base (ie. prior to the announced Laravel migration).

Therefore when a user deletes their account, all the shared stories on this account also immediately get deleted. Those stories (and their usernames) may still show for up to thirty days because of the cached templates, but as soon as those templates get refreshed they are gone. That also includes all the votes and reports associated with those stories.

I'm not sure this is what users would expect. Likely that users who shared many stories, especially those that accrued many stars, don't expect their public stories to also get deleted. They may want to only delete their personal info (username, email, ...) and perosnal stories, while retaining their shared contributions.

Ideally I'd have a checkbox on the account deletion confirmation page, for users to confirm whether they want to also delete the shared stories. Shared stories could be "orphaned" from the original author, but I don't have a simple solution right now. To be honest I just want to move on with the Laravel migration but if someone can think of a relatively simple and better way to handle this, suggestions are welcome.

With that said in practice this isn't a big issue because the vast majority of account deletion requests are either recent users who simply wanted to check out the site and it wasn't exactly what they are looking for, as well as people who registered years ago and I am guessing like to clean up their tracks and delete old unused accounts.

Who's Reviewing? Broken Edition

In the recent update I also introduced a typo that broke the Who's Reviewing page. Thanks again to Roderick for letting me know! It was a simple typo introduced while refactoring some CSS. A class name output in a bit of JSON. I thought I was smart back then with my JSON data in a php method, but that bit of JSON does not get any syntax checking in the code editor. Sigh. Also I didn't know about short array syntax in php back then which is why I resorted to JSON to return a configuration object in a less verbose and unsightly syntax.

This particular code is almost as old as the site which is why the component is internally called "MembersList": indeed the early "Reviewing the Kanji" website's main feature was the spaced repetition system with the builtin RTK flashcards. The stories area was in fact added later (a heavily requested feature ;)).

This got me thinking. The "Who's Reviewing" page is one of the few places of the site that gives a bit of a community feel. I realized this page may be one of the simplest and early features I could write on the new Laravel stack : with Laravel Jetstream I should be able to add user's custom avatars to the list (cf. profile management). I think this will make the page more lively and add a bit more personality to user's public profile.

Next

Having completed one of the three main items of Phase 1, I will now move onto either the "Finish Typescript API refactor", or Issue #184 Add "Again" button in Review page. I should probably start with the Javascript refactor to refresh myself on some Javascript patterns since I'll need to edit quite a bit of Javascript for the Flashcard Review page.

I'm actually one week behind the schedule I planned on my little Gantt chart ... but to be fair I had to refresh myself on a bunch of things like handling MySQL imports/exports in the docker container, fix some issue with the Bash prompt, install and configure some php extensions, etc.