Earlier quoted context omitted.
You can get all of that with Electron-based terminals. Perhaps take a look at Hyper.
I downloaded Hyper on your recommendation. I can't see how it supports inline multimedia. What am I missing?
It doesn't.
Learning from Terminals to Design the Future of User Interfaces
341–350 of 379 posts
Re: Learning from Terminals to Design the Future of User Interfaces
#342The 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…
I agree. I've long thought that animation could potentially make it much clearer what's going on in Vim. Like if the user types 'das' to delete the current sentence, and it quickly highlights the text to be deleted, and then shows it shrinking away, as the text that was following it moves in to take its place. (Obviously, you'd want the animation to happen pretty quickly). Such animation could make it clearer what th…
I'd suggest just switching to movement first, by way of visual mode. "v" turns on visual mode, "as" selects/highlights the sentence, then "d" to delete it or escape to return to normal mode.
Re: Learning from Terminals to Design the Future of User Interfaces
#343Earlier quoted context omitted.
Actually natural language scales quite well. Aza Raskin and his father Jeff did a lot of good work in this area. The discoverability of commands in a system like Emacs is much more powerful than a menu based system. In fact, I bet most people navigate the web now days by typing part of the URL in the omni bar and letting the browser fuzzy match versus mainting large bookmark lists.
I’m accustomed to typing “s” for StackOverflow, “g” for GitHub, “gm” for Gmail, and probably several others I don’t even realize. This sort of “smart” / reachable interface seems like an improvement over having to type entire words over and over. Is there a terminal with similar ability?
I use ctrl+r for this.
Re: Learning from Terminals to Design the Future of User Interfaces
#344Earlier quoted context omitted.
Gosh TOPS-20 had this back in the early 1980s (and this is why bash has readline...)
Yet there's no standard way for system and user programs to expose their parameters and help to the command line, like most TOPS-20 programs did. So bash's completion and help facilities pale in comparison.
PowerShell has this; all cmdlet parameters are parsed by the PowerShell environment, so you don't have to write argument parsing code over and over; parameters to cmdlets are a standard form with many using the same common names where it makes sense.
Because of that design they are long and readable words but tab completable, and ctrl-space will bring up a menu of available matches starting with what you've typed so far.
Re: Learning from Terminals to Design the Future of User Interfaces
#345Earlier quoted context omitted.
Yet there's no standard way for system and user programs to expose their parameters and help to the command line, like most TOPS-20 programs did. So bash's completion and help facilities pale in comparison.
Indeed Don, why don't you extend gnu getopt to generate a special ELF section with an argument grammar and then modify bash to load this section? Shouldn't take too long and then this feature would become automatic!
Accessibility demands Tourette Syndrome Compatible noise word support.
Re: Learning from Terminals to Design the Future of User Interfaces
#346I wrote a comment under a different post just a few days ago. My comment got _way_ out of hand and wasn't as articulate as I had hoped. But the salient point I made with it is simple and applies equally well to this article. UI is hard. User interfaces seems really simple. Every programmer I know has looked at a UI and thought to themselves "I can code that in an hour!" and then ended up spending weeks, sometimes _mo…
Will we ever solve UI? UI is the meeting place of tech and user, and in a sense it is THE problem for humanity right now. UI informs how we tend to use the internet, and for example we are currently involved with UIs that tend towards consumption (e.g. discovery mechanisms, feeds, etc). To solve UI would imply a certain optimal way to live our lives, if that exists. I agree with you that UI is unsolved and extremely…
> we are currently involved with UIs that tend towards consumption
Astute observation. Clearly this relates heavily to our culture of consumption and the asymmetry of creation/consumption.
But I wonder if another important part of this is related to the divide between how humans learn to do things and how computers can't teach humans very well. If we could automate showing people how to accomplish their goals, we'd be empowering creatives. So far, this task is relegated to youtube videos (e.g. "How do I make two shapes into one shape in Adobe Illustrator?").
Re: Learning from Terminals to Design the Future of User Interfaces
#347Earlier quoted context omitted.
Emacs’ Dired mode lets you interact with the file system this way. Imagine the output of ‘ls -l’ as an editable document — seeing this in action was one of the killer features that made me an Emacs user.
What's an Emacs? Running that command just seems to reduce my disk quota. The functionality you're describing sounds pretty much like vidir (from moreutils[1]), though. [1] https://joeyh.name/code/moreutils/
vidir is a low-fidelity imitation of Emacs dired mode. Emacs has had dired since at least the 80's.
Re: Learning from Terminals to Design the Future of User Interfaces
#348Re: Learning from Terminals to Design the Future of User Interfaces
#349Earlier quoted context omitted.
Indeed Don, why don't you extend gnu getopt to generate a special ELF section with an argument grammar and then modify bash to load this section? Shouldn't take too long and then this feature would become automatic!
Accessibility demands Tourette Syndrome Compatible noise word support.
I am sure that can be controlled by $LOCALE
Re: Learning from Terminals to Design the Future of User Interfaces
#350Earlier quoted context omitted.
https://en.wikipedia.org/wiki/Learning_curve > The familiar expression "a steep learning curve" is intended to mean that the activity is difficult to learn, although a learning curve with a steep start actually represents rapid progress.
Well, progress along the Y axis is only achieved if progress is made on the X axis too. If the curve is too steep, the user is expected to learn too much too quickly, and many will simply give up.
The X axis of an actual-jargon “learning curve” is effort, not time. Steeper slope means higher “learning ROI”—more learning out per unit of effort invested in.