Closed aesculus closed 7 years ago
This is essentially already available in that you can set the minimum arrival SOC for the downstream waypoint. If you adjust that SOC it will effect the charge time on the upstream charger.
Somehow this would have to override the current model that sets the charging time based on arrival and departure SOC. The times are determined by the charging rate (not linear with some chargers).
If the user set a charge time what would happen if the time was not sufficient to get to the next stop? Also the optimizer does not deal with time as much as energy consumed.
This seemingly simple request if fraught with issues, not to mention how confusing it might be for some.
From a beta user
In my case, I'm thinking that when I hit Harris Ranch, I know I'm going to be there for awhile...in my example above I was contemplating eating lunch at Harris Ranch, so I figure I'd be there at least an hour. So if I only needed 30 minutes (or whatever) to make the next charger, I'd get 30 extra minutes of charging, which might allow me to skip the next charger, charge for less time at a subsequent charger, drive faster, or whatever. I'm trying to capture what that extra charging time means. (We actually had this situation when we did this road trip in early April.)
I'm not sure I understand the question.
Is this a question about how to utilize the Minimum Stop Time at a charging stop to accumulate more energy than required? (Pin the charger, then edit Min Stop Time).
Aquire more energy than needed because you are waiting anyway. I could probably charge to 100% or whatever the min stop time will give you.
How about this option on the Edit Waypoint dialog? It would be grayed out unless the user has selected a charger and advanced the Stop Time past 0.
Essentially it would keep charging until the time ran out or the car reached 100%.
This discussion falls into the app philosophy category stabbed at in #456.
I want to take a step back to a larger perspective, and in the process, restate some suggestions I've previously made.
For the sake of discussion, let's assume that the primary objective of the app is preflight planning. In other words, a user is sitting on their couch, or in a diner booth, sketching out a possible trip from A to B. Further, let's put ourselves in the shoes of the 80% users, not the 20% EVBs, quants and tweakers.
After inputting an Origin and Destination, they Auto calculate an optimized route, which proposes a couple of auto charging stops. One of these stops puts them at a supercharger location with a nearby restaurant at approximately lunchtime, with a proposed 20 min charging time. User is contemplating the proposed route and stops, and thinks, "Hmm, I could stretch this stop, have lunch next door, and get a pain-free top-off supercharge that might come in useful later in the day."
Based on my forum readings, Tesla drivers in this real-life, real-time situation would intentionally set a higher SoC target in the car than needed to get to the next stop, giving them extra time to enjoy an unhurried meal without being nagged by Tesla that their charging is complete, and please get the hell out of the charging stall. They finish their meal, and wherever the SoC is when they return to the car, they accept it, because it's higher than it would have been had they simply been charging to the minimal necessary SoC to reach the next waypoint.
So how do we model this behavior in the app? While looking at the stop, they would be thinking "I'll bump my stop time from the minimum of 20 mins to an hour." Their expectation would be that the subsequent recalc would show them the incremental SoC they'd get for the extra charge time. I propose that they'd be curious to see the SoC deltas. "What if I only stopped for 45 minutes instead of 60 minutes?"
What I'm having a hard time envisioning is a scenario in which, after declaring that they wanted to spend a longer time at the stop than the minimum required, they wouldn't want to use that time for overcharging. In other words, when would the user not check that box that you've mocked up?
The only scenario I can think of is that they arrive at a supercharger location planning to have lunch, there's a waiting line for the charging stalls, they finally get their spot, and they feel so guilt-ridden that they do a minimum charge to let someone else have the charging stall as quickly as possible. But I also think that they likelihood of them anticipating and modeling that possible scenario in the planning stages is very low, unless they know from experience that the location is always too busy. And in that case, they might try to skip that stop.
My vision of the 80% user is one who wants a planning tool that does a reasonable job of modeling trips. In this proposed scenario, I think the dialog behavior that would most conform to their expectations and provide the most delight would be:
Apologies for the overly-long restatement of my position, but I think the design and behavior of this dialog exposes the philosophy of the app, and it's important to get it right.
Question: In what scenario would you imagine the user would not check the 'Keep charging while stopped' box?
So the net is:
Whenever a user sets the Minimum Stop Time at a charging stop, charge to meet the goals of the optimizer or fill up the charging time with the wait time, whichever is larger?
Yes, that's an accurate summary of the influence of the Stop Time slider as I see its role at automatic charging stops.
OK. That is easy to do in the manual mode. Will have to see what happens in Auto mode. I suspect it should work OK with a bit of tweaking on the server.
Yes, that's an accurate summary of the influence of the Stop Time slider as I see its role at automatic charging stops.
Whoops. Your statement just got me confused. Auto stops don't have any stop time or other things a user can tweak. Only manual waypoints or auto waypoints converted to required. Is that what you meant?
You're correct. Manually added charging stops, or automatic stops that have been converted to required stops.
OK. You owe me a year of my life back from the panic attack. :-)
Oops. Sorry about that. :-|
Should this ability to auto increase charge time to fill wait time be a setting or just do it regardless?
Question: In what scenario would you imagine the user would not check the 'Keep charging while stopped' box?
I could see it where a user wanted to do a quick charge for the car, disconnect, and then go do something else.
Are you asking if there should be a checkbox in Settings (or somewhere), giving the user control of whether adding Stop Time at a manual charger means that they want to use the additional time for charging?
If that's the question, I'd say just do it regardless, no checkbox.
Suppose that user is charging for 20 minutes at a Fred Meyer SC, and then wants to go inside to shop for another 20 minutes, but they pull out of the charging stall and into a conventional parking spot.
How do they tell EVTO?
My proposal would be 20 mins charging stop, then add a waypoint for Fred Meyer, even though it might only be 50 yards away. I think the 80% use case is they want the extra charging time.
Is that what you meant?
EVGrokker wrote:
Are you asking if there should be a checkbox in Settings (or somewhere), giving the user control of whether adding Stop Time at a manual charger means that they want to use the additional time for charging?
That's it.
If that's the question, I'd say just do it regardless, no checkbox.
Suppose that user is charging for 20 minutes at a Fred Meyer SC, and then wants to go inside to shop for another 20 minutes, but they pull out of the charging stall and into a conventional parking spot. How do they tell EVTO?
The checkbox you wanted me to remove. :-)
My proposal would be 20 mins charging stop, then add a waypoint for Fred Meyer, even though it might only be 50 yards away. I think the 80% use case is they want the extra charging time.
Is that what you meant?
Yes.
Seems like forcing them to create another waypoint is harder and not as intuitive as just selecting a checkbox.
I think the checkbox will be a challenge to label, difficult to explain, and rarely, if ever used. I'd vote against it.
But if you want it, yours is the deciding vote.
so "Keep charging while stopped" wasn't clear?
I am just afraid of forcing this behavior without any way to turn it off.
I don't find it clear.
I'd suggest:
Additional Stop Time increases charging time
I'd like fit it on one line. :-(
Exactly my point. It's not an easy concept to convey tersely.
Adding Stop Time adds charging time
(no period)
Still too fat.
What about;
Now it turns out there is a related issue to this:
The Roadster has some quirky limit to how much it can charge. It can never go above 94% (Range Charge) and the Standard Charge is capped at 83%.
So what is needed is a radio that is in exactly the same place as this one that would toggle Standard vs Range Charge when using a Roadster. Issue #478
Before we go on, I want to be certain we're in agreement about the eventual behavior of the Edit Waypoint dialog. Are you intending to implement any of the linked slider behavior I described earlier?
So what is needed is a radio that is in exactly the same place as this one that would toggle Standard vs Range Charge when using a Roadster. Issue #478
So these radio buttons would replace the checkbox we're trying to name when a Roadster is the active car?
Before we go on, I want to be certain we're in agreement about the eventual behavior of the Edit Waypoint dialog. Are you intending to implement any of the linked slider behavior I described earlier?
Not yet. Those are BIG changes and will require a lot of thought and planning as well as potentially big changes in the app.
So these radio buttons would replace the checkbox we're trying to name when a Roadster is the active car?
Yes
So Roadster drivers don't get the option of adding stop time to charging time?
Good point. I guess it needs to be in addition too rather than in place of. Things are getting crowded.
Clearly the Roadster radio buttons are important for Roadster users. No debate there. I'm not sure they belong on this screen - in fact, I'd argue they belong in the Energy tab of My Cars as a more persistent characteristic rather than localized to waypoints. That might require making that tab control group draggable for the Roadster.
Not only is it getting crowded, it's getting cluttered and confusing. 'Continue charging while stopped' isn't next to the slider whose behavior it's referencing. I'm not suggesting you place it between the sliders, that would be worse.
Have you considered that this checkbox is irrelevant unless they have a charger selected? Are you planning to hide it or simply disable it for non-charging waypoints?
Have you considered that these controls also need to be considered for the Edit Waypoint dialog?
Consider this. User has converted an auto charging waypoint to a required stop. I'm looking at one right now, where EVTO shows charging from 15% to 60%, requiring 24 minutes.
I open the Edit Waypoint dialog, and Stop Time shows 0 mins, not the 24 mins I might expect.
So the meaning of the slider, as currently implemented, is additional stop time, above and beyond the allocated charging time of 24 minutes, which is not shown in the Edit Waypoint dialog. But only when it's a charging stop, not when it's a regular waypoint.
So if you relabel that slider to Added Stop Time for charging stops, at least the gap between the 0 mins displayed and the 24 mins stop time already committed is less of a problem.
This all feels very loose and sloppy. I'll keep thinking about it.
Clearly the Roadster radio buttons are important for Roadster users. No debate there. I'm not sure they belong on this screen - in fact, I'd argue they belong in the Energy tab of My Cars as a more persistent characteristic rather than localized to waypoints. That might require making that tab control group draggable for the Roadster.
Nope. It's a charging thing that they elect to do at each stop. Weird car the Roadster.
Have you considered that this checkbox is irrelevant unless they have a charger selected? Are you planning to hide it or simply disable it for non-charging waypoints?
Yes it would only show up for charging waypoints. And it would gray out unless the Stop Time was advanced off of 0. I cannot pre guess the charge times since that could vary widely.
Stop Time shows 0 mins, not the 24 mins I might expect.
This is why it used to be labeled Minimum Stop time. In other words the app can stop as long as it wants, but the user says you MUST stop at least x amount of time. Now we are debating what the car should do with that time beyond the required time to charge to the next destination.
This all feels very loose and sloppy. I'll keep thinking about it.
Can you think about letting me go back to Minimum Stop Time as before? :-)
Can you think about letting me go back to Minimum Stop Time as before? :-)
It depends on the context:
In order to have some measure of consistency, the label should change depending on charger selection.
No. It's always the minimum stop time.
We could change it to Required Stop Time if this makes more sense.
How about this:
I can live with Required Stop Time as a compromise between charging and non-charging stops.
The label for the checkbox does not sit well. I'm still trying to come up with something that distinguishes the already committed charging portion of the stop from this additional portion that's not bad-tasting word soup.
Are you really bound to the idea that having this as an option is something lots of user will find useful, as opposed to simply presuming the additional charging time spent at a charger is in fact for charging?
I can live with Required Stop Time as a compromise between charging and non-charging stops.
Works for me too.
Are you really bound to the idea that having this as an option is something lots of user will find useful, as opposed to simply presuming the additional charging time spent at a charger is in fact for charging?
My gut tells me this is required. Personally I am with you. If they are going to be at a charging stop and select a larger time, then one would expect that they would keep the car plugged in.
But both you and I came up with scenarios that this was not the case. You have an alternative that says create another waypoint at the same location. That sort of works but it cannot be at the exact same location so I wonder how many people would think of pressing and holding on the map to create a waypoint a few feet way so they did not cover each other up?
This is why I think we need the checkbox.
Let me give you an alternate version of my Fred Meyer scenario.
Let's say that they're at a charging stop with a nearby store of interest, say a Starbucks. They only "need" 15 minutes of charging, but they know from experience to allow 20 minutes total stop time to walk over to Starbucks, wait in line, get their latte, and come back to the car. So they set a Required Stop Time of 20 minutes, and EVTO happily credits them the extra five minutes of charging time above and beyond the recommended 15 mins.
Remember, all of these scenarios are occurring in the user's head when they're planning their trip, not in realtime.
So suppose when the day of the trip comes, for some reason they decide to move their car after the allocated 15 minutes of charging, then go to SBUX for the latte after charging. EVTO didn't account for this change of plans, because the user made a spur of the moment decision. The only downside is that their ETA is now a few minutes off. But at that point, who cares? Even if they were tracking EVTO against their real progress, they'd make an allowance because they called an audible to change the itinerary slightly. And there's virtually no impact on energy consumption. No harm, no foul.
I think the checkbox is an unnecessary complication, and that we can easily provide recommended approaches to using the settings in this dialog to accomplish various real-life scenarios during the planning stages of a trip, where everything is shiny, smooth-edged and lines up neatly, unlike real life.
If the torches and pitchforks come out, blame it on me.
A few minutes extra is NBD. You have reduced the wait time to 120 minutes which does help in this situation. It used to be set for 4 hours if I remember, which was intended to let them go off to a museum or such without having to create an additional waypoint. Not intended really for a quick Starbucks run.
BTW a few hours can make a big difference in weather too. That can dramatically affect range. This is one reason I get a lot of hate mail for no Speed Adjust (which is interesting because in most cases they actually end up taking longer from waypoint to waypoint because of larger energy consumption and longer charge times).
I would even be so inclined to bring it back to 4 hours in 15 min increments. 15 minutes of extra charge is really not meaningful except at the bottom end of the SoC at a supercharger. Not the scenarios we are talking about here. In all other cases, even at a supercharger, 15 minutes buys you next to nothing.
I am willing to make a compromise here: Give me my 4 hours back in 15 minute increments and I will drop the checkbox in favor of forcing the charge to either 100% or the max time set. If we take grief for it later on then we can engage plan B, the checkbox.
Deal.
OK. What else do I have to sell today? :-)
I'm willing to trade something for #453.
I'm closing this, even though there were other variations introduced. At the point in time that you're willing to reconsider using Departure SoC for charging stops, we can open a new issue.
Question: For the Edit Waypoint dialog, would it be possible to modify the behavior for (manual or pinned) charging stops to show the allocated charge time on the Required Stop Time slider?
For example, let's say that we have a trip calling for a 15 minute stop at a supercharger. Upon opening Edit Waypoint, the slider would be set to the already allocated 15 minutes, and couldn't be set lower than that. But the user could adjust it higher.
If the allocated charging time doesn't fall on a 15-minute boundary, it would be displayed at its (approximately) correct slider position, but it could only be adjusted upwards or returned to the original minimum.
Currently, the process for figuring out how much time is already allocated is tedious:
The only way that a Required Charging Time will have an effect is if it's larger than the already allocated charge time. We can make this a lot easier for the user by letting them see what's already allocated.
If you do this, you'd also need to remember the initially allocated charge time so that if the user opens the editor at a later time to reduce the Required Stop Time back to its original value, they could do so.
After thinking about this, I think I can make it much simpler. As proposed above:
I realized that once the charging stop was pinned, the user is now in control of that charging stop. They can delete it if they want. So if they go in bump the time up, that simply adds to the charging time, as intended. But they could also reduce the charging time, or even set it to 0, which would be effectively the same as removing it. If they want to recover the EVTO-allocated charging time, they can Optimize.
This behavior would then be identical to editing a regular waypoint (non-charging) stop's time. What You See Is What You Get.
Of course, a negative adjustment may result in an unreachable Destination, but that's no different than the user deleting a charging stop.
Think of this scenario:
I do like you ask and put the 'current' time that the app determined was needed in the dialog. Let's say it is 45 minutes. You look at the Waypoint dialog and see 45 minutes and are happy with that. You wanted to charge for at least 40 minutes and you are good to go (you think).
Later you make a change to the trip (time, weather, routing, whatever...). The app recalculates the required charge time and now this stop only needs 20 minutes. Guess what. If you go look at the Waypoint dialog you will now see 20 minutes. WTF? Where did your 45 minutes go?
The number placed in the dialog MUST be fixed. It cannot be assumed to be a transient value. The user either wants to stop for time or not and as we agreed, if they are stopped now, they are going to charge for that amount of time up to 100%. If they want a fixed charging time (Required) they should put that in.
There is one possible means that might work in this scenario:
Instead of overriding the actual value, I create/modify a label (gray hint) to display the current charge time. This way there is a visual clue on what it currently is set at but it's only a clue and the user could tell and know it's not what is set. This would keep them from bouncing around as you noted above.
There is not much room to do this but if we are crafty we might be able to squeeze it in on the line the label is on. Not sure if I can override the label or not but I am willing to look into it.
I think I'm visualizing what you're proposing.
If you can come up with something that can be interpreted/explained as an indicator of the currently allocated charge level for the stop, that could work. I would propose that you could truncate the label back to 'Stop Time' (no mins) to give you plenty of space. With a visual tick mark I could explain it, and 'Required' would no longer be required. :)
Something like this (hacked from an earlier image in this thread)? :
Or this:
There is actually a double headed one of these sliders but the problem is when the predicted charger is larger than the users required charge the values would have to flip. That would be confusing IMHO
Can you create a different appearance for one head vs the other?
Another idea: Suppose you created a field with the allocation charge time next to the slider, to display it numerically? Or appended the allocated charging time to the slider label?
For example:
Stop Time (25 mins allocated)
Or appended the allocated charging time to the slider label?
That is what I was going to do. If we did some funky graphic or something to show that the value was the currently allocated time.
Can you create a different appearance for one head vs the other?
I can probably hack the color and increase the radius enough to make one a circle.
Probably a Pro feature