Printing from an electronic logbook and traditional "paper" logbooks

A few months ago, I had a blog post about printing from MyFlightbook.

I had a Facebook conversation with a pilot today about why sometimes the per-page subtotals spill onto an additional page, consuming extra paper and occasionally leaving swaths of blank space on a page.

The question he asked was twofold: (a) why do I have the extra clutter of having additional category/class rows in the per-page subtotals, and (b) why can't I reliably keep a page's flights the subtotals for that page actually on a single printed page?  Specifically: "is the challenge regarding the coding of it?"

It's a perfectly legitimate question, and I realize my earlier post may not have sufficiently or clearly explained that, so I decided to dive in and answer in a bit more depth, which I'm reproducing below (lightly edited for clarity, to remove typos, and to translate from Facebook format):

First: why do my per-page subtotals subdivide by category/class?

Paper logbooks put each category/class into their own columns. This makes sense for exactly one reason - allowing you to compute category/class totals by hand. You can't do (easy) hand summation if category/classes are co-mingled in a single column. (Of course, computers don't care, that works just fine).

But there are two really bad tradeoffs for doing this: one is that columns don't scale well at all. So if you've got some ASEL time, some ASES time, some AMEL time, some glider time, some balloon time, some helicopter time, ...well, now when you go to print you have a 2-dimensional problem: each flight of your logbook needs to spill over across two horizontal pages (Or, columns need to narrow, which means everything needs to grow vertically and becomes really hard to read!!!).

The other really bad tradeoff is that it effectively means you need to limit the number of category/classes you support. This is why most paper logbooks are focused on JUST airplanes, or JUST gliders, and might have only one column for "other".

Those are bad - but necessary - tradeoffs in the paper world. But in the electronic world, these are simply terrible tradeoffs, especially since the exact problem that they're trying to solve (aiding human computation of totals) doesn't exist once computers are can do the math.

So if you did this in the electronic world, you'd get all the downside with none of the upside. That seems utterly ridiculous.

For this reason, I striped the per-page subtotals by category/class because adding rows works great (stays within the flow of reading from page to page) but adding columns doesn't.

So - why can't I do a better job of keeping things on a page, from occasionally spilling on a page?

I'll back up for a moment to another problem with paper: the form in the paper world is sized and printed before any content is added. I.e., the layout is fixed. So you have three choices when you fill in oversized data:

• You can "spill over", with one flight spanning more than one row of the paper page;
• You can "clip" your data - stopping when you hit the boundary of the flight's row and discarding what didn't fit;
• Or you can "shrink to fit", making the text smaller and smaller until it fits the allotted space.

All of those are truly terrible solutions, but with paper, they are the only options; you can only choose the least evil.

In the electronic world, however, that ridiculous constraint is removed: the row can shrink or grow to accommodate the data. i.e., each row can be a unique height that is appropriate for the data contained therein.

So...your question was "is the challenge regarding the coding of it." At one level, the answer is "no, it's not complicated".

What you would do in this scenario is add a flight to the page, compute the subtotals for the page,  add those subtotals to the page as well, and see if it fits. Then repeat for the next flight. If the flight you add causes the subtotals to spill to the next page, then back up to where you were just prior to adding the flight, finish off that page, then start a new page with the new flight. There are a few other issues, but at the core, that's the process and it's straightforward.

Here we get to an architectural issue. MyFlightbook uses an abstract layout methodology (HTML). So I say "here's a row of a table; it has these cells and each cell contains this text." MyFlightbook doesn't know anything about fonts, font sizes, pixels, word wrapping, page margins, page dimensions, screen or printer resolutions, or a whole slew of other things that are required in order to figure out what to draw on a page. That is all handled on the web by the browser (which takes the HTML and converts it into stuff on a screen), or by the PDF generator that I use, which does the exact same thing as a browser, except that instead of drawing on the screen it draws into a PDF file.

So I can't implement the algorithm I described above (add a row, see if it fits, if not, start a new page). That is, I have to render the entire page in HTML, and THEN either send it to you so that your browser can render it to the screen, or send it to the PDF generator so that I can send you a PDF file. There's no ability to have the back-and-forth interaction that such an algorithm requires.

The ONLY way to solve that is to build an entire rendering engine - something that DOES know how to measure things, lay them out on the screen, perform word wrapping, make tables fit their contents (itself actually a really hard problem). I.e., I would quite literally need to re-implement most of what a browser does.

But I think about the herculean effort that represents (much bigger than all of MyFlightbook combined - and MyFlightbook actually isn't a small piece of code!), and I step back and ask "what problem would this solve?"

The answer is simple: per-page subtotals. That's it. No other purpose whatsoever is served.

And what makes per-page subtotals so important? Paper tradition. Per page subtotals serve exactly one purpose: if you're doing manual computation, you don't want to go back to the start of your logbook every time you want to compute your totals; that's ridiculous with a pen and paper. But in the electronic world, computers don't complain about doing that. So per-page sub-totals are an insane holdover from paper-and-pencil human arithmetic. Why on earth let an artifact of the 14th century drive such a massive software undertaking?

So in summary, the correct answer to the question "is the challenge regarding the coding of it", the answer is "yes. It would require literally thousands of man years of effort to actually solve an obsolete problem."

My suggestion? Turn off per-page subtotals. They are truly utterly pointless. "Continuous" mode will make much more efficient use of your paper and will still get the math right because computers don't make math mistakes. And your pagination will work great.

Update: since writing this blog post, I have added a hack to allow for better pagination.  If you have, say, 10 flights per page and on one page the 9th and 10th flights are "spilling over" onto a new page, you can edit the 8th flight on that page to include "///---" at the end of the comments.  The "///" and everything after is not included in the print layout, but it will force a new page after that flight, so what had been the 9th and 10th flight alone on a new page in this example would now be the 1st and 2nd flight on a new 10-flight page.

Declutter your life and your logbook

Marie Kondo is a surprise hit on Netflix, with her advice about getting rid of things in your life that no longer bring you joy.

Why not declutter your logbook in the same way?

After a few years of flying, you may find that your totals or currency get filled with all sorts of data that you have accumulated but about which you no longer need to be reminded on a continual basis.

MyFlightbook has options that can help.  Interestingly, MyFlightbook has no preconceived list of possible items to include in totals or in currency.  Instead, the system computes totals of all things that can be totaled and computes all currencies that could apply to your flying.  As a first stage of decluttering, the system then prunes away any total that is 0 and any currency that was never achieved.  But that can still leave a lot of "noise" values.

There are multiple options on the site that can further reduce clutter; most can be found in "Preferences" under the "Profile" tab.

Probably the easiest clutter to remove is expired currencies.  If you're an active pilot, you obviously want to know when your currency expires for any of the flying that you do on a regular basis.  But suppose that (like me) you once took a single lesson in a helicopter, in which you did 3 takeoffs/landings.  That was enough to make you current per 61.57(a), but you never pursued your rating nor do you intend to.  That expired currency is just clutter - remove it.

You can specify how long expired currency should show as follows:

 

And thus that meaningless expired currency will no longer crowd out your more meaningful ones.

Next on the list of clutter to remove is properties that can contribute to totals, but which aren't terribly meaningful.  By default, any property that can be counted (e.g., number of ILS approaches) or that is a time (e.g., safety pilot time) is included in totals.  But a good example of properties you might not care to track is maneuvers that you might have logged while training for a rating, but which you otherwise don't perform any more.

All of the properties you have ever used on a flight are in one of the two boxes above.  You can drag-and-drop from one to the other.  Properties on the left are "active" - ones that you use on a regular basis.  The ones on the right are inactive; by designating them as such you get two clutter-reducing benefits: 

• These properties are not shown by default on the screen for entering new flights (but they are still available for you to use if the need arises)
• Sums of these (such as the number of 180-degree power off accuracy landings or NDB approaches, in my example above) will not be included in your totals

One of the questions I am most frequently asked is how to log complex time.  The answer, of course, is that you don't: this is computed for you automatically, and displayed in totals.  There are actually a fair number of such totals that can show up in this manner: Turbine, Tailwheel, Complex, High Performance, and Retract (that isn't complex), and for each of these, there is total time, PIC time, and SIC time.  While any of these that are zero are pruned automatically, that's potentially 15 different items showing up in your totals!

You can turn these off under "Currency/Totals":

 

There's one more item that can reduce clutter in totals, and this starts to bleed over into reducing clutter in your overall logbook display.  MyFlightbook can record hobbs start/stop, engine start/stop, and flight start/stop automatically.  (You can also do tach time and block time, but these can't be detected by the mobile apps and are in the list of additional flight properties, whereas hobbs/flight/engine are "baked in" to the core flight).  

If a flight has both ends of hobbs, flight, or engine defined, and they are in the correct order (i.e., hobbs end is larger than hobbs start), then the elapsed hobbs/flight/engine time for that flight will accrue to a total elapsed hobbs/flight/engine time in your totals.

This is off by default (so is pre-de-cluttered?), but you can control it under flight entry:

This has three clutter-controlling aspects: 

• It controls whether or not totals include total elapsed hobbs/flight/engine time;
• It controls whether the "times and telemetry" section of the New Flight form is expanded by default; and
• It controls whether hobbs/engine/flight times are displayed by default in your list of flights

There are two other options above - CFI time and SIC time.  These are two additional "baked in" attributes of a flight (since they are available in just about every paper logbook...ever), and they're fields that a large percentage of pilots will use, but which any individual pilot either uses frequently or never uses.  For this reason you can turn these off/on as well.  This impacts whether the CFI and SIC fields show for new flights, and whether or not columns for them are shown by default in the list of your flights.  It does not affect the display of any non-zero CFI or SIC totals.

This leads naturally to some clutter-reducing tips for the display of your flights.

You may have noticed that next to the count of your flights is a drop-arrow.  If you click that, you can see some options for controlling the display:

Showing in pages vs. all of your flights isn't about clutter as much as it is about scrolling and performance (both network and browser), but it can be a nice option if you don't want to go page-by-page through your logbook.

But the compact view and the option to show images in-line are both great ways to control clutter in your display.

The compact view simply collapses each flight to a single line, consisting of date/route/comments.  You can click to expand the flight to see more details.

Images are, by default, decluttered, in that you have to hover your mouse over a camera icon to view them.  But if you prefer to have them show without moving the mouse, you can turn on this option to see the images directly.

Finally, I'll leave you with a clutter-reducing tip for your aircraft.  If you look next to each aircraft in your aircraft list, you'll see a drop-arrow there.  Click it, and you can designate the aircraft as active or inactive:

(You can also designate an aircraft as active/inactive using the Android or iOS app; tap the aircraft and you'll see the option; don't forget to update the aircraft to save your change!)

Active aircraft show up in the list of aircraft available for new flights, and show up on the search form; inactive aircraft do not.  If you've flown a lot of aircraft over the years but are currently flying just a few, this can greatly simplify your life.

So whether or not you follow Kondo's advice in your life on the ground, I hope you can reduce the clutter in your logbook!