<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 13, 2020, at 8:10 AM, Willem Ferguson <<a href="mailto:willemferguson@zoology.up.ac.za" class="">willemferguson@zoology.up.ac.za</a>> wrote:</div><div class=""><div class=""><p class="">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?</p></div></div></blockquote><div><br class=""></div>I have come to the conclusion that my over-engineered filter based columns idea was wacko. So I'm not proposing that anymore.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">
    <blockquote type="cite" cite="mid:FE5D8A9D-532A-4A55-9D9C-234E9D9C0D07@hohndel.org" class="">
      <div class="">
        <div class="">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.</div>
        <div class="">Then you pick the grouping (i.e. x-axis)</div>
        <div class=""><br class="">
        </div>
        <div class=""><img apple-inline="yes" id="79665DBE-883D-44D6-AE92-2354DCA6BA51" class="" width="413" height="293" src="cid:part1.487566F5.40E7A039@zoology.up.ac.za"></div>
        <div class=""><br class="">
        </div>
      </div>
    </blockquote><p class="">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). <br class=""></p></div></div></blockquote><div>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.</div><div>Just to rephrase your second sentence, I assume you are calling the filtered dives "marked dives"? </div><div><br class=""></div><div>I'd love to try and avoid too much confusion in terms - we have </div><div>- selected dives (really only on desktop)</div><div>- filtered dives (those shown by the filter)</div><div>- hidden dives (those not shown by the filter)</div><div>- invalid dives (those marked invalid, with an option in the preferences whether they are considered 'real' or not)</div><div>I don't think we need another category, do we?</div><div><br class=""></div><div>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.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><p class="">
    </p>
    <blockquote type="cite" cite="mid:FE5D8A9D-532A-4A55-9D9C-234E9D9C0D07@hohndel.org" class="">
      <div class="">
        <div class="">Once you pick one, if needed, there's a way to specify even
          further</div>
        <div class=""><br class="">
        </div>
        <div class=""><img apple-inline="yes" id="8F00D10B-653C-4AD9-A1EC-780F5E08482D" class="" width="406" height="242" src="cid:part2.4B198FFA.CE0C682F@zoology.up.ac.za"></div>
        <div class=""><br class="">
        </div>
      </div>
    </blockquote><p class="">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<br class="">
    </p><p class="">Time: montly, yearly, fixed no columns</p><div class=""><br class=""></div></div></div></blockquote><div>That may work for you. But what about people who dive every day? They may want weekly? Or daily?</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><p class="">Trip: I cannot think of any granularity options. Stats evaluated
      per trip.<br class="">
    </p><p class="">Depth: Increments of 5m, 10m, 20m, fixed no columns</p></div></div></blockquote><div><br class=""></div>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.</div><div>Also, this depends on your unit system. Other people might want increments of 10ft, 20ft, 30ft.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><p class="">Duration: Increments of 10 min, 20 min, 30 min, fixed no columns</p></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><p class="">Temp: Increments of 2, 5 10 degrees, fixed no columns</p></div></div></blockquote><div><br class=""></div><div>Ditto on fixed. And again, careful. Degrees of what</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><p class="">All the categorical variables: I think your suggestion as for
      tags below is excellent: text box.</p></div></div></blockquote><div><br class=""></div>what are categorical variables?</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><p class="">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".<br class=""></p></div></div></blockquote><div><br class=""></div><div>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.</div><div>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.</div><div>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.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><p class="">
    </p>
    <blockquote type="cite" cite="mid:FE5D8A9D-532A-4A55-9D9C-234E9D9C0D07@hohndel.org" class="">
      <div class="">
        <div class="">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.</div>
        <div class="">You've been diving for ten years and want seven columns,
          so... groups of 18 months?</div>
        <div class=""><br class="">
        </div>
        <div class=""><img apple-inline="yes" id="A42589D8-59E8-4BE5-AF42-869C17AB6D4B" class="" width="401" height="259" src="cid:part3.3DBC6B27.71DCDEC9@zoology.up.ac.za"></div>
        <div class=""><br class="">
        </div>
        <div class=""><br class="">
        </div>
        <div class="">What am I missing? What could be better?</div>
      </div>
    </blockquote><p class="">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.<br class=""></p></div></div></blockquote><div><br class=""></div><div>Yes, this was intended as an example for 'by time'.</div>And no, I suck as a UI designer.</div><div>But I've also learned that we cannot start creating a UI without having a decent idea of how it's supposed to look.</div><div>I have done that to Tomaz way too many times and it never was pleasant for him.</div><div><br class=""></div><div>/D</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><p class="">
    </p>
    </div></div></blockquote></div><br class=""></body></html>