Trip Refresh Needs To Be Done After Optimization and Manual Changes

[aesculus]

After an optimization, the trip needs to be refreshed in sequential order. If waypoints were changed the routing is different. Even if the route has not changed, there is a good chance that the energy calculations will be different and unless a segment terminates at a charging destination, the downstream chargers will receive and be affected by the upstream remaining energy at destinations.

Before the single optimization the optimization had to be done in sequential fashion. Now that there is a single optimization, there is less user action, but still the need for cleanup. This same issue occurs after manual changes as well. So if a user reroutes and upstream segment, or changes the date of a trip, each downstream segment will need at least an weather check and energy update.

The new version of the app has already flagged each segment with either it's need for route adjustment (calling Google's Direction API) or simply redoing the weather and then updating the energy calculations. The trick is how to do this so the user does not have to be involved and minimizes the impact/time for them to get the trip in a reliable state.

[aesculus]

One action that should take place is to force the trip back to segment one whenever the user optimizes. This will at least eliminate the problem at the first segment and potentially the next if they then choose the next sequential segment.

[aesculus]

I implemented the force to the first segment when optimizing in V1.2 (34). For two trip segments it's perfect. :-)

Now to figure out what to do when there are more than two segments in a trip.

[aesculus]

Another idea:

For any segment that just needs the energy calcs redone, the path is still valid. For those segments that need to be re-routed, and that are still further ahead in the segment list, I could do a pseudo route. I could plot a direct path between waypoints. That at least could be more appropriate than a path that showed a route that went by waypoints that no longer exist in that segment. It would be crude, but at least accurate.

[EVGrokker]

See my comments on this topic in #418.

[aesculus]

This is becoming a major PITA and really needs a solution. It is going to cause all sorts of issues if I cannot find a work around soon.

How about another idea?
I have already forced the trip to go to the first segment when the users optimizes. I think that is a decent approach.

What about processing the post segments when the user either selects one or if they select the folded map? This would at least keep the optimization performance reasonable to the user. It would delay the secondary calculation times until they wanted to see them. It would then not be as bad IMHO.

But I still have to figure out how to do this sort of in sequence without the user seeing a bunch of flashing trip segments if possible.

[EVGrokker]

I'm not thrilled about switching to the first segment when optimizing, because if the user's attention is focused on a waypoint they added in segment 2 (or later) causing the switch under the hood, they'll wonder why the app changed segments on them. It will lead to bug reports.

We can certainly address the consequences of optimization after route mods in help & tuts. I'm still thinking that the Trip Browser can be used to flag segments needing recalcs.

I'll append some of my relevant comments from #418 below:

---

A couple of thoughts:

• The simplest solution would be to remove the stop count from the Trip Summary, but that doesn't address the underlying problem.
• This may represent an opportunity disguised as a problem. Consider that due to the segmented trip model, there are actions that a user takes on a downstream segment that can cause an upstream segment to need recalculation. This is not intuitively obvious to users, because they're not thinking about the pre-charging requirements of arriving at a stop with adequate power. They want the app to tell them what to expect and how much to charge.
• Suppose that upon the user changing the downstream route in such a way that voids an upstream calculation, the trip summary changes the metrics for the voided segment, using the * character that you previously suggested looked like an error in the app? In other words, the segment charging time, the elapsed time, the distance, the driving time and the segment stops would all use * chars, perhaps even in red or gray to further emphasize the fact that one or more previous segments need to be revised to accommodate the update.
• To allow the user to recalc the affected segments from within the Trip Summary, you could add some real estate below the summary area at the very bottom of the dialog. It would contain both a text field with the overall trip calculation status representing 'up to date' or 'out of date', and a button that would only be enabled when an overall trip recalc was appropriate. So if the user performed an action that threw the previous segment out of sync, the previous segment's metrics would be voided (using * chars), the bottom status would reflect the need for an update, and the recalc button would be enabled. The benefit of this approach is that when it happens, the user would have the opportunity to connect the cause (adding a waypoint requiring re-routing) and the effect (the entire trip needs to be recalculated). At that point, if they invoke the recalc, the fact that it may take some time is acceptable, because they initiated it.

---

One other visual cue that the trip needs to be recalculated could be changing the appearance of the segment badge on the folded map icon. Changing the background color from red to gray (or some other change suggesting incomplete) would be a clue to open the Trip Summary, where the obsolete details described above would be visible. Once the trip has been fully recalculated, the badge would be displayed in red again, meaning it's up to date.

[aesculus]

I'm not thrilled about switching to the first segment when optimizing, because if the user's attention is focused on a waypoint they added in segment 2 (or later) causing the switch under the hood, they'll wonder why the app changed segments on them. It will lead to bug reports.

But since the optimizer could change the routing all the way back to the first segment, what recourse to we have? I do have a way of seeing which segments need routing now (I think), but as soon as you find the first one in sequence you have to at least start there. I proposed the first segment always since any other segment would confuse the user since it was not consistent.

Heck I am pretty sure they will scratch their heads why the first segment changed when they made a change in segment 3. :-)

I just thought we could put out a blanket statement that if you optimize, you are going to go back to segment 1, always.

[EVGrokker]

If there's no way around it, then I'd ask that we present a dialoging that situation to explain what's happening, something along the lines of:

Route modifications require recalculating earlier segments to balance energy requirements.

Then, the sudden change in segment focus would be understandable by the user.

At that point, what is the recommended course of action for the user? Should they reoptimize each segment individually? If so, let's cue them in that same dialog.

Please reoptimize each segment.

[aesculus]

then I'd ask that we present a dialoging that situation to explain what's happening,

Thoughts on how this would appear? Obviously this will need to be folded into the new design of the optimization dialog. I think it should also be included in the description of Optimize in the help text. "You want to optimize? This is one of the prices you pay ..."

At that point, what is the recommended course of action for the user? Should they reoptimize each segment individually? If so, let's cue them in that same dialog.

Egads we will be back to square one again. :-(

I am hoping to delay these other calculations, and if possible doing it when the user cannot see what is happening.

[aesculus]

Note that there is just a single optimization going on, it's just that it is not fully applied until they go to a segment right now. And unfortunately with our friends Google wanting $ and the performance hit you take, the follow on calculations need to be done in sequence order and as few times as possible.

[aesculus]

Actually the above statement is not totally correct wrt to Google $. If the segment only needs to be calculated, Google $ don't apply. It's just a performance issue.

[EVGrokker]

Thoughts on how this would appear? Obviously this will need to be folded into the new design of the optimization dialog. I think it should also be included in the description of Optimize in the help text. "You want to optimize? This is one of the prices you pay ..."

This proposed 'Route has changed…' dialog would be in response to them adding a waypoint. Is that the only scenario, or could it also happen when adding a segment if the hinge pin doesn't have a charger?

So I think the sequence would be:

• User adds waypoint, amending route.
• EVTO determines that a recalc is required
• 'Route has changed' dialog displayed, explaining that optimization will proceed starting from the first affected segment, with an OK button to proceed. (Should there be a Cancel? What state does it return to?)
• The optimization dialog sequence begins from the first affected segment.

Is that approximately correct?

[aesculus]

This proposed 'Route has changed…' dialog would be in response to them adding a waypoint. Is that the only scenario, or could it also happen when adding a segment if the hinge pin doesn't have a charger?

If they add a charger of their own then only the current segment needs to be re-routed. But any change in the trip will probably fire a recalc and then this means all downstream segments could be affected too.

When they optimize anything can happen. Chargers can come and go in any segment.

[aesculus]

With V1.2 (58) this is no longer required. Any update will force a automatic update. If the change only affects the current segment then it will be the only one recalculated. If they optimize the trip, the current segment will be set to the first segment and the each segment following will be recalculated in the background.

[EVGrokker]

I'm not sure how to test this, so I'll go ahead and close it. If there are new issues that arise as a result of the implementation, they can be opened with a specific description.

[aesculus]

There are basically two types of recalcs now:

1. Those that required rerouting
2. Those that just need to have the energy recalculated When you optimize the app gets a list of waypoints back from the server and compares it to what it already has for that segment. If it finds the waypoints are different it flags it as type 1 and then moves to the next segment and repeats the decision. After all the segments are done the app, in the background, automatically processes each of the segments in trip order as either type 1 or type 2 (more routines for type 1).

If you add/delete a waypoint manually that forces that segment to be a type 1 and then it gets the intense (routing) recalc. No other segments are affected, even though they might be technically. If you change anything else in a waypoint or the segment/trip it gets type 2 treatment.

If you change the routing without optimization no other segments are affected, even though logically they would be (ie you manually add a waypoint charger that negates the need for the first waypoint on the next segment). You have to optimize to have the app sort any major changes out.