Segment Summary: Proposed revisions to layout

[EVGrokker]

v 1.2.0 (23)

Now that you have the excellent split battery design implemented, I'd like to propose a streamlined appearance for the Segment Summary dialog focusing on the key highlights per leg.

• The battery icon has been added to each leg
• Seattle and Ellensburg have been modified with the proposed layout
• User can touch any of the waypoints to open the waypoint inspector for more details.

[aesculus]

Is the distance cumulative like the time?

[EVGrokker]

I would propose that both time and distance are treated the same in this display, cumulative.

[aesculus]

Here is a mock-up for your review:

[EVGrokker]

Oops. clearly I didn't make my concept clear in my mockup. Sorry.

I've reviewed and revised the mockup, attached below.

Comments:

• The summary details are now at the top, and bolded. This means that you can always see the segment summary, even if there are more legs that can fit in a single screen. I know that differs from the car display, but I think it's a more concise presentation that matches the user's expectations of what a summary should be: top-down detail. If you feel strongly that the summary should be at the bottom, that's OK.
• Charging times, elapsed times and mileage are in columns, so that you can quickly scan down the column to see the progression.
• Charge times are per leg, elapsed time and mileages are cumulative toward the totals.
• Battery icons shows split arrival/departure SoC per leg.
• The departure charge time is not shown, and the zap icon is shown in gray, meaning that it's assumed the user has charged to their default SoC.
• The arrival charge time is not shown, and the zap icon is shown in gray, meaning that the user is on their own to charge.

[aesculus]

I was being a bit short in my response. I just wanted to have you check the new summary layout, which you did by giving me a better sample. Hence the reason the biggest numbers were in there. Plus you added more info now (gray chargers).

I can probably go either way with the summary panel at the top or bottom. Since its an accumulation of the data above I thought it made logical (and functional) sense to have it at the bottom. It was sort of intended to match the car's navigation panel. Interestingly in that case the summary is always present at the bottom along with the destination. Anything that cannot be seen is faded (ie the second to last list item) to show the user there is more to be scrolled. With some trickery I could probably do that too.

[EVGrokker]

I have a bias towards putting the summary at the top. When I invoke 'Segment Summary', I expect to see a concise overview of the segment, followed by a concise summary of the legs. One plus of this approach is that each leg should take less vertical space, meaning more legs can fit on a small screen. For lists of legs longer than the available screen space, I'd rather have the summary at the top. I know this doesn't match the car but they've got nearly infinite screen space. If you thought you could display the summary at the bottom in a static panel and scroll the leg contents, I suppose that would be OK too but that seems like extra work.

[aesculus]

OK. While were are discussing this I wonder if Segment Summary is really the best term? It could also be named "Segments Waypoints", or better "List of Waypoints". What is the primary purpose?

The capabilities of the list are:

• Gain access to a waypoint (ie scroll map and show WP Inspector)
• See waypoint info in context (ie how much charge at each stop relative to each other)
• Spot anomalies (ie WPs that are red/yellow)
• See running info (time and distance)
• See segment summary info

One plus of this approach is that each leg should take less vertical space, meaning more legs can fit on a small screen.

It's actually only fractionally smaller if you look at my sample above. :-)

If you thought you could display the summary at the bottom in a static panel and scroll the leg contents, I suppose that would be OK too but that seems like extra work.

Probably lots of extra work and I wonder if the subtleness of the opaque list item would go unnoticed. Also the car is scrolling automatically as you drive so that makes sense. You rarely need to see what's hidden. In the summary list that is not the case.

[EVGrokker]

Good idea to review functionality and objectives.

Here's my vision of how Segment Summary (I'll call it that for now) fits into the big picture. I'll use the 5 Ws + H of story-telling to make sure we cover our bases:

Who: The car described in My Cars and Settings What: New Trip When: Defaults from Settings, or Edit Segment Details Where: Google Maps display of calculated route Why: Only the user knows :) How: Segment Summary, Waypoint Inspector

Segment Summary should summarize all of the information about how we're going to get from point A to point B, including ETD, ETA, energy reqs, planned stops, auto stops, predicted energy and arrival/departure SoC.

It's not a Trip Summary, since it only focuses on the active segment. So the word Segment needs to be used. I would argue that it should function as a one-stop summary, with access to drill down deeper. For example, touching a waypoint gives you a deeper view with the Waypoint Inspector.

By adding this level of detail and functionality to Segment Summary, we're only one step away from not needing the Segment Details panel. [gasp].

Consider that the only unique information contained in Segment Details is the wonky per-waypoint data like elevation change, efficiency, average speed, etc. That detail could be exposed through a popup from the waypoint listing.

Thoughts?

[aesculus]

I guess my biggest concern is that for those trips that are only a single segment, it sounds redundant or confusing to some users. In their world it's a trip. But so be it. They can adopt a new lingo. They made the transition to an EV after all. :-)

I wonder how many people hate the app because it's different? This is one case. Another is the concept of Min Arrival SoC. So many want to charge more at a previous charger just so they will have more when they arrive at a waypoint. The Min Arrival SoC does that better. It forces the app to figure out how much more the previous charge should be so you arrive within your comfort zone. But since every other planner uses the former paradigm, they are frustrated. I must have pointed that out 20 or more times to users and rarely (never?) have I gotten a 'ok, I understand now' back.

By adding this level of detail and functionality to Segment Summary, we're only one step away from not needing the Segment Details panel. [gasp].

Consider that the only unique information contained in Segment Details is the wonky per-waypoint data like elevation change, efficiency, average speed, etc. That detail could be exposed through a popup from the waypoint listing.

I think there is a lot more going on here than that but ...

But it certainly will remove the need to go to the Segment Details panel for many.

[EVGrokker]

I wasn't intending to dismiss the Segment Details dialog as unimportant, I was noting that Segment Summary has grown more expansive in the info it conveys, thus overlapping with the Segment Details. I'm sure I glossed over some of the details. My goal is always going to be getting as much functionality out of the fewest number of interfaces.

[aesculus]

Agreed. I suspect most will never need to go there. And the 3rd level is the CSV export in Segment Details for the truly obsessed.

[aesculus]

I just noticed the new summary does not have drive time. Can we use the car icon and put the drive time in? If yes what row do you want it in? Last one if it fits?

[EVGrokker]

To clarify, 'Drive Time' means time actually on the road, in the car driving, versus elapsed clock time (door to door), which includes charging?

If that's correct, and you feel that it's important to include, I'd put it on the last line of the summary section to the right of the total mileage. Note that the other three items in that line are vertically aligned in columns with content below, and you have space available above the waypoint ordering arrows.

[aesculus]

I will put it on the last line, last item.

I did not notice the vertical alignment with the waypoints. I think that goes right out the window as soon as you have different times etc and the bold vs normal font in the waypoint list below. I do see now that the two icons are aligned. My goal is to keep that alignment in the list items, but not necessary for the summary to align. And now it won't. :-)

It took me a while to create the table layout that supported the waypoints. This is why I showed you the sample of the largest numbers that could be in there. You have just enough space for what you have given the worst possible conditions. I had to drop the font size down a notch too, just to make sure everything fit.

[EVGrokker]

Tables are clearly the way to go. I'm fine with the smaller font. I think it's going to look very nice.

[aesculus]

This was a PITA. I am still not done as I have to worry about 2 conditions still:

• What happens if the arrival SoC is less than 0
• The case where there is reserved energy for destination travel

[EVGrokker]

Maybe a PITA, but gorgeous.

I was going to write an issue for reserved energy tomorrow proposing using a green striped section for reserved energy above the solid green section of arrival SoC.

Wow that looks good.

[EVGrokker]

Arrival SoC < 0: Solid red battery, interior label with deficit, e.g. -17%

[aesculus]

Egads. I have not done the destination yet either ...

[aesculus]

Arrival SoC < 0: Solid red battery, interior label with deficit, e.g. -17%

I was heading that way but then it did not reflect the required charge. Of course all of this is moot anyway. The red pushpin gives it away.

Do you like your idea or this better?

[EVGrokker]

Yours looks fine.

[EVGrokker]

There may be a case to be made that if arrival SoC <0 that subsequent stats should be blanked (-:--) since the trip is untenable.

[aesculus]

There may be a case to be made that if arrival SoC <0 that subsequent stats should be blanked (-:--) since the trip is untenable.

Well maybe not. It's still valid from that point on. If they added a charger in the middle (since I just whacked one to force the issue) it would work great.

[aesculus]

OK. Now off to make the destination fall in line and then to reserve energy that goes with the destination.

I was going to write an issue for reserved energy tomorrow proposing using a green striped section for reserved energy above the solid green section of arrival SoC.

It's blue today to stand out.

[EVGrokker]

Ok, but seeing a red charger is not necessarily a showstopper, since the arrival SoC could be 0-5%. Arriving with less than 0% is not recoverable without making some adjustments, which would then require recomputing the trip. Probably an academic debate at this point, but it seems like SoCs <0 should have visible breaks in the summary.

[EVGrokker]

It's blue today to stand out.

Maybe solid gold for consistency with the charging gains?

[aesculus]

Maybe solid gold for consistency with the charging gains?

I am not sure what it has to do with charging. It's the energy a user sets aside for local travel at a destination. If they don't use it, they lose it. It is not credited past that location.

The trouble with solid gold is that it is too close to yellow, the middle charge value less than 20%.

[EVGrokker]

I had a great argument for gold, but this gives me an even better argument for green.

In order to have reserve energy available for destination driving, the user needs to both declare the requirement and precharge earlier to bank the reserve.

There are three possible arrival conditions of the 'base charge' with reserve energy - green, yellow and red. In all cases, the precharged reserve allocation provided them with enough of a cushion to arrive at the destination, even if they didn't get there with as much as they hoped for. So they're happy.

Once they arrive, their thinking about the reserve energy switches to "how much battery do I have left for local driving?" In other words, upon arrival, they're no longer thinking about a split charge, it's just how much is left. If they have enough, they're good to go. If they don't have enough, they'll have to go source a local charger, or perhaps plan a local trip with EVTO. But that's outside the scope of the destination SoC.

So my proposal would be to split the destination SoC when reserve energy has been allocated, using whatever color the base should be (red/yellow/green), with reserve shown in solid green. Obviously you want a clearly visible divider, especially when the base is also green. To be clear, this would only be used for Destinations.

My goal here is to minimize the number of colors we're using to be able to tell a consistent story about how to read them. 'Green in the tank' above a divider pretty clearly represents reserved energy. And, if EVTO predicted close to correct, the green reserve will match what they're seeing in the car on the dash.

Now you might make the case that if they only reserved a few miles of local driving and the base SoC is yellow or red, the combined total might be less than 20% and should be shown in some other color, but I'd say that's an edge case, and representing the reserve in green has unmistakeable meaning.

[aesculus]

I follow you all along until you want green for both the regular arrival charge and the reserve for destination. I think it needs to be a different color. Whether they use it or not is not the issue. I treat it as throw away. If they don't use it all then they can adjust the outbound origin SOC accordingly.

I want it to be very clear to the user that that energy is not allocated for any other use but local travel. The blue color does that IMHO.

[aesculus]

This is what I ended up with in 1.2 (25). I also left in the text about how much distance was reserved for local travel in addition to my lovely blue color. :-)

[aesculus]

Oh. And this brings up another question:

What to do about the origin side of a charging hinge? I never account for charge times on destinations or origins. Do we just mention that in the help?

[EVGrokker]

1) This dialog is looking awesome. Nice work. 2) As far as the Origin (or Destination) side of a charging hinge, that's why the charger is grayed out. Basically, the explanation will be "The app assumes that you begin a segment charged to your Departure SoC." The gray zap icon means "charging required, but required time is outside of EVTO's scope." So it's the app's job to help you get from point A to B, but we assume that the user begins the segment with a charged battery. 3) Fussy nit-picks: In your screen capture, the Destination zap shows a time of 0:00, but the Origin zap shows nothing. They should be the same. Because it's on the user to manage this, and we don't know the actual charging time, I'd propose '*:**' 4) I like the appended text when there is reserved energy at the destination.

[EVGrokker]

One more nitpick: Are you able to adjust the spacing of the bottom row of the summary section (total charge time, elapsed time, total miles, drive time) so that the zap icon, stopwatch and miles align with the columns below? This would push drive time over to the right slightly, but it looks like there's room.

[aesculus]

Then it would be heavily skewed to the right and look worse IMHO. I noted before you had them lined up when there was no drive time, but with drive time added it went on its own path so to speak. I don't think it looks that bad, and the darker background announces it's a different animal than those that follow.

Maybe spreading it out is actually a better idea. Reinforce that it is not the same as below?

[aesculus]

Fussy nit-picks: In your screen capture, the Destination zap shows a time of 0:00, but the Origin zap shows nothing. They should be the same. Because it's on the user to manage this, and we don't know the actual charging time, I'd propose '*:**'

Think about the case where there is no charger vs where there is a charger but it's at a hinge. Today the app does not include charge time when there is a charger at a hinge (at least it's not supposed to), it just starts the next segment at the default (or user set) SoC.

So should we bother differentiating when there is a charger vs no charger?

[EVGrokker]

I don't think it's worth differentiating. Destination charging happens outside of EVTO.

But I do think it's worth including the dummy zap icons for symmetry and as a reminder that they're responsible for starting the trip with their MSoC and recharging at their destination before beginning a new segment or trip.

[aesculus]

they're responsible for starting the trip with their MSoC and recharging at their destination before beginning a new segment

Sort of. If the hinge does not have a charger the server is supposed to calculate the best approach and departure charging strategy for them. This is the crux of some of my server issues and why the optimization takes much longer when hinges don't have chargers. They have to be treated as waypoints.

[EVGrokker]

Hmmm. I guess I need to spend more time testing this feature.

[EVGrokker]

Then it would be heavily skewed to the right and look worse IMHO. I noted before you had them lined up when there was no drive time, but with drive time added it went on its own path so to speak. I don't think it looks that bad, and the darker background announces it's a different animal than those that follow.

What about moving drive time up to the middle line?

[aesculus]

Hmmm. I guess I need to spend more time testing this feature.

Not until I have it working right.

What about moving drive time up to the middle line?

You really want that aligned don't you. :-)

I could do that but really I like it the way it is. The bold text also sets it apart from the individual ones below that are in a small font etc.

[EVGrokker]

This comment addresses both the layout of the Segment Summary dialog and the Trip Segments dialog, shown below side by side.

1. The layout of these two dialogs should be the same.
2. With respect to the summary data, it's below the header in the Segment Summary dialog, and it's the footer in the Trip Segments dialog. We need to choose which layout is best. If we put it at the top, I think there needs to be a <hr/> element separating the title text from the summary data. If we put it at the bottom, the separation is already established by the formatting of the final item. At this moment, I'm leaning toward placing the summary data at the bottom, which would help me get over the fact that the columns are not aligned.
3. The Segment Summary data needs a bit more breathing space. I think this could be accomplished by reducing the size of the zap, the stopwatch and the car icons (both in the summary and the waypoints). In particular I'm looking at the crowding between the elapsed time icon and the '115.7 kWh'.
4. The '?' buttons should come down a few pixels. My eye wants to see them vertically centered with the title text.
5. The Trip Segments summary data should be formatted similarly to the Segments Summary data. The first line is already formatted correctly (it's unique to the Trip Segments dialog). The second line should be formatted the same. The third line should be formatted the same, using the appropriate icons, with the deletion of the overall mileage, since that's already reported in the first line.

[aesculus]

At this moment, I'm leaning toward placing the summary data at the bottom, which would help me get over the fact that the columns are not aligned.

It was at the bottom until just recently when you asked me to move it to the top. :-)

The Segment Summary data needs a bit more breathing space. I think this could be accomplished by reducing the size of the zap, the stopwatch and the car icons (both in the summary and the waypoints).

How about all the same height as the battery?

The '?' buttons should come down a few pixels. My eye wants to see them vertically centered with the title text.

Sure.

The Trip Segments summary data should be formatted similarly to the Segments Summary data.

I have not attacked the Trip Summary dialog yet until we settle on the Segment Summary dialog. This thread is an example of why. :-)

[EVGrokker]

Yes, it's a back and forth process. I need to see how the implementation looks, and you need to provide feedback on the proposed concepts.

Matching the icon height to the battery height sounds good.

At this point, I think placing the summary details at the bottom makes the most sense. There will be a UI issue when the number of waypoints in a segment exceeds the available screen space, because the design right now doesn't allow scrolling without also interpreting the drag as a touch. But we'll burn that bridge when we come to it. :)

[aesculus]

OK. Give me a few hours to get you a revised version of the Segment Summary. I am trying to break the nut on the server issue.

[aesculus]

How is this?

[aesculus]

BTW would you like the dialog shoved over to the left (like the space above to the tab bar) with just a few pixels of gap or like it is?

[EVGrokker]

If I'm understanding correctly, I think that the way it's shown in the image above is good, as it looks centered in the available space between the left edge and the map buttons.

[aesculus]

At least on an iPhone :-)

[EVGrokker]

v 1.2.0 (30)

A couple of comments about the dialog:

• The charging time field (following the gray zap) for Origin and Destination need to be 1) the same, and 2) indicative of the fact that we don't know what they are. I'm still in favor of either nothing (like the origin in the image below) or '*:**' in both fields, and in gray like the zap.
• The spacing in the bottom segment summary data looks crowded. Now that there's distance between the individual waypoint columns and the final summary data line, I'm less bothered by the fact that they're not aligned. So, now I'd propose spreading the individual components on the bottom line out to let them breathe. Also, maybe increase the vertical space between each of the lines in the summary data.

[aesculus]

If you want them the same, then I favor a blank or a grayed out 0:00.

The '*:**' looks like an error in the program.