Live data from Hacker News

Learning from Terminals to Design the Future of User Interfaces

brandur.org

231–240 of 379 posts

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

#231

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.

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.

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

#232
post #156

Earlier quoted context omitted.

You may check telegram’s games, services and other bots that allow to manage your entire world via chat (with programmatic buttons and menus to ease /cmds a little). I don’t use it much, but my coworker said that he almost lives there, visiting sites only for long, static content. From this perspective, “we” don’t “need” as the article says, since it’s already there and writing a simple bot is a no-brainer. (Downside…

Genuinely curious, why don't you use it much?

I’m not really into social games in my language (maybe should try english areas). Anyway, discoverability is a hard part of telegram. Like you don’t see tg-links on the internet often. For bots part I just didn’t go there yet – no particular need. I’ve written two utility bots for my company though.

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

#233
post #222

Earlier quoted context omitted.

That’s great for someone watching over your sholder eg if you’re doing a product demo but less good if you’re on your own. There it just slows you down when you want to move on to the next task.

I gave reasons why it could help the user themselves. (Here's another: for users learning Vim) And why should it necessarily make things slower? The animation could be quite fast, and I don't see why such animations would necessarily need to block or hold up future inputs or animations. (I do think, though, that you'd need to actually try it out to see if it works in practice)

I agree it’s possible to have animations that add useful information and don’t block the user.

In practice they are rare, certainly in consumer products. I can think of more products with janky UIs than I can ones with insanely great UIs.

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

#234

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?

I dunno. Do you think that's important? Why?

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

#236
post #113

Earlier quoted context omitted.

Problem is it doesn't scale well for people. Imagine if everything you did in slack was via CLI - there are dozens, hundreds of commands to learn? Imagine if every app had dozens of commands you had to learn and memorize. Sure you could do it and be blazing fast, but that's a really steep learning curve a lot of users wouldn't adopt.

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…

bash has this too.

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

#237

Earlier quoted context omitted.

I suggest Chrome or Firefox. I find the conclusion of the article totally off the mark. The author seems to not understand that problems begins with multimedia support and other "gimmicky" stuff (as he puts it). You want video? Then use your terminal to launch a video player. A tiling manager is precisely perfect for this (I wonder why you switched to i3 if you don't know that, btw).

Oh, I know that. But what I'd really like is something akin to Jupyter, only for the shell. I think I'd like that, anyway. For example, right now I can issue a shell command that lists cpu utilization by process (top). I can even have that command autorefresh, showing me changes in real time. But to do that it takes over the shell. It'd be neat to think about a shell where I could issue a top command, then command di…

> screws up my carefully constructed window layout.

To me this is off. With a tiling window manager I don't have to "carefully construct" a window layout. That's the window managers job!

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

#238
post #209

I agree that we need more speed. Some websites and apps are too slow. We need faster network and faster websites.

> We need faster network and faster websites.

We need less bullshit on websites, that'd solve both problems. See e.g. https://www.techtimes.com/articles/229533/20180606/thanks-to...

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

#239

Earlier quoted context omitted.

I suggest Chrome or Firefox. I find the conclusion of the article totally off the mark. The author seems to not understand that problems begins with multimedia support and other "gimmicky" stuff (as he puts it). You want video? Then use your terminal to launch a video player. A tiling manager is precisely perfect for this (I wonder why you switched to i3 if you don't know that, btw).

Oh, I know that. But what I'd really like is something akin to Jupyter, only for the shell. I think I'd like that, anyway. For example, right now I can issue a shell command that lists cpu utilization by process (top). I can even have that command autorefresh, showing me changes in real time. But to do that it takes over the shell. It'd be neat to think about a shell where I could issue a top command, then command di…

Personally I use GNUScreen in addition to dwm, but mainly because I use a 15 years-old Celeron PC as a network console, which for some reason puts a one-two seconds tax on window creations. This setup is quite flexible, but you can get lost easily, in particular if in addition you use ctrl+Z carelessly.

An alternative is Emacs, which will give you shells and windows and splits and somewhat-interactive documents (org-mode) and has some support for images. If you're ready to sacrifice an hour per day to Emacs configuration for the next twelve years, it will do your biddings eventually...

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

#240

Earlier quoted context omitted.

Zsh can also do this.

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.

Post reply on HN