This is a sub-issue for issue #906 where we can discuss the new outputs approach. This approach was outlined in #906:
Model outputs
Model-specific table building functionality will be removed from PolicyBrain. Instead, the upstream project will deliver content that is already renderable such as an HTML table or a picture. The upstream project will also deliver content that is only meant to be downloaded by the user such as a CSV file. The user will have an option to download all content as a zip file. All of this data will be stored by the webapp in these deliverable formats. This should resolve many of the backwards compatibility problems that have tripped us up in the past and give more power and responsibility to the upstream project for delivering results to the user. Example outputs are CSV files, JSON files, and tables or graphs (both static pictures and interactive widgets (see the CCC bubble plot)). The tables or graphs could either be pictures or some type of HTML/JavaScript file(s). We would need to establish further rules about what formats are allowed and their maximum size. They can provide anything that generally fits on grid, and we encourage the tables and charts to view well on mobile devices. See low-fi mockup here!
In order to implement this approach, we need to do these items:
Transition Tax-Calculator and B-Tax outputs to either renderable or downloadable data
Develop HTML page to display outputs, provide functionality to download zip file of all outputs
Store and serve all of this data
To get started on this, I think that we should produce a simple prototype so that we can have a better idea about how this outputs page would look and what types of unexpected technical challenges may come up. Further, I think having something that is a little more concrete would help us all have a clearer vision for what this outputs page would look like and how it would work.
This prototype should:
render two or three of the tables produced by Tax-Calculator using the dataframe.to_html method.
store this data in a Postgresql database
provide an option to download all ouputs as a zip file
Next steps after prototype include:
make the output page dynamic in that it can handle varying numbers of outputs
provide more types of media besides tables
explore ways to serve the media more efficiently
add styling and formatting to the outputs page
Backwards compatibility with previous results:
Keep existing code and data to serve the old results
one option is to have a separate site running on a low-cost heroku formation (or some type of AWS instance) that serves the code as is and data as is.
utilizing existing functionality minimizes the amount of work done up front to serve the old data formats. There could be long-term issues with running very old code with old software dependencies
I welcome and encourage all feedback. In particular, I'm interested in feedback on:
Are any steps missing?
Are the steps out of order?
Is anything still unclear?
Are there any barriers to this approach that I could be missing?
This is a sub-issue for issue #906 where we can discuss the new outputs approach. This approach was outlined in #906:
In order to implement this approach, we need to do these items:
To get started on this, I think that we should produce a simple prototype so that we can have a better idea about how this outputs page would look and what types of unexpected technical challenges may come up. Further, I think having something that is a little more concrete would help us all have a clearer vision for what this outputs page would look like and how it would work.
This prototype should:
dataframe.to_htmlmethod.Next steps after prototype include:
Backwards compatibility with previous results:
I welcome and encourage all feedback. In particular, I'm interested in feedback on:
@martinholmer @jdebacker @MattHJensen @GoFroggyRun @lucassz @Abraham-Leventhal @andersonfrailey