search

OneBusAway / onebusaway-alexa

An Java-based app to communicate with Amazon Alexa for devices such as the Amazon Echo
Other
52 stars 18 forks source link

Supported commands/questions from user for v1.0 #3

Closed barbeau closed 8 years ago

barbeau commented 8 years ago

Here are commands/questions that we should support for v1.0:

To get arrival times, after the initial setup is complete (see #1):

General (after the initial setup to set your city/region/stop):

philipmw commented 8 years ago

I'd like to support multiple route numbers in requests, because sometimes more than one bus can take me to my destination. If we know the customer's stop #, we should be able to support any route number at that stop.

For example,

What do you think?

I'd love also to support several bus stops (for example, oftentimes there are multiple stops within 0.2 miles, and the customer alternates between them depending on the destination), but we can save this for later.

barbeau commented 8 years ago

I'd like to support multiple route numbers in requests, because sometimes more than one bus can take me to my destination.

I think this would be a great feature, but I'm still a bit unclear on how well Alexa recognizes an open set of alphanumeric strings, and how we could potentially fuzzy-match this to route names. This is why I've been sticking to city names and numbers so far as input. Based on what I've read so far, it seems we would have to provide training examples for all route names for all regions at build time, which doesn't seem to be feasible. If you'd like to give this a shot and see how well it works, I'd certainly welcome adding this feature if it works.

I'd love also to support several bus stops

Agreed - let's table this for v1.1. I just opened https://github.com/OneBusAway/onebusaway-alexa/issues/6 to track v1.1 commands.

greenwoodcm commented 8 years ago

To simplify the requirements for v1.0, what about just configuring a home stop and nothing else? when you ask alexa to give you bus times, they just list all upcoming routes at the home stop. In the fullness of time I definitely see filtering by route as a helpful option, but this could be a good first step, the user just has to listen for the routes they care about.

barbeau commented 8 years ago

@greenwoodcm Agreed, for v1.0 I want to stick to just setting a single home stop.

philipmw commented 8 years ago

Can you explain a bit further, to someone who's relatively new to OneBusAway, why the user would care about what regions are supported? In particular, you're proposing that we first get the city. Once they've given us their city, would they ever ask to enumerate regions? As I see it, we either support their city or we don't.

barbeau commented 8 years ago

Sure, here's my two cents - I'm open to other thoughts on this too.

First off, it seems like good form to have some kind of user discovery for the regions list - this could be discoverable before setting the city as well. Otherwise it seems like a bit of a guessing game, especially if its the user's first experience with OBA. We have a 100 mile limiter when discovering regions (i.e., if the detected location is more than 100 miles from a supported region, we just ask for the city again). I would assume there are possible errors in mapping user responses to actual cities with the City slot (not to mention that this slot only supports cities larger than a certain population size), as well as geocoding errors in Google Maps going from a city to a lat/long. As a result it's possible the user could be saying a city that's actually near a supported region, but we're not understanding that for some reason. We've hit this issue with the mobile apps (although likely more geolocation errors there given GPS, network issues, etc.), and have worked to err more on the side of over-exposing current region / supported region info to users. If we give them a list of supported regions, they could potentially change their city response to something that we might be able to understand.

Maybe a better way of exposing this, then, is to bake it into the response when we can't find a region based on the city provided by the user. We currently say:

We could change this to enumerate the regions:

There are currently only 13 supported region, so it's not a huge list.

Arguably, though, if the majority of causes for a lack of an initial match are due to a city slot/geolocation error, we probably shouldn't be sorting by proximity, but alphanumerically, as proximity to a bad location isn't going to mean much to the user.

Does that make sense, or am I over-engineering this due to my experience on mobile? :)

philipmw commented 8 years ago

So you are concerned that a user's city would not be recognized by Alexa, Google, or OBA API, so we would be unable to map it to the OBA region. Is that accurate?

But if we expose regions, would that help this problem? If Alexa tells me that "Puget Sound" region exists, would it help me to say a qualifying city that everyone understands?

One possibility is to support input of the region directly, if the city intent isn't working out, though there are some downsides to that: more complex setup logic, and the regions would have to be hardcodes into the app through a custom slot.

barbeau commented 8 years ago

So you are concerned that a user's city would not be recognized by Alexa, Google, or OBA API, so we would be unable to map it to the OBA region. Is that accurate?

Yes. For example, within the Tampa region, we're currently expanding to include area west of Tampa Bay. Here's a list of cities in this geographic area that a user could give as a correct answer to "what city do you live in?". We, however, couldn't recognize most of these because they are under the 100,000 population limit for the city slot.

But if we expose regions, would that help this problem? If Alexa tells me that "Puget Sound" region exists, would it help me to say a qualifying city that everyone understands?

It's not a perfect solution, but I think we can try to at least point them in the right direction, rather than just saying "we didn't find anything", and ask the exact same question again - my sense is that this will just lead to an infinite loop. So maybe we rephrase it a bit to redirect their response - something like:

One possibility is to support input of the region directly, if the city intent isn't working out, though there are some downsides to that: more complex setup logic, and the regions would have to be hardcodes into the app through a custom slot.

Yeah, I really want to avoid this - as more regions are added this is more and more work. I'd like to strike a balance here where we leverage the city intent, but at least try to give the user a bit more info to push them in the right direction if their first response doesn't directly map to a region.

On a related note, this problem of mapping user location to a region should go away soon - from the Alexa team:

Location permissions model for 3rd party skills is coming first week of April

At this point, we should just be able to direct users to enter their location in the Alexa app, and then we can read that directly, just like the Uber skill does today.

philipmw commented 8 years ago

Re: location permissions, that's great -- can't wait.

I will take a crack at implementing the change you propose. Do you know off-hand the API to enumerate all regions?

Also, I plan to make that a separate PR from the PR #27 that I have currently. Let me know if you think that PR is fine, ignoring the regions issue.

philipmw commented 8 years ago

Never mind, I see that ObaUserClient.getClosestRegion enumerates all regions.

barbeau commented 8 years ago

We've implemented all these commands, so I'm going to close out this issue. We still have one remaining bug (https://github.com/OneBusAway/onebusaway-alexa/issues/39) so we are close to a v1.0!