Edit Waypoint: Terminology, user perspective

[EVGrokker]

I know we've discussed some of this before, but I can't find an issue that specifically addresses the topic, so I'm creating this issue, initially for discussion.

The Edit Waypoint dialog serves a couple of purposes:

• It allows the user to provide a more meaningful name
• It allows the user to set a Stop Time
• It allows the user to set an Arrival SoC

There are two type of Waypoints that may be edited: Charging, and non-charging.

For charging waypoints, the relevant variables are:

• "How long will I be here?"
• "How much energy will I leave with?"

Before opening the Edit Waypoint dialog, the Waypoint Inspector answers both of those questions. If the charging waypoint was automatically calculated by EVTO, pinning it to require it as a charging stop, reviewing the Waypoint Inspector shows how much time EVTO has allocated and the target energy upon departure.

Once we're in the Edit Waypoint dialog, the questions are more specific, depending on the waypoint.

For non-charging waypoints, the relevant variables are:

• "How long will I be here?"
• "How much energy will I arrive with?"

For charging waypoints, the relevant variables are:

• "How long will I be here?"
• "How much energy will I depart with?"

This difference is subtle but significant .

For non-charging stops, "How long will I be here?" affects the segment timeline, but not the energy calculations. "How much energy will I arrive with?" is relevant because this is not a charging stop. They may be planning to do some local driving here, and being able to boost the arrival SoC within the Waypoint Editor is logical.

For charging stops, "How long will I be here?" affects both the segment timeline and the energy calculations. "How much energy will I arrive with?" is not the right question to ask. The question should be "How much energy will I leave with?" Being able to influence this using the sliders is logical.

The proposal is that the behavior of the sliders for charging waypoints should be different from non-charging waypoints.

The behavior for non-charging waypoints is already correct.

For charging waypoints, I propose:

• Relabeling the SoC slider to Departure SoC
• Adjusting Stop Time moves the Departure SoC slider to show how much energy will be available upon departure.
• Adjusting the Departure SoC slider adjusts the Stop Time slider to show how long the desired departure SoC will take to achieve.

In other words, for a charging waypoint, moving one slider affects the other.

I vaguely remember that this has some implications for the server-side calculations, but I still want to get this into the queue as at least a discussion topic.

[aesculus]

For charging waypoints, the relevant variables are:

"How long will I be here?" "How much energy will I leave with?" Before opening the Edit Waypoint dialog, the Waypoint Inspector answers both of those questions.

Not exactly. It tells you how much energy you will leave with but only how much time you need to wait to get that charge. If you have set a minimum stop time, that is not reflected in the charge time today, however that can be considered. In other words I could just keep charging up to 100% or the minimum time set by the user. This will probably be a dramatic change but worth considering.

I am clearly losing the debate about figuring out how long a charge should take place. To me, logically it was about how much energy you wanted to arrive at the next location. Given that, the app figures out exactly how much to charge prior. No fooling around with setting a larger number earlier and then jumping to the next stop to see if what you wanted worked out or not, and then back and forth until you got it right.

I liked the idea above about making an exception when there was a minimum stop time applied and you were charging. Today the app stops charging to meet the goal above, even though you are still waiting on something else. In the new scenario it would keep charging until it reach 100% or the minimum time expired. This makes sense to me, especially with the new idle charger fees.

[EVGrokker]

To guide this discussion, it would help to take a step back and answer the question "How is EVTO intended to be used?"

The app is called a Trip Optimizer. The user wants to go from point A to B along a route that supports their charging requirements. EVTO helps them plan that trip, optimized to take advantage of available charging resources along a recommended route.

Question: From your perspective, what happens when the user gets in the car and starts driving the planned route? Is EVTO's work largely complete at that moment?

I would say yes, EVTO's work is largely complete when the user beings driving the route. The car has perfect knowledge of the car's actual SoC. The car offers additional live data about SC availability. The car knows how fast you're actually driving and consuming energy. The car's navigation UI is built into the dash and center screen.

If you agree, then this helps define (and refine) the role of EVTO:

• EVTO is a pre-trip planning aid
• EVTO lets you plan a simple point A-B route, then shape it with waypoints
• EVTO lets you fiddle with complex "what if" scenarios, becoming a smart energy calculator. "How much extra pre-charging do I need to have 50 miles of local driving available when I arrive at my destination?"
• EVTO supports "what if" questions while en route. "What if we add a scenic stop as a waypoint?"

In summary, EVTO supports the driver's use of the in-car nav. EVTO is not a replacement for the in-car nav.

This brings us back around to the original topic of this issue, offering the ability to manipulate charging times and SoCs.

Usage scenarios:

• Simple: User plans Auto route from A to B.
• Moderate: User adds manual waypoints, non-SC charging stops, segmented trips.
• Complex: User tweaks stop times and SoC charging targets.

In simple use cases, user wants reassurance that they can get from A to B with sufficient energy.

In moderate use cases, user wants to shape the route, use non-SC charging or break the trip into segments.

In complex use cases, user wants to modify the charging times proposed by EVTO.

In all use cases, EVTO responds with a recommended route and predicts energy requirements and SoC en route.

As of today [v 1.2.0 (39)], the Simple and Moderate use cases are handled. The Complex use cases are partially handled with Local Driving reserves.

You could take the position that supporting complex use cases is outside the scope of this generation of the app, and should be deferred to a later release. If that's the case, I would suggest some changes to the Edit Waypoint dialog, removing the Arrival SoC slider. The only option would be reserving local driving energy in the Edit Segment Details dialog. Stop Time would only be used to inform the segment time line, not to manipulate departure SoC by adding extra charging time.

On the other hand, if you want to support complex use cases, my initial comments stand.

[aesculus]

I am still convinced the real issue is that they are accustomed to setting a charge level in all the other approaches vs a charge goal in EVTO. It's a foreign concept, and one I am not really interested in giving up just because it's not normal (problem with being both Scottish and German).

But the use case presented to have it continue the charge beyond what was required because the car was just sitting there anyway was justified, and one I did not think of. To that end I think adding a checkbox that says something like "Charge to fill time" or something like that could fix that problem. However it will probably wreck havoc with my algorithms just when I think they are working. :-(

[EVGrokker]

I would encourage you not to make any changes that could upset the algorithms until we agree on what the feature is and how we want it to work.

[aesculus]

Agree. This is almost a religious deal. :-)

[EVGrokker]

I reviewed open issues relating to this discussion. There are currently at least 5 other issues dealing with managing reserved energy in different scenarios:

• 308: Add the ability to change Origin SoC in the Edit Waypoint dialog

• 232: Rethinking reserved energy at the end of a segment

• 213: Adjusting stop time, departure SoC for manually added SCs

• 114: Minimum stop time

• 103: Override charging times

I'm keeping this afloat. I think it's important to clarify the design philosophy in such a way that we can communicate to users how they accomplish specific objectives:

• Reserving energy for local driving at destinations, either hinge or final.
• Differentiating between Arrival SoC for waypoints, and Departure SoCs for charging stops
• Interactively showing the effect of charging to a goal of x% SoC (how many minutes required) or for x minutes (predicted SoC upon departure)

This may not be a feature of the next release, but it's still important to know where we're headed.

[EVGrokker]

Addressed by #103.