Report data display panel is always too tall to fit entirely on screen

@Coach Kristina — regarding your questions:

-Is this happening exclusively on the web app? - I only use the web browser and web app. It happens in both.

-Do you encounter the same issue using other browsers? — Yes. It is exactly the same in Edge.

-Do you encounter this issue across multiple devices, or are you seeing it on just on device? — I only access Simplifi on my computer, no other devices.

-What other reports have you noticed this issue happening with?

None other has this same problem, as far as I can tell.

It does not happen with the Taxes report, where the data panel fits vertically within the screen and the data scrolls within it (using it's own internal vertical scroll bar). This shows how the Profit & Loss report should work.

The Spending, Income, Net Income and Savings reports have Transaction Activity data panels, which expand to fit the rows of data (rather than having an internal vertical scroll bar). Their columns also auto-adjust to fit the screen width, so they don't have the same issue with the horizontal scroll bar not being accessible.

The Net Worth report data panel also expands to fit the rows of data, like the Transaction Activity panels.

@Coach Jon

Ok, here are duplicates of the images I shared earlier, but this time from the Edge browser:

In this first full-window snip, the column headers are visible and the portion of the report visible in the window appears to stop at the line "Insurance."

But if I scroll the entire report down slightly (using the farthest-right vertical scrollbar) you can see in the next snip that the report data panel actually extended below the screen and has two more lines as well as the horizontal scroll bar. (outlined in red)

REQUEST:

Can you post an image of how it looks on your computer so I can see what it is supposed to look like?

I am assuming that — as the data panel resizes itself based on window size — it is supposed to be sized such that both the column headers (at the top of the data panel) and the horizontal scroll bar (at the bottom of the data panel) are both visible on the screen.

@Coach Jon

"I do not see a horizontal scroll bar. Which is why I think this is probably device-specific."

In your image, you do not see a horizontal scroll bar because you have not scrolled the entire report window to its bottom. In fact, the way you have it positioned, you don't see the column headers either. Otherwise, your image looks just like my screen. So probably not device-specific.

In what follows (for clarity) I will call the panel within the Profit & Loss window — where the column headers, the lines of data, and the horizontal scrollbar live — the "data panel."

You can reveal the data panel column headers by moving up the outermost (rightmost) scrollbar up. (Don't use the scrollbar for the data panel. Use the one outlined in red below.)

Then, when you move outermost (rightmost) scrollbar down a little bit, you will see the horizontal scrollbar for the data panel, which was just offscreen to the bottom by a few lines.

The problem is well-illustrated by the image you posted. The data panel resizes itself when the window is resized, but it always settles on a size that is just 3-4 lines too tall for the user to see both the column headers at the top and the last few lines of data and scrollbar at the bottom. (In your case, you positioned it where you couldn't see either one.)

I think this is a bug. There is no reason for the data panel to be just 3-4 lines to big to fit on the screen. It is not like it is resizing itself to show all the lines of data in the report. That would make some sort of sense. It's pretty obvious that the developers tried to make it resize to fit the screen. They just missed by a bit.

"The scroll bars are utilized to see any data that is currently not showing when scrolling."

True. And that's what is happening in the images above. The January-October columns are on screen while the November-December columns are off screen to the right and "currently not showing."

The way things stand now, users can either (1) see the column headings at the top, but the scroll bar at the bottom is just off-screen, or (2) see the scroll bar, but the column headings are just off-screen.

But if that's not a bug — meaning, I guess, that the designed behavior is for the data panel to be just a smidge too tall for the screen — well, I don't think I will be able to convince those designers to change it.

@Coach Jon

I'm not sure if I can do any better at explaining this to you.

I'll give it one more try if you will walk through these steps with me. I will number them so you can tell me which part you don't understand or don't agree with.

(1) Simplifi is setting the height of the data panel (see above definition) so that it is always slightly taller than the available space in the window. Lets call the height "X lines" for these purposes.

(2) Simplifi does not do this to accommodate all the lines of data. If you have more that X lines of data — as is usually the case — you still have to use the data panel's vertical scroll bar to see them.

(3) Because of the chosen data panel height, the user cannot see the column labels at the top of the panel and the horizontal scroll bar at the bottom of the panel at the same time. It's either one or the other.

(4) Many reports (like a yearly report) have enough columns (identified by column headings) to exceed the width of the screen so that the user has to use the horizontal scrollbar to move back and forth to see them all.

(5) If Simplifi chose a slightly lesser height, say "X-3 lines," the user could see the column headings and the horizontal scroll bar at the same time. Then the user would be able to see what months they were scrolling on and off the screen when they are using the scroll bar.

I believe the above are all factual statements, not evaluations or suggestions. They are either true or not.

The following, on the other hand, are my thoughts about what is wrong and what went wrong.

(6) Providing the extra 3 lines of data space in the data panel doesn't accomplish anything significant. The user still has to scroll to see most of their data. There is no reason to do it that way.

(7) Reducing the data space in the data panel by 3 lines, on the other hand, would allow easier viewing of reports that exceed the screen width, like yearly "by month" reports. So there is reason to do it this way.

(8) It is likely that the programmers intended the data panel to fit in the screen but botched the "current visible height" calculation. (I have made this same mistake myself in systems I have programmed.)

(9) This is a bug because what the program is actually doing does not match what was intended.

It's as if a text data field used font that was just a couple of pixels to tall to fit. You could still read it, so you could say "Well, it's not a bug." But I think most would agree that it was mistake to be corrected.

That's all I've got. I'm sure you'll let me know which of these you disagree with.

@Coach Jon

I structured my previous post to make it easy for you to clarify why you don't consider this a bug.

I was disappointed that your response was only "I understand … but I still do not think this is a bug."

In the absence of a more substantive response — and I am not asking for one at this point — I really have no idea how to look at future issues and determine whether to make a bug report.

I thought that the apparently unintentional nature of this "feature" and its negative impact on the usability of full-year Profit & Loss reports (critical to businesses) would be enough. It's not… because…

Anyway, thanks for being so prompt in responding on this thread.

(I don't think this is suitable for an Idea Post, so I won't be making one.)

I get it.

In my work, we looked at things differently. Whenever something that was not working as we intended it to work when we programmed it, we considered it a bug and put it on the backlog, rated for severity.

I view your analysis is more related to bug severity — where bugs are rated as Low/Medium/High/Critical severity (or priority) depending on their effect on the user. That rating determined how likely a bug was to be addressed anytime soon.

We put bugs of all severities on the backlog for two purposes: (1) the unlikely event that we would have the time to address low-severity bugs, and (2) the more likely event that we would be reworking a certain part of the program and could address the issue at that time for little or no cost.

It sounds like your product team only wants you to report bugs in the High and Critical range. As a user, I don't like that. But I can understand it.