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

141–150 of 379 posts

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

#141

Post by digi_owl »

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…

IMO, intuitiveness is overrated.

As one snarky joke goes: only the nipple is intuitive, everything else is learned.

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

#142

Post by westoncb »

chris_mc wrote: post #117
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.

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

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

#143

Post by Avshalom »

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…

in cases like that how can you distinguish loving the cli paradigm and loving some one else doing the work for them

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

#144

Post by westoncb »

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…

> What if animations started at a slightly slower speed, and gradually increased in speed the more you used them?

That's an interesting idea. Or how about if the initiation of a new animated action forced already running animations to rapidly complete? Then if you're doing a bunch of things that trigger animations in rapid sequence, then they would all effectively just be running at higher speeds, in proportion to your specific speed of working.

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

#145

Post by jstewartmobile »

The sorry state of UIs is more of a marketing thing than a computer science failure. There is a trade-off between gloss and performance. Gloss is the easier sell. Let a little of the web doodaddery in, and users will not let up until you bring the rest of it. At that point, we just took the long trip back to Electron.

Also, learning from terminals to make better UIs--especially if the big selling points are speed and composability--is developer Stockholm syndrome. The speed is only there because the user-facing I/O is very limited, and rich media is out-of-the-picture. The composability is only there because we have 40+ years of command flags to format and reparse every single ad-hoc format into something the next command can understand. Interfaces like Jupyter and Mathematica did a decent job integrating rich media. Symbolics Genera--and probably a few other language-machines--had a better story on composability (by having a common structured data format).

Amen to "We should stop babying our users" though. Engelbart called that one from the outset--with something to the effect that if we're going to be using these things all our productive lives, most learning curves are going to be worth it--as long as the feature isn't garbage.

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

#146

Post by GlenTheMachine »

t1amat wrote: post #38
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.

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?

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

#147

Post by [deleted] »

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

[deleted]

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

#148

Post by taeric »

digi_owl wrote: post #141
sxates wrote: post #114

Earlier quoted context omitted.

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…

IMO, intuitiveness is overrated. As one snarky joke goes: only the nipple is intuitive, everything else is learned.

And as anyone with children can tell you, the nipple is far from intuitive.

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

#149

Post by Karrot_Kream »

KirinDave wrote: post #76
nomdehn_180714 wrote: post #51

Earlier quoted context omitted.

I think your criticism misses the mark. [1] You're answering an article that starts with a 45-second video of Slack opening (surely the worst offender among modern apps) with something about latencies measured in thousandths of a second. [2] As Nielsen is focused on web apps and applications, this advice is less applicable to UI provided by the OS that you interact with all day in presumably familiar ways. Note that…

[1]: Maybe you should read the article and see subsequent videos (e.g., animation jank) where we are in this time domain rather than skipping that part? TBF: the videos didn't play for me without opening them in a different tab. I'm not sure how they accomplished this, since typical embedding tags don't have this problem. [2]: > As Nielsen is focused on web apps and applications, this advice is less applicable to UI…

> The web is WAY more accessible to non-english-speaking people, people with physical differences, and people with issues focusing in the way terminals must demand you do.

A bunch of people (including Kay and Victor) have talked about this, but accessibility is only one part of the interface. Pieces of software that are productivity related should be easy to get started with and be accessible, but also allow you to become more productive. A lot of tools (like 1Password) focus on the former (accessibility to the lay user) but don't focus on the latter. This isn't some sort of unattainable ideal though: Excel and Powerpoint are great examples of tools that make it easy to just play around with as a beginner, but also to really reward power users.

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

#150

Post by pech0rin »

I think this stems from a problem of companies hiring visual designers over interaction designers. They are two completely different skill sets and yet when a UX & Interaction Designer applies for a job they are required to submit visual designs as well. I have a colleague going through this process right now. They are in the final stages of the interview process and are rejected because they can't put together a visually perfect design.

The world needs more User Experience designers and yet it seems like no one is hiring them (even if they say they are).

Post reply on HN