<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 12, 2020, at 2:24 PM, Dirk Hohndel via subsurface <<a href="mailto:subsurface@subsurface-divelog.org" class="">subsurface@subsurface-divelog.org</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><p class="">I am comfortable with your points of view, above. The 10m or
10min increments could easily be configurable. For instance a
person with OW certification (dives to 18m only with almost all
dives in the 10-18m range) would probably want at most a 5m
increment in depth. Unless I understand you wrongly (again).
Normally with statistical software (like R) the default increment
is determined by the (max-min) range of the data as well as the
number of data points being plotted. Of course I would not like an
increment of 3.674 m of depth as might be the case when increment
is automatically calculated by machine. My only point is that a
single fixed increment is possibly restrictive and it would help
if there were a simple rule to do some adjustment of the
increment.<br class=""></p></div></div></blockquote><div class=""><br class=""></div>It's those details that tend to make something go from "straight forward" to "crazy tricky".</div><div class="">No, I definitely don't want 3.764m increments, but some people might want 3.04m increments (ten feet). Getting this almost right for most people is easy (ask the user how many data points they would like, and then round so in their unit system the result is marginally pleasant). Getting exactly what people would want is likely about as painful as my initial over-engineered idea.</div></div></div></blockquote><div><br class=""></div><div>So here's a bad sketch:</div><div><br class=""></div><div>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>Then you pick the grouping (i.e. x-axis)</div><div><br class=""></div><div><img apple-inline="yes" id="79665DBE-883D-44D6-AE92-2354DCA6BA51" width="413" height="293" src="cid:9D2D3C7F-EB5C-4FE9-9FEA-6E6330F2D7CB" class=""></div><div><br class=""></div><div>Once you pick one, if needed, there's a way to specify even further</div><div><br class=""></div><div><img apple-inline="yes" id="8F00D10B-653C-4AD9-A1EC-780F5E08482D" width="406" height="242" src="cid:672A9E11-B472-4458-828D-CDEF72E97AD7" class=""></div><div><br class=""></div><div>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>You've been diving for ten years and want seven columns, so... groups of 18 months?</div><div><br class=""></div><div><img apple-inline="yes" id="A42589D8-59E8-4BE5-AF42-869C17AB6D4B" width="401" height="259" src="cid:B3CCB38B-F552-425E-9DE5-E00132B0CF04" class=""></div><div><br class=""></div><div><br class=""></div><div>What am I missing? What could be better?</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><p class="">As far as specifying categories like tags I like the present UI
where one could specify a number of tags to be included in the
filter, giving great flexibility. Again my impression of such a
plot possibly differs from yours. I like your binary set idea (a
set including compared to a set excluding). But I would more
realistically often want to compare (e.g. SAC when comparing two
tags "air" and "nitrox"), a use case which does not necessarily
imply a binary comparison because it could compare 3 or 4 tags.
Does this make sense at all?</p></div></div></blockquote><div class=""><br class=""></div><div class="">It makes sense for people who are able to use sets of tags in a meaningful way - one could have a mutually exclusive set of three tags (say, air, nitrox, trimix) and create statistics over them. Of course the results become "strange" if dives potentially have multiple of those tags.</div><div class="">Again, to get this "mostly right" is fairly easy. To cover all the crazy corner cases is what's hard.</div></div></div></div></blockquote><div><br class=""></div><div><img apple-inline="yes" id="0C44A5C2-3F51-4EF5-B541-150183B2F68C" width="420" height="261" src="cid:BA48C893-9CF0-401E-8D5B-250F4F710A15" class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><p class="">Lastly, I do not like candlestick graphs because the application
in econometrics does not include the equivalent of a mean value.
It is meant to indicate the limits and sometimes direction of
change within a specific time period giving rise to the candle
forming the central part of the graph. In my opinion a minimal box
and whisker approach is more readily interpretable.</p></div></div></blockquote><div class=""><br class=""></div>I keep saying "candlestick" when I mean to say "box and whiskers". My mistake. You are spot on correct, the error is mine.</div></div></div></blockquote><div><br class=""></div><div>And I was wrong in my earlier email. As I said above, for total duration and number of dives, you'd want a bar chart or line graph. For the rest I think box and whiskers is fine.</div></div><br class=""><div class=""><br class=""></div><div class="">/D</div></body></html>