📗 Want to read A Half-Built Garden by Ruthanna Emrys ISBN: 9781250210999
Came up with and tried a three phase pomodoro technique yesterday for working thru tasks and projects.
This three phase pomodoro cycle repeats and resyncs hourly. The three phases I came up with:
* physical tidying/cleaning
* physical processing
* digital processing
This worked quite well and I got a lot of things done, tasks completed or significantly advanced in ~6 hours.
Many of these were “annoying” or “boring” but often not immediately “necessary” tasks that I had left undone (procrastinated) for many weeks, especially with all the travel I have had in the past two months nevermind first two-thirds of this year.
I took the basic idea of a pomodoro 20-minute timebox¹, figured three of those fit into an hour, and picked three things that were cognitively different enough that switching from one to the other would use different cognitive skills (perhaps different parts of my brain), thus allowing a form of cognitive rest (rather than fatigue, and giving one part of my brain a chance to rest, while using others).
This eliminated the need to take “pomodoro breaks”, whether 5 minutes or 20-30 minutes and it felt nearly effortless (actually fun at times) to cycle through the three phases, repeatedly, for hours on end. Before I knew it six hours had gone by and many tasks had been completed.
The three 20 minute phases have the advantage of quickly determining at any time which phase you should be in by checking your watch/phone for :00-:20, :20-:40, :40-:00. If you happened to be “out of phase”, e.g. “run over” because you were finishing something up, rather than stressing about it, switch to the in-progress phase and pick-up a new task accordingly.
A 20 minute timebox also has the advantage that tasks are less annoying or boring when you know that in less than 20 minutes you will be able to set them down and switch to something else.
There was an iterative sense of expectation of novelty. The expectation of even only a little novelty was enough to make things go more quickly in the present, and even provide a game-like encouragement of see how far I can get with this boring or annoying task in the little time remaining. Could I even complete this one task in less than 20 minutes?
I think repeating three phase pomodoro cycles worked particularly well on a Saturday afternoon when I had very few external interrupts. I think that was key. It gave a sense of momentum, if actual flow², that itself felt like it gave me a source of energy to keep going. I’m not sure it would work during normal work hours in any highly or even partially collaborative environment.
Interruptions for physical needs, moving around, drinking, eating etc. were something that I allowed at any time, and that removed any stress about those too.
I rarely set any count-down timers. A few times when I recognized I was starting or picking up a task that I might get absolutely lost in (such as many digital processing tasks like email), I set an explicit count-down timer for the end of the phase. These timer alarms certainly helped to give me permission to put down that task (for now) and switch, rather than feeling compelled to “complete” it which I know from experience can often take much longer, and leave me feeling more tired, perhaps even too tired to do anything else.
There was also a sense of relief in knowing that even if I didn’t finish a particular task by the end of a phase, I would have the opportunity to pick it right back up in 40 minutes. Or maybe by then I would have decided to work on a different task in that phase.
This three phase pomodoro technique worked well for tasks that are not very cognitively engaging (hence boring or annoying). Such tasks have low context, and thus low context-switching costs, but still benefit from taking mental breaks and resets.
In contrast, any deeply cognitively engaging, thinking, or creative tasks, like inventing, coding, writing, typically have a much higher context-switching costs, and in my experience work better when you can set aside a longer block of time to allow yourself build up all the context and then joyfully explore the depths of whatever it is you’re creating.
That being said, I think some creative tasks (depending on the person) could benefit from time-boxing. Like having a constraint to write a short blog post in the morning before a workout or breakfast. Worth trying such one-off timeboxes or even formal pomodoros and seeing if they help complete some creative tasks faster (or more often) over time.
#productivity #pomodoro #pomodoroTechnique #gtd #gettingThingsDone #Saturday
References:
¹ Apparently I misremembered 20 minutes instead of the typical pomodoro 25 minutes: https://en.wikipedia.org/wiki/Pomodoro_Technique
² https://en.wikipedia.org/wiki/Flow_(psychology)
This three phase pomodoro cycle repeats and resyncs hourly. The three phases I came up with:
* physical tidying/cleaning
* physical processing
* digital processing
This worked quite well and I got a lot of things done, tasks completed or significantly advanced in ~6 hours.
Many of these were “annoying” or “boring” but often not immediately “necessary” tasks that I had left undone (procrastinated) for many weeks, especially with all the travel I have had in the past two months nevermind first two-thirds of this year.
I took the basic idea of a pomodoro 20-minute timebox¹, figured three of those fit into an hour, and picked three things that were cognitively different enough that switching from one to the other would use different cognitive skills (perhaps different parts of my brain), thus allowing a form of cognitive rest (rather than fatigue, and giving one part of my brain a chance to rest, while using others).
This eliminated the need to take “pomodoro breaks”, whether 5 minutes or 20-30 minutes and it felt nearly effortless (actually fun at times) to cycle through the three phases, repeatedly, for hours on end. Before I knew it six hours had gone by and many tasks had been completed.
The three 20 minute phases have the advantage of quickly determining at any time which phase you should be in by checking your watch/phone for :00-:20, :20-:40, :40-:00. If you happened to be “out of phase”, e.g. “run over” because you were finishing something up, rather than stressing about it, switch to the in-progress phase and pick-up a new task accordingly.
A 20 minute timebox also has the advantage that tasks are less annoying or boring when you know that in less than 20 minutes you will be able to set them down and switch to something else.
There was an iterative sense of expectation of novelty. The expectation of even only a little novelty was enough to make things go more quickly in the present, and even provide a game-like encouragement of see how far I can get with this boring or annoying task in the little time remaining. Could I even complete this one task in less than 20 minutes?
I think repeating three phase pomodoro cycles worked particularly well on a Saturday afternoon when I had very few external interrupts. I think that was key. It gave a sense of momentum, if actual flow², that itself felt like it gave me a source of energy to keep going. I’m not sure it would work during normal work hours in any highly or even partially collaborative environment.
Interruptions for physical needs, moving around, drinking, eating etc. were something that I allowed at any time, and that removed any stress about those too.
I rarely set any count-down timers. A few times when I recognized I was starting or picking up a task that I might get absolutely lost in (such as many digital processing tasks like email), I set an explicit count-down timer for the end of the phase. These timer alarms certainly helped to give me permission to put down that task (for now) and switch, rather than feeling compelled to “complete” it which I know from experience can often take much longer, and leave me feeling more tired, perhaps even too tired to do anything else.
There was also a sense of relief in knowing that even if I didn’t finish a particular task by the end of a phase, I would have the opportunity to pick it right back up in 40 minutes. Or maybe by then I would have decided to work on a different task in that phase.
This three phase pomodoro technique worked well for tasks that are not very cognitively engaging (hence boring or annoying). Such tasks have low context, and thus low context-switching costs, but still benefit from taking mental breaks and resets.
In contrast, any deeply cognitively engaging, thinking, or creative tasks, like inventing, coding, writing, typically have a much higher context-switching costs, and in my experience work better when you can set aside a longer block of time to allow yourself build up all the context and then joyfully explore the depths of whatever it is you’re creating.
That being said, I think some creative tasks (depending on the person) could benefit from time-boxing. Like having a constraint to write a short blog post in the morning before a workout or breakfast. Worth trying such one-off timeboxes or even formal pomodoros and seeing if they help complete some creative tasks faster (or more often) over time.
#productivity #pomodoro #pomodoroTechnique #gtd #gettingThingsDone #Saturday
References:
¹ Apparently I misremembered 20 minutes instead of the typical pomodoro 25 minutes: https://en.wikipedia.org/wiki/Pomodoro_Technique
² https://en.wikipedia.org/wiki/Flow_(psychology)
Recently finished this (good, heavy, tip-of-an-iceberg) book on influence operations:
https://martymcgui.re/2024/09/05/222732/
Now watching how it’s playing out in today’s (war and commercial) games industries. 😳
📕 Finished reading Stories Are Weapons: Psychological Warfare and the American Mind by Annalee Newitz ISBN: 9780393881516
Han Dynasty
📗 Want to read American War by Omar El Akkad ISBN: 9781101973134
📗 Want to read Says Who?: A Kinder, Funner Usage Guide for Everyone Who Cares about Words by Anne Curzan ISBN: 9780593444092
📗 Want to read Mobility by Lydia Kiesling ISBN: 9781638930563
📗 Want to read How We Show Up: Reclaiming Family, Friendship, and Community by Mia Birdsong ISBN: 9781580058070
📗 Want to read Emergent Strategy: Shaping Change, Changing Worlds by Adrienne Maree Brown ISBN: 9781849352604
Fourth Avenue Pub
✏️ I want the Read Write Suggest-Edit Accept-Edit Update Web.
The consumer Infinite Scroll Web leaves us feeling empty.
Too few of us participate in the Read Write Web, whether with personal sites or Wikipedia.
A week ago when we wrapped up #IndieWebCamp Portland and I was reading Kevin Marks (@kevinmarks@indieweb.social) live-tooting of the demos¹, I noticed a few errors, typos or miscaptures, and pointed them out in-person.
Kevin was able to quickly edit his toots and update them for anyone reading, thanks to #Mastodon’s post editing feature and its support of #ActivityPub Updates. But this shouldn’t require being in the same room, whether IRL or chat.
We should be able to suggest edits to each other’s posts, as easily as we can reply and add a comment.
13 years ago I wrote²:
“The Read Write Web is no longer sufficient. I want the Read Fork Write Merge Web.”
Now I want the Read Write Suggest-Edit Accept-Edit Update Web.
The ↪ Reply button is fairly ubiquitous in modern post user interfaces (UIs).
Why not also a ✏️ Suggest Edit button, to craft a fix for a typo, grammar, or other minor error, and send the author for their review, and acceptance or rejection? Perhaps viewable only by the suggester and the author, to avoid "performative" suggested edits.
If the author’s posts provide revision histories, when a suggested edit is accepted, a post’s history could show the contributor of the edit.
Instead of asking Kevin in-person, what if I could have posted special "Suggested Edit" responses in reply to his toots, for which he would receive special notifications, and could choose to one-click accept and update (or further edit) his toots?
To enable such UIs and interactions across servers and implementations, we may need a new type of response³, perhaps with a special property (or more) to convey the edits being suggested.
There is documentation of this and similar use-cases, prior art / UIs, as well as some brainstorming on the #IndieWeb wiki:
* https://indieweb.org/edit
Our interaction after IndieWebCamp has inspired me to take another look at how can we design and prototype solutions to this problem.
For now, if you host your blog and posts as static files on GitHub (or equivalent), you could add a button like this to your posts alongside Like, Reply, Repost buttons:
✏️ Suggest Edit
and link it to an edit URL for the static file for the post.
I don’t use GitHub static files myself for posts, but here’s an example of such an edit link for one of my projects:
https://tantek.com/github/cassis/edit/main/README.md
This will start the process of creating a “pull request”, GitHub’s jargon⁴ for a “suggested edit”.
After completing GitHub’s ceremony of entering multiple text fields (summary & description), and multiple clicks to create said “pull request”, it’ll be sent to the author to review. Presuming the author likes the suggested edit, they can perform the other half of GitHub’s jargon-filled ceremonies to “Merge” or “Squash & Merge”, “Delete fork”, etc. to accept the edit.
It’s an awkward interaction⁵, however useful for at least prototyping a ✏️ Suggest Edit button on sites that store their posts as files in GitHub. Certainly worthy of experimenting with and gathering experience to design and build even better interactions.
We can start with the shortest path to getting something working, then learn, iterate, improve, repeat.
#readWriteWeb #editableWeb #suggestEdit #acceptEdit
References:
¹ https://indieweb.social/@kevinmarks/113025295600067213
² https://tantek.com/2011/174/t1/read-fork-write-merge-web-osb11
³ https://indieweb.org/responses
⁴ The phrase “pull request” was derived from the git command: “git request-pull” according to https://www.reddit.com/r/git/comments/nvahcp/comment/h12hzj7/
⁵ “edits” in GitHub require taking far more steps, and navigating far more jargon, then say, Wikipedia pages, which come down to “Edit” and “Save”. We should aspire to Wikipedia’s simplicity, not GitHub’s ceremonies.
This is post 20 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/242/t1/indiewebcamp-portland
→ https://tantek.com/2024/246/t1/adventures-indieweb-activitypub-bridgy-fed
The consumer Infinite Scroll Web leaves us feeling empty.
Too few of us participate in the Read Write Web, whether with personal sites or Wikipedia.
A week ago when we wrapped up #IndieWebCamp Portland and I was reading Kevin Marks (@kevinmarks@indieweb.social) live-tooting of the demos¹, I noticed a few errors, typos or miscaptures, and pointed them out in-person.
Kevin was able to quickly edit his toots and update them for anyone reading, thanks to #Mastodon’s post editing feature and its support of #ActivityPub Updates. But this shouldn’t require being in the same room, whether IRL or chat.
We should be able to suggest edits to each other’s posts, as easily as we can reply and add a comment.
13 years ago I wrote²:
“The Read Write Web is no longer sufficient. I want the Read Fork Write Merge Web.”
Now I want the Read Write Suggest-Edit Accept-Edit Update Web.
The ↪ Reply button is fairly ubiquitous in modern post user interfaces (UIs).
Why not also a ✏️ Suggest Edit button, to craft a fix for a typo, grammar, or other minor error, and send the author for their review, and acceptance or rejection? Perhaps viewable only by the suggester and the author, to avoid "performative" suggested edits.
If the author’s posts provide revision histories, when a suggested edit is accepted, a post’s history could show the contributor of the edit.
Instead of asking Kevin in-person, what if I could have posted special "Suggested Edit" responses in reply to his toots, for which he would receive special notifications, and could choose to one-click accept and update (or further edit) his toots?
To enable such UIs and interactions across servers and implementations, we may need a new type of response³, perhaps with a special property (or more) to convey the edits being suggested.
There is documentation of this and similar use-cases, prior art / UIs, as well as some brainstorming on the #IndieWeb wiki:
* https://indieweb.org/edit
Our interaction after IndieWebCamp has inspired me to take another look at how can we design and prototype solutions to this problem.
For now, if you host your blog and posts as static files on GitHub (or equivalent), you could add a button like this to your posts alongside Like, Reply, Repost buttons:
✏️ Suggest Edit
and link it to an edit URL for the static file for the post.
I don’t use GitHub static files myself for posts, but here’s an example of such an edit link for one of my projects:
https://tantek.com/github/cassis/edit/main/README.md
This will start the process of creating a “pull request”, GitHub’s jargon⁴ for a “suggested edit”.
After completing GitHub’s ceremony of entering multiple text fields (summary & description), and multiple clicks to create said “pull request”, it’ll be sent to the author to review. Presuming the author likes the suggested edit, they can perform the other half of GitHub’s jargon-filled ceremonies to “Merge” or “Squash & Merge”, “Delete fork”, etc. to accept the edit.
It’s an awkward interaction⁵, however useful for at least prototyping a ✏️ Suggest Edit button on sites that store their posts as files in GitHub. Certainly worthy of experimenting with and gathering experience to design and build even better interactions.
We can start with the shortest path to getting something working, then learn, iterate, improve, repeat.
#readWriteWeb #editableWeb #suggestEdit #acceptEdit
References:
¹ https://indieweb.social/@kevinmarks/113025295600067213
² https://tantek.com/2011/174/t1/read-fork-write-merge-web-osb11
³ https://indieweb.org/responses
⁴ The phrase “pull request” was derived from the git command: “git request-pull” according to https://www.reddit.com/r/git/comments/nvahcp/comment/h12hzj7/
⁵ “edits” in GitHub require taking far more steps, and navigating far more jargon, then say, Wikipedia pages, which come down to “Edit” and “Save”. We should aspire to Wikipedia’s simplicity, not GitHub’s ceremonies.
This is post 20 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/242/t1/indiewebcamp-portland
→ https://tantek.com/2024/246/t1/adventures-indieweb-activitypub-bridgy-fed
Had a great time at IndieWebCamp Portland 2024 this past Sunday — our 10th IndieWebCamp in Portland!
https://events.indieweb.org/2024/08/indiewebcamp-portland-2024-8bucXDlLqR0k
Being a one day #IndieWebCamp, we focused more on making, hacking, and creating, than on formal discussion sessions.
Nearly everyone gave a brief personal site intro with a summary of how they use their #IndieWeb site and what they would like to add, remove, or improve.
* https://indieweb.org/2024/Portland/Intros
There were lots of informal discussions, some in the main room, on the walk to and from lunch, over lunch in the nearby outdoor patio, or at tables inside the lobby of the Hotel Grand Stark.
We wrapped up with our usual Create Day¹ Demos session, live streamed for remote attendees to see as well. Lots of great demos of things people built, designed, removed, cleaned-up, documented, and blogged! Everyone still at the camp showed something on their personal site!
* https://indieweb.org/2024/Portland/Demos
Group photo and lots more about IndieWebCamp Portland 2024 at the event’s wiki page:
* https://indieweb.org/2024/Portland
Thanks to everyone who pitched in to help organize IndieWebCamp Portland 2024! Thanks especially to Marty McGuire (@martymcgui.re) for taking live notes during both the personal site intros and create day demos, to Kevin Marks (@kevinmarks@indieweb.social @kevinmarks@xoxo.zone @kevinmarks) for the IndieWebCamp live-tooting, and Ryan Barrett (@snarfed.org) for amazing breakfast pastries from Dos Hermanos.
The experience definitely raised our hopes and confidence for returning to Portland in 2025.²
References:
¹ https://indieweb.org/Create_Day
² https://indieweb.org/Planning#Portland
This is post 19 of #100PostsOfIndieWeb. #100Posts #2024_238
← https://tantek.com/2024/238/t3/indiewebcamp-auto-linking
→ https://tantek.com/2024/245/t1/read-write-suggest-edit-web
https://events.indieweb.org/2024/08/indiewebcamp-portland-2024-8bucXDlLqR0k
Being a one day #IndieWebCamp, we focused more on making, hacking, and creating, than on formal discussion sessions.
Nearly everyone gave a brief personal site intro with a summary of how they use their #IndieWeb site and what they would like to add, remove, or improve.
* https://indieweb.org/2024/Portland/Intros
There were lots of informal discussions, some in the main room, on the walk to and from lunch, over lunch in the nearby outdoor patio, or at tables inside the lobby of the Hotel Grand Stark.
We wrapped up with our usual Create Day¹ Demos session, live streamed for remote attendees to see as well. Lots of great demos of things people built, designed, removed, cleaned-up, documented, and blogged! Everyone still at the camp showed something on their personal site!
* https://indieweb.org/2024/Portland/Demos
Group photo and lots more about IndieWebCamp Portland 2024 at the event’s wiki page:
* https://indieweb.org/2024/Portland
Thanks to everyone who pitched in to help organize IndieWebCamp Portland 2024! Thanks especially to Marty McGuire (@martymcgui.re) for taking live notes during both the personal site intros and create day demos, to Kevin Marks (@kevinmarks@indieweb.social @kevinmarks@xoxo.zone @kevinmarks) for the IndieWebCamp live-tooting, and Ryan Barrett (@snarfed.org) for amazing breakfast pastries from Dos Hermanos.
The experience definitely raised our hopes and confidence for returning to Portland in 2025.²
References:
¹ https://indieweb.org/Create_Day
² https://indieweb.org/Planning#Portland
This is post 19 of #100PostsOfIndieWeb. #100Posts #2024_238
← https://tantek.com/2024/238/t3/indiewebcamp-auto-linking
→ https://tantek.com/2024/245/t1/read-write-suggest-edit-web
Nice #IndieWebCamp discussion session with Kevin Marks (@kevinmarks@indieweb.social @kevinmarks@xoxo.zone @kevinmarks) on the topic of auto-linking¹.
I’ve implemented an auto_link function² that handles quite a few use-cases of URLs (with or without http: or https:), @-name @-domain @-domain/path @-@-handles, hashtags(#), and footnotes(^).
Much of it is based on what I’ve seen work (or implemented) on sites and software, and some of it is based on logically extending how people are using text punctuation across various services.
It may be time for me to write-up an auto-link specification based on the algorithms I’ve come up with, implemented, and am using live on my site. All the algorithms work fully offline (none of them require querying a site for more info, whether well-known or otherwise), so they can be used in offline-first authoring/writing clients.
I have identified three logical chunks of auto-linking functionality, each of which has different constraints and potential needs for local to the linking context information (like hashtags need a default tagspace). Each would be a good section for a new specification. Each is used by this very post.
* URLs, @-s, and @-@-s
* # hashtags
* ^ footnotes
#IndieWeb #autoLink #hashtag #hashtags #footnote #footnotes
Previously, previously, previously:
* https://tantek.com/2024/070/t1/updated-auto-linking-mention-use-cases
* https://tantek.com/2023/100/t1/auto-linked-hashtags-federated
* https://tantek.com/2023/043/t1/footnotes-unicode-links
* https://tantek.com/2023/019/t5/reply-domain-above-address-and-silo
References:
¹ https://indieweb.org/autolink
² https://github.com/tantek/cassis/blob/main/cassis.js
This is post 18 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/238/t1/indiewebcamp-portland
→ https://tantek.com/2024/242/t1/indiewebcamp-portland
I’ve implemented an auto_link function² that handles quite a few use-cases of URLs (with or without http: or https:), @-name @-domain @-domain/path @-@-handles, hashtags(#), and footnotes(^).
Much of it is based on what I’ve seen work (or implemented) on sites and software, and some of it is based on logically extending how people are using text punctuation across various services.
It may be time for me to write-up an auto-link specification based on the algorithms I’ve come up with, implemented, and am using live on my site. All the algorithms work fully offline (none of them require querying a site for more info, whether well-known or otherwise), so they can be used in offline-first authoring/writing clients.
I have identified three logical chunks of auto-linking functionality, each of which has different constraints and potential needs for local to the linking context information (like hashtags need a default tagspace). Each would be a good section for a new specification. Each is used by this very post.
* URLs, @-s, and @-@-s
* # hashtags
* ^ footnotes
#IndieWeb #autoLink #hashtag #hashtags #footnote #footnotes
Previously, previously, previously:
* https://tantek.com/2024/070/t1/updated-auto-linking-mention-use-cases
* https://tantek.com/2023/100/t1/auto-linked-hashtags-federated
* https://tantek.com/2023/043/t1/footnotes-unicode-links
* https://tantek.com/2023/019/t5/reply-domain-above-address-and-silo
References:
¹ https://indieweb.org/autolink
² https://github.com/tantek/cassis/blob/main/cassis.js
This is post 18 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/238/t1/indiewebcamp-portland
→ https://tantek.com/2024/242/t1/indiewebcamp-portland
At Bar del Pla in Barcelona
If this is hell, I don’t wanna go to heaven.
Happy Labor Day weekend y’all! 🥳