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

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

#321

Post by b0rsuk » Sat, Aug 04, 2018, 4:47 PM UTC

chris_mc wrote: post #117

sxates wrote: post #113

Earlier quoted context omitted.

Problem is it doesn't scale well for people. Imagine if everything you did in slack was via CLI - there are dozens, hundreds of commands to learn? Imagine if every app had dozens of commands you had to learn and memorize. Sure you could do it and be blazing fast, but that's a really steep learning curve a lot of users wouldn't adopt.

Look at the VSCODE command bar. You start to type what you want to do, and the search function is incredible, helping you find any command you want. Why couldn't something simple like that be applied to the command line interface for a shell maybe? Heck, with `zsh` I have a lot of autocomplete commands available, including several sub-commands and sub-sub commands. For example, when I type `git remote `, a listing sh…

You achieve this by putting the following 4 lines in your $HOME/.inputrc file:

  "\e[A": history-search-backward
  "\e[B": history-search-forward
  set show-all-if-ambiguous on
  set completion-ignore-case on

From now on, when you type part of a command, uparrow and downarrow provide you with incremental search based on your command history.

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

#322

Post by b0rsuk » Sat, Aug 04, 2018, 4:53 PM UTC

ssorallen wrote: post #228

0x445442 wrote: post #179

Earlier quoted context omitted.

Actually natural language scales quite well. Aza Raskin and his father Jeff did a lot of good work in this area. The discoverability of commands in a system like Emacs is much more powerful than a menu based system. In fact, I bet most people navigate the web now days by typing part of the URL in the omni bar and letting the browser fuzzy match versus mainting large bookmark lists.

I’m accustomed to typing “s” for StackOverflow, “g” for GitHub, “gm” for Gmail, and probably several others I don’t even realize. This sort of “smart” / reachable interface seems like an improvement over having to type entire words over and over. Is there a terminal with similar ability?

Actually I got this by turning OFF fuzzy search. I don't use bookmarks anymore. I just type gi or gm, or st and press enter.

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

#323

Post by chriswarbo » Sat, Aug 04, 2018, 4:53 PM UTC

sharmi wrote: post #212

ssivark wrote: post #119

Earlier 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…

This is related to DWIM (Do What I Mean) https://en.wikipedia.org/wiki/DWIM

It seems like DWIM features gained popularity from the 60s to the 80s, but more recent systems avoid it in favour of explicit (although sometimes cryptic) error messages ("weak types", like `==` in PHP and Javascript, are a remaining example of DWIM).

This might be connected to the rise of GUIs: more "general user" software became GUI driven, or menu driven, rather than using a free-form input language. That reduced the need for DWIM as a way to help new/casual users. It also meant that the CLI software that remained was generally more powerful, and therefore more dangerous (e.g. bash rather than zork), in which case there's a higher chance for a DWIM system to cause problems.

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

#324

Post by b0rsuk » Sat, Aug 04, 2018, 5:00 PM UTC

angleofrepose wrote: post #191

mikeryan wrote: post #164

Earlier quoted context omitted.

There’s an inherent dichotomy in UI in that the most “efficient” interfaces generally have the steepest learning curve. You can be really efficient in a terminal or VIM. But figuring those out take a lot of work. When we design interfaces we try to make them have a short learning curve but expose greater ability as you use them but it’s still hard.

Completely agree, but we can also figure out how to make it easier. Take a look at http://kakoune.org/why-kakoune/why-kakoune.html#_improving_o... (this is the section that introduces the flip on vim's command structure, but is otherwise a great article to read top to bottom). There are a lot of ways vim is right or not right, but this lowers the barrier to entry in a profound way. We can keep advancing like this, an…

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

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

#325

Post by erikpukinskis » Sat, Aug 04, 2018, 5:05 PM UTC

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

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

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

#326

Post by erikpukinskis » Sat, Aug 04, 2018, 5:10 PM UTC

ken wrote: post #28

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…

If your UI is complexly enough that it needs animations to show what’s happening, that’s a red flag.

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.

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

#327

Post by b0rsuk » Sat, Aug 04, 2018, 5:12 PM UTC

huntie wrote: post #295

fpgaminer wrote: post #87

I wrote a comment under a different post just a few days ago. My comment got _way_ out of hand and wasn't as articulate as I had hoped. But the salient point I made with it is simple and applies equally well to this article. UI is hard. User interfaces seems really simple. Every programmer I know has looked at a UI and thought to themselves "I can code that in an hour!" and then ended up spending weeks, sometimes _mo…

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

I designed a very convenient interface for my otherwise extremely simple Chess program.

In most chess games, keyboard interface works like this: one axis has labels 1, 2, 3, 4, 5, 6, 7, 8; the other has a, b, c, d, e, f, g, h. Then you movie pieces by inputing stuff like b4 d5. This is AWFUL. You have to look at the border of of the chessboard to see which row and column your chess piece is in. It wasn't designed for humans to play, it was for keeping records of matches and tournaments.

My interface works differently: each of your pieces having valid moves is assigned a key on keyboard. For example rooks could be labeled 1-8, others a-h. You select a piece to move simply by inputing its symbol. When that happens, spaces reachable with legal moves become labeled with symbols... You see where that goes. You look at a piece you want to move, read its symbol, then read the symbol of the place you want to move to. In each case you look at pieces or spaces that interest you, not at X and Y axis.

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

#328

Post by [deleted] » Sat, Aug 04, 2018, 5:18 PM UTC

sharmi wrote: post #212

ssivark wrote: post #119

Earlier 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…

[deleted]

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

#329

Post by jstarfish » Sat, Aug 04, 2018, 5:49 PM UTC

0x445442 wrote: post #305

jstarfish wrote: post #205

Earlier quoted context omitted.

Really? It seems that with the advent of Bootstrap and responsive design, website UIs are more consistent and generic than ever before. Every corporate landing page is a jumbotron/full-width image, followed by three columns of bullshit, followed by a few rows of random glyphicons and more vague nonsense to cross the minimum text SEO threshold, and a footer. The early internet was a much wilder place. Frames or no fra…

I'd agree with you when you're talking about websites that are, for the most part static and just conveying information. But when you're talking about actual web applications designed to get work done I think things are wildly disjointed. If I were to show you the web apps I interact with regularly, both personally and professionally, you'd see what I'm talking about.

Fair enough. I had not considered apps :)

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

#330

Post by samlehman617 » Sat, Aug 04, 2018, 5:53 PM UTC

ObsoleteNerd wrote: post #155

mbreese wrote: post #122

Earlier quoted context omitted.

I think another example of this would be using something like Adobe Photoshop or Illustrator. Switching between tools can be accomplished by clicking an icon, a drop down, or some other GUI element. However, once you get to a certain level of skill, it becomes faster to just use the keyboard shortcuts. For a novice, it's more forgiving. But for the expert, it's possible to be very efficient. It's also possible to go…

I still use cheat sheets, but I design my own into wallpapers that fit my desktop perfectly, than have them rotating randomly every hour. Keeps my refreshed on shortcuts in my popularly used programs, and adding a new one to the rotation is a great way to learn all the shortcuts for a new program. It's not like I ever leave my desktop visible for a pretty wallpaper to matter. My nice ones are on my lock screen.

Would you mind sharing some?