-
-
Notifications
You must be signed in to change notification settings - Fork 190
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
Indicate trips that start in the past #593
Comments
Hey @FloEdelmann, thanks a lot for idea! Making trips in the past slightly less visible sounds good. I wouldn't highlight anything in red as this draws attention while we want the opposite. |
Hi, I'd like to add a comment on this: |
@francescosoave is your last comment the same as #634 ? |
hi @grote no, they are 2 different issues (I think) that I'm having. #634 I don't know if it's in the past or in the future, but it doesn't always happen. The current issue instead seems to happen pretty much all the time and I don't understand the feature itself. Basically pretty much every time I do a search it shows the routes available 2, 3, 5, 20 minutes ago..as well as a few in the future (which are the ones I'm actually interested in). I'll post a screenshot when it happens again. But considering that both this and #634 seems to be both related with time maybe they are actually related. here's a screenshot. right now I don't have the issue as in #634 but you can see the first result was 7 minutes ago. Sometime it display several results in the past, while I only would like to see those in the future. |
I guess this specific issue with showing connections that are already in the past is linked to the data source. Even on tfl.gov.uk, the result shows a connection that starts 4 minutes before the indicated time: We could discuss if we want to filter out connections that start in the past, but I'd rather go with showing them slightly different (e.g. by graying out) as discussed above. |
out of sincere curiosity I'd like to know why this feature is needed..personally out of all the trip plan apps/websites I've used, I never even once thought of using them to see the trips that I cannot possibly take (it sounds like the very opposite of what trip planning is?) ..also it happened that I got 4-5 results that were much more in the past than what TFL is showing (worst one was "21 minutes ago"). Also it might be that the TFL considers variable walking time so "if you run" you still might be able to get that bus..? In fact it is only "4 minutes" in the past, assuming you start by having a 13 minutes walk to reach the bus stop..still, if I get 4-5 results in the past as first results on top of the list..that means I have to scroll down to see the first trip available and I think that really negatively affects the ux..but this is with my assumption of just not getting what is the point of showing trips in the past, in a trip planning app.. |
Well, I was thinking more about the case where you've already searched for connections some time ago and afterwards get back to the results screen. I guess you would then expect to see the same connections as before, even if their start time is now in the past. This is the case where I would opt for some visual difference. But we could certainly discuss about filtering out completely connections that have already passed in the very moment of querying them. @grote What's your opinion about this one? |
I think the expected behavior is that you see the next possible trips. That you can also get past trips is a feature, not a bug. What is the bug here is that this provider also returns past trips that are not possible anymore when querying for NOW. In other cases, older trips might have delays and are still possible to catch. |
I guess this bug should be better fixed upstream somewhere in https://github.com/schildbach/public-transport-enabler/blob/master/src/de/schildbach/pte/TlemProvider.java? |
In this thread was said about removing the pasted times, but as pointed @ialokim, sometimes it could be useful. |
Additionally, we might pre-scroll the results list to the first trip starting after the current time to handle strange API behavior as described above while not filtering out any connections. |
Acknowledgments
Is your feature request related to a problem? Please describe.
After searching for trips, the first one has often already started in the past few minutes, which doesn't help when you're searching for the next route. It's easy to miss at a glance though.
Describe the solution you'd like
It would be helpful if cards of trips that start in the past could be grayed out or something similar.
Describe alternatives you've considered
The "X minutes ago" test could be highlighted in red.
Additional context
I think the relevant code for this has to go into
setRelativeDepartureTime
(DateUtils, lines 107-110). Related issue: #185.The text was updated successfully, but these errors were encountered: