Being able to use the 'app' offline is a pretty important feature tho. I almost always have web access, but most apps also almost never need it (for me to do what I want to do).
This really depends on what the app is. A few of my friends use apps to look up when the next bus is coming. I use the official website. There's zero need for their apps to be available offline, they only thing they're for is looking up the next bus, which requires an internet connection. The app in this case gives absolutely no advantage to the website. I find that's the case for a lot of phone apps
I feel like such an app could download the bus schedule and do this all offline (and let the user know it is simply an estimate)
In fact, I really wish Google Maps did this, but I guess the damage of getting it wrong once is far greater than getting it right 100 times.
Phones are pretty powerful with huge storage. If you can compute directions offline, why not buses? Saving a map or route is tiny compared to the 64, 128, or 256 GB storage on most people's devices, surely bus schedules can't be that big.
Many public transit agencies provide both static and real-time data.
- static data often is sharing using the "GTFS" specification, which includes stop locations, route geometries, scheduled trips, etc. See http://gtfs.org/
- real-time data is shared using a variety of specifications, and typically includes vehicle locations, service alerts, and other notifications from the agency
The static kind of data can certainly be cached for local use. Try browsing and downloading some from the Transitland open transit data platform and its API: https://transit.land
The online search takes into account all short term schedule modifications. Considering how many such changes occur on almost daily basis, you would be quickly complaining about data usage from all those schedule updates. Or you would frequently get wrong route.
Either way, a lot of complexity / resources spent on something trivially solved by the original solution (webpage).
the app is in leveraging the rider's actual experience ... each time the rider rides the bus, she records the time of arrival - eg takes a photo of the bus - and builds a record of actual arrival times. the app makes predictions about when the bus will come.
Even for this use case, an app (including offline-enabled PWA) should load faster than an online-only website if they're designed properly, because the app UI is pre-cached and it's just making a small JSON web request for the next bus.
That's ridiculous argument against offline use - bus schedules are small enough data that we print them out and carry them in our pockets.
Sure, if the bus company socks, it might be nice to know about changes due to roadwork, real-time updates (ie look up the next bus via it's gps location and speed) - but doing off-line route planning would be a great feature...
It sounds like you're not a daily bus rider. The printed bus schedules are useless due to delays. I take transit into work everyday and you need to know when the next bus is coming or you risk waiting at a station for twenty minutes.
Yeah, they're majorly helpful for transit commuters - you can avoid extended wait times, know when you can take a walk to the convenience store or even know when there's another or a bigger bus coming so you can decide whether it's worth getting on the packed bus or waiting for the next one. It really does change the transit game a lot.
In Missoula, Montana, where I live, the Mountain Line app shows you where every individual bus on a given route is, and computes ETA to a selected bus stop.
I'm pretty sure that's common functionality.
(To be honest, the Mountain Line is very punctual, so I could likely do just fine with just a printed schedule.)
Where I currently live, the bus app does the same, but the difference between scheduled time at each individual stop is typically 1-3 minutes. So it's not like off-line functionality would be useless, even if on-line can add value. But it obviously only adds value when you're on-line - and if off-line the app doesn't work at all...
Displaying the live AVL data for all Missoula busses is not too bad. In Seattle where I currently live, not so much. Thus, most of our apps here tend to give arrival times of busses with nearby stops.
Fun aside: my dad drove for the Mountain Line many years ago. I rescued one of his 1970s yellow shirts with the embroidered logo patch a while back.
You must not live in a city with over 100 bus schedules.. in my city, the offline app which uses your location data to tell you what bus stops are nearby and what the arrival times of each bus are, is immensely helpful.
Can you elaborate why offline use is something that matters for bus schedules?
I mean, I get the usefulness of wilderness-related apps (e.g. ocean fishing) or various things that could be useful in an emergency like the aftermath of a hurricane, and for these offline functionality matters, but for buses, if you're within a few miles of a bus stop and the buses are running at all, then you're guaranteed to have high-speed cellular internet access and offline features don't matter.
I can imagine being in the middle of some national park where the closest bus is unimaginably far away but I still have mobile internet access, but I really can't imagine a situation where I'd care about buses but don't have internet. Or are USA data plans so small that it's worth thinking about the data usage (as opposed to just latency) of downloading a webpage with timetables?
Certainly, our rural public transit is a catastrophe in it's own right. That still supports the argument that there is a very real use case for offline bus schedule lookup.
Nah, you're wrong! [You're not totally wrong, tho you wrote in really broad absolutes.] Even your example would be a much better app with offline support. The app shouldn't stop working just because of a hiccup in the user's internet connectivity.
If I, the user, switch from the when-is-the-next-bus-coming app to another app and then switch back (within, say, a few minutes), it'd be really great if the app could default to showing me info based on the data it just downloaded instead of automatically resetting the UI and waiting to update it until it downloads the data again.