...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 thedo.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.