Difference between revisions of "Charge statuses from the user point of view"
Jump to navigation
Jump to search
| (23 intermediate revisions by the same user not shown) | |||
| Line 13: | Line 13: | ||
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 start seen by the user == |
{{#mermaid:graph TD; | {{#mermaid:graph TD; | ||
| + | classDef charge-status fill:#ffde00,stroke:#2c3a49,font-size:1.0em,color:#2c3a49; | ||
START(User wants to charge the car) --> | START(User wants to charge the car) --> | ||
Q_BOOK{User wants to book?} | Q_BOOK{User wants to book?} | ||
| Line 21: | Line 22: | ||
BOOKED --> Q_USERDELETESBOOKING{Does the user delete the booking?} | BOOKED --> Q_USERDELETESBOOKING{Does the user delete the booking?} | ||
Q_USERDELETESBOOKING --> |yes| DELETED[Charge status DELETED] | Q_USERDELETESBOOKING --> |yes| DELETED[Charge status DELETED] | ||
| − | Q_USERDELETESBOOKING --> |no| Q_BOOKINGEXPIRES{Does the booking expire?} | + | Q_USERDELETESBOOKING --> |no| Q_BOOKINGEXPIRES{Does the booking expire?<br>it happens after 15'} |
Q_BOOKINGEXPIRES --> |yes| EXPIRED[Charge status EXPIRED] | Q_BOOKINGEXPIRES --> |yes| EXPIRED[Charge status EXPIRED] | ||
Q_BOOKINGEXPIRES --> |no| GOES_TO_CP[User goes to a CP] | Q_BOOKINGEXPIRES --> |no| GOES_TO_CP[User goes to a CP] | ||
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 32: | Line 33: | ||
Q_CHARGESTARTED -->|yes| ACTIVE[Charge status ACTIVE] | Q_CHARGESTARTED -->|yes| ACTIVE[Charge status ACTIVE] | ||
Q_CHARGESTARTED -->|no| FAILED | Q_CHARGESTARTED -->|no| FAILED | ||
| − | + | class BOOKED,DELETED,EXPIRED,FAILED,ACTIVE,STOPPED charge-status | |
| + | }} | ||
| + | |||
| + | == Charge flow end seen by the user == | ||
| + | {{#mermaid:graph TD; | ||
| + | classDef charge-status fill:#ffde00,stroke:#2c3a49,font-size:1.0em,color:#2c3a49; | ||
| + | START(Car is in charge ACTIVE) --> | ||
| + | Q_CHARGED{Car is charged?} | ||
| + | Q_CHARGED -->|yes| STANDBY[Charge status STANDBY] | ||
| + | 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'?} | ||
| + | Q_USERDISCONNECTSINTIME -->|yes|DISCONNECTCABLE[User disconnects the cable] | ||
| + | Q_CHARGED -->|no| Q_USERWANTSTOSTOP{Does the user<br>want to stop the charge?} | ||
| + | Q_USERWANTSTOSTOP -->|no| START | ||
| + | Q_USERWANTSTOSTOP -->|yes| STOPCHARGE[User stops the charge with the card<br>or with the app] | ||
| + | STOPCHARGE --> STOPPED[Charge status STOPPED] | ||
| + | STOPPED --> Q_USERDISCONNECTSINTIME | ||
| + | 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] | ||
| + | STOPPED_STANDBY_WITHPENALTY --> DISCONNECTCABLE | ||
| + | DISCONNECTCABLE --> CDR[The CDR arrives from the CPO] | ||
| + | CDR --> COMPLETED[Charge status COMPLETED] | ||
| + | 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 | ||
}} | }} | ||
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 ;)