Learning from Terminals to Design the Future of User Interfaces • Hacker News Board

Re: Learning from Terminals to Design the Future of User Interfaces

#191

Post by angleofrepose » Sat, Aug 04, 2018, 1:03 AM UTC

mikeryan wrote: post #164

sleepyams wrote: post #140

Earlier quoted context omitted.

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…

There’s an inherent dichotomy in UI in that the most “efficient” interfaces generally have the steepest learning curve. You can be really efficient in a terminal or VIM. But figuring those out take a lot of work. When we design interfaces we try to make them have a short learning curve but expose greater ability as you use them but it’s still hard.

Completely agree, but we can also figure out how to make it easier. Take a look at http://kakoune.org/why-kakoune/why-kakoune.html#_improving_o... (this is the section that introduces the flip on vim's command structure, but is otherwise a great article to read top to bottom).

There are a lot of ways vim is right or not right, but this lowers the barrier to entry in a profound way. We can keep advancing like this, and stacking those advancements on each other until vim isn't hard. Maybe? What do you think?

I think one of the big ways vim is hard is what Kakoune attempts to fix - visualizing selection. Adding a "layer" to working in vim, we had `u` and `^r` to figure things out - doing something and knowing we could go back. Now with Kakoune we have movement before action. This adds another way the program can converse with the user.

Disclaimer: I don't use Kakoune, but I dig what it's doing and I want to try it out. I think it is a fantastic critique of vim.

Re: Learning from Terminals to Design the Future of User Interfaces

#192

Post by srazzaque » Sat, Aug 04, 2018, 1:03 AM UTC

It'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, check. Fonts, check. Command-driven, check. Lightning fast, check.

Moving traders and other front-office staff away from BBG terminals is next to impossible due to the drop in efficiency and familiarity.

Pretty much every "function" (more similar to what devs might call an "app") can be launched via a command typed into their command bar. And it's incredibly well indexed and fast to search. Everything from reading news, checking messages, seeing a quote for AUDUSD (then subsequently purchasing). No mouse required.

Edit: typos

Re: Learning from Terminals to Design the Future of User Interfaces

#193

Post by sorahn » Sat, Aug 04, 2018, 1:14 AM UTC

NegativeLatency wrote: post #189

eikenberry wrote: post #185

Earlier quoted context omitted.

Zsh can also do this.

But it needs plugins, fish has it builtin. Nothing to configure

Yup this. If I wanted to carry around a bag of plugins all day, I'd just use bash.

Re: Learning from Terminals to Design the Future of User Interfaces

#194

Post by ericpsimon » Sat, Aug 04, 2018, 1:18 AM UTC

aphextron wrote: post #68

I had sort of an "aha" moment reading a non-technical co-workers conversation on Slack the other day. Someone built a Slackbot to show the menu for whatever food truck is outside our building that day, and people could use it just by typing "/foodtruck". They were blown away and loved it. Rather than opening a browser and navigating some disparate menu pages, they could simply fire off a command in their "console". I…

Has Slack innovated in the last 5 years?

Re: Learning from Terminals to Design the Future of User Interfaces

#195

Post by protomyth » Sat, Aug 04, 2018, 1:39 AM UTC

ssivark wrote: post #119

aphextron wrote: post #68

I had sort of an "aha" moment reading a non-technical co-workers conversation on Slack the other day. Someone built a Slackbot to show the menu for whatever food truck is outside our building that day, and people could use it just by typing "/foodtruck". They were blown away and loved it. Rather than opening a browser and navigating some disparate menu pages, they could simply fire off a command in their "console". I…

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…

It makes on wonder if an Infocom-style VM could be adapted for CLI use. They did have a database as I recall.

Re: Learning from Terminals to Design the Future of User Interfaces

#196

Post by cnasc » Sat, Aug 04, 2018, 1:48 AM UTC

crazyloglad wrote: post #100

cnasc wrote: post #46

A related sort of idea, which has been posted to HN before but never gotten a huge amount of attention is the Arcan project [1]. Basically an interesting implementation of a display server and desktop environment being worked on by a lone dev as far as I know. Really impressive stuff, and in the author's own words: it is keyboard dominant, building a better and more efficient CLI than the flaccid terminal emulators o…

lone dev here, and thanks for noticing - so this is where the traffic came from :-) The lack of attention (and releases, not representative of the half a million lines of C code and about 100k of Lua it entail) is mostly by design - to a large extent, I prefer obscurity to the point that productivity dips and lethargy sets in around release bursts, it opens up old mental war wounds from academia (also - getting a ph.…

I think it's a fantastic project! Seems like a lot of what I want in a desktop. Looking forward to the new posts.

Re: Learning from Terminals to Design the Future of User Interfaces

#197

Post by blunte » Sat, Aug 04, 2018, 1:49 AM UTC

As with debugging, it's important to choose your battles. How often do you start up slack? Is that 45sec once per day or even per hour, or is it per minute? Obviously it's not a frequent occurrence. So that delay, regardless of your computing power, is not an issue.

A case where it does matter is with a good mobile phone camera. It must launch and be able to capture an image within one or two (or at least within 5) seconds.

But back to the Electron topic... Would you rather a tool exists and isn't perfect, or it does not exist at all? Ok, or maybe it exists but costs $99 per user?

I love clean, performant, low latency interfaces. I live in a terminal. But I also understand the value of developer time. Whether tools and frameworks actually make devs more efficient can sometimes be unclear, but often they allow things to be made that otherwise wouldn't be made due to budget (time cost) constraints.

Re: Learning from Terminals to Design the Future of User Interfaces

#198

Post by gumby » Sat, Aug 04, 2018, 2:00 AM UTC

The other important factor the author neglects to mention is the keyboard -- ctrl-tab is so great because you don't have to take your hands off the keyboard or your eyes from the screen. The place the machine is waiting for the user is when he or she is screwing around with the mouse and then returning their hands to the keyboard.

Re: Learning from Terminals to Design the Future of User Interfaces

#199

Post by gumby » Sat, Aug 04, 2018, 2:01 AM UTC

westoncb wrote: post #142

chris_mc wrote: post #117

Earlier quoted context omitted.

Look at the VSCODE command bar. You start to type what you want to do, and the search function is incredible, helping you find any command you want. Why couldn't something simple like that be applied to the command line interface for a shell maybe? Heck, with `zsh` I have a lot of autocomplete commands available, including several sub-commands and sub-sub commands. For example, when I type `git remote `, a listing sh…

I've been wondering this for years. It seems like the most obvious way to greatly improve CLIs, yet no one seems to talk about it...

Gosh TOPS-20 had this back in the early 1980s (and this is why bash has readline...)

Re: Learning from Terminals to Design the Future of User Interfaces

#200

Post by WhatIsDukkha » Sat, Aug 04, 2018, 2:03 AM UTC

micheljansen wrote: post #11

I recently got gifted an old Commodore PET. It boots straight into BASIC, so anything you type can be a command or a program, but what’s even cooler is the way the console (they call it “monitor”) works. If you press “up”, rather than scrolling through past commands one by one like in Bash, DOS etc. the cursor simply goes up the screen. You can modify anything you see and hit return to commit. This can be a previous…

I used to love this on my Apple 2.

It exists nowadays as Emacs in the built in eshell.

The buffer is the shell is the buffer.