Subtotals and running totals in the logbook view

Currently, MyFlightBook users can get printed reports with page totals and running totals (and optionally previous page totals) for the currently selected subset of flights. The user can select a particular layout and add or exclude properties from the printed report, as well as request that each page should contain a specific number of flights.

This printing feature of MyFlightBook has several limitations, however. There is no way for users to define their own layouts, and there is no way to save, name and reuse or share (possibly modified) layouts. The ability to add or remove properties from the layout is also very limited. Issue #479 addresses all of these limitations.

MyFlightBook forces printed reports to include all flights (no filtering) in ascending order. The printed report can compute subtotals only for each group of approximately N flights per page, and not for any other grouping criterion. Here, we offer a broader solution to grouping and summarizing flights that eliminates these deficiencies.

There is a strong case to be made for putting subtotals (and running totals) following groups of flights in the normal logbook view. This approach doesn't have the limitations of printed reports mentioned above. This feature is general purpose, and satisfies many real-world requirements.

Apologies for the length of this post, but there are quite a few issues to discuss :

Subtotals per page vs for "every N flights"
Ways to group flights
Types of totals
Paged vs continuous logbook view
Sort order
Totals with subsets of flights
Describing groups of flights
Displaying totals
User interface
Motivation

Subtotals per page vs for "every N flights"

A principle motivation for per-page totals on a printed report is to facilitate maintaining manual logbooks (though this is an old habit and an archaic practice). This objective is thwarted by the fact that MyFlightBook can't guarantee a fixed number of flights per page. However, users might be interested in subtotals for any number of subgroups of their flights.

With totals displayed in the normal Logbook view, there is no problem providing totals for a fixed number of flights per group. Subtotals can easily be produced, for "every N flights" ... or for any other type of group.

Ways to group flights

With respect to printed reports, we've been discussing providing totals/subtotals for every page of N flights out of a chronological list. However, grouping flights based on their chronological sequential order and number of flights on a printed page is just one way to group flights. Thinking about subtotals as a “per-page” feature is misleading.

It’s really more appropriate to think of grouping N flights in a date-ordered list, regardless of how many pages it takes to display the flights. For such a list, N means a number of flights, not the number of lines on a (printed) page.

Flights could be grouped by any shared characteristic, such as:

N consecutive flights (in a chronological list)
each month or each week (in a chronological list)
day or month name (across periods)
airports visited
aircraft flown
aircraft types flown
student, instructor or pilot name

It seems reasonable for MyFlightBook to provide a set of pre-defined grouping criteria (e.g., the list above). Many other groupings (day vs. night, VFR vs IFR for example) can be addressed with filtering rather than subtotals. On the other hand, user-defined grouping criteria might make sense.

Another idea is to support grouping criteria (pre-defined or user-defined) based on multiple properties (e.g., day/night flights by month). Probably overkill though.

Types of totals

Subtotals for a group of flights makes sense regardless of the grouping criterion, and regardless of filtering or sort order, and regardless of how many lines/pages their display requires.

Running totals per group of flights make sense only when the list is in ascending order by date. MyFlightBook should preclude running totals otherwise.

Grand totals always make sense at the end of any list of flights, regardless of filtering or ordering.

Paged vs continuous Logbook view

Having a paged view of the logbook with running totals and subtotals no doubt works fine. However, the typical use case for this feature may not be to interactively scroll through and up and down over a number of pages. Some users might want to print the entire logbook (e.g., “Print to PDF”), where the continuous view would be more useful (especially if the goal were to facilitate entering data in a manual logbook). So, totals should be available with either continuous or paged format. I can’t comment on any performance issue there may be with a continuous format.

Sort order

Subtotals make sense whether flights are in ascending or descending order by date (or any other criterion). The only exception is that running totals should be used only when flights are in ascending order by date.

Totals with subsets of flights

Subtotals are not incompatible with a subset of flights (defined by searching/filtering). Currently, MyFlightBook provides totals for a (single) subset of flights by searching for a set of flights, and selecting Totals from the menu bar. So, totals are already available for fewer than ALL flights. Of course, this feature does not provide a way to get subtotals for multiple subgroups at once.

A subtotal is useful for any group of flights that share some characteristic, even for a groups within a subset of all flights. Among the many ways to filter flights, perhaps date range is the most obvious, but any of the existing search criteria are reasonable to use, even in combination.

Running totals are useful for a subset of all flights (e.g., those flights in a range of dates). This set of totals would not be helpful for filling in a manual logbook, but is sensible for other scenarios. A user might want to see running totals by month for the current year, or since he first soloed or similar criteria. Perhaps a user wants to see running totals only of his night flights during the recent past. It seems best not to be overly restrictive, and allow running totals even when dealing with a subset of all flights, so long as they are in ascending order.

Describing groups of flights

Similarly to the way MyFlightBook lists the criteria being used to filter flights ("Only flights matching these criteria are shown"), some description of the flights being summarized should appear for each group of flights, followed by the totals:

Subtotals for the last N flights from dd/yy/yyy through mm/dd/yyyy
Subtotals for monthly/weekly between dd/yy/yyy through mm/dd/yyyy
Subtotals for aircraft tail number XXXXXX
Subtotals for flights visiting airport XXXX
Subtotals for flights on Saturdays
Subtotals for flights in December
Subtotals for flights for student/instructor/pilot XXXX

Displaying totals

The template feature described in issue #479 allows the user to control the set of parameters displayed in the logbook view. All numeric values that can be summed would be presented in the totals and subtotals lines of the listing, using a "short name" for each property.

Since there are likely several/many flights per subgroup, these totals lines should be shaded or boxed differently from the surrounding white or gray shading used for flight details.

The "xxxx" above would be the short name of the property being totaled. Some totals might be whole numbers, and some might be hours.fractional_hours.

User interface

The Search page seems to be the right place for specifying whether or not totals should be displayed (though "Search and Group" is more accurate).
The user interface could look like this:

The running totals option would be available only when the flights are in ascending order. Alternatively, MyFlightBook could change the sort order for the current result set, but that seems odd to do for the logbook view. The logbook view displays the flights the user has searched for, in the order he specified. This differs from printed reports, where all flights are always included. in ascending order (regardless of the most recent search the user did).

Using a drop-down, the user can chose among a set of "reasonably" sized subgroups of flights. (It doesn't seem necessary to permit grouping by every integer, such as "every 17 flights".)

The grouping criterion should be sticky, as the user might wish to change search options to select a different set of flights to be displayed in the logbook view, keeping the same display format.

Motivation

This feature of putting totals in the logbook view is a more general solution than printed reports, and is useful in these ways:

facilitating or double-checking totals in a manual logbook (still a desire of some users)
satisfies basic curiosity of pilots wanting to check their progress and summarize flying activities
for a CFI with multiple students (possibly for billing)
for a student to correlate an instructor with a group of flights
for a club manager to see how the club's planes are being used
addresses a shortcoming of MyFlightBook compared to other electronic logbooks

Although manual logbooks (with their subtotals) may be archaic, there are surely many plausible other reasons to summarize flights with totals.

Initial comment on subtotals: I already have 90% of this functionality; it's not at all clear to me that periodic subtotals (at least not based on number of flights) is the right way to get the other 10%, or that my existing solution is inadequate/problematic in a way that subtotals would improve.

The 90% that I have:

You can click on "Analysis" to see your top-line totals grouped by day, week, month, or year. This corresponds to a real need pilots have ("how many hours of PIC did you have last month?").
Those top-line totals include running totals
You can very easily copy the data (both per period and running) into a spreadsheet, or click on a period to see the constituent flights.

The 10% I don't have:

It's currently a fixed set of field you can group/subtotal (Total time, landings, approaches, night, simulated IMC, actual IMC, cross-country, dual, ground sim, PIC time, CFI time, SIC time, flights, and flight days), so you can't do arbitrary summable numeric properties here.
You can only see one field at a time.

Both of those are legitimate features, but I think the right way to address this is to enhance the Analysis tab as opposed to adding subtotals.

But let me back up a bit: there's the proposal here of doing this every "N" flights. I group by time period because pilots have actually expressed a need to summarize by year or month. I've never heard of anybody needing to summarize every N flights, though. The ONLY scenario I can see for that would be facilitating double-checking of totals in a paper logbook, but even there it doesn't work:

You can check your paper math with simple search queries, if that's what you want. So the functionality is already there.
Paper logbooks don't have a fixed number of flights per page either. See the picture of my logbook from issue #460. So doing this every "N" flights will quickly get out of sync with your paper logbook anyhow.
At some point, you gotta trust that the computer doesn't make math errors. It's the 21st century; if you doubt my math, I'm not likely to satisfy you on other functionality
You can quickly get appropriate subtotals by going to the analysis tab, finding the period that corresponds to the page in your paper logbook, and clicking it. Tally your paper logbook by week or month and this works great.

So let me pull that part out into a new issue #482 to cover analysis enhancements there.

The other issues about grouping/sorting/etc. I'll respond to those separately, since I think they're distinct issues.

Types of totals:

Grand totals always make sense at the end of any list of flights, regardless of filtering or ordering

On the printed page I agree with you, because you can't interact with it. In an interactive environment, I disagree. There's no need to scroll way down or page to the 50th page to see totals; clicking "Totals" gives you this directly, and you can expand/collapse it. So why stick it at the end?

I still think subtotals interspersed in the list of flights is a terrible way to see the totals per group, as opposed to actually doing an interactive report. The analysis tab or search functionality can do this.

BTW, an answer I've long given for this sort of deep analysis is "Excel Pivot Tables are an amazing thing." I can't hope to match Excel's power and flexibility here; I don't see the point of trying to do so. What I can do is try to make actual real-world scenarios easy, and leave the hypothetical ones and "it could be interesting" ones to Excel.

Paged vs. continuous view - I'm not sure what you're comment or suggestion is here. I support both today. Paged is much more efficient from a performance perspective, but you can do whichever you prefer. What was the suggestion?

ditto your comments on sort order.

Totals with subsets of flights: you can search for a subset of flights and then click the Analysis tab to see your totals grouped by various date periods. So yes, I would need to address #482 to allow you to see multiple aspects at once, but otherwise it seems to me that you can do all of the scenarios you describe today. E.g., want to see you running totals year-to-date? Piece of cake today: search for year-to-date then click the analysis tab. That's seems significantly easier than scrolling through your flights and looking every so many flights at the subtotals, where you may have already scrolled past the last grouping of subtotals, which makes it hard to see how things vary month to month, for example.

BTW, you also mention grouping by aircraft. That is indeed an interesting scenario. I do give some data here in the Aircraft tab (sort by "Recency of flight"), but it's not a bad idea to consider adding aircraft (or model) as an option for the X axis in analysis. That may, however, be getting into "Excel Pivot tables are an amazing thing" land. :)

For displaying totals: here's where things get really complicated. If I were to break every so many flights (month boundaries, or year boundaries or xxx boundaries) and show subtotals, I think you can't have arbitrary subtotals there. They HAVE to correspond to the columns under which they are displayed or else things just look wrong - both from an alignment perspective (if the number of subtotal columns doesn't equal the number of columns in the flights above it) and from a logical perspective (the human brain is going to want to be able to tie the subtotal to the cells above it). E.g., if you have "Number of ILS approaches" in a subtotal, then the column above it needs to be ILS approches and you need to be able to add them up and tie to the subtotal.

So this immediately requires either doing issue #479 first, or having the subtotal columns be fixed.

But I still come back to scratching my head about why a periodic display of subtotals interspersed in the list of your flights is a better solution than having it in one place (i.e., the analysis tab). That's why I did the analysis tab. What's broken about it?

Took a brief look at the code last night before bed to remind myself how the analysis stuff works and I realized another key benefit to doing this as a report (which is what the analysis tab really is) rather than periodic subtotals: the report (summarizing your flying by month or week, etc.) is a histogram, which subtotals are not. That means that it can capture not only the flying you did but also the flying you didn't do. E.g., if you display subtotals at the end of each month, then you either miss the fact that you did no flying in December, or you have two identical subtotals back-to-back (November subtotals followed immediately by identical December totals).

Also, in a report format, you can always have an effective ascending date sort order, which allows running totals.

But I still think a report structure is the better way to address the scenarios you describe than a dispersed periodic display of totals.

Analysis vs Logbook view with totals

I still come back to scratching my head about why a periodic display of subtotals interspersed in the list of your flights is a better solution than having it in one place (i.e., the analysis tab). That's why I did the analysis tab. What's broken about it?

I think the right way to address this is to enhance the Analysis tab as opposed to adding subtotals.

Conceptual overview Printed reports, the Analysis tool, and the Totals tab all present totals, but each capability addresses different use cases, and have different features, strengths and limitations as compared with each other. The logbook view addresses many other use cases, and has different features, strengths and limitations. Different use cases often require different tools even if the tools are similar in some ways. Some things are easier to do with one tool than another.

The Analysis feature isn't broken. It's very powerful and easy to use. The functionality of the Analysis tool is very different from having totals displayed within the logbook, and serves very different purposes. The visual representation in the chart is a great way to see trends in one of 11 popular or useful or certification-related metrics (though users might want to analyze other metrics as well). The logbook of course wouldn’t really show trends, but it can present totals for multiple metrics in a compact and easy to use way.

Having totals available in different ways is not problematic. There is no reason MyFlightBook couldn’t support showing totals in the logbook view along with Reports, Analysis and Totals.

Interactivity It’s nice that the Analysis chart is quite interactive, which the logbook view is not. I can click on a bar or running total dot in the graph (or a number in the running totals table) and see the corresponding flights. But when I do, the totals are no longer visible. And the only flights shown are those corresponding to the date range of the place I selected. I then have to turn that off (the red X) and go back to analysis to look at a different group of flights. Each time I do, there is (likely) work done on the server. The proposal here would display totals and running totals for multiple groups of flights in a tabular format, right along with the details of the flights of the group, with no extra performance hit.

In the Analysis tool, I can hover over a bar or running total dot and see a single data point for a single metric (the number of landings or total flight time, for example). However, if I hide the raw data, I can’t see all the data points at once. I can only download (cut/paste into a spreadsheet) the running totals one metric at a time (until you enhance the Analysis tool to show multiple totals in the table).

The Analysis feature only totals those metrics in the "See your trends" drop-down menu. The logbook approach makes it easy to see (and download, possibly through cut/past) the raw data and the totals for multiple metrics, along with the flights. By using a template to control the logbook view, the user can specify the set of properties that will be totaled/subtotaled.

There is a lot of extra work going on behind the scenes here (with a performance hit to the server), or imposed on the user, as compared to a logbook listing with interspersed totals. It's actually a plus that the logbook view isn't nearly as interactive as the Analysis tab.

Grouping flights The trend analysis of the Analysis tool permits grouping only by time periods. The grouping criteria proposed for the logbook feature is a superset of what Analysis can do (if "group by year" is added). Although you plan per issue #482 to add aircraft model and tail number to Analysis for grouping, it's not clear how you'll graph those if at all. Other grouping criteria like airports visited or the names of a student, instructor or pilot would similarly be difficult to graph, but are interesting grouping criteria.

The search functionality plus the Analysis tool can provide totals for a single subset (group) of flights. This really isn't a reasonable way to see totals for multiple subsets (groups) of flights. To see totals for more than one subset of flights, it's necessary to specify a new query, and revisit the Analysis tool, along with considerable clicking and navigation, as well as server work.

The logbook view has the significant advantage that in one step, the user can view group-level totals for all of the metrics in which he is interested, for multiple groups. He can scroll through the logbook to find a particular group of flights and see the totals right there. There's no need to execute a search and navigate around the application for each subset of flights.

For example, if an instructor wanted to get a list of flights grouped by the student name, he simply views the log, scrolling through to look at the flights of a particular student very easily, along with the subtotal for that student. The same idea would work for a club manager who wanted to see the flights and total hours each club aircraft was used, or the flights and totals for each of the pilot members of the club. Similar scenarios apply with respect to other grouping criteria. It is just much more complicated to get similar information using the Analysis tab.

Date order and gaps in time

You also point out above that

in a report format, you can always have an effective ascending date sort order, which allows running totals.

As mentioned above, the UI could offer running totals only when the current result set is ordered by ascending date. There is no need for that ordering unless running totals are to be included. Running totals work fine in a logbook view, and don't lead to a requirement for a "report format", only that the data be in ascending date order.

You also made the point that histograms

"can capture not only the flying you did but also the flying you didn't do".

Well, that is surely more obvious visually with histograms, but you can also see gaps in the logbook view. With monthly subtotals, the November group of flights would be followed by the January group. The gap is there, and with a helpful description to the left of the subtotal row ("Subtotals for flights in December"), it's not so hard to perceive the gap.

Metrics summarized The Analysis tool can summarize only a pre-defined set of numeric flight properties. This is no doubt a common and typical use case. But surely there are valid reasons users might want to see summaries other metrics. For example, an aerobatic or student pilot might be interested in his totals of various maneuvers and none of the other "normal" properties. A user might want to see totals of various types of approaches, landings or takeoffs.

Neither printed reports nor the Totals tab would serve these purposes well. Supporting complete user customization of the print template would surely be a lot of work. While the Totals tab might be enhanced (maybe via templates?) to allow the user to specify totals of interest, the (current) display formats are not very compact. And as discussed, these two tools don't produce totals for multiple groups at one time.

Summary The Analysis tool provides a lot (maybe not 90%?) of functionality related or similar to totals within the logbook. The Analysis tool addresses some of the possible usage scenarios, often not in a straightforward way, while not addressing others at all. There are differences between the two approaches with respect to metrics, subsets of flights, grouping criteria and performance.

Totals in the logbook have several advantages / differences vs. the Analysis tool:

Instead of a pre-defined list of properties, the logbook can summarize any numeric property (specified in a "display template") when new properties are added. The “See your flying trends" prompt could be a drop-down of 600+ properties, but that’s awkward, at best. Perhaps Analysis could also use templates, though that wouldn't specify a particular metric to summarize.
Via a display template, the users would specify a set of metrics for summarization, and the logbook can show totals of multiple metrics at a time. Changing the Analysis tool to show multiple totals and running totals is a good idea, but there currently is no user control over which totals are tabulated. The graph, of course, shows only one metric.
The logbook view can show subtotals for multiple groups of flights at a time. The Analysis tool summarizes only the entire current flight result set. It's hard to imagine how it could support multiple groups in a compact way. It would likely require considerable development work to address this.
The logbook view can support useful grouping criteria other than time periods (such as names, tail numbers, etc and even "Every N flights" ... ha!). These are not currently available in the Analysis tool, and might be awkward or difficult to add.
The logbook approach imposes no performance hit on the server. Repeated use of either the Analysis or Totals tool (for many of the scenarios I mention) requires multiple searches and computation. The logbook view has limited "interactivity", whereas a click in the Analysis tool may cause server work. Using the logbook to display totals also causes less work for the user ... fewer clicks, less navigation and no hard thinking about how to get what he wants (whether it's multiple uses of the Analysis tool or using Excel).

Grouping criteria

doing this every "N” flights … I group by time period because pilots have actually expressed a need to summarize by year or month. I've never heard of anybody needing to summarize every N flights, though.

As enumerated above, there are other ways to group flights other than time periods. You found it appealing to group by aircraft and aircraft model, but why not names of students, etc.?

Grouping by the last N flights is only one of many possible grouping criteria for the logbook view. Because getting subtotals with the logbook view is quite general, it is likely very easy to support subtotals for N flights. It basically falls out of the implementation.

The issue we're discussing here is about the merits of supporting totals in the logbook view at all, without respect to a particular grouping criterion. The questions about the value of running totals and grouping by N flights (and the relationship to a paper logbook) are better addressed in a separate topic. I will create a separate issue for that part of our discussion.

Displaying totals

You correctly perceive that using display templates (issue #479) would determine not only the set of parameter values that are displayed for each flight, but also the corresponding totals for summable properties. Certainly the subtotals "HAVE to correspond to the columns under which they are displayed". I don't think I suggested otherwise.

The converse isn't really true. It is possible and sensible to not display subtotals for some of the properties (the non-summable ones) displayed for each flight. Although the subtotals would always be aligned vertically with their corresponding properties, there is no reason some columns couldn't be blank in the subtotals row. This might apply if the tail number, for example, were made a property that might be part of the "display template".

Me: Grand totals always make sense at the end of any list of flights, regardless of filtering or ordering

You: On the printed page I agree with you, because you can't interact with it. In an interactive environment, I disagree. There's no need to scroll way down or page to the 50th page to see totals; clicking "Totals" gives you this directly, and you can expand/collapse it. So why stick it at the end?

I'd argue that it does make sense to have grand totals on the end of the logbook view if there are totals interspersed. It would seem very odd not to do so in fact. It's not a matter of "needing" to scroll down to the bottom of the last page of the logbook to see the grand total. It's easy for you to compute. The user who is looking at (possibly a subset) of his flights and is interested in subtotals is likely also interested in the grand total. It's reasonable to want to see grand totals in any of the scenarios mentioned above (e.g., all flights by all students, after seeing the subtotals by student).

So if there are any totals, there should also be grand totals. I don't see any problem with grand totals at the bottom of the last page of flights in the logbook view.

I still think subtotals interspersed in the list of flights is a terrible way to see the totals per group, as opposed to actually doing an interactive report. The analysis tab or search functionality can do this.

Clearly, I don't see what is "terrible" about interspersed totals. The Analysis tab is great for some things, and the logbook view approach is great for other things. For many use cases, using the logbook approach is much more flexible and simpler for the user.

Excel or MyFlightBook?

an answer I've long given for this sort of deep analysis is "Excel Pivot Tables are an amazing thing." I can't hope to match Excel's power and flexibility here; I don't see the point of trying to do so. What I can do is try to make actual real-world scenarios easy, and leave the hypothetical ones and "it could be interesting" ones to Excel.

I'm certainly not asking you to match the power of Excel, which indeed is a wonderful and amazing product. I can't say I am the world's greatest expert, but I've used Excel for a long time, fairly extensively.

Making real-world scenarios easy is the precisely the point of this enhancement request. It is certainly easy to export the entire logbook. And a user can, with some effort, accomplish much of what logbook totals would provide.

Exporting the entire logbook, and using the pivot function is certainly possible. However, using Excel is a lot more work for the user than simply turning on subtotals in the logbook view. If the goal is to make something "easy", then reducing conceptual effort and the time it takes to accomplish the task is what's required. The intention of this proposal is to address a wide range of scenarios without requiring entry into '"Excel Pivot tables are an amazing thing" land. :)'.

Use Cases/Scenarios

It's of course a matter of opinion whether certain use cases are hypothetical or only "possibly interesting". We certainly could have a conversation about any of the use cases I provided above (which we haven't had so far). Maybe some scenarios are less broadly interesting or important than others, but the point is that a wide range of use cases can be supported with (what I claim is) an "easy" to implement and simple to use feature.

It's not so much that this new feature would support one or more specific scenarios, whether rare or common. Instead, implementing templates for and totals in the logbook would provide general functionality that makes a solving many different scenarios very easy, whether or not those scenarios can be anticipated. These features empower the user to do things with little work on their part (and, I hope, not too much on yours).

It's surely possible that the "need" for different ways to summarize flights doesn't rise to the level of pain so that a user requests an enhancement, but that doesn't mean the enhancement wouldn't be useful to him.

Implementation

As you mention in issue #478, using a "display template" to control the logbook view isn't "super hard". Here, we're suggesting another probably not "super hard" enhancement ... adding totals to the view.

I probably shouldn't speculate, but it seems adding subtotals to the logbook view is not very difficult. The user specifies, in the UI, the grouping criterion (or perhaps someday multiple criteria). As suggested, it would be handy for the grouping criterion/criteria to be sticky until changed. When the logbook view is generated, something like this pseudo code approximates what's needed:

/* set up initial conditions */
If there are no grouping criteria then
  OutputtingTotals = false;
 else 
  OutputtingTotals = true;
end if;

If OutputtingTotals then
  SubtotalsArray, GrandTotalsArray = 0;  /* array: template's numeric fields */
  reset CurrentGroupCriteria, PreviousGroupCriteria;
end if;

/* As flights are being rendered, compute and render totals */
For Flight = 1 .. flights in the current result set
  RenderFlight(Flight);  
  If OutputtingTotals then
     add numeric properties of Flight to SubtotalsArray, GrandTotalsArray; 
     If Flight > 1 and CurrentGroupCriteria <> PreviousGroupCriteria then
         RenderSubTotals(SubtotalsArray);
         SubtotalsArray = 0;
         PreviousGroupCriteria = CurrentGroupCriteria;
     end if;
  end if;
end loop;
If OutputtingTotals then RenderGrandTotals(GrandTotalsArray); end if;

Clearly, there's more to it than that! Like, for example, making sure the renderer for subtotals and grand totals produce a good description, per the example display above. And, for grouping by "N flights", only a small change is required (add "or Mod(F,N) = 0" to the line detecting the next group).

From the user perspective, all that's required (as shown in the UI proposed above) would be to select a display template for the logbook (or use the default) and a grouping criterion. So, it doesn't seem like tons of work for you or the user.

Paged vs. continuous view and sort order

In #460, about printed reports, you commented that totals in the logbook don't ...

work for an interactive logbook view because running totals and subtotals only have meaning in ascending date and with all flights included

We agree that running totals only make sense with flights ordered by oldest to newest. However, they make sense with a subset of flights too ... running totals of this year's flights, for example.

Also you say

The interactive logbook view is also (generally) a paged view - which GREATLY improves performance (and reduces scrolling); not quite sure how that works with interspersed subtotals ... What was the suggestion?

The comments under this topic above were in response to this comment. No specific suggestion other than to say that "totals should be available with either continuous or paged format".

As a further clarification, with totals in the logbook view, there will be more "rows" on any given page of the logbook than the number of "flights per page" (as selected in the drop-down). I don't believe this is a problem.

Also, re sort order ... sort order is important only for running totals (which is an entirely separate topic, for which I will generate a new issue sometime soon). There's no conflict between subtotals and any other sort order. Further, the "natural" sort order might be when the flights are ordered by the grouping criterion (say student name, tail number, etc.).

The Bottom Line

You said in #460

What would the purpose of this feature be? Subtotals are completely a vestige of paper and human computation, they serve utterly no actual functional purpose in the electronic arena. So what problem would be solved by adding this?

Well, we fundamentally disagree here. Subtotals are/were important on paper logs and where human computation has been done. Subtotals are also valuable and useful for many use cases and applications. It's certainly not all about paper log books or getting totals for N flights at a time. This whole topic is about the problems that can be solved with subtotals in the logbook, and the advantages of doing so.

Thank you for your time as we discuss all this. I am hopeful that this discussion (and #479) are helpful and that someday you'll find time to implement features like those I've suggested.

As always, thank you so much for all you do for the GA community. MyFlightBook is a treasure!

I greatly appreciate your thorough and thoughtful reply - it truly is great having someone with a different perspective putting so much effort and thought into this.

I just took out the enhanced analysis (issue #482 ) stuff today. You should give it a try. I think it addresses literally every single use case you've described (other than group-by-student, but I actually can add that; I'm just tired right now), and is far simpler and more flexible than subtotals. I should probably rename the tab "Reporting" or "Summaries", since that's what we're really talking about, whether with subtotals or the currently-named "Analysis" tab. All the scenarios here are really reporting scenarios, and at the end of the day that's what this functionality really does - summarize aspects of your flying.

So, while the graph only shows one thing (plus optional running totals at a time), this now:

Can group by non-date groupings. Specifically aircraft, model, or ICAO. I can add more (like student or CFI or ...)
can show anything that is (a) summable, and (b) that you've ever recorded. So it doesn't show you carrier landings if you've never landed on an aircraft carrier, but if you want to see the summary of your aerobatic maneuvers, you can do it.
Includes a table with ALL of the summable values at once, including running totals, scrolling horizontally
Includes a "Download to Excel" feature.
I have the ability to do every "N" flights, but haven't included it because...I still feels like 100% arbitrary "because I could" functionality. I have yet to hear an actual use case beyond "the user might want to" that requires this.
all are clickable - in table or in graph - to view the constituent data.

Some of the downsides of subtotals, as mentioned:

blank columns for values you can't totals
limited horizontal real estate limits the number of subtotals you can show
I understand your pseudo-code above, but it actually doesn't map at all to how the system works. It would mean rewriting literally everything. I use a "gridview" control provided by ASP.NET, and bind the data to it. I'd have to do what I do for printing, which is actually create multiple gridviews and give each one a subset of the data. Or, just do a varying page at a time. And since I'd be doing the slice/dice/subtotalling, it's computationally intensive.
Pagination would be weird. E.g., if you group by aircraft, you'll have one super long page, and lots of one-line pages with subtotals.
Subtotals are dispersed, possibly at highly irregular intervals. You may have to page or scroll a good distance to get from one to the next.

Grouping in the logbook view has some potential merit. There's a related issue #236 that requests that from a "chapter" perspective, but grouping by things like student may be more interesting. It does, however, break the gridview model which does mean changing an obscene amount of code and rewriting a vast amount of stuff that gridview does for me. True templates (including layout, etc.) would mean I'd have to do a lot of that anyhow (adding/removing columns, in a separate issue, doesn't).

I'm going to close this; I think the the problems that subtotals are proposed to solve are best solved via #482, which I'm happy to continue to enhance (e.g., adding things like student or instructor or employer or ...)

Um. Well.

I know you just put a lot of work into histograms. I believe there is not much work in totals in the logbook. Significant performance and usability differences too.

I put a lot of thought and effort in my comments. I'm sorry it took so long for me to post them (while you were no doubt working on histograms). I also regret that I don't have more comments or discussion from you than

the problems that subtotals are proposed to solve are best solved via #482

However, of course it is your product and your prerogatives. I hope someday you'll revisit this issue.

Thanks again

I really do appreciate the effort and thought in your comments. If you'd like I can address your comments more line-by-line (in email - the point-by-point is easier there), but I think we're going in circles, especially since so many of the scenarios/use-cases you describe above are ones we agree on, we just disagree about which solution is best to do it.

Try out the histograms; I think you'll find it answers all of the questions that subtotals were intended to address.

And it would be a highly, highly non-trivial amount of work. There's a crazy amount of functionality in the logbook and use cases in that. So it needs to be compelling in the sense of not just an alternate way to solve a problem, but actually solving something new.

I'm glad to share my thoughts. Our dialogue helps me understand a different design philosophy and various implementation issues, as well as learn more about aviation.

I appreciate the explanation of how histograms can address all those scenarios, as well as the comments about the possible limitations of subtotals in the logbook. I also understand (sort of) the issues re implementation effort.

I will definitely try histograms. However, my set of data is very limited. I'd love to have access to a "playground" where I could try other things (#488).

Thanks for the discussion above and your the comments you sent by mail. We'’ll continue the dialogue via email as we both have time and interest.

ericberman / MyFlightbookWeb

Subtotals and running totals in the logbook view #481