Difference between revisions of "Charge statuses from the user point of view"
Jump to navigation
Jump to search
| Line 9: | Line 9: | ||
** Charge card | ** Charge card | ||
** A mix of them (es. users can start a charge with the mobile app and end it with the charge card) | ** A mix of them (es. users can start a charge with the mobile app and end it with the charge card) | ||
| − | * '''Don't trust timing of simulated (CU-Simulator, Q-Simulator, ecc...) and developing (dev, staging or sandbox) environments:''' due to the fact that the domain counts various external systems ( | + | * '''Don't trust timing of simulated (CU-Simulator, Q-Simulator, ecc...) and developing (dev, staging or sandbox) environments:''' due to the fact that the domain counts various external systems ([[Glossary#CPO|CPO]] s, physical charging points but also license plates microservice, ecc...), the timing in the "real life" can be significantly longer than the one in simulated and developing environments (we are working to improve this part). |
Some http calls will require to be asynchronous (es. after a charge is completed a [[Glossary#CDR|cdr]] could take even days to arrive) and others could require many seconds to complete (ex. a [[Glossary#Remote start|remote start]] takes 4-5 seconds to complete on average). UI/UX should be designed in order to specify which scenarios are asynchronous and which ones are expected to be synchronous but longer than expected and should provide the UI elements (like spinners, progress bars, texts explaining what's happening, ecc...) to give the user a feedback to let him know that something is happening behind the scenes. If this is not the case feel free to ask ;) | Some http calls will require to be asynchronous (es. after a charge is completed a [[Glossary#CDR|cdr]] could take even days to arrive) and others could require many seconds to complete (ex. a [[Glossary#Remote start|remote start]] takes 4-5 seconds to complete on average). UI/UX should be designed in order to specify which scenarios are asynchronous and which ones are expected to be synchronous but longer than expected and should provide the UI elements (like spinners, progress bars, texts explaining what's happening, ecc...) to give the user a feedback to let him know that something is happening behind the scenes. If this is not the case feel free to ask ;) | ||
= Charge flow seen by the user = | = Charge flow seen by the user = | ||
| − | + | User books a charge using the app → charge goes in status [[Glossary#Charge statuses|BOOKED]] | |
| − | User goes near to the charging point → he can use the app to invoke a [[Glossary#Remote start|remote start]] or he can start the charge using the [[Glossary#Charge card|charge card]]</ | + | User goes near to the charging point → he can use the app to invoke a [[Glossary#Remote start|remote start]] or he can start the charge using the [[Glossary#Charge card|charge card]] → charge goes in status [[Glossary#Charge statuses|ACTIVE]] or [[Glossary#Charge statuses|FAILED]] |
| + | |||
| + | After user requested to start the charge (via app or card) if he doesn<nowiki>'t plug the cable in 30''</nowiki> the charge goes in status [[Glossary#Charge statuses|STOPPED]] | ||
| + | |||
| + | Once the car is charging (e.g. the charge is in status [[Glossary#Charge statuses|ACTIVE]]) if the user | ||
Revision as of 16:00, 25 June 2021
Domain rules
- Don't expect a strict connection between user actions on the app and the screen to show: during the whole process, external events can occur and these events can cause a change in the charge status, for this reason, in many scenarios, the mobile app status can change even when user does nothing on the app, wheter the app is in foreground, background or closed.
Example: the mobile app is closed, there are no charges in progress nor reserved. If a user goes to a charging point and start the charge with the card and he/she opens the app, the app must open showing the screen showing the charge in progress
- Users can charge their cars in three ways:
- Mobile app
- Charge card
- A mix of them (es. users can start a charge with the mobile app and end it with the charge card)
- Don't trust timing of simulated (CU-Simulator, Q-Simulator, ecc...) and developing (dev, staging or sandbox) environments: due to the fact that the domain counts various external systems (CPO s, physical charging points but also license plates microservice, ecc...), the timing in the "real life" can be significantly longer than the one in simulated and developing environments (we are working to improve this part).
Some http calls will require to be asynchronous (es. after a charge is completed a cdr could take even days to arrive) and others could require many seconds to complete (ex. a remote start takes 4-5 seconds to complete on average). UI/UX should be designed in order to specify which scenarios are asynchronous and which ones are expected to be synchronous but longer than expected and should provide the UI elements (like spinners, progress bars, texts explaining what's happening, ecc...) to give the user a feedback to let him know that something is happening behind the scenes. If this is not the case feel free to ask ;)
Charge flow seen by the user
User books a charge using the app → charge goes in status BOOKED
User goes near to the charging point → he can use the app to invoke a remote start or he can start the charge using the charge card → charge goes in status ACTIVE or FAILED
After user requested to start the charge (via app or card) if he doesn't plug the cable in 30'' the charge goes in status STOPPED
Once the car is charging (e.g. the charge is in status ACTIVE) if the user