Eric PoulinKeymasterDecember 10, 2008 at 9:03 pmPost count: 377
I received an email from a CalendarBudget user who deleted a category from 1 account and expected it to be deleted from their other accounts.
I designed CalendarBudget with the ability to have each account have its own categories. I know this is a “could be” useful feature, but it also has drawbacks, such as you can’t report across accounts on category usage, and you have to maintain categories in each account if you want them in synch.
What do you expect CalendarBudget to do regarding categories across multiple accounts?
ObelixParticipantDecember 12, 2008 at 4:29 amPost count: 48
I expected the categories to carry over when I first got started. I was disappointed that I would have to start over with setting them up. I ended up not even using the categories in my Money market account. They just sit there hopelessly waiting for the day they get something assigned to them. I just keep that account to keep track of the money it holds.. that money isn’t really allocated monthly in CB (altho it is in my personal budget and there’s another feature request for you when I get a chance to write it up). I think you should consider at least asking the user when they add a new account if they would like to carry over the category settings from one they already have. You could then let them radio button one of their current accounts defaulting to the first one.
Eric PoulinKeymasterDecember 12, 2008 at 7:03 amPost count: 377
Does it make more sense to copy categories from one of your accounts, or just have all your categories common across accounts. Having common categories would certainly simplify aggregate reporting. Is the flexibility of having different categories in each account necessary?
ObelixParticipantDecember 12, 2008 at 3:16 pmPost count: 48
Hmm thats a good question. If you made them common across all accounts, would allocations made in alternate accounts show up while viewing a different account? Like if I’m looking at checking and I had allocated $100 towards the mortgage from my moneymarket account, does that allocation show up in the totals shown on my checking page? Doing that would probably be best, but will make your category space much larger as all accounts will have to share the space if you have special categories that are specific to an account.
And here’s another pie in the sky suggestion if you go this route. You have category types – income,expenses(savings *nudgenudge*). make them collapsable in the category area. Allow the user to add custom category types and move a category between types if they want to. This allows user to by default have income and expenses, but by preference they could move some of their expenses to a different category type. property taxes that only get paid once a year. Self employment taxes that get paid 4 times a year. Business expenses vs personal expenses(for the self employed whose personal and business finances are more likely to be intertwined).
All these then being common and available on every account page, you could place the categories for a MoneyMarket account in its own category type(by preference, not enforced). This structure (assuming you can code it) should provide a highly flexible, easy to get started with, complete(with the savings category type) way for people to keep up with their accounts, cashflow, and specific savings goals.
Erm.. you didn’t have anything else to work on did you?
Eric PoulinKeymasterDecember 12, 2008 at 3:38 pmPost count: 377
You bring up a good point – that being – if categories are shared across accounts, they *should* also share the amount and contributions to it. In fact, this is the best way to budget. You budget your money based on your income, not based on the number of accounts you have. Our goal is more to encourage good personal finance, less to have a flexible tool.
The only visual problem is… now we have categories that will say you have, say, $100 spent, but its not clear where its been spent if that spending is not in the current account.
The planned aggregate account view will take care of that, but viewing a specific account will have its drawbacks.
We had thought if having the category side bar be expandable to the right, show more details about your plan vs actual spending. We could simply have 1 column for plan, and x columns for actual, 1 for each account and show its contribution to that category’s activity.
This will be a bit of a mess to convert all existing users accounts to – but I think the net results will be positive.
ObelixParticipantDecember 12, 2008 at 5:56 pmPost count: 48
I’m not convinced that showing the multi columns within the confines of the current page layout are necessary. maybe others have different experiences, but I pay bills out of one account. But,on the other hand, these are categories we are talking about here, not always specific bills so maybe I can see paying His phone bill out of His checking account and Her phone bill out of Her account. Both fall under the Phone category.
What about just changing the way you can view that information. Instead of changing the entire page layout to enable the columns(which is a huge waste of space if you have to allocate area to empty or non-participating accounts), why not have a hover popup when you mouse over each category that shows quick summary info on that category. The popup should appear just under the category so the checkbox activation is still enabled on clicking. As you moved down the page, once you leave the actual category area (not the popup) that popup disappears. If you moved over another category, popup that categories quick summary.
This would preserve your current layout and functions and simply add a popup feature (which could be used for lots of other things as well).
If you really wanted to provide an account breakdown, do it like the charts where you pop up a window to show the breakdowns for the month. You could also include a link in that window to download it as a tab-delimited text file or just straight text.
The quick summary popup could include all accounts that contributed to that category for the month, the current amount, the budgeted amount, maybe even a tight/small review of the past couple months for this category. Size/space used isn’t as important since its going away anyways as soon as the mouse leaves the category label area.
Eric PoulinKeymasterDecember 12, 2008 at 6:17 pmPost count: 377
Sorry, I think I wasn’t clear in my last post. The idea of the multi-column sidebar is only as an expandable (expanding to the right) option. You may expand it temporarily while reviewing budget spending, it would likely hover over the calendar, not shrink it. The normal view would be pretty much as it is today, with the category spending showing spending for your entire finances, not just the current account.
In fact, it just dawned on me… to make this more visually clear, the Account Tabs would start AFTER the category side bar – so the category side bar would not be specific to any account, but a global shared entity.
AnonymousGuestDecember 12, 2008 at 8:02 pmPost count: 42
I agree with the new direction on where this going but lets back track a bit and look at the fundmentals of what CalendarBudget is being designed for. I believe the purpose of CalendarBudget is to help users maximize their income by closely tracking and reducing expenditure.
Now the basics of budgetting is Income – Expense but it becomes very complex when you look at how individuals deal with their budgetting. Some maintain multiple accounts, others single accounts, some use multiple accounts to pay multiple bills other specific account for specific bills, etc. None of these are wrong it all has to do with how well you manage the options you pick.
This brings us to having an application that can cater to needs of the various users at the same time not compromising its simplicity of use and accountability (in terms of reporting).
My idea is to have 1 instance for categories since most people maintain one budget regardless of multiple accounts. Now have a main category for income and multiple sub-categories created by users for their sources of income. All income regardless of which account it goes to should be captured in the income pool (already in place). Also based on user’s information provided, income should be calculated in advance for the current month.
In Envelope Budgetting categories are assigned amounts to correspond to them. The total income calculated for the month should to distributed for the various categories. Now one will as so how do I account for which account a transaction took place in? The answer will be during the entry of an transactionm, a new option is included to show the source of payment by account and the destination by category. This will deduct transactions from funds assigned to the category and also account for where the funds came from.
It will allow reporting from the accounts and at the same time reporting based on categories. It can also facilitate the missing feature of transferring funds between accounts that some people do on a regular basis. At the moment you have to create it as an Unassigned transaction which I do not believe will give an accurate report and requires inputing a transfer transaction twice.
I hope this contribution is helpful.
ObelixParticipantDecember 12, 2008 at 9:04 pmPost count: 48
Do I know you? :D
So what you are proposing is that ALL projected income for a month should be allocated to some category? Not sure I like that. It’s not as flexible as the current free form assignment.
I do like the extra entry option to assign the entry to a particular account even if you aren’t on that account page. That would let new entries be added from anywhere without having to switch over. You could possibly show all entries on all account pages just labeling them with $0 or something to help remind users they are there… of course that will start to get messy if the user has a lot of transactions.
Eric PoulinKeymasterDecember 12, 2008 at 9:33 pmPost count: 377
At the moment any category can be flagged an typically an “income” or “expense” category. This distinction is used to group the categories, and in fact reverse the count on the category.
For Income categories, the “budget” is a target you hope to reach.
For Expense categories, the “budget” is the maximum you should spend.
Probably we’ll keep tis distinction. We’ve discussed having sub-categories in the past with roll-up totals. We’ll probably do that eventually, but not any time soon, simply because there are other higher priority features.
Regarding transfers – having a single set of categories across all of your accounts nicely facilitates the target account entry. I’m liking the single instance of categories more and more. Perhaps, I’ll do that now in combination with transfers (before releasing transfers) since it will make things much simpler. Unfortunately the next system upgrade will be pushed until next week, but its for the best I think. I’ve discussed this with the other half of the design team and I’m going to go ahead with making categories a single global entity.
Also, funny enough… the current entry dialog DOES have an account field allowing you to create/move entries to other accounts. However, I have *just* removed it as part of the transfer feature. The account field is just clutter on the entry dialog, it never gets used. Behaviorally, people won’t create a transaction unless they are “in” that account and thus seeing the surrounding context. I originally thought it was a good idea as mentioned by Obelix, however, noone is using it, including me – its just another field to have to tab through.
Eric PoulinKeymasterDecember 19, 2008 at 4:28 pmPost count: 377
Changing to a single set of global accounts is done, along with some associated performance improvements.
However, this code change is coupled with the transfer feature, which is taking a little longer than expected. It will likely roll over to next week to ensure its well tested before we release it.
Eric PoulinKeymasterDecember 29, 2008 at 4:07 pmPost count: 377
This has been completed and is now available.
- You must be logged in to reply to this topic.