Proposal: Statistics in Subsurface

Thu May 7 13:46:33 PDT 2020

I would redesign the statistics page on using a default chart and a
dropdown at the top to select more granular things like yearly, monthly.
when selected the chart just readjust dinamic
Only one tab. more tabs gets confusing and crowdint the screen.
Just an idea.

On Thu, May 7, 2020, 18:37 Dirk Hohndel via subsurface <
subsurface at subsurface-divelog.org> wrote:

> On Thu, 2020-05-07 at 14:37 +0200, Willem Ferguson via subsurface
> wrote:
> > I have been thinking  a long time about graphical statistics
> > facilities
> > for Subsurface, that is presenting the dive statistics as bar graphs
> > or
> > other types of graphics.
>
> This is a topic that we have tried to tackle for something like 5 years
> now. And it is a tough one, in large part because I strongly believe
> that if we do spend the effort to do this, we should do so in a way
> that works both for desktop and mobile - because better statistics are
> the #1 request for the mobile app (ahead of an implementation of the
> planner).
>
> Which means this should ideally be implemented in much of the same way
> as the Maps. As a QML module that can be used in both apps. Which makes
> things harder - but I strongly believe is the right thing to do.
>
> How we should start is with a drawing board and sketches. What are we
> visualizing? Which numbers and data points are likely to be most
> interesting and useful for people - we have learned in the past that
> the answers to this vary shockingly widely. And equally importand, how
> are we visualizing this - just draw things with a pen on paper and send
> a picture...
>
> Once we have that, we can look more into how to implement this. The
> available QML modules for graphics are limited. Check here for a quick
> intro:
> https://doc.qt.io/qt-5/qtcharts-qmlchart-example.html
> Yes, there are much more powerful toolkits available, but I haven't
> found one that doesn't add significant overhead for the mobile
> platforms.
> Someone pointed out to me a while ago that we might be able to use a
> full Javascript charts framework like https://www.chartjs.org/ this
> will require some experimentation for iOS and Android. If someone
> wanted to tackle THAT question (which could happen in parallel to the
> work on the actual design above), that would be great.
>
> > 1) In doing so, I looked at the yearly statistics as implemented at
> > the
> > moment and realised that this is actually a pretty comprehensive
> > statistical framework and that it would be inefficient to write a
> > separate code base for graphical statistical presentation. The
> > current
> > code for statistics is somewhat complicated but perfectly workable.
>
> Correct me if I'm wrong, but I thought that both the yearly statistics
> and the statistics tab use the same backend code (basically
> statistics.c)
>
> > 2) The current statistics tab, accessible from the Notes Panel (i.e.
> > the
> > statistics tab adjacent to the Information tab) actually largely
> > duplicates what can be obtained from the Yearly statistics panel.
> > The
> > only difference is that, currently, the Yearly statistics calculates
> > results based on the whole dive log, while the Statistic tab
> > presents
> > results for all the dives selected on the dive list. However,
> > yearlystatisticsmodel.cpp already already has code that in principle
> > allows calculations for the *selected* dives in the dive log: it is
> > just
> > not activated as far as I can see.
>
> Again, I believe that this is all using the same backend code. And
> ideally we really want to have just ONE spot where we calculate things
> and have the UI layer just deal with how things are presented to the
> user. Typically in the past our code wasn't always very careful in
> following these design goals.
>
> > 3) The main problem with the yearly statistics is that the table is
> > pretty large. In order to make this more user friendly, my proposal
> > is
> > to break the yearly statistics table into smaller chunks and move
> > them
> > over to the Statistics tab.
>
> Yes, the visualization is not great (to be kind)
>
> > 4) This would bring all the statistics together in one place. Seeing
> > that the info in the Statistics tab has no one-to-one connection
> > with
> > the dive profile being displayed, the question arises: should the
> > statistics tab not be elevated to the main menu rather than a tab
> > within
> > the Notes Panel ??
>
> I'm not against the idea of having the graphical representation of
> statistics replace the profile on the desktop - that certainly wouldn't
> work on mobile as the layout there is completely different. My guess is
> that there we'd have a completely separate page, along the lines of the
> dive summary.
>
> > 5) What I am thinking of is to break up the results for yearly
> > statistics and move them over to the statistics tab. The interface
> > may
> > perhaps be a dropdown list corresponding to all the headings on the
> > left-hand side of the yearly statistics. Another dropdown list would
> > have information similar to the column headings of the yearly
> > statistics. One would then select an item from each of the dropdown
> > lists and this would bring up the relevant numbers as well as a
> > graphical representation of these numbers. The min, max and average
> > numbers currently shown in the statistics tab needs to be made
> > accessible in some way, but probably integrated with the above
> > somewhere. This would mean that the existing statistical
> > infrastructure
> > largely remains as is, it is just the UI for showing the results
> > that
> > changes.
>
> Now we are getting into the 'how we visualize' and there textual
> descriptions tend to work very poorly. This really requires some
> pictures.
>
> > Does this look like a viable approach at all?
>
> I would love to get more people into this conversation.
>
> /D
>
> _______________________________________________
> subsurface mailing list
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20200507/1f4ad57d/attachment-0001.html>