> Why can't it just take the photo, take the text description, and hold that until service is better? Just give the driver the map, and upload the other stuff when you can.
The obvious answer is because asynchronous workflows are brittle, and require intervention from the end user to correct if they break
Then most end users aren't going to care to fix it when it breaks, or be able to fix it when it breaks for a variety of reasons
Better they can't continue than they do the last order wrong, amirite?
There's some strong "Seeing Like a State" vibes here. I'm pretty sure these apps are intentionally designed as tools to force the users (here, drivers) into a specific flow, a flow that minimizes complexity for the vendor, reality be damned.
Another way to look at it: the job of the driver side of a delivery (or taxi) app isn't to be useful to the driver; the job is to be a remote control with which the business can control the driver like they were an automaton.
It's dispute resolution in a low-trust environment.
When a customer shows up saying something went wrong with the delivery, the CSRs will need evidence and if the driver did their job then they can be exonerated.
The logistics are a bit more complex than a restaurant where customers are eating at tables in the same building.
Lots of delivery jobs are effectively paid by the piece or paid by the route. The driver is not paid hourly.
This is one reason that package delivery drivers often will say that they've attempted delivery when they at best drove past the delivery point. Marking the delivery as attempted gets them off the hook for that delivery, and they can finish their shift that much faster.
Having a broken app that forces the driver to 100% complete every delivery before moving to the next one thus costs the company relatively little, but saves some complexity, missing proof of delivery, etc.
You can still queue the upload client side and let the worker move on. Don't consider the delivery complete until the upload happens, but allow the next leg of the job to start. The client workflow can require taking the picture and clicking submit, but it can accept queueing the actual upload.
In any case, if the network is down, a spinner is a lie. It's pretending to be working on something when it's not. It should show an error at least.
Relevantly, in this specified case, the picture of their delivered food is shown to the customer immediately. This is more than a nice to have (imagine a large apartment building, where your food could be dropped in any number of locations).
The obvious answer is because asynchronous workflows are brittle, and require intervention from the end user to correct if they break
Then most end users aren't going to care to fix it when it breaks, or be able to fix it when it breaks for a variety of reasons