6 ms·

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 ren

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.

rconti 8y ago
What does "accessible" mean? Screen readers sure work better on text than on GUI elements, for one.
- madeofpalk 8y ago
  How do screen readers work with curses interfaces? Genuinely curious.
  - KirinDave 8y ago
    Generally you fool them into spitting raw text and carefully crafted menu summaries into a socket that speaks text at high speed.
  - mwcampbell 8y ago
    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.
    - rconti 8y ago
      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.
      - mwcampbell 8y ago
        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.
calcifer 8y ago
> So to sum up 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?
- juancampa 8y ago
  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 Edit: s/animation/transitions/g
  - cnasc 8y ago
    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. [1] https://en.wikipedia.org/wiki/Mission_Control_(macOS) https://en.wikipedia.org/wiki/Mission_Control_(macOS)
  - xnzakg 8y ago
    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)
- KirinDave 8y ago
  I obviously disagree with your interpretation of the article. I think the author made these points implicit their demonstration.
nomdehn_180714 8y ago
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.
- KirinDave 8y ago
  [1]: 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.

rconti 8y ago

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

madeofpalk 8y ago
How do screen readers work with curses interfaces? Genuinely curious.
- KirinDave 8y ago
  Generally you fool them into spitting raw text and carefully crafted menu summaries into a socket that speaks text at high speed.
- mwcampbell 8y ago
  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.
  - rconti 8y ago
    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.
    - mwcampbell 8y ago
      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.

calcifer 8y ago

> So to sum up 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?

juancampa 8y ago
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 Edit: s/animation/transitions/g
- cnasc 8y ago
  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. [1] https://en.wikipedia.org/wiki/Mission_Control_(macOS) https://en.wikipedia.org/wiki/Mission_Control_(macOS)
- xnzakg 8y ago
  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)
KirinDave 8y ago
I obviously disagree with your interpretation of the article. I think the author made these points implicit their demonstration.

nomdehn_180714 8y ago

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.

KirinDave 8y ago
[1]: 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.