Request: Sort notes by their scheduling

[And-Garcia]

First of all, been using this add-on a LOT these last few months and it is a real game changer. Many thanks to all the contributors for your hard work.

The use-case for my suggestion would be the following: Suppose I come to the add dialogue knowing that I want to tackle something in the category of biology. I have my biology notes, be it PDFs, videos, extracts, etc, marked with the tag "bio" - so I can easily find all of the relevant notes. However, I can't visually ascertain in this filtered list what position they occupy in the queue, so I lose the value of the scheduler.

Another, and perhaps more relatable, example would involve different note types. For instance, I have a LOT of text notes - that is perhaps somewhat of an issue on my side rather than a problem with the add-on. Sometimes, I'll be in a mood to continue reading one of my books, but the top of my queue will be full of text notes. Now, I can easily find all of my books under PDFs on the side-bar. Problem is, once more, the resulting list gives no hint as to which book is 'most urgent' in terms of the internal scheduling.

Of course, I could always decide on my own which particular biology note or which book I want to tackle, but in most instances, I don't have an immediate preference. This is why I try appeal to the scheduler even in this cases. That sort of middle ground where I may know the category of thing I want to do but not the particular note in said category - that would be where this feature come into play.

My work-around has been to open the New Note dialogue, switch to the Queue tab and scroll down until I find a note of the type I want (in the PDF case it's easier to open the queue itself, since they're easy to tell apart due to their icon). After that, I just search it and open it. This isn't too troublesome, so I wouldn't necessarily say this should be a priority. Perhaps there is already some built-in way to do what I want and I am just being silly?

[fonol]

Hi, I too have been thinking about ways to better handle different topics, from which I only want to study a subset on a given day. My initial approach was too kind of simulate different queues by emptying the queue and adding all notes with a given tag in the queue manager. But that approach still has some drawbacks and is a bit cumbersome. I kind of like your idea. Adding a "sort by position" to the list of filters/sorts could be a possibility. Another option I can imagine is having a "meta" card at the the top of the results when you click on a tag, just like when you click on "PDFs". That card could have options like "read random", "read highest placed in queue" etc. That would be a click less to open the note, and there wouldn't be another sort/filter that only has an effect in some cases.

[And-Garcia]

Hello, Fonol! Thanks a lot for your response and, once again, for all the work you've put into this project!

Another thing that occurs to me is that you can get the effect of 'only study subject Y' in a given session quite naturally from this meta card option.

Whenever someone clicks on the "read highest placed in queue" option, you could store the name of the tag from which they did so. Then, when the user hits done on that first note, rather than simply jump to the next note in the queue, you can do a simple loop to advance until you hit another note with the same tag. Or, if it is more efficient for processing, you could store the sorted list of notes of a given tag (as sorted by position in queue) and refer to that sorted list rather than the global queue to decide the next note to load on done. The latter will require you to update the sorted list, though I am uncertain as to whether you'd have to update it on each hit of done or only every so often. If it has to be updated after every note, however, you might as well just recycle the method that finds the note that is highest placed in the queue and call that method again after hitting done on each note.

This condition of exploring only notes of a single tag could then be reset to null whenever the user manually exits the note or closes the add dialogue. Alternatively you can also directly add options within that meta tag to set "only see this tag today" - and do something similar but keeping the values until the next time the dialogue is opened and the date is detected to have changed.

In either case, it might be good to have some kind of visual reminder in the UI that you are currently tracking a single tag, perhaps you could allow the user to click on that to exit the "single tag condition" as well.

[fonol]

Hm, I don't know what would be the best way to approach this. In general, I prefer to add less additional state in the app (there is already a lot which makes it kinda hard to maintain). Adding a special mode which makes stuff like the done button behave differently adds complexity to many parts of the code, Plus, as you said, there would be the need to somehow visually indicate that you are in that mode, which would have to happen in both, the pdf reader and the main UI, so it might mean quite some UI work. Maybe I will introduce some kind of "filtered queue" at some point, but that will be a rather big undertaking, and for the time being too much work. A stateless solution, which I can imagine, and which would be easy to implement: Add an "Open next item with common tag" checkbox to the Done dialog, which makes the dialog open the tag's next note when confirmed, instead of the first item in the queue. The dialog could remember the last choice for this checkbox, so it wouldn't really be any extra clicking work for the user (except for the first time), and it would enable staying on the same tag without adding any complexity. Of course that opens the question what a common tag means, e.g. do parents in hierarchical tags count too, and what if you have a tag that every note in the queue has?

[And-Garcia]

There is another work-around to having to do this as a special mode. That is, you could generalize the mode, such that the behavior of the done button is always to parse the queue for the next highest note of a particular "current tag". The trick would be to assign an invisible tag to all notes upon creation, such that by default, it is that "All" tag that you filter by normally.

In that case, it would be a matter of controlling the current tag between one chosen by the user, when clicking on the right option of the meta card, or the default one - restored when a certain condition is met. As a matter of fact, you could even generalize the UI indicator. For instance, by putting a small button to the side that says something like "browsing All notes" or "browsing bio notes", depending on the current tag - this button could just be shown always by replacing the tag text when appropriate.

Of course, I imagine that changing how the done button fundamentally behaves is not going to be any less of a mess than changing it for only certain cases. And the fact that the button could be constantly displayed does not reduce the potential UI work required. it likely would still be quite the undertaking, as you say.

Your checkbox idea is a lot more feasible. The notion of common tag, however, as you express, seems hard to define in a useful way... I for instance have a lot of notes tagged "misc", I checked just now and I do have 2 notes that are both "misc" and "bio", so as you point out, it is entirely possible for me, when intending to study bio notes, to just fall into the pit of "misc" notes, most of which probably have nothing to do with the original "bio" category. I'd say this system require special consideration on the user's side when tagging notes - to avoid creating those 'pits' of notes that are too broad in scope.

A potential solution is to add a drop-down menu next to the checkbox to select the specific tag you want the next note to have.

It might look something like: "[x] Open next item with common tag: bio".

You could then also connect it with the idea of the meta card option. Clicking the appropriate option in the meta card on a tag's note list could open the highest placed card AND automatically set the value of the "common tag" to match. Then, if the user marks the checkbox, he'll stay in that "filtered queue" without any further clicks. Alternatively, when cycling through the queue as usual, with the checkbox off, the user may run into a note and then decide they want to stick to that subject for the rest of their session - this would entail clicking the checkbox and then setting the tag manually, then it would work for the rest of the session without further clicks.

Quick edit: The thought just occurred to me... I don't personally use hierarchical tags, but you did mention them and they might actually complicate things more than I initially anticipated. It is not clear to me how easy it will be to include or exclude parents and/or children from particular filtered lists or what criteria one should generally default to... To illustrate with the drop-down suggestion: if I'm standing on a "bio::anatomy::9.01::terms" note... should the drop down menu give you the option to select all the way up to "bio" as the common tag?

[fonol]

As a matter of fact, you could even generalize the UI indicator. For instance, by putting a small button to the side that says something like "browsing All notes" or "browsing bio notes"

I think maybe I was wrong with the UI indicator being needed in the main UI too. It kind of makes sense only in the reader, doesn't it? It could even be confusing to show it elsewhere, because people might think it applies some kind of filtering to the search results too.

Maybe a filtered queue wouldn't even require that many changes, but it would certainly require a lot of consideration on whether to change UI elements and behaviour with respect to the current filter or not. Examples would be the Random button, the Postpone button, the queue manager, the display of items 1-5 in the bottom of the reader, etc.

So I would go with the checkbox in the Done dialog at first, which could also potentially still be used if there would be any tag filter added in the future.

You could then also connect it with the idea of the meta card option. Clicking the appropriate option in the meta card on a tag's note list could open the highest placed card AND automatically set the value of the "common tag" to match.

I think that is a good approach. So as I imagine it now, you have an input field, where you can manually input the tag(s), and a dropdown to the right, where you can select from a list of suggested tags. That list would include first and foremost the tags of the current note, in all possible hierarchy levels, so for misc::bio::anatomy, it would be misc::*, misc::bio::*, and misc::bio::anatomy::* e.g. misc::* would then match misc, as well as misc::math. Clicking on a dropdown item adds it to the input. An empty input means no tag filter.

[And-Garcia]

I think maybe I was wrong with the UI indicator being needed in the main UI too. It kind of makes sense only in the reader, doesn't it?

This is true. In fact, thinking about it, the original way I had envisioned it, you would exit the filtered mode as soon as you exited the viewer anyways! It would have been quite redundant.

Maybe a filtered queue wouldn't even require that many changes, but it would certainly require a lot of consideration on whether to change UI elements and behaviour with respect to the current filter or not.

Yes, I suppose those changes would mark the difference between a "true" filtered queue and a simulated filtered queue. I don't necessarily think the use case necessitates going all the way to modifying the queue manager, or even the random button. You can always have the random option in the meta card, and it seems a bit strange of a situation to be in the middle of a filtered session and hit the random button - so long as we assume filtering is handled by sessions (in the reader), rather than by dates. On the other hand, postpone and the top 5 items at the bottom of the reader could be useful, but are perhaps not crucial.

Either way, for a future development, as you say, you could still use the "generalization" approach, where all these behavior: postpone, random, display top 5, etc., are "filtered" to begin with - with the caveat that in normal use they filter by the "All" tag.

So as I imagine it now, you have an input field, where you can manually input the tag(s), and a dropdown to the right, where you can select from a list of suggested tags. That list would include first and foremost the tags of the current note, in all possible hierarchy levels

Yes, I think we've hit the right implementation right here! With that, you handle both potential parent and children tags quite neatly. My only residual worry would be that the dropdown list might get extensively long for someone who has a lot of hierarchy levels! However, adding the inputfield for manual input makes that a non-issue.

Thanks for the back and forth and for considering my suggestion, @fonol ! Not sure if I was much help with my ramblings, but I hope I at least gave you a chance to bounce some possibilities in your head.

[fonol]

The develop branch now has a first version of the tag filter, if you want to try out. Meta card for tags is still missing, but the filter can be set in the Done dialog. I will use it a bit before updating the Ankiweb entry, just to make sure. But it seems to work fine in my initial testing, and I am quite pleased with the resulting workflow.