
Learning from Terminals to Design the Future of User Interfaces - juancampa
https://brandur.org/interfaces
======
aphextron
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 realized that people love Slack because it has introduced them to the CLI
paradigm of computing for the first time. CLI is _so_ much more efficient and
powerful if users can somehow be incentivized to put in the time and effort to
become productive, which Slack has focused on a lot. As inefficient and silly
as it may seem to us developers, Slack with it's endless command based
integrations has succeed wildly at that where nothing else has so far.

~~~
ssivark
Most successful interactions with Siri/Alexa/Cortana/GoogleNow also fall under
the same paradigm. They have some finite number of templates/recipes that they
can respond to, and just enough "NLP" to attempt a fuzzy matching between what
you ask for, and the triggers to the recipes.

The key point is that communication is fundamentally serial, in both voice and
basic text consoles, whereas GUIs allow parallel communication streams (and
hence "exploration") organized spatially.

I find it ironic how the same people consider GUIs a more newbie friendly
interaction paradigm than the terminal/console, and then say the same for
voice interfaces over GUIs.

~~~
sharmi
Maybe because, the cli mode means, you need to remember the commands?

In GUI mode, though inefficient, you know exactly where to access help and a
few basic params (like dropdown menu on top, usually save under file, cut and
copy under edit) that smoothens the learning curve. They have some solid
ground from which to start exploring.

Whereas under console mode, there is no unifying paradigm. So each tool has a
different way of doing the same thing. There is a lot of inertia at the start.
Like what command is it for help 'h' or 'h?' or 'help' or 'H' ? What command
is it for quit 'q' or 'quit' or 'ctrl+d' or 'ctrl+c' or 'bye' ?

For example, in gmail, I expected archive to be 'a' and delete to be 'd' or
atleast "DEL". Very basic operations and basic expectations. Turns out,
archive is '#' and delete is some char I can't remember now (I think '{' and
'}' to indicate whether to go to the previous mail or the next mail. A 'd' to
go to next mail and a 'D' to go to previous email would have been a lot more
intuitive). Of course, you can customize the key bindings, but then you got to
go do it across all your accounts.

While people may be quite happy to be able to wield so much power within the
slack environment, they are very quickly going to lose their enthusiasm with
the introduction of each new console tool, unless what they have learned in
the slack environment translates into easier learning curve in the next
console env.

Basically for users to be able to adopt the console mode, there is should be
some sort of standardization.

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

~~~
tomxor
Also ctrl+enter is send email (immediately) which is very annoying after
working in google sheets for a while where ctrl+enter is newline...

~~~
dunham
The most annoying for me is “j” in outlook. It means “move down” in Gmail and
dozens of other apps - in outlook it means “mark as junk”.

~~~
btschaegg
TBH, outlook hotkeys generally are a mess like that - not even when compared
with their "competitors", but also when compared with Windows itself. I can't
even tell how many times I wanted to search for text in a long email only to
find that "Ctrl+F" forwards the open email.

------
ken
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 they say "you're working
fast!", while in environments with no animation (like Emacs), it's just "I
have no idea what you did". I want computers to seem efficient, not
unapproachably magic.

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

We shouldn't need to pick one animation speed for all users, but we also
shouldn't make expert users tweak it manually. And I definitely want to see
full animations for new applications that I'm not familiar with yet, but not
those in old applications which I've seen 1000 times.

~~~
jamesrcole
I agree. I've long thought that animation could potentially make it much
clearer what's going on in Vim.

Like if the user types 'das' to delete the current sentence, and it quickly
highlights the text to be deleted, and then shows it shrinking away, as the
text that was following it moves in to take its place. (Obviously, you'd want
the animation to happen pretty quickly).

Such animation could make it clearer what the command is doing, and this could
also make it easier to tell if you'd accidentally typed a command that didn't
do quite what you wanted.

~~~
chin123
You might like kakoune, a vim-like editor which focuses on interactivity:
[https://github.com/mawww/kakoune](https://github.com/mawww/kakoune) It flips
around a few of vim's operations (like for example, to delete a word, you do
'wd' and not 'dw'). This allows it to highlight the text before performing an
operation, which makes what you're doing much clearer.

~~~
petepete
I love Kakoune. Vim muscle memory and not being able to work out how to have
per-language settings (for indenting) were the only thinsg that stopped me
from switching.

------
fpgaminer
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 _months_ building the UI.

I believe UI is a big, unsolved problem in modern computer science. Just as
hard as any other unsolved problem in our field. Right up there with general
artificial intelligence and P=?NP. I'm not even joking.

We will eventually solve the problem of UI. But there are a thousand and one
articles posted every day either A) complaining about existing UI or B)
telling everyone the solution (without providing real, concrete new libraries,
frameworks, code, etc). No one wants to admit that this stuff is just plain
hard and we shouldn't beat ourselves up over the fact that we haven't solved
it yet.

In other words, it's easy to complain. It's easy to display hubris. It's hard
to put forth real, practical solutions. Or at least be humble and admit that
we _don't_ have the solution.

~~~
sleepyams
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 complex, but I don't think it something
to be solved as much as it is the political heart of technology.

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

~~~
angleofrepose
Completely agree, but we can also figure out how to make it easier. Take a
look at [http://kakoune.org/why-kakoune/why-
kakoune.html#_improving_o...](http://kakoune.org/why-kakoune/why-
kakoune.html#_improving_on_the_editing_model) (this is the section that
introduces the flip on vim's command structure, but is otherwise a great
article to read top to bottom).

There are a lot of ways vim is right or not right, but this lowers the barrier
to entry in a profound way. We can keep advancing like this, and stacking
those advancements on each other until vim isn't hard. Maybe? What do you
think?

I think one of the big ways vim is hard is what Kakoune attempts to fix -
visualizing selection. Adding a "layer" to working in vim, we had `u` and `^r`
to figure things out - doing something and knowing we could go back. Now with
Kakoune we have movement before action. This adds another way the program can
converse with the user.

Disclaimer: I don't use Kakoune, but I dig what it's doing and I want to try
it out. I think it is a fantastic critique of vim.

~~~
b0rsuk
I'm not trying to say Kakoune's exploration is without value, but Vim very
much does have "movement before action" mode. It's the visual mode, entered by
the "v" key. It's the main feature vim has over vi.

------
srazzaque
It's interesting to me that nobody has yet mentioned the Bloomberg terminal,
which is basically what the author is describing. It seems Bloomberg "got
this" a while back, and dug their heels on for their keyboard-driven terminal-
like UI whilst all other shops were going w32, Excel plugins, Web, etc. It's
not sexy by any means, looks like it's from the 80s in a mainframe, but it
works well for a lot of people.

Images, check. Fonts, check. Command-driven, check. Lightning fast, check.

Moving traders and other front-office staff away from BBG terminals is next to
impossible due to the drop in efficiency and familiarity.

Pretty much every "function" (more similar to what devs might call an "app")
can be launched via a command typed into their command bar. And it's
incredibly well indexed and fast to search. Everything from reading news,
checking messages, seeing a quote for AUDUSD (then subsequently purchasing).
No mouse required.

Edit: typos

~~~
unit_circle
This is super cool! Are there any OSS like Bloomberg Terminal?

------
bichiliad
I think this article points out some very valid problems (I relate a lot with
Slack's loading, OSX spaces taking too long to switch between, etc), but the
conclusions may be a little misguided. To address specific examples first:

1\. Slack is slow to start, and, as others have pointed out, uses animations
to remind the user that it's working and not just frozen. The fix here is to
improve the application's performance, but there will never be 0 network lag.

2\. Animations are good here so that you remain spatially aware of a "space"
relative to other spaces. I agree that the animations are too long, and I
myself have shortened their duration.

My biggest disagreement is with this quote:

"We should stop babying our users and try to raise beginners and the less
technical to the bar of modern day power users rather than produce software
that’s designed for the lowest common denominator."

I think the best software is intuitive to use for novices, yet leaves room for
people to improve. I'm learning how to use OSX's Logic right now, and I've
been really happy with the amount of guidance it gives me. There are options
to expose advanced controls, and there are a fleet of really convenient
shortcuts, but I have no problem getting around.

~~~
mbreese
I think another example of this would be using something like Adobe Photoshop
or Illustrator. Switching between tools _can_ be accomplished by clicking an
icon, a drop down, or some other GUI element. However, once you get to a
certain level of skill, it becomes faster to just use the keyboard shortcuts.

For a novice, it's more forgiving. But for the expert, it's possible to be
very efficient.

It's also possible to go too far the other way too. Not to date myself too
much, but an old example of too much "expert" levels was back in the DOS days
with Word Perfect. Keyboard shortcuts were the only way to do things (like
formatting). So you either learned the magic codes (with three extra/meta
operations per code) or you kept a cheat sheet on the keyboard itself. That
was a learning curve to get to 'power-user' status.

~~~
ObsoleteNerd
I still use cheat sheets, but I design my own into wallpapers that fit my
desktop perfectly, than have them rotating randomly every hour. Keeps my
refreshed on shortcuts in my popularly used programs, and adding a new one to
the rotation is a great way to learn all the shortcuts for a new program.

It's not like I ever leave my desktop visible for a pretty wallpaper to
matter. My nice ones are on my lock screen.

~~~
samlehman617
Would you mind sharing some?

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

[1]: They're not. [https://danluu.com/term-latency/](https://danluu.com/term-
latency/)

[2]: They do add value in helping direct user attention.
[https://www.nngroup.com/articles/animation-
usability/](https://www.nngroup.com/articles/animation-usability/)

[3]: Right-to-left is still poorly supported by shells, and the installation
and support process for custom glyphs in terminals is often extremely
complicated.

~~~
nomdehn_180714
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 generally "directing user attention" isn't
necessary in a shell: output always comes at the bottom. However, be sure to
read the "Frequency: Don’t Get in the User’s Way" heading that includes almost
verbatim the OP's points against animations that slow the user down.

[3] Yes, internationalization is still hard. At least for Terminal.app, this
is basically a solved problem, but of course it's possible for terminal apps
(ncurses etc) to need custom support. The situation with web tech is about the
same, these things are solved for you if you stick with the basic
technologies, but if you get fancy you may need more explicit support.

~~~
gav
> 45-second video of Slack opening (surely the worst offender among modern
> apps

I hate to defend Slack as it's far from snappy, but comparing it to a console
app seems hardly fair.

I wonder how much of it's slowness is due to network requests? I could make
the argument that git is slow because when I clone a large repository it takes
a while.

~~~
tonysdg
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 git-controlled folder. It would be insane, and no
one would use git (or any other version control).

~~~
KirinDave
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 displacing longtime
contenders like sublime, because it's genuinely quite good and plenty fast
enough for most folks.

~~~
madeofpalk
Slack's problems have zero to do with Electron.

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

------
ProfessorLayton
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 hate that, the real problem is
performance, not the animation. Would it be better if no animation happened
and didn't inform the user about about what's going on? Keep in mind that the
animation also serves to inform the user that it hasn't "frozen", so a still
interstitial would be a regression.

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

I do value choice though, so perhaps there should be a setting for power users
to disable/minimize them.

~~~
tonysdg
> 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 fraction of a second to
perceive any change; animations within that fraction of a second are perfectly
fine. Anything that extends the change past that fraction of a second,
however, is eating into my productivity (or at least, so the author would
claim).

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

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

~~~
masswerk
P.S.: If you're looking for inspiration by a movie, have a look at the status
screens and their update process in 2001 – A Space Odyssey, which were grossly
overlooked for other effects in this movie and didn't have much of a real life
impact. (I guess, for the era they came from, the clarity and economy, these
are just in line with the article.)

~~~
juancampa
Relevant: [https://ilikeinterfaces.com/](https://ilikeinterfaces.com/)

~~~
masswerk
Interestingly, while the site (which is great BTW – thanks for the link!)
features all kind of minor UIs in 2001, the major status screens, which can
bee seen in various places and scenes, are not covered in any way. (Again!)

~~~
MrEldritch
Even more relevant - the Sci-Fi Interfaces blog, which analyzes various
science-fictional interfaces in movies from an actual UI/UX standpoint.

[https://scifiinterfaces.com/category/ghost-in-the-
shell-1995...](https://scifiinterfaces.com/category/ghost-in-the-shell-1995/)

------
micheljansen
I recently got gifted an old Commodore PET. It boots straight into BASIC, so
anything you type can be a command or a program, but what’s even cooler is the
way the console (they call it “monitor”) works. If you press “up”, rather than
scrolling through past commands one by one like in Bash, DOS etc. the cursor
simply goes up the screen. You can modify anything you see and hit return to
commit. This can be a previous command, a line of code or even the contents of
the system’s memory (!).

It’s a really interesting form of direct manipulation that I have only ever
seen matched by “document” style interfaces like Matlab, R etc.

If anyone is interested, I’ll do a write up later with some videos or
something.

~~~
GlenTheMachine
IIRC all Commodore machines did this. The C64 did. That's how you edited a
program: you LIST'ed it, and then scrolled up and changed the lines on the
screen. When you hit ENTER the new line overwrote the original one.

The C64 did not have any way to directly show or edit system memory, though.
That's cool.

~~~
micheljansen
The C64 was indeed one of the only Commodore machines that did not ship with a
Machine Language Monitor. You could however install one:
[https://www.c64-wiki.com/wiki/Machine_Code_Monitor](https://www.c64-wiki.com/wiki/Machine_Code_Monitor)

~~~
GlenTheMachine
Sure. I even wrote my own, as an exercise in learning 6510 assembly.

------
jwr
Yes! I am so glad somebody called out the UI animations! The one in 1Password
bugs me every time, I don't use Spaces because it takes too long for the
animations to play out. There are more examples.

Every time a programmer adds an animation, a settings option should also be
added to "disable animations". Advanced users will love you for it!

~~~
fingerlocks
I'm confused. By Spaces animation, are we talking about the horizontal sliding
transition?

On my machine (High Sierra) the transition time between Spaces is dependent on
the finger gesture swipe velocity. I'm not really sure I would even call this
an animation- the Spaces x-offset is being adjusted as I move my fingers along
the track pad in the same way as scrolling up/down in a browser behaves.
There's literally no waiting for the "animation" to complete; when I lift my
fingers I'm either in one space or the other.

~~~
jwr
Compared to i3wm on Linux, it takes ages. I can could probably switch
workspaces three or more times (using the keyboard) during the time that a
single Spaces animation takes to complete.

Also, I am on High Sierra too, and there is at least a half-second lag between
when the gesture ends and when the animation is complete. Taken together with
the time it takes to initiate the gesture, I'd say we're around 0.75s.

------
cnasc
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 of yore_

[1] [https://arcan-fe.com/](https://arcan-fe.com/)

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

~~~
cnasc
I think it's a fantastic project! Seems like a lot of what I want in a
desktop. Looking forward to the new posts.

------
GlenTheMachine
<Slow clap>

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.

~~~
swiley
If you use mlterm (and supposedly xterm with the right compile flags) you can
have inline pixelmaps via DEC -regis- sixel escapes.

~~~
digi_owl
Actually i think REGIS is for vector graphics, SIXEL (six pixels pr character)
is the pixel graphics.

I seem to recall that at least one terminal browser can pull some tricks to
insert images into the window in X as well.

~~~
swiley
Oops, you're right.

The browser you're thinking of is w3m.

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

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

------
juancampa
> We need a reboot. We need toolkits that produce interfaces that are fast,
> consistent, bug free, and composable by default

I would add to this list "programmable" so that automation is possible without
being too disconnected from the GUI. Imagine clicking on an element in the
page and being able to see (and use) the API behind it. This is one of the
premises behind our project (shameless plug alert:
[https://membrane.io](https://membrane.io))

"Bug free" though...

------
fhood
"UIs that are pretty and friendly are nice to have, but the true values of a
good interface should be speed and efficiency to make their users as
productive as possible."

Nonononononono! Both. I want both. The biggest problem with terminal
interfaces is that very little of the functionality is obvious from the
outset.

~~~
amiga-workbench
Ease of use and utility/efficiency seem to exist on the opposite ends of a
continuum.

The more common "easy to use" software is designed to be up-front and
intuitive but because of its nature it is hobbled from a maximum
utility/efficiency standpoint. The interface usually relies on interaction
modes that are severely limited in bandwidth (poking things with a pointer).

And the stuff on the other end is designed to be as useful and efficient as
possible, but because of this its functions aren't immediately obvious and it
requires the user to actually read the manual instead of fumbling their way
around the interface. Once you actually put the time and effort in and learn
the program you will be working far faster with this than the friendlier
software.

There is one piece of software that comes to mind which seems to exist in a
happy medium, the nano text editor can be extremely powerful once you learn
the hotkeys but it meets you half way and gives you a heads up of all the main
functions without you asking.

------
justamus
I absolutely agree that aesthetics shouldn't come at the expense of
efficiency, but I don't think it's practical to expect every user to be a
power user. There are some products and programs, like the Adobe Suite and a
bunch of terminal programs, that are marketed for and should be designed with
power users in mind. But I'd say the majority of programs we use every day
aren't designed with professionals in mind - they're designed for a standard
computer user. And having something that "just works" rather than something
that is tailored for a power user is absolutely valuable to the billions of
people out there that aren't going to be power users.

Slack, like I'm thinking a lot of applications, falls in a middle ground where
lots of users are power users, but many use it just a couple times a day, or
less. It should be fast for those users, but those users shouldn't have to
climb a steep learning curve to get value out of the product. An ideal
interface would be easy for a newcomer and powerful for an experienced user,
but that's a difficult challenge for a designer, and tradeoffs need to be
made.

~~~
unwabuisi
Yes, I agree here and you would not be losing much with the added effort.
power users are already more likely to dig into most software/s and tweak
settings so it is a win-win

------
JoshMnem
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 accessibility issue[1][2][3], especially when the
animation is designed to mimic physical motion (parallax, Material Design,
etc.).

To try and make computing bearable, I switched to i3wm and turned off all CSS
animation in my browsers with Stylus. It's still too much.

I also have a suspicion that animation is causing cognitive damage to users by
regularly breaking attention.

[1]
[http://simplyaccessible.com/article/animations/](http://simplyaccessible.com/article/animations/)

[2]
[http://accessibility.psu.edu/animations/](http://accessibility.psu.edu/animations/)

[3] [https://www.smashingmagazine.com/2018/04/designing-
accessibi...](https://www.smashingmagazine.com/2018/04/designing-
accessibility-inclusion/#lens-animation-effects)

~~~
arendtio
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 for your computer to finish
rendering and that sucks.

[1]: Terminal emulator which comes down from the top of the screen
[https://www.kde.org/applications/system/yakuake/](https://www.kde.org/applications/system/yakuake/)

~~~
emilsedgh
I used to use Yakuake heavily. Loved it. It made me much more productive.

Then I realized what was the reason behind it. And it's not the animation.

Yakuake has a specific shortcut that your muscle memory can remember. Making
Yakuake super accessible. It's like my brain has now O(1) to access my
konsole.

So I removed Yakuake and saved a specific shortcut for Konsole.

It's much better. Because there's no annoying notification and the window is
full screen.

I applied this pattern to all my apps and I'm far more productive than I've
ever been in any environment:

F1 opens up browser

F2 opens up pdf viewer

F3 opens up text editor...

(You can apply a shortcut to any application/window using Kwin -> Special
Application Settings -> Arrangement & Access

------
TheOtherHobbes
There are _very_ few web apps where users need - or want - to do any kind of
intelligent, complex text editing.

Most web apps are virtual paper forms with pre-filled menu options and -
usually - a bread crumb trail so users can change their choices and/or their
minds.

Animations are largely irrelevant to the user experience. The best way to
speed up this kind of web app is to iterate over and over to find the sticking
points empirically, and then nuke them from orbit.

That means minimising the number of menus, making sure they have useful
defaults, and spending extra time on problematic elements like date and time
selectors.

The user should type as little as possible and click as little as possible to
get the job done. Beyond that, "productivity" does not apply as a concept.
Users do not need composability or grep-like text manipulation options.

It's also handy if a page looks good, because this makes an impression on many
users and is one factor that can persuade them to come back.

So no - I do not think there's anything of value in the OP, except perhaps as
another example of "Developers want to turn everything into a emacs and a
build system, because that makes them happy, even though it's 100%
inappropriate for non-developers."

~~~
TeMPOraL
I disagree on several aspects.

I do agree that "most web apps are virtual paper forms with pre-filled menu
options (...)", but that doesn't mean they don't need productivity
improvement. First of all, many people use those "forms" for work, not just
casual browsing. It's one thing when you're putting up some old book you found
on eBay, it's another when you have to manage hundreds of such auctions each
day. Suddenly, the difference between old and new web design trends is
measured in 10x increase of time spent on task.

I know because I sometimes help my SO do her work tasks faster, and usually
get 10x-100x speedup with clever application of web scraping, regular
expressions and batch processing in command line.

Another thing - people don't "fill in forms" in isolation. Each webapp being a
productivity-hostile silo causes pain whenever a task involves more than one
of them. Often, users do in fact need "composability or grep-like text
manipulation options", they just don't get them, so they suffer (or delegate
to a friendly programmer, who can _force_ a webpage to have some semblance of
interoperability, whether its authors want it or not).

> _So no - I do not think there 's anything of value in the OP, except perhaps
> as another example of "Developers want to turn everything into a emacs and a
> build system, because that makes them happy, even though it's 100%
> inappropriate for non-developers."_

It's not that - though I do believe that Emacs presents a much better UI
paradigm than the one accepted in the mainstream (due to flexibility,
interoperability and consistency). It's just that present day software - web
apps in particular - are _ridiculously_ hostile to productivity. The perfect
solution is not doing everything from CLI, but it's also not shiny, animated
web UIs exposing as little functionality as possible while still being able to
sell the product.

Someone upthread mentioned the concept of threshold and ceiling. Emacs and CLI
tools are high-threshold, high-ceiling. Webapps and mobile apps are low-
threshold, low-ceiling. Perfection would be low-threshold, high-ceiling - that
is, something accessible to beginners, but designed so that they can level up
and become power users, if they need/want to.

------
lxe
Last year's discussion when it was posted:
[https://news.ycombinator.com/item?id=13733777](https://news.ycombinator.com/item?id=13733777)

------
npunt
Agree with author that desktop UIs could be quite a bit better, and web tech
gives devs enough rope to hang themselves with, which most do. Rest of the
article sort of reads like a general annoyance with a grab bag of various apps
and UIs tho.

The most revealing part of the article is that the author states current UI
philosophy is making things legible and intuitive, but that UIs should be
about speed and efficiency. These aren't really either/or, good UI/UX should
explore the frontiers of both, and pitting them against each other feels off.

I think speed/efficiency are proxies for something deeper that the author is
really getting at - many apps focus on approachability so much that they
become superficial when they should be powerful. There are, however,
approachable apps that are powerful. For example, Airtable is quite intuitive
and approachable, but ultimately its a tool that helps users manage
complexity, not avoid it. This class of tools is what we need more of, and I
think the author is looking to fixing frameworks when deep down the problem is
actually having better apps (e.g. this feels like category error).

Also, the author is asking for a reboot, but has failed to look at the most
important UI reboot in the last decade - iOS UIkit. A junior dev can make a
passable app just by following iOS Human Interface Guidelines that is
accessible, responsive, intuitive, etc.

Personally, I like terminals for their show your work ledger aspect and the 'I
know exactly what I want' factor, but just about everything else they're
terrible at UI-wise. And in improving them, I'm not seeing anything in this
piece that makes me think the same mistakes won't be repeated over again.

------
SteveJS
Visidata seems like an example of the kind of UI this author thinks would be
better. [http://visidata.org/](http://visidata.org/)

A former coworker used this as his project while on sabbatical at the recurse
center.

It is mostly GPL v3, except for MIT license on the core UI.

From the Visidata GitHub page: The innermost core file, vdtui.py, is a single-
file stand-alone library that provides a solid framework for building text
user interface apps. It is distributed under the MIT free software license,
and freely available for inclusion in other projects.

------
goldenchrome
You can only have success in building interfaces if you first understand who
your users are, and what problem you're solving for them.

The author compares the benefits of flashy, spread-out interfaces and CLI. The
truth is that both have incredible value in the right contexts. The tricky
part is making an interface that is easy to pick up, but powerful enough for
power users.

If you deeply understand your users you can build adaptive user interfaces[0].
LayerVault experimented[1] with the idea of progressive reduction—stripping
down UI elements as the user becomes more familiar so they can work more
efficiently.

[0][https://en.wikipedia.org/wiki/Adaptive_user_interface](https://en.wikipedia.org/wiki/Adaptive_user_interface)

[1][http://layervault.tumblr.com/post/42361566927/progressive-
re...](http://layervault.tumblr.com/post/42361566927/progressive-reduction)

------
neeasade
Everything the author describes lacking in the end exists in emacs. Come on
in, the water is fine.

~~~
yourapostasy
Are there Emacs-based terminal UI libraries?

Looking at how insanely fast competent line staff are with terminal interfaces
like in retail POS settings, I sometimes wonder if Emacs would be fast enough
to keep up with them. If so, instead of using a browser as the base UI
framework, would a terminal-screened Emacs (that is, in console mode or
perhaps inside xterm, and not the graphical Emacsen) with an appropriate text
UI library be feasible?

It can't possibly be worth the effort unless the text UI in the code is the
only presentation layer, I'd imagine. But if you have to go down that route,
it might be faster and easier than rolling your own termcap-based text UI,
especially with all the elisp goodness within. The only extensive text UI I
knew of was Vermont Views' product, which has since disappeared off the Net
and was closed source anyways. There are some open source libraries, but none
with nearly the power that came with that closed source offering, and all
still quite low level.

------
alkonaut
I think it's probably easier to make a web app or desktop app as
fast/bare/responsive/etc as an old terminal app, than it is to add good
rendering of mixed fonts images etc into terminals.

So what he's arguing for is simpler, faster traditional non-terminal apps.
Because those are good.

------
axiomdata316
'Software on the web today takes too long to load, depends too heavily on
synchronous calls to slow networks, overemphasizes visual gimmickry, and lacks
the refinement that allows mastery by more experienced users to gain huge
leverage for productivity’s sake.'

This nicely describes the road Intuit has gone down with QuickBooks Online.
Slow user interface, and lack of productivity. I wish Intuit would take half
the money they spend on Marketing and use it to develop their Desktop
offerings of QuickBooks.

------
xpaulbettsx
> I think we can all agree that the interface of this prospective future is
> incredible and desirable, but if we drill into it, what’s its most amazing
> aspect?

This had to make me laugh a little bit. Jaron Lanier actually designed this UI
to intentionally be unusable and bad, because the film was described to him at
the time as a Dystopian film, so he designed a computer interface to be
equally dystopian. Yet, the effects look so cool, that people actually thought
it was a good idea

------
ArtWomb
That "Composability" bullet point rang so true for me just now. There are
command line tasks for which I can just be 10x productive. And it usually
comes down to the simple portability of stream IO.

Cloud functions may create a set of standard libraries or tasks that can be
ported to any interface. You can get a sense here from this snapshot from a
recent Google Cloud Next talk:

[https://imgur.com/a/RghGkQE](https://imgur.com/a/RghGkQE)

Many of the libraries are multimedia related. But its easy to see how the set
can also include Cloud ML functions for pre-trained scene recognition.

Another welcome development is an anecdotal renaissance in IRC. Slack and
Discord are killing it due to the ease with which new users can come onboard.
But the communities forming around mission critical infrastructure, chaos
engineering and SRE seem to rely on the old tried and true minimal ircd
configurations from last generation.

There is no reason for web application entropy to make sites unusable. Modern
browsers have high performance timers, request animation frame, gpu
acceleration, background workers, and of course access to low level
instructions via web assembly. It comes down to investing in the web again.

------
agumonkey
One of my favorite application interaction was an old as400 thing from the 80s
at the tax office. I was in college and still a bit into async js + css (in
theory). That app had usual terminal screens, but the ergonomics were
holistic, no brainer keyboard usage, no latency whatsoever, and the software
was helpful. It was such a bliss. Software was never in the way, the only time
it bugged you was to actually notify you of important issues (absurd data) and
to provide either correct automatic fixes or a few clear suggestions. I
realized how much context/paradigm is worth. It was obvious the efforts were
spent on logic and not tech for the sake of it. Ironically it was the first
wave of web2.0 business fad, so we were introduced to the new reincarnation of
the tax UI in html/css and it was subpar in speed and ergonomics, and was of
no help.

------
ChuckMcM
I don't think the 'terminal' model of UI gets enough attention. I don't know
why that is, perhaps it is a feeling that it is the "old" way to do things and
so not a source of good ideas.

Xerox's XDE had a very nice terminal. It could use proportional fonts and you
still had precisely formatted text for code. It was not as fast as a VT100 or
an xterm which relied on monospaced fonts. But that was the root of the issue.

Terminals conflate "formatting" and "content" in the worst way possible, there
is content that "is" formatting (whitespace). This closely mimicked how
typewriters did it but they did it that way not because it was "best" but
because it was "possible" given the mechanics of building lines of type
without a bunch of lead letters.

It is insidious how that in band content/formatting mixing of ASCII and then
later ISO-Latin-x drove compromises in editor and text manipulation tool
design. But here we are.

I wrote a pretty printer for come code once that pulled apart the format from
the content and it would print out source code with a nice proportional font
(I think a2ps(1) could do this too at some point) and I admit that the code
"looks wrong" in that form but I also have to admit that it only looks wrong
because I'm not used to seeing it in that form. It is harder to read when
things like parenthesis fade into the text because they are so much thinner,
but this is again the design vs eyeball sorts of trade-off.

When I read this bit what I heard was "Gee, it would be really awesome if some
designer could capture the flow of terminals with a modern set of
capabilities." But that XDE terminal? Dave Curbow, who was with Xerox Business
Systems, once tracked down how many function calls had to be made before the
glyph ever hit the screen and it was a _lot_. It made it hard to run
efficiently on the hardware of the time (great when you can code new
microcode, less useful on CPUs without that capability).

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

------
sebringj
I think animations that you don't notice as animations are the most useful.
Take scrolling and scroll locking an element to fixed when a threshhold is
reached. A slide down of a section opening, a zooming of an image, a swipe
left... these are useful gestures that are not noticed but rather feel as
though they should be part of the experience naturally. Focus on useful
animations that add to the experience but we are not going to the stark days
of command lines ever again although as a programmer I love them and can't
stand probing for settings deep in UIs or navigating nested trees via
clicking. We are not normal though.

------
rini17
Happy KDE Plasma user here(with KDEPIM/KMail too), on 10y old AthlonII desktop
with 5y old GPU. All GUI animations are configured to my taste, inobtrusive
and smooth, on 4K monitor.

------
LeoPanthera
On macOS, SysPrefs > Accessibility > Display > Reduce motion will disable some
of the unnecessary animations.

I don't know if third party apps can read this setting and also comply.

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

------
sriku
One way to think about interface power is in terms of thresholds and ceilings.
CLIs are powerful with a somewhat high threshold and high ceiling. In the
attempt to lower the threshold, most UIs and OSes significantly lower the
ceiling too.

I don't recall who originally described it this way. One of Logo's motivations
was to have an experimentation environment for kids with low threshold and no
ceiling. Perhaps Seymour Papert.

------
jancsika
> Composability: I’m far from a zealot singing the praises of the Unix
> philosophy, but most terminal apps produce output that I can process in some
> way to get into another program.

Composability _within_ the conceptual framework of the terminal itself (e.g.,
using a pipe).

But suppose I want to shuttle text back and forth across the terminal/GUI
domain.

Do I even have a reliable way to select and copy text that extends past the
viewport of a terminal? Even the method of copying a selection isn't cross-
platform in terminals (e.g., among terminals running in Linux/OSX/Windows).

Compare that to the holy trinity of <ctrl_or_cmd-a>, <ctrl_or_cmd-c> and
<ctrl_or_cmd-v> in any viewport of any web browser.

Plus, you can't even depend on a particular feature being available to a
terminal of a single platform. Take the example of middle-click selection
pasting from the terminal. Can I depend on distros to _never_ bother me by
removing that feature? If so, what is the standard that governs the
requirement for this feature?

~~~
TeMPOraL
> _Composability within the conceptual framework of the terminal itself (e.g.,
> using a pipe)._

Personally, I think that operating systems (and browsers) failed in enforcing
such a framework, or at least _strongly suggesting it_.

Compare with Emacs, which is a prime example of how interoperable software
could be, if it adhered to a common paradigm more. There's a reason people run
tasklists, e-mail, IRC, shell, time tracking, invoicing and others straight
from it. It's not because they're crazy. It's because the overarching UX
principles enable greater productivity and integration than it's possible
elsewhere.

------
carapace
If you're interested in good UI design read Jef Raskin, "Humane Interface"[1].

You should also study the Oberon OS. You would have to read up[2] on it to use
it[3], but it's a high point of UI elegance that has never been equaled since.
(Specifically the base system plus the "Gadgets" UI extensions.)

[1]
[https://en.wikipedia.org/wiki/The_Humane_Interface](https://en.wikipedia.org/wiki/The_Humane_Interface)

[2] [http://www.projectoberon.com/](http://www.projectoberon.com/)

[3] Live in-browser Oberon system from original source code, via JS emulator
for the underlying RISC CPU:
[https://schierlm.github.io/OberonEmulator/](https://schierlm.github.io/OberonEmulator/)

\------

edit:

And if you want to read a book that fell through a wormhole from thirty years
in the future read: "Computers as Theatre" by Brenda Laurel.

------
antome
The first thing I do when I get a new Android phone, or update the OS, is
disable all animations. As a consequence, my Nexus 5X is in some respects more
responsive than many flagship phones today. Sometimes animation can feel nice,
but after using a piece of software more than a few times, I'm much more
interested in responsiveness.

------
blunte
As with debugging, it's important to choose your battles. How often do you
start up slack? Is that 45sec once per day or even per hour, or is it per
minute? Obviously it's not a frequent occurrence. So that delay, regardless of
your computing power, is not an issue.

A case where it does matter is with a good mobile phone camera. It must launch
and be able to capture an image within one or two (or at least within 5)
seconds.

But back to the Electron topic... Would you rather a tool exists and isn't
perfect, or it does not exist at all? Ok, or maybe it exists but costs $99 per
user?

I love clean, performant, low latency interfaces. I live in a terminal. But I
also understand the value of developer time. Whether tools and frameworks
actually make devs more efficient can sometimes be unclear, but often they
allow things to be made that otherwise wouldn't be made due to budget (time
cost) constraints.

~~~
013a
> Would you rather a tool exists and isn't perfect, or it does not exist at
> all? Ok, or maybe it exists but costs $99 per user?

I understand this argument for niche tools. I'm eternally grateful for things
like Insomnia (a GraphQL client), NoSQLBooster (MongoDB GUI), etc, all written
in Electron. I understand that asking for things like that in native is a
recipe for them to not happen, or for them to be Mac-only, or for them to cost
$100/year.

Slack is not in this category. It is produced by a corporation valued at three
billion dollars. It is a product that is completely, totally, and wholly
solved. They produce very little that is novel. I expect that experience to be
all twenty shades of pixel perfect, because they have no excuses.

Let's look at Telegram. Great app. But they wondered if there were ways it
could be improved, so they released, simultaneously, Telegram X on the app
store [1]. A rewrite, using the same backend and APIs. It's even better. With
Slack's resources, they could have done this twenty times over.

[1]
[https://telegram.org/blog/telegram-x](https://telegram.org/blog/telegram-x)

------
ProxCoques
Hi. UX designer here who reads Hacker News as a way of keeping tabs on what
geeks are up to :-)

I think the article is generally correct when it concludes that we're on the
wrong path. But I'd just like to assure the "engineering community" that the
"design community" is fully aware of this and has been since about 2003
(mainly due to the effects of Flash at time - remember the loading screens?).

Part of the problem stems from the fact that UI design has swung into a bit of
a dark age at the moment in terms of usability. Most designers are "visual
designers" who don't know much about the history or practice of interaction
design as developed by Norman, Raskin, Tognazzini, Nielsen, Cooper and others.
With so few interaction designers around it's not surprising that UIs are
designed to just look good rather than also work well. Some of the main issues
are summarised here: [https://www.fastcompany.com/3053406/how-apple-is-giving-
desi...](https://www.fastcompany.com/3053406/how-apple-is-giving-design-a-bad-
name)

I'd also point out that this means engineers are probably just as confused
about the difference between visual design and interaction design, since there
are so few people to look to who are practising the latter. So articles like
the one at brandur.org will be written as though they are broaching new issues
on the topic. In fact, discussions around the advantages of CLUIs are pretty
old and nothing in the article is particularly new in that regard.

The only thing I'd say after that is a minor point: he says native phone apps
are faster and more responsive than web ones. Is that true? The apps I have on
my phone mostly use webviews or network API calls for large parts of their UX
which is by definition practically the same speed as the web, no? At least, I
can't tell any difference between using, say, Amazon's native app to search
for and buy something compared to if I go to Amazon with my phone's browser.

------
analog31
>>> These powerful devices should be propelling our workflows forward with us
gangly humans left barely able to keep up, and yet, almost without exception
we wait for our computers instead of the other way around. We’re conditioned
ourselves to think that waiting 30+ seconds for an app to load, or
interrupting our workflow to watch a half second animations a thousand times a
day, are perfectly normal.

In addition, the GUI has conditioned us to think that in order to make a
computer do work for us, we have to perform precise manual labor to guide it
through a lengthy series of tiny discrete steps. "I have seen the computer,
and he is us." In addition to making those steps quicker, we should also be
thinking about how to eliminate them altogether by having the computer
understand natural language.

~~~
makecheck
This extends to how people think about teaching others about computers. I
would get so frustrated with E-mails that consisted of about 9 “steps” to walk
through when using a WEB site, instead of posting a direct link to the final
target!

The progress animations are out of control too. Every time I see one, I
imagine the engineering hours it took to animate and wondered if they could
have just spent hours optimizing the code instead. The _weirdest_ thing about
a lot of progress indicators is that developers don’t even get the point: your
indicator has to be _in sync_ with the activity! It has to give meaningful
updates, it can’t just be a background animation that looks alive even when
the server has died and isn’t coming back.

~~~
analog31
Indeed, I've seen installation instructions that come with hardware
accessories or software, where it's page after page with pictures of dialogs
with circles and arrows and a paragraph on the back of each one.

And they don't apply to your version of the OS.

The instructions for installing the same thing on Linux is just a series of
commands that you copy and paste into your console.

------
tylerc230
I remember finding TermKit a while back and thinking it had some interesting
concepts. Looks like it hasn’t been touched in a while though.
[http://acko.net/blog/on-termkit/](http://acko.net/blog/on-termkit/)

------
devxpy
> compose able by default

You're looking for click

[http://click.pocoo.org/5/](http://click.pocoo.org/5/)

It's the best framework across any programming language that I have found for
building command line user interfaces.

I instantly know how to use an application made using click because it
prevents you from making non-obvious GMO interfaces.

Even as a developer, I love using it. I often create CLIs for common chores in
my projects using click. The applications always come out perfect, with little
to no effort.

I wish there was something like this for GUI.

This makes me want to make a GUI framework like click, where you don't deal
with the bare components, but "compose" your UI by just providing data

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

------
branislav
I agree with the article in that designers can be too focused on the shiny and
non-functional aspects of interfaces.

Personally I would treat _design_ as being purely about function and anything
superficial is about _aesthetics_.

But I think the author is throwing the baby out with the bathwater by wanting
to restrict all animations. Fast, subtle animations, especially in the form of
transitions between states/screens are extremely important for keeping the
user informed about where they are in the context of the system.

~~~
collinmanderson
I also think animations are not what’s making slack take so long to load.

I don’t think it would load any faster without the animations.

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

------
perishabledave
I wonder if the 1Password animation only seems egregious to me because I'm not
the crowd that it'll add value to. I understand on some level what 1Password
does when I enter in my password. If I were to get my parents to use 1Password
however, the visual effect of the vault unlocking could help them understand
what 1Password does.

I think we may be too quick to judge these things within our own context
rather than in the broad range of users which these user systems were designed
for.

------
fermienrico
I totally agree with this article and if the author is reading this comment,
please do one about touch based interfaces. I am sick and tired of touch
interfaces in Cars, home appliances and laptop screens. I want a billion knobs
and switches. About the only place they make sense is an hand held phone.

Every designer needs to read this article. I am just so angry at what is being
taught in graphic design schools and the sheer incompetence that graduates
from UX/UI courses.

------
gumby
The other important factor the author neglects to mention is the _keyboard_
\-- ctrl-tab is so great because you don't have to take your hands off the
keyboard or your eyes from the screen. The place the machine _is_ waiting for
the user is when he or she is screwing around with the mouse and then
returning their hands to the keyboard.

------
z3t4
If "terminals" was improved to support fonts, images, videos, etc it would
basically become a _web browser_.

------
westoncb
Reading this reminded me of my parents sitting on their patio, complaining
about the neighbor's air-conditioning unit. I wouldn't even notice the sound
it was making until they said something—but for for them, being so tuned into
it and having it already on their mind as 'a problem,' it was a prevalent part
of their experience.

There are two regularly occurring situations times where I'm delayed by the
slowness of interfaces:

1\. At work, waiting for our web app to reload after I've made some changes to
the source. This is actually a problem and eats up a significant amount of
time and makes me lose focus.

2\. I'll occasionally come across a slowly loading webpage. And I stress
'occasional' here—it's maybe once every couple of days when I open an article
on HN or something and it's some site with a tons of ads and stuff. It's a
non-issue—easily less than 5 minutes per week.

Aside from those delays, I basically never find myself waiting for whatever
software interface I'm interacting with, and that's on a 2014 macbook pro.

------
mbrock
I was once annoyed with the slowness of Lynx, the terminal web browser. Poking
around in the source code, I noticed that it literally called sleep() several
times while loading a page. I removed every sleep call in the code and
suddenly Lynx was a lot faster. Try it!

------
131012
My only disappointment working with terminal comes from SQL queries (mostly
mysql & postgres). The queries results always come scrambled and absolutely
unreadable. Anybody ever heard about 'responsive design' for sql results?

~~~
pwg
The results likely have lines wider than the screen. Configure your CLI access
app to display table results using the "less" pager, then configure your
environment variables to include the "-S" option to less. The long lines will
be clipped at the screen edge (instead of wrapping) and you can scroll around
horizontally and vertically (look into the less man page for how to move
around inside of less).

edit: typo

------
kayoone
I think you can get pretty close by investing a lot of time into configuring
your perfect linux desktop, but hardly anyone is willing to do that as OSX or
even Windows is good enough for most people.

------
daguire
I couldn't find a date on this article, but the author clearly isn't using the
latest (rebased) version of 1pass which still has the animation, but it's very
smooth and quick.

------
erikpukinskis
I don’t accept that HTML is the reason why Slack is slow.

Can anyone explain, in concrete terms, what resource does Slack require a lot
of, which is fast to produce on iOS but slow to produce in HTML?

------
Posibyte
I get the idea, and I agree in general. However, I've always struggled with
DE's like i3 because they were so barren with visual information up front. I
respect the power they present, but I appreciate a nice balance. Animations,
more than anything, just need to be paced appropriately. They help a lot in
easing a user into a flow within an app. Slack for me does this perfectly. It
doesn't feel kludgy, slow, nor does it feel like everything pops up in your
face loud and obnoxiously. The interface and animations helped me feel like I
was getting down a flow, and when I learned the hot keys and patterns, it felt
like playing an instrument well.

------
nicodjimenez
I like this article. In the future everyone will be "a developer", and apps
that are developer centric will go mainstream - at least that's my prediction.

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

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

Yes, and here's the point I would like to stress that is completely lacking to
make the idea of user friendly terminals work:

 __GUI:s are more user friendly than Terminals because of discoverability and
limiting affordances. __

User friendly Terminals might just be possible if you allow users to explore
what is possible with clever search and query completion. It should be able to
recognize what entities you are likely typing about and suggest commands that
use them. Let 's call it "Semantic terminal"?

------
malkia
[https://github.com/ocornut/imgui](https://github.com/ocornut/imgui)

------
Kirth
Seeing that 20 second start-up time [of the Slack OS X desktop app] in the
video on the site was kind of painful :/.

------
SteveJS
Jef Raskin's book "The Humane Interface" is basically the book-length version
of this article.

------
iamwil
I had thought the author meant airport terminals, and was waiting for an
insight to come that never did.

------
a2x
agreed - at the end. But a terminal isn't faster per se. It is fast if you are
a rapid typer and have all the knowledge to point exactly that command with
that param in the right terminal and the right context. Otherwise, it is just
a blank piece of paper. ;-)

------
baxtr
Isn’t one of the most successful companies ever built on that principle?
(Google.)

------
arg84
Ironic that the author uses up 2/3 of valuable screen space for the title of
the article when a much smaller size would have sufficed. It took me extra
time to scroll down to the main content. This just goes to show that
aesthetics have more value than perhaps the author is conscious of.

~~~
juancampa
An article, something you use once, is different from an application, which
you use continuously for long periods of time

~~~
arg84
Following that logic would mean that the more time we spend interacting with
the medium the less important aesthetics/gestalt is, and that the medium
should instead be focused solely on function. I think one thing the low level
tech focused individual can sometimes overlook is that it is humans
interacting with these interfaces, and humans are varied, and as such
interfaces need to incorporate many different methods of engaging the user.

~~~
juancampa
Aesthetics are always welcome as long as they don't compromise usability. What
I've noticed is that the more you look at something, the more normal it tends
to look, regardless of whether initially you thought it was beautiful or ugly.
Not sure why it happens but aesthetics stop being as important as time passes.

~~~
arg84
I agree. I just think we shouldn't be too quick to write off things that seem
frivolous or maybe slow down the power user. For example a fade animation may
seem like it's wasting time, but used properly it creates a visually pleasing
transition, while at the same time possibly allowing for work to be done in
the background while the UI would be otherwise unresponsive. However, I have
also seen this abused as well. I think it's best that we continue to call it
into question like this article does, but also try and stay balanced and not
ignore some of the other considerations.

------
ests_eu
This is why I am loving Alfred, and recommend it to everyone I can.

------
plg
What is the terminal running in the 5th movie? (ThemWare)

------
OOPMan
I stopped reading when he claimed Minority Report was a great movie, the
forecast UI was "incredible and desirable" and confused the technology in the
movie with the book on which is was based.

------
hkon
I like animations. The blinking cursor for instance.

~~~
arg84
That's a great point of how animations communicate an idea to the user

------
stevebmark
please, god no. i've watched so many "terminal gurus" painfully hold left or
right keys to jump to editing text (I use vi mode, but it still sucks). i've
watched them fumble with !! to do something they think is efficient, but
really slows them down. i've watched them write unreadable buggy awk scripts
over the course of hours that end up not getting the job done. terminals are a
classic example of fundamentally bad design.

~~~
LyndsySimon
Could this be because people who are in the process of learning things like
that are more apt to use them and show them off?

------
skookumchuck
One of the failures of modern GUI design is exemplified by the calculator app
on the iphone. It looks exactly like the old stand-alone desktop calculators.
What could be wrong with that?

Have you ever used a calculator, and wondered if you'd punched in the operands
correctly? I have. And so I do the calculation again.

With a scrolling terminal, you can see (and check) the operands on the
previous line(s).

~~~
ytjohn
It's for macOS instead of iOS, but numi is a great scratchpad calcualtor.
[https://numi.io/](https://numi.io/)

Never tried it, but Soulver looks like a good solution for iphone:
[https://acqualia.com/soulver/](https://acqualia.com/soulver/)

and CalcNote on Android - just installed this and its' just like numi.
[https://play.google.com/store/apps/details?id=com.burton999....](https://play.google.com/store/apps/details?id=com.burton999.notecal.pro&showAllReviews=true)

------
guessthejuice
Bare bones terminal design is great for power users just like vi is great for
power users. The saying is as you get more competent in linux, the more you
stay in the shell/terminal with the keyboard and the less you use the mouse.
But for ordinary folks ( especially beginners ), they are drawn towards
animations, mouse clicking, visual, etc. And most beginners don't advance to
the power users stage. My guess is that this pattern will hold in the future.

------
394549
I few months ago, I changed a developer-options configuration on my Android
phone to increase the speed of the animations to the maximum. My phone felt
_so_ much more responsive, it was like I got a major processor upgrade.

IMHO, two big curses in UX today are unnecessary animations and webfonts that
render ugly when font smoothing is off.

------
auct
I agree that we need more speed. Some websites and apps are too slow.

We need faster network and faster websites.

~~~
sdx23
> We need faster network and faster websites.

We need less bullshit on websites, that'd solve both problems. See e.g.
[https://www.techtimes.com/articles/229533/20180606/thanks-
to...](https://www.techtimes.com/articles/229533/20180606/thanks-to-gdpr-eu-
version-of-websites-are-faster.htm)

------
transfire
Yes.

------
DannyB2
What is a console?

Definition:

Console: (verb) To comfort someone in a time of grief because they are forced
to use the command line.

Oh, wait. You thought console was a noun?

~~~
rhencke
It is a noun as well.

[https://www.merriam-webster.com/dictionary/console](https://www.merriam-
webster.com/dictionary/console)

Specifically:

3b. a combination of readouts or displays and an input device (such as a
keyboard or switches) by which an operator can monitor and interact with a
system (such as a computer or dubber)

