Add a status dialog when EVTO is optimizing, calculating or refining

[EVGrokker]

This enhancement emerged from a discussion (issue #357) about the potential for user confusion when EVTO is performing various operations.

The proposal is to present a status dialog communicating progress through a series of (not more than) three descriptive steps. While an individual step is active, it has a rotating arrow 'spinner' next to it. When the step is complete, it receives a checkmark. For example, for a trip with Auto charger selection:

	Creating New Trip…
✓	Searching Routes (or something describing initial stages)
⟳	Predicting Energy Consumption (or something describing intermediate stages)
	Finalizing Route (or something describing final stages)

A trip with Manual charger selection would be a simpler sequence, but should use the same format dialog, with fewer steps, perhaps as simple as:

	Creating New Trip…
⟳	Searching Routes

I'd opt for simplicity, brevity, and reasonable accuracy in the step names 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. For the first implementation, there won't be a Cancel button.

I feel strongly that this should be introduced concurrently with resolution of issue #10, as we will have one good opportunity to reeducate existing users about how trip calculation and optimization works. So presumably that makes it a 1.2 feature.

[EVGrokker]

The same dialog format would be used anytime EVTO does a recalculation based on user input. Adding a waypoint, adding a segment, etc.. The specific dialog content for each scenario can be fine-tuned once the format is established with the big ones, New Trip: Auto and Optimize Routing.

• [ ] Creating New Trip (Auto) - all
• [ ] Creating New Trip (Manual) - all but 3
• [ ] Optimizing Routing - 3-5
• [ ] Adding Segment - all but 3
• [ ] Segmenting Trip - all but 1, 3
• [ ] Deleting Segment - all but 1, 3
• [ ] Adding Waypoint all but 3
• [ ] Editing Waypoint all but 3
• [ ] Deleting Waypoint 4-5
• [ ] Reordering Waypoints 4-5
• [ ] Modifying Departure Times 4-5
• [ ] Switching Segments after optimization 4-5
• [ ] Switching Segments no prior optimization - nothing

[aesculus]

Agree that this should be in V1.2.

[aesculus]

To make it accurate these are the things going on:

1. locating places and verifying addresses etc.
2. showing an initial route via Google maps (helps set the route order of required waypoints and get some background info needed for step 3)
3. picking chargers, adding/deleting (the server side of optimization)
4. obtaining forecasts for waypoints that either don't have weather yet or the times are no longer valid
5. calculating all the energy and weather impacts and figuring out accurate charge times etc.

Now this is probably too many steps to describe. Also you really could not stop the train except maybe between 2-3, and once you get to 3, you have to keep going otherwise you would have a partially changed trip and that would be a disaster. These steps must be done in order but not all steps apply in your checklist above.

I'll modified the checklist to show which steps are appropriate

[EVGrokker]

We'll abstract and combine the steps so that the user at least has a sense of where things are. And not more than three levels of abstraction :) For example:

• Scanning potential routes
• Evaluating energy requirements
• Finalizing itinerary

[aesculus]

Not sure if there is any need to call out 1 and 2 would come with it. Perhaps 1+2 would just be initializing or something.

3 is a big step and might take longer with V1.2. It is also the place where you can put on the brakes without applying it's results. After that you are committed. This is the only place a Cancel would work.

4-5 go hand in hand. It may turn out I don't need to do 4, but it's waypoint by waypoint. Again no way to stop that train. But 4 is still a data gathering event and does need web support so it could be different based on data need and comms speed. 5 is probably dependant on the number of waypoints in the route.

Oh I need to add a scenario about, switching segments.

[EVGrokker]

Please annotate each item on the list: App or Server operation? Is only step 3 server-side?

1. locating places and verifying addresses etc.
2. showing an initial route via Google maps (helps set the route order of required waypoints and get some background info needed for step 3)
3. picking chargers, adding/deleting (the server side of optimization)
4. obtaining forecasts for waypoints that either don't have weather yet or the times are no longer valid
5. calculating all the energy and weather impacts and figuring out accurate charge times etc.

[aesculus]

Is only step 3 server-side?

Only picking chargers is server side.

[EVGrokker]

From a performance perspective, would there be any advantages to moving additional functionality to the server side?

[aesculus]

Maybe, but not much I would think. The heavy lifting is already going on there. One thing that could help is not having to fetch weather for sc locations for everyone, but truthfully that is more of an impact on the weather server than my app or server. Since I don't use the weather until you need a SC or waypoint, the number per user is not that great.

I do cache the weather too when possible. So if you reoptimize, and a charger is still in the new result, I don't fetch new weather unless it falls out of the 48 hour window.

When you reoptimize I ghost all the trips SC's and then turn back on any that show up in the new results. I also check the weather date later to insure that it's still valid. This could be why a Calculation takes longer than before, for the same trip.

[EVGrokker]

Do all of the client-side calculations depend on connectivity? Are any of them pure number-crunching within the app? (1, 2, and 4 seem totally dependent upon connectivity. Step 5 seems the most likely candidate for pure local calculation)

[aesculus]

All of the number crunching is local, but you still need connectivity to show maps, get weather, supercharger lists, NREL data.

So basically the app is pretty dead without connectivity. If Google would allow us to cache the map for a route, we would be good. But alas they prohibit any caching except for a new service you may have seen for their own map app to cache your local area.

There is one option that we could create a static map of a trip and I think legally save that for display. But this is sort of a so what? I think you other idea of sending the trip to the car might be a better alternative to that.

[EVGrokker]

For the initial iteration of this dialog, here's what I think's important to accomplish:

• The dialog is up from the time the user passes control to EVTO until EVTO returns control to the user
• There's always an indication of the current step, so problem reports can make it clear "during step x, I observed y"
• The length of time on each step should be roughly equal, within reason and as feasible. I understand that sometimes you post server requests that have an indeterminate execution time, but I'm guessing you have a reasonable idea of how much time each phase takes when connectivity is adequate.
• There should be a time-out mechanism, so that if something takes unreasonably long, the dialog self-cancels and reports to the user "server failed to respond" or whatever's appropriate. What appears to the user to be a hung EVTO might in fact be a non-responsive server, and users should be aware of that so they don't blame EVTO.

For the first pass, I'd suggest these (same) three steps, but this is a total stab in the dark:

• Scanning potential routes
• Evaluating energy requirements
• Finalizing itinerary

I don't comprehend how switching segments fits into your detailed 5-step description. Do you start over for each segment? If so, I don't want to see the dialog start over for each segment, that would frustrate the user.

If there's a status bar, you might do a detail text for each step. For example, 'Scanning potential routes' might have a text detail of 'Segment 1', 'Segment 2', etc.

Ultimately, the bottom line is that until we see the behavior of the dialog we're not going to know how to fine-tune it. For now, use the detail text to call out whatever extra info you want, and we can refine that.

I'm excited about this feature.

[aesculus]

I don't comprehend how switching segments fits into your detailed 5-step description. Do you start over for each segment? If so, I don't want to see the dialog start over for each segment, that would frustrate the user.

If you use the Trip Inspector or touch one of the gray routes, you switch segments.

If you remember before I flag a segment as needing to be calculated if anything upstream changes (our white destination pin). But now instead of the user taking action, I am just doing a calculation on their behalf.

If there's a status bar, you might do a detail text for each step. For example, 'Scanning potential routes' might have a text detail of 'Segment 1', 'Segment 2', etc.

That's an idea.

[EVGrokker]

Ah, OK. I thought 'switching segments' meant the algorithm shifting focus from segment to segment.

However, to clarify: Once a trip (collection of segments) is calculated and optimized, the act of switching segments (user touches an inactive route segment, or uses the Trip Inspector to select a different route segment) should not trigger any sort of recalculation, right? The only time that happens is if the user has edited the active segment in a way that might affect the prediction.

Is that correct?

[EVGrokker]

New thinking on the difference between an optimization pass (with auto-selected chargers) and a calculation pass (without auto-selected chargers):

Future steps should be rendered in gray until they are active or completed. In the first table below, 'Finalizing' would grayed out, since it's not yet an active or completed step.

The difference in the Auto vs Manual dialogs should be the supercharger selection step.

There are two possible approaches to dialog steps. I'll call them Option 1 and Option 2.

---

Option 1: Auto gets an extra step compared to Manual.

New trip with Auto charger selection:

	Creating New Trip (Auto)…
✓	Selecting Superchargers
⟳	Calculating Energy Requirements
	Finalizing (grayed out)

A trip with Manual charger selection, or recalculating a route with already-selected automatic charging stops would be a simpler sequence, using the same format dialog, minus the first step:

New trip with Manual charger selection:

	Creating New Trip (Manual)…
✓	Calculating Energy Requirements
⟳	Finalizing

---

Option 2: Auto has a different step 1 than Manual. The dialog always has three steps. This would be useful in the future when 'Minimize Energy', 'Minimize Distance' and 'Minimize Stops' are active options, as the preferred route selection criteria would be visible.

New trip with Auto charger selection:

	Creating New Trip (Auto)…
✓	Selecting Superchargers
⟳	Calculating Energy Requirements
	Finalizing (grayed out)

A trip with Manual charger selection would display a different first step:

	Creating New Trip (Manual)…
✓	Selecting Minimal Time Routing
✓	Calculating Energy Requirements
⟳	Finalizing

For option 2, the dialog steps for other than New Trip (creating segments, editing waypoints, etc) would probably be reduced to two steps:

	Updating Trip…
✓	Calculating Energy Requirements
⟳	Finalizing

[EVGrokker]

I think my vote would be for Option 2.

[EVGrokker]

Proposed table of user-initiated events vs optimization/calculation dialog design. Steps labeled (1), when included, are mutually exclusive. Steps 2 & 3 are always included. The design follows the concept laid out above, with a symbol on the left indicating active or completed steps, and the text on the right displayed in gray for steps not yet started.

UI Event	(1) Selecting Superchargers	(1) Selecting [type of]* Routing	(2) Calculating Energy Requirements	(3) Finalizing
Main | Plan a Trip (Auto)	Y		Y	Y
Main | Plan a Trip (Manual)		Y	Y	Y
Main | Settings (any change)			Y	Y
Main | My Cars (any change)			Y	Y
Plan | New Trip (Auto)	Y		Y	Y
Plan | New Trip (Manual)		Y	Y	Y
Plan | Add Segment (Auto)	Y		Y	Y
Plan | Add Segment (Manual)		Y	Y	Y
Plan | Edit Segment Details (any change)			Y	Y
Plan | Add Waypoint		Y	Y	Y
Plan | Optimize Segment	Y		Y	Y
Plan | Refresh Segment			Y	Y
Plan | Reverse Route			Y	Y

• [type of] corresponds to the Settings | picker list for how the route is to be optimized. Currently, the only available selection is 'Minimize Travel Time'. The constructed dialog text for all planned picker selections would be:

  Settings selection	Dialog text
  Minimize Travel Time	Selecting Minimal Time Routing
  Minimize Energy	Selecting Minimal Energy Routing
  Minimize Distance	Selecting Minimal Distance Routing
  Minimize Stops	Selecting Minimal Stops Routing

[aesculus]

This would be useful in the future when 'Minimize Energy', 'Minimize Distance' and 'Minimize Stops' are active options, as the preferred route selection criteria would be visible.

Actually there is no difference in these from the devices visibility. Once it goes off to the server it does not have any more info until it gets a set of waypoints back in the optimal order.

Internally on the server, all but Minimum Stops uses the same algorithm, just different metrics. That one is a bit simpler (have not actually finished coding it yet but 90% of the way there). The others either minimize time, energy or distance. There is a simple calculation internally that does that. Actually the harder one is time, so I just don't complete a few calcs for the other two.

[EVGrokker]

Good to know it's not a major technical challenge. Swapping the description is a bit of eye candy that let the user know that you're using their Settings preference.

[aesculus]

(1) Selecting Minimal Time Routing

Not exactly sure what this might be. When a user first starts a trip (segment) or adds a waypoint, I engage Google to plot out a route (both Auto and Manual). So no matter what this happens.

Then if Auto is engaged I automatically engage the optimizer (same as a user who chose manual and then immediately afterward selected Optimize Route).

I need some stuff from the Google routing for the optimizer to work.

[EVGrokker]

I copied the list from the existing pick list in Settings (v 1.1.6). The current default (and only available choice) is Minimize Travel Time.

[EVGrokker]

I'll edit the table to make clear that there's a replaceable bit of text ('Selecting [type of] Routing') based on Settings.

[aesculus]

Yes. The others are waiting in the wings. Mostly do to testing and other priorities. Once V1.2 is out and solid, I was planning on going back to the other optimizer choices. All but min stops should just involved turning on the UI and then testing (hopefully), but Min Stops needs a different, but much simpler, model I hope. But after this last debacle I should hold my fingers on that comment. :-)

[aesculus]

I'll edit the table to make clear that there's a replaceable bit of text ('Selecting Routing') based on Settings.

But the second column actually always gets done. It's the first that is optional. Unless it's just a label.

[aesculus]

Oh, and the second column gets done twice when optimize is involved. First with the ICE mentality, and then with chargers.

[EVGrokker]

I understand that there's a disconnect between what's actually going on under the hood and what the dialog's displaying. I'm trying to strike a balance between what the user thinks should be happening, the relative amount of time each dialog step takes, and a reasonably accurate description of what's going on.

From a user's perspective, invoking 'Auto' means, "hey EVTO, you figure out everything. I just want to get there." So when they see "Selecting Superchargers", that makes sense as the first step. With Auto, route selection would be considered part of step 1, an integral part of selecting the superchargers.

When they invoke 'Manual', it makes sense that the first thing they see is route selection. They're planning to add their own charging stops (or use Optimize later).

Does that make sense?

[EVGrokker]

Oh, and the second column gets done twice when optimize is involved. First with the ICE mentality, and then with chargers.

This is a perfect example of an implementation detail that I'm hoping to hide with the dialog. There's no need for users to know that.

[aesculus]

But this is why I sort of favor four statuses, and just gray out the picking charger one (first status) when there is no optimization in the mix. Much easier for me programming wise. I have certain events (routines) that are taking place and those key ones can announce their state when encountered. Little or no logic on my part.

When the app starts at the second step (no charger selection), it would show the first step as grayed out with a checkmark. From here on it's the same for each path.

[EVGrokker]

If a four-step dialog is easier for the initial implementation, you should definitely start there. We need to see how it looks and feels before finalizing the design.

When you're skipping the first step for manual trip planning, don't put a check mark on it - that suggests something was done. I'd leave the left column blank, and gray out the right side text as you propose.

I would point out that in the table above, four of the dialogs are two-step dialogs. How will you handle those initially?

[aesculus]

I would point out that in the table above, four of the dialogs are two-step dialogs. How will you handle those initially?

When only a the last two are relevant, why not just gray the other two out too?

So the dialog could be:

• Selecting chargers
• Choosing routing
• Calculating energy
• Finalizing

BTW we need to keep those status levels small because of the phone size. Text plus icon will eat up space quickly.

[EVGrokker]

As far as reducing textual content, I can envision a couple of space-reducing strategies:

Verbose	Selecting Superchargers	Selecting [type of] Routing	Calculating Energy Requirements	Finalizing
Terse	Superchargers	Routing	Energy	Finalizing
Iconic	[supercharger pin]	[zig-zag line]	[calculator]	∑ [sigma]

[aesculus]

OK. On the icons. Lets see what comes about on the size thing. Remember our old friend the iPhone SE I still have a ToDo open on. Only 320 px wide.

[EVGrokker]

Here's another drastic approach for the smaller screens.

Rather than using a two-column dialog, you could use color and checkmarks to indicate progress. The unaccomplished steps would be in gray with an ellipsis prefix. Active steps would be in black with an ellipsis prefix. Completed steps would have a checkmark prefix. In the table below, Superchargers and Routing are complete and in black, Energy is the active step in black, and Finalizing is yet to be started (in gray).

Creating New Trip (Auto)…

✓ Superchargers

✓ Routing

…Energy

…Finalizing

Of course, in your "always show all four steps" approach, skipped steps would not have checkmark prefixes.

Again, this approach is really only for screens too small to support the fancier/prettier versions we've been discussing.

[aesculus]

I'll probably start simple and build up, at least while we only have one model.

Lets see what today brings and then we can play with look and feel over the week as we test (hopefully) the underlying functionality of V1.2.

[EVGrokker]

v 1.2.0 (13) The new progress dialog looks excellent. A couple of observations:

• The vertical alignment of the icon and its associated text is off. It looks like they're aligned at the baseline, but it would look better if they're aligned at their midpoints.
• Is it possible to make the icons smaller? The text size is fine (on an iPhone), but it's overwhelmed by the icons.
• In terms of the progress bar, it seems that about ~75% of it takes place during Selecting Superchargers, then everything else is crammed into the remainder. I'd rather see a roughly equivalent amount of space taken by each step, even if the rate of progress for that step varies. This gives the user a chance to appreciate what's going on under the hood.
• When calculating a New Trip, the dialog header is 'Updating Trip'. I'm not opposed to that header when using the Optimize Routing from the menu for an already existing route, but I think it should be 'Creating New Trip…' for new trips.

[EVGrokker]

v 1.2.0 (13) When using Manual routing, no progress dialog is displayed. I realize that this is typically a much quicker operation, but depending on network connectivity it could take longer than expected. I'd like to see the dialog displayed with the appropriate steps.

Same comment applies when adding a waypoint.

[EVGrokker]

v 1.2.0 (13) (Minor) dialog text comments: You have four stages in the full version of the dialog:

1. Selecting Superchargers
2. Obtaining Routing
3. Calculating Energy
4. Finalizing Route

With respect to 2, I don't like 'Obtaining' because it suggests that you're borrowing or externally sourcing something (I know, you are, but stay with me for a moment.) I'd prefer Optimizing Route, because that's the app's value added. It's also the menu item that may have been used to initiate this dialog.

With respect to 4, I think I'd just go with Finalizing. I don't like 'Route' showing up twice in the dialog, and 'Finalizing' is vague enough to cover any housekeeping cleanup that you're doing prior to displaying the final route.

[EVGrokker]

Another thought on the progress bar… it might be easier to let the progress bar go to 100% for each of the tasks than to try to balance the ratios.

[aesculus]

I think that would be confusing it it went to 100% multiple times.

The issue of balancing is troublesome. Because two things are going on:

• One is the amount of time it takes for certain processes
• The ability to stop the process.

Since the server is probably where the bulk of time is taking place now, and that is also the process you can cancel, it sort of needs to be the length it is. I could fake a split in there but not sure what that would do. It would be a fake split.

I don't want to add time the other processes just so they even out the times because that would make the app perform badly.

What I have done, and might be able to improve a bit, is to make the progress go faster for the non server portion. You may have noticed this. Each 1 pt takes a second on the server side but only 1/10 second on the later stages. I might be able to play with this a bit. What might be happening is that the server may need to get it's fill before it moves on to the faster rate. I will try some experiments.

Like I said this first attack is pretty rough.

[EVGrokker]

The first pass looks good actually, this is definitely fine-tuning to prettify the wait time.

I definitely wasn't intending to propose padding the time spent, faster is always better. I was talking more about shifting the boundaries between steps.

The reason this occurred to me (using multiple 100% passes) is that in some scenarios, you're not going to be running all the steps, like when calculating a route and energy without superchargers. In that case, what do you do? Start at 25% because you're skipping the first step? That's one approach. Using multiple 100% passes solves that problem because the appearance is that each step goes from 0 to 100. I think it's worth a try just to see how it feels, after you've done the fine-tuning you have in mind.

[aesculus]

With respect to 2, I don't like 'Obtaining' because it suggests that you're borrowing or externally sourcing something (I know, you are, but stay with me for a moment.) I'd prefer Optimizing Route, because that's the app's value added. It's also the menu item that may have been used to initiate this dialog.

With respect to 4, I think I'd just go with Finalizing. I don't like 'Route' showing up twice in the dialog, and 'Finalizing' is vague enough to cover any housekeeping cleanup that you're doing prior to displaying the final route.

Changed in V1.2 (14)

[aesculus]

When using Manual routing, no progress dialog is displayed.

Fixed in V1.2 (14)

[aesculus]

The vertical alignment of the icon and its associated text is off. It looks like they're aligned at the baseline, but it would look better if they're aligned at their midpoints. Is it possible to make the icons smaller? The text size is fine (on an iPhone), but it's overwhelmed by the icons.

Fixed in V1.2 (14)

[aesculus]

When calculating a New Trip, the dialog header is 'Updating Trip'. I'm not opposed to that header when using the Optimize Routing from the menu for an already existing route, but I think it should be 'Creating New Trip…' for new trips.

Can we come up with a single header for both use cases? I am worried the icon will be wrong if I have two different titles and don't want to spend the time right now working on that.

[EVGrokker]

Can we come up with a single header for both use cases? I am worried the icon will be wrong if I have two different titles and don't want to spend the time right now working on that.

If you want a single header that covers all invocations, I'd suggest 'Optimizing Trip'. That's a reasonable all-purpose header, regardless of how the dialog was invoked.

[EVGrokker]

Observation about progress dialogs:

Creating a New Trip, Fremont CA - Denver CO, Manual:

• I see the dialog once, skipping the supercharger step, as expected.

Creating a New Trip, Fremont CA - Denver CO, Auto:

• I see the dialog sequence twice, unexpected.

Can you help me understand why the progress dialog is seen twice during Auto route calculation?

I suspect that you are calculating some aspects of the trip in multiple passes, which causes a second pass through the sections of code displaying the dialog. What's going on under the hood is not an issue, but I think we need to present the dialog once, from start to finish, regardless of Auto or Manual.

Perhaps some conditional code that displays a different progress sequence, depending on Auto vs Manual?

[aesculus]

I have not delved into this yet. It could mean a logic problem that is causing two passes, or maybe the dialog is happening twice for some reason. This is a single segment trip correct?

EVGrokker mailto:notifications@github.com Tuesday, May 16, 2017 12:23 PM

Observation about progress dialogs:

Creating a New Trip, Fremont CA - Denver CO, Manual:

• I see the dialog once, skipping the supercharger step, as expected.

Creating a New Trip, Fremont CA - Denver CO, Auto:

• I see the dialog sequence twice, unexpected.

Can you help me understand why the progress dialog is seen twice during Auto route calculation?

I suspect that you are calculating some aspects of the trip in multiple passes, which causes a second pass through the sections of code displaying the dialog. What's going on under the hood is not an issue, but I think we need to present the dialog once, from start to finish, regardless of Auto or Manual.

Perhaps some conditional code that displays a different progress sequence, depending on Auto vs Manual?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/aesculus/EVTO-App-Feedback/issues/363#issuecomment-301888638, or mute the thread https://github.com/notifications/unsubscribe-auth/AARS5KvBh-SckD4BxkNOnROKgdYWgE-4ks5r6fevgaJpZM4NOt3J.

-- Chris Couper

[EVGrokker]

Yes, it's a single segment trip.

Let me clarify that the trip ultimately computes with acceptable results. The time each dialog is displayed is roughly equal, and steps are being executed during each pass. If I recall, the auto charging stops are not displayed until the dialog finally closes.

[aesculus]

My guess is that I am doing something to reset the dialog, but I will check it out tomorrow.

I have to take off in few minutes and probably won't get the first issue resolved today. Not sure why it is not failing. I jacked it to 25% and it is still happy too. Needed to get it to 30% before it added the charger.

EVGrokker wrote:

Let me clarify that the trip ultimately computes with acceptable results. The time each dialog is displayed is roughly equal, and steps are being executed during each pass. If I recall, the auto charging stops are not displayed until the dialog finally closes.

-- Chris Couper

[aesculus]

This dialog will appear twice during a new trip with Auto set. The first time is when it creates the route (similar to what happens if you change or add a waypoint but don't optimize). Then after the basic route is complete and this dialog ends, the auto optimization kicks in and redisplays the dialog, this time with the first item on. Then it will complete the entire sequence and close.