B-Tax entry point

[talumbau]

One question that came up with the new B-Tax capability: how should a user get to the page? If they go to ospc.org -> Apps, this brings up ospc.org/taxbrain which is just the microsim input page. One option we discussed was ospc.org -> Apps brings up a window and you must choose "Business Tax" or "Personal Tax" and then you would either go to ospc.org/taxbrain/btax (for the former) or ospc.org/taxbrain/taxcalc (for the latter). @MattHJensen what is the best way to do this? Also, we have had discussions that "TaxBrain" is a term/brand that would apply to all the models that are available, not just the microsim (and dynamic models connected to the microsim). Does that align with your idea of the branding of the webapp(s)?

[MattHJensen]

I have been thinking ospc.org-> Apps would take you to ospc.org/apps which would then list TaxBrain as one app and Cost of Capital Calculator (or some other name) as the second app. We might also list the Vizualization Gallery as an app so we have everything in one place.

One option we discussed was ospc.org -> Apps brings up a window and you must choose "Business Tax" or "Personal Tax" and then you would either go to ospc.org/taxbrain/btax (for the former) or ospc.org/taxbrain/taxcalc (for the latter).

Could this become confusing if we integrate personal taxes into the cost of capital calculator?

Also, we have had discussions that "TaxBrain" is a term/brand that would apply to all the models that are available, not just the microsim (and dynamic models connected to the microsim)

My thinking has been that TaxBrain would refer to the big "unified" app that is primarily focussed on revenue and distributional analyses, where all of the models are connected.

Under that scheme, the cost of capital calculator would start off as a separate app and then be merged with TaxBrain only after it can team up with Tax-Calculator and OG-USA to provide static revenue and distributional analyses and dynamic revenue analyses. (I could even imagine incorporating B-Tax with our PE dynamic page and possibly our ME dynamic page later on.)

I am not wed to this scheme though, and would be interested to hear more about the advantages of applying TaxBrain branding to everything. That idea is new to me, and I will keep thinking through it myself as well.

[talumbau]

I have been thinking ospc.org-> Apps would take you to ospc.org/apps which would then list TaxBrain as one app and Cost of Capital Calculator (or some other name) as the second app. We might also list the Vizualization Gallery as an app so we have everything in one place.

This is definitely possible, it's just that we would have to design the landing page to select which app one wants to go to, and I was trying to cut that step out, since it seems like a significant step (or at least, one that we would want to get right, but one I don't have a good instinct for personally).

Could this become confusing if we integrate personal taxes into the cost of capital calculator?

Yes I see your point about this.

My thinking has been that TaxBrain would refer to the big "unified" app that is primarily focussed on revenue and distributional analyses, where all of the models are connected.

Under that scheme, the cost of capital calculator would start off as a separate app and then be merged with TaxBrain only after it can team up with Tax-Calculator and OG-USA to provide static revenue and distributional analyses and dynamic revenue analyses. (I could even imagine incorporating B-Tax with our PE dynamic page and possibly our ME dynamic page later on.)

The advantage of keeping the "TaxBrain" branding on the whole thing, with multiple apps inside, is that we won't have to come up with a good name and images for the BTax app. If TaxBrain is for only the unified/integrated set of models (which does make sense to me, by the way), then we have to figure out how to brand BTax (which really to me just means a name and some reasonable images similar to our current TaxBrain PNG images). The image design part seems hardest and was something I was trying to avoid.

[MattHJensen]

This is definitely possible, it's just that we would have to design the landing page to select which app one wants to go to, and I was trying to cut that step out, since it seems like a significant step (or at least, one that we would want to get right, but one I don't have a good instinct for personally).

What do you think of starting off w/ a landing page that looks like the TaxBrain dynamic model landing page?

The advantage of keeping the "TaxBrain" branding on the whole thing, with multiple apps inside, is that we won't have to come up with a good name and images for the BTax app. If TaxBrain is for only the unified/integrated set of models (which does make sense to me, by the way), then we have to figure out how to brand BTax (which really to me just means a name and some reasonable images similar to our current TaxBrain PNG images). The image design part seems hardest and was something I was trying to avoid.

For the name, what about something simple like "Cost of Capital Calculator"? Then we'd have TaxBrain, Cost of Capital Calculator, and Visualization Gallery in the apps page?

The image design part seems hardest and was something I was trying to avoid.

Yes, I agree, but I think there is someone at AEI who could do a good job once we settle on a name; in the meantime, we could just use some standard font. It would look crude until we have the nicer image, but we can call it an alpha.

cc @jdebacker, @bfgard

[jdebacker]

My thinking has been that TaxBrain would refer to the big "unified" app that is primarily focussed on revenue and distributional analyses, where all of the models are connected.

I can see this. I had thought differently: TaxBrain as the interface for a number of different models that may interact or not, but all deal with taxes. At some point, we'll have linkages from Tax-Calc to/from B-Tax and from B-Tax static to several B-Tax dynamic options (including OG-USA). So does B-Tax (or the "Cost of Capital Calculator") reside in a separate app until these integrations, and then get pulled over? Does it move when it takes individual income tax parameters (say from the current Tax Brain fields)? Or only when it can provide inputs to revenue/distributional analysis?

For the name, what about something simple like "Cost of Capital Calculator"? Then we'd have TaxBrain, Cost of Capital Calculator, and Visualization Gallery in the apps page?

This seems ok w/ me. Although some labeling (e.g. "Explore individual income taxes", "Explore taxes on capital", "Visualize the tax code") to make the content more obvious could help. Depending on the user, I can imaging "cost of capital" being too opaque of a term. Likewise - "visualize" what? It's not clear. Maybe have separate buttons for visualize taxes, environmental policy, etc. as other areas are added. Or, if TaxBrain is the umbrella for tax models/visuals then perhaps we have "EnviroBrain" (or whatever - this is a bad name, but you get the point) to be the web app to interact with models/visuals related to environmental policy... and so on for other policy areas.

[MattHJensen]

This seems ok w/ me. Although some labeling (e.g. "Explore individual income taxes", "Explore taxes on capital", "Visualize the tax code") to make the content more obvious could help.

Definitely agree. The dynamic landing page layout will allow this. We just need TaxBrain and cost of capital calculator labels for now. What do you think of this:

TaxBrain: Explore the effect of individual income and payroll tax reforms on budgetary, distributional, and economic outcomes using static and dynamic economic models.

Cost of Capital Calculator: Explore the effect of business tax reforms on investment incentives across assets, entity types, and industries.

[jdebacker]

Sounds good to me.

[MattHJensen]

Does it move when it takes individual income tax parameters (say from the current Tax Brain fields)? Or only when it can provide inputs to revenue/distributional analysis?

I think we would want to integrate the cost of capital calculator with TaxBrain as soon as it can feed into some of the outputs currently presented by TaxBrain, either the static revenue and distributional tables or the economic outputs produced by OG-USA.

• To feed into the static revenue and distributional tables, I believe B-Tax will need to be linked in both directions to Tax-Calculator: i.e., it would need to accept TC params as inputs and it would need to be able to distribute B-Tax outputs to the TC microdata.
• To feed into OG-USA, it can either feed into the TC microdata, or it can feed directly into OG-USA.

Based on an earlier email from @jdebacker, I expect what will happen first is that B-Tax will feed into OG-USA.

At that point, I think we could bring B-Tax under the TaxBrain branding as the business tax side of TaxBrain.

Here's why:

Whether you start with B-Tax or TaxCalc, you will eventually get to OG-USA. Once at OG-USA, we can give the user the option to fill out the side that he did not start with.

For example, I start with B-Tax, get the cost of capital outputs, click link to dynamic simulation, get to the OG-USA page, and am offered an opportunity to also make reforms to the individual and payroll tax before running OG-USA. Alternatively, I start with individual and payroll taxes, get the static and distributional tables, link to the dynamic simulation, go to OG-USA, and am offered an opportunity to make reforms to business taxes before running OG-USA.

This would be an OK place to be while we wait for B-Tax and TC bidirectional integration.

That said, it isn't optimal because we will be doing quite a bit of front-end web development and user interface work that we will end up deleting once we have the B-Tax TC bidirectional integration and can just merge the B-Tax inputs into the first step of TaxBrain.

My sense is we should just wait and see how far away B-Tax/TC bidirectional integration is once we get B-Tax/OG-USA integration. If we are really far away from B-Tax/TC integration, then we can go ahead and bite the bullet and do the UI work described above. If we are pretty close to B-Tax/TC integration, then we can wait for it and then do a whole sale merge.

[jdebacker]

What I'd like to see even before B-Tax feeding the current TaxBrain outputs (or OG-USA) is to see the TaxBrain inputs feed into B-Tax.

B-Tax needs some ability for the user to modify parameters like rates on ordinary income, interest, dividends, cap gains. We could add these fields to the B-Tax UI at low cost, but I'm afraid they would be difficult for the user to understand since you are putting in just a single rate to represent the "marginal investor".

Ideally, we have the user enter individual income tax parameters in an interface like TaxBrain and be able to use those inputs along with the inputs we are currently building into the B-Tax UI to evaluate business income taxes. The tax parameters representing the "marginal investor" would be imputed from the micorsim output (e.g. some weighted avg of the rates on different filers based on capital income).

I am hoping this come sooner than later. If/when it does come, what makes sense as the B-Tax entry point? Does it change where we would put it now (assuming we'd want this direction of integration relatively soon)?

[MattHJensen]

What I'd like to see even before B-Tax feeding the current TaxBrain outputs (or OG-USA) is to see the TaxBrain inputs feed into B-Tax.

Definitely makes sense.

Which parameters from the TaxBrain input page do you think would be relevant?

[jdebacker]

Which parameters from the TaxBrain input page do you think would be relevant?

Since this is moving more away from the UI question, I'm answering this in a new issue here.

But the answer to that question might affect how we do the UI.

[MattHJensen]

What I'd like to see even before B-Tax feeding the current TaxBrain outputs (or OG-USA) is to see the TaxBrain inputs feed into B-Tax.

In light of the discussion PSLmodels/Cost-of-Capital-Calculator#43, what do you think about this:

1. Some subset of parameters from TC are displayed on the Cost of Capital Calculator (CCC) input page. (@jdebacker will provide this list)
2. There is unfolding/expansion option on the CCC input page that allows the CCC user to see all of the TC params that are currently available on TB.
3. On the TB static results page, there is a "Link to Cost of Capital Calculator" button right next to the "Link to Dynamic Simulations".

Feedback from @mistakevin, @talumbau, and others on front end feasibility might be helpful, especially for # 2.

[jdebacker]

I like this solution.

[jdebacker]

Re which TaxBrain inputs to include, I would suggest just the rates (not bracket ranges) under the "Regular Taxes" section. This should be simple enough and we'll then offer the ability to expand to all Tax Brain inputs.

cc @MattHJensen

[MattHJensen]

Ok. We'll want to grab the AMT Rates (both OI and CG/DIV) as well, since those eat up pretty much anything that happens to the regular taxes section -- especially the CG/DIV rates.

[jdebacker]

Ah, yes @MattHJensen.

Re the MTRs that will be returned from the Tax-Calc run to enter into the user defined parameter dictionary for B-Tax, we should be able to leverage what you all built for the macro elasticity model.

[talumbau]

we have addressed the overall issue here, which is that the Cost of Capital Calculator is a separate product from TaxBrain. There is still the underlying technical discussion of how taxcalc, btax, and ogusa all interact with each other through the various web application. For btax <-> taxcalc, the relevant discussion is here:

PSLmodels/Cost-of-Capital-Calculator#43