RFC: Statistics in Subsurface

Mon May 11 15:02:06 PDT 2020

Since we all know and agree that I am, indeed, the premier UI developer and
most talented graphical designer*

*currently residing at this address and typing the email

Here's a crazy idea how this could look for example:

The filters are built incrementally, with a drop down menu that allows you to
add criteria or constraints. Like date range, tags, people, etc

once the user picks one, that is added to the list and can be populated. 
In the example the user first added 'date' and then 'tags'.
The tags one shows the idea of having additional options (all/any/none and
substr/starts/exact, just like we have today). Using font size and font color
to make this seem less cluttered.

You could make obvious algorithmic choices like "annually", "monthly", "by trip"
available as additional constraints.

Yeah, I had someone not show up for a 1:1 and tried to do something fun the last
half hour. can you tell?

/D

> On May 11, 2020, at 2:46 PM, Dirk Hohndel via subsurface <subsurface at subsurface-divelog.org> wrote:
> 
> 
> 
>> On May 11, 2020, at 2:22 PM, Berthold Stoeger <bstoeger at mail.tuwien.ac.at <mailto: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
> _______________________________________________
> subsurface mailing list
> subsurface at subsurface-divelog.org <mailto:subsurface at subsurface-divelog.org>
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface <http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20200511/a15e9e60/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2020-05-11 at 2.57.04 PM.png
Type: image/png
Size: 315099 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20200511/a15e9e60/attachment-0002.png>
-------------- 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/a15e9e60/attachment-0003.png>