From here to the end of Season 1 we build one real application together. This lesson is
where you meet it, and where you write its plan using everything from this module.
What we are building
Recall is a study app. You put in cards with a question on one side and an answer on
the other. It shows you the cards you are about to forget.
The idea behind it
You have already noticed this while preparing for exams. If you read something once, you
forget most of it in a few days. If you look at it again just as you are about to forget it,
it sticks for much longer. Do that a few times, spread further and further apart, and it
stays for years.
This is called spaced repetition. Review a card just before you would have forgotten it.
That means the app must decide, for every card, when to show it next. A card you answered
easily should come back in a long time. A card you got wrong should come back soon.
Remember that rule. In Module 4 the agent will get it slightly wrong, the app will look
perfectly fine, and you will learn more from that than from anything working correctly.
Why this app and not a todo list
Three reasons, and they matter for what you learn:
- It has real logic. The scheduling decision is not obvious. There is something to get
wrong. - The mistakes are quiet. A wrong schedule does not crash. It just teaches you badly,
for weeks, without telling you. That is the dangerous kind of bug from Lesson 1.3, and
you cannot learn to catch it on a todo app. - You can use it. This is not a toy. By Module 7 it is on the internet and you can
study from it.
The plan
Here it is, in the four parts from Lesson 2.3. This is your working document for the rest of
Season 1. Keep it.
GOAL
Build a web app called Recall that helps a student remember things
using spaced repetition.
A student can create cards with a question and an answer. Each day the app
shows only the cards that are due for review. After seeing the answer,
the student says how well they remembered it, and the app decides when to
show that card next.
The point is that a student can open it, review, and close it in five minutes
a day without deciding anything themselves.
LIMITS
- TypeScript everywhere.
- Data stored in SQLite, in a single file.
- No user interface framework in Season 1. Plain HTML and CSS.
- Must work on a phone screen.
- One person's data only. No sharing between users.
WHO USES IT
One student, on their own phone or laptop, mostly in short sessions.
WHAT IT DOES
1. Add a card: a question and an answer, both plain text.
2. See all cards.
3. Edit or delete a card.
4. Review: see the cards due today, one at a time.
- Show the question.
- Student thinks, then taps to see the answer.
- Student picks one of three: "Forgot", "Hard", "Easy".
- The app decides the next review date from that answer.
5. See a small summary: total cards, cards due today, cards reviewed today.
SCHEDULING RULES
Every card keeps two things: a gap in days, and a next review date.
- A new card has a gap of 1 day.
- "Forgot" sets the gap back to 1 day.
- "Hard" multiplies the gap by 1.2.
- "Easy" multiplies the gap by 2.5.
- The gap is never less than 1 day and never more than 365 days.
- The next review date is today's date plus the new gap, rounded down to whole days.
EXAMPLES
- A new card answered "Easy" has a gap of 2.5, rounded down to 2 days.
- A card with a gap of 10 days answered "Hard" gets a gap of 12 days.
- A card with a gap of 10 days answered "Forgot" gets a gap of 1 day.
- A card due yesterday still appears today. Overdue cards are not skipped.
- A student with no due cards sees "Nothing to review, well done".
NOT IN SEASON 1
- Logins and accounts.
- Sharing cards with other people.
- Images or sound on cards.
- A mobile app. The website is enough.
DONE WHEN
- A student can add a card, review it, and see it return on the right day.
- Overdue cards appear.
- The empty case shows the message above.
- The scheduling rules above are covered by tests, and npm test passes.
Look at what that document does
Read it once more and notice a few things.
The scheduling rules are written as numbers, not as “the card should come back later if
you knew it”. There is nothing to guess.
The examples include the boring case that is easy to get wrong: an overdue card must
still appear. That single line will catch a real bug in Module 4.
The “Not in Season 1” list is doing quiet work. Without it, an agent will cheerfully add
a login system because most apps have one.
Change it if you like
If you would rather build something else, do. Write your own version of this document in
the same shape, and carry your app through the course instead. Everything you learn applies
the same way.
Most people should build Recall the first time. It is easier to learn a method when the
problem is already decided.
Try this before the next lesson
- Read the scheduling rules and work out, on paper, the next review date for a card with a
gap of 30 days answered “Hard”. - Find one thing in the plan that is still unclear. There is at least one. What would you
add? - Show the plan to somebody and ask them what the app does. If they describe your app, the
plan is working.