Output format

[feenberg]

I would also like to bring up the output format. There is a surplus of white space, resulting a need for much additional scrolling viewing online and much difficulty getting a usable printout? In Chrome I only get to "Personal Exemptions" in the printout, even in landscape mode with "Print to fit" selected. Is there some way to get more?

Similar concerns are evident if I copy and paste into a word document. (Actually, it nearly works in landscape if one chooses the right paste mode). Is this the browsers fault or can we do something about it? I easily get 15 columns in portrait mode in my work for Marty, by simply specifying <xmp> for the tables and printing cells in 8 character widths.

Perhaps we will use PDF for printable output? We still need to get the output on a landscape 8.5x11 page, which will mean drastically reducing the whitespace.

The vertical whitespace is also excessive - only a third of the vertical space is allowed for text, but a half is more than enough.

The closest I could get to a printable table was to copy to Excel and then print to fit. That looked pretty good (vertical and horizontal whitespace are both correct and the font is small but readable). Column headings were truncated. but We could fix that if headings like "Taxable Income" were given 2 lines and "Billions of Dollars" shortened to "Billions".

I would like to see the run number explicit in the printout, so that each printout can serve as an advertisement for TaxBrain, with an easy way to access the online simulation. Perhaps something like this below the table:

Source: http://www.ospc.org/taxbrain/374/

A bit of "branding".

dan 617-863-0343

[MattHJensen]

[NOTE: the inclusion of <xmp> in the text seems to have confused github. I wrapped it in backticks ( ` ) and the formatting cleaned itself up. cc @feenberg]

[zrisher]

I think a couple things are missing here that would really improve the situation for this use case: both the PDF export and Print format buttons are broken. We have issues open for each of those (#26, #45), and I think they would be the best places to optimize printability and page-fit.

That said, there is a ton of padding on this page, possibly more than is useful given the amount of data we have to display.

Here's the current padding of 15px:

Here it is with the bootstrap default of 8px:

And here it is with 5px:

Personally I believe somewhere closer to 5-8 px would be a good choice for this page.

[feenberg]

On Mon, 14 Sep 2015, zrisher wrote:

I think a couple things are missing here that would really improve the situation for this use case: both the PDF export and Print format buttons are broken. We have issues open for each of those (#26, #45), and I think they would be the best places to optimize printability and page-fit.

That said, there is a ton of padding on this page, possibly more than is useful given the amount of data we have to display.

Here's the current padding of 15px:

image

Here it is with the bootstrap default of 8px: image

And here it is with 5px: image

Personally I believe somewhere closer to 5-8 px would be a good choice for this page.

Even less than 5 px would be fine with me.

I notice that the cell values are still low-contrast, while the labels are high-contrast. I don't understand the purpose for that distinction. Everything should be easily read.

I also notice that the horizontal spacing is still excessive, and prevents the tables from being printed usefully. On my monitor, the tables are cut off at the 5th column, hardly a third through the table.

This isn't a magazine advertisement, where content is optional and impression is all that matters. The content is the point, and white space is only useful to the extent that it makes the contest easier to follow.

dan

— Reply to this email directly or view it on GitHub.[AHvQVcJJbf7mdrtMwzHLMROV3scQdqzeks5ox1EXgaJpZM4F4g0v.gif]

[MattHJensen]

Not sure how helpful these comments are going to be because I'm just going to agree with everything that has been said, but here goes...

I notice that the cell values are still low-contrast, while the labels are high-contrast. I don't understand the purpose for that distinction. Everything should be easily read.

Agreed.

I also notice that the horizontal spacing is still excessive, and prevents the tables from being printed usefully. On my monitor, the tables are cut off at the 5th column, hardly a third through the table.

Agreed.

This isn't a magazine advertisement, where content is optional and impression is all that matters. The content is the point, and white space is only useful to the extent that it makes the contest easier to follow.

Agreed. More and more I care less and less about 'impression' on this output page.

Similar concerns are evident if I copy and paste into a word document. (Actually, it nearly works in landscape if one chooses the right paste mode). Is this the browsers fault or can we do something about it? I easily get 15 columns in portrait mode in my work for Marty, by simply specifying <xmp> for the tables and printing cells in 8 character widths.

Agreed. It would be really nice to be able to copy selected tables from the webapp to to a separate document.

I would like to see the run number explicit in the printout, so that each printout can serve as an advertisement for TaxBrain, with an easy way to access the online simulation. Perhaps something like this below the table: Source: http://www.ospc.org/taxbrain/374/

Agreed.

---

All that said, I also agree with @zrisher's sentiment that the most important place to prioritize page fit is in the pdf and print views.

I think a couple things are missing here that would really improve the situation for this use case: both the PDF export and Print format buttons are broken. We have issues open for each of those (#26, #45), and I think they would be the best places to optimize printability and page-fit.

---

@feenberg, do you have examples of these classes tables that you have made in the past for web display?

[MattHJensen]

@feenberg, @Amy-Xu, and I were discussing our output tables yesterday. We realized that our output can be boiled down to three types of tables with several different combinatorial dimensions for each type; that realization inspired some thoughts on how to make our output more digestible.

First, the three types of tables are

1. Revenue table.
2. Diagnostic table.
3. Difference table.

Revenue Table

The revenue table should always be displayed by year, as is.

The only change would be to add two rows, one with payroll tax liabilities change and one with total liabilities change (sum payroll and individual income tax). The current 'total revenue change' we should rename 'individual income tax liabilities change'.

Diagnostic Tables

Many different configurations of the Diagnostic Tables are useful and interesting. The primary dimensions on which Diganostic Tables can be configured are:

1. Plan Y or Plan X or Difference
2. Aggregate or Average by return
3. Year
4. Expanded Income classifier or AGI classifier
5. Bins or Deciles

@feenberg and I hope we can make all of the potential configurations available to the user, while not needing to throw them all on one page, by providing radio buttons or similar (dropdown for year) and updating the table displayed to the user based on which radio buttons are selected.

It would also be nice if there were a way to "hide" or "collapse" columns, and if we could decide which columns are hidden by default and the user could also choose to hide or unhide columns. @zrisher, is this easy to do? I'm not sure what what happen to the column labels if you hide a column (how would you know it is there and get it back afterwards?).

We also need to add a few columns to the diagnostic tables, namely: total credits (refundable + non-refundable), misc. surtax (where we will put the benefit cap surtax), payroll tax liability, and total liability. We can delete the 'tax before refundable credit' column and rename the existing 'Revenue' column to individual income tax liabilities.

The columns that should be hidden by default (if we decide hiding makes sense) are "standard deduction filers", "AMTI", "non-refundable credits", "refundable credits", "payroll tax liabilities", and "individual income tax liabilities". I suppose we could also have a rule that "misc. surtax" is hidden if it is zeroes.

Difference tables

It would also be nice if we could provide the user the ability to select a configuration of the difference table on the fly. The combinatorial dimensions that matter for the difference table are:

1. Years
2. Expanded Income classifier or AGI classifier
3. Bins or Deciles
4. Payroll tax or individual income tax or combined taxes

Summary

If these changes were implemented, I think our output page would be much more manageable, with only 3 tables needed rather than the many and expanding number of tables we currently have.

Additionally, we could move towards csv and pdf output on a per table basis, rather than trying to output all possible tables at once. This will become even more important if we add more combinatorial dimensions or entirely new classes of tables/charts in the future. Users can always go back to the output URL and get other tables if they'd like.

@Amy-Xu, do you think the best place to start is making sure all of the combinations of these tables are available through the table generator interface we have available in taxcalc/dropq via some nice and relatively consistent API? Then @zrisher can give feedback on the approach generally and on UI and webapp implementation after he finishes off the params validation.

[zrisher]

Re: hiding table columns - yes I think this is pretty feasible using display: none and jquery's .hide() function.

Re: approach - yes please design the new tables as an extension of the current table interface if possible, or if it's in need of full rewriting let's design it to be somewhat forward-thinking. Also, napkin sketches of the new tables and where the various toggling buttons go on the page would help with implementation and discussion.

[MattHJensen]

@zrisher, here you go. I envision these being placed over the tables, and we'd set a default selection. What do you think.

[Amy-Xu]

It seems to me this issue needs a bit more thinking on the webapp than tax-calculator itself, even though the table-generators do need expansion on functionality.

Purely from the perspective of generating these tables, we've already had most things we need from Tax-Calculator. If I understand @MattHJensen's sketch correctly, there are four independent groups of radio buttons and each group has the options listed in that column. In utils,py of Tax-Calculator, the table generator for diagnostic tables looks like this: create_distribution_table(calc, groupby, result_type, income_measure='_expanded_income'). Comparing our function signature with the sketch, we can see that planX/planY options (except difference of two plans) can be handled by calc argument, aggregates/average can be handled by result_type, the table classifiers by income_measure, bins/deciles by groupby. We probably need to add one more argument (or any other easy ways) to indicate whether this is showing the difference or just one calculator's results. Similarly for the difference table, create_difference_table(calc1, calc2, groupby, income_measure='_expanded_income'), we only need to add one more argument to switch among payroll, individual income taxes and the sum of the two.

On the backend of webapp, drop Q has a similar set of table generators, which need to be expanded as the ones we have in Tax-Calculator utils.py. Did I misinterpret anything from utils.py in both Tax-Calculator or drop Q @talumbau? Thanks!

In terms of the interface, what I'm not quiet sure is whether we want to calculate all the tables on the back and sent all of them to the front, and then let the users to see the already-finished tables. Or through front-back interaction, generating tables on the go. The second option doesn't seem efficient to me, but the first one needs 36 (3X2X2X2 + 2X2X3) tables generated before users can see anything.

I should be able to make the changes pretty quickly to Tax-Calculator utils.py. But kind of feel we need to straighten this issue out before we start. I was also wondering by what time we need to have this done? @MattHJensen

[MattHJensen]

@zrisher, could you make a big push on output tables and try to get as much of the feedback from this issue into next Thursday's release? Is that a reasonable time table? @Amy-Xu and @talumbau would be able to work with you to get whatever you need into tax-calculator and drop q.

I see those todos as the following, but it is worth looking over the whole discussion again.

1. generalize into three types of tables, variations of which are chosen with radio buttons as per the last few comments in this issue.
2. Through some means (potentially by adding the option to hide columns, reducing white space, reducing font, or some other magic) make it so that users can copy the tables into a word document as per the earlier comments in this issue. Default landscape word document would be ok, portrait would be best.
3. Make everything as high contrast as possible.

[zrisher]

@MattHJensen Yes I can definitely work on this this weekend and early next week. I'm on vacation Wed-Fri for a wedding though. If the tables are readily available I think we should be able to get a working version together.

Re: the data flow, since we're designing an API my feeling is that the data returned from the API should be in the format that makes the most sense to most consumers. So if most people using the API would expect tables of these kinds, then the call to calculate should directly return data organized in that manner. That work should be done in taxcalc (since dropq will eventually be removed) and passed through dropq accordingly.

[MattHJensen]

@zrisher, do you think this could be incorporated before a release this Friday?

[talumbau]

resolved via #134