Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learning from Terminals to Design the Future of User Interfaces

brandur.org

Post reply on HN
Print view View original

301–310 of 379 posts

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

#301

Post by GlenTheMachine »

omaranto wrote: post #218
GlenTheMachine wrote: post #162

Earlier quoted context omitted.

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…

How about instead of something merely like Jupyter you just use precisely Jupyter? I'm sure someone wrote a shell kernel, and if not, use ipython's shell magic.

That... could actually work. In fact there is a bash kernel for Jupyter. Not a lot of info about it on the github page, but it's there.

Then the issue becomes how well bash output takes advantage of Jupyter. Research forthcoming.

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

#302

Post by 0x445442 »

pbhjpbhj wrote: post #272
akx wrote: post #252

Earlier quoted context omitted.

Fish's abbr feature does this. They're aliases that expand in place. For example I have gph abbr'd to "git push origin HEAD", and I can continue editing the command after expansion.

Is there a way to expand special commands (and optionally aliases) in BASH without executing them. Like if I put `ll !$` it would show, say, `ls -al /home/user/downloads` on a new line. I'd love tab style completion that offered explicit history as well as standard completions. So if I `find` and then press the completion key-combo I get a list of the last 10 unique find commands (and I can choose one and edit before…

This may be possible with fzf but I'm not sure of all the features it's capable of.

This type of behavior would be a great addition to the terminal or popular shells. Instead of having the command prompt always display at the end of output, have it stay in the same place at the top or bottom.

Something like you get with the Emacs mini-buffer with tools like helm but for the terminal.

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

#303

Post by brazzledazzle »

tonysdg wrote: post #66
gav wrote: post #60

Earlier quoted context omitted.

> 45-second video of Slack opening (surely the worst offender among modern apps I hate to defend Slack as it's far from snappy, but comparing it to a console app seems hardly fair. I wonder how much of it's slowness is due to network requests? I could make the argument that git is slow because when I clone a large repository it takes a while.

This goes to the article's point about caching; a chat app -- of all programs -- should cache conversations for a fast boot up. Sure, _updating_ the conversations -- the "cloning" stage -- may take some time, but why should you have to wait for the network requests to complete before seeing your past conversations? The git equivalent would be if you had to wait for git to do a fetch/pull every time you ran "ls" on a…

That's not really a fair comparison. Git changes but the version you have and are looking at is fixed. With slack the conversation changes and you can't let the user respond until they're up-to-date because if they did people would be on HN ripping Slack for causing confusion. Not only that but the messages can literally change from one moment to the next. What happens when a user deletes a message?

The equivalent with git would be having each directory be a submodule and someone is rewriting the history out from under you every few seconds.

For technical people it’s easy to assume we understand the problem especially when we see what looks like a questionable design choice but when we do this to applications we don’t have experience with it only hurts us collectively.

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

#304

Post by 0x445442 »

collinmanderson wrote: post #293
0x445442 wrote: post #178

Earlier quoted context omitted.

Ding, ding, ding!!! I've been beating this drum for a few years now. The interesting thing about chat bots is the UI not natural language processing. I think people are completely overwhelmed by the massive lack of consistent UI the Web has brought us. I also think the more "apps" that could be brought into platforms like Telegram, the happier users would be. There's also evidence of this in China where 100's of mill…

I realize it’s called “WeChat”, but isn’t it super popular because all of the mini UI-driven apps inside of it? I don’t get the impression that people really talking to bots much using that app. They’re either chatting with humans or interacting with UIs. http://a16z.com/2015/08/06/wechat-china-mobile-first/

At the very least all those mini UIs are cornered into a more standardized system just from the limitations presented by the chat environment. On the other end, most of the functionality can be driven from textual commands the way SMS "apps" used to be.

Of course the elephant in the room to this entire thread is advertising and analytics, which IMO is the biggest reason the web has devolved so badly. I mean it's much harder to generate revenue if you're just serving me textual content that I'm interested in.

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

#305

Post by 0x445442 »

jstarfish wrote: post #205
0x445442 wrote: post #178

Earlier quoted context omitted.

Ding, ding, ding!!! I've been beating this drum for a few years now. The interesting thing about chat bots is the UI not natural language processing. I think people are completely overwhelmed by the massive lack of consistent UI the Web has brought us. I also think the more "apps" that could be brought into platforms like Telegram, the happier users would be. There's also evidence of this in China where 100's of mill…

Really? It seems that with the advent of Bootstrap and responsive design, website UIs are more consistent and generic than ever before. Every corporate landing page is a jumbotron/full-width image, followed by three columns of bullshit, followed by a few rows of random glyphicons and more vague nonsense to cross the minimum text SEO threshold, and a footer. The early internet was a much wilder place. Frames or no fra…

I'd agree with you when you're talking about websites that are, for the most part static and just conveying information. But when you're talking about actual web applications designed to get work done I think things are wildly disjointed.

If I were to show you the web apps I interact with regularly, both personally and professionally, you'd see what I'm talking about.

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

#306

Post by btschaegg »

dunham wrote: post #282
tomxor wrote: post #273

Earlier quoted context omitted.

Also ctrl+enter is send email (immediately) which is very annoying after working in google sheets for a while where ctrl+enter is newline...

The most annoying for me is “j” in outlook. It means “move down” in Gmail and dozens of other apps - in outlook it means “mark as junk”.

TBH, outlook hotkeys generally are a mess like that - not even when compared with their "competitors", but also when compared with Windows itself. I can't even tell how many times I wanted to search for text in a long email only to find that "Ctrl+F" forwards the open email.

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

#307

Post by 0x445442 »

neeasade wrote: post #30

Everything the author describes lacking in the end exists in emacs. Come on in, the water is fine.

I love emacs but I just can't get the terminal/shell options it provides to work as smoothly as I can with a proper terminal emulator. What would be perfect is if you could duplicate a terminal buffer for stdout/stderr but have the command line/stdin be in the mini buffer so as to leverage helm or ivy. To me, this would be nirvana.

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

#309

Post by vezycash »

pbhjpbhj wrote: post #268
vezycash wrote: post #226

Earlier quoted context omitted.

That's what ctr+z is for isn't it?

To stop the current job!? ;oP

Press delete accidentally or intentionally and you should see a notification about the delete.

If you want to undo, then Ctr + Z. At least that's the way computers have worked for eons.

Ctr + Z is the reason I prefer computers to typewriters. Software without the ability to undo or reset actions are devolving the user experience to typewriter age.

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

#310

Post by gumby »

DonHopkins wrote: post #278
gumby wrote: post #199

Earlier 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.

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!
Post reply on HN