In case you missed our In Memoriam post for Mark Forster, it’s a posthumous guest post by Forster himself about his system he called Final Version and that we call Forster Lists or sometimes Dot Lists. It includes a link to this implementation that @bee made:
And then in the comments, Adam Courtemanche pointed us to his own version that I think is the best one I’ve seen:
I just wanted to share that (and I have a beemergency to move something from the Discord to here in the forum for posterity). If you have your own favorite to-do list system you want to share, by all means.
By default, Trello boards create lists that have dots that you can check off to indicate that they’re part of your queue for a Forster list.
Trello boards with a list is the default way to use the application. You don’t need to setup any automation to create a Forster list, and it is already actually 98% of the way towards a working Forster list setup.
New tasks get added by default to the bottom of your existing list.
Trello is a highly mature application with native apps for every notable platform and a website that can be used everywhere it doesn’t have a native app
Trello’s cloud sync is SaaS enterprise-tier reliable.
Cons
A paper Forster list allows you to see previously completed, or crossed out tasks naturally taking space alongside tasks that are in the process of being completed, which I think is a big part of the motivational aspect of a Forster list. An ideal Forster list application would be a STABLE UNIT TESTED or ideally open source digital version of a paper Forster list, AKA a gigantic list that you can scroll thru to see past tasks, add dots, cross things off, or send things to the bottom of the list. It would also need to have cloud sync so your tasks don’t disappear into the ether, and a good PWA implementation so it can be added to the home screen of a phone where most tasks tend to be captured for people in this day and age.
You can’t see where completed tasks fall in the overall list, unlike a paper Forster list.
It’s geared for execution, not task management. It puts the focus on the current benchmark task (in purple), the next candidate task, and the question of whether to “dot” it. The green progress bar tells me how far down the list I’ve gone.
The biggest deviation from a physical list is that there’s no underlying order, from the perspective of this prioritization UI. There’s just the chain, items that have been considered but rejected, and the rest of the list. This lets me pull the tasks in from anywhere. My main task list is a Markdown note in Obsidian.
“Dislodge” removes the benchmark from the chain without marking it complete.
My task list is a few hundred items long, and I’d often gladly procrastinate by clicking Yes/No/Can’t forever, so it stages these interventions:
The reason it can do that, and the reason that the UI distinguishes between “No” and “Can’t” is that it maintains an underlying estimated rank for each task (loosely based on this). “Can’t” allows me to reject a task without it being taken as a signal that the rank should be lowered.
The rank estimates save me a lot of time because it allows the UI to present candidates that I’m actually likely to add to the chain. New tasks have a uniform prior, so they tend to be presented too.
Here’s a sample of tasks and their estimated ranks:
If you actually look closely at that list, be nice to me. It’s a cooler visual if I show real data. Don’t forget Forster’s criteria is whether you “want” to do something.
@alltom , this looks very interesting. Are many of the items on the list recurrent that are automatically re-added to the list for the next time when they are supposed to happen?
And you’re right, it’s always more valuable to see what the UI will show when real data is used instead of something made up for a viz. I am wondering, what do the graphs by the tasks in the last screenshot refer to?
~10–20 tasks recur. They’re the minority, and mostly 30-second tasks.
The sparkline is the likelihood distribution of the rank of the task. Tasks that are likely to be picked have left-biased charts.
The top-K chart is some arcane criteria like “the smallest K for which P(\text{rank} \leq K) \geq 1 - 1/K”. It’s a stopping criteria: if I think I’ll do 5 tasks today, then if I add to the chain until the benchmark task reaches top-5, and do that 5 times, then in expectation I’ll have only executed on one task that wasn’t actually in the top 5. It is cute, but leads to unnecessarily long chains.
I ended up creating an implementation based upon alltom’s screenshots using a combination of ChatGPT Codex and Claude Code. (I sought out and also got their blessing to post my implementation publicly, so thanks to them for that!)
Add tasks. You can tag them with contexts and enable contexts so that todos that NEED to match that context are surfaced. If the context is not enabled, those todos are not surfaced.
Then hit start scanning.
The oldest task outstanding and not blocked on your list is added to a “chain” of todos you need to do in order.
Then, you are presented with candidates to add to the todo list in descending order of your likelihood to want to add it to your chain. You can hit yes, improving its rank via trueskill rating, or no, to decrease its chance of coming up again.
You can also hit can’t, which will snooze the task for a duration you’ve configured in settings.
You will continue until either you hit done scanning, or the app recognizes the chances of you finding a better task dips below 25% (percentage configurable in settings menu) in which case it will gently nudge you to stop searching for a new todo.
Once you’re done scanning, you will be presented with a chain of todos you will need to complete from the bottom of the “chain” up to the top, marking tasks as done, worked on (sends it back to the todo list for later) or can’t / dislodge.
# Fun Features
There are four different backgrounds with random animated events going on. Sunrise, Sunset, Daytime, and Nighttime.
I’ve added cloud sync, and PWA support, so you can install this as an app by going to the share button in Safari iOS, and adding it to your iOS home screen. I personally use the cloud sync to have a single todo list consistent across iOS, macOS, and iPadOS with the same app. Every action you do is cloud synced.
You can mark a task as evergreen, so hitting done sends it back onto the list for later completion.
There are fun little messages that are relative to the time of day.
You can SET YOUR LOCATION so the animated cityscape’s astronomy matches wherever you are ISH. I haven’t bothered to verify this in depth tbh.
The constellations in the animated sky are IN THEORY correct. I haven’t bothered to verify this, though. The path of the sun in the sky and when the sun rises and sets is also IN THEORY accurate, and the app reflects the four different seasons in the backdrop.
There’s also a history of all the tasks you have done.
# Daily Driving It
I’ve been daily driving my implementation of alltom’s implementation for about three weeks now and it’s changed my life for the better - I’ve gotten like 132 todos done over the course of three weeks and it’s killed my analysis paralysis, in the words of Beeminder adjacent folk, it pareto dominates a paper forster list for me.
Try it out here!
It’s open source, so feel free to fork, copy, pull request. Note that since I made this for personal usage, you may see things change often as I use this as my personal todo list app and I do a lot of tweaking to make it fit my personal preferences…
And, yes, I do merge straight into main. This is a personal side project that got outta hand, lmao. BUT I do TDD and there’s a battery of more than five hundred (at least) tests that I would recommend you use if you would like to fork or pull request.
This looks beautiful. I am already trying it out How do I enter/mark tasks that are supposed to recur vs one-time tasks? I mean, for the app to have an idea of whether or not I am likely to pick a task, the same tasks as yesterday probably shouldn’t be entered from scratch as if they are totally new?
Sorry, I found the response to my question in your previous explanation, here it is just in case anybody else will also be wondering:
I am planning to add a per task setting allowing you to choose the interval in hours for an evergreen task to reoccur. Please lmk if you have any suggestions for other features or run into other weirdness / bugs. TY!
I will also update the copy to make sure evergreen tasks / other features are more clear.
I think sometimes the most logical thing (real-life-wise) would be “allow not earlier than tomorrow” rather than “after N hours” - but if the logic of your script works better with “after N hours”, this will be great too.
Shipped changes / fixes today adding a configurable evergreen reocurance duration default configurable in settings, and a per task evergreen. So you can have a task reoocur after, say, four hours, or 72.
The default functionality kept thru now is that evergreen tasks reoccur / become eligible again after either 18 hours, OR after the 2 AM mark. Could add more granularity, but don’t want the settings page to become too convoluted from the task or app perspective.
I also added a “chance mode” for the scanner by default in settings that randomly chooses tasks based upon the likelihood of you adding that task to your chain next, instead of scanning down the list by strictly descending likelihood of adding it to the chain. The old functionality can be restored in the settings by choosing descending likelihood mode. Both scanning modes are undo resistant and should serve up the same choice options after using undo functionality.
I think this is an ideal solution to the duality mentioned above. For things that make sense only with daily granularity (but it doesn’t matter what time of the day; IDK like anki reviews) - the 2AM mark will govern their reappearance correctly, and for other types of recurrent tasks that it makes sense to do once every few days or even multiple times a day, the hours setting will do the job. Thanks for implementing that!
Could you please elaborate on the implications of the hours by the tag “worked”:
Does it mean it won’t be suggested again for this many hours? I have seen various numbers with this tag but I’m not sure I can quite pin the logic myself
In my internal expectation, when I press “worked on it”, it would mean that I’m done with this item for this chain, but more work needs to be done, probably even today. But I am honestly not sure what’s the behaviour rule currently, which is why I am asking.
Removes from task list, moves to history as crossed out (completed)
Done on evergreen task
Removes from eligibility for x hours, then returns it as an eligible task to be scanned later. There is a default value for number of hours worked that can be edited per task, though a default can be set in settings. (There is a hidden universal two AM ish pass that resets most flags so when you wake up you’re not stuck with stale can’t and dones)
Notates in history
Worked on it
Removes it from eligibility for x hours, then returns to eligibility later.
This is the same behavior as done on an evergreen task, but unlike done on an evergreen task which has a configurable per task number of hours before it is returned as a candidate to be added onto a todo chain, the number of hours a worked on it task is held from being a candidate is set in the settings menu of the app.
Dislodged
Removes a task as a candidate UNTIL THE CURRENT SCAN IS COMPLETED and produces a negative rank signal, making it less likely for it to be scanned next round. It can be scanned immediately next round in theory. Every eligible card will eventually get scanned if you keep going down the list.
The reason why worked on it doesn’t have a per task editable hour field like done on evergreen tasks is because I figured how long until you need to come back to a task could be pretty variable.
You can click on any task and click on return as candidate should you need to return a dislodged, worked on it, worked, or no task back as candidate early.
Tags
Yep, in summary, the hours countdown in tags is until it is a viable candidate again. You can always override most flags and return as candidate early by clicking on a task in all tasks to open its edit pane, and clicking return as candidate to scan it early.
If worked on it takes too long, you can change the default worked on it hours duration in the settings menu, though I believe the default is either eight or sixteen hours. The app originally did not implement done evergreens, and worked on it came first, though in my mind they’re two slightly different ideas that are worth differentiating in history so I / we can be like - oh, okay! I finished this but only merely worked on this.
Thank you for the feedback! I could do to slightly improve documentation. Always LMK if there are other features that would help the core ethos!
Postscript - Unrelated, but I might open a separate thread soon to continue this forum thread conversation at somepoint so that the original topic (digital implementations of forster lists) is cleaner and continuing conversation live under a nice thread of its own.
I wanted to discuss a conceptual principle behind the idea of such lists (in any implementation): as far as I understand, the most ancient item on the list should be added automatically at the beginning of the chain, as the initial point of comparison, to make sure that the stalest item still appears on the to-do, even if I repeatedly do not choose it. (Correct me if I am wrong in my reasoning.)
I cannot say I 100% know the logic implemented in your version, but it feels like this principle clashes with the “evergreen” idea. It looks like, currently, my most ancient item is “reading”, which is an evergreen task. It has been picked as the baseline comparison a few times now already. So, even when I mark it as “done” daily, it is still the baseline the next time. And the actual most stale one-off tasks that I have been ignoring for a while avoid being picked again and again.
I know that I should probably look more in the direction of marking “context” properly and then creating chains based on the contexts. If one context has all repeated admin/home-organization tasks, and another context all work-related one-offs, this will never be a problem.
Oh gosh, you’re absolutely right. I am pushing a change so that the oldest dotted task is one that cannot have been marked as done, but can have been marked as worked on.
See, alltom and my implementation swap out a lot of a forster list for a trueskill ranking algorithm to make evergreen tasks work, similarly to how you would just put an infinity mark next to a task on a sheet of paper. If you have suggestions on how we could rank them alternately, I’m going to move this discussion to this thread linked here. I appreciate all the feedback!
I spent last night fixing a cloud bug that only affects users with a lot of todos, so I’m very glad that didn’t affect you and I squashed it before it arrived at anyone else.
New thread for all feedback. Thank you so much for the feedback, I use this app on a daily basis so your feedback improving it directly makes my life better too, haha.
(I sought out and also got their blessing to post my implementation publicly, so thanks to them for that!)
