<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hallo Davide,<br>
<br>
Thank for your informative reply. I will address a number of the
isssues you raised and make a few proposals with screen mockups.
Responding to your last message:<br>
<br>
<blockquote type="cite">
<div><b>Stats panel congestion.</b></div>
<div><br>
</div>
<div>Originally I proposed two UI implementations: tabbed pane or
master detail pattern:</div>
<div><br>
</div>
- Tabbed pane: a classic but maybe somehow obsolete design. It
gives the maximum horizontal space, wasting very few vertical
space.<br>
- Master details pattern: modern UI but it waste a lot of
horizontal space.
<div><br>
</div>
<div style="font-size:12.8px"><u>Both approach have the benefits
that you could implements statistics in several steps (adding
tabs/items) and the UI seems complete.</u></div>
<div style="font-size:12.8px"><br>
</div>
<div style="font-size:12.8px">Master details pattern: <a
href="http://i.imgur.com/GdH6psp.png" target="_blank"
style="font-size:12.8px">http://i.imgur.com/GdH6psp.png</a></div>
<div style="font-size:12.8px">Tabbed pane (you already saw it): <a
href="http://i.imgur.com/6d1eF4N.png" style="font-size:small">http://i.imgur.com/6d1eF4N.png</a></div>
<div style="font-size:12.8px"><br>
</div>
</blockquote>
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.<br>
<br>
<blockquote type="cite">
<div style="font-size:12.8px"><b>About usability.</b></div>
<div style="font-size:12.8px"><br>
</div>
<div style="font-size:12.8px">IMHO current multi-filter lacks of
an important text message to the user:</div>
<div style="font-size:12.8px"><br>
</div>
<span style="font-size:12.8px">When there is no filtering in
action the string is: </span><i style="font-size:12.8px">"You
have 523 dives logged"</i><br>
</blockquote>
This is already shown at the top of the filter tool, if I understand
you correctly. "Filter shows ** out of ** dives"<br>
<br>
<blockquote type="cite">
<div><b>Multi-filter space congestion.</b></div>
<div><br>
</div>
<div>I remember Tomaz wrote he implemented this widget with
modularity in mind so we could add more filters in the future
like plugins. I see that horizontal space could be a problem. In
the wireframe I add some filters as textbox on top of combo
boxes. As today the t<span style="font-size:12.8px">he most
important filter missing is a date range control. I see that
"Trips" are important to many users so a filter for them would
be important. </span>Do not forget that currently we have a
small arrow button to collapse multi-filter giving plenty of
space to filtered dive list or future stats panel.</div>
<div><br>
</div>
<div><span style="font-size:12.8px"><i><b>Idea</b>: we could
choose form preference panel which filters we use the most:
which filters I want to display in the filter panel. Once we
have more filters than available space I could just
add/remove them. The same idea would apply to the infinite
button list on our dive graph. I never used most of them and
we could choose in prefs panel which button I want on the
graph.</i></span></div>
<div><br>
</div>
<div><br>
</div>
</blockquote>
I agree that is an option, and would require another page in the
Preferences (which is in principle organised as a Tabbed Pane!)<br>
<br>
My proposal is as follows.<br>
<br>
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.<br>
<br>
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:<br>
<br>
1) present aggregated statistics for the filtered dives.<br>
2) show statistics for each trip for the selected dives<br>
3) show statistics for each year for the selected dives.<br>
<br>
If no dives are selected, then statistics are calculated for the
whole dive log.<br>
<br>
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 <b>Depth_stats.jpg</b>, 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 <b>Summary_stats.jpg</b>.
Important here is that all statistics should be indicated in
appropriate units and that proper statistical terminology is used.<br>
<br>
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 <b>Trip-Depth_Stats.jpg</b>.<br>
<br>
3) Yearly Statistics. This follows the same principle as in Trip
Statistics, but represents data for each year in the selected set of
dives.<br>
<br>
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.<br>
<br>
There are two problems that still need solving:<br>
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.<br>
2) More complex is the issue of the bin sizes of histograms. E.g. in
<b>Depth_stats.jpg</b> 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.<br>
<br>
I hope all this makes sense.<br>
<br>
Kind regards,<br>
willem<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>