<div dir="auto">I would redesign the statistics page on using a default chart and a dropdown at the top to select more granular things like yearly, monthly. when selected the chart just readjust dinamic <div dir="auto">Only one tab. more tabs gets confusing and crowdint the screen.</div><div dir="auto">Just an idea. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 7, 2020, 18:37 Dirk Hohndel via subsurface <<a href="mailto:subsurface@subsurface-divelog.org">subsurface@subsurface-divelog.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 2020-05-07 at 14:37 +0200, Willem Ferguson via subsurface<br>
wrote:<br>
> I have been thinking  a long time about graphical statistics<br>
> facilities <br>
> for Subsurface, that is presenting the dive statistics as bar graphs<br>
> or <br>
> other types of graphics.<br>
<br>
This is a topic that we have tried to tackle for something like 5 years<br>
now. And it is a tough one, in large part because I strongly believe<br>
that if we do spend the effort to do this, we should do so in a way<br>
that works both for desktop and mobile - because better statistics are<br>
the #1 request for the mobile app (ahead of an implementation of the<br>
planner).<br>
<br>
Which means this should ideally be implemented in much of the same way<br>
as the Maps. As a QML module that can be used in both apps. Which makes<br>
things harder - but I strongly believe is the right thing to do.<br>
<br>
How we should start is with a drawing board and sketches. What are we<br>
visualizing? Which numbers and data points are likely to be most<br>
interesting and useful for people - we have learned in the past that<br>
the answers to this vary shockingly widely. And equally importand, how<br>
are we visualizing this - just draw things with a pen on paper and send<br>
a picture...<br>
<br>
Once we have that, we can look more into how to implement this. The<br>
available QML modules for graphics are limited. Check here for a quick<br>
intro:<br>
<a href="https://doc.qt.io/qt-5/qtcharts-qmlchart-example.html" rel="noreferrer noreferrer" target="_blank">https://doc.qt.io/qt-5/qtcharts-qmlchart-example.html</a><br>
Yes, there are much more powerful toolkits available, but I haven't<br>
found one that doesn't add significant overhead for the mobile<br>
platforms.<br>
Someone pointed out to me a while ago that we might be able to use a<br>
full Javascript charts framework like <a href="https://www.chartjs.org/" rel="noreferrer noreferrer" target="_blank">https://www.chartjs.org/</a> this<br>
will require some experimentation for iOS and Android. If someone<br>
wanted to tackle THAT question (which could happen in parallel to the<br>
work on the actual design above), that would be great.<br>
<br>
> 1) In doing so, I looked at the yearly statistics as implemented at<br>
> the <br>
> moment and realised that this is actually a pretty comprehensive <br>
> statistical framework and that it would be inefficient to write a <br>
> separate code base for graphical statistical presentation. The<br>
> current <br>
> code for statistics is somewhat complicated but perfectly workable.<br>
<br>
Correct me if I'm wrong, but I thought that both the yearly statistics<br>
and the statistics tab use the same backend code (basically<br>
statistics.c)<br>
<br>
> 2) The current statistics tab, accessible from the Notes Panel (i.e.<br>
> the <br>
> statistics tab adjacent to the Information tab) actually largely <br>
> duplicates what can be obtained from the Yearly statistics panel.<br>
> The <br>
> only difference is that, currently, the Yearly statistics calculates <br>
> results based on the whole dive log, while the Statistic tab<br>
> presents <br>
> results for all the dives selected on the dive list. However, <br>
> yearlystatisticsmodel.cpp already already has code that in principle <br>
> allows calculations for the *selected* dives in the dive log: it is<br>
> just <br>
> not activated as far as I can see.<br>
<br>
Again, I believe that this is all using the same backend code. And<br>
ideally we really want to have just ONE spot where we calculate things<br>
and have the UI layer just deal with how things are presented to the<br>
user. Typically in the past our code wasn't always very careful in<br>
following these design goals.<br>
<br>
> 3) The main problem with the yearly statistics is that the table is <br>
> pretty large. In order to make this more user friendly, my proposal<br>
> is <br>
> to break the yearly statistics table into smaller chunks and move<br>
> them <br>
> over to the Statistics tab.<br>
<br>
Yes, the visualization is not great (to be kind)<br>
<br>
> 4) This would bring all the statistics together in one place. Seeing <br>
> that the info in the Statistics tab has no one-to-one connection<br>
> with <br>
> the dive profile being displayed, the question arises: should the <br>
> statistics tab not be elevated to the main menu rather than a tab<br>
> within <br>
> the Notes Panel ??<br>
<br>
I'm not against the idea of having the graphical representation of<br>
statistics replace the profile on the desktop - that certainly wouldn't<br>
work on mobile as the layout there is completely different. My guess is<br>
that there we'd have a completely separate page, along the lines of the<br>
dive summary.<br>
<br>
> 5) What I am thinking of is to break up the results for yearly <br>
> statistics and move them over to the statistics tab. The interface<br>
> may <br>
> perhaps be a dropdown list corresponding to all the headings on the <br>
> left-hand side of the yearly statistics. Another dropdown list would <br>
> have information similar to the column headings of the yearly <br>
> statistics. One would then select an item from each of the dropdown <br>
> lists and this would bring up the relevant numbers as well as a <br>
> graphical representation of these numbers. The min, max and average <br>
> numbers currently shown in the statistics tab needs to be made <br>
> accessible in some way, but probably integrated with the above <br>
> somewhere. This would mean that the existing statistical<br>
> infrastructure <br>
> largely remains as is, it is just the UI for showing the results<br>
> that <br>
> changes.<br>
<br>
Now we are getting into the 'how we visualize' and there textual<br>
descriptions tend to work very poorly. This really requires some<br>
pictures.<br>
<br>
> Does this look like a viable approach at all?<br>
<br>
I would love to get more people into this conversation.<br>
<br>
/D<br>
<br>
_______________________________________________<br>
subsurface mailing list<br>
<a href="mailto:subsurface@subsurface-divelog.org" target="_blank" rel="noreferrer">subsurface@subsurface-divelog.org</a><br>
<a href="http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface" rel="noreferrer noreferrer" target="_blank">http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface</a><br>
</blockquote></div>