This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Bug in x-axis spacing of all activity graphs in the connect app

I noticed that the amount of time between each dot on the x-axis varies in all the activity graphs (heart rate, cadence, pace, and elevation). In the screenshot below you can see that the time from the first to the second point is 2:09, while the time from the second to the first point is 2:48, to the fourth 2:54, and so on. This is rather serious as it interferes with visual presentation of the data and can be misleading. For example, you can see that the white line (which marks my intervals) appears to be longer for the first sprint than for the three following sprints. This is not true, all the intervals were 4 min, and this visual artefact comes from the nonlinearity in the x-axis which also deranges the steepness of the incline/decline in heart rate so that it is not visually comparable between intervals.

Another comment on the x-axis is that it would be less visually noisy if you settled on even numbers. So in the screenshot, you could use 0, 2, 4, 6... or 0, 3, 6, 9...(with or without :00 for the seconds).

On the y-axis, the distance is even, but it appears that the rounding approach causes the numbers to look a bit unintuitive. This is minor but it could be nicer to but the first dot at an even number, say 40 in the attached screenshot and then proceed in even increment (so 40, 80, 120 and so on).

One last potential issue is that while heart rate, cadence, and elevation all use the same ticklabels on the x-axis, the pace graph uses different times (slightly higher). This could be an issue if the data is not rescaled when overlayed on the other axis since it might be artificially offset, but that's something that is hard to tell in the graph since the offset would be small.

Thanks for reading, I posted this as a bug to Garmin but did not get any response. I hope it will be possible to fix these bugs soon, I am really enjoying my garmin watch and the app so far and this would make it even better!

Screenshot:

0 trux over 5 years ago

This is not really a bug, but rather the way the data is presented on Garmin Connect Mobile (GCM). Unless you use the "Every Second Recording" mode, the logging is irregular, depending on diverse conditions (changes of direction, elevation, HR, etc.). Unlike GCW (Garmin Connect Web), GCM simply plots all the keypoints into the graph, without egalizing the x-axis over the duration or over the distance. You need to look at the x-axis labels that help you evaluating the data properly.

If you need a more precise graphs with the x-axis egalized either over the duration or over the distance, you have to use Garmin Connect Web - at the graphs there, you can choose whether you want to have a linear time or linear distance on the X-axis. This option is not currently available on GCM.

Alternatively, you can use the "Every Second Recording" mode - the X-axis on GCM should be then linear over the time, too. Note: this mode can drain your battery and memory space slightly faster than the default "Smart Recording".

0 Joel over 5 years ago in reply to trux

trux said:
Unlike GCW (Garmin Connect Web), GCM simply plots all the keypoints into the graph, without egalizing the x-axis over the duration or over the distance.

I would classify this behavior as a bug (or intentionally misleading if the app is designed to display data like this). The display of the data should be independent of the logging interval, and the mobile app should do either the same as the web version, or at least spread out the points at unequal length if they are recorded at unequal time intervals. Having unequal time intervals at equal distance along the x-axis severely limits the ability to correctly interpret the plot.

However, I don't think this is a logging problem. As can be seen by the granularity in the heart rate curve, there are clearly enough data points to choose them so that they would be spread out equally timewise along the x-axis. It is incredibly difficult to mentally adjust for the current irregular offset and a fix in the app would be very simple.

0 trux over 5 years ago in reply to Joel

Joel said:
I would classify this behavior as a bug

Of course, you can classify it as you like, but it won't change anything on its behaviour. GCM simply currently shows the data in this way. If you want graphs with a linear time axis, you'll need to use the graphs on GC Web, or trying whether the Every Second Recording helps.

0 Joel over 5 years ago in reply to trux

trux said:
Of course, you can classify it as you like, but it won't change anything on its behaviour. GCM simply currently shows the data in this way.

Naturally my classification won't magically change how the app works, I don't get your point here. Thanks for letting me know that there is no current way of changing this so that I just haven't missed an option somewhere.

I detailed my reasoning to why I think the plot is not fulfilling its desired purpose of communicating data clearly to its readers and suggested a more suitable behavior for this purpose (which you helpfully pointed out is already the default web behavior). By bringing up reasons for why the current behavior is subpar, I hope to get an idea if others share my view point or if there are benefits with the current state of things that I have overlooked. If many app users agree on one side of an issue, hopefully someone at Garmin would notice it and take action.

Do you consider the current behavior desirable and if so which advantages you see with it? Would you prefer it to change to be consistent with the web representation?

0 trux over 5 years ago in reply to Joel

Joel said:
Do you consider the current behavior desirable and if so which advantages you see with it? Would you prefer it to change to be consistent with the web representation?

Frankly told, personally I do not care much. For me the most important is understanding how the data is presented, and how to interpret it. As long as that is assured, I am rather flexible and can adapt a wide range of formats. And especeially knowing that there is another aternative, in the form of the GCW graphs, that I prefere using anyway, it really does not bother me at all.

That told, I understand that you or anyone else may prefer a different way. However, the user forum here serves primarily for the mutual help. We can help each other, offer explanations, advices, and workarounds, but that's about all. You do not communicate to Garmin here, and whether the posts on the forum have any impact on the decisions at Garmin at all, is highly doubtful. You better contact them directly, or use the form at https://www.garmin.com/en-US/forms/ideas/

0 Joel over 5 years ago in reply to trux

trux said:
the user forum here serves primarily for the mutual help. We can help each other, offer explanations, advices, and workarounds, but that's about all. You do not communicate to Garmin here, and whether the posts on the forum have any impact on the decisions at Garmin at all, is highly doubtful.

Well received, and it has been helpful finding out that there is no option to change this and that the web version is different. I have seen a few posts from Garmin reps, so I was (maybe naively) hoping that posting here could potentially get an official response or explanation, since I didn't hear back when I contacted them directly.

I also think this issue is not immediately obvious when looking at the graph (I initially noticed it because my even length intervals showed up as differently long white lines), and getting more people aware of the current behavior could both be helpful for them and potentially cause more people to suggest that this changes.

0 trux over 5 years ago in reply to Joel

Yes, it is certainly very helpful posting it here, because people looking up similar problems in future, can find so the explanation and the workarounds.

0 marhog70 over 5 years ago in reply to trux

I would also classify this behavior as a bug. The current presentation is useless or at least missleading. In fact, I was collecting logs and screendumps for a troublereport when coming across this chat.