RFC: Statistics in Subsurface

Wed May 13 08:36:40 PDT 2020

> On May 13, 2020, at 8:10 AM, Willem Ferguson <willemferguson at zoology.up.ac.za> wrote:
> Not a bad sketch. In fact the concept behind it all is excellent. One thing that I pick up here is that no filter is specified here. How would the proposed UI below affect the present filtering facility? Will that be replaced by a more simple filter mechanism or will it remain unchanged? The way I read this, the existing filter would not be changed (which would personally like). But your idea of filter sets is not raised here at all. I assume that this is a different topic that is not being dropped, I hope?
> 

I have come to the conclusion that my over-engineered filter based columns idea was wacko. So I'm not proposing that anymore.

There is a second suggested improvement to replace the current filter panel (which I hate) with something based on my incremental filter suggestion. But that's not in itself connected to the statistics.

One thing that isn't in the drawings but that I had mentioned is that I made the assumption that we should always do the statistics only on the filtered dives. Not as an option, but as an 'always on' feature.

>> First you pick your values and your grouping. Most of them are box/whiskers, the two that have just a simple # per column could be just a plain line graph of bar chart.
>> Then you pick the grouping (i.e. x-axis)
>> 
>> 
>> 
> The grouping dropbox would obviously require an item "No grouping", i.e. the full dataset. If this proposal will not affect the existing filter mechanism, then by default the graphing will only work on marked dives (i.e. the result of filtering using the filter tool) *if indeed any dives have been marked by the filter* (i.e. the filter is active). 
> 
By time with 1 column is obviously the same as "all dives". But sure, this could be an additional entry to make it more obvious.
Just to rephrase your second sentence, I assume you are calling the filtered dives "marked dives"? 

I'd love to try and avoid too much confusion in terms - we have 
- selected dives (really only on desktop)
- filtered dives (those shown by the filter)
- hidden dives (those not shown by the filter)
- invalid dives (those marked invalid, with an option in the preferences whether they are considered 'real' or not)
I don't think we need another category, do we?

And as I said above - I believe we are best served by always only using filtered dives for the statistics. If the user wants all dives, then clear the filter. You always get the statistics on the dives that are shown. That seems logical and straight forward and removes yet another UI element.

>> Once you pick one, if needed, there's a way to specify even further
>> 
>> 
>> 
> This is just a brainstorm that may help to get granularity articulated in a useful way and the way it would work in practice. For the granularity above, the options could be
> 
> Time: montly, yearly, fixed no columns
> 
> 
That may work for you. But what about people who dive every day? They may want weekly? Or daily?

> Trip: I cannot think of any granularity options. Stats evaluated per trip.
> 
> Depth: Increments of 5m, 10m, 20m, fixed no columns
> 

No, fixed no columns makes no sense for multiple criteria, because it's always the same result. All filtered dives in one column. Which is why I said above I'd just add 'all dives' as an option.
Also, this depends on your unit system. Other people might want increments of 10ft, 20ft, 30ft.

> Duration: Increments of 10 min, 20 min, 30 min, fixed no columns
> 

Ditto on fixed. Also, those increments are getting weird really quickly. multiples of 50 minutes, anyone? I'd keep it at 15, 30, 60, and then just give me the number of columns you want.

> Temp: Increments of 2, 5 10 degrees, fixed no columns
> 

Ditto on fixed. And again, careful. Degrees of what

> All the categorical variables: I think your suggestion as for tags below is excellent: text box.
> 

what are categorical variables?

> For stats based on an "air/not_air" or "drysuit/no_drysuit" basis, a mechanism would be required.  A "drysuit/no_drysuit" equipment analysis would then be specified in the textbox by e.g. "drysuit, opposite".
> 

I have no intention of doing that. People can group 'by suit' which is simply comparing text strings. Or they can have tags that describe the thing they want to group by.
And I have walked away from the idea of showing binary (tag present, tag not present). Instead I'd suggest simply having one column per tag that the user gives.
And if people feel that's useful, we can add a final column that's "none of the tags you gave me" - which with a single tag then degenerates to that binary idea.

>> For example, with by time with a fixed # of columns we would create something that feels "semi reasonable" that gets us the right number of columns.
>> You've been diving for ten years and want seven columns, so... groups of 18 months?
>> 
>> 
>> 
>> 
>> What am I missing? What could be better?
> I honestly cannot think of any obvious improvement. We will make a UI designer of you yet. The # of columns above would obviously only be active for numeric variables since it would not serve a purpose for categorical variables such as tags.
> 

Yes, this was intended as an example for 'by time'.
And no, I suck as a UI designer.
But I've also learned that we cannot start creating a UI without having a decent idea of how it's supposed to look.
I have done that to Tomaz way too many times and it never was pleasant for him.

/D

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20200513/24db521b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2020-05-12 at 2.42.18 PM.png
Type: image/png
Size: 254860 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20200513/24db521b/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2020-05-12 at 2.42.26 PM.png
Type: image/png
Size: 152671 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20200513/24db521b/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2020-05-12 at 2.42.31 PM.png
Type: image/png
Size: 165917 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20200513/24db521b/attachment-0005.png>