RFC: Statistics in Subsurface

Dirk Hohndel dirk at hohndel.org
Mon May 11 14:46:31 PDT 2020



> On May 11, 2020, at 2:22 PM, Berthold Stoeger <bstoeger at mail.tuwien.ac.at> wrote:
> 
> On Montag, 11. Mai 2020 23:02:32 CEST Dirk Hohndel wrote:
> 
>>>> BUT: would this mean that the existing filter panel be rewritten in QML
>>>> to be mobile-compatible?
>>> 
>>> This is not necessary. The filter code is generic and we only need a tiny
>>> display layer on top. Let's not introduce QML where not absolutely
>>> necessary.
>> You are correct. It isn't necessary.
>> But at the same time, assuming we want to go down this rabbit hole of using
>> this as a way to define groupings in statistics, then yes, we most likely
>> want the exact same options for filtering here and there. Which is easiest
>> done by sharing the same QML widget.
> 
> They should have the same fields (although even that is debatable) - they 
> should not be forced to have the same layout. Let's try to separate display 
> from logic. If we keep the display layer sufficiently thin, then the 
> flexibility outweighs the redundancy (and we minimize suffering owing to QML). 
> To be clear: I'm talking about the filter widget.

Hmm.
So many things to argue about.
Of course you are correct. There is no reason that we must have the same widget.
And certainly the way we do filtering in the mobile dive list right now seems sufficient
for the mobile platform.
Which raises the question if what I'm suggesting isn't completely bogus in the first place.
Said that, If we envision this as a separate page that is used to create these named
sets, then adding those as choices in the current mobile filter dropdown also might be 
feasible.

Which leaves us with the question: does it make sense to have two different UIs to 
collect more or less the same data. 



This thing of beauty is our current widget to set up filtering on the desktop.
I think we can all agree that this is absolutely perfect, nothing could be improved here,
I believe that it is used as an example of visionary design in several books on UI
design currently being worked on.

And we certainly would want to replace this with something that we would share with
the mobile UI, done in QML.

Ok, biting (and pointless) sarcasm aside - yes, we can of course have two different entry
widgets. One implemented in QML, one in QWidgets.

>>> Generally, I wouldn't try to do the all-in-one solution. There are two
>>> kinds of statistics, which I would treat separately. Firstly, an overview
>>> over a defined set of dives with filter presets. Secondly, temporal
>>> progressions (e.g. development of SAC rate, grouped by day / week / month
>>> / year).
>> I'm not sure what you are saying here. Are you suggesting that we should
>> not try to have the same statistics module for desktop and mobile?
> 
> No - what I'm saying is that there are different kinds of statistics, which 
> should be treated mostly separately. E.g. pie charts vs. temporal 
> progressions.

Yes, I believe that that's where we need a lot more thinking and drawing before
we really can make any decisions. There are many different aspects of statistical
analysis of dive data that lend themselves to different visualization.

I guess we need to start collecting them...

But what I don't understand in your example, is what makes
- overview over a defined set of dives with filter presets
different from
- temporal progression

Isn't the latter just a special case of the former? I guess it would be really painful
to have to manual edit corresponding filter sets, but fundamentally, a monthly
progression could very much be captured as a group of such sets:

set1: all other criteria plus first month
set2: all other criteria plus second month
etc

e.g.: 
set1: all dives with tag "boat" and from 2018/01/01-2018/01/31
set2: all dives with tag "boat" and from 2018/02/01-2018/02/28
...
set24: all dives with tag "boat" and from 2019/12/01-2019/12/31

A pain to manually create. Not hard at all to algorithmically create.

But maybe I'm just completely over engineering all this and what we should do
is three default graphs and be done with it.

/D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20200511/52c24073/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2020-05-11 at 2.36.10 PM.png
Type: image/png
Size: 235958 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20200511/52c24073/attachment-0001.png>


More information about the subsurface mailing list