Statistics Reloaded.

[Davide DB]

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 <willemferguson at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170714/3972a533/attachment-0001.html>