Difference between revisions of "Charge statuses from the user point of view"
Jump to navigation
Jump to search
| (4 intermediate revisions by the same user not shown) | |||
| Line 27: | Line 27: | ||
Q_BOOKOK -->|no| FAILED[Charge status FAILED] | Q_BOOKOK -->|no| FAILED[Charge status FAILED] | ||
Q_BOOK -->|no| GOES_TO_CP | Q_BOOK -->|no| GOES_TO_CP | ||
| − | GOES_TO_CP --> STARTSCHARGE[User starts a charge with the card<br>or with the app | + | GOES_TO_CP --> STARTSCHARGE[User starts a charge with the card<br>or with the app] |
STARTSCHARGE --> Q_USERPLUGGEDCABLEINTIME{Did user plug the cable in 30''} | STARTSCHARGE --> Q_USERPLUGGEDCABLEINTIME{Did user plug the cable in 30''} | ||
Q_USERPLUGGEDCABLEINTIME --> |no| STOPPED[Charge status STOPPED] | Q_USERPLUGGEDCABLEINTIME --> |no| STOPPED[Charge status STOPPED] | ||
| Line 42: | Line 42: | ||
Q_CHARGED{Car is charged?} | Q_CHARGED{Car is charged?} | ||
Q_CHARGED -->|yes| STANDBY[Charge status STANDBY] | Q_CHARGED -->|yes| STANDBY[Charge status STANDBY] | ||
| − | STANDBY --> CARCHARGEDNOTIFICATION[User receives | + | STANDBY --> CARCHARGEDNOTIFICATION[User receives a push notification<br>saying that the car is charged<br>and if he doesn't disconnect the car in 60'<br>he will face a penalty] |
CARCHARGEDNOTIFICATION --> Q_USERDISCONNECTSINTIME{Does the user disconnect<br>the cable in 60'?} | CARCHARGEDNOTIFICATION --> Q_USERDISCONNECTSINTIME{Does the user disconnect<br>the cable in 60'?} | ||
Q_USERDISCONNECTSINTIME -->|yes|DISCONNECTCABLE[User disconnects the cable] | Q_USERDISCONNECTSINTIME -->|yes|DISCONNECTCABLE[User disconnects the cable] | ||
Q_CHARGED -->|no| Q_USERWANTSTOSTOP{Does the user<br>want to stop the charge?} | Q_CHARGED -->|no| Q_USERWANTSTOSTOP{Does the user<br>want to stop the charge?} | ||
Q_USERWANTSTOSTOP -->|no| START | Q_USERWANTSTOSTOP -->|no| START | ||
| − | Q_USERWANTSTOSTOP -->|yes| STOPCHARGE[User stops the charge with the card<br>or with the app | + | Q_USERWANTSTOSTOP -->|yes| STOPCHARGE[User stops the charge with the card<br>or with the app] |
STOPCHARGE --> STOPPED[Charge status STOPPED] | STOPCHARGE --> STOPPED[Charge status STOPPED] | ||
STOPPED --> Q_USERDISCONNECTSINTIME | STOPPED --> Q_USERDISCONNECTSINTIME | ||
| − | Q_USERDISCONNECTSINTIME -->|no|STARTPENALTY[User receives | + | Q_USERDISCONNECTSINTIME -->|no|STARTPENALTY[User receives a<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 | + | STOPPED_STANDBY_WITHPENALTY --> 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] | ||
| − | COMPLETED --> END(User can now pay and | + | COMPLETED --> END(User can now pay the charge cost and the penalty cost if present) |
class START,STANDBY,STOPPED,STOPPED_STANDBY_WITHPENALTY,COMPLETED charge-status | class START,STANDBY,STOPPED,STOPPED_STANDBY_WITHPENALTY,COMPLETED charge-status | ||
}} | }} | ||
Latest revision as of 15:02, 2 July 2021
Domain rules[edit | edit source]
- 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 ;)