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)
> 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)
>>> 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.
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.
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.
On the one hand, a voice interface would be really great. Think of a car - you could control things (open/close the windows, turn the AC on/off, change the radio station, ...) just by talking without ever taking your eyes off the road. This might actually prevent a few accidents.[0]
On the other hand, imagine the office where I work, one room, four people, and imagine them talking to their computers instead of typing or mouse clicking.
[0] I have no idea how many accidents are caused by drivers looking at their radio, AC control, whatever. I am conviced the number is greater than zero, but I suspect it is only small fraction of the overall number of traffic accidents. But still.
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!
I have a Wells Fargo auto loan. Their site is separate from the main Wells Fargo site. They have no animations (not even spinners) and basic web forms. The site feels so fast compared to other sites it's jarring. I often feel the need to double check that what I just did actually got applied because it feels like someone is presenting a mock UI demo with static images.
It would not surprise me in the least if the 1Password unlock animation is a deliberate attempt to hide the time it takes 1Password to decrypt your password list.
I seem to recall reading this when I investigated before. Article is shooting the messenger in a way, the animation is not the problem. Agilebits (the co who makes 1password) generally aren't the types to introduce superfluous elements.
It's not the decryption process that is slow (computers can do AES really really fast these days), it's the deliberate slowness introduced by PBKDF2, which attempts to thwart brute force attacks.
> Every time a programmer adds an animation, a settings option should also be added to "disable animations".
You can disable every animation in OS X itself via the command line (defaults write). I put them all in a shell script that I run on new installs. You may be out of luck with 1Password.
Unfortunately, not every animation. In particular, the Spaces transition animations that the OP is complaining about is not one of the ones you can disable with `defaults.write`.
I re-check if it's been added with every new macOS release; no luck so far :(
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.
Agreed on the gesture, I feel that’s implemented well. But I suppose the author is talking about the animation you get when using the keyboard. I also find myself annoyed switching spaces on macOS vs. dwm, tmux, etc.
Something else: I got myself a tablet a few weeks ago and now find myself disliking the constant scrolling and wishing for (instant) pagination instead.
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.
They are keyboard-based ways to switch spaces too.
I do find that if you use the keyboard to switch spaces quickly, the animations become faster too. Unfortunately the app in the other space do not get new keyboard input during the animation.
Incidentally, I am on Xubuntu, and I would love to have the workspace switching transition that macOS has. Switching workspaces on xfce is lightning-fast but I would love to have an indication on whether I moved left or right. (other than the small indicator in a Panel) Ubuntu solves this with a HUD (or at least did with Unity).
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.
In an ideal world everyone would get a UX specifically tailored to their expertise level. Software must be a LOT cheaper to build for this to ever happen though.
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
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.
mlterm also works great with non-monospaced fonts (but doesn't, to my knowledge, have a way to switch between fonts within terminal output, which seems to be what the OP wants).
I've always wondered what a tiling window manager provides over tmux. This isn't a rhetorical question, I've never used a tiling window manager.
Anyway, a separate space with full-screened iterm2 + tmux on macos is my preferred way to work. I can swipe left to check slack, browser and then swipe right to go back to my terminal.
The old Symbolics Genera had a "terminal" which was extremely interactive and object based, yet still worked much like a modern text only terminal. I still love working in that operating system. Pictures, fonts, diagrams, etc., were all supported well. I have not tried video nor seen examples of it but those computers were responsible for some CGI in movies in their time, so may have been supported.
I find the conclusion of the article totally off the mark. The author seems to not understand that problems begins with multimedia support and other "gimmicky" stuff (as he puts it). You want video? Then use your terminal to launch a video player. A tiling manager is precisely perfect for this (I wonder why you switched to i3 if you don't know that, btw).
Oh, I know that. But what I'd really like is something akin to Jupyter, only for the shell. I think I'd like that, anyway.
For example, right now I can issue a shell command that lists cpu utilization by process (top). I can even have that command autorefresh, showing me changes in real time. But to do that it takes over the shell. It'd be neat to think about a shell where I could issue a top command, then command displays and exits, giving me a shell prompt again. But I have the option of asking the shell to update the old output every N seconds.
Yes, I could in i3 spawn a new shell and just keep top running in it. And maybe in the long run that's the better interface. But doing that screws up my carefully constructed window layout.
I guess what I'm saying is that we have two interface paradigms: the gui, and the command line. But interfaces like Jupyter and Mathematica show that there are middle grounds between those two extremes, and that middle ground is interesting.
How about instead of something merely like Jupyter you just use precisely Jupyter? I'm sure someone wrote a shell kernel, and if not, use ipython's shell magic.
Personally I use GNUScreen in addition to dwm, but mainly because I use a 15 years-old Celeron PC as a network console, which for some reason puts a one-two seconds tax on window creations.
This setup is quite flexible, but you can get lost easily, in particular if in addition you use ctrl+Z carelessly.
An alternative is Emacs, which will give you shells and windows and splits and somewhat-interactive documents (org-mode) and has some support for images. If you're ready to sacrifice an hour per day to Emacs configuration for the next twelve years, it will do your biddings eventually...
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.
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.
Emacs’ Dired mode lets you interact with the file system this way. Imagine the output of ‘ls -l’ as an editable document — seeing this in action was one of the killer features that made me an Emacs user.
> What's an Emacs? Running that command just seems to reduce my disk quota.
It's an operating system that offer the sanest capabilities for productive work with everything that's primarily textual, or could be made to be primarily textual.
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.
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.
[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.
IMO animation is only useful in certain cases like notifications and smooth scrolling.
If the user is the one initiating an interaction though, there's usually no need to animate anything (opening a menu, for example) because he/she is already expecting something to happen
In my opinion, animations should be like reverb in music. If it's noticeable, you're probably using too much (surf music excepted). A little bit of animation can smooth things out and enhance the experience with helpful cues. Too much makes the application a pain to use.
> he/she is already expecting something to happen
Just as an example, if I were to trigger Mission Control [1] in macOS without animations, it would be pretty jarring. In this case, I control the speed of animation with the speed of my mouse gesture, and it's quick enough not to get in my way, but animated enough so that I have a sense of continuity between my full screen web browser and the view of all windows on that desktop.
In contrast, the default minimize/restore animations in macOS are too long and cutesy for me.
I think animations are pretty useful for some touchscreen UIs, for example if you have a menu that can be swiped away, or to attract attention to things that happen without user interaction. The only issue is a lack of consistency.
Also, animations can hide load times while making things seem fast (see iOS app opening animation)
[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.
> 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.
I do not see how that comparison is unfair. Terminal IRC clients, for example, accomplish the same exact functionality as Slack in a curses UI in a vastly faster way.
Probably because IRC is an outdated protocol with inferior features to Slack and very few good open source options for connecting. For example:
* DCC is still unreliable.
* There is no audio connection option, which is quite popular in 2018.
* Channel history management is ad hoc
* Authentication is done in band, in plain text.
* "secured" channels rely on this bad authentication, and if they don't (perhaps electing to manage it themselves) network flaws can completely steal your channel.
* IRC isn't even particularly open source, many servers and networks have private patches that are not shared publicly.
IRC isn't better than slack. I agree with you that it's confusing why people suggest that it ought to be.
Also, most IRC networks are controlled by entities even more inscrutable than Slack's executive team and board. I can go look up who runs slack, I cannot actually find good details on who runs any given IRC network. I have no idea what I'm dealing with or how they're using my data. I have no legal recourse if I do discover bad behavior, and I'm forced by the ossified protocol to keep using their insecure authentication mechanisms which make abuse trivial.
> ... I cannot actually find good details on who runs any given IRC network. I have no idea what I'm dealing with or how they're using my data. I have no legal recourse if I do discover bad behavior...
Ah, the good old days of the Internet. You make me so nostalgic.
Certainly I use a lot more software products by a lot more diverse sources that all have a lot more accountability to the consumer. This, at least, is a positive trend. One of the few good parts of the commerical software movement is more accountability and higher minimum standards for the consumer. I think that shows in trends in modern computer adoption.
Wouldn't say that IRC has the same exact functionality as Slack. But the Slack mobile app does, and it runs far better than the desktop version (starts up in 3 seconds on a low-powered device instead of 30 on a much faster machine).
I've read this opinion a few times and at one point (before trying mobile slack) I believed it. Is this true for iPhone users maybe?
I've used slack on mobile and I find it worse than the desktop version.
It starts slightly faster (10 seconds vs. almost 20) but navigating through channels is bad (and slower) and threads are completely unusable. It also runs my device hot like nothing else.
The faster startup speed isn't a big victory for me because it's still a factor of 10 away from what I would consider acceptable.
The "best" interface for slack, IMHO, is the web version, provided that you are already using Chrome.
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).
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.
Yeah this was my takeaway as well. Category error - author didn't like electron apps, and therefore wants to dump GUIs in favor of terminals (which would slowly become GUIs with his improvements).
It's obvious from the outside, isn't it. Hindsight is everything.
But the reality is is that Slack is an application made by a real company by real people/developers who all faced real constraints. Go build Slack for yourself, through the same history they have, and lets see what we come out with.
That's not really a fair comparison. Git changes but the version you have and are looking at is fixed. With slack the conversation changes and you can't let the user respond until they're up-to-date because if they did people would be on HN ripping Slack for causing confusion. Not only that but the messages can literally change from one moment to the next. What happens when a user deletes a message?
The equivalent with git would be having each directory be a submodule and someone is rewriting the history out from under you every few seconds.
For technical people it’s easy to assume we understand the problem especially when we see what looks like a questionable design choice but when we do this to applications we don’t have experience with it only hurts us collectively.
Maybe you should read the article and see subsequent videos (e.g., animation jank) where we are in this time domain rather than skipping that part? TBF: the videos didn't play for me without opening them in a different tab. I'm not sure how they accomplished this, since typical embedding tags don't have this problem.
[2]:
> As Nielsen is focused on web apps and applications, this advice is less applicable to UI provided by the OS that you interact with all day in presumably familiar ways.
Multiple interactions were offered in the article that were native apps that had animation. Principles of UX are not exactly the same between local and web, but the principles of how animation guides user attention and context are more universal than you make them out to be.
For example, I love to make fun of the 1pass animation but I think it does serve a valuable purpose: making sure the user has realized the environment is now authenticated as a result of password entry. A unique cue for that is a good idea.
> Note that generally "directing user attention" isn't necessary in a shell...
This is fantastically wrong!
We have a long history of working to make sure that user attention is directed in shells! From guidance on how to do a menu with highlighting (folks have settled on doing the chosen option in a select menu with inverse text and an extra glyph to keep degenerate cases like 1-tuples and 2-tuples from being ambiguous) to ongoing refinements to midnight commander.
Another example in a more command-line domain is silver searcher's bash integration, which makes history search a lot better.
And there is a whole world of UI around log aggregation, search and UI that extends onto the console and has seen rapid evolution over the last 5 years.
[3]:
> Yes, internationalization is still hard. At least for Terminal.app, this is basically a solved problem
It's really not. Lots of tooling breaks.
> he situation with web tech is about the same,
CSS makes this dramatically better on the web side, and we haven't even gotten to support for folks with physical differences that make precise keyboard input or traveling eyesight easy.
The web is WAY more accessible to non-english-speaking people, people with physical differences, and people with issues focusing in the way terminals must demand you do.
> The web is WAY more accessible to non-english-speaking people, people with physical differences, and people with issues focusing in the way terminals must demand you do.
A bunch of people (including Kay and Victor) have talked about this, but accessibility is only one part of the interface. Pieces of software that are productivity related should be easy to get started with and be accessible, but also allow you to become more productive. A lot of tools (like 1Password) focus on the former (accessibility to the lay user) but don't focus on the latter. This isn't some sort of unattainable ideal though: Excel and Powerpoint are great examples of tools that make it easy to just play around with as a beginner, but also to really reward power users.
Poorly, IMO. This became clear to me when I had to talk a blind Windows user through installing Red Hat Linux with the Speakup screen reader in early 2001, using Red Hat's text-mode installer. That was when I realized that Windows had actually become more usable with a screen reader than screen-oriented text-mode UIs in a terminal.
hmm I have a couple of blind friends, and one was an avid redhat user in the late 90s/early 2000s. I didn't reply to the question because I honestly can't remember, but in the late 90s, at least, dealing with Linux was a lot easier than JAWS on windows.
The transition from DOS to Windows in the 90s was difficult for blind users as well as screen reader developers. For some blind techies who were comfortable with DOS, Linux was indeed a more attractive next step. I was heavily involved in the blind Linux community from 1999 through 2001, and helped several newbies get started with Linux.
But that's ancient history. Even as I was deeply involved in the blind Linux community, Windows screen readers were getting good, particularly for everyday tasks like web browsing. Today, there would be no reason for any blind person other than a programmer or sysadmin to use a command-line interface, let alone a screen-oriented terminal interface.
To see why a screen-oriented terminal interface isn't in fact blind-friendly, consider that Red Hat text-mode installer I talked about last time. On screen, you have an approximation of a GUI using line-drawing characters, some ASCII art (for check boxes), and colors to convey where the focus or selection is. Suppose you're in a list of check boxes with buttons below it. What does the screen reader read when you arrow through the list? When you toggle a check box with Space? When you tab to one of the buttons? With the Linux Speakup screen reader in particular, the output wasn't at all intuitive, and one often had to use screen review commands to be sure of what was happening. I wish I still had a copy of a tutorial I recorded in late 2000 where I walked through the installation of Debian with Speakup. (The Debian and Red Hat installers were and are very similar in this regard.)
Contrast that with the Fedora or Ubuntu graphical installer running under GNOME with the Orca screen reader. Like other major GUI platforms, GNOME has an accessibility API. Screen readers and other assistive technologies can get a tree of UI elements, and receive events about those elements. Assuming the application implements its side of the API (and often the UI toolkit takes care of this), a screen reader has easy access to high-level information about the widgets on the screen, what's happening to them, which one has the keyboard focus, etc. So when you arrow through that list of check boxes, the screen reader can say things like, "Web server, not checked". Then when you hit Space, it can just say, "checked". Finally, when you press Tab, it can say something like, "Next, button". It's clearly a much better experience.
I'm happy to answer any questions if anyone is curious.
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.
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.
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.
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.
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.
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.
"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.
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.
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.
> What if animations started at a slightly slower speed, and gradually increased in speed the more you used them?
That's an interesting idea. Or how about if the initiation of a new animated action forced already running animations to rapidly complete? Then if you're doing a bunch of things that trigger animations in rapid sequence, then they would all effectively just be running at higher speeds, in proportion to your specific speed of working.
A good animation should be barely perceptible. If it’s too slow, the application feels sluggish. Too fast, you may not know what happened. It reminds a UX talk from Airbnb, where they have this one guy that focus only on animations.
It’s a good idea to provide the ability to skip the transition with the press of a button. It’s reminds me how one can skip the dialogues in video games.
> If it’s too slow, the application feels sluggish.
> It’s a good idea to provide the ability to skip the transition with the press of a button.
It is not really about animation speed, but more about responsiveness, commonly animation block all inputs because it is easier.
Few days ago there was a discussion on the BEAM/Erlang ecosystem designed so that everything is as responsive as possible. I believe that is really cool.
Classic Mac interface (one of best interfaces of all time, IMHO) actually had special animation to show how a folder opens from a small icon into a larger window with contents. The whole interface was very economical, they just could not afford extra cruft those days, yet they decided that this animation was crucial for understanding.
Agree the Classic Mac animations were really good and didn’t really slow you down.
I’d compare that with the too slow IMHO animation when an app goes full screen on macOS.
Or look at Split View, it was clearly designed for ios touch and then later shoehorned into macOS.
My pet theory is that they left out keyboard ahortcuts for Split View because moving windows about with the keyboard would be too fast and highlight how slow the animations are.
Using a touch pad or mouse is slow anyway so you notice less.
JIRA pages are "animated" by new widgets popping in, then showing loading icons and then finally displaying their final content. You cannot target any single element on the page while it does that because everything moves around every 500 milliseconds or something like that. You just have to sit there and wait until all done. And then it only loaded X of Y items and you have to click to get the rest which again leads to more layout changes. It's as I am watching the same rube goldberg machine over and over again.
Ok, I can see that something is happening. But that renders the whole UI unusable while it does. And it gets tiresome after the first time.
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.
That’s great for someone watching over your sholder eg if you’re doing a product demo but less good if you’re on your own. There it just slows you down when you want to move on to the next task.
I gave reasons why it could help the user themselves. (Here's another: for users learning Vim)
And why should it necessarily make things slower? The animation could be quite fast, and I don't see why such animations would necessarily need to block or hold up future inputs or animations. (I do think, though, that you'd need to actually try it out to see if it works in practice)
I think they'd be great for new users but we'd need to be able to turn them off. No matter how fast and intuitive an animation is it's never going to be as fast as no animation.
You might like kakoune, a vim-like editor which focuses on interactivity: 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.
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.
I'd suggest just switching to movement first, by way of visual mode. "v" turns on visual mode, "as" selects/highlights the sentence, then "d" to delete it or escape to return to normal mode.
We can probably learn a lot about UI animation from video games.
In fighting games there are the concepts of animation priority[0] and cancelling[1], which essentially govern whether the animation for your previous move will block your next move, and whether an animation can be interupted by a new move.
Most good video game UI animates after-the-fact, so you can navigate very quickly and the UI animation lags behind your navigation a little bit. That’s mostly only possible with a controller input because with a mouse the anmiation must complete before the widgets are visible to be clicked on.
YES! Please, Apple, listen. I hate that Safari scrolling on iOS is blocked during the animation of link opening in background tab. Let the icon fly, just let me use the browser meanwhile!
If you're very frequently cmd-tabbing between two apps on different spaces, that delay - any delay - becomes infuriating. I tried a 'one app per space' model a few months ago, because I wanted a one-key shortcut to any app, but the animation delay just made it unworkable.
The problem with the animations are not that they are bad, per se.
They do provide a visual guide to new users of what just occurred. That has value for the new user.
The problem is that too many systems/programs that provide these animations forget that the animation that was useful to one as a new user the first few times, becomes an irritating time sink when it has been watched the ten thousandth time. After the ten thousandth time watching it, many users already know what is going to occur, and just want it to occur and move on. But the system/program provides no "turn off animations" profile setting. So when one gets to the point that one no longer needs the animation to inform of what occurred, one is still forced to sit through its delays. That is the big problem with animations.
Real world example. My Android 7.1 phone came with all the standard android animations turned on at the outset. At some point after having it for a short time, I discovered the animation time adjustment settings inside the hidden developer menu. After I set them all to zero (i.e., do not animate) the phone suddenly felt like it was 1000% faster.
So, in this case Google did include a "turn them off" feature (good). But they hid it inside a normally hidden menu inside the settings app (bad). Why was this hiding of this setting bad? Because most users will never find the developer options menu (because it is hidden) and therefore will never know about the "turn off animations" settings that could make their phone feel significantly faster immediately. So most will be stuck watching animations that make their phone feel slow, even when they already know the outcome and no longer need the assist provided by the animation.
What about GP's suggestion: The more a particular animation occurs, the faster it runs. Remove some milliseconds from it each time, down to some very low limit, so new users get the clarity benefit and experienced users get the speed.
I remember reading about such auto-adjusting UIs long ago, but the idea from then was things like shrinking labels to make room for more advanced features showing up. Not good for consistency, but auto-adjusting animations...
To be fair, with some software we are often not even targeting new users at the expense of power users - we are targeting the audience for our product demos.
If our animations make a punter go wow when they see the product for the first (and only - unless we get to stage 2) time, and they buy it, then it has done its job.
You just gave me an idea for a vim plugin... I guess it's already done? Recent changes could be highlighted with a background color. For example changes from the last 10 edits would have green background. That way if I pressed a key by accident and caused vim to change who knows what, I could spot it.
> What if animations started at a slightly slower speed, and gradually increased in speed the more you used them?
Ubuntu's Unity does this; it keeps track of the number of times you've minimised a window, and as you minimise windows more, it progressively speeds up the animation (maxing out after 100 times).
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.
I love emacs but I just can't get the terminal/shell options it provides to work as smoothly as I can with a proper terminal emulator. What would be perfect is if you could duplicate a terminal buffer for stdout/stderr but have the command line/stdin be in the mini buffer so as to leverage helm or ivy. To me, this would be nirvana.
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.
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.
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.
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
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.
Visidata seems like an example of the kind of UI this author thinks would be better. 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.
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.
378 comments
[ 5.0 ms ] story [ 302 ms ] threadDefinition:
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?
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)
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)
"Bug free" though...
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.
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.
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.
On the other hand, imagine the office where I work, one room, four people, and imagine them talking to their computers instead of typing or mouse clicking.
[0] I have no idea how many accidents are caused by drivers looking at their radio, AC control, whatever. I am conviced the number is greater than zero, but I suspect it is only small fraction of the overall number of traffic accidents. But still.
Every time a programmer adds an animation, a settings option should also be added to "disable animations". Advanced users will love you for it!
You can disable every animation in OS X itself via the command line (defaults write). I put them all in a shell script that I run on new installs. You may be out of luck with 1Password.
I re-check if it's been added with every new macOS release; no luck so far :(
https://i.imgur.com/zg4gZA7.png
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.
Something else: I got myself a tablet a few weeks ago and now find myself disliking the constant scrolling and wishing for (instant) pagination instead.
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.
I do find that if you use the keyboard to switch spaces quickly, the animations become faster too. Unfortunately the app in the other space do not get new keyboard input during the animation.
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.
I'm switching away from macOS to Linux with the i3 window manager for precisely this reason. But all of his criticisms of terminals are spot on: no multimedia, no support for anything other than monospaced fonts, etc. Lord, somebody give me a terminal program that produces laid-out text and can show inline video.
I seem to recall that at least one terminal browser can pull some tricks to insert images into the window in X as well.
The browser you're thinking of is w3m.
Anyway, a separate space with full-screened iterm2 + tmux on macos is my preferred way to work. I can swipe left to check slack, browser and then swipe right to go back to my terminal.
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.
Then the issue becomes how well bash output takes advantage of Jupyter. Research forthcoming.
To me this is off. With a tiling window manager I don't have to "carefully construct" a window layout. That's the window managers job!
An alternative is Emacs, which will give you shells and windows and splits and somewhat-interactive documents (org-mode) and has some support for images. If you're ready to sacrifice an hour per day to Emacs configuration for the next twelve years, it will do your biddings eventually...
Not for everyday use, of course. Network connectivity (and application support) are nonstarters. But that shell interface does look <ahem> inspired.
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.
The C64 did not have any way to directly show or edit system memory, though. That's cool.
The functionality you're describing sounds pretty much like vidir (from moreutils[1]), though.
[1] https://joeyh.name/code/moreutils/
http://ranger.github.io
It's an operating system that offer the sanest capabilities for productive work with everything that's primarily textual, or could be made to be primarily textual.
It exists nowadays as Emacs in the built in eshell.
The buffer is the shell is the buffer.
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/
[2]: They do add value in helping direct user attention. 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.
You start with this, and then make two-and-a-half points (I'll kinda give you animation) that the article doesn't. How is that a summation?
If the user is the one initiating an interaction though, there's usually no need to animate anything (opening a menu, for example) because he/she is already expecting something to happen
Edit: s/animation/transitions/g
> he/she is already expecting something to happen
Just as an example, if I were to trigger Mission Control [1] in macOS without animations, it would be pretty jarring. In this case, I control the speed of animation with the speed of my mouse gesture, and it's quick enough not to get in my way, but animated enough so that I have a sense of continuity between my full screen web browser and the view of all windows on that desktop.
In contrast, the default minimize/restore animations in macOS are too long and cutesy for me.
[1] https://en.wikipedia.org/wiki/Mission_Control_(macOS)
[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.
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.
* DCC is still unreliable.
* There is no audio connection option, which is quite popular in 2018.
* Channel history management is ad hoc
* Authentication is done in band, in plain text.
* "secured" channels rely on this bad authentication, and if they don't (perhaps electing to manage it themselves) network flaws can completely steal your channel.
* IRC isn't even particularly open source, many servers and networks have private patches that are not shared publicly.
IRC isn't better than slack. I agree with you that it's confusing why people suggest that it ought to be.
Also, most IRC networks are controlled by entities even more inscrutable than Slack's executive team and board. I can go look up who runs slack, I cannot actually find good details on who runs any given IRC network. I have no idea what I'm dealing with or how they're using my data. I have no legal recourse if I do discover bad behavior, and I'm forced by the ossified protocol to keep using their insecure authentication mechanisms which make abuse trivial.
Ah, the good old days of the Internet. You make me so nostalgic.
I've used slack on mobile and I find it worse than the desktop version.
It starts slightly faster (10 seconds vs. almost 20) but navigating through channels is bad (and slower) and threads are completely unusable. It also runs my device hot like nothing else.
The faster startup speed isn't a big victory for me because it's still a factor of 10 away from what I would consider acceptable.
The "best" interface for slack, IMHO, is the web version, provided that you are already using Chrome.
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).
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.
However, I agree Slack's got a lot of issues that are just bad implementation choices.
But the reality is is that Slack is an application made by a real company by real people/developers who all faced real constraints. Go build Slack for yourself, through the same history they have, and lets see what we come out with.
The equivalent with git would be having each directory be a submodule and someone is rewriting the history out from under you every few seconds.
For technical people it’s easy to assume we understand the problem especially when we see what looks like a questionable design choice but when we do this to applications we don’t have experience with it only hurts us collectively.
Maybe you should read the article and see subsequent videos (e.g., animation jank) where we are in this time domain rather than skipping that part? TBF: the videos didn't play for me without opening them in a different tab. I'm not sure how they accomplished this, since typical embedding tags don't have this problem.
[2]: > As Nielsen is focused on web apps and applications, this advice is less applicable to UI provided by the OS that you interact with all day in presumably familiar ways.
Multiple interactions were offered in the article that were native apps that had animation. Principles of UX are not exactly the same between local and web, but the principles of how animation guides user attention and context are more universal than you make them out to be.
For example, I love to make fun of the 1pass animation but I think it does serve a valuable purpose: making sure the user has realized the environment is now authenticated as a result of password entry. A unique cue for that is a good idea.
> Note that generally "directing user attention" isn't necessary in a shell...
This is fantastically wrong!
We have a long history of working to make sure that user attention is directed in shells! From guidance on how to do a menu with highlighting (folks have settled on doing the chosen option in a select menu with inverse text and an extra glyph to keep degenerate cases like 1-tuples and 2-tuples from being ambiguous) to ongoing refinements to midnight commander.
Another example in a more command-line domain is silver searcher's bash integration, which makes history search a lot better.
And there is a whole world of UI around log aggregation, search and UI that extends onto the console and has seen rapid evolution over the last 5 years.
[3]:
> Yes, internationalization is still hard. At least for Terminal.app, this is basically a solved problem
It's really not. Lots of tooling breaks.
> he situation with web tech is about the same,
CSS makes this dramatically better on the web side, and we haven't even gotten to support for folks with physical differences that make precise keyboard input or traveling eyesight easy.
The web is WAY more accessible to non-english-speaking people, people with physical differences, and people with issues focusing in the way terminals must demand you do.
A bunch of people (including Kay and Victor) have talked about this, but accessibility is only one part of the interface. Pieces of software that are productivity related should be easy to get started with and be accessible, but also allow you to become more productive. A lot of tools (like 1Password) focus on the former (accessibility to the lay user) but don't focus on the latter. This isn't some sort of unattainable ideal though: Excel and Powerpoint are great examples of tools that make it easy to just play around with as a beginner, but also to really reward power users.
Screen readers sure work better on text than on GUI elements, for one.
But that's ancient history. Even as I was deeply involved in the blind Linux community, Windows screen readers were getting good, particularly for everyday tasks like web browsing. Today, there would be no reason for any blind person other than a programmer or sysadmin to use a command-line interface, let alone a screen-oriented terminal interface.
To see why a screen-oriented terminal interface isn't in fact blind-friendly, consider that Red Hat text-mode installer I talked about last time. On screen, you have an approximation of a GUI using line-drawing characters, some ASCII art (for check boxes), and colors to convey where the focus or selection is. Suppose you're in a list of check boxes with buttons below it. What does the screen reader read when you arrow through the list? When you toggle a check box with Space? When you tab to one of the buttons? With the Linux Speakup screen reader in particular, the output wasn't at all intuitive, and one often had to use screen review commands to be sure of what was happening. I wish I still had a copy of a tutorial I recorded in late 2000 where I walked through the installation of Debian with Speakup. (The Debian and Red Hat installers were and are very similar in this regard.)
Contrast that with the Fedora or Ubuntu graphical installer running under GNOME with the Orca screen reader. Like other major GUI platforms, GNOME has an accessibility API. Screen readers and other assistive technologies can get a tree of UI elements, and receive events about those elements. Assuming the application implements its side of the API (and often the UI toolkit takes care of this), a screen reader has easy access to high-level information about the widgets on the screen, what's happening to them, which one has the keyboard focus, etc. So when you arrow through that list of check boxes, the screen reader can say things like, "Web server, not checked". Then when you hit Space, it can just say, "checked". Finally, when you press Tab, it can say something like, "Next, button". It's clearly a much better experience.
I'm happy to answer any questions if anyone is curious.
Nonononononono! Both. I want both. The biggest problem with terminal interfaces is that very little of the functionality is obvious from the outset.
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.
I don't know if third party apps can read this setting and also comply.
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.
That's an interesting idea. Or how about if the initiation of a new animated action forced already running animations to rapidly complete? Then if you're doing a bunch of things that trigger animations in rapid sequence, then they would all effectively just be running at higher speeds, in proportion to your specific speed of working.
> It’s a good idea to provide the ability to skip the transition with the press of a button.
It is not really about animation speed, but more about responsiveness, commonly animation block all inputs because it is easier.
Few days ago there was a discussion on the BEAM/Erlang ecosystem designed so that everything is as responsive as possible. I believe that is really cool.
I’d compare that with the too slow IMHO animation when an app goes full screen on macOS.
Or look at Split View, it was clearly designed for ios touch and then later shoehorned into macOS.
My pet theory is that they left out keyboard ahortcuts for Split View because moving windows about with the keyboard would be too fast and highlight how slow the animations are.
Using a touch pad or mouse is slow anyway so you notice less.
Ok, I can see that something is happening. But that renders the whole UI unusable while it does. And it gets tiresome after the first time.
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.
And why should it necessarily make things slower? The animation could be quite fast, and I don't see why such animations would necessarily need to block or hold up future inputs or animations. (I do think, though, that you'd need to actually try it out to see if it works in practice)
In practice they are rare, certainly in consumer products. I can think of more products with janky UIs than I can ones with insanely great UIs.
In fighting games there are the concepts of animation priority[0] and cancelling[1], which essentially govern whether the animation for your previous move will block your next move, and whether an animation can be interupted by a new move.
Most good video game UI animates after-the-fact, so you can navigate very quickly and the UI animation lags behind your navigation a little bit. That’s mostly only possible with a controller input because with a mouse the anmiation must complete before the widgets are visible to be clicked on.
[0] https://www.giantbomb.com/animation-priority/3015-7740/
[1] https://www.giantbomb.com/animation-canceling/3015-1568/
They do provide a visual guide to new users of what just occurred. That has value for the new user.
The problem is that too many systems/programs that provide these animations forget that the animation that was useful to one as a new user the first few times, becomes an irritating time sink when it has been watched the ten thousandth time. After the ten thousandth time watching it, many users already know what is going to occur, and just want it to occur and move on. But the system/program provides no "turn off animations" profile setting. So when one gets to the point that one no longer needs the animation to inform of what occurred, one is still forced to sit through its delays. That is the big problem with animations.
Real world example. My Android 7.1 phone came with all the standard android animations turned on at the outset. At some point after having it for a short time, I discovered the animation time adjustment settings inside the hidden developer menu. After I set them all to zero (i.e., do not animate) the phone suddenly felt like it was 1000% faster.
So, in this case Google did include a "turn them off" feature (good). But they hid it inside a normally hidden menu inside the settings app (bad). Why was this hiding of this setting bad? Because most users will never find the developer options menu (because it is hidden) and therefore will never know about the "turn off animations" settings that could make their phone feel significantly faster immediately. So most will be stuck watching animations that make their phone feel slow, even when they already know the outcome and no longer need the assist provided by the animation.
I remember reading about such auto-adjusting UIs long ago, but the idea from then was things like shrinking labels to make room for more advanced features showing up. Not good for consistency, but auto-adjusting animations...
If our animations make a punter go wow when they see the product for the first (and only - unless we get to stage 2) time, and they buy it, then it has done its job.
You could add the animation, or you could remove things from the UI until it’s clearer.
Sometimes a “tool” for getting things done is actually a tool for helping you do bad things longer.
Ubuntu's Unity does this; it keeps track of the number of times you've minimised a window, and as you minimise windows more, it progressively speeds up the animation (maxing out after 100 times).
Source: https://ubuntuforums.org/showthread.php?t=2204321&p=12923084...
The latency they produce is.
If you had a 10ms animation that blocks UI, that would be annoying.
If you had a 10 second animation that doesn't block UI, that would probably be fine.
Even if an animation feels like it blocks UI, that is a problem.
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.
So what he's arguing for is simpler, faster traditional non-terminal apps. Because those are good.
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/
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.
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.
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.