Add a way to jump between kanji without remembering the keyword or number in study page.

[Shibodd]

In study page, i often find myself jumping back and forth between nearby kanji, without remembering the keyword or frame number; for example to return to the kanji for which i may have thought "i'll come back to this later", or to take a quick peek at the story, or maybe it is a kanji for which i want to use its image instead of its keyword.

Currently, this means either repeatedly clicking "previous" or "next", guessing the frame number, or taking a look at the book - the first two mean flooding the server with useless requests (and hitting the request rate limit, which makes it very painful).

What i suggest is a way to allow me to jump between kanji without having to switch page/window; for example, a "navigation bar": You can see a proof of concept for the idea in the image below. It is a scrollable view which shows kanji in order, possibly showing the frame number too. You can see the current kanji is highlighted and the user can drag the navigation bar to see more kanji. The user can then click on a kanji shown on the navigation bar to navigate to the study page of that kanji. As far as i understood, the kanji list (and therefore frame numbers) are stored client-side, so this would require no interaction with the DB unless additional information is added.

[fabd]

I've been thinking about this, though reading your suggestion there are two use cases, potentially both could work together:

1) some kind of popup close to the search bar could show a grid of kanji, indeed this is mostly doable client side, and that lets you just pick another char going by visual only (no framenumber; or keyword) ... this is similar to your suggestion

2) another idea I had for a while, just never really got motivated to do, is to add like a "browser history" - just a list of the last ten visited study pages, and that could potentially fit in the sidebar, so if you jump from kanji #1 to #100, then you could jump back more easily. edit: #275

Both of these sound like small features that can be motivating to work on so hmmm - maybe I'll put them on the list right after the "kanji to keyword srs reviews". I'll pin this in the meantime.

[Shibodd]

The history too sounds, to me, like a good idea, being client-side too but easier to implement than the grid; it should not even require the knowledge of what index the user is using. IMHO, the only thing that is worth to point out as a requirement is not to have duplicates in the history.

[fabd]

The history too sounds, to me, like a good idea, being client-side too but easier to implement than the grid; it should not even require the knowledge of what index the user is using. IMHO, the only thing that is worth to point out as a requirement is not to have duplicates in the history.

I created a separate issue #275

No duplicates I agree. Just visualizing how it would work I am going to try most recent visited kanji always at top of the list. If it'"s not there already, insert to top of list. Trim list to max N items. Maintain in window.localStorage . Front end has lookup tables for index / UCS / keyword

And yes I think client side only is fine. Maintaining this between devices seems unnecessary complex. It's mostly useful per session, and can be maintained in the browser.

[fabd]

I think this was solved by #275. Closing. Thanks again for the feedback. I am working on an improved navigation as well, some kind of popup near the search box.