Great idea. As a "visual type" this would be so much more intuitive to decipher. I prefer TUIs over GUI exactly because they're simpler and work hard to focus on the essential. This is low hanging fruit to enhance TUIs.
Agree. Gist of the FA is about "calm technology". Title should reflect it better.
Also agree on everything author mentions. I can't attest to all examples but I know what a UI is.
Author mentions center of focus of attention. We should hear more often about the periphery of our attention field. Its bandwidth so to speak is a magnitude lower compared to the center but it's still there and can guide some decisions quite unintrusively to flow.
(Major) eye movements are a detriment to attention, which itself should be treated like a commodity (in case of a UI thousands use, moreso like a borrowed commodity).
I made my own web app using boring technology(1). It's not available anywhere since it's completely tailored to my own needs so probably not useful to anyone else. Also some parts of the code need cleanup and there is no documentation.
(1) SQLite/Django/Bootstrap5/Unpoly app. SQLite is used for all the data and the full text search. Huey is used for background tasks. Tinytags gets metadata from audio files. LastFM API provides similar artists functionality. YT-DLP is used to fetch music that is not easy (for me) to get (no bandcamp, only on streaming, old stuff not easy to find...). Bootstrap provides a clean look and the usual responsive stuff. Dropbox API is used to maintain a copy of the music files in my dropbox account. The app currently handles a collection of 70k files and runs on a raspberrypi behind the caddy web server.
They mentioned tabbing and screen readers quite a few times.
I found the "jumping" ordering quite concerning but further down in the article they mention "tolerance" that seems to be a way to allow the layout to be more consistent in terms of ordering.
In my opinion author fails to make distinction between small tasks (atomic tasks) and complicated tasks. Also misses to mention 2 important concepts: flow state and friction.
For small tasks you should absolutely strive to remove any friction (examples: editor undo, dictionary lookup, make a note).
Complicated tasks (writing a blog post) are a different beast:
- needs to be broken down in small tasks
- while carving out small tasks needs finesse and fluency
- small tasks need to be frictionless
But, principal difference is you need to load your working memory (small but fast (RAM)) (e.g. read documentation, browse a repo, connect to your work from yesterday, ...). Loading your 'RAM' is an investment. And your ROI shrinks if you need to collect the threads from scratch again and again. So, IMO it's not about moving fast but moving uninterrupted. Moving uninterrupted produces flow state and gives you the impression of moving fast (despite your moving only slowly but steadily). Speed becomes irrelevant if you're moving steadily forward.
The blog post shows another problem if your working 'too long' on something: you need to reconnect from scratch to your original idea/intention, which might change. So your creation may become an incoherent medley, you begin to miss the forest for the trees, or worse: you begin to doubt yourself.
I like to think about the mind as an extensible limb that can extend in the direction of a distant goal, but can only span small distances. It's literally like the mind walking. Making steps too big is like moving trying not to touch the floor. It needs unreasonably more effort and is long-term exhausting. You may even break down and think you're a failure. But standing on one leg for too long is exhausting too.
You may laugh about the author who had this post 6 years in the making, but it's extremely important to work by a mental model that doesn't exhaust you, but works FOR you.
"I never understand anything until I have written about it."
– Horace Walpole
"If you’re thinking without writing, you only think you’re thinking."
– Leslie Lamport
reply