upvote
> my justification for 'app' over website has been offline.

Gosh, I wish more apps did some kind of progressive "enhancement" and let people read already cached messages and do deferred sends like the old days, instead of being completely useless without a data connection.

reply
I used to run a company (2010-2018) where our customers were almost always using our product inside of grocery stores, which are almost always metal sheds with some finishings on the walls. Not so great for cell service, it became essential for us to support offline mode if we wanted to keep those customers happy and engaged.

I spent many late nights trying to debug reachability bugs. It's frankly a nightmare trying to build a reliable app when the user has /some/ cell service, but not enough to operate the app reliably.

reply
Gosh, having tried to use the Home Depot app (to find products in store) while IN their stores... It's so bad. I can't even imagine what you dealt with in trying to handle those things.

(And so, so many little bugs in my map thing from upthread were these odd timing quirks when a user didn't have good service and one check would run and leave something else hanging resulting in a blank map. <sigh>)

reply
Yeah, home depot is a tricky case. They have a huge array of products, and in my experience when you cant find something you need to search beyond the store you're in....so the database you need access to isn't exactly small. Makes a practical offline experience tricky.

Home depots website sucks anyway, slow, clunky, terrible touch space, and the search is awful.

Aside, they should ad cell repeaters inside to fix all this.

reply
If I have good service their mobile app is actually pretty quick, but I don't want to join their wifi so... Yeah. :\
reply
Maybe in the US, in Canada i find their online services are pretty average. A lot of the time i search for something and i get a US link, much to my disapointment.
reply
This actually handles that, at least for my use case. Specifically, on first load of the page (in a browser, or the stripped-down browser that runs the app-like PWA install) a service worker gets installed, that caches the entire site/app/map locally, and runs it from there. Then every 24 hours, or on new page load, it checks the live site for content changes and pulls down the changes if they exist. If there's no network connectivity it just silently runs the map.

Each map is 16MB - 20MB in total, so this is all nice and simple to do. Even on a slow 3G connection it's only a minute or so for a full map update to stream in.

The whole point of this system was to take a snapshot of data (mostly OSM), add on some local things that can't really be represented in OSM (like WHICH parking lots are most appropriate, stylistic overrides, system descriptions, etc) and display them. Because of issues I've had in the past with well-meaning-but-misguided OSM mappers wrongly editing trail systems I did not want anything that pulls live.

And then by having purely static content the hosting is very cheap and easy, there's no security concerns around... well... anything dynamic on the site. And each map is portable were I to want someone else to host them. And literally in a couple of years if I haven't updated the map it won't change yet still will work, and that's fine and accepted for this use. Sort-of like a mobile version of a traditional print map. Kinda like the print workflow of editing/design/etc and then rendering the PDF, but web.

This all aligned nicely for me to have a tool that works this way, with each map generated by a tool.

(Sort-of disclaimer: It was also a big personal project in learning to work with AI stuff for development. I knew and understood the inputs and outputs, was able to design the UI, handled/managed all the testing... But I didn't have to worry about the actual-code part. I was able to make pretty quick progress and iterate nicely on my ideas.)

Happy to talk, etc, more about it too. Either here, or contact info is on the site.

reply