[sheraz]

I think the author echos some things I've been feeling about my work environment (the desktop). There is a lot of friction that comes when each of my applications wants to be its own immersive experience. My take-away from his post is that he seems to be iterating away from those rich, colorful, and distracting interfaces to something that is kind of interface-less.

This, too, is my dream (or sorts).

- Spotify without the spotify interface. (Google Music, in his case)

- Slack without the slack interface (IRC, I guess)

- Email without the web-client or sluggish Apple mail interface.

I know there are CLI for each of those use cases. But it takes commitment to learn and get them working to your liking.

[cmiles74]

I think I'd go a little further, even: not only is there friction moving from one "immersive" application to another, there seems to be some expenditure of energy necessary to actually make the switch. Each fights in it's own way, not only to deliver on it's function but to somehow tempt you into spending ever more time with that particular application.

A console or text-based interface seems like a big equalizer; for sure it's often easier to manage a console application but it puts hard limits on how much attention these applications may siphon away. Perhaps it's easier for my attention to wander than others, but when the task at hand is particularly boring or unpleasant, I find I can waste quite a lot of time browsing through music or "catching up" on likely useless Slack conversations. Since I've moved them to a text-based interface, I do feel I am wasting time like this far less often.

[SanderSantema]

This is exactly the reason why I've tried to port as much stuff as I can to my terminal. Productivity in the sense of using a program faster is a nice by-product, but preserving my attention is way more important to me. To me it seems nowadays you don't pay hard cash for things online, you pay in attention. I'm trying to get my digital experience to serve me again instead of me serving to something which I'm using.

On a sidenote: Any tips on making my digital experience less attention focused? For instance I would really like to use surf or uzbl but they don't have support for MacOS and I would still need an adblocker/ reader mode.

[b0rsuk]

Actually I noticed something related with websites. It's not that they want to be "an immersive experience", they want to be the immersive experience. In the world of free, apps and websites compete for our attention. This is what "please register" is about. Every website wants to be your home of sorts, track you, give you badges for activity, wish you happy birthday or new year. Few of them recognize that you just want them to be useful. Just use them and get the job done.

[sk8ingdom]

This is generally my goal with Emacs customization. I'm basically just using APIs (Spotify, Outlook Exchange Server, myFittnessPal, Reddit, HN) in a common Emacs interface. The downside, of course, is that it's a lot of work to develop and maintain.

[0x445442]

The problem is applications. Applications, even within an environment of standardized widgets, still present a wildly disjointed experience to users. Now you throw in the infinite number of UI paradigms available with HTML/CSS/JS and you have a modern desktop that requires so much context switching between one use case and another that users who are trying to be more efficient with their computing are slammed in the face.

I believe that's why "power" users gravitate to the command line. With the command line and terminal you have a much more cohesive experience with your computing.

Jeff Raskin with the Canon Cat (http://www.canoncat.org/) and his son Aza with Enso (https://therichwebexperience.com/blog/aza_raskin/2007/01/ens...) and later with Ubiquity (https://venturebeat.com/2008/08/27/mozilla-labs-aza-raskin-t...) attempted to address this problem.

Actually, the first time I started to recognize this issue was back in 1996 when I read about David Galernter's Lifestreams (http://www.cs.yale.edu/homes/freeman/lifestreams.html).

The current state of affair;, Emacs goes quite a ways to solving this problem. Where Emacs falls down is the ability render html content and graphical content in general the way a browser does. If Emacs could render graphical content then I think it could be used to implement my ideal UI.

My ideal UI would be this:

1. Command input component similar to browser omni bars or Emacs M-X interface which parses command input and delegates to service.

2. Result of command entry is a list of 0-N items presented in a tree list view with the first item in the list selected by default. Think old Usenet UI.

3. Any item selected in 2 renders its own view. Again think of old Usenet UI. However instead of just text this item renderer can be anything. Text, graphics, embedded video, etc.

4. The resultant list of any command can, in turn, be used as input to a following command. Think Unix pipe.

The result is an interface that's a hybrid of the command line and Emacs M-x but is modern enough to handle more than text rendering. With this interface you don't develop applications but agents/verbs that return items and you provide renderers for each item

[fao_]

> 1. Command input component similar to browser omni bars or Emacs M-X interface which parses command input and delegates to service.

You might find what you're looking for in dmenu: https://tools.suckless.org/dmenu/

[0x445442]

Yeah, so dmenu might potentially cover the command input bit but AFAIK it's really just like Enso, QuickSilver, Launchy etc. What I'm thinking of doesn't really index executables per say but allows for the registration of commands.

What I'm thinking of is limited in scope to "commands" that are registered with the component. Maybe dmenu can be bent to this use case; thanks for the link.

[curioussavage]

I found a really cool project that makes a sublime style command menu for any gtk app https://github.com/p-e-w/plotinus. Still need to try it but it sounds awesome

[0x445442]

That's cool... It seems KDE's KRunner is pretty extendable as well. (https://techbase.kde.org/Development/Tutorials/Plasma4/Abstr...)

[fao_]

dmenu at it's core takes a list of input (dmenu_path), fuzzy matches it, and then just fork()s off or something like that, it's tiny so it'd be trivial to alter it so it does something else with that match. You could hook it up to xdotool or something and have it send a command to alter the current X app or whatever.

[zeckalpha]

What are executables on your PATH but registered commands?

[walshemj]

You mean a MUA (Mail User Agent) like outlook ?