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.…
Learning from Terminals to Design the Future of User Interfaces
161–170 of 379 posts
Re: Learning from Terminals to Design the Future of User Interfaces
#162I'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).
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
#163I 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…
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
#164I 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…
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
#165The 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…
Re: Learning from Terminals to Design the Future of User Interfaces
#166Earlier 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...
Re: Learning from Terminals to Design the Future of User Interfaces
#167The 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…
Re: Learning from Terminals to Design the Future of User Interfaces
#168Earlier 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…
Re: Learning from Terminals to Design the Future of User Interfaces
#169I 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…