There is a personal finance website, Buxfer.
It has an IOU component. There is a basic implementation of what you require. There are multiple people, sharing and expense. If we need to split it unevenly, it provides a simple UI with text boxes to provide the different amounts.
It starts with equal split and as you make changes the yet untouched fields are automatically updated.
Notice that when you make a manual edit in any field, it will not programatically alter its contents.
If you edit all and if it does not total up to amount, the system does not allow you to save. I liked some aspect of this UI.
- It allows you to dynamically add a sharer.
- It makes sure the amount always totals to the transaction amount.
- System only updates the fields which are not yet touched by the user. It does not override user's inputs.
- You can further enhance by giving a different border or something to fields user has explicitly edited.
- At all times, it provides users options to reset by an equal split.
You can probably augment it with a graph which is reflected as soon as user makes changes on the fields. You can have actual values at the base of each bar and give gradients based on percentage of your total budget consumed by each bar. You could probably add overlay on each bar showing the percentage.
It is essential part of your algorithm how to handle the balancing, but I would be weary of touching any amounts user has explicitly entered. This leaves you with less control. While users are manipulating the graphs, you could turn individual bars red, or whole graph red if you perceive system can't make decisions based on user state.
Basically, the math part is going to be complicated. When you are trying to adjust some figure, you'd probably consider historical values, trending values, etc. User's reaction of you making decisions for him also makes a lot of difference.
Buxfer goes a neutral way, it equally splits remaining amount, and if it can not it disables the save/submit action and tells user that things don't add up. If you do not want that route, you'd need more information on user behavior based on profiles, what and how they use the system, and still you run a risk of annoying a bunch who would not like unequal splits patronizingly made by system for them.
There is a issue of how dynamically adding a category when some calculations are taking place. What effect should it have on the math till now? I'd suggest equal splits only if user has not touched any amounts, or equal splits between amounts which are not yet touched by the user.
In any case, there remains a choice between being heavy handed and restricting user operations heavily, or being liberal and force user to correct wrong inputs before he saves. This choice can be made considering the context of your application, the kind of data being budgeted, the amount of meta information the system has.
I'd also suggest considering the operation time. A power user will expect a way of inputting data which does not involve graph manipulation.
Also, I know your explicit requirement said about no jumps, but that is going to result in having amounts like 63, 41, 39 etc. Call it a personal pet peeve but I can't stand such amounts on sliders, I try to round it up to nearest multiple of 5, 2 or 10, based on the kind of data I am dealing with. This is more time consuming and annoying. (Discount this as it is a personal opinion and not backed by any search). When I am trying to put budgets on something, I am more inclined towards ballparks than specifics like mentioned above.
Let me know if I need to add something more.