Statistics Reloaded.

[Willem Ferguson]

On 14/07/2017 23:57, Davide DB wrote:
> - We all agree that space is a problem but in this layout we have in
> the same screen: map, dive-list and dive profile which occupy/waste a
> lot of space.
>
> - Once the user filters dives getting a subset of them, the map and
> dive profile becomes immediately useless if not wrong. They would
> display data for the latest dive selected before the user played with
> stats. e.g. I have a wreck dive selected from he dive list and then I
> filter only cave dives. Right now the map and dive profile get updated
> with the first dive in the filtered dive list.
>   While I understand that a solution like this works (we have stats and
> filtered dives analysis in one screen, WOW) why all of this
> complexity?
> I'd rather prefer a more KISS approach. One feature at the time.
> Do I need to find and analyze some dives? I use the Log > Filter list
> feature currently implemented.
> Do I need stats for all of part of my dives? Let's use the stats view.
An excellent argument. Firstly, the question is, does one want to use 
the complete screen for the statistics view in the same way as the 
planner does? I have a sentiment that the Dive List should be visible in 
the statistics view: this reflects the source upon which the statistics 
are being calculated and if there is any statistic I would like to check 
up, the Dive list is accessible without removing the statistics. But if 
the Dive List panel is kept, one is left with a funny three-part screen 
surface (current Notes, Profile and Map panels) and the question is if 
one could create an efficient statistics view in such an odd area. What 
is your opinion? How would you use a larger screen surface than the 
small part I used in my mockups?
> Regarding the three buttons (trips, yearly, filtered) I do not fully
> understand how "Yearly" and "Trips" work with other filters. What's
> happen if I select "John Doe" and then "Yearly" or "Trips"?
> AFAIK they are just prepacked selections I could obtain with proper
> filters (e.g. I could get yearly just using date sliders... I could
> get trip stats just selecting one or more trips from a combo box with
> all of them and then using stat tabs below...) Moreover once we need
> another special prepacked selection we would add another button...
> I'm under the impression that those button breaks the filter meaning:
> we should have basic quantities filtering on multi-filter and then
> playing with data in the stats view (graphs, tables and so on).
>
> Maybe it's a moot point. I expect Dirk entering this discussion armed
> with Hattori Hanzo's Sword soon :)
Yes, I fear for my life for the moment he enters the discussion.

More seriously, I think Tomaz's idea of the type of graph he suggested 
about 2 weeks ago has merit. I want to ask  the question: Has my 
duration of cave dives become significantly longer over the last 5 
years? Or, has my SAC rate for dives between 40 and 50 meters improved 
over the last 20 trips? Yes, I could generate a histogram for each year 
by selecting only dives for that year and comparing the histograms 
visually, but that is user-unfriendly. Basically, the existing View -> 
Yearly statistics could be incorporated into the new framework and, 
using the same filter tool, be presented in a graphical way. Therefore 
the Yearly/Trip-orientated views. But I understand your point that, from 
a future expansion point of view, the organisation of buttons would 
present a significant layout problem. Maybe I do not understand your 
point. I feel that, it a Statistics View is implemented, then all the 
statistics should be incorporated in one single tool. They should not be 
scattered over the user interface.
>> 2) More complex is the issue of the bin sizes of histograms. E.g. in
>> Depth_stats.jpg the depth increments are 10m for each bar. What if all dives
>> were performed in the depth range 10-20 meters? This would result in a
>> histogram with a single bar. Not satisfactory. So we need to have a feature
>> to halve the bin size, i.e. to reduce the interval for each bar to half of
>> the present size (i.e. 5 m in this example) or to some smaller number. The
>> most simple would be to have a text box or a dropdown box in the graphic
>> field in which a default bin size is used and with which a different bin
>> size could be specified. But I am not sure which way is the most acceptable
>> from an intuitive UI point of view.
> IMHO axis range should be automagically calculated by the program
> based on data content exactly as the current dive profile. No user
> option.
This is a deeper statistical problem. Theory says that, for 
non-categorical data, the best interpretive presentation for a histogram 
is to use 10-12 bars: take the minimum and maximum values, divide by 12 
and use that as the bin size. Of course the problem is that this often 
results in inconvenient bin boundaries, e.g. a specific histogram bar 
that represents data for dives between 12.4 and 17.8 meters. The way we 
think about dive depth it is usually in multiples of 10m. And so, you 
are correct. But the statistical requirements of a freediver differs 
vastly from those of a deep technical diver. The freediver has, maybe a 
maximal depth of 40m whereas the tec diver has dived 150m. Having a 
single right-hand histogram bar of ">70m" helps neither of these two 
divers because the tec diver probably expects better information above 
70m and the freediver has no use for the histogram in the area deeper 
than 40m. Therefore a need to have some control over the bin size of the 
histogram. There is not a one-size-fits-all solution.
> I hope my Ital-english was clear enough.
>
Perfectly. I hope my English English is understandable.
Kind regards,
willem