Hi Willem, I'll try to resume my proposal here and I try to comment to your questions.
On 7 July 2017 at 08:57, Willem Ferguson <willemfergu...@zoology.up.ac.za> wrote: > We need to think about the most common criteria that a diver would require > for statistics. I think these are probably: > > a) Start date and end date (a bit more flexible than just selecting calendar > year) - this can currently be done by selecting from the dive list > b) Dive site(s) - this could currently be done from the filter tool. > c) Trip(s) - This could currently be done by selecting from the dive list > d) Depth range - This cannot easily be done at present. e.g. SAC for > different dive depths. > e) Davide suggested Run time - This cannot be done at present., e.g. Depth > for different run times. In my wireframe I run my imagination free so I added everything I could think of. Hence we can happily forget runtime filter. > So, the ease of selection of dives to be analysed is just as important as > the statistics graphs shown for these dives. A starting point for selection > would be to show statistics for the currently selected dives in the dive > list, either selected by hand on the dive list or through the filter tool. > But Davide's proposal at > http://i.imgur.com/6d1eF4N.png > is compelling. He used the current filter tool and added three more items > for filtering: date, depth and dive duration. > > The question is: how should one, in addition, select the item to be analysed > (Depth, Duration, Temperature,SAC)? Davide solves that by using tabs on the > Info Panel. The trick is to implement something that does not congest of > clog the visual display. The current desktop display is already pretty full, > so showing a selection space-efficiently is a challenge. If this applies to > the desktop, then there are even more challenges on the mobile version. I don't get you here. Items to be analyzed are those you find into the multifilters. Of course, some of these quantities will appear as stats results too. e.g. depth: you have a filter for it but you have a depth graph too. In my idea the stats tab should be removed because I always found it misleading because that tab is graphically linked to one dive while it displays stats for all or some selected dives. We could leave "Yearly statistics" in the view main menu. You access it from the main menu so its meaning it's clear. Regarding in-depth statistics I think that regardless of the UI action we choose to display them, the "stats view" is always displayed along the multi-filter panel. *Prerequisites:* - By default no filter is applied, so stats refer to full logbook. - once you play with the multi-filter you get stats for selected subset. The challenge here is UI consistency so my proposal to access "stas view "was: *#1 Key combination (CTRL/Apple + Something) or item from the main "View" menu.* You get this screen: http://i.imgur.com/6d1eF4N.png where multi-filter is initialized with proper values from logbook. e.g. depth slider min/max values reflect user logbook and so on. Stats are live updated while acting on multi-filter OR using "statistics" button on multi-filter (you decide what's it's better). *#2 "Statistics" button on multi-filter panel.* Currently we have a "filter dive-list" item in "Log" menu. This brings to a view more or less like this: http://i.imgur.com/tix3ImE.png You filter the dive list based on your multi-filter choices. Now we will add that "Statistics" button. You press it and the lower panels (dive info, graph, divelist, marble map) will be substituted by the stats panel. Basically you get this http://i.imgur.com/6d1eF4N.png that is the #1 use case. I think I covered all use cases but of course I wait for your feedback. Regarding screen real estate, vertical space it's the most precious with screen resolution 1366 x 768 being the worst I tried. Hereafter some comments: *Multi-filter space congestion.* I remember Tomaz wrote he implemented this widget with modularity in mind so we could add more filters in the future like plugins. I see that horizontal space could be a problem. In the wireframe I add some filters as textbox on top of combo boxes. As today the the most important filter missing is a date range control. I see that "Trips" are important to many users so a filter for them would be important. Do not forget that currently we have a small arrow button to collapse multi-filter giving plenty of space to filtered dive list or future stats panel. *Idea: we could choose form preference panel which filters we use the most: which filters I want to display in the filter panel. Once we have more filters than available space I could just add/remove them. The same idea would apply to the infinite button list on our dive graph. I never used most of them and we could choose in prefs panel which button I want on the graph.* *Stats panel congestion.* Originally I proposed two UI implementations: tabbed pane or master detail pattern: - Tabbed pane: a classic but maybe somehow obsolete design. It gives the maximum horizontal space, wasting very few vertical space. - Master details pattern: modern UI but it waste a lot of horizontal space. *Both approach have the benefits that you could implements statistics in several steps (adding tabs/items) and the UI seems complete.* Master details pattern: http://i.imgur.com/GdH6psp.png Tabbed pane (you already saw it): http://i.imgur.com/6d1eF4N.png *About usability.* IMHO current multi-filter lacks of an important text message to the user: When there is no filtering in action the string is: *"You have 523 dives logged"* When I apply one or more filters the message is: *"You selected XX dives so far..."* > The biggest impediment to statistics on the mobile version is the inability > to select or filter dives. This will probably only become realistic once we > can collapse dive trips on the mobile dive list because there are optimised > tools for doing list selection in the mobile environment. In fact, we are > already doing that when, on mobile, we select the already-downloaded dives > to be added to the dive list. > > I would strongly support the principle of doing the statistics in QML > because that reduces duplication of development. > > After a long and meandering argument, here are my specific suggestions: > > 1) The current item Yearly Statistics in the View Main Menu item should be > the primary way of obtaining min/mean/max graphs. Currently this shows > statistics for all 4 the variables: depth, duration, SAC and temperature. > The default display could be depth, with an on-panel radio button to select > which of the 4 variables needs display. Alternatively Davide's idea of tabs > on the same panel. BUT: this panel should present min/mean/max statistics > only for the dives that are selected in the dive list. If no dives are > selected, then all dives are analysed. > > 2) Remove the current Statistics tab in the Dive Notes panel of a dive > because these data do not pertain to the specific dive being shown at the > time: it pertains to the dive list. Under View in the Main Menu, add another > item Detailed Statistics, which allows histograms for specific variables for > the selected dives in the dive list. If no dives are selected, then all > dives are analysed. There is a need to select which of depth, duration, SAC > and temperature should be shown (probably depth by default, with either > radio buttons or tabs to choose between variables). > > 3) Implement Davide's idea of adding two more items to the filter tool: > dates, and depth. I am not convinced that a filter for dive duration will be > extremely useful. It would need additional screen space in an > already-congested area. Forget about it > So it turns out that for efficient statistics rendering, the main work is > actually not in generating statistics and graphics, but in generating ways > to select the dives to be analysed. I 100% agree with you I will add everything to Github issue tracker for better traceability. Bye -- Davide https://vimeo.com/bocio/videos
_______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface