<div dir="ltr">On 06/07/2017 22:44, Davide DB wrote:

<br><blockquote type="cite" style="color:rgb(0,0,0)">Hi guys

<br>

Do you remember I sketched tons mockups for statistics maybe two years ago?

<br>

<br>On 6 July 2017 at 22:18, Tomaz Canabrava <a class="gmail-moz-txt-link-rfc2396E" href="mailto:tcanabrava@kde.org"><tcanabrava@kde.org></a> wrote:

<br><blockquote type="cite" style="color:rgb(0,0,0)">Willem,

<br>

<br>

<br>Thanks for your feedback, I'll play more with this on the weekend. I do

<br>believe that your ideas are nice and I'll experiment with them. If you want

I can give you my branch for you to test and experiment too.

<br>

<br>Actually, considering that I'm by no means a good math person, do you mind

<br>to create mockups for all possible statistics that you can think Subsurface

should provide?

<br>

This will help me a lot.

<br>

<br>Tomaz

<br>

<br></blockquote></blockquote>Tomaz, Davide,

<br>

<br>I think the statistics on the current statistics tab are probably those 

that would mostly be looked at. There are two types of display that one 

would probably like:

<br>

<br>1) Summary information for a selected number of trips or time periods. 

This is exactly what you proposed in your mail: A number of bars 

indicating min/mean/max for each trip or time period.

<br>

<br>2) More detailed information for a specific trip, dive site or period. 

This assumes one can select the trip, dive site or period. That could be 

done from the dive list. In this respect I like Davide's idea of using 

the filter tool to select some of the dives. The information could be 

displayed as a histogram/bar chart as Davide suggested. For instance, 

show a bar histogram of dive depth for a particular group of dives; or a 

histogram of SAC for a particular period.

<br>

<br>We need to think about the most common criteria that a diver would 

require for statistics. I think these are probably:

<br>

<br>a) Start date and end date (a bit more flexible than just selecting 

calendar year) - this can currently be done by selecting from the dive list

b) Dive site(s) - this could currently be done from the filter tool.

<br>c) Trip(s) - This could currently be done by selecting from the dive list

<br>d) Depth range - This cannot easily be done at present. e.g. SAC for 

different dive depths.

<br>e) Davide suggested Run time - This cannot be done at present., e.g. 

Depth for different run times.

<br>

<br>So, the ease of selection of dives to be analysed is just as important 

as the statistics graphs shown for these dives. A starting point for 

selection would be to show statistics for the currently selected dives 

in the dive list, either selected by hand on the dive list or through 

the filter tool. But Davide's proposal at

<br><a class="gmail-moz-txt-link-freetext" href="http://i.imgur.com/6d1eF4N.png">http://i.imgur.com/6d1eF4N.png</a>

<br>is compelling. He used the current filter tool and added three more 

items for filtering: date, depth and dive duration.

<br>

<br>The question is: how should one, in addition, select the item to be 

analysed (Depth, Duration, Temperature,SAC)? Davide solves that by using 

tabs on the Info Panel. The trick is to implement something that does 

not congest of clog the visual display. The current desktop display is 

already pretty full, so showing a selection space-efficiently is a 

challenge. If this applies to the desktop, then there are even more 

challenges on the mobile version.

<br>

<br>The biggest impediment to statistics on the mobile version is the 

inability to select or filter dives. This will probably only become 

realistic once we can collapse dive trips on the mobile dive list 

because there are optimised tools for doing list selection in the mobile 

environment. In fact, we are already doing that when, on mobile, we 

select the already-downloaded dives to be added to the dive list.

<br>

<br>I would strongly support the principle of doing the statistics in QML 

because that reduces duplication of development.

<br>

<br>After a long and meandering argument, here are my specific suggestions:

<br>

<br>1) The current item Yearly Statistics in the View Main Menu item should 

be the primary way of obtaining min/mean/max graphs. Currently this 

shows statistics for all 4 the variables: depth, duration, SAC and 

temperature. The default display could be depth, with an on-panel radio 

button to select which of the 4 variables needs display. Alternatively 

Davide's idea of tabs on the same panel. BUT: this panel should present 

min/mean/max statistics only for the dives that are selected in the dive 

list. If no dives are selected, then all dives are analysed.

<br>

<br>2) Remove the current Statistics tab in the Dive Notes panel of a dive 

because these data do not pertain to the specific dive being shown at 

the time: it pertains to the dive list. Under View in the Main Menu, add 

another item Detailed Statistics, which allows histograms for specific 

variables for the selected dives in the dive list. If no dives are 

selected, then all dives are analysed. There is a need to select which 

of depth, duration, SAC and temperature should be shown (probably depth 

by default, with either radio buttons or tabs to choose between variables).

<br>

<br>3) Implement Davide's idea of adding two more items to the filter tool: 

dates, and depth. I am not convinced that a filter for dive duration 

will be extremely useful. It would need additional screen space in an 

already-congested area.

<br>

<br>So it turns out that for efficient statistics rendering, the main work 

is actually not in generating statistics and graphics, but in generating 

ways to select the dives to be analysed.

<br>

<br>The last question is to what we can realistically expect Tomaz to do. I 

offer to mess with the present Yearly Statistics menu item, using C/C++ 

to print only the numeric statistics of one of the four variables and to 

select which variable is being shown in text. Then Tomaz can take the 

text and turn it into a graphic that is mobile-compatible. Someone else 

may wish to adapt the filter tool. But first we need some type of 

consensus that the above approach is indeed the one to go.

<br>

Apologies for a long email.

<br>Kind regards,

<br>willem

<br>

<br>

<br>

<br>

<br>

<br>

</div>