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

The case against conversational interfaces

julian.digital

Post reply on HN
Print view View original

181–190 of 225 posts

Re: The case against conversational interfaces

#181

Post by dcrimp »

Zamaamiro wrote: post #180
fragmede wrote: post #92

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…

I don't see how "but that's the way we used to do things" is an argument in favor of conversational interfaces. The whole point is that we currently have better , more efficient ways of doing those things, so why would we regress to inferior methods?

the inferior methods were slower but more flexible - could handle any and all edge cases. Currently we have a UX that really efficiently realises 80% of cases.

To relate to the article - google flights is the Keyboard and Mouse - covering 80% of cases very quickly. Conversational is better for when you're juggling more contextual info than what can be represented in a price/departure time/flight duration table. For example, "i'm bringing a small child with me and have an appointment the day before and I really hate the rain".

Rushed comment because I'm working, but I hope you get the gist.

Current flight planning UX is overfit on the 80% and will never cater to the 20% because cost/benefit of the development work isn't good

Re: The case against conversational interfaces

#182

Post by furyofantares »

shakna wrote: post #176
furyofantares wrote: post #135

Earlier quoted context omitted.

That's true, but that is the input section of the diagram, not the output section where [specific and exact output] is labeled, so I believe there was legitimate confusion I was responding to. To your point, which I think is separate but related, that IS a case where LLMs are good at producing specific and exact commands. The models + the right prompt are pretty reliable at tool calling by themselves, because you giv…

The tool may not even exist. LLMs are really terrible at admitting where the limits of the training are. They will imagine a tool into being. They will also claim the knowledge is within their realm, when it isn't.

At inference time you can constrain output to a strict json schema that only includes valid tools.

Re: The case against conversational interfaces

#183

Post by littlestymaar »

UncleMeat wrote: post #161
littlestymaar wrote: post #107

Earlier quoted context omitted.

Why couldn't the interface ask you about your preferences? Because instead, what we have right now are clunky web interface that just cram every choice in the small screen in front of you and letting you understand how they are in fact different and sort out yourself how to make things work. Of course a conversational interface is useless if it tries to just do the same thing as a web UI, which is why it failed a dec…

Scrolling through a list of a few options seems much less clunky than being asked via voice about which option I prefer. I can see multiple options at once and compare them easily. But via voice I need to keep all of the options in working memory to compare them. Harder.

The problem with scrolling is that you'll be presented tens of options you don't care about because the options have to be determined in advance and be the same for everyone.

That's why the “advanced search” is almost always hidden somewhere. And that's also why you can never find the filter you need on an e-shopping website.

Re: The case against conversational interfaces

#184

Post by taneq »

grbsh wrote: post #165
fragmede wrote: post #92

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…

It's a great point that this is how we primarily used to interact with businesses and services, but we've moved on. For Gen-Z, e.g., many will refuse to use the product or service if they have to speak to an actual human. Just like we're now not willing to take boat across the ocean for 3 months, but before airplanes this was not uncommon.

Taking a 3 month voyage was still an uncommon thing to do for a person, it’s just that it was the most common type of intercontinental journey due to lack of competition.

Re: The case against conversational interfaces

#185

Post by walterbell »

eviks wrote: post #89
walterbell wrote: post #86

Earlier quoted context omitted.

Blackberry physical keyboard had many shortcuts, https://defkey.com/blackberry-10-classic-shortcuts iPad physical keyboards also have shortcuts.

These are both desktop equivalents using an actual desktop keyboard or a mini variant thereof

Why is Blackberry a desktop equivalent? It preceded iPhone by many years, with unique workflows that varied by model.

Re: The case against conversational interfaces

#186

Post by eviks »

walterbell wrote: post #185
eviks wrote: post #89

Earlier quoted context omitted.

These are both desktop equivalents using an actual desktop keyboard or a mini variant thereof

Why is Blackberry a desktop equivalent? It preceded iPhone by many years, with unique workflows that varied by model.

Because it's literally a physical=desktop keyboard, just smaller in size while almost all current mobile interfaces are touch based?(also, the question wasn't about uniqueness, but productivity levels of a desktop productivity app, think about code editors with extensions, keyboard and mouse gesture customization.

What did they have in their touch interfaces?

Re: The case against conversational interfaces

#187

Post by walterbell »

eviks wrote: post #186
walterbell wrote: post #185

Earlier quoted context omitted.

Why is Blackberry a desktop equivalent? It preceded iPhone by many years, with unique workflows that varied by model.

Because it's literally a physical=desktop keyboard, just smaller in size while almost all current mobile interfaces are touch based?(also, the question wasn't about uniqueness, but productivity levels of a desktop productivity app, think about code editors with extensions, keyboard and mouse gesture customization. What did they have in their touch interfaces?

For most of their existence, Blackberry had no touch interface. One appeared in later versions as they tried to compete with Android and iPhone. One example of a "mobile keyboard" shortcut was long pressing a physical key to launch a specific function.

It might be hard to understand now, but Blackberry power users could be much more productive with email/texting than any phone that exists today. But they were special purpose 2-way radio (initially, pager) devices that lacked the flexibility of modern apps with full internet data access.

Re: The case against conversational interfaces

#188

Post by shakna »

furyofantares wrote: post #182
shakna wrote: post #176

Earlier quoted context omitted.

The tool may not even exist. LLMs are really terrible at admitting where the limits of the training are. They will imagine a tool into being. They will also claim the knowledge is within their realm, when it isn't.

At inference time you can constrain output to a strict json schema that only includes valid tools.

That would only be possible, if you could prevent hallucinations from ever occurring. Which you can't. Even if you supply a strict schema, the model will sometimes act outside of it - and infer the existence of "something similar".

Re: The case against conversational interfaces

#189

Post by lolinder »

throwaway290 wrote: post #159
lolinder wrote: post #155

Earlier quoted context omitted.

> 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 some way. No, that's what a junior engineer will do. The first thing that an experienced and bright senior engineer will do is think over the request and ask clarifying questions in pursuit of a more rigorous specification, then…

I used to think like you. My job is to ask questions etc. But after a couple decades I see if someone doesn't bother to even think about the idea enough to understand it himself beyond a few words he is not worth engaging with in this fashion. He doesn't really know what he wants. Today I ask a clarifying question he says one thing, next week he changes his mind or forgets and the result slowly becomes a mess > The p…

You and I are either talking about very different kinds of specifications or very different kinds of product people. The product people I'm familiar with are completely incapable of creating a specification that is sufficiently detailed to implement without a lot of back and forth. Not because they're not good at what they do, but because what they do does not include defining requirements in sufficient fidelity for an engineer to act on.

Re: The case against conversational interfaces

#190

Post by furyofantares »

shakna wrote: post #188
furyofantares wrote: post #182

Earlier quoted context omitted.

At inference time you can constrain output to a strict json schema that only includes valid tools.

That would only be possible, if you could prevent hallucinations from ever occurring. Which you can't. Even if you supply a strict schema, the model will sometimes act outside of it - and infer the existence of "something similar".

That's not true. You say the model will sometimes act outside of the schema, but models don't act at all, they don't hallucinate by themselves, they don't produce text at all, they do all of this in conjunction with your inference engine.

The model's output is a probability for every token. Constrained output is a feature of the inference engine. With a strict schema the inference engine can ignore every token that doesn't adhere to the schema and select the top token that does adhere to the schema.

Post reply on HN