Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learning from Terminals to Design the Future of User Interfaces

brandur.org

Post reply on HN
Print view View original

351–360 of 379 posts

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

#351

Post by marcus_holmes »

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…

also there's no method of discovering the commands in a CLI.

A GUI shows you what you can do, by having all the buttons and widgets displayed.

People google for "how to close Vim". I know I did when I started climbing that learning cliff. GUI's usually don't suffer this problem (except Google's UI's, which for some reason are bizarrely complex and hard to navigate).

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

#352

Post by projektir »

b0rsuk wrote: post #334
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.

I think this is nowhere more evident than in the world of games. In my opinion RTS games stagnated and died because they failed to innovate in interface department, outside of a few like Total Annihilation / Supreme Commander. The classic Dune2/Warcraft interface only works for selecting single units and squares. So when any bigger engagement happens, it's just people throwing blobs at one another and juggling group…

Hmm. To me, large-army games and small-army games are just very different games, and I have little interest in large-army games. I don't see Total Annihilation ever replacing StarCraft for me, for instance. If I could only control the game via keys, I'd be very uninterested as that'd be a very different kind of game. Most of these games went turn based for a reason.

I specifically like AoE II for the feeling of grabbing a pack of Mangudai and watching them quickly run somewhere and fire arrows. It's not realistic, but it's understandable and pleasing, in a way that a super serious military simulator isn't.

I think RTS, like many other genres, mostly "died" due to stagnation around clones, which I think has more to do with the industry at large that is not innovating all that much anymore, and RTS is often not the genre of choice for a small indie developer, either.

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

#353

Post by projektir »

digi_owl wrote: post #141
sxates wrote: post #114

Earlier quoted context omitted.

The difficulty is not just in coding the UI, but crafting one that's easily and intuitively understood by users. We haven't yet established a universal design pattern for GUI's yet, to the parents point, just a bunch of conventions that are often tossed in favor of something new. A 'solved' UI example would be of a car (not the radio, but the operation of the vehicle). Learn to drive one car, and you can pretty much…

IMO, intuitiveness is overrated. As one snarky joke goes: only the nipple is intuitive, everything else is learned.

Since when does intuition exclude learned information? It's very much relevant to, say, what interfaces people have used before.

You might be thinking of instinct.

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

#354

Post by majewsky »

vezycash wrote: post #309
pbhjpbhj wrote: post #268

Earlier quoted context omitted.

To stop the current job!? ;oP

Press delete accidentally or intentionally and you should see a notification about the delete. If you want to undo, then Ctr + Z. At least that's the way computers have worked for eons. Ctr + Z is the reason I prefer computers to typewriters. Software without the ability to undo or reset actions are devolving the user experience to typewriter age.

> If you want to undo, then Ctr + Z. At least that's the way computers have worked for eons.

You're missing the joke. Way before Ctrl-Z started to mean Undo in GUI programs, it was (and still is) assigned to "stop current job" in terminals.

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

#355

Post by jackthetab »

Galaxeblaffer wrote: post #274
skykooler wrote: post #220

Earlier quoted context omitted.

It would be interesting to make an Alexa-style device, which instead of natural language used a set of composable voice commands, like Bash and the unix utilities but pronouncable.

Google home already kind of have this, don't know about Alexa. I'm amazed at how simple commands can be when you learn the simplest form of a command. And you could of course go nuts with ifttt and create your own syntax

Details wrt the first paragraph, please.

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

#356

Post by petepete »

chin123 wrote: post #248
jamesrcole wrote: post #216

Earlier quoted context omitted.

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

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.

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

#357

Post by ProxCoques »

skykooler wrote: post #220
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…

It would be interesting to make an Alexa-style device, which instead of natural language used a set of composable voice commands, like Bash and the unix utilities but pronouncable.

Yes. At the moment, voice interfaces are a novelty and it makes sense that we're assuming they will use the language we use. But I wonder if that will continue?

Given one of the problems with voice interfaces is false triggering between humans and machines and humans and humans ("You want to know what?" "No, I was just talking to Alexa!" "Sorry, I can't find any results for that.") I wonder if in the far future we will have worked out a "machine language" partly for this reason.

It might be a bit like radio procedure words mixed with "machine syntax". So rather than "Alexa, give me a list of the top ten companies by market capitalisation", or "Alexa, who was the director of the Poseidon Adventure?" you'd say "Chip list market capitalisation companies ten" or "Chip, director Poseidon Adventure", where "Chip" is the universal signal for invoking voice commands (followed optionally by the name of the device you're addressing) and the grammar of the query is ordered from general to specific. This would minimise linguistic ambiguities and allows accurate but imprecise answers if necessary (eg if the machine can't order by market cap). It might also be sufficiently different for humans in earshot to screen it out. There might be specialised words too, similar the Bash and the unix utilities you mentio (eg for recalling queries and modifying them, stealth mode invocation, even piping perhaps).

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

#358

Post by beachy »

pwg wrote: post #312
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…

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

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.

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

#359

Post by ProxCoques »

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

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

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

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

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

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

#360

Post by vezycash »

majewsky wrote: post #354
vezycash wrote: post #309

Earlier quoted context omitted.

Press delete accidentally or intentionally and you should see a notification about the delete. If you want to undo, then Ctr + Z. At least that's the way computers have worked for eons. Ctr + Z is the reason I prefer computers to typewriters. Software without the ability to undo or reset actions are devolving the user experience to typewriter age.

> If you want to undo, then Ctr + Z. At least that's the way computers have worked for eons. You're missing the joke. Way before Ctrl-Z started to mean Undo in GUI programs, it was (and still is) assigned to "stop current job" in terminals.

Thanks. Learned something new.
Post reply on HN