Trip Summary Update to Match New Segment Summary Layout

[aesculus]

This item will create the same basic layout as the Segment Summary but swap Stops or the Battery icon.

This will include #223

[aesculus]

Here is a draft of the dialog. Still need to work on the summary section at the bottom.

[EVGrokker]

This looks good. I like the addition of the segment count in the segment data.

[EVGrokker]

One comment about spacing in the segment data lines: With the addition of the segment count, you now have 5 elements displayed. I'd like to see the distance element centered, with the other items spread out as much as possible to give them breathing space. The distance crowds the car icon, which makes it unclear which number is associated with the car.

[aesculus]

Now we have a dilemma to solve. Too much info and not enough space.

What do you want to do about the last row in the summary section?

[EVGrokker]

First reaction is to drop the total number of stops in the last line of the summary.

[aesculus]

That would be my vote too. But of course say goodbye to your columnar icons. :-)

[aesculus]

And anything else you want before I whack the stop count and make everything bigger?

[EVGrokker]

Sigh. I know. The fact that the summary icons are separated by a couple lines of text softens the blow.

[EVGrokker]

I believe you use lower case 'am' and 'pm' elsewhere.

[EVGrokker]

What about time zone display for other localities? Would it make more sense to use 'GMT -6' style?

[aesculus]

What about time zone display for other localities?

Damn. I knew you would spot those timezones. The app converts to the correct timezone based on the locale. So if the trip started in NY it would say EDT.

And now you are going to ask for those to be on every date in the app. :-)

[aesculus]

I believe you use lower case 'am' and 'pm' elsewhere.

Everywhere but the Status dialog where I cheat there too. A bit more programming is in order.

[EVGrokker]

Only if you want to add them, I'm not that concerned about domestic times. I'm just concerned that international users will complain if the time zone representation is US-centric.

[aesculus]

They are supposed to be global.

[EVGrokker]

If there are internationally recognized abbreviations for all time zones, then go with them. As long as users recognize them as valid in their locale it should be a non-issue. As far as segment ETAs and ETDs, I think it's like you said earlier, it's the same way that airlines quote them, always presumed to be local.

[aesculus]

Here you go:

[EVGrokker]

v 1.2.0 (31)

The per-segment pin count is incorrect for the following trip:

This is a feedback report for EVTO. Please handle promptly. Report Type: Bug Report Comments: Car Data: X90D, Charger: 48, Wheels: 20, Tires: 0, Pano: 0, 5 Seat: 1, Rear CC: 0, Bat Life: 94 Device Info: iPhone; CPU iPhone OS 10_3_2 like Mac OS X Settings: Reserve SoC:20, Default SoC: 90, Region: 0, Units: 0 Version: 1.2.0 (31) IAP: Pro:1, Sub:1 Location: Unknown Trip: Bend Supercharger, [dxnu5x795brkuu660g7avs]

Segment 1 has two stops (not including Origin and Destination) (displays as 11) Segment 2 has four stops (displays as 8) Segment 3 has two stops (displays as 3)

Is the intent that the pin count does not include Origin and Destination? That would be my assumption.

[aesculus]

When was this trip made? The count is correct. If you look at the trip you will see blue paths where there should be gray ones. The trip has tons of auto charger waypoints like it did not get rid of ones after an optimization and just kept on adding them.

[EVGrokker]

I made it this morning.

[EVGrokker]

I think I did Seattle-Fess Parker (Santa Barbara), then added Bend OR as a waypoint, optimized, then added Petaluma as a waypoint, optimized

[aesculus]

Ouch. OK, I better do it myself to see why it made some many fake waypoints.

[aesculus]

OK. I just tried this with V1.2 (33). Here is what I found:

• Seattle to SB and optimize came up with 10 waypoints
• Adding Bend, segmenting kept the same number of waypoints but different route
• If you looked at the Trip Inspector it said 11 and 6 (WTF)? This was while I was on the new segment 2
• The routing looked screwy too. Wrapping back on itself.
• If I switched to segment 1, the status dialog came up and rerouted segment 1 appropriately
• Now segment 1 waypoint count was 3
• Selecting segment 2 again brought up the status dialog, but only for an energy calc, because segment 1 had changed.
• Segment 2 waypoint count remained at 6
• I did not do the third segment as I knew now what was going to happen

So the question is: I wait to redo routes until the user goes there. but that means the trip inspector and the gray route is probably going to be wrong. What to do about this?

[aesculus]

One option.

• Flag the non active trips that have not been rerouted so they will not show their paths.
• On the trip inspector put some sort of notice about needing to go to the segment to refresh it if it needs rerouting.
• If it does not need rerouting the waypoint count will be correct, but the rest of the stats will be wrong until the user visits those legs.

So I wonder if I just need to do all of the updating in the background to prevent this? If so the app will take a pretty big performance hit, but it would be more accurate. Something to ponder.

[aesculus]

Some thoughts:

• I think that if the user optimizes I should automatically force the current segment back to the starting segment. This will help a bit
• I can try to experiment with doing the subsequent segment calcs in the background. Right now it works on the current trip only, and of course updates the dialog. This could be nearly impossible to do as I suspect that the current trip ID is embedded into everyone of the calcs but it's worth a look at.
• In the absence of doing it in the background perhaps some sort of guidance or warning might be adequate but if they go out of order, it's not going to be pretty.

[EVGrokker]

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.

[EVGrokker]

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.

[EVGrokker]

I don't agree with how you're counting stops.

Assume a simple trip of 25 miles to a nearby town with no charging stops and no waypoints. IMHO, that's a total of 0 stops.

When you book an airline trip, a non-stop flight is understood to start at the origin and arrive at the destination without any stops along the way.

If no stops are required for charging, or leg-stretching, or shopping, and you just want to get from point A to B, I think that should be displayed as 0 stops.

[aesculus]

So you don't want to count the destination as a stop? That's easy to do.

[EVGrokker]

I don't think the origin or destination should be included in the stop count. The count should be the number of planned stops between the origin and destination, without including either the origin or the destination.

[aesculus]

OK. I will have to hunt these down in the app. I will remove all final destinations in the count.

[aesculus]

The only place I could find stops was in the Compare Trips and Trip Summary. If you see any others let me know. This has been updated in V1.2 (35).

[EVGrokker]

v 1.2.0 (36)

This Trip Summary doesn't look right.

Note that the elapsed time for segment 1 is 7:28, segment 2 is 5:06. Yet the trip summary at the bottom indicates an elapsed time of 7:05. Seems like it should be 12:34?

[EVGrokker]

Question: Does it make sense to include the elapsed time in the trip summary? We already have the departure and arrival times, and once the trip spans more than a day you don't think about the elapsed time in hours. Cumulative driving time does make sense - "I drove 9 and a half hours over 2 days".

[aesculus]

I agree that the elapsed trip time does not make a lot of sense when it's a MST with overnight stops, but it could have some value. Let me see why it's not working first before we kill it.

[EVGrokker]

Maybe switch the display format to days and hours (and minutes?) for Trip summaries. That would be useful, but require more space if you include minutes.

[stopwatch] 2d 4h 39m

Less than 24 hours (single segment, or multiple segments within 24 hours) would revert to the current format.

[aesculus]

I think I can squeeze in the minutes. Good point.

[aesculus]

I found the (a?) bug in how round trip second segments times were created. They were basically done in the past. Well actually they got the same start date and time as the first segment. :-(

This has been corrected in V1.2 (37) with issue #428 . This was causing wrong dates and elapsed times for those types of trips. Regular segmentation and continuations were and should be OK but will need to monitor start date/times to be sure. Note that the start dates and times on segments > 0 will be the arrival time of the prior segment. This can be changed by the user in Edit Segment Details.

[aesculus]

I decided to just make the elapsed time the same no matter how many days, So it's always days:hours:minutes

[EVGrokker]

I don't think that using colons to separate days works. It would be convenient, but very unconventional. Users would read that as '1 hour, 5 minutes, 04 seconds.'

I suppose you could do '1d 05:04', which would be a compromise and save some space, since you wouldn't need a leading 0.

[aesculus]

I can get rid of the ':' but adding the 'd' pushes me out against the edges with too little margin IMHO.

[EVGrokker]

How about using a single digit when possible (no leading '0') with a single space between the day and hours:min. You can also eliminate leading zeros in the hours. That's cryptic, but at least it's parsable.

[stopwatch] 1 5:04

[aesculus]

Here is what I did:

• got rid of the forced leading 0's on days and hours.
• replaced the first ':' with a 'd '

Now you will probably object to the extra space between the elapsed time and the distance. That is variable. And because I now don't have the forced '0's the space will change depending on the needs of those. I also had to hack the auto width spacing of that row because the possible length of the row exceeded the space allotted to an element (ie I had to move into the margins). And when we have 2 digit days and 2 digit hours, there will be very little space between elapsed time and distance.

[EVGrokker]

Not complaining about the variable space. I like the extra space since it's numbers up against numbers. How about using the smaller/lighter font for 'd', the same as used for Start, End, PDT, kWh?

[EVGrokker]

What would you think about including average trip speed in the third line of the summary, along with energy and efficiency? This would match the Trip Summary suggestion in #400.

[aesculus]

It's not hard to add the average speed. I wonder what it would do from a user's perspective? Would this help the acceptance of the concept of an average speed vs max speed?

[EVGrokker]

I definitely think it would help emphasize the underlying complexity of the energy calcs, given the varying speed limits along the route. And it would help sell why you can't drive 75 all the time.

[aesculus]

OK. Think about how you want it labeled. Just saying 72.1 mph will be dangerous. They need to know it's an average

[EVGrokker]

Please don't add a decimal point, just round it off like you do in the waypoint inspector.

[EVGrokker]

And label it 'mph' or 'kph'

[aesculus]

OK. No decimal point. No average? Can I send the emails to you? :-)

And lastly what position (1,2 or 3)?