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

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

#261

Post by JoshMnem » Sat, Aug 04, 2018, 10:07 AM UTC

arendtio wrote: post #256

JoshMnem wrote: post #241

Animation 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…

If I remember that tool correctly, it animates down without over-the-top easing effects. Those aren't as bad as animation that simulates physical motion.

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

#262

Post by arendtio » Sat, Aug 04, 2018, 10:08 AM UTC

> We should build networked applications that cache content and make network fetches asynchronously to remote APIs so that humans aren’t waiting for data to come back over the wire while they’re working.

I built something like that a year ago and thought that I wouldn't have to bother the user with the sync state. I was wrong. Due to the nature of the mobile connections it happens quite often that for short periods multiple devices aren't synced. Yes I could certainly improve the logic to let this happen less often but in the end the user requires some indication about the sync state (e.g. last successful sync).

So when you build something similar don't hide everything from the user just give him as much freedom as possible to allow him to keep working while the sync happens in the background.

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

#263

Post by [deleted] » Sat, Aug 04, 2018, 10:14 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...

[deleted]

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

#264

Post by ghthor » Sat, Aug 04, 2018, 10:15 AM UTC

chocolatebunny wrote: post #128

buchanae wrote: post #107

Earlier quoted context omitted.

I remember being giddy about the potential of Ubiquity to bring the CLI to a wider audience, and bring more power to existing CLI users. Too bad it never played out. https://wiki.mozilla.org/Labs/Ubiquity

That kind of stuff comes up every so often. I heard rumors in the early 2000s about Microsoft implementing a version of Office that was more commandline oriented (this was when people were getting sick of their "smart" menubar, before the ribbon interface).

My partner is a lawyer and we both agree that the rich text editors are massively killing productivity in the space, where plain text is PLENTY powerful enough. The dumb shit they deal with documents and formatting and PDF's. It's fucking dumb, plain text & markdown for life.

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

#265

Post by jasonm23 » Sat, Aug 04, 2018, 10:16 AM UTC

0x445442 wrote: post #179

sxates wrote: 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.

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.

Emacs + Smex makes the M-x command discovery even more effective.

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

#266

Post by TeMPOraL » Sat, Aug 04, 2018, 10:26 AM UTC

slrz wrote: post #50

sandinmyjoints wrote: post #22

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

> What's an Emacs? Running that command just seems to reduce my disk quota.

It's an operating system that offer the sanest capabilities for productive work with everything that's primarily textual, or could be made to be primarily textual.

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

#267

Post by theclaw » Sat, Aug 04, 2018, 10:45 AM UTC

ken wrote: post #28

The 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…

We can probably learn a lot about UI animation from video games.

In fighting games there are the concepts of animation priority[0] and cancelling[1], which essentially govern whether the animation for your previous move will block your next move, and whether an animation can be interupted by a new move.

Most good video game UI animates after-the-fact, so you can navigate very quickly and the UI animation lags behind your navigation a little bit. That’s mostly only possible with a controller input because with a mouse the anmiation must complete before the widgets are visible to be clicked on.

[0] https://www.giantbomb.com/animation-priority/3015-7740/

[1] https://www.giantbomb.com/animation-canceling/3015-1568/

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

#268

Post by pbhjpbhj » Sat, Aug 04, 2018, 10:46 AM UTC

vezycash wrote: post #226

freefal wrote: post #225

Earlier quoted context omitted.

Just so no one accidentally deletes an email on Gmail, 'e' is archive and '#' is delete.

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

To stop the current job!?

;oP

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

#269

Post by kdma » Sat, Aug 04, 2018, 10:48 AM UTC

GlenTheMachine wrote: post #10

I'm switching away from macOS to Linux with the i3 window manager for precisely this reason. But all of his criticisms of terminals are spot on: no multimedia, no support for anything other than monospaced fonts, etc. Lord, somebody give me a terminal program that produces laid-out text and can show inline video.

looks like you are ready for templeOS

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

#270

Post by oneeyedpigeon » Sat, Aug 04, 2018, 10:51 AM UTC

sxates wrote: post #114

Asooka wrote: post #96

Earlier quoted context omitted.

I think a simple data-display UI shouldn't be that hard to code. Every program you run has access to a terminal, which it can use to display and read text. It shouldn't be hard to extend that to displaying and reading structured data. One dream I have is to have a Desktop where each program can send an ioctl to stdout that turns it into a stripped-down browser, so it can then just dump XHTML data and have it be visua…

The difficulty is not just in coding the UI, but crafting one that's easily and intuitively understood by users. We haven't yet established a universal design pattern for GUI's yet, to the parents point, just a bunch of conventions that are often tossed in favor of something new. A 'solved' UI example would be of a car (not the radio, but the operation of the vehicle). Learn to drive one car, and you can pretty much…

As someone who has only been driving for a couple of years, please don’t make my UI as complicated as my car's 'interface'! I take your point about 'portability' (although different cars are notoriously different to drive - even the gear pattern on the stick varies between different manufacturers) but the initial learning curve is incredibly steep. If I really wanted to, I could learn emacs from a manual. I can’t imagine learning to drive without another human involved.