Enhance Logbook > Totals with improved format and user-supplied date(s)

[KayRJay]

The weekly and monthly notification reports of recent activity (issue #588) have a nice new compact format with lots of interesting information.

Similar information is already provided at Logbook > Totals, but totals currently cover "all time".

it would be excellent to adopt the same format and content as the notifications, and to allow the user to specify a date or a date range.

A report "as of" a particular date, would include the prior 7 days, the prior month and the prior year as well as month to date (if the date was not the first of the month) and year to date (if the date is not Jan 1).

A report "over" a date range would omit the trailing periods, and just include the totals.

[ericberman]

I'm not sure I agree on this one.

For one, as you mention, the email layout doesn't really play all that well with the interactive nature of totals where you can specify arbitrary searches (including date ranges) anyhow; I think it would be weird to arbitrarily be showing me all of these additional time periods if I don't search on a time period, but then not show them if I do specify a time period (as must be the case).

For another, things like "last 7 days" make sense in an email with a 7-day frequency, but is just clutter to me if I'm just trying to read my totals for an insurance report. And I don't know why I'd want to see last month's or last year's totals every single time I view my totals; they just don't change all that often.

It also hits the database a ton more: computing totals already involves creating a temp table and doing up to three separate queries against it, and each column of the email totals is a separate totals computation.

You also lose the subtotals of landings/approaches because I discarded them from the email layout.

The layout in #588 is actually not more compact at all; indeed, it takes up a lot more space because because it's showing a lot more information, arranges all the totals vertically (so that horizontal can be used for striping by the various date ranges). It's more information dense.

I'm not sure that that density serves a purpose there, though. Email is static and serves as a push notification report with a 7- or 28-to-31-day lag between updates; this page is interactive and dynamic and can be visited frequently (or not). They're serving different purposes.

I think the dense report does have a place, but not in Logbook->Totals. Possibly on the IACRA / 8710 page as a peer of the "Rollup by model" report (which, by the way, also overlaps with what I did for issue #588). Both of those probably need a new home (or I need to change the name of the menu item); they're kinda orphaned, but what they share in common is that they all provide commonly asked questions for insurance, employers, or regulators.

[KayRJay]

I think it would be weird to arbitrarily be showing me all of these additional time periods if I don't search on a time period, but then not show them if I do specify a time period (as must be the case).

I don't see this that way. In either case ("as of" a date, or "over a date range"), the user IS specifying a time period. The user is always searching on a time period ... its just that one has no lower (oldest) bound, and the other time period is bounded on both ends.

I don't see "weirdness" here, and if there is, it has nothing to do with whether the user is searching over a time period or not. You could show the prior week/month/year even when a date range is given (from the first day backwards), but I agree it's not particularly interesting (but it does have meaning ... it's the period before the first date of the range).

"last 7 days" make sense in an email with a 7-day frequency, but is just clutter to me if I'm just trying to read my totals for an insurance report. And I don't know why I'd want to see last month's or last year's totals every single time I view my totals; they just don't change all that often.

Certainly, a user might want to occasionally see his "all time" totals (perhaps for an insurance report or to brag). But as you said, the "all time" totals don't change very much between times I look at them. It seems more likely that a user would like to see totals over smaller (and more recent) periods of time than since his first flight.

You obviously have a lot more experience than I, and certainly better understand typical use cases. But why limit the functionality only to the use cases you can think of? I'm guessing there are are other reasons to be interested in totals other than "all time" totals.

• plain and simple curiosity
• looking at recent activity trends
• seeing totals in the winter months, or when at a second home
• wanting to compare activity in similar periods (two separate date range reports)
• etc

My bias would be to give the user tools to do what he wants (as long as it's not too much work to implement or too much of a performance hit).

I don't know why I'd want to see last month's or last year's totals every single time I view my totals; they just don't change all that often.

The user wouldn't likely be seeing the same prior month's total each time he looks at totals. Why would he specify the same "as of" date more than once? He's very likely to specify a different date each time he looks at totals.

It also hits the database a ton more: computing totals already involves creating a temp table and doing up to three separate queries against it, and each column of the email totals is a separate totals computation.

I'd be interested in knowing your SQL algorithm. I'm pretty sure this can be simplified and made more efficient.

You also lose the subtotals of landings/approaches because I discarded them from the email layout.

What's the reason? Landing a plane is certainly the most important thing a pilot ever does!

The layout in #588 is ... more information dense.

The point of my comment is that the prior email format took up a lot of space to present the data it did. The new format does present more information, possibly in the same amount of space as the prior format.

Email is static and serves as a push notification report ... thus page is interactive and dynamic and can be visited frequently (or not). They're serving different purposes.

You talk about the differences between the email and the page. Those differences are real, but don't speak to the purpose.

To me, the user has an interest in seeing totals, whatever his purpose or reason for wanting to see those totals. He may choose to see them in weekly or monthly emails, or on demand. The purpose doesn't necessarily change with the frequency or manner of access. Here, you may be confusing your intention/purpose with the possible one(s) of users.

I think the dense report does have a place, but not in Logbook->Totals.

Seems a natural place to me, just as the present version does.

they all provide commonly asked questions for insurance, employers, or regulators.

But there are other reasons to answer those questions. And of course, your REAL client is the user, not insurance, employers, or regulators. This goes back to the topic of "engagement" and making the product do something that users want and appreciate.

[ericberman]

I don't see this that way. In either case ("as of" a date, or "over a date range"), the user IS specifying a time period. The user is always searching on a time period ... its just that one has no lower (oldest) bound, and the other time period is bounded on both ends.

The new mail layout shows multiple specified time periods. If I then search for, say, previous year as my time period, then showing me last 7 days and last month and year to date are all - by definition - zero because my query is restricted to last year. The layout is imposing date periods that may or may not overlap with the date I specify in my query.

Certainly, a user might want to occasionally see his "all time" totals (perhaps for an insurance report or to brag). But as you said, the "all time" totals don't change very much between times I look at them. It seems more likely that a user would like to see totals over smaller (and more recent) periods of time than since his first flight.

It may not change much, but it is - far and away - the most important totals that people have. Yes, they also need to know how much time they have in some recent trailing period, but the most important factor most of the time is "how much over all time".

I'd be interested in knowing your SQL algorithm. I'm pretty sure this can be simplified and made more efficient.

You can look at the code, but the quick summary (it's actually 4 queries on a temp table)

• One query does no grouping - just straight-line totals: how much night flight, how much cross-country, how much dual, etc.
• One query groups by category/class/(class+type), so that you can see how much ASEL time you have vs. AMEL time vs. type-rated AMEL time (e.g,. B-737 or A-320). Or, if you're grouping by model, it does that grouping
• One query groups by model feature, so that you can see how much complex time/turbine/retract/tailwheel time (and PIC/SIC subsets) you have
• One query totals your properties (remember, those are in a separate table).

If you know how I can do all of this in one query, I'd love your advice on that.

You also lose the subtotals of landings/approaches because I discarded them from the email layout. What's the reason? Landing a plane is certainly the most important thing a pilot ever does!

Because it didn't fit. There are 7 columns in the weekly email table. This is meant to be read in email. But I may be able to make them fit; looking at that right now.

The point of my comment is that the prior email format took up a lot of space to present the data it did. The new format does present more information, possibly in the same amount of space as the prior format.

Not true. It presents MORE data in MORE space. It is demonstrably more space - significantly. A lot of the data is empty (e.g., if you didn't do a category of flying in one of the various time periods). So it might actually be less dense, contrary to my earlier assertion.

Let me be clear: it's readable, it's information rich, and that's all goodness! But not by any measure is it more compact! It is absolutely not. Lest there be any doubt about that, here are my totals in both formats. It's very clear which is bigger and requires more scrolling:

General totals layout (one time period at a time): (986x446 pixels = 439,756 pixels total)

Vs. the email layout: (614 x 1,179 pixels = 723,906 pixels total)

Notice all the blank space where I didn't have much flying (or didn't have much of a given type of flying). The current totals report has none of that - in fact, it guarantees that all values of "0" are stripped.

(Oh, and note that the screenshot above includes my fix to show the landings/approach subtotals. A bit ugly, but it's OK because I've constrained the width of the columns; otherwise, you'd have a really ugly mix of wide and narrow columns that is just hard on the eyes.)

You talk about the differences between the email and the page. Those differences are real, but don't speak to the purpose.

I was explicitly speaking to purpose. The purpose of the email is to be a push notification, to let you know information without you thinking to ask for it. The purpose of the website is to let you store and retrieve information on demand. Very different purposes, very different use cases. It's all about the purpose of the medium.

I think the dense report does have a place, but not in Logbook->Totals. Seems a natural place to me, just as the present version does.

I certainly get that - it's totals, after all. But it's a canned report - it doesn't play well (for reasons described above) with the full flexibility of the totals page, which is by definition not canned.

But there are other reasons to answer those questions. And of course, your REAL client is the user, not insurance, employers, or regulators.

Of course, but that just begs the question of WHY someone wants a given bit of functionality. Insurance/employers/regulators want this data, and that's why users want that data. They want other stuff too, but these are absolutely critical needs.

Note that the 8710 form and the "rollup by model" each also have a lot of overlap with the totals page as well, but they don't belong there - they have specific layout, specific time periods (although you can customize them). That's why I think - since this is a canned report - it really belongs with those. I.e., a library of common reports that pretty much all pilots need now and then.

That's why I think this layout belongs there by default.

[KayRJay]

If I search for, say, previous year as my time period, then showing me last 7 days and last month and year to date are all - by definition - zero because my query is restricted to last year. The layout is imposing date periods that may or may not overlap with the date I specify in my query.

No, not by definition, but by your choice. The "query" does not include the previous periods. It defines the period for which totals are desired, and there are ALSO flights from BEFORE that period that can be summarized.

There are usually flights in the period before period specified in the query (in your example, the previous year). There is data before the first day of any particular date (except the date of the very first flight). While your decision to not present data summarizing the prior period is up to you, it's not because there is nothing there to summarize or the question is insensible. The totals that are presented correspond to the period specified, and the prior periods are NOT IN that date range, they precede it.

Another way of stating this is ... it's not the LAST 7 days, it's the PRIOR 7 days. PRIOR to the specified date range. So, taking your case, with Jan 1 2019 to Dec 31 2019 as my query, it is entirely sensible and well defined to talk about the totals from December 2018 and all of 2018.

[All time totals] ... may not change much, but it is - far and away - the most important totals that people have. Yes, they also need to know how much time they have in some recent trailing period, but the most important factor most of the time is "how much over all time"

Ok, maybe it is the absolutely most important by far. Overwhelmingly so, if you say so. But my question is ... is it the ONLY set of totals that are interesting? I don't see how you can make that case.

SQL algorithm ... 4 queries on a temp table ...

There is a way to compute several totals including different subsets of the data, without doing grouping. Use the CASE clause to add a zero or the actual value to what you're totallng. Say x is the attribute for flight time. Something like this perhaps would work:

select sum (X),   /* total flight time */
    sum (case when CategoryClass = 'ASEL' then X else 0) as ASELTime), /* ASEL time */
    sum (case when CategoryClass = 'AMEL' then X else 0) as AMELTime, /* AMEL time */
...  
from FLIGHTS
where USER=UserName AND FLIGHTDate between DATE1 and DATE2;

You can do all your groups of times in a single query, and all those for properties in a second query. I'm not sure why you need a temporary table at all, but perhaps it's to decode certain columns that you map using coding tables or some such?

[Losing] the subtotals of landings/approaches because ... there are 7 columns in the weekly email table. ... But I may be able to make them fit; looking at that right now.

This is the cost and benefit of a more dense format. If you need to, you could separate out Total / Day / Night landings each on separate rows, but (in my estimation), it's best to keep things dense and use fewer rows.

The new format ... presents MORE data in MORE space. It is demonstrably more space - significantly. A lot of the data is empty (e.g., if you didn't do a category of flying in one of the various time periods). So it might actually be less dense, contrary to my earlier assertion.

To be fair, you might say the new format presents FAR more data in SOMEWHAT more space. Maybe as much as five times as much information in about 60% more pixels?

I think you've chosen a diabolically bad case, where there is no prior period data to summarize (but most often there probably IS such data). And to the extent that many/most users fly all of ASEL, AMEL, ASES, Helicopter and Glider ... your argument might be true. My bet is that the vast majority of users fly at most two of these types of aircraft.

Also, if there were customization (so I could look for totals only in AMEL, for example), then the issue is less critical.

The purpose of the email is to be a push notification ... The purpose of the website is to let you store and retrieve information on demand. ... Very different purposes, very different use cases. It's all about the purpose of the medium.

I guess we're talking at cross purposes here. Whose purpose and what purpose are we talking about?

I can't disagree with the character of emails vs the website, in terms of when and how information is retrieved. Yes, different purposes and use cases in terms of delivery. The user may want one mechanism sometimes and the other at other times.

The other questions to ask are: WHY is a user looking for totals at all? What's HIS purpose? Is it to satisfy an itch, a curiosity, a particular "need to know" or a query from an insurance rater? The user's purpose in being interested in the flight totals has little to do with and is distinct from the manner of delivery of the totals.

So, there might be different purposes for different "mediums" (methods of delivery), but those are not the same as the reason the user is interested in totals at all.

(Logbook->Totals) ... is a canned report - it doesn't play well (for reasons described above) with the full flexibility of the totals page, which is by definition not canned.

It's not necessary that the Totals page be 100% identical in format to the email notifications. However, it's a good starting point.

Your REAL client is the user, not insurance, employers, or regulators. ... Of course, but that just begs the question of WHY someone wants a given bit of functionality. Insurance/employers/regulators want this data, and that's why users want that data. They want other stuff too, but these are absolutely critical needs.

Again, that's one ... perhaps the very most important one, who am I to say? ... reason why the totals are interesting and useful. I think I gave some plausible other rationales for wanting to look at totals. WHY exclude these other reasonable use cases?

I don't want to offend you, but I think your position on this topic (and some others) is rather rigid. You have a very specific mindset ... "it's all about regulation, currency, FAA rules, etc.". The fact is, at least some of your users are just recreational pilots, who are interested in tracking their flights and looking at them (and summarizing them) in various interesting (to them) ways. Again, it's all about making the product better and deepen user engagement by better filling each individual's unique needs. Food for thought.

[KayRJay]

Oh, and by the way, that's a reasonably good fix for the approaches and landings info. Obviously that info is quite important.

Seems you could save quite a few rows and pixels (and eye scanning time) by subgrouping within groups, and omitting mostly blank lines. Is there really a need to have the word "Approaches" appear several times under "Other Totals"? Why not something like

Approaches
   GPS/LPV
   ILS
   RNAV/GPS
   VOR
   VOR/DME
Copilot Time
Solo Time

The same would be true for many of the row labels in your example above. Abbreviations can be used (XC for Cross Country on two lines, Sim Inst. instead of Simulated Instrument on two lines, etc.).

The landings info could be compressed too. Something like this would use only 3 lines instead of 5:

Personal preference, of course. But it to my eyes, it's easier to see just the numbers in the table, so I don't have to read/scan over repeating text in every column. Saves pixels too.

[ericberman]

Another way of stating this is ... it's not the LAST 7 days, it's the PRIOR 7 days. PRIOR to the specified date range. So, taking your case, with Jan 1 2019 to Dec 31 2019 as my query, it is entirely sensible and well defined to talk about the totals from December 2018 and all of 2018.

No, that's not correct. The "Last 7 days" is the subset of the query that falls within the period of 7 days ago until "today". The default query is "start of time until today". The "last 7 days" is a strict subset of that, it is not prior to it. Think of it as a subtotal.

But if I search for "Flights between Feb 2015 and March 2016", by definition none of those flights are in the last 7 days, in the last month, in the year-to-date, in the previous year, etc. And showing flights in the 7 days from Jan 24-Jan 31 (the 7 days "before the specified date range") makes no sense whatsoever. See what I mean?

Ok, maybe it is the absolutely most important by far. Overwhelmingly so, if you say so. But my question is ... is it the ONLY set of totals that are interesting? I don't see how you can make that case.

I'm not making that case in the least! That's why the totals page can be queried, that's why the breakdown by date that you proposed for email makes sense not just in email but also to expose on the site.

I think you've chosen a diabolically bad case, where there is no prior period data to summarize (but most often there probably IS such data). And to the extent that many/most users fly all of ASEL, AMEL, ASES, Helicopter and Glider ... your argument might be true. My bet is that the vast majority of users fly at most two of these types of aircraft. Also, if there were customization (so I could look for totals only in AMEL, for example), then the issue is less critical.

Not "diabolically bad" at all. I'm not at all atypical, and a design has to scale for all sorts of users in all sorts of scenarios. You can't just design for the simple case; the more people fly, the more totals they accumulate. The design must scale!

And it is absolutely customizable. If you search for, say, just AMEL, then it absolutely reduces to only those non-zero totals in AMEL.

There is a way to compute several totals including different subsets of the data, without doing grouping. Use the CASE clause to add a zero or the actual value to what you're totallng. Say x is the attribute for flight time. Something like this perhaps would work: select sum (X), / total flight time / sum (case when CategoryClass = 'ASEL' then X else 0) as ASELTime), / ASEL time / sum (case when CategoryClass = 'AMEL' then X else 0) as AMELTime, / AMEL time /

That only works if I can enumerate up front the potential groupings, which i can't. It's data driven. E.g., there are 18 category classes (bad enough from a query complexity scenario already), but that becomes unbounded when you factor in type-rated aircraft (I need to subtotal B-737's and A-320's as subsets of AMEL because they have separate currency rules and turbine rules, etc.), so I need to use "GROUP BY" to group on whatever actually arises. You can also group by the model or the model's ICAO (and there are thousands of those, and all data driven at that).

For properties, I'm pushing 700 properties, and many (booleans, strings, dates) don't make any sense to sum.

I could probably coalesce the model feature query (turbine/retract/etc.), since that's finite and bounded, but since I need to create the temp table and do 3 other queries on it anyhow, that's sorta the least of the problems.

The other questions to ask are: WHY is a user looking for totals at all? What's HIS purpose? Is it to satisfy an itch, a curiosity, a particular "need to know" or a query from an insurance rater? The user's purpose in being interested in the flight totals has little to do with and is distinct from the manner of delivery of the totals.

All of those, but the manner of delivery does matter and is not completely independent.

Think about the news headlines you might get on your phone as an analogy. They don't push entire articles, they pop up headlines; you click on the headline to read the news story. The purpose of the push is "hey, there's something to check out" and give a little information about what it is. The purpose of the website is to inform you of the details of the story beyond the headline. But clearly the headline and the story must be related

I don't want to offend you, but I think your position on this topic (and some others) is rather rigid. You have a very specific mindset ... "it's all about regulation, currency, FAA rules, etc.". The fact is, at least some of your users are just recreational pilots, who are interested in tracking their flights and looking at them (and summarizing them) in various interesting (to them) ways. Again, it's all about making the product better and deepen user engagement by better filling each individual's unique needs. Food for thought.

You're not offending me in the least. I'm not trying to be rigid here; indeed, I'm trying to build something that works as seamlessly as possible across as broad an audience as possible, and that has the flexibility (which is related to - but not the same as! - customization) for each of them. Scalability across use cases and across complexity of the data!

The "rigidity" here is that the email layout is super optimized for a particular sort of query and answering a particular question on one's totals - and that's completely awesome; which is why I did it.

But that optimization comes with tradeoffs - screen bloat, performance, and awkward interaction with any dates that might be in the user's query. So that's why I think it works better as a "canned report", since it matches what a lot of people need to know at a glance, more than as a default view.

[KayRJay]

If search for "Flights between Feb 2015 and March 2016", by definition none of those flights are in the last 7 days, in the last month, in the year-to-date, in the previous year, etc. And showing flights in the 7 days from Jan 24-Jan 31 (the 7 days "before the specified date range") makes no sense whatsoever. See what I mean?

No, I surely don't see what you mean. It's clearly a matter of perspective. You just said that BY DEFINITION none of the flights in the prior periods are in the set defined by "Flights between Feb 2015 and March 2016". Isn't that equivalent to saying that the query is the defined set, and the other flights are BEFORE it?

The totals page can be queried, that's why the breakdown by date that you proposed for email makes sense not just in email but also to expose on the site.

Actually and literally, the Totals page itself is not queried. What happens is that you search for a subset of flights in the LogBook and then total them. That works, but it's not really the same as "querying the totals page". I understand, though, that the full range of query criteria can be specified while searching on the LogBook page, so that has lots of value.

Seems we agree that there are multiple use cases, and likely multiple ways to address those cases. A lot of this discussion comes down to how best to expose "queryable totals" info in the site.

You can't just design for the simple case; the more people fly, the more totals they accumulate. The design must scale!

Absolutely it must scale. The design might not be optimal (though it must work) for the "worst case" (or even your specific case), but it should be reasonable for the average case. The average user (or majority of users) should be well served, even if the most extreme users are a bit disadvantaged.

If you search for, say, just AMEL, then it absolutely reduces to only those non-zero totals in AMEL.

I was missing the multi-step process of selecting search criteria on the Logbook page, Finding matching flights, then going to Totals. My bad. I was kinda trapped in the idea of the user's preferences indicating how much/what kinds of information a user might want to see in the notifications (which certainly should be a limited set of criteria as I suggested in the original post).

I imaged the query criteria could be incorporated into a new Totals feature. That's way too simple, and not as flexible as the current mechanism, which amounts to computing totals on a previously found set of flights.

There is a way to compute several totals including different subsets of the data, without doing grouping. ... That only works if I can enumerate up front the potential groupings, which i can't.

OK, I get it. There's a lot more complexity to the completely general case than I was considering.

Is the current approach a performance problem?

"The user's purpose in being interested in the flight totals has little to do with and is distinct from the manner of delivery of the totals." ... the manner of delivery does matter and is not completely independent.

I think the two issues ARE independent, very much so. I read headlines and I also read full articles. In either case, I am interested in information about the topic at hand. At some times I might want to be offered the information unsolicited, and at other times I want to go look for more details, when I want to do so.

I subscribe to the things I'm interested in. That determines the content of the notifications I get and the articles I read. My desire to be interrupted or peruse information at my leisure is a completely and totally independent issue of the topics I care about.

I'm not trying to be rigid here; indeed, I'm trying to build something that works as seamlessly as possible across as broad an audience as possible, and that has the flexibility (which is related to - but not the same as! - customization) for each of them. Scalability across use cases and across complexity of the data!

The right goal, of course. As long as you're open minded about the entire universe ... or a good part of it ... of your users' use cases and their interests.

The "rigidity" here is that the email layout is super optimized for a particular sort of query and answering a particular question on one's totals

That's the same topic as above .. the difference between the manner of delivery of the information (and why the user wants it one way or another) and the content of the information (and why the user is interested in it in the first place).

But that optimization comes with tradeoffs

Always.

• I think it works better as a "canned report", since it matches what a lot of people need to know at a glance, more than as a default view.

I've made my case and you have your opinion. So, we're still friends, but with different points of view.

[ericberman]

Take a look at the 8710 report (if you haven't already) and also (on the same page) at the rollup by model. There is basically nothing in these reports that you can't get from the Logbook->Totals page, but they're super optimized so that you get it all in one place.

• The 8710 form maps very well to what every pilot needs for the FAA before every checkride.
• The "rollup by model" maps very well to airlineapps.com, the one-stop airline application.

Again, nothing unique in either of these reports that you can't get from the more generic Totals page, just all done in one place for you without having to do multiple queries. But neither of them serve well as the basis for a general purpose totals function.

I think what I'm going to do is to put the email-style report here as a 3rd option - "rollup by time". Because the nice thing about this is that lots of people do ask for this sort of breakdown. E.g., I fly for Angel Flight and they ask this stuff, and insurance companies ask for it. So it's another optimized report.

The performance issue is not a major issue if this is not the primary view, and not serving things like the mobile apps (which it isn't).

If search for "Flights between Feb 2015 and March 2016", by definition none of those flights are in the last 7 days, in the last month, in the year-to-date, in the previous year, etc. And showing flights in the 7 days from Jan 24-Jan 31 (the 7 days "before the specified date range") makes no sense whatsoever. See what I mean? No, I surely don't see what you mean. It's clearly a matter of perspective. You just said that BY DEFINITION none of the flights in the prior periods are in the set defined by "Flights between Feb 2015 and March 2016". Isn't that equivalent to saying that the query is the defined set, and the other flights are BEFORE it?

I don't quite understand that. But let me clarify the question I was asking. I flew around Namibia in 2010. So I want to know "how much time did I spend flying in Namibia." I can do this by searching on date (June 2010) (among others). If I then click "Totals", I get the relevant totals, easy peasy:

Now if I tried to do that in the email-style layout you have columns for "all time", "this month", "last month" (March 2020), "Year to date" and "Previous year". My Namibia flights contribute nothing to any of those totals except "all time". And since I explicitly said I only wanted flights in June of 2010, why would those columns even be there?

That is what I meant about "by defintion" all of the columns other than "All time" are blank? Those columns lose meaning in a query that specifies a date range, since those columns are themselves specifying date ranges (all relative to "Today"). There's a conflict there.

But as a standardized report to compare multiple periods at once? It rocks. And yes, you can apply some querying to it. It's just not a standardized fully-flexible totals tool

[ericberman]

Publishing this as I speak. This actually sparked me to clean up the 8710 page and break it out into 3 "canned" roll-up reports: 8710 report (used for FAA checkrides), Model rollup (used by airlines), and Time rollup (the one I just put into email here, that is really an aggregation of multiple queries sliced by time, and which correlates well to what insurance companies and flying organizations like Angel Flight ask). It also gives me a place to put any future ones I might find.

I also cleaned up the layout/appearance of these, and unified the UI to match other pages on the site.

It does support searching/filtering. What I did here w.r.t. the Time Rollup is look to see if the user-supplied filter includes a date component. If not, then I continue to show the time slices (this month, previous month, year-to-date, previous year, all time). If it does include a date component, though, then I use that date component and limit to a single slice (the user-specified time range).

I like the result. It's under the "Training" tab because that's where the other canned reports are; arguably they could go under Logbook, but since these are most commonly accessed at some sort of milestone in your flying arc, I think "Training" is reasonable.

[KayRJay]

Well, I must say, this worked out very well! I like the look and the new features. And I do now understand your rationale. Not surprisingly, I have a few final (?) comments.

I would seem to be better to have this on the LogBook > Totals page, as as these are indeed totals. I had never looked at the 8710 / IACRA reports, but certainly had looked at Totals. It's interesting that you've promoted "Rollup by Model" and "Rollup by Time" to be items in the Training menu. Those are really different aspects of the Totals functionality.

The new LogBook > Totals page would look like this:

Where the "Overall" totals are for the flights in the current result set (e.g., after a search). Putting these all under LogBook>Totals has the advantage not only of having these all in the same place, but provides the same SEARCH functionality and user interface as for the other types of totals. You might then also use a similar format for the "Overall" totals as the others.

Some time down the road you might consider yet another form of totals, summarizing by multiple time periods (week, month, year). The format would need some work (perhaps limiting the number of periods, perhaps? use a horizontally scrolling window?). You might also want to select a subset of numbers to present, as it might be too overwhelming.

[ericberman]

Yeah, I can see all of that.

Note that the "Logbook->Totals" page is not a distinct page at all - it is integrally linked with Search, Currency, Analysis, and printing, as well as the list of flights that are underneath them; the menu is just shortcuts into expanding one or another of these. But the search, for example, applies across all of these - it applies to analysis, it restricts what gets printed in the print view, it impacts totals, etc. That's why the "Only flights matching these criteria" box (in the image above) is between the buttons and the sections that they expand.

So I can't really put these extra reports in there, at least not as top-level reports - just not enough horizontal room. I could put them under the "More" button, but those items generally vector off to other sections of the site.

Note too that your chart above ("by period", which then breaks out to 2018/2019/2020) is pretty much exactly what I currently have in the analysis tab: if you group by year and then expand the raw data underneath.

Another way to do it at some point might be to put it under the "Totals" button on the main page. E.g., Totals by default would show you grouped (or flat) totals, as it does today, but then you could also choose from a dropdown to display in 8710 format, in model-rollup format, in time-rollup format, or in other "canned" reports. That would continue to integrate with the search box, at the expense of page weight and a few other things, but it's doable.

[KayRJay]

I understand that the Totals page isn't a separate page. It essentially is the top of the Logbook flight listing, as are the Currency, Analysis, IACRA, Model and Time reports. Because they are all the same structurally, it seems all should be incorporated into the Logbook menu. The tie to the Training menu seems a bit tenuous to me. (And I agree these other totals should not be under "More ...".)

Another way ... you could also choose from a dropdown to display in 8710 format, in model-rollup format, in time-rollup format, or in other "canned" reports.

I think that would be great, so I mocked this up:

When the is clicked or hovered on, a submenu of the various options appears, covering up part of the Logbook menu. (As above, "Overall" totals are for the flights in the current result set, aka the current Totals display.) This not only integrates all of the totals, but keeps the Logbook menu reasonably short. The submenu might expand someday to include the rollups by period as suggested above.

[The "by period" info is] ... in the analysis tab: if you group by year and then expand the raw data underneath.

The Analysis report is close to the "by period" summaries, but the totals printed with the raw data are not the same. Also, there's no grouping by Category/Class, Aircraft features, etc.

By the way, on the IACRA and model rollups, there's something labelled 6/12/24. What does that signify?

[ericberman]

those are months. 6 month, 12 month, 24 month.