...because how else are you going to get a capital 'R' into mapviz?

The MAP assessment is a computer-adaptive, norm-referenced assessment published by NWEA, a not-for-profit organization that specializes in assessment. More than 10 million students take the MAP assessment - including KIPP, the organization where Chris works, and Andrew used to work before he joined Public Prep.

We'd like mapvizeR to be a home where data scientists working with MAP data can share visualizations and analysis tools, given that we're all working on a common data set. If you work with MAP data, please reach out!

Nope! This is an independent community effort.

mapvizieR is a product of some lessons learned about the promises, and pitfalls, of sharing common analysis code. Central to our approach here is workflow to create a mapvizier object, so that plots, analysis, and reporting can benefit from clear definitions and data structures. The basic idea is that if each participating entity can build a data loading pathway into the mapvizieR object, reporting becomes easy scalable.

Take a look at this this vignette, which describes the object in detail.

prep MAP data and create cdf_long and cdf_growth dataframes. along with roster info, those data frames get wrapped up into a mapvizieR object, which can be passed to the visualization functions below..

test data frames to see if they conform with mapvizieR conventions and expectations.

these plots show MAP scores for a group of students across multiple testing terms. they expect a cdf_long dataframe and return ggplot charts. some examples:

• becca_plot()
• galloping_elephants()

unlike the functions above, which can take 1, 2, 3, n... test seasons, a lot of MAP analysis revolves around growth windows. these visualization functions expect a 'cdf_growth' dataframe. examples include:

• quealy_subgroups()
• haid_plot()
• goal_bar()

college ready/rutgers ready growth stuff will go here

• follow the lintr conventions https://github.com/jimhester/lintr
• .lintr has configuration options for the lintr bot.
• read about rstudio code analysis integration here

• write tests & vignettes off of the sample CDF in data/CombinedAssessmentRsults.csv

• did you how it said 'write tests' up there? write tests!

• a note on testing: remember that if you are doing something fancy with do.call, coveralls/travis might give you the false impression that you have full coverage. enumerate the types of things the do.call step might do, and write test cases for each. (this bit me here)

• separate data processing functions from visualization functions

• use ggplot themes, where possible, to handle formatting stuff (font size, transparency, etc) on plots

• there's a tag for design philosophy in issues; put down thoughts about how we're thinking about handling data, workflows, etc there.