<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 11, 2020, at 2:22 PM, Berthold Stoeger <<a href="mailto:bstoeger@mail.tuwien.ac.at" class="">bstoeger@mail.tuwien.ac.at</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Montag, 11. Mai 2020 23:02:32 CEST Dirk Hohndel wrote:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">BUT: would this mean that the existing filter panel be rewritten in QML<br class="">to be mobile-compatible?<br class=""></blockquote><br class="">This is not necessary. The filter code is generic and we only need a tiny<br class="">display layer on top. Let's not introduce QML where not absolutely<br class="">necessary.<br class=""></blockquote>You are correct. It isn't necessary.<br class="">But at the same time, assuming we want to go down this rabbit hole of using<br class="">this as a way to define groupings in statistics, then yes, we most likely<br class="">want the exact same options for filtering here and there. Which is easiest<br class="">done by sharing the same QML widget.<br class=""></blockquote><br class="">They should have the same fields (although even that is debatable) - they <br class="">should not be forced to have the same layout. Let's try to separate display <br class="">from logic. If we keep the display layer sufficiently thin, then the <br class="">flexibility outweighs the redundancy (and we minimize suffering owing to QML). <br class="">To be clear: I'm talking about the filter widget.<br class=""></div></div></blockquote><div><br class=""></div><div>Hmm.</div><div>So many things to argue about.</div><div>Of course you are correct. There is no reason that we must have the same widget.</div><div>And certainly the way we do filtering in the mobile dive list right now seems sufficient</div><div>for the mobile platform.</div><div>Which raises the question if what I'm suggesting isn't completely bogus in the first place.</div><div>Said that, If we envision this as a separate page that is used to create these named</div><div>sets, then adding those as choices in the current mobile filter dropdown also might be </div><div>feasible.</div><div><br class=""></div>Which leaves us with the question: does it make sense to have two different UIs to </div><div>collect more or less the same data. </div><div><br class=""></div><div><img apple-inline="yes" id="8596552A-686A-478B-B440-CCBAFB5791D1" width="480" height="486" src="cid:FC64E6F8-53FE-4AB0-A57C-CE99F336FFD5" class=""></div><div><br class=""></div><div>This thing of beauty is our current widget to set up filtering on the desktop.</div><div>I think we can all agree that this is absolutely perfect, nothing could be improved here,</div><div>I believe that it is used as an example of visionary design in several books on UI</div><div>design currently being worked on.</div><div><br class=""></div><div>And we certainly would want to replace this with something that we would share with</div><div>the mobile UI, done in QML.</div><div><br class=""></div><div>Ok, biting (and pointless) sarcasm aside - yes, we can of course have two different entry</div><div>widgets. One implemented in QML, one in QWidgets.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Generally, I wouldn't try to do the all-in-one solution. There are two<br class="">kinds of statistics, which I would treat separately. Firstly, an overview<br class="">over a defined set of dives with filter presets. Secondly, temporal<br class="">progressions (e.g. development of SAC rate, grouped by day / week / month<br class="">/ year).<br class=""></blockquote>I'm not sure what you are saying here. Are you suggesting that we should<br class="">not try to have the same statistics module for desktop and mobile?<br class=""></blockquote><br class="">No - what I'm saying is that there are different kinds of statistics, which <br class="">should be treated mostly separately. E.g. pie charts vs. temporal <br class="">progressions.<br class=""></div></div></blockquote></div><br class=""><div class="">Yes, I believe that that's where we need a lot more thinking and drawing before</div><div class="">we really can make any decisions. There are many different aspects of statistical</div><div class="">analysis of dive data that lend themselves to different visualization.</div><div class=""><br class=""></div><div class="">I guess we need to start collecting them...</div><div class=""><br class=""></div><div class="">But what I don't understand in your example, is what makes</div><div class="">- overview over a defined set of dives with filter presets</div><div class="">different from</div><div class="">- temporal progression</div><div class=""><br class=""></div><div class="">Isn't the latter just a special case of the former? I guess it would be really painful</div><div class="">to have to manual edit corresponding filter sets, but fundamentally, a monthly</div><div class="">progression could very much be captured as a group of such sets:</div><div class=""><br class=""></div><div class="">set1: all other criteria plus first month</div><div class="">set2: all other criteria plus second month</div><div class="">etc</div><div class=""><br class=""></div><div class="">e.g.: </div><div class="">set1: all dives with tag "boat" and from 2018/01/01-2018/01/31</div><div class="">set2: all dives with tag "boat" and from 2018/02/01-2018/02/28</div><div class="">...</div><div class="">set24: all dives with tag "boat" and from 2019/12/01-2019/12/31</div><div class=""><br class=""></div><div class="">A pain to manually create. Not hard at all to algorithmically create.</div><div class=""><br class=""></div><div class="">But maybe I'm just completely over engineering all this and what we should do</div><div class="">is three default graphs and be done with it.</div><div class=""><br class=""></div><div class="">/D</div></body></html>