Bare bones terminal design is great for power users just like vi is great for power users. The saying is as you get more competent in linux, the more you stay in the shell/terminal with the keyboard and the less you use the mouse. But for ordinary folks ( especially beginners ), they are drawn towards animations, mouse clicking, visual, etc. And most beginners don't advance to the power users stage. My guess is that this pattern will hold in the future.
Learning from Terminals to Design the Future of User Interfaces
361–370 of 379 posts
Re: Learning from Terminals to Design the Future of User Interfaces
#362It's interesting to me that nobody has yet mentioned the Bloomberg terminal, which is basically what the author is describing. It seems Bloomberg "got this" a while back, and dug their heels on for their keyboard-driven terminal-like UI whilst all other shops were going w32, Excel plugins, Web, etc. It's not sexy by any means, looks like it's from the 80s in a mainframe, but it works well for a lot of people. Images,…
> Moving traders and other front-office staff away from BBG terminals is next to impossible due to the drop in efficiency and familiarity.
This is what happens when a technology becomes so entrenched. People get so used to it that it becomes nearly impossible to switch. It's why I laughed when people talked about google docs replacing MS Office. They just underestimate how entrenched Excel is in finance and corporate america overall (especially with the bosses). Hell, even MS Access is entrenched enough that it'll be around for decades longer even though MS is desperate to get their customers to switch to SQL Server.
Re: Learning from Terminals to Design the Future of User Interfaces
#363Earlier quoted context omitted.
But it needs plugins, fish has it builtin. Nothing to configure
I’ve tried fish shell a few times and ended up preferring ZSH. To my understanding Fish shell doesn’t have complete BASH compatibility and it breaks many scripts. It also doesn’t seem to have nearly as wide of an adoption as ZSH so less overall community support in genera. Sure you can just specify the interpreter with hash bang but it’s something worth noting before considering a switch.
Bash itself breaks compatibility with POSIX sh. You can supply --posix, but you can also just use bash -c from fish.
Re: Learning from Terminals to Design the Future of User Interfaces
#364What is the terminal running in the 5th movie? (ThemWare)
Re: Learning from Terminals to Design the Future of User Interfaces
#365The animations serve a valuable purpose, though, especially for new users. They show what's happening. Lots of old UIs (like those running in VT100 emulators) had instant wipes from one view to another, but made it impossible to tell what had happened, or why. Even when I wish animation was faster (like with Spaces, sometimes), I rarely wish it didn't exist at all. I often have people watching me, and with animations…
> What if animations started at a slightly slower speed, and gradually increased in speed the more you used them?
Ubuntu's Unity does this; it keeps track of the number of times you've minimised a window, and as you minimise windows more, it progressively speeds up the animation (maxing out after 100 times).
Source: https://ubuntuforums.org/showthread.php?t=2204321&p=12923084...
Re: Learning from Terminals to Design the Future of User Interfaces
#366Earlier quoted context omitted.
Most successful interactions with Siri/Alexa/Cortana/GoogleNow also fall under the same paradigm. They have some finite number of templates/recipes that they can respond to, and just enough "NLP" to attempt a fuzzy matching between what you ask for, and the triggers to the recipes. The key point is that communication is fundamentally serial, in both voice and basic text consoles, whereas GUIs allow parallel communica…
Maybe because, the cli mode means, you need to remember the commands? In GUI mode, though inefficient, you know exactly where to access help and a few basic params (like dropdown menu on top, usually save under file, cut and copy under edit) that smoothens the learning curve. They have some solid ground from which to start exploring. Whereas under console mode, there is no unifying paradigm. So each tool has a differ…
"In GUI mode, though inefficient, you know exactly where to access help"
I wonder how useful "help" is to the average user. I've personally never been aided in a strange GUI by visiting the help. Usually there is a cryptic search box that returns useless results when I try to look for what I want, or else I'm presented with what is essentially a book to read about the entire philosophy of the interface. *nix manpages/infopages have a similar problem, but Windows help pages seem to be worse for some reason.
Re: Learning from Terminals to Design the Future of User Interfaces
#367Earlier quoted context omitted.
Maybe because, the cli mode means, you need to remember the commands? In GUI mode, though inefficient, you know exactly where to access help and a few basic params (like dropdown menu on top, usually save under file, cut and copy under edit) that smoothens the learning curve. They have some solid ground from which to start exploring. Whereas under console mode, there is no unifying paradigm. So each tool has a differ…
"In GUI mode, though inefficient, you know exactly where to access help" I wonder how useful "help" is to the average user. I've personally never been aided in a strange GUI by visiting the help. Usually there is a cryptic search box that returns useless results when I try to look for what I want, or else I'm presented with what is essentially a book to read about the entire philosophy of the interface. *nix manpages…
Help was the first command that came to my mind. Atleast in my very early days, (this was in early 2000s) I did use lots of help. Maybe help was better then or I was so clueless that even the insipid quagmire of the help pages still proved to be useful.
But in general, I am talking about certain consistency among ui. Say you have opened a new program and you do not know where to start. We can go to 'File' and there is sure to be a "New Document"/"New Object"/"New Diagram"/"New " available to start.
Similarly Edit, Insert, Preferences, Script, Debug and their visual and keyboard access methods are all paradigms that are consistent across GUI.
At the worst case, you can do a systematic exploration of the ui to find all possible actions one can perform. This has to be standardized to CLI also for a shot at widespread adaptation.
Re: Learning from Terminals to Design the Future of User Interfaces
#368Earlier quoted context omitted.
"In GUI mode, though inefficient, you know exactly where to access help" I wonder how useful "help" is to the average user. I've personally never been aided in a strange GUI by visiting the help. Usually there is a cryptic search box that returns useless results when I try to look for what I want, or else I'm presented with what is essentially a book to read about the entire philosophy of the interface. *nix manpages…
Help was the first command that came to my mind. Atleast in my very early days, (this was in early 2000s) I did use lots of help. Maybe help was better then or I was so clueless that even the insipid quagmire of the help pages still proved to be useful. But in general, I am talking about certain consistency among ui. Say you have opened a new program and you do not know where to start. We can go to 'File' and there i…
Yeah, I guess we're talking less about "help" (F1 in Windows, or at least it used to be) than about the user-interface guidelines that mandate the "File" dialog and so. As for doing a "systemic exploration", this is largely the role that manpages or "-h" fills in traditional Unix programs, but you're right that we need a better solution for widespread adoption of a "modern" Slack-y CLI for nontechnical users. Maybe show HELM-style autocomplete "menu" of possible subcommands in the input area or sidebar?
Re: Learning from Terminals to Design the Future of User Interfaces
#369Animation is unnecessary in most cases. Minimal animation can be added where the UI would otherwise be unclear, but other than that it's visual spam. Animation should be like a very thin layer of icing on a cake, but we're getting fed cakes with 4 inches of icing on the top. There is often little aesthetic restraint. Designers should be asking, "how can I remove as much animation as possible?" It spammy and also an a…
I wouldn't say animations are unneecessary. There are cases where they do add something positive. For example I see this open/close animation of yakuake [1] up to a hundred times per day since years and I still like it. I think the key to good animations is that they use the right timing. They are best when you barely even see them. They should transport a notion, but as soon as you see it clearly, you have to wait f…
I personally prefer Yakuake with the animation turned off; it makes it feel really fast.
Re: Learning from Terminals to Design the Future of User Interfaces
#370Earlier quoted context omitted.
Most successful interactions with Siri/Alexa/Cortana/GoogleNow also fall under the same paradigm. They have some finite number of templates/recipes that they can respond to, and just enough "NLP" to attempt a fuzzy matching between what you ask for, and the triggers to the recipes. The key point is that communication is fundamentally serial, in both voice and basic text consoles, whereas GUIs allow parallel communica…
Maybe because, the cli mode means, you need to remember the commands? In GUI mode, though inefficient, you know exactly where to access help and a few basic params (like dropdown menu on top, usually save under file, cut and copy under edit) that smoothens the learning curve. They have some solid ground from which to start exploring. Whereas under console mode, there is no unifying paradigm. So each tool has a differ…
> Like what command is it for help 'h' or 'h?' or 'help' or 'H'?
It's all about smart desing of commands. In your example all of those options could work, plus options like 'he', 'hel', 'help', 'help!!!', 'Help???', and even 'HALP' or 'WTF?'. Combine this with smart autocomplete, and good hints (i.e. I don't understand 'hlp'. Did you mean 'help') and you can mitigate the drawbacks of CLI commands greatly. As for Gmail, you are talking here about keyboard shortcuts, NOT commands, and that's something I completely different IMO.