Statistics Reloaded.

Davide DB dbdavide at gmail.com
Fri Jul 14 14:57:50 PDT 2017


On 14 July 2017 at 19:43, Willem Ferguson
<willemferguson at zoology.up.ac.za> wrote:
>
> The Tabbed Pane approach wastes a lot of screen space on the left hand side
> of the screen. In addition, the present Notes Pane UI already is
> tab-oriented within the Notes Panel and one would not want to change the
> look-and-feel now. In contrast, tabs use much less space.

I guess you meant "master detail pane" wastes left hand side space.
I agree with you: tabs are space savvy and we already use them.


> 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"
>
> This is already shown at the top of the filter tool, if I understand you
> correctly. "Filter shows ** out of ** dives"

You are right. I forgot it.

> My proposal is as follows.
>
> Initially we stick to the statistics that are currently shown (Depth, SAC,
> Temp, Duration), but design in the ability to expand if it would be
> required. From your mockups I am not sure what other information you think
> may be necessary. So, below, I stuck to the four basic variables already
> calculated in the present version.
>
> Look at Depth_stats.jpg, attached. I cut down the filter in order to make
> use of the screen space as efficiently as possible. The Depth filter and the
> Date filter need to be added to the existing filter tool. Then there are
> three button options:
>
> 1) present aggregated statistics for the filtered dives.
> 2) show statistics for each trip for the selected dives
> 3) show statistics for each year for the selected dives.
>
> If no dives are selected, then statistics are calculated for the whole dive
> log.
>
> 1) Aggregated statistics for the filtered dives, activated by the button
> "Filtered statistics" in the filter panel. There are five tabs,. one ofr
> each of the four variables currently calculated, plus "Summary statistics".
> See Depth_stats.jpg, attached. The statistics are presented as a bar graph
> (more accurately a histogram) plus a calculated mean value. The "Summary
> statistics" present the maxima and minima, the same data shown in the
> existing Statistics tab. I honestly think these data still have value,
> independent of the histograms. See the attached Summary_stats.jpg. Important
> here is that all statistics should be indicated in appropriate units and
> that proper statistical terminology is used.
>
> 2) Trip Statistics. Here I assume that the user is interested in long term
> trends in variables. e.g. long term change in SAC rate, depth or duration.
> Therefore the correct labelling of individual trips is not required and a
> numbering from first to last is sufficient. If the user wished for a
> specific trip, this could be extracted by selecting that trip using the
> filter and using the Filtered statistics button. See the attached
> Trip-Depth_Stats.jpg.
>
> 3) Yearly Statistics. This follows the same principle as in Trip Statistics,
> but represents data for each year in the selected set of dives.
>
> Since the bar graphs in the Trip Statistics and Yearly Statistics tabs show
> minimum, mean and maximum, the summary data currently viewed under "View ->
> Yearly statistics" can probably by removed from the code.

While I agree with you to start with basic quantities as Depth, SAC,
Temp, Duration, I find that proposed UI layout a little bit
complicated. I'll try to explain me better:

- We all agree that space is a problem but in this layout we have in
the same screen: map, dive-list and dive profile which occupy/waste a
lot of space.

- Once the user filters dives getting a subset of them, the map and
dive profile becomes immediately useless if not wrong. They would
display data for the latest dive selected before the user played with
stats. e.g. I have a wreck dive selected from he dive list and then I
filter only cave dives. Right now the map and dive profile get updated
with the first dive in the filtered dive list.
 While I understand that a solution like this works (we have stats and
filtered dives analysis in one screen, WOW) why all of this
complexity?
I'd rather prefer a more KISS approach. One feature at the time.
Do I need to find and analyze some dives? I use the Log > Filter list
feature currently implemented.
Do I need stats for all of part of my dives? Let's use the stats view.

On my 1920x1200 24" desktop Dell monitor current multi-filter is ok
but on one of my old 1280x720 laptop I get nervous after few minutes.
Dive list below multi-filter is barely usable. Filter, Stats and Dive
list would all share the already rare vertical space. It would be a
shame having stats graph in a so small space.

Regarding the three buttons (trips, yearly, filtered) I do not fully
understand how "Yearly" and "Trips" work with other filters. What's
happen if I select "John Doe" and then "Yearly" or "Trips"?
AFAIK they are just prepacked selections I could obtain with proper
filters (e.g. I could get yearly just using date sliders... I could
get trip stats just selecting one or more trips from a combo box with
all of them and then using stat tabs below...) Moreover once we need
another special prepacked selection we would add another button...
I'm under the impression that those button breaks the filter meaning:
we should have basic quantities filtering on multi-filter and then
playing with data in the stats view (graphs, tables and so on).

Maybe it's a moot point. I expect Dirk entering this discussion armed
with Hattori Hanzo's Sword soon :)


> There are two problems that still need solving:
> 1) Currently the Yearly statistics menu option can extract data for dive
> types, i.e. OC, pSCR or CCR. This could be obtained via yet an additional
> filter field or a preference setting and is in principle easily solved.

Yes

> 2) More complex is the issue of the bin sizes of histograms. E.g. in
> Depth_stats.jpg the depth increments are 10m for each bar. What if all dives
> were performed in the depth range 10-20 meters? This would result in a
> histogram with a single bar. Not satisfactory. So we need to have a feature
> to halve the bin size, i.e. to reduce the interval for each bar to half of
> the present size (i.e. 5 m in this example) or to some smaller number. The
> most simple would be to have a text box or a dropdown box in the graphic
> field in which a default bin size is used and with which a different bin
> size could be specified. But I am not sure which way is the most acceptable
> from an intuitive UI point of view.

IMHO axis range should be automagically calculated by the program
based on data content exactly as the current dive profile. No user
option.

I hope my Ital-english was clear enough.

Bye

-- 
Davide
https://vimeo.com/bocio/videos


More information about the subsurface mailing list