search

CUTR-at-USF / OpenTripPlanner-for-Android

An Android app for multi-modal trip planning and navigation using any OpenTripPlanner server.
Other
129 stars 91 forks source link

Enhance auto-trip plan functionality #359

Open kalon33 opened 10 years ago

kalon33 commented 10 years ago

Hello, here is a problem I experience with OTP android app:

When planning a trip, you don't have time to choose date/time of travel after setting start and stop locations. The app immediately starts to look at some itinerary, whereas it should allow you to choose "start now" or choose some time. Same thing when you change either start or stop.

I don't think it's the best thing, because you trigger the server for some useless requests.

vreixo commented 10 years ago

@kalon33 this was intentionally done to work that way.

The reason for doing it this way is that I suppose that the more general use case is to retrieve a trip for the current time (in fact that was the only option that was present before on the app) and I think that would be counterproductive to slow down the more general use case requesting the user to set a time before start planning.

The the trip is not exactly always automatically triggered when you select the time, this only happens if origin and destination are already set, so for example on first start you can adjust first the time, then set destination and only one trip request will be triggered.

My main concern is that I really like the idea of automatically trigger the process of request a trip, guessing when the user might want this, and I think that will be a clear problem if they set the date and after nothing happens.

So, I only can think about two possible solutions:

Another thing related to this that might be worth to study, is to make the date and time button more dynamic showing someway the time that is going to be used to plan the trip, directly in the map screen. This will give some context to the user and might point him to change the time the first thing so trip request won't be triggered. The main problem is that I was not able to find a good design to accomplish this, because I think that the buttons looks better not so huge to display the trip date ant time. One option will be to only show the time.

One last thought that came to my mind is that the only disadvantage that I can see to trigger <> requests is that they might be too much disturbing to the user, because they block the UI. So, we might consider to make them in the background and maybe warn with a toast of the new trip obtained or just make the process completely silent, this way won't be a problem anymore to make too much requests.

kalon33 commented 10 years ago

@vreixo I need to think a bit more about your solutions to give you my advice :)

Is that also expected that when you get an error message or willing to change time again after looking for a trip, it resets to the current time?

----- Mail original -----

De: "Vreixo González Caneda" notifications@github.com À: "CUTR-at-USF/OpenTripPlanner-for-Android" OpenTripPlanner-for-Android@noreply.github.com Cc: "Nicolas Derive" kalon33@ubuntu.com Envoyé: Lundi 25 Août 2014 18:52:06 Objet: Re: [OpenTripPlanner-for-Android] Itineraries shoudn't be calculated as soon as both start and stop points are defined (#359)

@kalon33 this was intentionally done to work that way.

The reason for doing it this way is that I suppose that the more general use case is to retrieve a trip for the current time (in fact that was the only option that was present before on the app) and I think that would be counterproductive to slow down the more general use case requesting the user to set a time before start planning.

The the trip is not exactly always automatically triggered when you select the time, this only happens if origin and destination are already set, so for example on first start you can adjust first the time, then set destination and only one trip request will be triggered.

My main concern is that I really like the idea of automatically trigger the process of request a trip, guessing when the user might want this, and I think that will be a clear problem if they set the date and after nothing happens.

So, I only can think about two possible solutions: 

* Recover again the plan trip button. I don't think that this is a good idea, now is all much faster and clean and also some user feedback that I had was really positive to remove the button. You can see for example that there is no such button on Google Maps. 
* Add one check somewhere to change the default behavior and allow the user to choose to don't trigger the process after changing the time. I also don't think that is a good idea, because will be much better to don't put the user to choose something so technical and internal of the app. Maybe put something on an advanced section in preferences but I still don't see it.

Another thing related to this that might be worth to study, is to make the date and time button more dynamic showing someway the time that is going to be used to plan the trip, directly in the map screen. This will give some context to the user and might point him to change the time the first thing so trip request won't be triggered. The main problem is that I was not able to find a good design to accomplish this, because I think that the buttons looks better not so huge to display the trip date ant time. One option will be to only show the time.

One last thought that came to my mind is that the only disadvantage that I can see to trigger <> requests is that they might be too much disturbing to the user, because they block the UI. So, we might consider to make them in the background and maybe warn with a toast of the new trip obtained or just make the process completely silent, this way won't be a problem anymore to make too much requests.

— Reply to this email directly or view it on GitHub .

vreixo commented 10 years ago

@kalon33 ok :-)

Yes it's expected for both cases, although with the new design might be interesting to think if this restart is the best approach, you can see more details here https://github.com/CUTR-at-USF/OpenTripPlanner-for-Android/issues/69

barbeau commented 10 years ago

I agree with most of @vreixo's points. I do think the process could be a little smoother from a UX perspective - to me, it seems like there is a slight delay (likely while geocoding destination) after you set your destination but before the trip is planned. IMO this could be improved to make it clearer to the user that something is happening that's going to result in your trip being planned. As @vreixo says, maybe we don't block the UI at all but just do some onscreen event to show that the trip is being planned (e.g., something like the progress bar at the top of Gmail while its refreshing mail).

Perhaps a good solution to the trip time issue is after the first time after install the trip is planned, show a little on-screen arrow to the user pointing to time, saying that it can be changed before/after planning a trip. We could definitely use more instructional prompts within the app to guide the user through the first time they use it, and this could be one of them.

vreixo commented 10 years ago

@barbeau I think that this could be very interesting. Maybe we can show the bottom itineraries spinner view as soon as the trip is requested with an undetermined ProgressBar exactly as Google Maps does. But I think that would be easier to only show this after geocoding was completed, and before (and in general for all geocoding processes) put another progress bar (or little circle) inside the text box, just like the button for additional options.

In suppose that the delay that your refer is when planing a trip setting a map marker, because the gocoding process can be a bit slow. When the direction is selected from the autocomplete I think that trip request is triggered pretty quick.

barbeau commented 10 years ago

@vreixo Yes, I'm referring to it being slow when setting the map marker via long-press.

I like the above ideas for progress bars for geocoding and trip plan.