Live data from Hacker News

The case against conversational interfaces

julian.digital

121–130 of 225 posts

Re: The case against conversational interfaces

#121

Star Trek continues to be prescient. It not only introduced the conversational interface to the masses, it also nailed its proper uses in ways we're still (re)discovering now. If you pay attention to how the voice interface is used in Star Trek (TNG and upwards), it's basically exactly what the article is saying - it complements manual inputs and works as a secondary channel. Nobody is trying to manually navigate the…

I remember Picard barking out commands to make the ship do preprogrammed evasion or fight maneuvers too. This seems like another good use.

Yeah, this and I think even weapons control, happened on the show. But the scenario for these cases is when the bridge is understaffed for episode-specific plot reasons, and the protagonist has to simultaneously operate systems usually handled by distinct stations. That's when you get an officer e.g. piloting the shuttle/runabout while barking out commands to manage power flow, or voice-ordering evasions while manually operating weapons, etc.

(Also worth noting is that "pre-programmed evasion patterns" are used in normal circumstances, too. "Evasive maneuver JohnDoe Alpha Three" works just as well when spoken to the helm officer as to a computer. I still don't know whether such preprogrammed maneuvers make sense in real-life setting, though.)

Re: The case against conversational interfaces

#122
post #93

This clearly elucidated a number of things I've tried to explain to people who are so excited about "conversations" with computers. The example I've used (with varying levels of effectiveness) was to get someone to think about driving their car by only talking to it. Not a self driving car that does the driving for you, but telling it things like: turn, accelerate, stop, slow down, speed up, put on the blinker, turn…

This rules out conversational UI for some tasks and applications but there are many where it will be useful and many where a hybrid would be best. Even in a car, being able to control the windscreen wipers, radio, ask how much fuel is left are all tasks it would be useful to do conversationally. There are some apps (im thinking of jira as an example) where i'd like to do 90% of the usage conversationally.

> Even in a car, being able to control the windscreen wipers, radio, ask how much fuel is left are all tasks it would be useful to do conversationally.

are you REALLY sure you want that?

how much fuel there is is a quick glance into the dash, and you can control precisely the radio volume without even looking.

'turn up the volume', 'turn down the volume a little bit', 'a bit more',...

and then a radio ad going 'get yourself a 3 pack of the new magic wipers...' and car wipers going off.

id hate conversational ui on my car.

Re: The case against conversational interfaces

#123
post #102

Earlier quoted context omitted.

[imprecise thinking] v In many cases, you don't want or need that. In some, you do. Use right tool for the job, etc.

I don't think they give a specific and exact output, considering how nondeterminism plays a role in most models.

The diagram you're replying to agrees with this.

Re: The case against conversational interfaces

#124

Earlier quoted context omitted.

And 10x worse than that is booking a flight: I found one that fits your budget, but it leaves at midnight, or requires an extra stop, or is on an airline for which you don't collect frequent flyer miles, or arrives it at a secondary airport in the same city, or it only has a middle seat available. How many of these inconveniences will you put up with? Any of them, all of them? What price difference makes it worthwhil…

But that is how we used to buy a plane ticket. Long before flights.google.com's price table, you'd call a human up and tell them you'd like to go on holiday. They'd ask you where and when and how much you could afford, and then after a while with the old system (SABRE) clicking and clacking they'd find you a good deal. After a few flights with that travel agent, they'd hey to know you and wouldn't have to ask so many…

But the booking agent used to understand what you were saying, and it'd be very easy to work out miscommunications. AI chatbots just send you in circles endlessly and if you get "stuck" there is no recourse.

Re: The case against conversational interfaces

#125
post #102

Earlier quoted context omitted.

I don't think they give a specific and exact output, considering how nondeterminism plays a role in most models.

The diagram you're replying to agrees with this.

Does it? The way I'm reading it, the first step is LLM turning human imprecise thinking into specific and exact commands

Re: The case against conversational interfaces

#126

Earlier quoted context omitted.

But that is how we used to buy a plane ticket. Long before flights.google.com's price table, you'd call a human up and tell them you'd like to go on holiday. They'd ask you where and when and how much you could afford, and then after a while with the old system (SABRE) clicking and clacking they'd find you a good deal. After a few flights with that travel agent, they'd hey to know you and wouldn't have to ask so many…

And how many people book flights that way today?

Many people today are booking flights for others, be it families, business leaders, or traditional travel agents. They’re communicating preferences and asking about preferred travel times, budget, seat selection, and more. When you book for and with someone else, these preferences get learned and you no longer have to ask if they prefer an aisle seat—you just pick it.

The booking experience today is granular to help you find a suitable flight to meet all the preferences you’re compiling into an optimal scenario. The experience of AI booking in the future will likely be similar: find that optimal scenario for you once you’re able to articulate your preferences and remember them over time.

Re: The case against conversational interfaces

#127

This clearly elucidated a number of things I've tried to explain to people who are so excited about "conversations" with computers. The example I've used (with varying levels of effectiveness) was to get someone to think about driving their car by only talking to it. Not a self driving car that does the driving for you, but telling it things like: turn, accelerate, stop, slow down, speed up, put on the blinker, turn…

Yeah, it comes and goes in games for a reason. If it's not already some sort of social game, then the time to speak an answer is always slower than 3 button presses to select a pre-canned answer. Navigating a menu with Kinect voice commands will often be slower than a decent interface a user clicks through.

Voice interface only prevails in situations with hundreds of choices, and even then it's probably easier to use voice to filter down choices rather than select. But very few games have such scale to worry about (certainly no AAA game as of now).

Re: The case against conversational interfaces

#128

Earlier quoted context omitted.

> If you have a team of senior, experienced and bright engineers, you can with a few words point out a desire and, trust them to ask for information when there is relevant ambiguity, and expect a good outcome It's such a fallacy. First thing an experienced and bright engineer will tell you is to leave the premises with your "few words about a desire" and not return without actual specs and requirements formalized in…

I do understand that in bad cases it can be very frustrating as an engineer to chase vague statements only to be told later 'nah, that was not what I meant'. This is especially true when the gap in both directions is very large or there is incompetence and/or even adversarial stances between the parties. Language and communication only work if both parties are willing to understand. Unfortunately if either is the cas…

> What I've also seen more than once is years of formalized specs and requirements work while nothing ever gets produced, and the project is aborted before even the first line of code hit test.

It just shows that no one really understood what they wanted. It is crazy to expect somebody to understand something better than you and it is hilarious to want a conversational UI to understand something better than you.

Re: The case against conversational interfaces

#129

Earlier quoted context omitted.

> If you have a team of senior, experienced and bright engineers, you can with a few words point out a desire and, trust them to ask for information when there is relevant ambiguity, and expect a good outcome It's such a fallacy. First thing an experienced and bright engineer will tell you is to leave the premises with your "few words about a desire" and not return without actual specs and requirements formalized in…

I think you work in different domains. Expecting a good outcome is different from expecting to get exactly what you intended. Formal specifications are useful in some lines of work and for some projects, less so for others. Wicked problems would be one example where formal specs are impossible by definition.

> Formal specifications are useful in some lines of work and for some projects, less so for others

There is always formal specification. Code is final formal specification in the end. But converting vague vibes from natural language into a somewhat formalized description is key ability you need for any really new non trivial project idea. Another human can't do it for you, conversational UI can't do it for you...

Re: The case against conversational interfaces

#130

Earlier quoted context omitted.

> If you have a team of senior, experienced and bright engineers, you can with a few words point out a desire and, trust them to ask for information when there is relevant ambiguity, and expect a good outcome It's such a fallacy. First thing an experienced and bright engineer will tell you is to leave the premises with your "few words about a desire" and not return without actual specs and requirements formalized in…

I think you work in different domains. Expecting a good outcome is different from expecting to get exactly what you intended. Formal specifications are useful in some lines of work and for some projects, less so for others. Wicked problems would be one example where formal specs are impossible by definition.

>Anyway, the disabled are pretty much always allowed to be collateral damage by society, so this will just be senseless pain.

For games, you don't really need nor desire formal specs. But it also can really show how sometimes a director has a low tolerance for interpretation despite their communication being very loose. This leads to situations where it feels like the director is shifting designs on a dome, which is a lose-lose situation for everyone involved.

If nothing else, formal specification is for CYA. You get what you ask for, and any deviation should go in the next task order or have been addressed beforehand.

Post reply on HN