Live data from Hacker News

Learning from Terminals to Design the Future of User Interfaces

brandur.org

161–170 of 379 posts

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

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

Well, it's pretty awesome. Good work.

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

#162

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.

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 displays and exits, giving me a shell prompt again. But I have the option of asking the shell to update the old output every N seconds.

Yes, I could in i3 spawn a new shell and just keep top running in it. And maybe in the long run that's the better interface. But doing that screws up my carefully constructed window layout.

I guess what I'm saying is that we have two interface paradigms: the gui, and the command line. But interfaces like Jupyter and Mathematica show that there are middle grounds between those two extremes, and that middle ground is interesting.

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

#163

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

Yep, that's been a huge problem for me too. I've put lots of time into thinking deeply about interaction design issues, and implementing solutions to them (mostly in the context of developing new kinds of programming tools). I've studied a good bit of psychology, and learned some from my dad who worked in HCI for > 30 years.

However, whenever I try describing to folks the kind of design where I have some ability and accomplishments, they seem unable to disentangle the problems I'm talking about from visual design. I've even regularly ended up falling into rolls at work where I'm consulted on interaction design issues—but no one knows the name for this or anything, just that when a problem comes up about, "how can we make this easy for people to do?" I tend to have useful ideas. But I won't be hired for it initially, and there won't be anything once I leave the job or work with new people there which says that's something I contributed.

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

#164

I wrote a comment under a different post just a few days ago. My comment got _way_ out of hand and wasn't as articulate as I had hoped. But the salient point I made with it is simple and applies equally well to this article. UI is hard. User interfaces seems really simple. Every programmer I know has looked at a UI and thought to themselves "I can code that in an hour!" and then ended up spending weeks, sometimes _mo…

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.

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

#165
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…

A good animation should be barely perceptible. If it’s too slow, the application feels sluggish. Too fast, you may not know what happened. It reminds a UX talk from Airbnb, where they have this one guy that focus only on animations. It’s a good idea to provide the ability to skip the transition with the press of a button. It’s reminds me how one can skip the dialogues in video games.

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

#166

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

Check out Fish Shell.

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

#167
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…

Classic Mac interface (one of best interfaces of all time, IMHO) actually had special animation to show how a folder opens from a small icon into a larger window with contents. The whole interface was very economical, they just could not afford extra cruft those days, yet they decided that this animation was crucial for understanding.

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

#168
post #114
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…

I wouldn't compared all GUIs with the car; the car is more like a particular type of GUI, say, of word processors. Plus, the basics may be standard, but everything else (mainly the dashboard) is still quite a mess. I wouldn't say it's solved at all.

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

#169

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

Indeed, not a lot of people know the difference between UI and UX designer, even in tech. To add to the confusion, the profession title is now shifting to “Product Designer”.

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

#170
One thing I found out the lazy way is that for single purpose UI as part of some overall process (Point of sale, Order picking and what not) TUI really works because the set of actions is constrained by what Fx key you can press and what barcode you can read. For convention front office (cash/voucher/pre-order converted into event ticket) I ended up with UI that mimicks IBM's ISPF built on top of Python's urwid. Previous versions were straight readline (which worked well for the happy path) and GUI thing which confused the operators.
Post reply on HN