![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
someone once said that emacs is a general TUI platform. I agree, but i'm not sure that it's a great one -- it seems unclear to me how to make a new TUI easily, and it also seems to me like existing once (e.g. magit) aren't particularly discoverable
---
conductr 1 day ago
| parent | next [–] |
I don’t think productivity was ever the goal of this software. It was to have a record that is standard, digital, transferable, etc. Doctors fought it as long as they could because they knew what it meant for them.
I remember pretty early demos in early/mid 2000s when I was doing some clinical grunt work in college. I had written some software to make my department’s life easier so I was offered up as the hospital’s liaison for the software evaluation. This is when I formed my “never replace a terminal based app, with a GUI based app and expect productivity gains” theory. Everyone working in the hospital knew the terminal app, they type in some random 3 letter code and a screen would pop up. Then they would memorize how many tabs each field was apart from each other. Without a mouse, people could just hum along imputing data a blazing speed once some muscle memory was in place. Everyone had little cheat sheets printed out for the less frequently used commands/codes. When you replace this with a browser/desktop GUI with selectors and drop downs and reactive components of GUI, it tends to 1) require mouse usage for most people and 2) lose the ability to do this quick data entry I described. The pretty interface becomes a steady stream of speed bumps that reduce productivity. Since then I’ve witnessed it in banking and other industries too.
reply
StillBored? 1 day ago
| root | parent | next [–] |
IMHO, this is because the people writting GUI's these days are mostly incompetent, or hamstrung by "web" technologies.
Early GUI's didn't have the problem you describe because they were designed as discovery mechanisms to the underlying function. AKA, the idea was that after clicking File->Save a dozen times you would remember the keyboard accelerators displayed on the right hand side of the menu. Or if nothing else, Remember that the F in File was underlined along with the "S" in Save (or whatever). Which would lead people to just press ctrl-s, or Alt-F, S. Then part of testing was making sure that that the tab key moved appropriately from field to field,etc.
I remember in the 1990's spending a fair amount of time doing keyboard optimization in a "reporting" application I wrote (which also had an early touchscreen) for use by people who's main job wasn't using a computer. Then we would have "training" classes and watch how they learned to use it.
So, much of this has been lost with modern "GUI's", even the OS vendors which should have been keeping their human interface guidelines updated, did stupid things like _HIDE_ the accelerator keys in windows if the user wasn't pressing the Alt key. Which destroys discoverability, because now users don't have the shortcut in their face. Nevermind the recent crazy nonsense where links and buttons are basically the same thing, sometimes triggering crazy behaviors like context menus and the like. Or just designing UI's where its impossible to know if something is actually a button because the link text is the same color as the rest of the text on the screen..
reply
deadbunny 1 day ago
| root | parent | next [–] |
In my experience the rise of GUIs over TUIs they lost the command buffering. If you knew what you were doing with a well designed TUI you could hit a sequence of keys that would be buffered and "replayed" as the next screen(s) loaded. Hit a sequence of commands in a GUI and they'll just get lost after the first one as the app/website loads.
reply
int_19h 1 day ago
| root | parent | next [–] |
What you describe is the natural outcome of having a single message loop with synchronous handlers, and describes e.g. Win32 just as well - a sequence of keys would simply end up as the corresponding sequence of window messages in the queue, and processed in order.
Where we partially lost that is when UX started to get async. It's not fundamentally incompatible with well-ordered input messages, but in practice, people who write async code all too often forget that it's async all the way (and not just for their favorite scenario). And so you get travesties such as textboxes that let you type text into them, and then erase all that when the app or the page is "fully loaded".
reply
orangepurple 1 day ago
| root | parent | prev | next [–] |
Amen. I talked to some guys in their 20s in the oil and gas industry in Houston and they preferred using the old TUI systems because of this exact reason.
reply
sn41 1 day ago
| root | parent | prev | next [–] |
On a related note: the same is true for Keyboard Macros in Emacs, Vim etc. I often send a bunch of related, but each slightly different from the others, using Emacs keyboard macros and gnus. Felt great the first time I discovered it, saved perhaps 3 hours I would have spent writing and debugging a script.
reply
---
https://kellyjonbrazil.github.io/jc/
---
dotancohen 3 days ago
| parent | next [–] |
If you're bringing that up, then this is the place to spread the word about my dream of a stdmeta file descriptor.
https://unix.stackexchange.com/questions/197809/propose-addi...
Just like we have stdout and stderr, header lines such as those produced by `ps` should be printed to stdmeta. Curl is the worse offender here, outputing meta lines to stderr instead of stdout. A stdmeta file descriptor would make it clear what is data, what is an error, and what is _describing_ the data.
reply
runlevel1 3 days ago
| root | parent | next [–] |
That reminds me of something I've wanted for quite a while:
A ringbuffer filetype. Similar to a named pipe file (see: fifo(7)[^1]), but without consuming the contents on read and automatically rotating out the oldest lines.
Of course, there would be some complexities around handling read position as lines are being rotated out from under you.
[1]: https://linux.die.net/man/7/fifo
reply
---
https://borretti.me/article/shells-are-two-things https://lobste.rs/s/sqtnxf/shells_are_two_things ---
https://lobste.rs/s/ijpr36/fascination_awk
---
https://jalammar.github.io/visual-interactive-guide-basics-neural-networks/
---
https://simonwillison.net/2023/Sep/30/cli-tools-python/
note: e likes the 'click' lib for options
---
