Educating Users: Auto vs Manual, Optimization vs Calculation

[EVGrokker]

This issue is a place to capture discussions concerning optimization, calculation, and how to help users understand them.

It began with an email discussion triggered by a user's UI suggestion to @aesculus :

xxx wrote:

Yes, the problem was that I needed to re-optimize. My ui suggestion is that in segment details any of the relevant items could be edited and then clicking an icon on the map would recalculate the trip. Example: Change the charge duration (maybe because you want to eat lunch there) so the leaving state of charge goes up so the next charge duration goes down after recalculating.

It does recalculate. Do you mean re-optimize? There is a big difference. Recalculate does all the energy calculations and figures out if you can make it with the chargers defined. Re Optimizes throws all the auto chargers away and figures out a new route based on the changes you made.

By doing this the drop down menu could be used much less and be more intuitive. Why not swipe down to see the details, swipe up and below the details the map appears. No need to select from the menu.

We are working on various UI improvements. I will pass your comments to my UI guru.

[EVGrokker]

@EVGrokker responded:

This person is an early adopter, so they’ve got some reflexes that newer users might not have. But this explanation is something we need to really make clear, especially once issue #10 is resolved.

If I were describing the operation to someone, I’d say it like this.

Input an origin and destination for the trip. Select Auto for EVTO to calculate your trip. The route is optimized to select the best supercharger locations based on your car’s characteristics.

If you want to modify your route by adding waypoints, or add charging time to a stop, the trip is recalculated automatically.

If you modify the route in such a way that causes a charging stop in the red (or yellow, depending on your tolerance for range anxiety), you should ask EVTO to reoptimize the segment. If this happens frequently, you are an advanced user, and should probably be using Manual mode. You would construct your route without any automatic charging stops, add waypoints, then optimize after the route’s established to select the optimal charging stops.

In the typical use cases, there should be no need to ask for EVTO to reoptimize unless you alter the route, changing the segment mileage.

In most cases, EVTO Does The Right Thing.

---

@aesculus responded: Yes. How do we get people to think the same way. Most think I should be doing all of this auto-magically in the background. I have had three people in the last week upset that I don't auto optimize on every change. BTW I don't think any of the planners do this. I think they require you to press some sort of button.

I guess the case could be made that if they add/delete a waypoint, it should be auto optimized but really I think that's bad form like you spell out above.

[EVGrokker]

Questions:

• If a route is initially calculated using Auto charger selection, does that have any impact on EVTO behavior after the route is initially calculated? I believe that it only matters the first time the route is calculated. Is that correct?
• Suppose that a route was calculated using Auto, and the user adds an off-route waypoint. EVTO recalculates, changing the route. Can you tell that the route has changed from the initially calculated route? Perhaps by its mileage, or some other attribute? If so, you could display a dialog: "Route has changed. Use Optimize Routing to reevaluate charger selection." Maybe if we had a reliable mechanism to train users when re-optimization is called for, they would know when to use it.
• Let's say EVTO is calculating a route using Auto charger selection. That's a two-step process, correct? My observation is that there are two spinner dialogs: 1) 'Optimizing Trip', then the route is displayed, then a pause, then 2) 'Calculating Trip', then the automatic charging stops are displayed. What's happening during 'Optimizing Trip'? At first glance, it would appear that these spinner dialogs two are mislabeled.
• Why is there a pause between steps 1 'Optimizing Trip' and 2 'Calculating Trip'? What's EVTO doing?
• If I input a trip using Manual charger selection, I get a single spinner 'Calculating Trip', after which the route is shown. Why is that different than the first half of the Auto sequence?
• As I recall, when Manual charger selection is used, the selected route is probably not the route the user would want if they were using superchargers. If that's the case, what criteria were used to select that Manual route? Distance? Fastest travel?
• I believe the original design was Manual only. EVTO would display three route choices, and the user would display the charger overlays and assign them. Then you received feedback that users wanted EVTO to do everything for them, which led to the Auto mode enhancements. Is that approximately correct?

[aesculus]

If a route is initially calculated using Auto charger selection, does that have any impact on EVTO behavior after the route is initially calculated? I believe that it only matters the first time the route is calculated. Is that correct?

Only the first time, yes.

Suppose that a route was calculated using Auto, and the user adds an off-route waypoint. EVTO recalculates, changing the route. Can you tell that the route has changed from the initially calculated route? Perhaps by its mileage, or some other attribute? If so, you could display a dialog: "Route has changed. Use Optimize Routing to reevaluate charger selection." Maybe if we had a reliable mechanism to train users when re-optimization is called for, they would know when to use it.

I suppose I could keep track of a metric such as distance. Then if the distance changes, I know they did something to the route and it MAY need optimization. But really you don't know it needs optimization unless the SOC for waypoints falls out of line. So I could basically determine if any waypoint falls below the min SOC for that waypoint, trigger an alert. Keep in mind though that people may in fact not necessary want the optimal route, and forcing optimization may not be desirable. This will get more complicated later when we add the min stops, min energy and min distance to the optimization models.

Let's say EVTO is calculating a route using Auto charger selection. That's a two-step process, correct? My observation is that there are two spinner dialogs: 1) 'Optimizing Trip', then the route is displayed, then a pause, then 2) 'Calculating Trip', then the automatic charging stops are displayed. What's happening during 'Optimizing Trip'? At first glance, it would appear that these spinner dialogs two are mislabeled.

EVTO uses a number of steps:

1. When you first create the trip you have an origin and destination. Google takes over immediately and shows a route that you could take in an ICE between those two points. Before I showed multiple possible routes but that was confusing so I turned it off. One can argue that showing this route is a tease and should not be done. We can think about this.

2. If you have Manual selected the app stops here. If you have Auto selected the app now takes the two waypoints and sends it off to the server with some parameters such as your SOC requirements, car energy data, times etc. The server takes all of this in and tries to find the set of SC that will get you between the origin and destination in the least amount of time (other models to come later). It then returns to the app a set of chargers that fill in the energy gaps in the order best suited to the optimization model. It also gives back some energy factors that will help at the end of segments and waypoints. This is what is happening when you see the Optimizing Trip message. Maybe should be Route now. This is a fairly crude pass because it does not use weather in its calculation (issue #35 ) and it does it using energy calcs between stops, rather than turn by turn.

3. Now the app takes this set of stops and builds a detailed route for Google Maps. Google comes back with turn by turn directions with very small distances. Each of these in turn is sent to another calculator to do very minute detailed energy calcs. So the results are much more accurate than step 2. It's usually a refinement but where it can be an issue is if the weather is dramatic. Then the route optimizer and detailed calculator may not agree. You could see this where you end up with a little more energy than your default Min SoC or where it turns yellow like 13%-14% when you asked it to never go below 15%. All this is being done when you see the Calculating message.

Why is there a pause between steps 1 'Optimizing Trip' and 2 'Calculating Trip'? What's EVTO doing? If I input a trip using Manual charger selection, I get a single spinner 'Calculating Trip', after which the route is shown. Why is that different than the first half of the Auto sequence?

EVTO is sorting all of the waypoints, discarding ones that are no longer needed and adding new ones (ie chargers). It's also going off to the web to get elevation and weather data for these new places. I guess I could add a spinning message at this point so people don't think it went brain dead.

As I recall, when Manual charger selection is used, the selected route is probably not the route the user would want if they were using superchargers. If that's the case, what criteria were used to select that Manual route? Distance? Fastest travel?

Purely Google fastest drive time using an ICE. No considerations for anything else. See comment above why you could make a case not to show this when Auto is used.

I believe the original design was Manual only. EVTO would display three route choices, and the user would display the charger overlays and assign them. Then you received feedback that users wanted EVTO to do everything for them, which led to the Auto mode enhancements. Is that approximately correct?

It was something I was considering providing some options. But that was a carry over from the purely manual world and was a tease for optimization users.

[EVGrokker]

Very helpful answers, thanks for the detail.

Here's a suggestion for the Auto route calculation sequence. You have a series of steps, and the user has no clue where EVTO is in the process. I'd suggest one of two approaches to keep them informed as to the progress: 1) A simple progress bar with high-level labels describing where we are in the process. Step 1 might be 'Searching Routes' ending at 33% progress. Step 2 might be 'Predicting Energy Consumption' ending at 66% progress. Step 3 might be 'Finalizing Route', sending the progress meter to 100% by time it completes. If you're able to provide incremental value updates within the major steps, so much the better. 2) A dialog with three steps, and a Cancel button. The labels of the three steps would be the same as Option 1. While the step is active, display a spinner. When the step is complete, display a checkmark. If user bails, back to the New Trip dialog.

The goal of this would be reassure users that something's going on, and to provide a sense of how long it's going to take. It would also drive home the significant differences between Auto and Manual. Manual could have a one-step version of the above.

[aesculus]

Cool ideas.

The goal of this would be reassure users that something's going on, and to provide a sense of how long it's going to take. It would also drive home the significant differences between Auto and Manual. Manual could have a one-step version of the above.

You mean like those totally bogus estimates of how long it takes to download a file from the internet? :-)

[EVGrokker]

Yep, like those totally bogus estimates. That's why I offered option 2:

	Automagic Route Optimization
✓	Searching Routes
⟳	Predicting Energy Consumption
	Finalizing Route

Cancel

[aesculus]

The cancel thing might be hard to implement, but I can give this a go. The cancel may be just to dismiss the dialog manually at the first, and later may be able to stop the process. For many devices and optimizations it will probably happen quicker than they can cancel anyway. The big time eater is the weather fetch I think and by that time you cannot stop that train.

[aesculus]

So we might want to add a step two which is "Gather Data for New Charger Stops" or something like that.

[aesculus]

And predicting is more like refining but ...

[EVGrokker]

With respect to a multi-step dialog communicating progress to the user, I'd opt for simplicity, brevity, and reasonable accuracy over nuts and bolts details. I'm happy to iterate on the terse descriptions of the steps, but they should be something that makes sense to the user in the same way that the spinner dialogs do now. We're communicating that EVTO is grinding away, and will return shortly with results. If the cancel may not be immediate, let's wait to see how it feels in practice before deciding how to process a user cancelling or dismissing the dialog. I'll create an issue with an enhancement request to implement a status dialog during recalculations and optimizations.

[EVGrokker]

Something that has been clarified in this discussion for me is that there are two major operations that EVTO may engage in, either as part of a sequence or standalone.

Optimization occurs when charging stops need to be assigned. EVTO is selecting the optimal route from origin to destination through superchargers. This is the typical Auto workflow. Subsequent optimization may change an existing route the original route has been modified by the user with new waypoints.

Calculation occurs when the route is known, and predicted Arrival SoCs need to be computed. Calculation will never change a route. This would typically happen when initially creating a new trip, or making any change to it, including ETDs, Reserve SoCs, updated car characteristics, new waypoints, etc. This is the typical Manual workflow. However, a user may invoke optimization on a manually created route at any time.

I think some user confusion emerges from the fact that optimization and calculation often happen in tandem and seem to be part of the same operation, when in fact they're quite different.

[aesculus]

They are somewhat different but there are parts that are duplicated, but at different places (app vs server).

Also Calculation always follows Optimization. If not, the optimization would not be complete. It would be lacking.

But all of this is sort of a secret. I suppose if I moved everything to the server, then there would be perhaps only one cycle needed. Architecturally that would have to be rethought out. Sort of why issue #35 has not been implemented yet in addition to other details.

[aesculus]

This issue is moot with V1.2 and the removal of Calculation.