(Puff) This was my last serious attempt to do something userfull to subsurface, almost 4 years ago. I basically gave up with around 120 - 140 commits because no way I did pleased everyone.
It’s something I would like to get it right, tougth. I’ll try again. Dirk, there’s a chart qml library that I’m using for a personal project, not qt quick charts, that thing is broken by design, that I think it can work. Best Tomaz On Thu, 7 May 2020 at 21:47 Chirana Gheorghita Eugeniu Theodor via subsurface <[email protected]> wrote: > 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 < > [email protected]> 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 >> [email protected] >> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface >> > _______________________________________________ > subsurface mailing list > [email protected] > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface >
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
