4 ms·

I feel the same way. I actually like dealing with the details and making sure I get the absolute best experience. Wifi? Best price/date compromise? Probability

I feel the same way. I actually like dealing with the details and making sure I get the absolute best experience. Wifi? Best price/date compromise? Probability of on-time departures? Opportunities on connecting flights? In-flight alcohol? In-flight chargers? Free meals? Expected leg room? Luggage price? Carry-on limits? That's a 5 minute conversation right there... 20+ minutes if I want to explore results. I'd call a human if I wanted a conversation. Voice UX is about commands. Fulfill my command if you can give me good results. If you can't, send me to a website pre-filled with data from the command and let me do the rest myself. Anything in between is just a reinvented phone tree.

tedmiston 10y ago
> If you can't, send me to a website pre-filled with data from the command and let me do the rest myself. Anything in between is just a reinvented phone tree. That's a really neat idea. Unfortunately it seems to be completely unscalable. For instance, booking on an airline site usually involves navigating and fill a complex multi-page form. Some of the fields are privacy conscious information. The form layout and process varies from airline to airline. Those are just two of the biggest concerns.
- losteric 10y ago
  How is it unscalable? "Book me a flight to London on Monday" goes through a speech to text recognition service, then NLP translates that text into service queries. At some point in that chain you're querying a flight aggregation service (ie Kayak). Just slap together an SPA that calls the same aggregation service, and prefill it with the recognized query. Amazon's Alexa app is already pretty close, although their queries are less sophisticated (3p integrations just get the literal speech 2 text translation, no deep query transformations/context at play). Google Now is even closer... ask it to "Set an alarm tomorrow morning" and it will give you a partially filed out form with the option to finish it vocally or visually.
  - tedmiston 10y ago
    There are several reasons. 1. The general pattern of an aggregation service only covering the lowest common denominator features among what it aggregates. 2. I'm not sure of Kayak's terms specifically but accessing via third party aggregator API vs. direct API can affect who gets credit for the referral (i.e., $$$). 3. At the aggregator level, _someone_ has to write the glue code for all of the services. See IFTTT for an example of this. This is a good foreshadow of the problems here by analogy to IFTTT [1]. 4. "Just slap together an SPA that calls the same aggregation service, and prefill it with the recognized query." Who's going to build the SPA? For each service vertical? For each company? [1]: https://blog.pinboard.in/2016/03/my_heroic_and_lazy_stand_against_ifttt/ https://blog.pinboard.in/2016/03/my_heroic_and_lazy_stand_ag...
    - losteric 10y ago
      1. That is just convention, services are free to filter on features that are present on a small subset of the data. 2. I don't know how Kayak specifically works, they're just a general example of a customer-facing website that also vends an API that could be integrated with Voice UX. 3 / 4. Everyone has a different approach here and I'm not sure how Viv's would work... but Alexa's ownership model is app-based. 3rd parties build services that process the user's command however they want. They build the backend service, the Alexa voice integration endpoint, and (optionally) a companion website. Amazon owns the marketplace and physical interface. In this model, Uber owns the Uber integration, Lyft owns the Lyft integration, and whoever manages to search both Uber and Lyft would own that meta-service integration.

tedmiston 10y ago

> If you can't, send me to a website pre-filled with data from the command and let me do the rest myself. Anything in between is just a reinvented phone tree. That's a really neat idea. Unfortunately it seems to be completely unscalable. For instance, booking on an airline site usually involves navigating and fill a complex multi-page form. Some of the fields are privacy conscious information. The form layout and process varies from airline to airline. Those are just two of the biggest concerns.

losteric 10y ago
How is it unscalable? "Book me a flight to London on Monday" goes through a speech to text recognition service, then NLP translates that text into service queries. At some point in that chain you're querying a flight aggregation service (ie Kayak). Just slap together an SPA that calls the same aggregation service, and prefill it with the recognized query. Amazon's Alexa app is already pretty close, although their queries are less sophisticated (3p integrations just get the literal speech 2 text translation, no deep query transformations/context at play). Google Now is even closer... ask it to "Set an alarm tomorrow morning" and it will give you a partially filed out form with the option to finish it vocally or visually.
- tedmiston 10y ago
  There are several reasons. 1. The general pattern of an aggregation service only covering the lowest common denominator features among what it aggregates. 2. I'm not sure of Kayak's terms specifically but accessing via third party aggregator API vs. direct API can affect who gets credit for the referral (i.e., $$$). 3. At the aggregator level, _someone_ has to write the glue code for all of the services. See IFTTT for an example of this. This is a good foreshadow of the problems here by analogy to IFTTT [1]. 4. "Just slap together an SPA that calls the same aggregation service, and prefill it with the recognized query." Who's going to build the SPA? For each service vertical? For each company? [1]: https://blog.pinboard.in/2016/03/my_heroic_and_lazy_stand_against_ifttt/ https://blog.pinboard.in/2016/03/my_heroic_and_lazy_stand_ag...
  - losteric 10y ago
    1. That is just convention, services are free to filter on features that are present on a small subset of the data. 2. I don't know how Kayak specifically works, they're just a general example of a customer-facing website that also vends an API that could be integrated with Voice UX. 3 / 4. Everyone has a different approach here and I'm not sure how Viv's would work... but Alexa's ownership model is app-based. 3rd parties build services that process the user's command however they want. They build the backend service, the Alexa voice integration endpoint, and (optionally) a companion website. Amazon owns the marketplace and physical interface. In this model, Uber owns the Uber integration, Lyft owns the Lyft integration, and whoever manages to search both Uber and Lyft would own that meta-service integration.