The Totals info takes up a lot of space; it can be more compact

[KayRJay]

The Totals page provides some useful summary information, but it could be better organized, more clear and more compact. Related items should be close to one another, grouped into adjacent lines. Also the display can use less real estate (always a concern, right?). Also, not sure why total time is listed after ASEL without a label, as it does appear later, properly labeled.

(I realize that what is displayed is, as usual, a function of what data has been entered/used. I'm not aware of the full potential of the Totals display. I realize, too, that some items are underlined, so a click executers a query. This feature could of course be retained in a more compact display. The iOS/Android app need not change.)

Instead of

ASEL: 103.8 173 Landings (2 Day), 1 Approach 103.8 Cross-Country Time over 50nm: 6.6 Go-arounds: 19 Ground Instruction Received: 2.0 Landings - Stop and Go: 4 High Performance: 103.8 Flight Time: 0.72 Engine Time: 0.73 Cross Country: 6.6 Dual: 103.8 Total Time: 103.8

A format more like the following could be used, using up 8 lines (for my case) rather than 12. (I used "insert code" to approximate readable spacing in the below, but it would be nice if numbers aligned vertically for "beauty".)

ASEL Flights
Landings:  173 (2 Day), 1 Approach      Stop and Go:    4       Go-arounds:    19

ASEL Times
Flight Time:     0.72      Engine Time:     0.73
Total Time:     103.8     Dual:     103.8
Ground Instruction Received:     2.0
Cross Country:       6.6         Cross-Country Time over 50nm:      6.6

MSEL ....

[ericberman]

Total Time without a label is your total logged flight time. "ASEL" above is the subset of your total time that is in single-engine land aircraft. So it's showing your subtotals by category/class. E.g., my totals look like this:

Indeed, it is redundant if you've only ever flown one category/class of aircraft; but even then it serves a purpose in telling you which category/class your time is in (ASEL) and that it is all in that category/class.

From a technical perspective, it is absolutely easy to group the other subtotals by category/class (e.g., your dual time by category class, your cross-country time, etc.).

But note that (a) this is actually MORE information (albeit potentially more compact as well), but (b) generally NOT what you're looking for.

E.g., insurers and DPE's when you go for a checkride ask "how much total time do you have", or "how much cross-country time do you have". If I broke it all out by category/class, you'd have to add up multiple numbers (which aren't shown anywhere) instead of being able to read them right off. Whereas with the way I have it, if you want to know your cross-country time in multi-engine aircraft, you can simply click on AMEL and then read the resulting cross-country time.

Note also that doing a 2-dimensional layout like you suggest can use a lot of horizontal real-estate, which is generally more precious than vertical real estate, and (as you point out) doesn't work on iOS/Android - which would now get more lines because they are getting lots of sub-grouped totals where before they weren't.

I'm pretty comfortable that I have the right line items of information in totals; I'm open to alternative layouts if you want to draw a picture. But I think this specific proposal is actually putting more information into the report and (unless you add yet more lines - further distancing from "Compact"), actually removes the aggregate numbers that people generally need more than they need the sub-grouped numbers.

[ericberman]

BTW, note that the 8720 form does provide a bunch of these totals (and more - including combinations) segregated by category. That one is, of course, regulatory-driven, so it's not extensible.

[KayRJay]

I appreciate the response and explanation. Mostly it makes sense.

My intent was not to add or remove information (nor did I suggest displaying group totals). Instead, I suggested displaying the existing data in a more compact, readable way.

There is already some grouping of totals in the order used now, but it becomes easier to scan for info with a few changes and group labels. Multiple totals per line simply saves space (and pixels). The attached picture (with your data) uses 22 lines vs 35 lines currently, and would be even less if you omitted group headings, and/or have more totals per line (perhaps up to four in some groups?). You'd continue to display totals only for non-zero values, of course.

I don't see how a layout that uses more horizontal real-estate is a bad thing. If horizontal space is "more precious" than vertical real estate, then it isn't logical to waste it by leaving it blank. (On a very narrow page, flight comments wrap to multiple lines, as an aside.) As to iOS/Android, I did mention that it need not change at all.

[KayRJay]

Slightly more compact listing, with PIC / SIC for flight times in different aircraft. Saves 2 more lines.

[ericberman]

I think there may be something to these layouts.

Need to think about it - and of course, the grouping is a challenge since I'm generating a set of totals from multiple database queries, and they are all simply tuples of {Label, value, note/description, URL}. There are a few other fields to aid in rendering, but the key thing is that any semantics are (deliberately) completely abstracted away by the time they hit the display engine, so there's no notion of different "types" of totals, much less a notion of displaying them in different manners (such as breaking out a separate table for the category/class totals above in a different layout from the other groups). And within properties, we get into the whole morass of the fact that properties can be grouped in multiple non-mutually-exclusive taxonomies. I generate a list of totals, and then I hand them off to a renderer who displays them. This also means that I can modify my totals code (perhaps to add additional totals) without having to modify the renderer.

The day/night/approaches you see in small type under the total are even more abstracted: they're not clickable, and this is a localized description string that's handed to the renderer to display by the total; it can contain any text, the renderer can't make any assumptions about what it contains.

But it could be as simple as labeling these with the groups that they currently are (and are performed by distinct queries today): (a) category/class (or per-model) breakdowns, followed by (b) properties that can be totaled, followed by (c) model-feature totals (complex/retract/tailwheel/turbine), followed by (d) "core" totals (Night, IMC, ground sim, PIC, etc.) To your question about complex and retract: a complex aircraft has retractable gear (or is a seaplane, in which case it typically has retractable rudders) AND a controllable prop AND props. And by the way, I actually compute 3 totals for each of these: PIC, SIC, and Total, and I dedupe and prune. That's why you're seeing, for example, Turbine time and Turbine PIC time in my totals with different values)

BTW, what I meant above about "horizontal real estate" being precious was that horizontal scrolling sucks, while vertical scrolling is "natural". By which I mean that web pages are designed to grow vertically, and the human eye (for most languages) is trained to read side-to-side and then down to the next line, but if you have to scroll left and right to finish reading a line before going to the next, it's a terrible experience. I.e., you want the data to fit in the width allotted to it! I could probably address that by allowing totals to wrap atomically - e.g., go to a 2- or 3- column layout when space is available, else a 1- or 2- column layout.

Some other tricky things with breaking it out:

• need to ensure that each item is the same width or else the alignment gets off and it becomes really hard to read. Even from one group to another. E.g., in your image above, look at where the "102.6" for simulated instrument is vs. "314.62" from dual on the line above it.

I might play with a few layouts here.

[KayRJay]

Thanks, Eric. It's very helpful to get an understanding of the underlying implementation considerations. I do appreciate that the data structures you have must contain the info you need to format things in a certain way. You design is robust in that you can add things and treat them all the same way.

Of course you have a better understanding (as a pilot and the implementor) of what the "groups" should be. My almost certainly naive examples reflect my inexperience.

However ... "properties that can be totaled" is kind of a grab-bag, with many (600+?) different total-able things. This is too big a group, it seems. Without some sort of sub-grouping, a long list of totals is little better than the current display if there are many such properties in use.

I get that flight properties could be grouped in arbitrary and overlapping ways. Maybe it's worth re-thinking how properties can/should be grouped, both for this purpose and the user interface for selecting and displaying properties in the data entry and logbook screens. A naming/grouping taxonomy need not require that a given property is in only one group. Each property could be associated with a list of groups it belongs to, and damn the fact that there would be overlaps and redundancy. As long as the property name or value (or its total) is displayed in the proper groups, it doesn't matter if it is displayed more than once. But that's a topic for a different GitHub issue devoted to the subject, as discussed in issue #355.

It seems the "simple labeling" you mention does fit with the current model, without a lot of headaches. Since you currently execute different queries for the different groups (a)-(d), I'd imagine you'd send the result to a specific renderer appropriate for each format, rather than use one renderer for all.

I agree completely that horizontal scrolling using a scroll bar sucks. You do want the data to fit in the width allowed. But if the browser window is wide enough for your maximum display width, that's ok. There'd be no need to implement the automatic wrapping. (Seems users mostly would have a reasonable width window, else the comments field for flights wraps, making the display hard to read.)

Agree re the "pretty print" issue of alignment. My obviously manual attempts (using a mixture of tabs and spaces) was a fail. Each of the "items" (a label and a value) in a group needs to have a display width, and the label would be left-justified, and the value right-justified within that display width. All display widths in a group would be the same, and thus all "items" would align.

As always, thanks for considering my ramblings ...

[ericberman]

Agree on all of above (and don't worry, I knew that it was a sketch of a layout :))

Yes, "properties that can be totaled" is a large set - currently 385. The reason that you'd want any property grouping to be mutually exclusive would simply be so that the same property totals doesn't show up in multiple groups. I suppose you could designate a "primary" for purposes of totals, but then there are also a bunch of "one off" properties (e.g., "Alaska Time" for tracking time spent in Alaska - yes, there's actually regulatory reasons for tracking that!) that I guess would need to go into a "Misc" bucket. So solvable...

I'd still use one renderer for each group. I don't want the rendering engine to know about one group or another.

[KayRJay]

I think we're not communicating clearly. I don't suggest that the total for a property would be different in different groups. The total for the property is the same, no matter how many groups it is displayed in. There is no need to have different types of totals. A given property ... with the same identical value ... might be displayed in multiple groups. Groups are only for display, and have nothing to do with the underlying calculations. Thus, mutual exclusivity is not a problem ... you total the values for the property ONCE, and display it wherever its group is displayed.

[ericberman]

No, I understood. The point was to suppose, say, the "ILS Approaches" is in two groups for purposes of finding the group (perhaps "Approaches" and "Instrument flight" and "Instrument training", for the sake of argument). I.e., for purposes of Issue #355, it could be in multiple groups. Then when totaling this property, per the sample you did above, would the resulting total go into the "Approaches" section or the "Training Related" section, or both? My suggestion was that if I were to do these groups, one could be designated as "primary" for this purpose. I don't think you want to display the total multiple times - that really is a waste of space.

BTW, a minor issue perhaps - if I go to laying out some totals horizontally relative to others, then I can't use an HTML table, since it doesn't support wrapping semantics as you resize a window; this can make cut/paste into a spreadsheet more difficult. I'm not sure if that's a significant issue. Worth playing around with and seeing what the tradeoffs are.

[KayRJay]

The "primary" group is a good idea, using your best judgement for each property which is the "primary" group.

It's almost certainly overkill to consider any further refinement on this idea. However, just to complete this discussion, you could allow the user to specify, for each property, in which group or groups the total should be displayed. Further overkill would be to make it a user option to display any group of totals, and/or support collapsing groups of totals. (This is of course all too much to consider, as these choices should be persistent per user.)

Re tables and wrapping: based on some initial Googling, it may be that CSS tables instead of HTML tables might work. CSS tables have a lot more flexibility than traditional HTML tables. Instead of wrapping a table's rows, CSS tables can be "responsive", with horizontal scrolling. While horizontal scrolling is generally horrible, it wouldn't likely be necessary with a layout like those above, unless the browser page was extremely narrow. CSS tables address the cut/paste issue and permit word wrap within table cells, while addressing narrow page widths.

[ericberman]

"CSS Tables" is still an html table. The essence is still that it's rows and columns, and the cell content determines width/height of each. If it's a 4-column table, it's a 4 column table regardless of the page width. The data wraps within cells as needed. The "responsive" just accomodates with a scrollbar.

What I'd love is to have snaking columns, like what page layout programs can do (think how some newspapers work): you read down one column to the bottom, then go up to the top of the next column to read. So as the window resizes from narrow to wide, you go from a long narrow single column, to two columns, to three columns. I'm not aware of any HTML solution to do that.

The closest I'm aware of (which is pretty straightforward to do) is to make each total item a fixed-width

(so that the alignment works) with inline-block display. Then they will wrap atomically, traditional word-wrap style (i.e., you still read horizontally then go to the next line) as opposed to the snaking column model. Doing this, though, does mean leaving tables behind so that cut/paste into a word processor or Excel would stop working.

Another option is to make the display explicit: have a button to switch between a linear layout and some sort of two-dimensional layout. At least then if you have horizontal scrolling issues, you chose it.

[KayRJay]

Isn't the behavior of a CSS table exactly what you want? I just tried cutting/pasting a CSS table into Excel and it seems to work fine, and from what I (probably mis-)understood, the display characteristics are appropriate too.

Make a group's table have a fixed number of columns, where some of the cells can be empty/blank. Left-align the total's label in the cell, and the value right-aligned with the align attribute. The wrapping within cells seems to be just what's needed. I'm sure I'm missing something. Without borders around cells, it would look very much like my samples, no?

[ericberman]

A CSS table is still a table. Its column/row dimensions are fixed - if it's 4 columns x 15 rows, then it's always 4 columns x 15 rows. I want something where the number of columns varies based on the window size.

[KayRJay]

Why would you want the number of columns to change based on the window size?

I'm not sure why all the totals across all groups would need to be displayed in the same table. What if each group were displayed in its own table with the appropriate number of group-specific rows and columns? I assume you can know the number of value pairs to be displayed within each group. (This might or might not mean each group required a separate cut/paste into a spreadsheet, but no big deal.)

Or, suppose all groups were displayed in one table. That would just mean some columns are unnecessarily wide. But if the cells have no borders, it would probably look ok.

[ericberman]

You could certainly do separate tables, but that doesn't address the dynamic layout problem.

E.g., take the flight types section above. On an iPhone (narrow width), you'd want it to look like this: Solo:xxx Night:xxx Dual:xxx X-C:xxx IMC:xxx PIC:xxx

On the iPad, or a wider window, you'd want this: Solo: xxx X-C: xxx Night:xxx IMC: xxx Dual:xxx PIC: xxxx

I.e., you've gone from 6 rows x 2 columns to 3 rows x 4 columns

And on a wider screen, you could even go: Solo: xxx X-C: xxxx Night: xxx IMC:xxx Dual:xxxx PIC: xxx

I.e., 2 row x 6 columns.

(Snaking would do the same thing, just in a vertical orientation).

Neither of these is possible with HTML tables (there is no such thing as a "CSS Table"; that's just an HTML table that is formatted with CSS.) And that's really the only way to simultaneously fill horizontal space while allowing for multiple screen widths AND avoid horizontal scrolling.

So really the only way to do this is to go away from tables. I can get precisely the behavior I want above by making each label+value pair a pre-defined width block ("div" in HTML parlance) and let them wrap like words in a paragraph do. Then you'll get as many as can fit, and as the window gets narrower, they will just wrap to lay out accordingly. But - by definition - you've lost tables.

One big table vs. multiple independent ones really doesn't factor into this. The only tradeoff there is column alignment works better in a single big table because column widths are uniformly adjusted based on all of the content. But you could absolutely do separate tables, using a fixed width to ensure alignment across table boundaries.

[KayRJay]

Ok, makes sense. It's surely fine if cut/paste into a spreadsheet requires some fooling around after the paste (like Data>Text to Columns in Excel).

Thanks!

[ericberman]

Playing with this a bit...I think there's something to this. Still some work to do, and there are a few oddities of the current implementation that this highlights. For example, in the current implementation, I keep your bottom-line total of overall flight hours on the literal bottom line. Here, it's grouped with Overall flight time. I think I might change the label of "overall flight time" to "Total times by kind of aircraft" (this can be category/class/type OR it can be model OR it can be ICAO code, based on preference). Note that I declared a fixed width for each item ahead of time - since these by definition (discussion above) can't be in a table that aligns itself to its content, I have to declare it.

Anyhow, I have a few more ideas and some clean up to do, but I think it's got enough legs that I'll implement this.

the three images below were simply the result of resizing the window - the layout changed dynamically.

[ericberman]

Mostly there on the core bits, but here's an interesting wrinkle. If you fly aircraft that require a type rating to fly, I show those as subtotals of the category/class. E.g., I have time in a piper seneca (no type rating required) and (for testing purposes) I added some sample time in a Boeing 777. In this scenario, i always show 3 or more totals items: your total non-type rated AMEL time (i.e,. the seneca time), your total in each distinct type-rating-required aircraft (e.g., 777 time, 747 time, A-320 time, etc.) and then your total for the category/class as a whole (all of these added together, since they're all multi-engine land aircraft).

In the vertical layout, it works because these are grouped together. I'm not sure it works as well in the 2-D layout, as shown in the picture below:

Or, as this image shows (if you had more type-rated time or a narrower window):

Probably just go with it...

[KayRJay]

Very cool, and a LOT more readable. Sensible groups of totals too.

Did you implement a name/taxonomy system that could improve searching for a property to add to a flight? Are there other places where this taxonomy might surface?

Thanks!

[ericberman]

No, taxonomy for properties is a bigger deal. This doesn’t prevent any such solution, though.

[KayRJay]

Care to describe the implementation of groups for totals, at least briefly for curious minds?

[ericberman]

Sure. I build a temporary denormalized table and do 4 queries against it:

• A query that groups by category/class (and type, if available), model, or ICAO. As necessary, it includes totals within each category/class too.
• A query that groups by model-feature (retract, turbine, tailwheel, complex) and further breaks down PIC/SIC, etc.
• A query that does totals for properties that are (a) times, (b) counts, or (c) currency (i.e., dollars), and which are not flagged as "nosum" (e.g., hourly rate is not something you'd add up)
• Finally, a query for the "main" fields (i.e., the stuff that is common across all logbooks and which is in my main flights table, as opposed to in properties), which includes the overall total.

Each of the above groups gets tagged with the group it belongs to, and I segregate out the overall total time so that I can put it on the bottom. (At the moment, doing it by text, which is not robust; one of the things I need to do before checking it in is to do this by an ordinal value, to aid in sorting and to ensure robustness).

[KayRJay]

Cool! Glad I could "help" ... rather, inspire ... you to do this. I think users will appreciate it!