Why limit row/col contents in category summary?

John Keating

The new reporting features allow more flexibility, but for some reason the category summary still has arbitrary restrictions. Why can't rows and columns use the same list of choices? Is there some reason that rows can't represent "time" or "account", or that columns can't be "category"?

RickO

That's because the Category Summary (and Payee Summary) are older legacy reports are being deprecated. Instead of using those, you will want to be using the new "Create Summary Report", which was developed using a new reporting engine under the hood. This report does basically the same thing, but is much more flexible in its customization. 

Have you tried this? Is there something that Category Summary does for you that Summary Report doesn't? If so, it might just be a matter of finding the right customization.

John Keating

I was actually talking about the new reports. When I "Create Summary Report", I'm presented with the attached popup that lists content choices for rows and columns. But the options are different for rows than for columns, which seems arbitrary and less flexible. I can't make the Y-axis (rows) be "time" for example.

RickO

Sorry I didn't understand what you were getting at. And re-reading your original post, I probably should have. 

I don't see why, for example, you couldn't have Time for rows and Categories for columns. In this example, you would only want to run that with the number of categories limited or you could have a VERY wide report.

That said, would this report really get you any info that you don't have in the reciprocal report with Categories as rows and Time as columns (other than the formatting, of course)? As a workaround, I suppose you could export to Excel and transpose the rows/columns (menu Edit > Paste Special > Transpose). I'm not sure if Numbers has that ability.

I don't think this has been suggested as an IDEA topic, but I'll ask the mods if your post should be converted to one.

jacobs

I agree with what RickO said. As to feasibility, I'd just note that we are three years  into the development of a new reports engine -- and it's still not complete. The developers have mostly prioritized adding capabilities the program is completely lacking over ease-of-use refinements that some users would like.

It's a database, so it certainly could be programmed to allow additional options for rows and columns, but all of those options do add additional coding work -- sometimes relatively easy, sometimes incredibly complex. So while I'm not at all opposed to this idea for greater report flexibility, I'm just trying to set expectations why this might not be high on the priority list. Especially since exporting to a spreadsheet and transposing rows and columns is pretty quick and easy to do in both Excel and Numbers.

John Keating

I agree that this isn't what I'd characterize as a critical feature; more that it's a feature of QM7 that was lost in transition. And I was pondering the reasoning behind the current design since, from a programming perspective, implementing the more flexible general case (rows and columns have all the same options) is often as easy, or even easier than imposing artificial limitations.

Of course you're both right that I can have the spreadsheet do the transposition which is what I'm doing now. Just wanted to get insight into the design decision is all.

Regarding wide reports - I have over 30 years of data but less than ten tags, which would be my columns, so putting time on the Y-axis would actually narrow my reports.

jacobs

John Keating said:

from a programming perspective, implementing the more flexible general case (rows and columns have all the same options) is often as easy, or even easier than imposing artificial limitations.

Maybe, but definitely not always. I've dealt with databases where every permutation needs to be built as a complex SQL query, either to simply get the right data out or so performance isn't unbearably sluggish. To the user, it looks simple to select the report criteria from menus or radio buttons, but behind the scenes there can be a lot of complicated code to make it work. I don't know about the structure of the Quicken database, but I know it's pretty complex due to the mix of banking and investment data, which are structured differently. Judging by the time it's been taking for them to build the new reports, I would guess that more options for rows and columns would require a not-insubstantial amount of time. That's just a guess, though. Perhaps they built it in a way that it actually is easily extensible, but they just haven't taken the time to go back to add more options because they didn't see it as a high priority need.

John Keating

Agreed. Even though I write code for a living, I'm not familiar with their underlying db structure so we can only speculate. I just want to make sure the current UI design choice wasn't made for lack of awareness of the value of providing flexible row/col choices.