I wrote a comment under a different post just a few days ago. My comment got _way_ out of hand and wasn't as articulate as I had hoped. But the salient point I made with it is simple and applies equally well to this article. UI is hard. User interfaces seems really simple. Every programmer I know has looked at a UI and thought to themselves "I can code that in an hour!" and then ended up spending weeks, sometimes _mo…
Learning from Terminals to Design the Future of User Interfaces
311–320 of 379 posts
Re: Learning from Terminals to Design the Future of User Interfaces
#312The 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 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.
Re: Learning from Terminals to Design the Future of User Interfaces
#313My only disappointment working with terminal comes from SQL queries (mostly mysql & postgres). The queries results always come scrambled and absolutely unreadable. Anybody ever heard about 'responsive design' for sql results?
edit: typo
Re: Learning from Terminals to Design the Future of User Interfaces
#314Re: Learning from Terminals to Design the Future of User Interfaces
#315I wrote a comment under a different post just a few days ago. My comment got _way_ out of hand and wasn't as articulate as I had hoped. But the salient point I made with it is simple and applies equally well to this article. UI is hard. User interfaces seems really simple. Every programmer I know has looked at a UI and thought to themselves "I can code that in an hour!" and then ended up spending weeks, sometimes _mo…
>UI is hard How many people are actually putting effort into their UIs? How many people do usability tests? I know Microsoft has done them before, but what about Slack? There are a lot of complaints here about their UI. I'm sure not many free software projects do usability tests. You can't just slap things together and hope for the best, you need to have tests, and you need to run the tests again when you make change…
And they added toggle switches to UWP (https://docs.microsoft.com/en-us/windows/uwp/design/controls...) that are usability disasters IMO.
When such switch used alone you cannot tell in what state it is - you need to remember that "on the right - is on" (yet what about RTL environment?).
While there is no such problem with old plain checkboxes.
Re: Learning from Terminals to Design the Future of User Interfaces
#316Earlier quoted context omitted.
What does "accessible" mean? Screen readers sure work better on text than on GUI elements, for one.
How do screen readers work with curses interfaces? Genuinely curious.
Re: Learning from Terminals to Design the Future of User Interfaces
#317Earlier quoted context omitted.
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 di…
> screws up my carefully constructed window layout. 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!
Re: Learning from Terminals to Design the Future of User Interfaces
#318I'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.
looks like you are ready for templeOS
Not for everyday use, of course. Network connectivity (and application support) are nonstarters. But that shell interface does look inspired.
Re: Learning from Terminals to Design the Future of User Interfaces
#319Earlier quoted context omitted.
Most successful interactions with Siri/Alexa/Cortana/GoogleNow also fall under the same paradigm. They have some finite number of templates/recipes that they can respond to, and just enough "NLP" to attempt a fuzzy matching between what you ask for, and the triggers to the recipes. The key point is that communication is fundamentally serial, in both voice and basic text consoles, whereas GUIs allow parallel communica…
Maybe because, the cli mode means, you need to remember the commands? In GUI mode, though inefficient, you know exactly where to access help and a few basic params (like dropdown menu on top, usually save under file, cut and copy under edit) that smoothens the learning curve. They have some solid ground from which to start exploring. Whereas under console mode, there is no unifying paradigm. So each tool has a differ…
It's "j" for next conversation, "k" for previous - comes from hjkl, vim (and older [0]) keyboard navigation. Then "n" for next and "p" for previous, for emails within the same conversation.
Thing is, just like vim, these are supposed to become short-circuited so when in the right context, you don't think of the letters anymore. It's not "that key is j, which is up", it becomes "that key is up". It's the same newbie discovery vs power-user productivity problem described in the post.
[0] https://vi.stackexchange.com/questions/9313/why-does-vim-use...
Re: Learning from Terminals to Design the Future of User Interfaces
#320Earlier quoted context omitted.
Back when I was a kid this sounded romantic. Now I just know it means that folks spy on me for fun.
As opposed to the non-anonymous internet?