We’re not currently including mortgage insurance, no. You could approximate it by increasing the mortgage rate, but the tax treatment of mortgage insurance payments may be different and so that may not be accurate. Perhaps this is something we can add in the next iteration of the calculator.
The interaction between down payment rate and mortgage insurance rate also reveals a limitation of our user interface: On the one hand, it’s nice to have all the variables decoupled so that you can set and explore them independently. On the other hand, many of the variables are not independent. If you change one variable, you may need to change other variables to maintain a realistic scenario.
Having the mortgage insurance rate tightly coupled to the down payment would probably be too limiting, but maybe there’s a still a way to better identify when certain variables (or combination of variables) are unrealistic.
Maybe instead of just having reasonable defaults, you could include reasonable ranges through a background gradient on each graph (darker for more common, lighter for less common)? With that, you could manipulate the reasonable ranges through interactions between graphs, while still allowing people to set the actual number anywhere they pleased.
Definitely. We actually designed something like that, but due to time constraints weren’t able to ship it (yet). One complication is that a reasonable range for a given variable can depend on other variables. But hopefully we’ll figure it out.
I'm sure you've seen TangleJS by Bret Victor. Its performance wasn't quite good enough for the way I wanted to use it, but it looks like that level of meta-interactivity is what you're going for.
"The interaction between down payment rate and mortgage insurance rate also reveals a limitation of our user interface: On the one hand, it’s nice to have all the variables decoupled so that you can set and explore them independently. On the other hand, many of the variables are not independent. If you change one variable, you may need to change other variables to maintain a realistic scenario."
Well I'm not sure I'd call this a 'limitation' of your UI. This is actually a very common issue when designing user interfaces for models (I have been doing this for a living for almost 15 years). There is a continual tradeoff between the positives of the software ensuring internally consistent, and realistic, values - and allowing the user flexibility for edge case exploration. And then there are issues like discoverability, speed of use, technical limitations, etc. - as always.
One of my favorite mental toys in this area is: devise a way for a user to assign a fixed amount (call it a 'budget') to several categories. For a simple example, consider a budget of $100 over 5 expense categories. But it should also work for allocating a road maintenance budget across 25 districts, or for assigning a weighting to the importance of policy objectives (ecology, health, economic growth for example).
In the vast majority of cases, after several meetings about this, clients say 'fuck it, let them copy/paste their own values from Excel' (at this point I come in and broker a truce between the warring factions of several solutions and implement a meet-everybody-halfway solution :) ) It's one of those 'how hard can it be?' <2 weeks later> 'oops yeah pretty hard' things.
devise a way for a user to assign a fixed amount to several categories
A slider for each category. When one slider is moved up by 1% of the total the others automatically move down in proportion to their current value to collectively lose 1% of the total.
Yes, this is the first instinct. But moving all of the others down/up is in the majority of cases not what you want. Imagine you have 100 to spread out over 4 categories. Let's say you start with setting them all to 25. You set the first to 33, then you want to set the second to a desired values except oops, the first one is now no longer 33. Basically in this scenario you have to way to set them all to a precise value without trial and error until you're close enough to what you want.
This does work for the use case where you only want to set an initial distribution, but quite often you want to play with trading one option against another afterwards, e.g. spend more on housing and less on holidays, but not less on food or car payments. Basically when developing various scenarios you set an initial distribution (the baseline) and then make scenarios, variations on that baseline. (I imagine it's quite similar for people doing serious exercises with the tool in the OP, I've also written tools to assess investment options, that is similar too).
(The above is a simple example of a personal budget which I always use to illustrate the point, my actual use case is usually something like 'spend more on nature protection and less on road maintenance, but don't change expenditure on social security'. It's easy to see how various political persuasions have some sliders they don't want to budge on, some they want to minimize, and others to maximize).
Usually you need some form of 'reserve' account in your UI; i.e., you're 'spending' from a certain total, and as you increase/decrease some items, that amount is taken from / added back to the reserve. But then how do you guarantee people always spend everything (in some cases that is needed) without introducing modality (i.e., a dialog that says 'you need to spend everything' when you click 'next' or whatever). And sometimes you need a way to move units between accounts, without using the reserve as an intermediate store; plus you usually need a way to move exact amounts, which is hard to do with sliders.
Another approach is something where you stick with the sliders you proposed, and add functionality to 'fix' certain ones, and optionally a way to indicate how much to increase/decrease the others. E.g., proportional to their current values, or distribute the amount equally, or something else, ... The problem with this approach is that it is natural for nerds, but almost instantly becomes unwieldy for 'normal' users. And in that case, the 'fuck it, let's do it in Excel' is better.
If you're interested in this sort of things, I'd love to hear your thoughts or see mockups on other ways you think this could be done. I have talked about this numerous times but usually not with people who know something about UX or even care, beyond their project in front of them.
The interaction between down payment rate and mortgage insurance rate also reveals a limitation of our user interface: On the one hand, it’s nice to have all the variables decoupled so that you can set and explore them independently. On the other hand, many of the variables are not independent. If you change one variable, you may need to change other variables to maintain a realistic scenario.
Having the mortgage insurance rate tightly coupled to the down payment would probably be too limiting, but maybe there’s a still a way to better identify when certain variables (or combination of variables) are unrealistic.