aesculus / EVTO-App-Feedback

A project to track bugs and ideas for the EVTO App
MIT License
1 stars 0 forks source link

Create Estimated Range Scale on SoC Chart #457

Closed aesculus closed 7 years ago

aesculus commented 7 years ago

Some users would like a way to see where they stack up with regard to estimated range instead of purely using SoC percent. If there was a scale of estimated range on the right side of the SoC chart, this would help in that regard. Then of course it will beg the question if it is still a SoC chart. :-)

EVGrokker commented 7 years ago

I like this idea a lot. This enhancement should be combined with #344, which would change the appearance as well.

aesculus commented 7 years ago

Moved from #344

So the graph will be labelled SoC on the left Y axis, and Range on the right Y axis?

Each car would have a different right side Y axis range, depending on model, battery size, condition, SA, PF, and the general weather and altitude conditions affecting that trip, right?

Shouldn't the right side just be rated miles that the user specified at 90% but scaled to 100%. Those other factors are trip dependant. But certainly weather cannot be part of that because it is waypoint dependant.

That would be a very nice feature.

aesculus commented 7 years ago

While this was a great idea, the space required on the phone renders the chart too small.

Suggestions?

image

aesculus commented 7 years ago

For the phone I thought eliminating the axis labels and moving the legend into the white space below was better, so I hacked the chart. I thought you could cover the axis labels in the help file and once the user had the grasp of what they were, they would be OK with it.

image

EVGrokker commented 7 years ago

A couple of ideas:

EVGrokker commented 7 years ago

v 1.2.0 (40)

I like the changes. The chart is definitely more informative with the addition of the right-side range legend.

However, there's a spacing issue. In the sample above, you used negative -100 kms as the x-axis min value, which gives the graph some breathing space on the left. And it appears that you either rounded up to 700, or added a pad to make sure there was breathing space on the right. It might make sense to pad both sides by maybe 15% or so to ensure symmetrical breathing space. Ideally, I'd rather not see the min label as a negative number, but I realize that might be out of your control. I'd rather see a negative number than no breathing space.

Also, the left-side Y axis labels are unnecessarily fussy. As noted earlier, I'd always use 20% increments, then round the range numbers on the right side wherever they fall.

soc_chart

aesculus commented 7 years ago

The left Y axis (Soc) is constant, always 0 to 100. I'd suggest splitting it with 4 subdivisions instead of three, so they fall at 20, 40, 60 and 80%.

I will try. Seems to me the plugin only lets me put in the min/max and not the number of divisions. I am not sure why you were getting three decimal places. I will also put back the padding. Having the chart start at the edge looks untidy. However when Do this it will force the negative number as that is how the plugin works. I might be able to hack that out though.

If you're concerned about ambiguity in the SoC (left) axis, you could append '%' to the numbers.

I can add that but it will make the chart are less wide. Is it worth the chart area for what is/should be a obvious label?

You could apply a light color-coding to to the chart with horizontal bands of color matching the battery SoC. For example, 0-5 would be red, 5-20 would be yellow, and 20-100 would be green. If you like this, I'd suggest a fairly transparent use of the color - not a solid, like the chart line. If you can control the rendering, I'd also put it behind the grid lines.

Interesting. I took a look at the chart plugin and it does not have this capability natively. It would require a large hack to pull it off and I am not sure it would be worth it. I also think it might look ugly with competing elements even if I made the background very transparent.

For the Range (right) axis, I'd suggest appending 'mi' or 'km' to clarify units.

Again this is going to take away the chart area. See the samples above. Appending % or mi is just about as bad as the vertical text label

If it's not possible to append both '%' on the left and 'mi' on the right, I'd prioritize the right side label with distance units.

I don't understand this statement

EVGrokker commented 7 years ago

If it's not possible to append both '%' on the left and 'mi' on the right, I'd prioritize the right side label with distance units.

I don't understand this statement

I was anticipating your concern about the extra width required to add the units. If you felt that there was room enough to add units on one axis, but not both, I was suggesting that the distance units (mi/km) on the right vertical axis were more valuable/informative than the % units on the left.

If you don't want to give up the real estate for the units, I think the chart is fine without any units. If you can force 20-40-60-80-100 on the left, the numbers on the right will look familiar as range numbers, and we can call that out in the help as well.

aesculus commented 7 years ago

If you don't want to give up the real estate for the units, I think the chart is fine without any units. If you can force 20-40-60-80-100 on the left, the numbers on the right will look familiar as range numbers, and we can call that out in the help as well.

I think this is the best compromise given the small real-estate we are working with on phones.

EVGrokker commented 7 years ago

Here's a heretical thought.

You can nuke the left-side numbers. We don't need 0-100% labels on the left side, because:

The right side numbers are very useful, because they offer another perspective on energy resources that's not available anywhere else in the app - "How much range do I have left from this point?" It can vary by payload, SA, PF and conditions. One could almost argue for a relabeling of the tab to 'Energy'.

aesculus commented 7 years ago

Here is what I have done:

image

On the consumption chart the same but you can also touch a juncture in the chart to see the efficiency at that point too.

image

aesculus commented 7 years ago

Timeout. I think I found a way to force the SoC chart to break down by more logical steps

Forget it. It has a mind of it's own. First time was good and second time it formatted with strange spacing. :-(

Strike that. I found another setting that can force the 25% steps, or anything else for that matter.

image

EVGrokker commented 7 years ago

These improvements all look excellent. If you can force the subdivisions at 20% I think that's even better, because 20% and 80% are important thresholds.

EVGrokker commented 7 years ago

Oh well. All of the spacing improvements look good. I'd encourage you to try with no units on the left if that's possible to see how it reads.

aesculus commented 7 years ago

It's got some fetish with the range numbers when I force 20% jumps. Makes no sense to me.

image

EVGrokker commented 7 years ago

Do you have the option of providing a background image?

aesculus commented 7 years ago

Here is no ticks at all. So far I like the 25% one best

image

aesculus commented 7 years ago

Do you have the option of providing a background image?

For what purpose? What type of image and where? Just in the chart area?

Be careful because this chart is dynamic based on the users device size and orientation, and of course data.

EVGrokker commented 7 years ago

A couple of observations on the latest sample image:

With respect to the question about the background image, I was thinking that you could have a canned image with the colored areas, but you'd have to have multiple versions for different devices. If the framework gives you access to the graph canvas, you could render bands to it, but that's probably more effort than it's worth for the eye candy effect.

aesculus commented 7 years ago

Both x and y scales are now distance. The bottom x scale is trip distance, the right-side y scale is remaining (range) distance. That's interesting to ponder. I had to think for a minute when I observed that both axes have 228 as their max value, until I realized it was a coincidence.

Yeah. Funny huh?

With the left-side % scale numbers removed, do you have enough room to append the [mi/km] label on both axes label numbers? Would that screw up the 'Start' hack (which looks great)?

Seems to be a waste of space. Everyone would assume its km or miles based on settings and their world view.

Do you have room to append 'Range' to the tab title? For example 'SoC • Range' or Soc + Range'?

What about a singular term Energy?

What are your thoughts about eliminating the left-side y numbers? It's certainly a clean look, if unorthodox. I think I like it.

As I posted above I think it looks naked.

Another version of the same concept would be to put the range numbers on the left side in the traditional position with the right-side y axis unlabeled. But I like them on the right, because the graph line progresses toward the range axis, so your eye moves in the same direction as the graph line and the labeled axis.

I agree that they should be on the right.

The nodes are touchable to get individual SoC, which is a nice feature for those feeling adrift without an SoC reference.

Yep, if they knew it was there. Do you know you can do the same in the car? That's what inspired me and again the look was intended to clone what the car does.

With respect to the question about the background image, I was thinking that you could have a canned image with the colored areas, but you'd have to have multiple versions for different devices. If the framework gives you access to the graph canvas, you could render bands to it, but that's probably more effort than it's worth for the eye candy effect.

I suspected that. Right now I favor the simple approach so I can get back to solving functional problems. Later, we can revisit this idea.

aesculus commented 7 years ago

BTW you can touch anywhere along the line to see the SoC %, not just at the waypoints.

Oh and I guess it still is a SoC, just that there are two ways of viewing it:

aesculus commented 7 years ago

This is now locked for V1.2 (41)

EVGrokker commented 7 years ago

This looks really nice. One minor nit with layout. In the image below, note that the first stop's first initial is obscured (masked) within the graph area. Interestingly, the last stop's initials are not - they overlay the edge of the graph area, extending into the axis labeling area.

Also, note that the node circles for both the first and last stops are partially obscured.

I know that real estate is tight on this screen, but if you can squeeze a bit more pad in to at least make sure that the node circles are unobstructed, that would look better.

socoverlap

EVGrokker commented 7 years ago

More nit-picky enhancements opportunities:

aesculus commented 7 years ago

When touching a stop node, in addition to the SoC, could you also display the full stop name?

As mentioned before this has nothing to do with the stop. You can touch anywhere on the line to see the SoC at that distance of the trip.

I'll try to look into another solution for that later.

Let's try this in V1.2 (42)

image

aesculus commented 7 years ago

I was able to use 20% increments and get rid of the right axes grid line lust. Which do you like better the one above or this one with 20%?

Note on the one above if you switch charts then you get a grid line for each Y axis label. That is shown on the Elder's Corner image above with double grid lines.

image

EVGrokker commented 7 years ago

I prefer 20% increments. I think the image immediately above looks good.

I discovered that if a waypoint charges to 100% (or close) the waypoint initials are clipped at the top:

clippedwaypoint

EVGrokker commented 7 years ago

Note on the one above if you switch charts then you get a grid line for each Y axis label. That is shown on the Elder's Corner image above with double grid lines.

Not sure I understand. By 'switch charts' do you mean swiping among multiple segments in the same trip? Or switching between SoC and Consumption? How do you cause double grid lines to appear?

aesculus commented 7 years ago

Going between the two charts. It will change the values in the Y axis. The new version fixes the left axis at the 20% levels and then shows no grid lines for the right y axis. Otherwise you get a grid line for each axis label like this:

image

aesculus commented 7 years ago

We're going to have to live with the 100% overlap thing. If I try to change it then the right side will no longer show the correct rated range (note it can be off by 1mi as it is).

EVGrokker commented 7 years ago

An alternate layout would be to place the waypoint initials to the side of the node instead of above (if that's an available option). The origin label would be placed to the right of the node, the destination label to the left of the node so everything fits inside the graph area.

If that's not an option, I'd rather live with the range numbers being close and deal with the missing label on the 100% stops.

I think I can anticipate that the label placement (if it's variable) has to be the same position for all labels, so this idea is probably a non-starter.

aesculus commented 7 years ago

When touching a stop node, in addition to the SoC, could you also display the full stop name?

In V1.2 (42) if you touch the coded waypoint ID you get:

image

aesculus commented 7 years ago

The recharge lines would be very difficult to do. You would not believe what I had to do to show the different colors. Maybe someday, but not right now.

EVGrokker commented 7 years ago

Closing this issue, since the original objective of adding a second Y axis value is complete.