Difference between revisions of "Charge statuses from the user point of view"
Jump to navigation
Jump to search
| Line 52: | Line 52: | ||
Q_USERDISCONNECTSINTIME -->|no|STARTPENALTY[User receives the second<br>push notification saying<br>that the penalty is starting] | Q_USERDISCONNECTSINTIME -->|no|STARTPENALTY[User receives the second<br>push notification saying<br>that the penalty is starting] | ||
STARTPENALTY --> STOPPED_STANDBY_WITHPENALTY[Charge status STOPPED_WITH_PENALTY<br>or STANDBY_WITH_PENALTY] | STARTPENALTY --> STOPPED_STANDBY_WITHPENALTY[Charge status STOPPED_WITH_PENALTY<br>or STANDBY_WITH_PENALTY] | ||
| − | STOPPED_STANDBY_WITHPENALTY --> DISCONNECTCABLE | + | STOPPED_STANDBY_WITHPENALTY --> USERPAYING[User pays a penalty of some cents<br>for every minute passing<br>with the car connected] |
| + | USERPAYING --> DISCONNECTCABLE | ||
DISCONNECTCABLE --> CDR[The CDR arrives from the CPO] | DISCONNECTCABLE --> CDR[The CDR arrives from the CPO] | ||
CDR --> COMPLETED[Charge status COMPLETED] | CDR --> COMPLETED[Charge status COMPLETED] | ||
Revision as of 14:51, 2 July 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 ;)