Statistics Reloaded.

Tomaz Canabrava tcanabrava at kde.org
Fri Jul 7 00:48:22 PDT 2017


Davide,

I remember something about statistics that you did, I'm gonna take a look
on the mockups again. Thanks for reminding me.

Tomaz


On Fri 7. Jul 2017 at 08:57, Willem Ferguson <
willemferguson at zoology.up.ac.za> wrote:

> On 06/07/2017 22:44, Davide DB wrote:
>
> Hi guys
>
> Do you remember I sketched tons mockups for statistics maybe two years
> ago?
>
> On 6 July 2017 at 22:18, Tomaz Canabrava <tcanabrava at kde.org>
> <tcanabrava at kde.org> wrote:
>
> Willem,
>
>
> Thanks for your feedback, I'll play more with this on the weekend. I do
> believe that your ideas are nice and I'll experiment with them. If you
> want
> I can give you my branch for you to test and experiment too.
>
> Actually, considering that I'm by no means a good math person, do you mind
> to create mockups for all possible statistics that you can think
> Subsurface
> should provide?
>
> This will help me a lot.
>
> Tomaz
>
> Tomaz, Davide,
>
> I think the statistics on the current statistics tab are probably those
> that would mostly be looked at. There are two types of display that one
> would probably like:
>
> 1) Summary information for a selected number of trips or time periods.
> This is exactly what you proposed in your mail: A number of bars indicating
> min/mean/max for each trip or time period.
>
> 2) More detailed information for a specific trip, dive site or period.
> This assumes one can select the trip, dive site or period. That could be
> done from the dive list. In this respect I like Davide's idea of using the
> filter tool to select some of the dives. The information could be displayed
> as a histogram/bar chart as Davide suggested. For instance, show a bar
> histogram of dive depth for a particular group of dives; or a histogram of
> SAC for a particular period.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> The last question is to what we can realistically expect Tomaz to do. I
> offer to mess with the present Yearly Statistics menu item, using C/C++ to
> print only the numeric statistics of one of the four variables and to
> select which variable is being shown in text. Then Tomaz can take the text
> and turn it into a graphic that is mobile-compatible. Someone else may wish
> to adapt the filter tool. But first we need some type of consensus that the
> above approach is indeed the one to go.
>
> Apologies for a long email.
> Kind regards,
> willem
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170707/32c1880f/attachment-0001.html>


More information about the subsurface mailing list