Transportr
Transportr copied to clipboard
grote
Indicate trips that start in the past
Acknowledgments
- [X] The feature I want to propose would be useful for the majority of users, not only for me personally.
- [X] I am aware that Transportr is mostly developed by one person in their unpaid spare time.
- [X] I can help myself to get this feature implemented or know someone who wants to do it.
- [ ] If I want to add support for a new region or country, I checked that this is already available in public-transport-enabler and know the process described on the Transportr homepage.
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.
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, first of all, thank you for the great work, I hope I'll be able to completely replace the other non OS app I'm currently using.
I'd like to add a comment on this: I personally don't understand why I should be interested in seeing trips that are in the past. I use this app to check what's the next available route from where I am, and really don't get why the first 5-6 results are displaying things that are not useful (even 20 minutes in the past?). I'd like the option to completely remove from the search result these trips since they occupy most of the first screen, requiring extra scroll and cluttering the whole search results page.
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.
What is the bug here is that this provider also returns past trips that are not possible anymore when querying for NOW.
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. For this reason, I would opt to remark the pasted events somehow. I made a visual proposal in https://github.com/grote/Transportr/issues/696#issue-684503295
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.