Important suggestion: a different prioritization system

[ghost]

As Alexsejrs pointed out, the organizer is too manual and not convenient. If you manually put your top priority articles at the top of the list (which is already annoying if you've got a long list), then you cannot randomize anymore. But randomizing is important.

The priority of each article should be set by the user on a 1-10 scale. (or another 1-n scale)

• the "soon" and "later" buttons would disappear, along with their associated values (10% and 50%)
• the "show answer" button would be replaced by a "next" button, which would directly show the next article
• randomizing the articles in the organizer would be consistent with priorities: articles with high priorities would remain highly ranked in the reading list.
• the default priority of an extract would be the priority of the original article, but it could be changed by the user when extracting (or afterward) (by the way extracts should probably be scheduled with spaced repetition, but that's another issue)
• defining the priority should be fast (using shortcuts)
• changing the priority of an article would be possible at any time (in the course of reading, from the organizer, and from the deck browser)
• when importing several articles at the same time (e.g. from Pocket), the user should be able to choose between:
  • defining the same priority for all imported articles
  • defining the priority of each article (in a series of dialog boxes)
  • defining no priority at all (to define them later)
• so the priority "no priority" should be handled. Those articles would be randomized as all currently are, following a uniform distribution. And they would be emphasized in the organizer as priority-less.

Any thoughts?

[ghost]

Also:

• the priority of each article would be displayed in the organizer.
• in the current implementation, the article being read is always at the top of the reading list. This won't work anymore. The user will rather gradually explore the organizer toward lesser-priority articles. If the end of the reading list is found, a loop will begin: the user will go to the top of the organizer again.
• when the user hits the "next" button, the new position of the article is defined according to its priority and with some randomization. If the new position has a higher value than the current position, the article risks being found again quickly after. So it should be ignored until next day, or until getting to the end of the reading list.
• at some point, the user might stumble upon the least important articles and get bored. So an option making it possible to go back to the top of the reading list would be great.

[ghost]

If anyone happens to be interested in this suggestion, I have implemented it in my fork (I hope Luo Li-Yan comes back soon to Github so we can merge our versions). UPDATE: Luo Li-Yan has come back and it's not in my fork anymore. Every point has been implemented except:

To-do

• [ ] defining the priority should be fast (using shortcuts)

• when importing several articles at the same time (e.g. from Pocket), the user should be able to choose between:

• [ ] defining the same priority (or no priority) for all imported articles

• [x] defining the priority of each article (in a series of dialog boxes)

• Changing the priority of an article would be possible at any time:

• [ ] in the course of reading

• [x] from the organizer

• [x] from the deck browser

Not done but not to do

• Articles with no priority go to the bottom of the organizer instead of being randomized (I changed my mind).
• Always reading the article at the top of the reading list actually works. When the user goes to the next article, the previous article goes to the bottom of the organizer, where it remains until the next randomization (the loop is therefore automatically implemented).
• If the user gets bored due to stumbling on low-priority stuff, randomizing gets them back to high-priority articles.

[jdlorimer]

Gee whiz, someone has been working hard :-)

Give me a few days to look over the code.

[ghost]

Before I actually copy my changes to the new code and submit them as a pull request, it might be better to first discuss the desirability of this proposal, and how it might be improved. This is inspired by how I assume SuperMemo works − from what I've read, because I couldn't make it run on Linux. So here are all the changes that I suggest doing (this list overlaps the previous comments and should be exhaustive):

1. Adding a Priority field between Title and Text. This field would contain either nothing (no priority yet), or an integer in one of the following ranges: 1-10, 1-20 and 1-100.
2. This would make a new model: IR4.
3. The transition to model IR4 from IR3 and IRead2 would be automatic: all IR3 or IRead2 notes would be converted into IR4 with a default priority of 5 (as 1-10 is the default priorities range), and these note types would be deleted.
4. The maximum priority (10, 20 or 100) would be defined in the Options dialog. Switching from one to the other could be associated with an update of all existing priorities (e.g. multiplying all priorities by 10 when changing to 100 from 10): (the dialog isn't up-to-date)
5. The organizer would display priorities instead of ranks:
6. Randomizing would be consistent with priorities, using this formula: gauss(maxPrio - priority, maxPrio/20) then sorting.
7. Articles with no priorities would go to the bottom of the organizer
8. The Soon, Later and Custom buttons would be replaced by a single button: Next
9. 'When do you want to see this card again?' would be replaced by something like 'Hit space to move to the next article'
10. The Schedule extract option in Options/Extraction would disappear
11. The Scheduling tab in Options would disappear
12. Pushing the Next button would send the current article to the end of the organizer. Getting them back to the top would be achieved either by a small number of articles in the organizer, or by randomizing (which could be done whenever the user wants to, e.g. once per day)
13. adding a new note would randomize all articles (so that it doesn't go to the bottom of the organizer) (this I haven't coded actually, except for webpage imports)
14. A dialog would allow for quick priority definition on webpage imports: (clicking works, as does typing the priority)
15. The organizer might have 2 more buttons: Priority up and Priority down, which would increase or decrease the priorities of the selected articles of 1 unit.
16. The Top, Up, Down and Bottom buttons might or might not be removed, as they would be less useful.
17. The priority of an extract would be the priority of the parent article. However this will quickly raise issues for people who are used to extract a lot. As for myself, I don't use extracts (only quick keys) because I think they need to be scheduled with spaced repetition, not as regular articles. I acknowledge that with the current way extracts are handled, this proposal will make things worse for them: the user will quickly spend all their time reading high-priority extracts.
18. (independent proposition) A shortcut would be added for randomization from the organizer (R by default)

Does this sound like an improvement? Are there points that should be improved or not implemented? Are there points to add?

[jdlorimer]

My usual workflow is basically:

• Import a textbook (split into cards based on section headings)
• Read through the sections in order, scheduling with Soon or Later depending on how important they seem
• Extract particularly important passages into the same deck, so I end up going over them several times
• If a tight and focused question can be formulated from an extract, I use quick keys to create an SRS card
• Larger chunks of text get extracted into a Quote note type, if I don't think they can be refined further
• Cards are deleted when everything of interest has been extracted

I agree that setting priorities on import would be useful for managing a deck full of articles, but replacing the current system entirely wouldn't be compatible with certain workflows. In particular, it wouldn't work for anyone who relies on a fixed card order and control over positioning of extracts.

I like the idea of attaching priorities to IR cards, but I think think two approaches need to coexist.

[ghost]

Hm I see that it wouldn't be great for you. I've also read in issue #39 that @levodopa cares about order, too. I tend to think that most users would prefer priorities, but I might be wrong.

Here's my workflow, to give a bit of context:

• I have 2 decks: IR and Kn (for 'Knowledge': regular spaced repetition)
• Import a lot of independent articles and assign them priorities
• Read part of an article until I want to move to the next article
• Randomize the organizer every morning
• Use quick keys to either extract a chunk of text or formulate a question/answer or cloze deletion, both into Kn
• Refine the formulation of extracted chunks as I review them, occasionally transform them into clozes or questions/answers. This part takes slightly longer than if the chunks were of an IR note type, which would allow me to split into several questions or change the note type faster (with quick keys) (because changing the note type of an existing note can only be done from the browser and then requires a full upload of the collection).
• I also delete IR articles when I reach the bottom.

Now making the two approaches coexist is doable, so I'll do that.