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

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

#91

Post by nicoburns » Fri, Aug 03, 2018, 9:19 PM UTC

tonysdg wrote: post #72

ProfessorLayton wrote: post #64

I highly disagree that the animations are superfluous for the vast majority of users. Yes, they can be superfluous, but that's not by their nature of existing. History shows us that consumers value good UX, of which animation is a key component. The iPhone wasn't the first smartphone, but it was the fist one to take UX as seriously as the hardware. As for the examples: - Slack: Yes, it takes forever to load and I hat…

> Spaces: The animation tells the user what is going on! Having the entire screen change instantly would be confusing for the vast majority of users. That's an interesting point, and it makes me wonder if there's a level of nuance to be found here. For example, animations are acceptable iff they do not extend the time required to perceive the requested action. In other words, it's already going to take me some fracti…

When i upgraded my phone gro a nexus 5 to an S7 i was initially confused that my new (3 years newer, higher end) phone seemed sluggish compared to my old one.

It turned out that I'd enabled an option to double animation on the old phone. Enabling the same option on the new phone made everything as fast as expected.

That said, I really appteciate the (faster) animations. I wouldn't want to do a without them at all.

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

#92

Post by madeofpalk » Fri, Aug 03, 2018, 9:20 PM UTC

rconti wrote: post #88

KirinDave wrote: post #13

So to sum up, Terminals Are So Responsive & Fast Users Always Feel It [1]. Animations are bad because they take too long but add no value [2], and terminals render non-english characters super well [3]. I've been researching for a bit, and actually research on how to make a "good" and "accessible" terminal interface is pretty thin on the ground. You can find a lot of opinions but very few with any data backing them.…

What does "accessible" mean? Screen readers sure work better on text than on GUI elements, for one.

How do screen readers work with curses interfaces? Genuinely curious.

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

#93

Post by [deleted] » Fri, Aug 03, 2018, 9:21 PM UTC

KirinDave wrote: post #81

tonysdg wrote: post #66

Earlier quoted context omitted.

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…

Don't get me wrong, Electron has a lot of issues. I think Slack should switch toolkits. But I don't see how we argue that a famously poorly implemented app is somehow indicative of the entire space of GUI apps and that a space equally fraught with UX issues is somehow obviously better. Especally when we have excellent examples like VS Code, which is cheerfully giving neovim and emacs a run for their money and displac…

[deleted]

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

#94

Post by masswerk » Fri, Aug 03, 2018, 9:25 PM UTC

The single point that I disagree on:

> "Let’s dig into it by looking at the aspirational interface concept from a great movie: Minority Report. (…) I think we can all agree that the interface of this prospective future is incredible and desirable"

I guess, this single scene of a movie has distracted interface development like no other vision. However, it's just a terrible interface: Working over prolonged stretches of time, gesturing with stretched out arms, would be simply impossible, you had to memorize a complex alphabet of gestures, which made the command set of Wordstar shrink in comparison, not to speak of the visual clutter and the (perceptual) bandwith required. – Please, let's stop speaking about Minority Report in this context. (It's a nice visual effect in a movie, but nothing to aspire to in terms of real life – just as is true for most movie FX scenes.)

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

#95

Post by sixo » Fri, Aug 03, 2018, 9:25 PM UTC

These rants always seem to miss something important.

Not everyone thinks like you (seasoned terminal users) do. There are different kinds of intelligence. The only way to get good with a terminal is to RTFM and _play_ with it, until you're used to it and have constructed a mental model of its internal "types", their logic and composability.

Software developers are as a group highly predispositioned to construct mental models of this sort, and to learn by reading the docs. Most people aren't. Many more people are very good at building a _spatial_ model of something, and remembering how to do things by _where they are_. Animations, different screens, various OSX ui components, etc, tabs, all do this. For discovering features and learning to do new things, rather than read the manual, you explore of the environment presented to you. While working, instead of writing intermediate state to buffers somewhere (like the pushd stack) you _put_ it somewhere, and when you want to find it again you go look where you put it.

I'm personally better at this than at the software way of thinking and generally find that if things move too fast I just get stuck and have to wait for my brain to catch up. This is probably a fault but it's not going to change overnight. I'm also bad at reading manuals, or at least, I don't like to put the time in to read the manual for everything I do, and am very annoyed when an interface exposes its internal model and complexity non-uniformly, ie to do something that I can _think_ about quite simply I have to absorb and model a lot more of how it works than it feels like should be necessary. (That sentence was about git, also a favorite of these advocates. But also bash, and honestly most CLI tools.)

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

#96

Post by Asooka » Fri, Aug 03, 2018, 9:27 PM UTC

fpgaminer wrote: post #87

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…

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 visualised on screen, while stdin feeds you json-serialized user input, e.g. user entered text X in input field Y, or selected file Z. It won't be useful for multimedia or anything like that, but will make building simple one-off UIs much easier.

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

#97

Post by rcthompson » Fri, Aug 03, 2018, 9:28 PM UTC

To the point of animations looking cool the first time and then quickly getting old, Ubuntu actually has a good solution for at least the window minimizing/restoring animation. The first time you minimize a window on a fresh install, the animation plays somewhat slowly. Each time the animation plays after that, it plays slightly faster, until it becomes almost but not quite instant, so you can still see where the window went, but it doesn't waste your time now that you know what to expect.

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

#98

Post by KirinDave » Fri, Aug 03, 2018, 9:29 PM UTC

madeofpalk wrote: post #89

KirinDave wrote: post #81

Earlier quoted context omitted.

Don't get me wrong, Electron has a lot of issues. I think Slack should switch toolkits. But I don't see how we argue that a famously poorly implemented app is somehow indicative of the entire space of GUI apps and that a space equally fraught with UX issues is somehow obviously better. Especally when we have excellent examples like VS Code, which is cheerfully giving neovim and emacs a run for their money and displac…

Slack's problems have zero to do with Electron.

I think maybe it's security problems have something to do with Electron.

However, I agree Slack's got a lot of issues that are just bad implementation choices.

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

#99

Post by KirinDave » Fri, Aug 03, 2018, 9:30 PM UTC

madeofpalk wrote: post #92

rconti wrote: post #88

Earlier quoted context omitted.

What does "accessible" mean? Screen readers sure work better on text than on GUI elements, for one.

How do screen readers work with curses interfaces? Genuinely curious.

Generally you fool them into spitting raw text and carefully crafted menu summaries into a socket that speaks text at high speed.

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

#100

Post by crazyloglad » Fri, Aug 03, 2018, 9:31 PM UTC

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.d wasn't worth it).

The posts etc. so far is much in the terms of documentation, not dissemination or politics. Coming soon: "Arcan vs. Xorg - far beyond feature parity" and "The Divergent Desktop"; that will show how these things fit together. The latter expands a lot on some of the ideas in this article.