<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="">just after I finished writing the email below, I realized that Willem had sent it only to me - but this discussion really needs to be on the mailing list... so I'm resending my response (which I believe includes all of his proposal text) to the list<br class=""><div><font color="#5856d6" class=""><br class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class=""></span></font><blockquote type="cite" class=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">On May 8, 2020, at 2:39 AM, Willem Ferguson <<a href="mailto:willemferguson@zoology.up.ac.za" class="">willemferguson@zoology.up.ac.za</a>> wrote:<br class=""><font color="#00afcd" class=""><span style="caret-color: rgb(0, 175, 205);" class=""><br class=""></span></font><div class=""><div class="">1) When considering the bulk of the Subsurface users, I honestly think the existing framework is pretty wide-ranging and also extensible. So my first suggestion would be to use the existing statistics framework and just improve on the presentation of the information. The only absolute requirement would be that the table is presented for the SELECTED dives in the dive list, not for the complete dive list as at present.<br class=""></div></div></div></div></blockquote><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class=""></span></font>That should be easy to do in code - it gets trickier when we think about UI. See our current filter widget. Crazy powerful. Definitely not the most user friendly part of Subsurface.<br class="">And it gets even trickier when we keep in mind my request that this has to work for both desktop and mobile - because on mobile there is no concept of "selecting multiple dives".<br class=""><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class=""></span></font>I don't want to do anything that creates more pressure to allowing multiple dive selection on mobile. There be dragons.<br class=""><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class=""></span></font><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><div class="">2) The following is a conceptual description of what I am thinking of in terms of CONTENT, NOT in terms of UI presentation. Consider the attached image Yearly_stats which mainly presents the Yearly statistics as it is at the moment. What I would like to do is to select a particular row on the left-hand side as well as a column heading at the top, and extract the appropriate information. For instance, someone wants to extract information on his/her SAC rate at dives at different depths, the relevant information is indicated by the information in the red-outlined blocks. This is present as radio buttons on the left and another set of radio buttons along the top. Select the appropriate radio button on the left and another along the top, and the information in Table1.png is presented. Only the information requested is presented here, not the huge and expandable table where one needs to search for the information one wants. So the first step would be to merely have a mechanism to easily extract information from the large Yearly statistics table.<br class=""></div></div></div></div></blockquote><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class=""></span></font>interesting concept. Right now on the left we have<br class="">- by year<br class="">- by trip<br class="">- by type (OC/CC)<br class="">- by max depth<br class="">- by min temp<br class=""><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class=""></span></font>I think that list would have to be expanded to cover more of the likely graph scenarios, right?<br class="">- by duration<br class="">- by tag<br class="">- by...<br class=""><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class=""></span></font>So let's go back to what I said earlier about (ab-)using the filter. How about we use the insanely flexible filter to allow the user to define their own group:<br class="">- pick filter settings (dive with tag 'boat', longer than 40min)<br class="">- name that 'set' (boat dives > 40min)<br class="">- pick different filter settings (dive with tag 'boat', 30-39:59 duration)<br class="">- name that 'set'<br class="">combine a group of 'sets' into a group which gives you the slicing of the dives that you want<br class=""><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class=""></span></font>Now offer those sets as rows in the statistics table. That way we can reasonably easily allow users to create almost any statistics they might want.<br class=""><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class=""></span></font>Currently on mobile we don't have this level of detail because the way the dive list is presented, this didn't seem feasible. But adapting the UI to create these groups should be reasonably straight forward, even in QML... it would just have to be its own page.<br class="">Or. Crazy thought. But of course. We store those groups of sets with the dive log. So you can create and name them on the desktop, and re-use them on mobile...<br class=""><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class=""></span></font><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><div class="">3) As indicated, the above explanation is only conceptual. In terms of UI implementation one of the most straight-forward approaches would be to have a dropbox that contains all the topics on the lefthand siide of the Yearly statistics table, and another dropdown box that represents the heading at the tops of the columns in that table. Selecting the topic "All by max depth" topic in the first dropdown list and "SAC" in the second dropdown results in the output presented in Table1.png (attached).<br class=""></div></div></div></div></blockquote><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class=""></span></font>Definitely a good starting point - using a drop down we could simply add the groups that the user has defined as options for the rows (which in your visualization then turn into the individual bars in the graph)<br class=""><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class=""></span></font><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><div class="">4) The attached image Graph.png represents a graphical representation of the same information as in Table1. In terms of UI implementation the choice of tabular or graphical representation is open to discussion because a choice of one of the two types of presentation can be implemented, or a UI that presents BOTH the tabular and graphical formats. For me personally a graphical presentation is much more immediately interpretable than the tabular presentation.<br class=""></div></div></div></div></blockquote><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class=""></span></font>Nothing stops us from offering both and the ability to flip between them.<br class=""><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class=""></span></font><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><div class="">5) I would argue that the present Yearly statistics option in the main menu->View submenu be retained and that the Statistics tab in the Notes panel is removed.<br class=""></div></div></div></div></blockquote><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class=""></span></font>I think the statistics tab is somewhat different in that in offers information that is not available in the yearly statistics (gas consumption) and in that it feels like it's a very easy to approach "quick overview" of your dives. Almost like the dive summary on mobile.<br class=""><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class=""></span></font>Great ideas - let's hear what others think.<br class=""><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class=""></span></font>/D<br class=""><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class=""></span></font><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><img class="" apple-inline="yes" id="16425B27-F131-4587-8114-93B6D5A1CF16" src="cid:4FAB165F-FC65-4373-9306-ED0182DCEF1B"><img class="" apple-inline="yes" id="FF3FF260-CC15-45C0-98AD-5C1DC7F5B307" src="cid:30099606-C2E1-4806-956A-BA3100204C6F"><img class="" apple-inline="yes" id="08E36B81-5EF8-4A25-9D47-2189746C8A84" src="cid:2015AE47-712A-4DC7-AF97-F1DE32BF0014"></div></div></div></div></blockquote><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class=""></span></font></div><br class=""></body></html>