The immediate problem that we need to solve is that the current app frequently crashes while delivery riders are trying to complete their tasks, which is highly inconvenient. So THE task for v1.0 is simply to replicate the current deliverers' user experience, but without the crashes.
Alex's proposal for that is to hoover up the existing spreadsheet data into a relational database as a batch process, and drive the deliverer's view from that.
Niceties like automatic routing, and even user accounts, can wait for later.
User story
As a delivery rider/driver:
I need quick and easy access to the route that I will be following, including all info shown in the original web app (client name, address, phone number, number of portions, any food preferences, free text instructions, and "what to do if you can't make contact"). [Currently this works via a URL e.g. app.cckitchen.uk/?p=ABCD which is automatically texted to riders ~90 minutes before their shift; if the four-letter passcode matches with one of the route sheets in the Google Spreadsheet, the info on that sheet is presented by the web app. Replicating exactly that functionality would do for v1.0]
I need the list of addresses presented in an optimal order to minimise travel time.
I need a GOOGLE MAPS button for each drop that sticks a pin in a map, based on the stored PlusCode.
I need a CALL button for each drop to make a phone call to the recipient if needed.
The immediate problem that we need to solve is that the current app frequently crashes while delivery riders are trying to complete their tasks, which is highly inconvenient. So THE task for v1.0 is simply to replicate the current deliverers' user experience, but without the crashes.
Alex's proposal for that is to hoover up the existing spreadsheet data into a relational database as a batch process, and drive the deliverer's view from that.
Niceties like automatic routing, and even user accounts, can wait for later.
User story
As a delivery rider/driver: