Flights / page in printed logbook: explain "approximate" and truncate as needed to fit

[KayRJay]

Unfortunately, the MyFlightBook printed logbook pages don't always fix the number of flights per page as requested. The reason for this is explained in the blog post of Sept 16, 2018.

As noted in the blog post, printed logbook pages with subtotals serve as a way to double-check page totals in a manual paper logbook. While page-level totals may be obsolete or unnecessary for a variety of reasons, this double-check aspect is definitely useful for some users.

Apparently,

MyFlightbook has some heuristics so that it automatically reduces the number of flights on a page when it sees what appear to be "tall" flight entries

But the post doesn't explain what a "tall" flight entry might be.

Two suggestions come to mind. First, use a popup explanation behind a [?] to refer to the blog and/or briefly explain that "flights with long comments or many included properties might result in fewer flights per page than requested".

More importantly, provide an option to truncate or omit comments or other details of a flight to make it "not tall" before you pass it to the rendering engine. Then, the user could get enough details to cross-check the printed page with my manual logbook.

[ericberman]

Excellent suggestion. Note that there already is an option to truncate in comments: "///". But this was buried in the FAQ; highlighting it here makes lots of sense.

I don't generally like to link to a myflightbook branded thing (like the blog) because the website is designed to be brandable, but I'll make an exception here.

[KayRJay]

Thanks for partially addressing this. Would it be possible to have MyFlightBook automatically force each flight to be "not tall", so that you could reliably get n pages per page? Truncate comments, remove "extra" properties, etc., so that each flight would be a nominal size permitting n flights per page?

[ericberman]

How do you propose doing that? How do you decide what to trim? If they say to include images or signatures, do you override what they say?

[ericberman]

The relevant blog post is actually not the one you referenced above, it's the one I linked to in the tooltip. That explains why this is such a gnarly problem to solve. Note too that since you can choose from a wide variety of page sizes, you simply can't solve this problem in any reasonable way without doing the layout yourself - the truncation you would do differs based on page size and content, so it would simply be another form of approximation.

I really don't like the idea of playing god and deciding what is and isn't important. If you went to the trouble of logging data, I am going to assume you thought it was important to log; it's absolutely not my place to second guess you.

[ericberman]

This is the blog post that explains the issue far better.

[KayRJay]

Yes. Do whatever it takes to make each flight “not tall” if the “force” option is chosen.

You could use any heuristic you like .. first eliminate images then eliminate properties, then truncate comments ... as an example. Or, some other heuristic, whatever seems most reasonable.

The idea is to get to N flights per page, not to preserve all the information requested on the report, but instead facilitate the double-checking of manual per-page totals.

Trust the user to know what he wants.

Sent from my iPad

On Jan 20, 2020, at 10:34 PM, Eric Berman notifications@github.com wrote:

 How do you propose doing that? How do you decide what to trim? If they say to include images or signatures, do you override what they say?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[KayRJay]

That this topic keeps coming up probably reflects a significant interest among users for a reliable way to print N flights per page.

The key thing here is not 100% fidelity of the printed log in this particular use case. It’s that the user wants a little help in generating page-level totals to double-check his manual logbook entires. We are not asking you to pay god .. nor delete any actual recorded info. Just give the user a way to generate page-level totals.

Heck, this could be a lot simpler. Have a report type that lIsts ONLY the page-level totals a user wants. So, don’t think of it as a corrupted “dump” of the full logbook, but instead an entirely new type of report that is for the specific purpose of summarizing flights in “groups” of N flights. You could give the user control of which totals to display. But instead of trying to replicate the look of a logbook with its N flights per page, you’d simply provide running totals and totals of desired metrics every N flights.

[ericberman]

Your suggestion above of simply providing running totals every N flights is basically what I do today, but people definitely don't want that in the middle of the page.

But at a higher level, I fundamentally disagree about the priority of actually hitting N flights per page. I think that is a complete red herring of a goal. It serves utterly no actual purpose. Really, it serves absolutely zero functional purpose; it is strictly a comfort/tradition thing, nothing more. Frankly, I should default to continuous mode because it makes the most efficient use of the real estate.

The issue that comes up most here is NOT about # of flights per se; it's about wasted paper/whitespace or odd pagination. People adjust the target # of flights per page in order to address THAT issue - i.e., getting the target flights per page is not a primary problem, it is a a mechanism people use to try to get one set of subtotals on the bottom of each page, without a half a page of whitespace following because of tall data. (And continuous renders this problem 100% moot)

Trusting the user means defering to them: I give them tools to cut out images, cut out properties, truncate comments - to achieve the target flights-per-page or white space efficiency, but all at their discretion because they know what's important and what isn't, far better than I could.

I'm open to concrete proposals, but any other heuristics I do will still be just heuristics. There are really only two variables you can play with: (a) adjust the data displayed for each flight, or (b) adjust the number of flights per page.

My current heuristics address - imperfectly - (b) (hey, they're heuristics after all; they're making educated guesses about row height!). They explicitly are designed to vary the # of flights per page precisely to achieve the goal of filling the page without overflowing the page.

Let me be more clear about the tradeoff: it is provably impossible to simultaneously have precisely N flights per page AND have all of the data for each flight. It cannot be done; the problem is inherently overconstrained.

Varying N is easy for me to do without screwing with the user's data, so that's where I go by default. If the user wishes to adjust the included data so that I don't have to vary N, that's great - it's their data, it's their choice. I give them the tools for that.

It might be possible for me to force a row-height and have the renderer clip everything that doesn't fit. But that's essentially a completely random method for deciding what does and doesn't show, and it looks super unprofessional (i.e., if the box is an uneven multiple of the line height for the font that's installed, then you would see the tops of the words of the truncated text). I've looked into shrink-to-fit (i.e., the text would get smaller until it fit the box I provided), but I haven't found a technical way to achieve that.

So I think letting N vary (variable (a)) and giving the user tools to adjust the data displayed (variable (b)) is by far the best tradeoff here.

Or...just get past the notion of pre-printed fixed paper forms, join the 20th century (much less the 21st) and use continuous. Hitting "N" flights per page is a means to an end (filling the page efficiently), it is NOT a goal in and of itself.

[KayRJay]

Rather than respond to your strongly held feelings on this topic, and although I disagree with several points, here is a different suggestion.

On the regular logbook display (not printing), provide an option for subtotals and running totals in the regular logbook display.

This doesn't seem to pose any of the issues or concerns you cited. The full, beautiful display of each flight is preserved, with a user-requested subtotal every N flights.

[ericberman]

I get where you're coming from, and this deserves a full (albeit long) response, so I apologize in advance for that. There are indeed parts that I feel strongly about, but let's start here with the parts that are completely objective, where my opinions don't matter.

A print view of a logbook in other-than-continuous mode nominally is trying to satisfy the following constraints:

• N flights per page
• Subtotals on the bottom of each page (I'll come back to that, since I think you're suggesting concerns this)
• Content Cn (C1, C2, C3...CN) for each flight
• Page size P (Letter, legal, A4, etc.)
• No large gaps of whitespace (e.g., spilling over onto an extra page and leaving only a little of that next page used.) - by FAR, this is the biggest complaint I hear from people, because they believe it looks unprofessional when they're going for an airline job, for example.

While these constraints can often all be satisfied at once, in the general case they cannot. Here is an example from my old paper logbook that demonstrates exactly this:

Note that in this example, N=13 (the paper form has 13 rows for 13 flights), the subtotals are on each page, the page size is fixed. But the 2nd to last entry on this page is a critical entry: it is my pre-checkride test prep, and my instructor was very clear to indicate that it is such and to indicate what was covered, because the DPE is likely to ask "Show me that you've had the test prep required by 61.109(a)(4)" (and "show me where you've had training in ___", such as emergency descents.) This entry (and others on the page) simply didn't fit into the space alloted for a single entry, so it consumes three positions.

Anyhow, the point is that SOMETHING has to give in a scenario like this where the content doesn't fit; that's not strongly held feelings, that's 5 equations with only 3 variables.

There are a number of ways this could be addressed. I will enumerate them; if I'm missing any, please let me know. (I'm including here what I think I understand your suggestion to be). I'll list my perceived pros/cons for each; that's obviously where there's room for different perspectives.

Option	Pros	Cons
Change the page size (larger paper)	Easy Reliable (fits more on the page)	* Often not an option for a user (depending on printer availability or other requirements)
Change N (done by user, applies to ALL pages)	* Often solves the problem	* Suboptimal use of paper
Use Continuous mode	(OK, I've kinda beaten this one to death) Optimal use of white space Per-page totals serve no actual functional purpose anyhow	Per-page totals are traditional and expected Per-page totals do allow for spot checking of math
Fixed form: just spill into next entry/entries	* Emulates paper exactly	Emulates paper exactly Hard to read because of the lines.
Expand entries: entries grow/shrink	* Fits content	* If entry grows, you're likely to push an entry to the next page.
Expand entries + Heuristics: Expand entries, but when you think a row is going to be M entries tall, reduce N - but only for that page - by M-1 (This is what I do right now)	* Fits content	Breaks the "N" constraint. Since heuristic is only a heuristic (can't be deterministic for reasons in my blog post), it might not solve the white space problem
Shrink text to fit	* Fits content without breaking other constraints	Can lead to unreadable entries As far as I can tell, this is simply not possible to do without writing an entire rendering engine.
Clip what doesn't fit	Ensures even line height Meets the "N" constraint	Brute-force arbitrary way of deciding what does and does not get shown Cuts of data that could be important * Depending on text or fonts, text could be cut off or bits from the line below could show (like in this sample)
Reduce Content Cx (This is currently supported to let the user do this)	Can help remove the constraint violation, fit the content If controlled by user, then very predictable and they can make their own prioritization decisions	Can cut off important data (signatures, details) If done by the system, then the decisions of what to trim are unlikely to match what the user wants. Few obvious heuristics for what to cut. (Images, for example, often contain important endorsements) If
Expand Entries But Hold N constant (I think this may be one variant of your suggestion, applied to printing)	N constraint is not violated Predictable - subtotals are every N flights, period	* Subtotals can be pushed to the next page, so you can have a lot of whitespace before the next page starts. E.g., if N=10 and you can only fit 8 flights on the first page, then 9, 10, and subtotals go on the second page, leaving the rest of that page blank.
Expand Entries But Hold N constant, eliminate page breaks (I think this may be the alternate variant of your suggestion, applied to printing)	N constraint is not violated Predictable * Very efficient use of whitespace (second only to continuous!)	* Subtotals will appear in random positions on each page. E.g., if N = 10, and only 8 flights fit on the first page, then you'll have 1-8 on page 1, then page 2 will have flights 9-10, subtotals, and probably only be able to fit, say, 4 more flights, meaning the page after that will have 6 flights, then subtotals, then one or two more.

Whatever your position on any of these solutions, I think that it's clear none of them is without tradeoffs. Something has to give when content gets big, there is no avoiding that.

Here are three data points that I think are informative about how to evaluate the pros/cons above:

• It is super clear to me from innumerable conversations with pilots over the years that (for the ones where "continuous" doesn't suit their purposes), the biggest issue is spillover and wasted whitespace. I.e., where if you have 10 flights per page with subtotals on most pages, but on one or two pages a flight or two (along with the page's subtotals) spill over to the next page. In all of those conversations,
• I've never had a pilot complain to me about not having precisely N flights between subtotals. After all, look at my paper logbook above - it only has 6 flights on a page built for 13!!! Most paper logbooks have "N" that varies from page.
• When I ask people about why they don't just use continuous, they say that sometimes a prospective employer will do spot checks on the math - pick a page and verify that the subtotals match the data on that page.

So this is why I have chosen "N" as the best constraint to break in printing. If I've missed an option above, please let me know; I would absolutely like to find a better solution.

OK....now to your suggestion, which is applied to the regular logbook view (as opposed to print view) I'm afraid it doesn't work for an interactive logbook view because running totals and subtotals only have meaning in ascending date and with all flights included, two attributes that are generally true for printed logbooks and NOT true for online (where the most recent flight on top makes sense to reduce scrolling). Otherwise the numbers on the screen can't be reconciled with each other. So I could do it when there is no filter applied and when the sort order is ascending, and suppress it otherwise. 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 (though I could put them at the bottom of each page, just using the page size to set "N".)

But here I ask...why? 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?

[KayRJay]

Thank you, Eric, for taking the time to respond to the issue of running totals down in pixels. I am sure your objections to trying to fit exactly N flights per page MyFlightBook are technically sound. I won't (can't) argue the case that any of the approaches you mention above are the right ones for getting a fixed number of flights per page on a printed report.

I’ve come to realize that the current printing feature of MyFlightBook has several limitations. The "flights per page" feature is only approximate. 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 very limited.

By the way, a user interface nit: the Printing options page uses the term “columns” for adding to the layout, and “properties” for excluding properties. Aren’t all “columns” really “properties”? if so, the terminology should be consistent.

I've thought a lot about ways to give users more flexibility in controlling what parameters are displayed, and how flights can be grouped for summarizing (totals). I have added new Github issues to address this topic. In issue #479, I propose using templates to control the properties displayed on the normal logbook view. In issue #481, I suggest an approach for grouping flights and summarizing them.

[ericberman]

Columns and properties are neither synonymous, nor interchangeable. You're thinking like a DB person here (where effectively, yes, they can be synonymous), not a non-technical end-user.

In the user interface terminology, a column refers to a vertical area in a two-dimensional layout - if it is not literally oriented along the y-axis on a screen or a page, it's not a column. This is the lay-person meaning of a column - it's got to be vertical to be a column. True in architecture, table layouts, and any other lay-meaning of the term.

A property, on the other hand, is simply a structured attribute attached to a flight. And from flight to flight, the set of properties attached to the flight can vary. In technical terms, a property is a data point in a sparse matrix. Unlike the "core" fields of a flight (which indeed do correspond 1:1 to MySQL columns int he database), a given property may or may not be present for a given flight. So a property actually doesn't even correspond to a column in the flights table (otherwise, the flights table would have over 700 columns and adding new properties would be a tremendously burdensome process).

The overlap between them is that I allow you to put some properties into columns in the print view (specifically: numeric columns that can be "added"; e.g., solo time and approach counts can be put in, but "Per Diem", or "Tach start" cannot.)

So, for example, in the image below:

The red and green areas are indeed columns. The green area is coincidentally a property that is in a column. And the blue area is a property, decidedly not in a column.

I'll respond about grouping/summarizing/subtotals in those issues.

[KayRJay]

Ok, I do understand the distinction (and I did ask, 'Aren’t all “columns” really “properties"?' ... and, in truth, the values shown in the columns ARE property values).

Thanks for the explanation of the underlying implementation. As a database guy, I do understand that the flights table couldn't possibly have 700 columns, and that there is (I assume) another table, with flight ID, property ID and a value for that property. I've seen this database design many times.

Though I am firstly a techie and not a trained user interface specialist, I do try to think like a user. To me, this is a key priority of a good product manager. It's why I've made most of the suggestions I've made. I think about typical use cases, ease of use, consistency (internally and with standards or conventions), the visual appearance ... and the kinds of understanding a typical user might have, among other things such as competitive products and alternative solutions. Users are probably mostly not sensitive to implementation considerations or minor semantic issues. I also prefer to "trust the user" (even to make mistakes), letting them be the judge of what they want or need, and I try not to pre-judge the relative value of plausible use cases.

In this instance, perhaps the problem isn't the use of the word "properties" or "columns", but the prompts:

• Choose up to 4 additional columns to display
• Exclude these properties when printing

The words "printing" and "display" are pretty similar. Neither term accurately describes where the value (of the property) is located in the "output". Also, you're not displaying "columns" at all ... you're displaying "property values" IN a column or in the description of a flight. Here's a suggestion for clearer prompts:

• Add up to 4 additional property values to the columnar display
• Exclude these properties from the flight description

By the way, it's not clear to me why only 23 certain properties can be added to be displayed in columns. This list includes many properties I've not used. Perhaps for some unstated reason these properties are those you think most relevant. or useful for the columns? However, it would seem that any property could be included, whether summable or not. Shouldn't this choice be up to the user?

Nor is it clear why only selected properties (out of 700) can be hidden. The list there includes many properties I don't believed I've ever used (and I'm pretty sure are not presently recorded for any of my flights). For example, I don't believe I've ever used the fuel-related properties or aerobatic time.

Further by the way, if that list does draw on the properties I've (ever) recorded for my flights, it seems it could be a very long list.

[ericberman]

I can clean up the language, though I find "property values to the columnar display" frightfully awkward phrasing. You actually are adding a column to the display that wasn't there before, so I think "additional columns" is both simple and correct. (And sometimes its not a "property" at all - e.g., it could be a category/class or complex time or similar, which is actually your total time conditioned on whether the model fits that attribute). Also "exclude these properties from the flight description" does only apply to the print view - it does NOT apply to the interactive logbook.

The set of properties that are displayed should be the subset of properties that you've ever logged, minus the ones that cannot be summed (since I show subtotals for these). You had "Aerobatic time" in your list of "Don't show these" properties, but indeed when I remove it from that list, I don't see any flights with aerobatic time. You also had a bunch of fuel related properties. I wonder if I have a bug where having something in your property blacklist is polluting the set of properties that I offer for extra columns. (And something could be in your blacklist because you had it at one point, but then deleted the last underlying property). Ill file a separate issue on that (issue #484)

But the short answer is that this list is generated dynamically based on your flying. There's obviously no point in listing, say, aircraft carrier landings if you've never logged a carrier landing.

[ericberman]

Just checked - when I removed the fuel properties from your blacklist, they disappeared from the print view optional column drop-downs. So that's a bug (Issue #484)

[ericberman]

Oh, and yes - it could potentially be a very long list if you've used a wide diversity of properties. Drop-down lists are scrollable; it scales. I don't think there's a particular problem there. To your point: let the user decide what they want in this real estate.

[KayRJay]

I can clean up the language, though I find "property values to the columnar display" frightfully awkward phrasing.

Agreed. I didn't spend a lot of time thinking of alternatives as I had other thoughts to display. Other ideas:

• Tabulate up to 4 additional properties
• Show and summarize up to 4 additional properties

You actually are adding a column to the display that wasn't there before, so I think "additional columns" is both simple and correct.

Yes, that's true, but the significant thing is that you're choosing WHAT to add, not just the container (the column). So, it's not INcorrect, but doesn't focus on the most important aspect of what's being added, the property (value).

(And sometimes its not a "property" at all - e.g., it could be a category/class or complex time or similar, which is actually your total time conditioned on whether the model fits that attribute).

Well, in the vernacular, something like the category/class or complex time is a "property" of (the plane used for a) flight. From an implementation viewpoint (again, not something the user thinks about), it is not stored as a property of the flight directly, but indirectly, via a chain of other properties or values.

Also "exclude these properties from the flight description" does only apply to the print view - it does NOT apply to the interactive logbook.

Yes, I mentioned this entire topic as a nit in printing options, and wasn't referencing the logbook view.

The set of properties that are displayed should be the subset of properties that you've ever logged, minus the ones that cannot be summed (since I show subtotals for these).

Why are the property values that are in the columns on the right of the printed report only those that can be summed? There is no need for subtotals of all of the columns. My Gleim manual logbook has a column for type & location of instrument approaches. Jeppesen has "duration of flight" as a column. While I don't think there is a strong case for non-summable properties in columns, it does make it easier to scan a list of flights in the printed report, to look for certain properties.

something could be in your blacklist because you had it at one point, but then deleted the last underlying property

I think I did do that.

Thanks for investigating and fixing the bug in issue #484

Oh, and yes - it could potentially be a very long list if you've used a wide diversity of properties. Drop-down lists are scrollable; it scales. I don't think there's a particular problem there. To your point: let the user decide what they want in this real estate.

It doesn't look like the list of properties to EXCLUDE is a scrollable list. Maybe it changes to one if there is a long list of properties?

[ericberman]

The list of properties to exclude is not a scrollable list. It's mutli-select, not "pick one". It's scalability comes from being in an expand/collapse group.

[KayRJay]

I'd argue that on/off isn't "scalable". It's a fixed size ... zero or potentially a lot of space. Scalability is "the capacity to be changed in size or scale", not just display or hide something. A scrollable list can be of fixed size, or can be enlarged/shrunk to contain more or fewer items. That's scalability.

[ericberman]

I also required summable properties because the column for two reasons:

• Numeric fields have a very narrow bell curve of widths, so the column can fit. Putting free-form text fields/people's names/etc. does not work very well with many layouts.
• In order to support subtotals on some properties, the system has to have all of the infrastructure to compute/store the subtotals. But the code that knows how to do this is pretty far divorced from any of the semantics of what's in the column. So for simplicity (on my end), this is for numeric summable fields. (So "Fuel Added" is OK, because it's summable, but "fuel level" isn't).

[ericberman]

The expandable checkbox list of properties is a paradigm I use all over the place. E.g., the search query form. I've never had any feedback that it doesn't work. Sure, I could make it scroll, but then hey, you need to scroll it, which you need to do with a large expand/collapse list anyhow. What do you propose as an improvement that would be significant enough to warrant doing?

[KayRJay]

free-form text fields/people's names/etc. does not work very well with many layouts.

I think you're focused on "standard layouts". I'm not. The idea here is to give the user complete control, via templates, over what columns are displayed in the logbook view rather than the printed report. Templates (other than your "layouts", which are not the new "templates") have nothing to do with printed reports.

This present topic is actually in the wrong place. I spent time on templates because I was interested in the logbook view. I'll reply more on that issue soon.

If a user wants to scan the logbook list of flights with a given name (for example), why not let him choose to take up that space (perhaps up to a limited number of characters)? The entire page width could be used, just as it is today in the logbook. When the page width is bigger than the window, the user can scroll left and right in the window.

In order to support subtotals on some properties, the system has to have all of the infrastructure to compute/store the subtotals. But the code that knows how to do this is pretty far divorced from any of the semantics of what's in the column.

I can understand this consideration. I don't know whether or not summing summable properties would be difficult in the logbook view. I don't know if you have a tag on a property that indicates it is summable. If you do, then it would seem easy enough, when presenting totals, to include totals only for summable properties.

[KayRJay]

The expandable checkbox list of properties as in the the search query form makes the entire search form "scalable", not each list of groups of search criteria. For the entire page, this expand/collapse paradigm works.

It's when a single "thing" (the list of excludable properties") gets large that a more scalable solution might be helpful.

I'm not actually suggesting that (for me) I need a scalable or scrollable region for the excludable properties. Nothing should be done now. I'm just commenting on your claim that the current list is "scalable".

[ericberman]

Yes, here (issue 460, about printing), I am indeed focused on the print layouts. I have 9 of them and they require a decent amount of hand-tuning to work correctly. The flexibility of full customization would be nice, but it would be an insane amount of work to do and it would still be hard to make something that looks good.

[KayRJay]

Yup. I gave up arguing about the printing subsystem. I'm thinking that logbook view plus templates might yield a significant amount of customization without incredible amounts of work.

[ericberman]

I agree that logbook view + templates would be awesome, I'm much less clear how to do it without a large amount of work.

[KayRJay]

Great .. .well, let's talk about that! ;-)