You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, every single courier's route must include a location with access to the Internet, which makes things extremely hard to scale.
If a given region is covered by multiple couriers but the nearest location with access to the Internet is a hundred miles away, each courier would have to do that journey periodically to keep their users connected. This is very inefficient and exposes more people to the risks involved in the long journey.
Describe the solution you'd like
Allow couriers to sync amongst themselves, so that they can optionally organise themselves as last-mile and long-distance couriers (though nothing would stop a courier from being both last-mile and long-distance).
In the scenario above, only one courier would have to do the long-distance journey.
When syncing with another courier, the initial courier should be given the option to delete all the delivered cargo at the end of a successful sync. This is in case they want to repeat the sync with another courier. (This is a nice to have; if we don't have time, delete all the delivered cargo without asking)
Implementation
I think the biggest challenge is going to be the UX here as we may need to rethink key elements.
UX changes
The "obvious" solution would be to add a third item to the home screen, to run a sync with another courier. Not only would this introduce a bit more complexity, but also we wouldn't be able to guide the user reliably like we do with the current two options (sync with users, sync with Internet) as these would be their potential statuses:
Button
Connected to WiFi or mobile network
Disconnected from WiFi and mobile network
Sync w/ users
Disabled
Enabled
Sync w/ Internet
Enabled, unless connected to WiFi hotspot of another courier
Disabled
Sync w/ courier
Enabled if connected to WiFi hotspot of another courier
Disabled
The problem with toggling the enablement of the buttons above is that the sync with Internet and courier buttons could change for no apparent reason, given the checks we'd be doing to check if the device is connected to the WiFi hotspot of another courier. For example, if Courier A is trying to sync with Courier B, but Courier A connects to Courier B's WiFi hotspot before Courier B is ready to sync with users nearby, then the app will assume that the WiFi network is not that of a courier's hotspot until Courier B is ready.
Another complexity introduced by this feature is that "Sync with users" becomes "Sync with users and couriers", strictly speaking.
Due to the issues above, I suspect we may want to rethink the home screen.
Backend changes
(For lack of better words, I'll be using the terms "client courier" and "server courier" here to refer to the two couriers in the synchronisation, but we should try to come up with a better terminology.)
From the point of view of the client courier, syncing with couriers is effectively the same as syncing with the Internet, with the following differences:
Cargo collection: The CCA should not be deleted at the end of the method call.
Cargo delivery: If the UI asks the client courier to confirm whether to delete the delivered cargo, honour their preference.
From the point of view of the server courier, syncing with other couriers will be exactly the same as syncing with users.
Finally, if the client courier is also an Awala user, we should have a mechanism for the local gateway to send the cargo to the courier app when syncing with another courier.
Describe the problem
At the moment, every single courier's route must include a location with access to the Internet, which makes things extremely hard to scale.
If a given region is covered by multiple couriers but the nearest location with access to the Internet is a hundred miles away, each courier would have to do that journey periodically to keep their users connected. This is very inefficient and exposes more people to the risks involved in the long journey.
Describe the solution you'd like
Allow couriers to sync amongst themselves, so that they can optionally organise themselves as last-mile and long-distance couriers (though nothing would stop a courier from being both last-mile and long-distance).
In the scenario above, only one courier would have to do the long-distance journey.
When syncing with another courier, the initial courier should be given the option to delete all the delivered cargo at the end of a successful sync. This is in case they want to repeat the sync with another courier. (This is a nice to have; if we don't have time, delete all the delivered cargo without asking)
Implementation
I think the biggest challenge is going to be the UX here as we may need to rethink key elements.
UX changes
The "obvious" solution would be to add a third item to the home screen, to run a sync with another courier. Not only would this introduce a bit more complexity, but also we wouldn't be able to guide the user reliably like we do with the current two options (sync with users, sync with Internet) as these would be their potential statuses:
The problem with toggling the enablement of the buttons above is that the sync with Internet and courier buttons could change for no apparent reason, given the checks we'd be doing to check if the device is connected to the WiFi hotspot of another courier. For example, if Courier A is trying to sync with Courier B, but Courier A connects to Courier B's WiFi hotspot before Courier B is ready to sync with users nearby, then the app will assume that the WiFi network is not that of a courier's hotspot until Courier B is ready.
Another complexity introduced by this feature is that "Sync with users" becomes "Sync with users and couriers", strictly speaking.
Due to the issues above, I suspect we may want to rethink the home screen.
Backend changes
(For lack of better words, I'll be using the terms "client courier" and "server courier" here to refer to the two couriers in the synchronisation, but we should try to come up with a better terminology.)
From the point of view of the client courier, syncing with couriers is effectively the same as syncing with the Internet, with the following differences:
From the point of view of the server courier, syncing with other couriers will be exactly the same as syncing with users.
Finally, if the client courier is also an Awala user, we should have a mechanism for the local gateway to send the cargo to the courier app when syncing with another courier.
See also
The text was updated successfully, but these errors were encountered: