[WIP] Add progress bars for categories and goals

[tbuist]

Fixes #2965

This change introduces visual bars to indicate the status of a particular category for that month.

For standard expense categories, green, red, and gray indicate the value you have remaining/overspent in that category.

For categories with a #goal template, the bar uses blue to indicate the progress.

[netlify]

✅ Deploy Preview for actualbudget ready!

Name	Link
🔨 Latest commit	3e954ef
🔍 Latest deploy log	https://app.netlify.com/sites/actualbudget/deploys/67c13616c983e30008ee8df9
😎 Deploy Preview	https://deploy-preview-4371.demo.actualbudget.org
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[github-actions]

Bundle Stats — desktop-client

Hey there, this message comes from a GitHub action that helps you and reviewers to understand how these changes affect the size of this project's bundle.

As this PR is updated, I'll keep you updated on how the bundle size is impacted.

Total

Files count	Total bundle size	% Changed
18	7.07 MB → 7.07 MB (+6.54 kB)	+0.09%

Changeset

File	Δ	Size
src/components/budget/ProgressBar.tsx	🆕 +5.3 kB	0 B → 5.3 kB
src/components/budget/envelope/EnvelopeBudgetContext.tsx	📈 +208 B (+25.03%)	831 B → 1.01 kB
src/components/budget/BudgetTotals.tsx	📈 +257 B (+7.94%)	3.16 kB → 3.41 kB
src/components/budget/BudgetTable.tsx	📈 +209 B (+3.28%)	6.23 kB → 6.43 kB
src/components/budget/envelope/EnvelopeBudgetComponents.tsx	📈 +487 B (+3.17%)	14.99 kB → 15.46 kB
src/components/budget/index.tsx	📈 +110 B (+1.20%)	8.95 kB → 9.05 kB

View detailed bundle breakdown

Added

No assets were added

Removed

No assets were removed

Bigger

Asset	File Size	% Changed
static/js/index.js	4.35 MB → 4.36 MB (+6.54 kB)	+0.15%

Smaller

No assets were smaller

Unchanged

Asset	File Size	% Changed
static/js/workbox-window.prod.es5.js	5.69 kB	0%
static/js/resize-observer.js	18.37 kB	0%
static/js/pt-BR.js	112.83 kB	0%
static/js/AppliedFilters.js	10.8 kB	0%
static/js/nl.js	97.78 kB	0%
static/js/uk.js	111.11 kB	0%
static/js/indexeddb-main-thread-worker-e59fee74.js	13.5 kB	0%
static/js/es.js	60.58 kB	0%
static/js/useAccountPreviewTransactions.js	1.69 kB	0%
static/js/wide.js	102.9 kB	0%
static/js/fr.js	88.87 kB	0%
static/js/narrow.js	86.23 kB	0%
static/js/de.js	114.35 kB	0%
static/js/BackgroundImage.js	122.29 kB	0%
static/js/en.js	103.18 kB	0%
static/js/en-GB.js	98.67 kB	0%
static/js/ReportRouter.js	1.59 MB	0%

[github-actions]

Bundle Stats — loot-core

Hey there, this message comes from a GitHub action that helps you and reviewers to understand how these changes affect the size of this project's bundle.

As this PR is updated, I'll keep you updated on how the bundle size is impacted.

Total

Files count	Total bundle size	% Changed
1	1.34 MB	0%

Changeset

No files were changed

View detailed bundle breakdown

Added

No assets were added

Removed

No assets were removed

Bigger

No assets were bigger

Smaller

No assets were smaller

Unchanged

Asset	File Size	% Changed
kcab.worker.js	1.34 MB	0%

[youngcw]

Do you have to do something to turn on the progress bars?

What will happen when viewing multiple months?

[tbuist]

Do you have to do something to turn on the progress bars?

Yes, I added a global preference in the Themes section. I saw the documentation recommends against adding configuration for small UI tweaks, so I'm happy to hear feedback on if this is big enough to warrant a config option, or if it belongs somewhere else like a feature flag (or on by default, but I didn't want to presume).

What will happen when viewing multiple months?

The bars only appear in the sidebar that hosts the category titles, and only consider budgetting/spending in first month that is being looked at. Any thoughts about that? Two examples:

[Teprifer]

Do you have to do something to turn on the progress bars?

What will happen when viewing multiple months?

Tick box on the settings page by the theme selector.

Multi month looks like this, with the bars calculated for the left most month:

Multi-month presents a tricky UI challenge, probably simplest might be to have it only calculated for the current month, and all hidden when the current month isn't on screen.

My initial thoughts, were the bars look cramped.

Categories without any goal, budgeted, or spent, still have the bar space reserved.

Not sure about the mixed use of a bar to represent goal progress and budgeted vs spent as it's budgeting with goals, and usually goals are paired with templates, but the bar doesn't incorporate those because that way lies madness.

I can see a category bar will go red because an expense was recorded against it, indicator a 'negative' or bad thing, when really it's fine because the category balance is still positive, and the money for it had been budgeted in a prior month. So a little misleading?

Might be worth taking a look at #3424 which attempted to incorporate the multi-month aspects.

[tbuist]

Multi-month presents a tricky UI challenge, probably simplest might be to have it only calculated for the current month, and all hidden when the current month isn't on screen.

This seems reasonable and intuitive to me.

My initial thoughts, were the bars look cramped.

Categories without any goal, budgeted, or spent, still have the bar space reserved.

Currently the color would be empty at least, so the bar still shows but doesn't draw as much attention.

Not sure about the mixed use of a bar to represent goal progress and budgeted vs spent as it's budgeting with goals, and usually goals are paired with templates, but the bar doesn't incorporate those because that way lies madness.

Fair point.

I can see a category bar will go red because an expense was recorded against it, indicator a 'negative' or bad thing, when really it's fine because the category balance is still positive, and the money for it had been budgeted in a prior month. So a little misleading?

Also a fair point.

Might be worth taking a look at #3424 which attempted to incorporate the multi-month aspects.

Wow, I'm not sure how I missed that entire thread when looking for other attempts at this problem. After skimming, this does seem like a more complex attempt than what I intended mine to be. Thinking more deeply about what I envisioned these bars representing, I think I was targeting only the two most basic use cases:

1. For expense/template categories in one particular month, how much did I intend to spend, and how much did I actually spend?
2. For goal categories in one particular month, how much did I intend to save, and how much do I now have saved in total as a result?

I think those cover the intended use cases and avoid entirely the complexity of communicating single- and multi-month statuses for a category at the same time, but obviously does so by limiting the amount of information being shown. That might be a philosophical difference, but I will mull on what multi-month support would need to look like.

[youngcw]

I think the progress bars really should be per month and not next to the categories, if we are going to add them. Also this currently doesn't have any indication of underfunded categories which will need added too.

[lelemm]

I like the idea, but I find it too distracting, not sure if the colors are too intense, or the colors doesn't fit to the overall theme. also, I agree with @youngcw.

I think the progress bars really should be per month and not next to the categories, if we are going to add them. Also this currently doesn't have any indication of underfunded categories which will need added too.

[tbuist]

Here's a version that moves the bars out of the category column and also deemphasizes them a little bit by just shrinking the height - thoughts on this?

Here's the same height in their original location

My thought is that the shorter the horizontal length of the bar, the quicker I'm able to glean what the state of the category is without parsing the actual amounts.

*Edit:
Multi-month bars gets busy really quickly.

[lelemm]

The smaller height makes it way better!
Try to use the color variables from the themes:

what if the current month shows the bar, but for other months you have to hover the month container?

[tbuist]

How do we feel about this? I'm just hooking into the same hover styling behavior that already exists on ExpenseCategoryMonth.

Alternatively, I can explore highlighting every category in the month when any part of the month component is hovered. I didn't see a clean way to do this with the way the components are structured, but I can mess around some more if we want to see that.

Separately, I've switched to using the report colors.

const ColorDefUnderBudgetRemaining = theme.reportsGreen; 
const ColorDefUnderBudgetSpent = theme.reportsGray; 
const ColorDefOverBudgetSpent = theme.reportsGray; 
const ColorDefOverBudgetOverSpent = theme.reportsRed;
const ColorDefGoalRemaining = theme.reportsLabel; 
const ColorDefGoalSaved = theme.reportsBlue; 
const ColorDefEmpty = ''; // No color for default

[tbuist]

One more to consider:

[diegofede]

This would be really nice to have! Thanks for the proposal, but I would prefer it how another tool (ynab) does it:

There is a container, so the bar doesn't really go edge to edge, this would also simplify the view for multiple months so the bars do not touch. The coloring is very simple too, only 3 colors: green, striked green, striked red. Where striked means spent.

This accounts for all the possibilities:

• Available to spend: green
• Spent within budget: striked green
• Overspent: striked red
• Goals: same rules as above but the left to reach the goal is grey (which is the color of the container).

This will simplify with less colors and people coming from the other tool will feel more at home.

[youngcw]

I'm not sure on the hover thing. If you do add it, I think the hover to show all categories option (your second option) makes the most sense. For starters you could just leave the progress bars on for all months that have goal data. Then we could see if its distracting to have non-current month progress bars.

I do appreciate the thin lines. Its not too obtrusive. I always thought the YNAB progress bars were way too big and made the budget table super cluttered. Back when I used YNAB I disabled the progress bars the second they got added to the app because they were annoying. The way you have the PR, I might actually try it. 🙂

It probably would be best to move the enable option into the "Category" menu. Same place as the "Toggle Hidden Categories" option.

Im not sold on having progress bars on categories without goals. I feel like that detracts from the usefulness of the categories with templates if all categories have a progress bar looking for attention.

[tbuist]

I'm not sure on the hover thing. If you do add it, I think the hover to show all categories option (your second option) makes the most sense. For starters you could just leave the progress bars on for all months that have goal data. Then we could see if its distracting to have non-current month progress bars.

Something like this? This made me realize that the non-goal progress bars are not of much use for non-current month visuals. They are most useful for communicating how much you have left to spend (although I suppose we still need to confirm whether this should be relative to the budgeted amount or the category balance - currently it's the budgeted amount), but 1) you can't change spending decisions for past months, and 2) spending for future months is always 0, even with scheduled transactions, so these would always be green under the current behavior.

Im not sold on having progress bars on categories without goals. I feel like that detracts from the usefulness of the categories with templates if all categories have a progress bar looking for attention.

Fewer colors helps.

It probably would be best to move the enable option into the "Category" menu. Same place as the "Toggle Hidden Categories" option.

Good idea, I'll move it here.

[lelemm]

I like how the other months are faded.
The thin bar looks better.

how does it look like if the progress bar is just under the balance column?

[tbuist]

Here's just under the balance column. If we went this route, do you think the bar ratios would need to reflect spending relative to the balance, as opposed to spending relative to budgeted?

I do think this is easier to read though.

[lelemm]

Here's just under the balance column. If we went this route, do you think the bar ratios would need to reflect spending relative to the balance, as opposed to spending relative to budgeted?

I do think this is easier to read though.

I like this version.

If its under the balance, I would prefer the progress bar to be the opposite. Right now you are showing from 100% to 0% (showing how much budgeted you still have based on spent).
If you put this current logic under budgeted, it gets more intuitive.

Could you update your branch with the current code so we can play with it too?

[tbuist]

Yep, just pushed everything. I moved the bar under the 'budgeted' column since that does make more sense with the current logic, like you mentioned. Let me know what you think.

[lelemm]

@tbuist , I played a little with your code, I liked it this way:

what do you think?

Check my changes here: https://github.com/tbuist/actual/compare/tbuist-category-ui-bars...lelemm:actual:bars?expand=1
I had to merge it with the current master because your branch was not working for me (some LRUCache errors)

[diegofederico1]

@tbuist , I played a little with your code, I liked it this way:

what do you think?

Check my changes here: https://github.com/tbuist/actual/compare/tbuist-category-ui-bars...lelemm:actual:bars?expand=1 I had to merge it with the current master because your branch was not working for me (some LRUCache errors)

I really like how it looks! But how would a category not yet budgeted look like? If it is the bar background color it would look the same as budgeted=spent, which is not too bad but could make it harder to spot non budgeted categories, which should be one of the advantages of having visual cues.

We can analyze the different scenarios:

Good

• Budgeted and no spending
• Budgeted and partially spent
• Budgeted and fully spent

Bad

• Budgeted and overspent
• No budget and no spending
• No budget and spending

I think all of this scenarios should be visually obvious via a quick glance. This should be possible to achieve by having the spent within budget as a shade of green, and the no spent part would be green (like the one you already used). The overspent part would be red. Background color would be gray (like the one you already used) which would represent no activity, no budget no spending. A combination of these would cover all scenarios.

Opinions on the color palette may vary, but I think we need to start with an overview of all scenarios first. Speaking of which, Goals:

Goals are more complicated because they are not really final on the current implementation but it would look something like this

Good
Budgeted equal or more than enough to reach the target for the month

Bad
Not budgeted enough to reach target for the month

Goals would need more thinking, but currently on a train and my stop is soon.

[deathblade666]

Firstly, this is looking great excellent job!!

But just a note and it maybe something that could be clarified in the docs. To me without initially making the connection that the progress bars are designed to visualize what's been budgeted and not the category balance throw me off. After looking at it more it made sense what it was showing but at first glance was a bit confusing.

If it was requested to be based on budgeted amount rather than balance then I admit I have not read the whole thread. Just wanted to provide a potentially more outside perspective.

[youngcw]

@tbuist , I played a little with your code, I liked it this way:

what do you think?

Check my changes here: https://github.com/tbuist/actual/compare/tbuist-category-ui-bars...lelemm:actual:bars?expand=1 I had to merge it with the current master because your branch was not working for me (some LRUCache errors)

would this have the same confusion where #goal is based off of balance instead of budgeted?

[lelemm]

would this have the same confusion where #goal is based off of balance instead of budgeted?

not sure if I understood what you mean.
you saying that this should be based off balance instead of budgeted?

[youngcw]

No matter which side you choose there will be templates that are based on the other column. So it seems like if you only use one column of space for the progress it will cause confusion. No matter which side is picked.

[lelemm]

No matter which side you choose there will be templates that are based on the other column. So it seems like if you only use one column of space for the progress it will cause confusion. No matter which side is picked.

what if we split the progress bar into two? do you think its still confusing? the current implementation of @tbuist it tries to show goals and budgeted all at the same progress bar.
we could have a simple budgeted vs spent under budgeted value and a goal progress bar under balance

(fake code here)

[deathblade666]

No matter which side you choose there will be templates that are based on the other column. So it seems like if you only use one column of space for the progress it will cause confusion. No matter which side is picked.

what if we split the progress bar into two? do you think its still confusing? the current implementation of @tbuist it tries to show goals and budgeted all at the same progress bar. we could have a simple budgeted vs spent under budgeted value and a goal progress bar under balance

(fake code here)

FWIW, to me, this approach seems less confusing overall. Just a thought on adding progress bars for goals, would it make more sense to move them to the existing goal tooltip?

[tbuist]

No matter which side you choose there will be templates that are based on the other column. So it seems like if you only use one column of space for the progress it will cause confusion. No matter which side is picked.

what if we split the progress bar into two? do you think its still confusing? the current implementation of @tbuist it tries to show goals and budgeted all at the same progress bar. we could have a simple budgeted vs spent under budgeted value and a goal progress bar under balance

My thought would be that in both cases (budgeted vs. spent, as well as goal progress), the budgeted amount is a component of the thing we're trying to communicate. That is, in both cases, I am interested in the budgeted amount for how much is remaining or for the impact it's having on the goal. I'm not sure I like multiple bars in one line.

@tbuist , I played a little with your code, I liked it this way:

I do like the narrowed width bars that you have here.