On 14/07/2017 23:57, Davide DB wrote:
- 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.
An excellent argument. Firstly, the question is, does one want to use
the complete screen for the statistics view in the same way as the
planner does? I have a sentiment that the Dive List should be visible in
the statistics view: this reflects the source upon which the statistics
are being calculated and if there is any statistic I would like to check
up, the Dive list is accessible without removing the statistics. But if
the Dive List panel is kept, one is left with a funny three-part screen
surface (current Notes, Profile and Map panels) and the question is if
one could create an efficient statistics view in such an odd area. What
is your opinion? How would you use a larger screen surface than the
small part I used in my mockups?
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 :)
Yes, I fear for my life for the moment he enters the discussion.
More seriously, I think Tomaz's idea of the type of graph he suggested
about 2 weeks ago has merit. I want to ask the question: Has my
duration of cave dives become significantly longer over the last 5
years? Or, has my SAC rate for dives between 40 and 50 meters improved
over the last 20 trips? Yes, I could generate a histogram for each year
by selecting only dives for that year and comparing the histograms
visually, but that is user-unfriendly. Basically, the existing View ->
Yearly statistics could be incorporated into the new framework and,
using the same filter tool, be presented in a graphical way. Therefore
the Yearly/Trip-orientated views. But I understand your point that, from
a future expansion point of view, the organisation of buttons would
present a significant layout problem. Maybe I do not understand your
point. I feel that, it a Statistics View is implemented, then all the
statistics should be incorporated in one single tool. They should not be
scattered over the user interface.
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.
This is a deeper statistical problem. Theory says that, for
non-categorical data, the best interpretive presentation for a histogram
is to use 10-12 bars: take the minimum and maximum values, divide by 12
and use that as the bin size. Of course the problem is that this often
results in inconvenient bin boundaries, e.g. a specific histogram bar
that represents data for dives between 12.4 and 17.8 meters. The way we
think about dive depth it is usually in multiples of 10m. And so, you
are correct. But the statistical requirements of a freediver differs
vastly from those of a deep technical diver. The freediver has, maybe a
maximal depth of 40m whereas the tec diver has dived 150m. Having a
single right-hand histogram bar of ">70m" helps neither of these two
divers because the tec diver probably expects better information above
70m and the freediver has no use for the histogram in the area deeper
than 40m. Therefore a need to have some control over the bin size of the
histogram. There is not a one-size-fits-all solution.
I hope my Ital-english was clear enough.
Perfectly. I hope my English English is understandable.
Kind regards,
willem
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
