Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use location #12

Open
anbasile opened this issue Nov 16, 2015 · 6 comments
Open

Use location #12

anbasile opened this issue Nov 16, 2015 · 6 comments

Comments

@anbasile
Copy link

I think the following flow could bring two things: a faster interaction and infinite pickup points.

1) Driver starts

Driver is about to start driving and tell the system he is a driver. Exactly as he does in the current version. He send his position to the bot.

2) Passenger starts

Passenger is at the bus stop. He says is a passenger (as he does in the current version) and sends his location to the bot. The bot replies with an approximation of the location to the nearest bus stop (easy to do since all the data are available).

3) Destination

Passenger send his destination. How ?

  • By selecting from a closed list (now he would see only ['Trento','Povo'])
  • By texting it (i.e. "povo, alla malga")
  • By sending a voice message

4) Waiting

Now passenger is waiting for a driver

5) About to leave

Driver is in his car and is about to leave for his way to work. He has already declared himself as a driver and has sent his position to the bot.

6) Broadcast

Driver receives a list of ALL the ride requests within a given range from his position. The item of the list he receives are tuples: (request_index,waiting_position,destination).

7) (driver_x,passenger_y)

Driver accept to satisfy one request from the list and a message is sent to the waiting passenger. The message contains also driver position and an estimation of the time it will take. The passenger request is cancelled from the list and new drivers are not going to see it.

8) Feedback

Driver leaves and stops to pickup the user. At the end both of them send a confirmation and leave a feedback.

9) Learn

The system will try to offer the best possibile order of the list by analyzing previous rides: i.e. passenger going to a specific location, particulare passengers, distance from waiting position, etc.

What do you think? Please discuss.

@matteosecli
Copy link

The fact that the driver can choose the passenger from a list does not convince me. First of all it's an extra step that we require from the driver, and we want to make the driver-experience as easy as possible. Secondly, even though we can make a smart suggestion system, the driver has the last word in choosing the passenger. This could create a situation in which a given passenger is never offered a ride because the drivers are always choosing someone else (if I got your points correctly). I think that a smarter system can be implemented in assigning a passenger number, but the passenger-driver pairing should be automatic. I agree on you on the other points, especially on the location and text/voice-interaction ones.

@anbasile
Copy link
Author

  1. No, the driver cannot choose the passenger, since the list items are in the format (request-Id, waiting position, destination). Assuming that request id is progressive by location and unique, then pairing can be implemented in a fair way: first come, first serve.

  2. it's not an extra step: now the driver has to select a pickup stop. I am suggesting that he selects a request in format I said before instead of the pickup point only.

@matteosecli
Copy link

OK, now I think I got it!

@maxiride
Copy link

Not a bad idea, also because at the moment the button for the Povo location states valoni/sommarive/mesiano but how can a driver know where is his passenger? Using the location in the appjcoild solve the pick up issue

@kercos
Copy link
Owner

kercos commented Nov 19, 2015

Location sounds great.
I'd avoid (at least for now) typing and voice message to select destination.
I agree that intermediate stops issue needs to be solved, but not sure that the idea of the driver receiving a list of ALL the ride requests (within a given range) is a good solution. This might in fact include passengers "close" to the driver but not on the ride path of the driver (could even be in the opposite direction).
Perhaps you could start implementing the location part but for the rest i'd suggest to wait and discuss a bit more about it, but feel free to experiment of course ;)

@anbasile
Copy link
Author

Ok I will see how it works.

Yes, at first the list would include those cases, but starting from the first pick of the driver, the system will start learning the drivers preferred path. If we think that pickmeup should be fit for daily and regular commuting I guess the learning task will be easy(majority class) otherwise it will need some more thought.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants